Revision as of 12:25, 22 December 2019

This page has been written to describe how IPv6 support has been provided in mIRC v7 onwards and the quirks of the current implementation, and to provide guidance to scripters on how to code /dns and /sockopen commands so that they work reliably regardless of the IPv4/v6 connectivity of the local and remote systems and regardless of the IP version used by the current IRC connection.

Background

mIRC was first conceived in 1995, when the Internet was in its infancy and IP version 4 seemed like it would easily scale to cope with global usage. But that was before mobile phones became IP based and the Internet of Things joined the fray.

Eventually it became clear that IP version 4 would run out of addresses at some point, and a new IP version 6 Internet was launched in parallel. The IPv4 Internet and IPv6 Internet share a lot of concepts and technologies, but they are essentially separate networks, with end-points (users or servers) residing either on the IP v4 network or the IP v6 network or both. (There are some technologies that provide some co-existence functionality, but these are probably not relevant here.)

Version of mIRC up to v6.x supported only IP v4. Version 7.0 in April 2010 introduced the first support for IPv6 and as IPv6 started to be supported by both IRC servers and IRC users, mIRC's IPv6 functionality was tweaked through to c. 2016 and is now considered to be mature and stable.

Up until December 2019, IPv4 addresses have been the primary allocation, with some servers and users also having an IPv6 address. This has meant that an IPv6 user wanting an IP connection with an IPv4 end-point could use IPv4 instead. However IPv4 addresses are now in seriously short availability, and it will become increasingly likely that both servers and end-users will start having only IPv6 addresses.

However, it should be recognised that mIRC's IPv6 support was implemented before there was widespread real-world usage of IPv6, and with the benefit of hindsight there are some areas in DNS name resolution where questionable decisions were made - the consequence is that mIRC (currently) has some implementation oddities that scripters and some users need to be aware of.

There are actually surprisingly few mIRC settings relating to IPv6. Out of the box, mIRC is capable of talking to both IPv4 and IPv6 networks without special configuration.

Still, it is important to understand how ipv6 works if you want to avoid any troubles.

DNS lookups

In order to resolve a domain name (for an IRC server or for any other connection) to an IP address (either an IPv4 or IPv6 address), mIRC requests Windows to do a DNS lookup. mIRC doesn't need to do a DNS lookup if you are specifying an IPv4/v6 IP address explicitly rather than using a domain name.

A status window has 3 possible states regarding the version of IP it can use: IPv4, IPv6 or both.

• When a new connection window is opened, the IP version state is set to ipv4 if the mIRC option Enable IPv6 support and prioritize IPv6 over IPv4 connections is not enabled, and v4/v6 if it is set.

• Making a connection via a host name without specifying the IP version explicitely (i.e. you don't user /server -4 or -6 and don't specify an explicit IP address) does not change the DNS lookup state.

• Making a connection using an explicit IP address or the -4 or -6 switches, changes the DNS lookup state to that IP version.

• It is therefore not possible to change the DNS lookup state for a connection window back to v4/v6 once it has changed to v4 or v6. It can only be reset by opening a new connection window

Ipv6 and Ipv4

This is the state you start with if you have the mIRC option for ipv6 enabled, (if you use /server -m6 for example, you can still view it as a short ipv4 state and then ipv6), again, you cannot go back to that state once you change from it.

In this state, you can resolve hostname to both ipv4 and ipv6 without explicitely asking for them, /sockopen and /dns without -4 and -6 switches will correctly work in all cases.

To stay in this state, you must never use any of the -4 or -6 switches in /server and you cannot pass an ip address directly to /server, you must use "/server hostname"

Ipv6

This is the state you are in if you used /server -6 or passed an ipv6 ip address to /server.

In this state, you cannot resolve hostname to ipv4 without asking explicitely for it, ipv4 is said to be disabled (by default). To be explicit about ipv4 and override the default, you must use direct ipv4 ip address (because then no DNS resolution happens) or use the -4 switch. That does mean old scripts using /sockopen or /dns on hostname which resolve to ipv4 only, currently fail in this state, they need to use the -4 switches if they are using hostname and needs ipv4 to work.

Therefore, if you attempt to reconnect to a server in this state without being explicit about ipv4, it will use ipv6 no matter what (it will fail to connect to an hostname resolving to an ipv4 ip address only).

Ipv4

This is the state you are if you used /server -4 or passed an ipv4 ip address to /server.

In this state, you cannot resolve hostname to ipv6 without asking explicitely for it, ipv6 is said to be disabled (by default) even if you have the mIRC option set. To be explicit about ipv6, and override the default, you must use direct ipv6 ip address (again, no DNS resolution needed) or use the -6 switch.

Notes

When using /sockopen -d, mIRC will base its DNS resolution on the ip address type, if it's an ipv6, it will look for ipv6 address (unsure it look for ipv4 still then depending on the state you are in)

Potential future mIRC enhancement

All in all, the mIRC option is the best choice if you want ipv4 to work (by default) later on, on your ipv6 connection. This decision to limit DNS lookups to the IP version of the state of the status window by default is odd, rather than do DNS lookups based on the versions that the user has connectivity over. Consequently, to ensure that connections are made whenever they are possible, regardless of the IP version used by the status window's state, scripts need to explicitly use the -46 switches on every /dns and /sockopen command in order to make a connection on the opposite IP version when needed, and scripts that have been written without this (e.g. written before IPv6 was implemented in mIRC) will not have backward compatibility and will not work reliably.

Indeed that makes sure it works for any type of ip address:

• ipv4/ipv6 state - there's no problem in this mode, you already have both, adding -46 won't change anything.
• ipv6 state - the -4 will request ipv4 explicitely while -6 is going to be ignored if you're resolving to ipv4 only (and otherwise, well ipv6 is going to be used)
• ipv4 state - the -6 will request ipv6 explicitely while -4 is going to be ignored if you're resolving to ipv6 only (and otherwise, well, ipv4 will be used)

With the benefit of hindsight, it might have been better for /sockopen (and /dns) without -4 or -6 to undertake DNS lookups on both IP versions (e.g. make the new /dns and /sockopen be like /dns -46 and /sockopen -46 by default), and to try first the version for a connection based on either the IRC connections IP version or the IP version prioritised in mIRC Options, but with a consistent fallback to the opposite version if a connection could not be made with that primary version.

As the number of IPv6 connected mIRC users increases substantially over the next few years, this issue is likely to become more frequent. In particular as IPv4/v6 connected users still connecting to IRC primarily over v4 increasingly try to make connections to end points that are IPv6 only, this incompatibility for older scripts may become a much more significant issue.

It would be nice if mIRC were to recognise this likelihood and make this change now despite the potential for occasional backward compatibility issues, and in the knowledge that this change would balance these backward compatibility issues with avoiding a potentially far greater level of backward compatibility issues from existing scripts failing.

IPv6 priority on tunnelled IPv6

As IPv6 only end-points increase, the number of IPv4 only users wanting to use a tunnelling IPv6 protocol (like Teredo) to get IPv6 functionality for occasional essential use is likely to grow. The issue is that Teredo connections involve a distant gateway which adds significant performance overheads, meaning that IPv4 connections should be given priority over IPv6 ones wherever possible.

Again, it seems likely that the number of users in this situation will increase substantially in the next few years, and it would be helpful if mIRC were to recognise this and make failover work when IPv4 is set as priority not just when you set IPv6 as priority.