Network

Three new things to know about deploying IPv6

Fields marked with an * are required

Subscribe to our newsletter

flow of information for obtaining an IPv6 address using RFC 7217

For people thinking of implementing IPv6 (Internet protocol version 6), AARNet’s Glen Turner reveals three changes to IPv6 you won’t find in the textbooks yet:

  1. Router Advertisements now contain details of a recursive DNS server, making deployment of IPV 6 simpler
  2. IPv6 addresses are no longer based upon MAC addresses, improving privacy and makes scanning more difficult
  3. Operating systems increasingly prefer using IPv6. 2015 marks the end of IPv6 as a ‘new’ protocol and the start of IPv4 as the ‘old’ protocol.

Here are the three changes to IPv6 in more detail:

1. Router Advertisements now contain details of a recursive DNS server

Router Advertisements are periodically sent by IPv6 routers to tell computers about the subnet their interface is attached to. When a computer brings up an interface it multicasts a Router Solicitation into the subnet to prompt an immediate Router Advertisements from all of the routers on that subnet. If the subnet is configured with Stateless Address Autoconfiguration (SLAAC) then the computer now has the information it needs to configure its interface and its routing table.

Figure 1. Router Solicitation prompts another Router Advertisement.

 

Before a web browser will work the IP address of a recursive DNS forwarder also needs to be configured. This is mostly done by IPv4 at present. What do IPv6-only computers do?

The designers of IPv6 were reluctant to put the address of a DNS forwarder into the Router Advertisement. Service naming was not regarded as a ‘network layer’ concern. The DNS of the era was not a complete service discovery solution, so this would be a slippery slope, with the addresses of NTP servers and other network services being contained within an ever-growing Router Advertisement.

There were successive unsatisfactory arrangements:

  • manually configuring the IPv6 address of a DNS forwarder
  • ‘Stateless DHCPv6’, which asks a DHCPv6 server for the address of a DNS forwarder, despite having received addressing
  • without needing a DHCPv6 server.

Practice shows that the only satisfactory arrangement is for the Router Advertisement to contain the IPv6 address of a DNS forwarder. This was described in RFC6106 as the Recursive DNS Server and the DNS Search List fields.

These configuration extracts have highlighting showing the configuration of a Recursive DNS Server:

IPv6 code

IPv6 RFC 6106 code extract

IPv6 RFC6106 code extract

DNS has now grown to supply generalised service discovery. Once DNS is configured it can then be used to find the IPv6 addresses of other network services. For example, a network time protocol server could be found by asking the recursive DNS server to resolve the query ‘IN SRV _ntp._udp.example.com.’, where ‘example.com.’ is taken from the DNS Search List in the Router Advertisement. Thus DNS is the only network service which is needed in the Router Advertisement.

The beginnings of support for RFC6106 are present in most routers and most operating systems. The combination of Stateless Address Autoconfiguration, Router Advertisements with RDNSS, and anycast DNS servers can give a IPv6 network design which is robust against many more failures than IPv4 networks.

 

2. IPv6 addresses are no longer based upon MAC addresses

Components of an common /48 IPv6 address

Figure 2. Components of an common /48 IPv6 address

 

Countless books and articles about IPv6 describe using Stateless Address Auto-configuration to determine the Interface Identifier for global IPv6 addresses. The top 64-bits of the address — the subnet’s routing prefix — is retrieved from a Router Advertisement. The lower 64-bits of the address — the Interface Identifier — is determined by the computer which is enabling its interface. The Interface Identifier can be any value. To minimise duplicate addresses the computer uses the interface’s MAC address, transformed into the EUI-64 format to allow interoperation with future forms of Ethernet.

IPV6 code extract

In this example the top 64-bits from the Router Advertisement are 2001:db8:1::/64; and the lower 64 bits are ba27:ebff:fe8c:174d, which is the EUI-64 transformation of the 48-bit MAC address b8:27:eb:8c:17:4d.

Privacy is lost with this scheme. The transformed MAC address is a unique number a server can use to track a computer as it moves from one network to another.

The IETF developed IPv6 Privacy Addressing in response to the privacy concerns of MAC-based Interface Identifiers. Privacy Addressing keeps changing the Interface Identifier. This is operationally challenging: a fault report can be hard to resolve when the IPv6 address in the report has long since disappeared.

Using MAC-based Interface Identifiers also makes life easier for vulnerability scanners. At first thought IPv6 seems impossible to scan: all that empty space between the few occupied addresses. But MAC addresses have two parts: the top three bytes are assigned to manufacturers; and the bottom three bytes must be 95% used before a manufacturer can ask for more space. With the publicly available register of MAC address assignments the scanner can determine much smaller ‘interesting’ ranges of IPv6 Interface Identifiers. For example, those containing MAC addresses issued in the past few years to computer manufacturers.

Sixty-four bits could be taken from a cryptographic random number generator and used as an Interface Identifier. This number could be saved to permanent storage so that the value of the Interface Identifier survives a reboot. This scheme solves the scanning problem: the random addresses will be randomly distributed across the 264 range. It doesn’t solve the privacy problem, as a unique random number is just as good as a MAC address for tracking a machine.

That shortcoming can be fixed by hashing the permanent random number with details unique to the subnet being attached to: the subnet prefix, the SSID, the interface’s name. That cyptographically hashed random number is still random, defeating vulnerability scanning. With the subnet prefix changing as the computer moves networks the hashed random number can’t lead to the Interface Identifier being used for tracking. When a machine returns to a particular subnet the inputs to the hash will be the same; in other words: when a computer returns to a subnet it uses the same IPv6 address as when it was last connected to that subnet.

This scheme offers just enough privacy, whilst having just enough stability of addressing. For example, firewall rules can be written for particular computers.

This scheme — or something similar — is used for IPv6 addressing in recent operating systems. The scheme is fully described in RFC7217. The RFC includes some tricky details not explored here, such as what to do if the proposed address fails Duplicate Address Detection.

 

3. Increasing preference for IPv6 connections

DNS is used to implement the transition from IPv4 to IPv6.

When a service available on both IPv4 and IPv6 DNS contains both addresses. For example:

IPV6 code extract

These DNS records are used by programs via the getaddrinfo() system function. This function is given a DNS name and returns an ordered list of IP addresses to attempt to connect to.

For example, a computer with both IPv4 and IPv6 addresses uses the getaddrinfo() system function to ask for the addresses to reach ‘www.aarnet.edu.au’. Under the hood, the function asks DNS for the A and the AAAA records for ‘www.aarnet.edu.au’. The getaddrinfo() function returns a prioritised list of address for the calling program to try, namely ((AF_INET6, 2001:388:3:803::3, …), (AF_INET, 202.158.207.3, …)). The calling program takes the first entry from the list, attempting to connect to the IPv6 destination 2001:388:3:803::3 . If this destination is not reachable then the program takes the next entry from the list, attempting to connect to the IPv4 destination 202.158.207.3.

A computer with only IPv4 addresses or with only IPv6 addresses has a list containing only IPv4 addresses (from DNS’s A records) or containing only IPv6 addresses (from DNS’s AAAA records).

You can see which protocols and addresses your particular computer is proposing for a particular name by using a simple Python program typed at your computer’s command line:

IPV6 code extract

On this computer ‘10’ is the numeric value of the IPv6 address family (AF_INET6) and ‘2’ is the numeric value of the IPv4 address family (AF_INET).

The author of getaddrinfo() — the operating system vendor — has a great deal of control over when an IPv6 destination is selected and when an IPv4 destination is selected. If they want to prefer IPv6 then they put IPv6 addresses earlier in the list, if they want to prefer IPv4 then they put IPv6 addresses later in the list.

The program too has some control. It need not use the address information in the order presented. The program could even implement its own DNS resolver and avoid the use of getaddrinfo() entirely. This is done by some web browsers.

This is a simple example. The real world is more complicated. The complexities are described in RFC3484 Default address selection for Internet Protocol version 6 and tabulated within the GNU C Library’s configuration file /etc/gai.conf.

The same small program can be used to explore the complexity in circumstances which might be of concern. On this Linux computer getaddrinfo() pushes the IPv6 address to the end of the priority list after the interface temporarily loses its IPv6 global address.

IPv6 code extract

Apple takes a different approach. Rather than using a table of conditions, Apple’s ‘happy eyeballs’ implementation attempts to give the best user experience by sending simultaneous IPv4 and IPv6 connections then abandoning the slower connection. This approach worked well when IPv6 networks were flaky tunnels used by early adopters. But now that IPv4 and IPv6 are implemented on the same production network the algorithm leads to a 50:50 split between IPv4 and IPv6 connections for websites which support both protocols.

The IPv6 networks of 2015 are mostly production networks. Furthermore the latency and jitter of the IPv4 network is increasing as stateful NAT replaces the more robust stateless packet forwarding used by traditional IPv4 and by IPv6. If IPv6 is available then it should be preferred: not only to advance the migration to IPv6, but also because IPv6 is now the better performing of the two protocols.

The most recent Apple operating systems now wait for 25ms before launching the ‘parallel’ IPv4 connection attempt. Apple say this leads to IPv6 being used for 90% of connections to dual-homed servers.

Similarly the trapdoors on Microsoft and Firefox browsers have recently been removed. These trapdoors disabled IPv6 whenever it encountered a fault, even if that network fault was also occurring to IPv4 traffic.

The 2015 releases of operating systems now give sharp preference to IPv6 when it is available. This marks the end of IPv6 as a ‘new’ protocol and the start of IPv4 as the ‘old’ protocol.


Related Stories

Conferences / Featured / Network

Aug 15, 2017

Register now for GLIF 2017-17th Annual LambdaGrid Workshop

REGISTER NOW FOR GLIF 2017 - the 17th Annual Global LambdaGrid Workshop, hosted by AARNet at Sydney University 25-27 September This event brings together leading network experts from around the world to collaborate and exchange knowledge on new networking technologies, pathfinding, middleware and applications. The workshop has a specific focus on how global...

Conferences / Featured / Network

Aug 4, 2017

AARNet Networkshop 2017 Highlights

Technologists working on networking and networked technologies at AARNet-connected universities and research institutions gathered in Melbourne on 22 & 23 June 2017 for Networkshop. Watch the video to hear what some of the highlights were for delegates. Networkshop 2017 was a two-day technical community-building event with an emphasis on technical...

Conferences / Network

Jul 27, 2017

AARNet Networkshop 2017 Highlights

Technologists working on networking and/or networked technologies at AARNet-connected universities and research institutions gathered in Melbourne on 22 & 23 June 2017 for Networkshop. Watch the video to find out what some of the highlights were for delegates. This was a terrific technical community-building event with an emphasis on...