(Major edit to try to explain IPv6 issues more clearly.) |
(Another rewrite of how we think it works to try to simplify the explanation.) |
||
Line 11: | Line 11: | ||
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. | 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. | + | 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 | + | 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. |
== mIRC Settings == | == mIRC Settings == | ||
Line 20: | Line 20: | ||
There is one mIRC setting for IPv6: '''Tools''' / '''Options...''' / '''Connect''' / '''Options''' / '''Ports...''' / '''Enable IPv6 support and prioritize IPv6 over IPv4 connections'''. | There is one mIRC setting for IPv6: '''Tools''' / '''Options...''' / '''Connect''' / '''Options''' / '''Ports...''' / '''Enable IPv6 support and prioritize IPv6 over IPv4 connections'''. | ||
− | Despite the title of this option, IPv6 '''''is''''' supported regardless of whether this option is checked or not. | + | Despite the title of this option, IPv6 '''''is''''' supported regardless of whether this option is checked or not. This option only seems to have a single functional impact - to enable fallback from IPv6 to IPv4 when you have a native (i.e. not tunnelled) IPv6 connection in parallel with IPv4. |
− | + | '''Note:''' It does not assist with connectivity in situations where you have only IPv4 connectivity, or (increasingly likely in the future) either because you have IPv6 only connectivity yourself (because increasingly IPv4 addresses will simply not be available) or alternatively you have only IPv4 native connectivity and decide to implement tunnelled (e.g. Teredo) IPv6 connectivity to get be able to functionally connect to IPv6 only addresses even if performance is not great. | |
− | |||
− | == | + | == DNS lookups == |
− | + | In order to convert 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 connection window has three DNS lookup possible states - IPv4, IPv6 or IPv4/6. | |
− | + | * When a new connection window is opened (because you start mIRC or you do File / New Window or you click the Connect Button in Options / Connect with New window checked or by a /server -m/n command manually or in a script), the IP version state is set to v4 if '''Enable IPv6 support and prioritize IPv6 over IPv4 connections''' is not set, and v4/v6 if it is set. | |
− | + | * Making a connection via a host name without specifying the IP version (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 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. | |
− | + | mIRC then runs all default DNS lookups (e.g. for IRC connections, /dns or /sockopen) which do not have an explicit -4, -6 or -46 switch using the DNS lookup state. | |
− | + | == Script Authors == | |
− | + | If you want to query both types of IP version i.e. in order to connect to an IPv4/6 end-point regardless of whether your IRC connection is IPv4/6, then '''you should explicitly use the -46 switch on the /dns or /sockopen command''' in order for your script to connect reliably regardless of the IRC version used by the connection window. | |
− | |||
− | |||
− | |||
− | |||
− | == | + | == Potential future mIRC enhancement == |
− | + | With the benefit of hindsight, this behaviour is a bit odd as it gives rise to the possibility that mIRC will limit connections to one IP version, with a risk that such a connection is not possible on that version but would have been possible on the other IP version. | |
− | + | This is particularly true for scripts which pre-date mIRCs IPv6 support, which used to work reliably in an IPv4 only world, but which can now fail increasingly frequently in a mixed IPv4/v6 world. This is because of the decision to limit DNS lookups to the IP version of the IRC connection in most circumstances, rather than do DNS lookups based on the versions that the user has connectivity over, and then where ''both'' IPv4 and IPv6 connections are possible to prioritise the choice of IPv4/v6 based on either the IRC connection type or the '''Enable IPv6 support and prioritize IPv6 over IPv4 connections''' setting. | |
− | + | ||
+ | Consequently, to ensure that connections are made whenever they are possible, regardless of the IP version used by the IRC connection, scripts need to explicitly code -46 on every /dns or /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. With the benefit of hindsight, it might have been better for /sockopen without -4 or -6 to undertake DNS lookups on both IP versions, 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. | ||
+ | |||
+ | However the '''only''' means at present for these users to get mIRC's automatic DNS queries for both IPv4/v6 is to set '''Enable IPv6 support and prioritize IPv6 over IPv4 connections''' and, as the name suggests, this gives priority to IPv6 connections. | ||
+ | |||
+ | 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. | ||
[[Category:mIRC|ipv6]] | [[Category:mIRC|ipv6]] |
Revision as of 18:45, 20 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.
Contents
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.
mIRC Settings
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.
There is one mIRC setting for IPv6: Tools / Options... / Connect / Options / Ports... / Enable IPv6 support and prioritize IPv6 over IPv4 connections.
Despite the title of this option, IPv6 is supported regardless of whether this option is checked or not. This option only seems to have a single functional impact - to enable fallback from IPv6 to IPv4 when you have a native (i.e. not tunnelled) IPv6 connection in parallel with IPv4.
Note: It does not assist with connectivity in situations where you have only IPv4 connectivity, or (increasingly likely in the future) either because you have IPv6 only connectivity yourself (because increasingly IPv4 addresses will simply not be available) or alternatively you have only IPv4 native connectivity and decide to implement tunnelled (e.g. Teredo) IPv6 connectivity to get be able to functionally connect to IPv6 only addresses even if performance is not great.
DNS lookups
In order to convert 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 connection window has three DNS lookup possible states - IPv4, IPv6 or IPv4/6.
- When a new connection window is opened (because you start mIRC or you do File / New Window or you click the Connect Button in Options / Connect with New window checked or by a /server -m/n command manually or in a script), the IP version state is set to v4 if Enable IPv6 support and prioritize IPv6 over IPv4 connections is not set, and v4/v6 if it is set.
- Making a connection via a host name without specifying the IP version (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 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.
mIRC then runs all default DNS lookups (e.g. for IRC connections, /dns or /sockopen) which do not have an explicit -4, -6 or -46 switch using the DNS lookup state.
Script Authors
If you want to query both types of IP version i.e. in order to connect to an IPv4/6 end-point regardless of whether your IRC connection is IPv4/6, then you should explicitly use the -46 switch on the /dns or /sockopen command in order for your script to connect reliably regardless of the IRC version used by the connection window.
Potential future mIRC enhancement
With the benefit of hindsight, this behaviour is a bit odd as it gives rise to the possibility that mIRC will limit connections to one IP version, with a risk that such a connection is not possible on that version but would have been possible on the other IP version.
This is particularly true for scripts which pre-date mIRCs IPv6 support, which used to work reliably in an IPv4 only world, but which can now fail increasingly frequently in a mixed IPv4/v6 world. This is because of the decision to limit DNS lookups to the IP version of the IRC connection in most circumstances, rather than do DNS lookups based on the versions that the user has connectivity over, and then where both IPv4 and IPv6 connections are possible to prioritise the choice of IPv4/v6 based on either the IRC connection type or the Enable IPv6 support and prioritize IPv6 over IPv4 connections setting.
Consequently, to ensure that connections are made whenever they are possible, regardless of the IP version used by the IRC connection, scripts need to explicitly code -46 on every /dns or /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. With the benefit of hindsight, it might have been better for /sockopen without -4 or -6 to undertake DNS lookups on both IP versions, 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.
However the only means at present for these users to get mIRC's automatic DNS queries for both IPv4/v6 is to set Enable IPv6 support and prioritize IPv6 over IPv4 connections and, as the name suggests, this gives priority to IPv6 connections.
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.