From WikiChip
IPv6 - mIRC
< mirc
Revision as of 15:45, 21 December 2019 by Ouims (talk | contribs) (mIRC Settings)


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.

There is one global setting for ipv6 in mIRC option, and that setting can be overriden per status window by using "/server -6" or /server ipv6_address"

Using "/server -6" or using "/server ipv6_address"

What it does:

  • sets the status window to 'ipv6' - meaning that if you attempt to reconnect without being explicit about ipv4 (not using -4 on /server or using the toolbar's connect button, for example), it will attempt to use ipv6 (will fail on ipv4 resolution of hostname), this 'ipv6' state is per status window and lasts forever until the status window is closed or until you explicitely ask for ipv4 (SSL also works this way).
  • disables ipv4 by default - as mentioned above, ipv4 is disabled 'by default': trying to /server (or /sockopen or /dns), with an hostname which resolves to an ipv4 address only, without being explicit about ipv4 (again, using the -4 switch, it is supported by /server, /dns and /sockopen) will fail.
  • overrides the global setting - indeed, there's no priority to ipv6 with ipv4 fallback here, it's only ipv6 by default where you have to explicitely ask for it if you want ipv4 support (-4 switches)

The drawbacks:

  • Old scripts using /sockopen or /dns on hostname which resolve to ipv4 only, will fail.

The solution to get ipv4 to work in all case, in this mode:

  • Use the -4 switch on /server, /dns, and /sockopen to explicitely enforce ipv4 resolutions.

mIRC Option

You can find it at alt + O Tools / Options... / Connect / Options / Ports... / Enable IPv6 support and prioritize IPv6 over IPv4 connections.

This is the global option, this option enables IPv6 by default.

It means that /server, /dns and /sockopen can use ipv6 but that ipv4 still work by default, you do not have to ask for it explicitely with the -4 switch.

However, to be in this case you have to:

  • not use /server -6
  • not pass an ipv6 directly to /server

The drawbacks:

  • You are forced to use an hostname, you cannot connect to an ipv6 server and have ipv4 working without explicitely asking for it if you are connecting with an ip address, which does not make any sense.


All in all, the mIRC option is the best choice is you want ipv4 to work (by default) later on, on your ipv6 connection. Otherwise you must make sure all your script use the -4 switches when they need to (which is probably always unless it's your server and you know it only resolve to an ipv6).


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

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.