Revision as of 16:15, 22 December 2019

The text below is entered here temporarily and is a proposed version of this page for review.

IPv6 - mIRC

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.

This page is most relevant if your PC has both IPv4 and IPv6 connectivity to the internet as it describes issues related to mIRC making connections to both network types (even if they are made at different times).

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.)

Versions 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. There are, however, a few quirks with how mIRC handles coexistence between IPv4 and v6, and this page will attempt to explain them.

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.

This page has been written to explain how mIRC's support for IPv6 works, and what you need to know to make it work when the quirks would otherwise create difficulties.

DNS primer

Firstly a quick reminder about the purpose of DNS - if you already understand this, please feel free to skip the rest of this section.

Both IPv4 and v6 use numeric addresses to identify computers and how they are connected in order to route information between them - when we humans need to use these numeric addresses we represent them as 1.2.3.4 for IPv4 and 1234::5678::90AB:CDEF for IPv6. Whilst these numeric addresses are great for computers to route packets, they are not so good for giving a computer a name or for identifying the services it provides, and of course the number used to route packets can change over time even if it is still the same computer you are trying to talk to. (In other words "I am a name not just a number".)

The names given to computers on the Internet (like www.wikichip.org or irc.undernet.org) are called Domain Names or hostnames, and the service provided to convert Domain Names to IP addresses is called DNS.

mIRC's quirks

Although mIRC can make IPv6 connections to explicitly specified IPv6 addresses out of the box without any mIRC configuration settings needing to be set, unfortunately this is not the same as mIRC fully supporting IPv6 without any configuration. Although you can connect using an explicit IPv6 address, most of the time we mIRC users would prefer to use domain names to find these computers rather than their IP addresses. The quirk in mIRC's implementation of IPv6 is that whilst it is capable of looking up both the IPv4 and IPv6 numeric addresses for a hostname, often it limits the lookup to only one version, and if the version that isn't queried happens to be the only version that the other computer supports then mIRC will not make the connection, and will instead tell you that it is "* Unable to resolve server".

Additionally whilst we would expect mIRC's IPv6 functionality to work consistently for the same commands or for connections to the same servers, unfortunately the IPv6 implementation can deliver different results not only depending on which IP version you are currently using to connect to IRC with, but indeed also based on what connections you may previously have made hours or even days ago (so long as you haven't closed and reopened mIRC in the mean time).

These are the gotchas that you need to be aware of!

mIRC's DNS lookups

As described above, for a domain name you can lookup either the IPv4 addresses or the IPv6 addresses or both types of address.

mIRC decides which versions to query based on an internal state associated with the status window of the connection.

A status window has 3 possible states regarding the version(s) of IP it uses for DNS lookups:

• IPv4
• IPv6
• Both - IPv6/v4.

mIRC will only lookup domain names (for your IRC connection or for socket connections) on both networks when the status window state is IPv6/v4.

When the status window state is IPv4 or IPv6, it will only lookup IP addresses on that network and will not lookup IP addresses on the other network. If IP addresses for the host name only exist on the other network, but mIRC doesn't look them up, then you will get "Unable to resolve server" and, even though your computer is capable of connecting to the hostname using the other network, mIRC will not try that and your connection will not be made.

Only when the internal state is IPv6/v4 will mIRC reliably make connections regardless of which network you are (or were previously) connected to IRC with, and which network the computer you are trying to connect to now is on.

The internal state of the status window is set as follows:

• When a new status 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 v6/v4 if it is enabled. (This setting can be found at Tools Options... (alt + o) > Connect > Options > Ports...)

• Making a connection via a host name without specifying the IP version explicitly (i.e. you don't user /server -4 or -6 and don't specify an explicit IP address) does not change the status windows 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 not possible to change the DNS lookup state for an existing status window back to v6/v4 once it has changed to v4 or v6. It can only be reset by opening a new status window.

IPv6/v4

This is the state a status window starts with if you have enabled the mIRC option for IPv6 priority. (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, mIRC will resolve a hostname to both IPv6 and IPv4 without explicitly telling mIRC to check both versions; IRC connections (e.g. using the connect button or /server), /sockopen and /dns without -4 and -6 switches will correctly work in all cases. In this state, this is equivalent to using these commands with the -64 switch.

If mIRC resolves a hostname to both IPv6 and IPv4 addresses, it will use the IPv6 address to try to make the IRC or socket connection - this is what is meant by IPv6 Priority.

To stay in this state, you must always connect to IRC via a hostname, and never by using either /server -4 or -6 switches or an explicit IP address.

Scripts using /server, /dns or /sockopen which were written for mIRC v6 (i.e. before IPv6 support) generally continue to work in this state because calls to these commands are equivalent to having specified -64.

Summary: If your status window is IPv6 state, then if you want to lookup or connect to an IPv4-only hostname, you need to explicitly code -4 on the /server, /dns or /sockopen command.

IPv6

This is the state you are in if you used /server -6 or used /server with an explicit IPv6 address.

In this state, mIRC does not resolve hostname to an IPv4 address without explicitly requesting mIRC to do so using a -4 switch. IPv4 using hostnames is effectively disabled for this status window.

If you want mIRC to resolve hostnames to IPv4 addresses and make connections over IPv4 for a status window that is IPv6, you need to use either an explicit IPv4 address or use a -4 switch on the command (i.e. /server -4, /dns -4, /sockopen -4).

Scripts using /server, /dns or /sockopen which were written for mIRC v6 (i.e. before IPv6 support) will not use -4 switches (because they didn't exist when the script was written) and consequently if they are run in a status window that is IPv6 they will fail to connect to an IRC or socket server that is IPv4 only - but the script would have worked if the status window was IPv4. For scripts to work reliably they need to code -46 on all /server, /dns and /socket calls.

Summary: If your status window is IPv6/v4 state, then you should be able to connect to IPv4 and IPv6 hosts without any issues. But there is no easy way for a user or a script to determine when the IPv6/v4 state has been changed to IPv4 or IPv6, and then things may start to break.

IPv4

This is the state you are if you opened the status window with IPv6 priority not enabled or if you made a connection to an IRC server using either an explicit IPv4 address or used /server -4.

In this state, mIRC does not resolve hostname to an IPv6 address without explicitly requesting mIRC to do so using a -6 switch. IPv6 using hostnames is effectively disabled for this status window.

If you want mIRC to resolve hostnames to IPv6 addresses and make connections over IPv6 for a status window that is IPv4, you need to use either an explicit IPv6 address or use a -6 switch on the command (i.e. /server -6, /dns -6, /sockopen -6).

Scripts using /server, /dns or /sockopen which were written for mIRC v6 (i.e. before IPv6 support) will not use -6 switches (because they didn't exist when the script was written) and consequently if they are run in a status window that is IPv4 they will fail to connect to an IRC or socket server that is IPv6 only. At present almost all servers have IPv4 connections so this is not a frequent issue, but in the future when IPv4 addresses are exhausted and many more computers will be IPv6 only this may become a far more frequent problem.

Summary: If your status window is IPv4 state, then if you want to lookup or connect to an IPv6-only hostname, you need to explicitly code -6 on the /server, /dns or /sockopen command.

Some examples

The following examples are for users who have both IPv4 and IPv6 internet connectivity:

Manual server connection

1. User connects to irc.ipv4only.net using Options dialog - connects just fine using.
2. User does /server -6 irc.ipv6.net - connects just fine.
3. User tries to connect again to irc.ipv4only.net using Options dialog - connection fails - it worked only a few minutes earlier, now it doesn't - user is flumoxed.

This is true regardless of IPv6 priority setting.

IPv6 priority not set

1. User connects to irc.net by IPv4.
2. Script to connect to www.ipv4only.com by IPv4 works just fine.
3. For some reason user connects to irc.net by IPv6 (for whatever reason).
4. Same script to connect to www.ipv4only.com by IPv4 breaks for no reason apparent to the user.

Additional SockOpen restriction

When using /sockopen -d to bind to a specific network card IP address on your own PC (i.e. to make the socket connection originate from a specific IP address when you have several), mIRC will base its DNS resolution and subsequent connection on the IP version of the IP address you specify to bind to.

If you bind to an IPv6 address (e.g. /sockopen -d 1234::5678::90AB::CDEF), then mIRC will only do an IPv6 lookup on the hostname (because the bind address is IPv6 and so the connection has to be IPv6, so no point in looking up IPv4 addresses).

If you bind to an IPv4 address (e.g. /sockopen -d 1.2.3.4), then mIRC will only do an IPv4 lookup on the hostname (because the bind address is IPv4 and so the connection has to be IPv4, so no point in looking up IPv6 addresses).

To prioritise or Not to prioritise? That is the question!

Assuming that you have IPv6 connectivity of some sort on your PC, you are (or perhaps should be) worrying about whether you should set the IPv6 priority option or not.

As described above, setting IPv6 priority gives you the best chance of network connections succeeding (particularly if you ensure that you preserver the IPv6/v4 state of your status window), but it also means that your hostname-based connections will all be IPv6 where possible, and only IPv4 when an IPv6 address is not available for the hostname.

If your IPv6 internet connection is native, then it is likely that the performance of your IPv6 connections will be on a par with your IPv4 connections, and you are recommended to set IPv6 priority. There should be no real down-side to this - in the event that you switch your status window from IPv6/v4 to IPv6 or IPv4, the situation would be no different had you not set this option.

On the other hand, if your IPv6 internet connectivity is delivered using a gateway protocol like Teredo on your individual PC or 6to4 as part of your network infrastructure, then it is likely that your the performance of your IPv6 connections will be substantially slower than your IPv4 connections. In this situation, you are recommended not to set IPv6 priority and to live with the occasions when connections to IPv6 are not made - which at present, whilst servers generally still all have IPv4 addresses, should be fairly rare. If you do set IPv6 priority in this situation, your IRC connections will default to IPv6 and be slower, but your ability to connect to both types of server is enhanced.

Recommendations for scripters

To ensure that connections are made whenever they are possible, regardless of the IP version used by the status window's state, scripts should explicitly use the -46 switch on every /dns and /sockopen command in order to make a connection on the opposite IP version when needed. 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.

Including these switches will make your script work in all circumstances regardless of the IP state of the status window:

Impact of quirks in the future

At present, almost all users and servers have IPv4 connections. Users connecting via IPv4 will be able to make connections to almost all servers over IPv4. Users who have IPv6 connectivity and set IPv6 priority will still get IPv4 connectivity by default unless they have explicitly connected a status window to a specific version.

However with IPv4 addresses now officially exhausted, it will become increasingly likely that users and servers will be IPv6 only. Whilst IPv6 users can still set IPv6 priority and connect automatically to IPv4-only servers, IPv4-only users will NOT be able to connect to IPv6-only servers and will be forced to implement a gateway protocol like Teredo to get IPv6 connectivity for these situations. But as identified above, with the the current mIRC implementation it is not recommended to set IPv6 priority for gateway IPv6 which is substantially slower, and we can therefore reasonably expect the number of mIRC users experiencing connection difficulties of this form to increase substantially in the near future.

Potential mIRC enhancement

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.

The decision seems a little odd to limit mIRC's DNS lookups by default to the IP version state of the status window, rather than always to do DNS lookups for all versions that the user has Internet connectivity for - but this easy to say with the benefit of hindsight.

The question for mIRC is whether to:

1. Retain the current implementation, preserving backwards compatibility with modern v7 scripts (if there are any) that have explicitly been written to expect that e.g. /dns or /socket calls will sometimes be limited to the IP version of the IRC connection (and sometimes won't) - but which breaks any existing scripts which use /server, /dns or /sockopen but which haven't explicitly been coded with -64 switches on any /server, /dns or /sockopen commands; OR

1. Change mIRC's DNS lookup behaviour, preserving backwards compatibility with any existing scripts which use /server, /dns or /sockopen but which haven't explicitly been coded with -64 switches on any /server, /dns or /sockopen commands, but breaking backwards compatibility with modern v7 scripts (if there are any) that have explicitly been written to expect that e.g. /dns or /socket calls will sometimes be limited to the IP version of the IRC connection (and sometimes won't).

At present, with most servers having IPv4 connectivity, this does not cause widespread connectivity issues. However as more servers become IPv6 only due to exhaustion of IPv4 addresses, IPv4 only users will be pushed into using IPv6 transition technologies to get IPv6 connectivity, and we should then expect the number of occasions when scripts fail because of the quirky DNS implementation to increase substantially.

If the authors decide to change mIRC's behaviour, the recommended changes are as follows:

1. Change the IPv6 Priority setting (and the description) to mean exactly that - for connections to hostnames with both IPv6 and IPv4 addresses, to use IPv6 rather than IPv4.
2. Make /server, /dns and /socket commands without -4 or -6 work as if -46 or -64 had been specified.
3. Make re-connections in the same window to the same server hostname as the last connection use the same IP version i.e. if you were previously connected by IPv6, then reconnect using IPv6.