IPv6

The Internet Protocol (IP) forms the basis of all traffic on the internet. IP is the network protocol that enables all internet-connected computers to reach one another. That includes not only desktops, laptops and mobile devices, but also server systems, webcams and IoT equipment, for example.

IP version 4 (IPv4) is the traditional version of the Internet Protocol. Under this protocol, each device is assigned its own IP address consisting of 4 numbers (32 bits in total), e.g. 192.0.2.26. Using that address, every computer on the internet can, in principle, be contacted by any other.

IPv4 is nearly fifty years old and is now technically outdated (legacy). The main problem with it is that it allows for a maximum of four billion (232) unique IP addresses to be created. That might sound like a lot, but not when you think that there are eight billion people in the world, and that every device – every desktop, laptop, mobile, webcam and so on – should (in principle) have its own IP address (and sometimes more than one) in order to connect to the internet.

The situation is aggravated by the fact that more and more small devices are nowadays internet-enabled and should therefore have their own IP addresses. Examples include smart energy meters, solar panel management systems, central heating thermostats and all other smart home devices. An even bigger number of the sensors and actuators used in industry are internet-enabled as well. IPv4 is completely unsuitable for connecting all those systems and mini-systems, the so called 'Internet of Things' (IoT).

Another, related, problem is that even the biggest private IPv4 address block (10.0.0.0/8), with its sixteen million addresses (used in combination with NAT44) has turned out to be not big enough to support all the internal systems and users of an IT giant such as Microsoft, Google or Amazon (the 'hyperscalers'). The reason being that much of the address space is 'lost' as a consequence of division into practically routable subnetworks.

Problems also arise in the IPv4 address space when organisations and their networks merge or when different virtual private networks (VPNs) are connected.

Despite having significant shortcomings, IPv4 is still used for most of internet traffic.

The stock of IPv4 addresses ran out long ago. In late 2019, RIPE NCC, the Regional Internet Registry (RIR) for greater Europe and western Asia, issued the very last IPv4 addresses. And it's not only the primary supply of IPv4 addresses that has run out: the pool of returned address blocks available for allocation to parties on the waiting list is also completely empty. (That's apparent from the second graph below, which shows linear increases in waiting times and in the number of departing LIRs.)

Consequently, if you need new IPv4 addresses or want to extend your existing network, the only practical option is the secondary (commercial) market.

Figure 1: The RIPE NCC IPv4 address pool. Source: RIPE NCC.

Figure 2: The RIPE NCC IPv4 address waiting list. Source: RIPE NCC.

The reason why the address shortage causes relatively few problems for service providers and end users (in the West.) is that access providers, telecom companies and network operators use all sorts of workarounds to keep the exhausted IPv4 network going a little longer. The main technical tricks used to share out and reuse the existing IP addresses are NAT and CGNAT (on the user side) and SNI (on the hosting side). However, anyone that wants to launch a website or another internet service is affected by the address shortage: it's increasingly difficult to get an IP address from a hosting provider, and the addresses that are available nearly always have to be hired individually by the month.

In order to keep the exhausted IPv4 network going a little longer, more and more makeshift solutions have been developed over time. The main workarounds are NAT and CGNAT (on the user side) and SNI (on the hosting side). However, the near-universal use of those technologies has fundamentally changed the nature of the internet. Today, the internet is a largely asymmetrical network, on which most end users' systems are no longer reachable directly from the internet.

As a result, self-hosting and peer-to-peer protocols are no longer viable or fully functional. So, for example, you can't:

• Run your own web server

• Run your own (distributed) 'social media' server (e.g. Matrix/Synapse, Mastodon, PeerTube or Pixelfed)

• Remotely access files or music stored on your home network

• Access a self-managed address book, diary, bookmarks, task list or notes from various devices (e.g. Nextcloud)

• Set up real-time, relay-delay-free connections between participants in multi-player games

• Realise problem-free, real-time voice and video connections for VoIP/WebRTC calling

• Establish direct connections between distributed/federated network nodes (e.g. Matrix and the fediverse)

More recently, we have seen the emergence of new workaround technologies such as STUN, TURN and ICE, which are designed to fix some of the shortcomings of (CG)NAT. Unfortunately, they don't always work.

However, the Internet Protocol has never distinguished between clients and servers. From the start, it was based on the end-to-end principle, which recognises only hosts, all of which are peers.

For a long time now, the IPv4-based internet, with its workarounds (NAT, CGNAT and SNI) has not offered full connectivity. Consequently, it is not future-proof and forms a serious obstacle to innovation.

The shortage of IPv4 addresses makes it impossible for existing providers to bring new large-scale services to market, such as new mobile applications and the Internet of Things (IoT). Meanwhile, market entrants find it difficult to gain a foothold. That was the case with Freedom Internet when it needed a way of providing all its customers with public IPv4 addresses.

If you need new IPv4 addresses or want to extend your existing network, the only practical option is the secondary (commercial) market. As illustrated by the following graph of transfer data published by RIPE NCC (the Regional Internet Registry (RIR for greater Europe and West Asia), a lively trade in IPv4 address blocks has developed in recent years.

Figure 1: IPv4 transfers in the RIPE NCC region. Source: RIPE NCC.

The seriousness of the IPv4 address shortage is apparent from the inflated prices that address blocks command. According to the broker IPv4 Market Group, the going rate in June 2024 was 30 to 40 euros per address, depending on the block size. Another broker, IPv4.Global, reports similar prices.

Figure 2: Market price of an IP address: change over time. Source: IPv4 Market Group.

Figure 3: IPv4 address prices. Source: IPv4.Global.

IPv4 address blocks are now so expensive that they have become financial assets. In October 2020, network specialist Andree Toonk calculated that the 100 million IPv4 addresses then owned by Amazon were worth about 2.5 billion dollars (now probably more than 3 billion euros). Since then, Amazon [1, 2] and other big cloud service vendors, such as Microsoft, Google and Oracle have steadily continued to buy up address blocks, ultimately at the expense of smaller providers and start-ups.

However, even for large, well-capitalised organisations, buying up IPv4 addresses is not a sustainable solution: although addresses are available, the block sizes are quite small. Small blocks mean long and complex routing tables and cumbersome address management.

Figure 4: Percentage of the IPv4 address space owned by Amazon. Source: Scott Seligman.

In March 2020, Vincentas Grinius, CEO of London-based hosting provider Heficed, predicted that the price of an IPv4 address would double in the next 5 years. He envisaged IPv4 address blocks as a tradeable commodity, with all sorts of associated lease constructions emerging. The going rate was likely to be about 2.50 dollars per address per year, he suggested. However, there is a limited window of opportunity for monetising IPv4 address assets. The adoption of IPv6 means that the value of IPv4 addresses is expected to peak within 10 years, before starting to decline.

The good news is that, in recent years, the prices commanded by IPv4 addresses have indeed stabilised and gone into a sharp decline. There is therefore good reason to believe that Peak IPv4 is now behind us.

The commercial implication of the challenges described above is nearly always that service providers feel the need to charge clients a monthly fee for each IPv4 address they use.

Source: 'IPv4 addresses: the new gold!'

The Internet Protocol has never distinguished between clients and servers. From the start, it was based on the end-to-end principle, which recognises only hosts, all of which are peers. However, the near-universal use of (CG)NAT has fundamentally changed the nature of the internet. Today, the internet is a largely asymmetrical network, on which most end users' systems are no longer reachable directly from the internet.

As a result, self-hosting and peer-to-peer protocols are no longer viable or fully functional. So, for example, you can't:

• Run your own web server

• Run your own (distributed) 'social media' server (e.g. Matrix/Synapse, Mastodon, PeerTube or Pixelfed)

• Remotely access files or music stored on your home network

• Access a self-managed address book, diary, bookmarks, task list or notes from various devices (e.g. Nextcloud)

• Set up real-time, relay-delay-free connections between participants in multi-player games

• Realise problem-free, real-time voice and video connections for VoIP/WebRTC calling

• Establish direct connections between distributed/federated network nodes (e.g. Matrix and the fediverse)

IP is the network protocol that enables all internet-connected computers to reach one another. IP version 6 is latest version of the protocol. Known as IPv6 for short, it's the direct successor to the traditional version, IPv4.

IPv4 may now be regarded as legacy. We should migrate to IPv6 as soon as possible.

IPv6 is a completely new version of the Internet Protocol. It's similar to the old version, IPv4, but not compatible with it. The two main advantages of IPv6 are:

• A vast address space

• Auto-configuration of IPv6 addresses on network interfaces by means of the SLAAC protocol

IPv6 offers 2 additional benefits:

• The packet headers are bigger than with IPv4, but their length is fixed and they don't include a checksum.

• Packets are not fragmented in transit. Instead, the sending host has to ensure that the packets are not too big. If a router receives a packet that is too big to be processed, it sends an ICMP(v6) message back to the sender requesting smaller packets. In theory, that allows IPv6 packets to be processed more quickly. However, the practical advantage is negligible because modern routers are all incredibly fast anyway.

Finally, with IPv6, everyone is fully reachable, opening the way for end users to do self-hosting and use peer-to-peer protocols. Perhaps significantly, such developments are at odds with the commercial interests of hosting service providers that sell business hosting packages and expensive conferencing services.

However, the real benefits of IPv6 are only felt if everyone actually starts using the new protocol.

Absolutely. IPv6 has already been around for nearly 30 years: it was first formally specified in RFC 1883, published in December 1995. IPv6 is a proven, robust technology. In June 2024, nearly half of Google visits were IPv6-enabled.

IPv6 addresses are available in vast numbers: the total IPv6 address space has 340 undecillion addresses. That's 34 followed by thirty-seven zeros.

The prefixes that Regional Internet Registries (RIR's) assign to their members are thirty-two bits long, meaning that each recipient organisation has 24/16 bits available for further subdivision of the address space into 56/48-bit routing prefixes for end users/sites. Each end user/site then has 8/16 bits available for further subdivision across subnetworks.

IPv6 is also supported by all mainstream network equipment: Interoperability is not a problem. Professional equipment no longer requires interoperability testing; all modern systems designed for business use support IPv6.

IPv6 is supported by all main network management software and tools as well. That includes provider platforms such as Plesk, cPanel and DirectAdmin.

Furthermore, IPv6 is supported by all the main operating systems, including both open-source and proprietary systems.

IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Consequently, investment in and migration to IPv6 involve no technological risk.

IPv6 is already in widespread use. In June 2024, nearly half of Google visits were IPv6-enabled, and the proportion is increasing by about 5 percentage points a year. If you are a private end user who has IPv6 and mainly uses Google, YouTube, Netflix, Facebook Instagram and WhatsApp, more than half of your traffic is probably already IPv6-based.

Figure 1: Global client-side IPv6 use. Source: Google.

Figure 2: IPv6 traffic on the Amsterdam Internet Exchange (AMS-IX). Source: AMS-IX.

The following case studies describe major IPv6 implementations by access providers:

• Dual-stack, NAT and CGNAT v. 464XLAT v. DS-Lite

• Telstra switches mobile users to IPv6-only

• South Korean and Vietnamese telecoms firms go for large-scale IPv6-only implementations

• India and China go for large-scale IPv6 implementation

• China targets complete migration to IPv6 by 2030

Against that background, the commercial risks associated with investing in IPv6 are readily manageable. Anyone who invests now is close to being amongst what Rogers' technology adoption model defines as the 'late majority'.

More information about IPv6 adoption is available here.

Version 5 of the Internet Protocol (IPv5) was once proposed as a standard for internet telephony. IPv5 was intended for use alongside IPv4. However, it never got further than the experimental stage or entered operational use. IPv6 is therefore the direct successor to IPv4.

For anyone who provides an internet service – a website, mail domain or webshop, for example – it's important to be easily reachable.

Services that don't yet have IPv6 addresses aren't part of the modern internet, and are less reachable. What's more, search engines assign lower scores to websites that don't support modern internet standards, meaning that they get fewer visitors.

Finally, because of the IPv4 address shortage, visitor traffic is increasingly routed via gateways. As a result, it can be difficult to distinguish new visitors from returnees, or to establish visitors' locations. IPv6 supports so many addresses that everyone and everything can have its own IP address or address block. That makes it easier to perform website usage analyses.

IPv6 is the basis for a completely new version of the internet. If you don't have an IPv6 address, you aren't part of that new internet, so you won't be able to interact with all internet-enabled computers, for example. Now that IPv4 address stocks are exhausted in all regions of the world, that's an increasingly significant problem.

The Dutch government has played an important pioneering role in the adoption of IPv6. In 2010, the Forum for Standardisation, which is an agency of the Ministry of Economic Affairs and the Ministry of the Interior, added IPv6 to the so-called 'use-or-explain' list (Dutch acronym: ptolu). Since then, government organisations have been more or less obliged to implement IPv6 on their infrastructures.

Furthermore, the Forum for Standardisation was behind creation of the Internet.nl portal. Via the portal, users can test connections and domains to see whether they are using six modern internet standards: IPv6, DNSSEC, HTTPS, DMARC, StartTLS and DANE. The test results are delivered in the form of a score, which serves as a quantitative indication of compliance. The site has already been used for hundreds of thousands of tests.

According to RFC 9386, the main drivers of IPv6 adoption are the shortage of IPv4 addresses and pressure from national governments.

Information about server-side IPv6 adoption in the Netherlands is available here.

IPv6 was added to the so-called 'use-or-explain' list (Dutch acronym: ptolu) in 2010 by the Forum for Standardisation, which is an agency of the Ministry of Economic Affairs and the Ministry of the Interior. Since then, public and semi-public organisations have been more or less obliged to implement IPv6 on their infrastructures.

IPv6 was added to the so-called 'use-or-explain' list (Dutch acronym: ptolu) in 2010 by the Forum for Standardisation, which is an agency of the Ministry of Economic Affairs and the Ministry of the Interior. All relevant standards on the 'use-or-explain' list have to be included in tender specifications for government contracts worth more than 50,000 euros, unless there are good reasons for their non-inclusion. Consequently, the implementation of IPv6 is normally an integral feature of public sector IT infrastructure upgrade projects.

Along with the Forum for Standardisation and the Platform for Internet Standards (which took over the old IPv6 Task Force's promotional role in 2018), we are strong supporters of the further rollout of IPv6 in the Netherlands.

For example, in summer 2017, we introduced an incentive scheme, under which registrars get discounts on IPv6-enabled domain name registrations. The scheme was set up to help tip the balance in favour of investment in IPv6.

Following introduction of our discount scheme, the proportion of .nl domains with IPv6-enabled mail servers or web servers (and associated name servers) quickly shot up. However, the rate of adoption has plateaued after a few years [1, 2] and hasn't responded to us increasing the incentive on offer.

In 2019, IPv6 use in the Netherlands received a further boost when we linked up with the Registrars' Association to organise three IPv6 workshops under the banner of the SIDN Academy. Each workshop lasted a full day and provided registrars with an excellent opportunity to hone their IPv6 expertise.

Also in 2019, Logius, VNG Realisatie, various vendors, service providers and other government agencies signed the IPv6 Declaration of Intent. That ultimately led to a Joint Ambition Statement, in which the stakeholders adopted the target of enabling IPv6 support on all government servers by the end of 2021.

In 2022, we launched an entire new area on our website, where all the information and tools we offer to help with the implementation of modern internet standards are conveniently arranged and presented. As well as comprehensive information about DNSSEC, SPF/DKIM/DMARC and DANE the new area features a page all about IPv6, including this FAQ section.

We offer our registrars 2 e-learning modules about IPv6 via the SIDN Academy.

World IPv6 Launch Day was 6 June 2012. That was the day that hundreds of internet companies – including Akamai, Cisco, Facebook, Google, Microsoft, Wikimedia, Yahoo and YouTube – all made some or all of their services available on the IPv6 network by publishing AAAA DNS records.

World IPv6 Launch Day was an initiative by the Internet Society (ISOC). It was preceded by World IPv6 Day (12 January 2011), which served as a (successful) test for Launch Day 18 months later.

IPv6 offers more than enough address space to resolve the address shortage associated with IPv4. IPv6 addresses are 128 bits long, providing scope for 2¹²⁸ = 3.4x10³⁸ (340 undecillion) unique addresses. That's so many – 34 followed by thirty-seven zeros – that it can only be described as an astronomical number.

Consider: the routable part of an IPv6 address is a prefix of thirty-two bits (/32). That is the level of the address blocks delegated to internet access providers and large organisations (LIRs) by their Regional Internet Registries (RIRs). Of the remaining ninety-six bits, an access provider typically uses sixteen to define subnetworks for customers.

Originally, each end user was then given a unique /48 prefix. However, RFC 6177 now suggest a /56 prefix for end users, which they can use to define up to 256 local subnetworks. Within each subnetwork, sixty-four bits remain available for assigning a unique IP address to each system (or, to be precise, each network interface).

Each individual internet user with a /56 prefix (address block) therefore has 2⁷² = 4.7 sextillion addresses available for personal use. In other words, each user's personal address space is 2⁴⁰ = 1.1 trillion times bigger than the space that IPv4 provides for the entire internet (2³²).

As well as providing a vast address space, IPv6 enables the auto-configuration of IPv6 addresses on network interfaces by means of the SLAAC protocol.

IPv6 offers two additional benefits:

• The packet headers are bigger than with IPv4, but their length is fixed and they don't include a checksum.

• Packets are not fragmented in transit. Instead, the sending host has to ensure that the packets are not too big. If a router receives a packet that is too big to be processed, it sends an ICMP(v6) message back to the sender requesting smaller packets. In theory, that allows IPv6 packets to be processed more quickly. However, the practical advantage is negligible because modern routers are all incredibly fast anyway.

Finally, with IPv6, everyone is fully reachable, opening the way for end users to do self-hosting and use peer-to-peer protocols. Perhaps significantly, such developments are at odds with the commercial interests of hosting service providers that sell business hosting packages and expensive conferencing services.

However, the real benefits of IPv6 are only felt if everyone actually starts using the new protocol.

IPv6 doesn't have any inherent drawbacks. It is broadly similar to IPv4, but resolves the significant problems caused by exhaustion of the IPv4 network.

However, we're currently in the midst of transition from IPv4 to IPv6, meaning that things are complicated by the IPv4 workarounds and IPv4-IPv6 transition mechanisms. Once we're through the transitional phase – for which we need everyone to implement and adopt IPv6 as soon as possible – IPv6 will operate in much the same way as the simple IPv4 networks of the past.

As an internet service provider, you're unlikely to notice any change if you implement IPv6 on your system, because in principle IPv6 provides exactly the same network services as IPv4.

However, you might find that your search engine score is improved by the extra reachability associated with IPv6, with the result that your website attracts more visitors.

In principle, IPv6 provides exactly the same network services as IPv4. However, if you enable IPv6, you may notice that certain connection problems occur much less often.

The Internet Protocol has never distinguished between clients and servers. From the start, it was based on the end-to-end principle, which recognises only hosts, all of which are peers. However, the near-universal use of (CG)NAT has fundamentally changed the nature of the internet. Today, the internet is a largely asymmetrical network, on which most end users' systems are no longer reachable directly from the internet. As a result, self-hosting and peer-to-peer protocols are no longer viable or fully functional.

With IPv6, every system is (or can be) assigned a public address. IPv6 therefore re-establishes the end-to-end principle underpinning the Internet Protocol.

IPv6 has now been around for nearly 30 years, but hasn't yet been widely implemented. Despite having significant shortcomings, IPv4 is still used for most internet traffic. That's partly because internet access providers and network operators have adopted various technical workarounds (e.g. dynamic address assignment, NAT, CGNAT and SNI) that enable existing IP addresses to be shared and reused, and partly because IPv6 and IPv4 are mutually incompatible.

Nevertheless, we're now past an important tipping point. Whereas previously people would implement IPv6 as an extension to their IPv4 networks, without any immediate added value, there are now more and more examples of IPv6 being used as the basis of a network, with a transition mechanism to enable IPv4-only connectivity (IPv4 as a Service).

In June 2024, nearly half of Google visits were IPv6-enabled, and the proportion is increasing by about 5 percentage points a year. If you are a private end user who has IPv6 and mainly uses Google, YouTube, Netflix, Facebook Instagram and WhatsApp, more than half of your traffic is probably already IPv6-based.

Figure 1: Global client-side IPv6 use. Source: Google.

Ultimately, IPv6 will completely replace IPv4. Until then, IPv4 and IPv6 can simply be used side-by-side on the same base network. Almost all hardware and software nowadays supports both IPv4 and IPv6. What's more, numerous transition mechanisms are now available to facilitate migration from IPv4 to IPv6.

Historically, the Netherlands has lagged far behind its neighbours and the wider world on client-side IPv6 adoption. In June 2024, roughly a third of Dutch Google visitors made use of IPv6. However, further adoption of IPv6 has almost stopped here. Elsewhere, IPv6 continues its advance, meaning that the Netherlands is falling further and further behind.

Figure 1: Dutch client-side IPv6 use. Source: Google.

Figure 2: Dutch client-side IPv6 use (international). Source: APNIC Labs.

Figure 3: Dutch client-side IPv6 use (Western Europe). Source: APNIC Labs.

Figure 4: Dutch client-side IPv6 use (change over time). Source: APNIC Labs.

For a detailed picture of the situation in the Netherlands, see the report on our major IPv6 survey published in late 2018, and the update report. As well as describing the current position, the reports explain why slow adoption disadvantages the Dutch economy and Dutch internet users, and why migration to IPv6 is an urgent necessity.

Since then, our position has actually got worse: 2 years ago, some important statistics relating to Dutch adoption of IPv6 became unusable, with the result that we lost our overview of IPv6 adoption in the Netherlands. Because reliable quantification of Dutch IPv6 adoption is much more difficult than it used to be, the task of developing policies to encourage further adoption is also more challenging. And legislating to mandate IPv6 support is more daunting still. What's more, any such initiatives would depend on effective means of measuring the effects of the measures taken.

If peak IPv4 is indeed now behind us, the Netherlands looks likely to emerge from the IPv4-to-IPv6 transition well behind many other countries.

In the Netherlands, we lag well behind other countries on the adoption of IPv6. The problem is that most access providers and corporate network operators don't currently offer IPv6 to their customers and users. The good news is that the country's 2 biggest access providers, KPN and Ziggo (part of VodafoneZiggo), have (finally) made considerable progress on IPv6 in recent years.

Figure 1: IPv6 use on the KPN network. Source: APNIC Labs.

Figure 2: IPv6 use on the Vodafone-Libertel network. Source: APNIC Labs.

However, smaller access providers and network operators don't appear to be making any progress with IPv6. While there are exceptions to that general picture -- e.g. Freedom Internet, SURF, the University of Twente, XS4ALL (now part of KPN) and Zeelandnet (part of Delta) -- they tend to be well-established technological innovators who adopted IPv6 long ago. For such players, use of the latest technology is integral to their identity and reputation.

Broadly speaking, therefore, the Netherlands lags well behind other countries on the adoption of IPv6. Because the Netherlands has traditionally been a pioneering country where the internet is concerned, Dutch access and service providers have bigger stocks of IPv4 addresses than their counterparts in many other parts of the world. Consequently, one explanation for the nation's poor performance on IPv6 may be the handicap of a head start.

For a detailed picture of the situation in the Netherlands, see the report on our major IPv6 survey published in late 2018, and the update report. As well as describing the current position, the reports explain why slow adoption disadvantages the Dutch economy and Dutch internet users, and why migration to IPv6 is an urgent necessity.

Since then, our position has actually got worse: 2 years ago, some important statistics relating to Dutch adoption of IPv6 became unusable, with the result that we lost our overview of IPv6 adoption in the Netherlands. Because reliable quantification of Dutch IPv6 adoption is much more difficult than it used to be, the task of developing policies to encourage further adoption is also more challenging. And legislating to mandate IPv6 support is more daunting still. What's more, any such initiatives would depend on effective means of measuring the effects of the measures taken.

If peak IPv4 is indeed now behind us, the Netherlands looks likely to emerge from the IPv4-to-IPv6 transition well behind many other countries.

Information about server-side IPv6 adoption is patchy. However, the major IPv6 survey we published in late 2018 revealed that few domain registrants/registrars had policies on IPv6, and that adoption wasn't progressing well. Levels of adoption also differed greatly from one sector to the next.

The Dutch public sector stands out for its high levels of adoption, reflecting rules that oblige government bodies to support IPv6. The latest report indicates that 80 per cent of government web servers and 46 per cent of mail gateways now support IPv6. However, those numbers remain a long way from the 100 per cent support that the Dutch government said it was aiming for by the end of 2021 (in the Joint Ambition Statement).

Figure 1: IPv6 support by Dutch government websites and mail servers. Source: Forum for Standardisation.

Here at SIDN, we perform monthly scans of all .nl domains in connection with the incentive scheme we run for .nl registrars. The scan results are used to calculate eligibility for incentives to promote the use of IPv6, for example.

Analysis of the scan data confirms the picture of adoption having plateaued. Following introduction of our IPv6 incentive scheme in summer 2017, the proportion of .nl domains with either an IPv6-enabled mail server or an IPv6-enabled web server (and associated name servers) quickly shot up. However, the rate of adoption has plateaued after a few years [1, 2] and hasn't responded to us increasing the incentives on offer.

Note that only about half as many .nl domains have both an IPv6-enabled mail server and an IPv6-enabled web server (and associated name servers): 1.4. million, rather than 2.7 million.

Figure 1: Percentage of .nl domain names with either an IPv6-enabled web server or an IPv6-enabled mail server (and associated name servers). Source: SIDN.

Figure 2: Number of .nl domain names with either an IPv6-enabled web server or an IPv6-enabled mail server (and associated name servers). Source: SIDN.

Figure 3: Number of .nl domains whose name servers, mail servers and web servers are all IPv6-enabled (with breakdown). Source: SIDN.

Broadly speaking, therefore, the Netherlands lags well behind other countries on the adoption of IPv6. Because the Netherlands has traditionally been a pioneering country where the internet is concerned, Dutch access and service providers have bigger stocks of IPv4 addresses than their counterparts in many other parts of the world. Consequently, one explanation for the nation's poor performance on IPv6 may be the handicap of a head start.

In regions that took to the internet much later, the shortage of IPv4 addresses is far greater and more acute. In some countries, for example, IPv4 addresses are reserved for shared hosting and CGNAT gateways. However, our 'IPv4 address wealth' will be of little value when we reach the stage where IPv6-only clients elsewhere cannot reach our IPv4-only servers. Or when our IPv4-only clients cannot reach the first IPv6-only servers elsewhere.

For a detailed picture of the situation in the Netherlands, see the report on our major IPv6 survey published in late 2018, and the update report. As well as describing the current position, the reports explain why slow adoption disadvantages the Dutch economy and Dutch internet users, and why migration to IPv6 is an urgent necessity.

Since then, our position has actually got worse: 2 years ago, some important statistics relating to Dutch adoption of IPv6 became unusable, with the result that we lost our overview of IPv6 adoption in the Netherlands. Because reliable quantification of Dutch IPv6 adoption is much more difficult than it used to be, the task of developing policies to encourage further adoption is also more challenging. And legislating to mandate IPv6 support is more daunting still. What's more, any such initiatives would depend on effective means of measuring the effects of the measures taken.

If peak IPv4 is indeed now behind us, the Netherlands looks likely to emerge from the IPv4-to-IPv6 transition well behind many other countries.

The number of Dutch networks (Autonomous Systems) that advertise IPv6 routes using the Border Gateway Protocol (BGP) grew significantly in the period 2008 to 2014, but has since remained at the same level.

Figure 1: Number of Dutch Autonomous Systems that advertise IPv6 routes. Source: RIPE NCC.

The percentage of resolvers that query .nl domains' name servers over IPv6 remained static at about 20-25 per cent for years, and only made a small jump to 30 per cent about 3 years ago.

Figure 2: Percentage of resolvers using IPv6 to request details of .nl domains' name servers. Source: SIDN Labs.

For a detailed picture of the situation in the Netherlands, see the report on our major IPv6 survey published in late 2018, and the update report. As well as describing the current position, the reports explain why slow adoption disadvantages the Dutch economy and Dutch internet users, and why migration to IPv6 is an urgent necessity.

Since then, our position has actually got worse: 2 years ago, some important statistics relating to Dutch adoption of IPv6 became unusable, with the result that we lost our overview of IPv6 adoption in the Netherlands. Because reliable quantification of Dutch IPv6 adoption is much more difficult than it used to be, the task of developing policies to encourage further adoption is also more challenging. And legislating to mandate IPv6 support is more daunting still. What's more, any such initiatives would depend on effective means of measuring the effects of the measures taken.

If peak IPv4 is indeed now behind us, the Netherlands looks likely to emerge from the IPv4-to-IPv6 transition well behind many other countries.

The Netherlands' sluggish adoption of IPv6 is damaging the Dutch economy. It makes the Netherlands less attractive for new, large-scale mobile applications and for initiatives with the Internet of Things (IoT), as well as tarnishing the country's image as a business-friendly innovation centre.

End users behind (CG)NAT systems cannot run self-hosted applications and experience connection problems with peer-to-peer technology. Finally, the shortage of IPv4 addresses makes it difficult for existing providers to bring new large-scale services to market, and for market entrants to gain a foothold.

The Netherlands' poor performance on IPv6 is inconsistent with the commercial, technical and economic ambitions concerning the modern internet often expressed both by the sector and by the government.

For a detailed picture of the situation in the Netherlands, see the report on our major IPv6 survey published in late 2018, and the update report. As well as describing the current position, the reports explain why slow adoption disadvantages the Dutch economy and Dutch internet users, and why migration to IPv6 is an urgent necessity.

Since then, our position has actually got worse: 2 years ago, some important statistics relating to Dutch adoption of IPv6 became unusable, with the result that we lost our overview of IPv6 adoption in the Netherlands. Because reliable quantification of Dutch IPv6 adoption is much more difficult than it used to be, the task of developing policies to encourage further adoption is also more challenging. And legislating to mandate IPv6 support is more daunting still. What's more, any such initiatives would depend on effective means of measuring the effects of the measures taken.

If peak IPv4 is indeed now behind us, the Netherlands looks likely to emerge from the IPv4-to-IPv6 transition well behind many other countries.

Sources:

• Overview of IPv6 adoption in the Netherlands lost, January 2024

• Further adoption of IPv6 has almost stopped in the Netherlands, September 2021

• Netherlands falls further behind on IPv6, January 2019

• SIDN IPv6 Survey, October 2018

As the adoption of IPv6 progresses, there must come a point where the demand for IPv4 addresses goes into decline and prices follow suit. That tipping point in referred to as 'peak IPv4'.

The expectation is that, once we are past peak IPv4, the market value of IPv4 addresses will go into decline. That will induce major holders to put their unused and newly released IPv4 addresses on the market as soon as they can, increasing supply and amplifying the downward price trend.

It appears that peak IPv4 is indeed now behind us: After years of steady increase, the prices paid for traded address blocks plateaued in the period 2021 to 2022, then fell sharply in 2023. As the following graph shows, the downward trend continued in 2024.

Figure 1: IPv4 address prices. [Source: IPv4.Global]

There are various possible explanations for the downturn in market prices: In recent years, the big cloud operators have bought up huge numbers of IPv4 addresses, so that they can continue offering their customers IPv4 portals for their online services. Since then, the scramble to buy up addresses has abated, and that may be why prices have come down.

However, while the prices paid for larger address blocks (/16 and above) have certainly fallen, prices for smaller blocks have fallen much more sharply. So it doesn't appear that the overall downturn can be attributed to a shift in the trading pattern, away from large deals towards the buying and selling of ever smaller address blocks. We are therefore witnessing a structural decline in the prices paid for IPv4 addresses across the entire spectrum of block sizes.

Figure 2: Prices of IPv4 addresses (address blocks /16 and larger). [Source: IPv4.Global]

Figure 3: Prices of IPv4 addresses (address blocks /17 and smaller). [Source: IPv4.Global]

Falling market prices are by no means the only sign that the IPv4 network has now peaked: The number of IPv4 routes is no longer increasing. The efficiency of IPv4 use has stopped increasing and started to decline. Some access providers are finding that NAT-based expansion of their infrastructures has ceased to be cost-effective.

Sources:

• IPv4 network growth is over; contraction expected

• Are we past peak IPv4?

• Tipping point reached: transition to IPv6 enters a new phase

Now that peak IPv4 has been passed, IPv4 is no longer the 'normal' Internet Protocol, and should be regarded as 'legacy'. So, when computer networks are built or upgraded, IPv6 should serve as the basis, with support for IPv4-only systems realised by means of an overlaid service (IPv4 as a service).

In the IPv6-focused landscape, a new group of IPv4-to-IPv6 transition mechanisms has acquired a central role. As we move towards an IPv6-mainly world, it's time for old mechanisms such as dual stack with NAT and CGNAT to make way for newer alternatives based on NAT64, DNS64 and 464XLAT.

However, it should be noted that the approach described typically works only for access networks. On the backbone, you simply switch from IPv4-only to IPv6-only. In a data centre, you don't want the complexity of multiple transition mechanisms and other workarounds. What's more, the biggest online service providers, such as Microsoft, Facebook and LinkedIn (the 'hyperscalers'), adopted IPv6-only strategies for their internal networks some years ago. Where possible, they have also sought to translate that into an IPv6-first proposition [Amazon].

Sources:

• IPv4 network growth is over; contraction expected

• Are we past peak IPv4?

• Tipping point reached: transition to IPv6 enters a new phase

It may very well be the case that we passed peak IPv4 in 2023, and that contraction of the IPv4 network is now in prospect. Indeed, contraction could begin as soon as 2026, according to an analysis by Geoff Huston, Chief Scientist at APNIC. Projections made with outliers removed from the statistics suggest that it might be a few years further away. However, regardless of when it starts, negative growth is inevitable in the years ahead. And, once the tide turns, Huston expects the market for IPv4 addresses to collapse very quickly. [1, 2]

Figure 1: A quadratic polynomial equation provides the best model of the IPv4 routing table; it predicts a switch to contraction in the coming years. [Source: Geoff Huston]

The worrying aspect of Huston's latest surveys is his ultimate conclusion that, although the IPv4 network still functions in its current form, it's holding back innovation, openness and diversification on the internet. Large scale use of NAT means that now only client-server connections initiated by the client over TCP and UDP are possible. Applications that aren't consistent with that architecture – such as multi-user games and real-time peer-to-peer applications (internet/video telephony) – don't (or no longer) work properly. Although most end users aren't inconvenienced, the self-hosting of servers is now possible only in exceptional cases where an access provider assigns a true (static) IPv4 address to each customer [e.g. Freedom Internet].

As a result, the market has concentrated around a small number of very big infrastructure and content providers, who are inherently risk-averse, conservative and controlling. We also run the risk that the existing internet will disintegrate into a number of separate parts, or 'service cones', each with its own private address space, formed around CDN points-of-presence (PoPs). What's more, it's only a matter of time before the first IPv6-only services are launched, probably in regions such as Asia or South America. Servers on those networks will be unreachable for IPv4-only clients.

All things considered, it seems that innovation and enterprise on the existing internet infrastructure have stalled. And Huston doesn't expect them to recover momentum until the IPv4-to-IPv6 transition is complete. The central conclusion, therefore, is that we need to transition to IPv6 as soon as possible.

Sources:

• IPv4 network growth is over; contraction expected

• Are we past peak IPv4?

• Tipping point reached: transition to IPv6 enters a new phase

At the moment, the Netherlands is not in a position to take full advantage of an IPv6-based internet. Indeed, we are failing to translate our strong position in the provision of (IPv4-based) internet services and infrastructure into a similarly strong position on the IPv6-based network.

Because the Netherlands has traditionally been a pioneering country where the internet is concerned, Dutch access providers and service providers have bigger stocks of IPv4 addresses than their counterparts in many other parts of the world. Consequently, one explanation for the nation's poor performance on IPv6 may be the handicap of a head start.

However, the Netherlands' sluggish adoption of IPv6 is damaging the Dutch economy. It makes the Netherlands less attractive for initiatives with the Internet of Things (IoT) and tarnishes the country's image as a business-friendly innovation centre.

Unfortunately, it appears that the Netherlands' position is actually getting worse: 2 years ago, some important statistics relating to Dutch adoption of IPv6 became unusable, with the result that we lost our overview of IPv6 adoption in the Netherlands. Because reliable quantification of Dutch IPv6 adoption is much more difficult than it used to be, the task of developing policies to encourage further adoption is also more challenging. And legislating to mandate IPv6 support is more daunting still. What's more, any such initiatives would depend on effective means of measuring the effects of the measures taken.

If peak IPv4 is indeed now behind us, the Netherlands looks likely to emerge from the IPv4-to-IPv6 transition well behind many other countries.

Sources:

• IPv4 network growth is over; contraction expected

• Are we past peak IPv4?

• Tipping point reached: transition to IPv6 enters a new phase

• Overview of IPv6 adoption in the Netherlands lost

Although the implementation of IPv6 involves an investment with no direct commercial return, IPv6 does deliver significant benefits and opportunities sufficient to support a sound business case. In contrast to IPv4 and the associated workarounds, which are now exhausted technologies, IPv6 opens the way for completely new internet applications because it has a vast address space (meaning that growth is not constrained by address availability) and enables direct contact with end users (symmetrical internet).

Indeed, IPv4 is a dead-end street. Consequently, all investments in internet-dependent innovations should be based on IPv6. In recent years, we have seen the first IPv6-only-based business models and services emerge, implying that doing nothing also involves risk. Because IPv6 is the Internet Protocol for the near future, investments in IPv6-only are inherently future-proof.

IPv6 adoption enables access providers and network operators to profile themselves as supporting modern internet standards. The advantage for customers and end users is full reachability, reviving possibilities such as self-hosting and peer-to-peer applications.

Furthermore, IPv4 addresses are now so expensive that investment in IPv6 offers the prospect of compensatory cost savings. As this case study explains, Australian telecoms service provider Telstra switched its mobile users to IPv6-only in order to avoid the high cost of acquiring new IPv4 address blocks.

Adoption of IPv6 can also reduce expenditure on anti-abuse activities. A hacked IPv4 server will immediately start scanning the internet for vulnerable ports, requiring manual intervention. With IPv6, however, the address space is so big that range scanning is very inefficient: "IPv6-only servers have the big advantage of being quiet." [PCextreme].

Finally, .nl registrars that support IPv6 qualify for a registration fee rebate under SIDN's incentive scheme, which was set up to help tip the balance in favour of investment in IPv6.

Absolutely! The following case studies describe new IPv6-only propositions from hosting firms and other service providers:

• Amazon: virtual IPv6-only networks and Virtual Private Servers

• TransIP: IPv6-only Virtual Private Servers

• Ungleich: IPv6-only hosting based on virtual machines, jump hosts and proxies

• PCextreme: IPv6-only infrastructure, IPv6-only virtual servers

On the contrary, IPv6 is a well thought-out, future-proof and badly needed protocol that is now very much on the up.

Certainly. In June 2024, nearly half of Google visits were IPv6-enabled, and the proportion is increasing by about 5 percentage points a year.

Absolutely. IPv6 is vital and needed urgently.

Although we hear it less often nowadays, IPv6 sometimes used to be described as a solution to a non-existent problem. People would say things like "we've been hearing for years that the IPv4 addresses had run out" and "(CG)NAT is a good solution that can keep us going for a long time yet".

The widespread adoption of IPv6 has indeed taken much longer than we originally expected. The exhausted IPv4 network has been kept going by the development of a series of makeshift solutions. However, those workarounds cause technical problems, extra complexity and associated maintenance burdens and costs.

In other words, IPv6 is badly needed, and it's a good thing that its widespread adoption is finally gathering momentum. That development is particularly good for the Netherlands, which has lagged well behind its neighbours and the wider world on IPv6 adoption.

The IPv6 protocol itself is not fundamentally more complicated than the IPv4 protocol. In fact, IPv6's auto-configuration feature makes life easier for network operators. However, the IPv6 protocol is significantly more extensive than IPv4.

Existing IP networks are made complex by the series of complicated workarounds developed over time to keep the exhausted IPv4 network going a little longer. The transition mechanisms needed during the period of transition from IPv4 to IPv6 are also a complicating factor.

Once we reach a situation where the world is IPv6-only (or IPv6-mainly), we will have a future-proof infrastructure that is far less complex than the current IPv4-network with all its workarounds, limitations and IPv4-IPv6 transition mechanisms.

On the contrary, IPv6's auto-configuration feature makes life easier for network operators. The more progress we make towards phasing out the existing IPv4 networks with all their workarounds and IPv4-IPv6 transition mechanisms, the less labour-intensive management of the new IP(v6) networks will become.

On the contrary, IPv6 is proven, robust technology that, as of June 2024, was used by nearly half of Google visitors. Consequently, investment in and migration to IPv6 involve no technological risk.

Absolutely. IPv6 is supported by all the main network hardware, operating systems, and network management software and tools. Interoperability is no longer a problem at all. Also, IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Definitely. The fact that any system behind a (CG)NAT gateway isn't directly accessible from the internet creates serious problems. For example, it makes self-hosting impossible and prevents peer-to-peer protocols working properly.

Although IPv6 isn't necessarily privacy-unfriendly, it does raise certain privacy concerns. The SLAAC protocol for the auto-configuration of IPv6 addresses uses the more-or-less unique MAC address of the relevant network interface to generate the interface identifier (the last sixty-four bits) of a unicast address. Because the identifier is always generated the same way, regardless of the network prefix, the addresses could be used to monitor the online behaviour of users and the locations of mobile devices.

The Privacy Extensions for SLAAC address that problem by, for example, the use of temporary (random) addresses generated on a daily basis.

Investigative agencies and access providers have repeatedly drawn attention to the fact that CGNAT in particular can frustrate the identification of online criminals. The reason being that the IPv4 address of a CGNAT gateway has numerous users, whose identity can be determined only by precisely correlating the address-port assignments in the various NAT layers over time.

By contrast, an IPv6 address has only one end user. Various investigative agencies have therefore expressed a strong desire to see IPv6 introduced as soon as possible.

End users who wish to protect their privacy will need to use a VPN service or some other privacy-enhancing technology (PET).

The privacy aspects of IPv6 are considered more closely in this article.

IPv6 is not a threat to security, but security does need to be reviewed when adopting IPv6. NAT(44) is often (incorrectly) viewed as a firewall, because systems behind the gateway can't be addressed directly from the internet without explicit port forwarding. However, NAT isn't a firewall; it's merely an almost universally used workaround for the problems associated with IPv4 , which has the unwanted side-effect of making systems behind the gateway inaccessible.

All generic IPv6 addresses are in principle routed (except for link-local and ULA addresses). That is not the case with addresses in private IPv4 blocks behind NAT gateways, which many present-day networks have. Consequently, the adoption of IPv6 does require a review of security provisions such as firewalls, screening routers, demilitarized zones (DMZs) and proxies.

Another point is that the IPv6 address space is so vast that it's impractical to block individual addresses on the basis of their prefixes to combat abuse (blacklisting/whitelisting). Consequently, filtering has to be based more on domain name reputation.

It's worth noting that a similar situation exists where IPv4 in combination with CGNAT is concerned: blocking a single IPv4 address can affect a large group of predominantly legitimate users. Also, when multiple services are sharing a single IPv4 address (e.g. by means of SNI), if the shared host comes under attack, it's not immediately apparent which service has been targeted.

The operational security aspects of IPv6 are discussed in this article.

A dual-stack set-up does involve more time input and expense than a single stack, because an additional IP(v6) network has to be rolled out and operated alongside the existing IP(v4) network. However, IPv6 is supported by all the main network hardware, operating systems, and network management software and tools. So it is mainly configuration and management that account for the additional workload.

Access providers that offer their customers public IPv4 addresses face the cost of buying or leasing additional IPv4 address blocks in order to grow. Their business models therefore need to provide for recovery of the associated costs.

However, the world is currently transitioning from IPv4 to IPv6, meaning that sooner or later the implementation of an IPv4-IPv6 transition mechanism will be unavoidable. In that context, it's important to recognise that we're now past an important tipping point. Whereas previously people would implement IPv6 as an extension to their IPv4 networks, without any immediate added value, it's now increasingly common for IPv6 to form the basis of a network, with a transition mechanism to enable IPv4-only connectivity (IPv4 as a service). This article describes a number of current transition mechanisms and considerations for various situations: dual-stack, NAT and CGNAT versus 464XLAT versus DS-Lite. The case studies listed here also include information that can be useful when devising a strategy, developing a roadmap and selecting a transition mechanism.

Choosing a transition mechanism for the access network is now much simpler than it was. For security reasons, the NSA advises against using protocols that rely on tunnelling and translation, except for NAT64/DNS64 and 464XLAT in IPv6-only networks.

What's more, it appears that peak IPv4 is now behind us. Consequently, a new group of transition mechanisms has acquired a central role. As we move towards an IPv6-mainly world, it's time for old mechanisms such as dual stack with NAT and CGNAT to make way for newer alternatives based on NAT64, DNS64 and 464XLAT.

IPv6 doesn't affect the IPv4 address shortage itself, but provides so much scope for creating new IP addresses – the number 34 followed by thirty-seven zeros – that, with IPv6, everything and everyone can have as many addresses as they like. However, that does require everyone switching to IPv6.

Many IPv4-to-IPv6 transition mechanisms make it possible to reuse IPv4 addresses currently in use, so that services and users can be connected to the existing IPv4 network. Consequently, like IPv4 problem workarounds, such mechanisms extend the life of the IPv4 network.

Down the years, a wide range of studies have compared the speeds of IPv4 and IPv6. However, no clear winner has emerged: in some studies IPv6 was faster, in others IPv4.

In theory, IPv6 should be slightly faster than IPv4, since it features certain optimisations to the packet headers, enabling IPv6 packets to be routed more quickly. What's more, (native) IPv6 connections don't require in-transit address translation of the kind needed with any IPv4 connection that involves (CG)NAT.

On the other hand, IPv6 support was added to network equipment later. That could mean that some ASIC hardware's IPv6 support isn't realised in an ideal way, and that router enhancements might tip the balance in favour of IPv4.

In short, using IPv6 generally makes no difference to communication speeds. Far and away the biggest argument for using IPv6 is its vast address space.

IPv6 addresses are 128 bits (= sixteen bytes) long. The notation is a series of eight hexadecimal numbers (each consisting of up to four hexadecimal digits), each separated from the next by a colon: ':'.

IPv6 addresses are 128 bits (= sixteen bytes) long. The notation is a series of eight hexadecimal numbers (each consisting of up to four hexadecimal digits). All letters must be lower case. Each of the eight hexadecimal numbers is separated from the next by a colon: ':'. One or more successive numbers may be omitted if their value is zero, so that two colons appear in succession: '::'. However, a double colon is allowed only once within a given address. For example:

2001:db8::abad:cafe:8765:4321

IPv6 address notation is defined in RFC 5952.

Note that the literal notation of an IPv6 address is problematic if included in a URL in combination with a port number, because port numbers have traditionally used colons as separators. In URLs and other identifiers, IPv6 literals are therefore always enclosed in square brackets:

https://[2001:db8::abad:cafe:8765:4321]:443/

IPv6 distinguishes three types of address:

• Unicast: addresses for one-to-one connections between hosts (more generally known as network interfaces). The scope of these addresses (as defined in RFC 4007) can be global or local. Generally speaking, the length of the prefix (the routing element of the address) is free (as in classless inter-domain routing (CIDR) in the IPv4 address space), although the division between prefix and interface identifier is usually 64/64 bits.

• Anycast: addresses for groups of hosts (more generally known as network interfaces), one of which (the closest in network-technical terms) is selected by a router. These addresses are exactly the same as unicast addresses and part of the same address space. The only difference is how the packets are routed. Although there is no fundamental reason why an anycast group shouldn't be globally distributed, that would require specific routing information (a host route) to be stored on all routers. In practice, therefore, anycast groups are confined to topological regions and have the longest possible shared prefix.

• Multicast: addresses for groups of hosts (more generally known as network interfaces) that can all be approached simultaneously. The scope of these addresses varies from local to global. Certain (permanent) groups are pre-defined for particular systems, such as all connected nodes, routers, and NTP, mDNSv6 and DHCPv6 servers.

The various types of IPv6 address are recognisable (i.e. distinguishable from each other) by looking at their most significant bits:

Details for each of the various types of IPv6 address are given in RFC 4291.

The structure of each type of address is explained below.

A generic unicast address is a global address that designates a system (i.e. a network interface). In other words, they are the unique addresses we normally use for hosts and servers on the internet. Each address consists of a 64-bit network prefix (for routing packets), followed by a 64-bit network interface identifier (for identifying a system (interface) on the relevant (sub)network).

The network prefix is subdivided into a routing prefix of forty-eight bits or more (for routing packets to the relevant network, e.g. a site network), followed by a subnet identifier of sixteen bits or less (for routing packets internally to various subnetworks within the relevant (branch) network).

The network interface identifier is usually:

• derived from the MAC address of the relevant interface (in Modified EUI-64 format, according to RFC 2464);

• assigned using DHCPv6;

• assigned randomly (using the Privacy Extensions for SLAAC, as defined in RFC 8981);

• or assigned manually.

The maximum length of a network prefix is sixty-four bits; shorter prefixes are allowed (as discussed in RFC 7421). The value of the interface identifier no longer has any special significance once generated (as discussed in RFC 7136). All 128 bits of the destination address are always available for routing IPv6 packets.

All global unicast addresses that start with anything other than three 'zero' bits (0b000...) have a 64-bit network prefix followed by an interface identifier in Modified EUI-64 format. Addresses that do start with three 'zero' bits (e.g. IPv4-mapped IPv6 addresses) may differ. Details of Modified EUI-64 format are given in RFC 4291, section 2.5.1.

The unicast address format is defined in RFC 4291, section 2.5.

An anycast address is a global address that designates one system within a group of systems (i.e. network interfaces) that share an IP address. In other words: anycast addresses are unique addresses that, like unicast addresses, are normally used for hosts or servers on the internet. They are therefore identical to unicast addresses and form part of the same address space.

The anycast address format is defined in RFC 4291, section 2.6.

A multicast address is an address that simultaneously designates multiple systems in a group that share an IP address. The value of the first byte of a multicast address is always 0xff. The least significant four bits of the second byte indicate the scope of the address, which can vary from local to global (as defined in RFC 7346 and by IANA). The most significant four bits contain three flags for specific type designations and functions (detailed in RFCs 3306 and 3956). For details, see RFC 4291, section 2.7, and RFC 4489). The remaining fourteen bytes contain the unique multicast group ID, the content of which is specified in more detail in RFCs 3306 and 7371.

The multicast address format is defined in RFC 4291, section 2.7.

Certain (permanent) multicast groups (identified by T flags with a value of zero) are pre-defined for particular systems (with particular scopes), such as all connected nodes, routers, and NTP, mDNSv6 and DHCPv6 servers. The list of groups/addresses in question is maintained by IANA:

https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

Solicited-node multicast addresses are used by the Neighbor Discovery Protocol (NDP) to ascertain whether an interface identifier is already in use on a network segment (by means of the Duplicate Address Detection (DAD) procedure). Each such address consists of the ff02::1:ff00:0/108 prefix, followed by the final twenty-four bits of the unicast/anycast address (the least significant bits of the interface identifier).

The address format is defined in RFC 4291, section 2.7.1.

Specific IPv6 addresses are addresses and segments of the IPv6 address space reserved for specific purposes/functions. Detailed definitions of most of the address formats in question are given in RFC 4291, section 2.5.

Note that specific addresses are not the same as reserved reserved Pv6 address blocks, whose use is simply prohibited.

A comprehensive list of special IPv6 addresses is managed by IANA. See:

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

The format of the (unicast) loopback address is 0:0:0:0:0:0:0:1 or ::1 (localhost).

The scope of this address is link-local, and it refers to the node itself (via the virtual loopback interface). The address must never be assigned to a physical network interface, therefore.

The format of the unspecified address is 0:0:0:0:0:0:0:0 or ::.

This address is not a real address: it is used only when no IPv6 address is known or required. The address must never be assigned to a node or a network interface, therefore.

For routing, the format of the https://en.wikipedia.org/wiki/Default_routedefault route is ::/0.

IPv4-compatible IPv6 addresses consist of ninety-six 'zero' bits, followed by an embedded IPv4 address in the final thirty-two bits: ::<IPv4 address>/96.

The IPv4 address in question must be global and unique (in other words, it must designate a host or server on the internet).

IPv4-compatible IPv6 addresses were intended simply to enable IPv4 addresses to be recorded in a data structure designed for IPv6 addresses during transition from IPv4 to IPv6. They are no longer used.

IPv4-mapped IPv6 addresses consist of eighty 'zero' bits and sixteen 'one' bits, followed by an embedded IPv4 address in the final thirty-two bits: ::ffff:<IPv4 address>.

The illustrated format maps the entire IPv4 address space within the IPv6 address space. This form of mapping is intended to keep the complexity of dual-stack implementations out of IP-version-independent network applications during the transition from IPv4 to IPv6. It means that, internally, such applications only require the implementation of IPv6. For details, see RFC 4038, section 4.2.

The address selection algorithms for IP-version-dependent network applications are described in RFC 3484.

Link-local unicast addresses consist of 0b1111111010 (ten bits) and fifty-four 'zero' bits, followed by a 64-bit interface identifier in Modified EUI-64 format: fe80::<interface ID>.

Link-local unicast addresses are valid only on a local network segment and must never be routed, therefore. They are usually automatically assigned to network interfaces and can be used only for connections with local systems on the same segment.

Site-local unicast addresses consist of 0b1111111011 (ten bits), followed by a 54-bit subnetwork identifier and a 64-bit interface identifier in Modified EUI-64 format: fec0::/10<subnet ID>:<interface ID>.

Site-local unicast addresses are valid only on a local network (e.g. on a particular site) and must never be routed to or from the outside world, therefore. The status of the site-local format is now 'deprecated' (as per RFC 3879) and has been succeeded by the ULA series.

All unique local unicast addresses (ULAs) start with the prefix fc00::/7. That prefix is followed by a 'one' bit (the 'locally assigned' flag) and a forty-bit (pseudo-random) global identifier. The result is a 48-bit prefix that is 'statistically unique' to the organisation: fd00:<global ID><subnet ID><interface ID>.

Unique local unicast addresses are freely available for internal use within an organisation (like 'private network' address blocks in IPv4). They are valid only within an organisation and must never be routed to or from the outside world, therefore.

The random identifier has two advantages. First, it prevents address space conflicts when organisations and their networks merge or when different virtual private networks (VPNs) are connected. Second, it ensures that accidental leakage of local addresses to the internet is not disastrous.

The address format is defined in RFC 4193.

Subnet-router anycast addresses consist of a complete subnet prefix, followed by an interface identifier made up entirely of zeros: <subnet prefix>::.

Subnet-router anycast addresses have a local scope and address one of the routers in the relevant network segment.

The address format is defined in RFC 4291, section 2.6.1.

IPv6 addresses for 6to4 consist of the prefix 2002::/16, followed by a 32-bit embedded IPv4 address: 2002:<IPv4 address>::/48.

The result is a 48-bit prefix that can be used in combination with a sixteen-bit subnet identifier and a 64-bit interface identifier for internal IPv6 traffic, possibly linked over IPv4 by means of 6in4 tunnelling.

The drawback of the 6to4 protocol is that it works only for clients with public IPv4 addresses, and not for IPv4 clients behind NATgateways. This transition mechanism is considered in more detail here.

The address format is defined in RFC 3056.

IPv6 addresses for Teredo tunnelling consist of the prefix 2001:0000:/32, followed by the 32-bit embedded IPv4 address of the IPv4 Teredo server, followed by a number of flags (sixteen bits), the UDP port of the client (sixteen bits) and the IPv4 address of the client (thirty-two bits): 2001:0000:<IPv4 address of Teredo server>:flags>:<UDP port of Teredo client>:<IPv4 address of Teredo client>.

Teredo is an IPv6-over-IPv4 tunnelling protocol designed by Microsoft. The advantage of the Teredo-protocol is that it works for IPv4 clients behind NAT gateways, unlike the 6to4 tunnelling protocol, which works only for clients with public IPv4 addresses.

Teredo is now outdated and should no longer be used for new implementations.

The address format is defined in RFC 4380.

IPv4-translated IPv6 addresses consist of sixty-four 'zero' bits, sixteen 'one' bits and sixteen 'zero' bits, followed by an embedded IPv4 address in the final thirty-two bits: ::ffff:0:<IPv4 address>.

IPv4-translated IPv6 addresses used to be reserved for the very first version of stateless IPv4–IPv6 translation (SIIT), but are no longer in use.

The address format is defined in RFC 2765.

IPv6 addresses for IPv4-IPv6 translation consist of the prefix 64:ff9b::/64, followed by an embedded IPv4 address in the final thirty-two bits: 64:ff9b::<IPv4 address>/96.

As an alternative to that well-known address block, an address format can be used with a variable-length optional postfix of zero, twenty-four, thirty-two, forty, forty-eight or fifty-six bits. With the alternative format, the prefix varies from thirty-two to ninety-six bits, within which the eight bits starting from position 64 always have the value 0b00000000: <prefix>::<IPv4 address with the value 0x00 inserted at position 64><suffix>.

The prefix 64:ff9b::/96 may be used only in the basic form (without the suffix). Otherwise one of the organisation's own prefixes must be used. The suffix itself is reserved for future applications. In the meantime, its value has to be zero.

Addresses of this type are used by NAT64/DNS64-transition mechanisms.

The address format is defined in RFC 6052.

A few years ago, the wider prefix 64:ff9b:1::/48 was also made available for IPv4-IPv6 translation to facilitate the use of various/multiple transition mechanisms in parallel.

The address format is defined in RFC 8215.

IPv6 discard addresses (for routing) all start with the prefix 0100::/64.

Any packet addressed to a discard address must be removed from the main traffic flow by a receiving router.

The discard address block is used in dynamic filters and routing tables as a 'black hole' or sinkhole (with logging/stats functionality) in order to defend against denial-of-service (DoS) attacks.

The address format is defined in RFC 6666.

Het kan voorkomen dat een niet-globaal IPv6-adres tegelijkertijd gebruikt wordt in verschillende zones van een systeem; dat gebeurt dan meestal bij Link-Local adressen. Hoewel dit verwarrend kan zijn, voldoet een dergelijke configuratie aan de eisen: elk van de 'identieke' adressen is immers alleen geldig binnen zijn eigen lokale zone.

Om binnen een systeem toch onderscheid te kunnen maken tussen deze adressen – bijvoorbeeld bij het selecteren van een interface voor uitgaand verkeer – krijgen ze een zone-index mee:

• voor Unix-achtigen is dat een procentteken gevolgd door de interfacenaam: fe80::dead:beef:1234:5678%eth0

• voor Windows-systemen is dat een procentteken gevolgd door het interfacenummer: fe80::dead:beef:1234:5678%2

De details over zone-indexen vind je in sectie 6 van RFC 4007.

Reserved IPv6 address blocks are blocks within the IPv6 address space whose use is prohibited.

Note that reserved addresses are not the same as specific addresses and segments, which are reserved for particular purposes/functions.

A comprehensive list of special IPv6 addresses is managed by IANA. See:

• https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

All IANA-delegated unicast address blocks (prefixes) are recorded in the following list:

• https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

The IPv6 addresses for applications of ORCHIDv2 (Overlay Routable Cryptographic Hash Identifiers) all start with the prefix 2001:20::/28.

The address block with that prefix is reserved for use by ORCHIDv2 applications, with IPv6-format endpoint identifiers used merely to identify hosts (on the basis of public keys), rather than to simultaneously identify and localise them (as the IPv6 routing tables do).

The reason for using an IPv6-like format is to facilitate use by applications and APIs designed to work with IPv6 addresses. Routing takes place on a separate overlay layer (between the application/API and the IP network). One example of such an application is the Host Identity Protocol (HIP).

The block reserved for ORCHIDv2 applications forms a distinct namespace, separate from the IPv6 network. In order to prevent confusion between the two namespaces, the reserved addresses have their own prefix, and any address with that prefix cannot be routed on the internet.

The address block is defined in RFC 7343.

The IPv6 addresses reserved for benchmarking all start with the prefix 2001:2::/48.

The address block is defined in RFC 5180.

The IPv6 addresses reserved for documentation all start with the prefix 2001:db8::/32.

The block of addresses with that prefix is reserved for use in documentation, examples and source code. The addresses are never routed.

The address block is defined in RFC 3849.

Each IPv6 host has the loopback (unicast) address ::1.

Each individual IPv6 network interface has a link-local unicast address (starting with fe80::, followed by a locally unique 64-bit interface identifier).

In addition, globally unique unicast addresses are automatically or manually assigned to all public network interfaces (depending on the operating system).

Anycast and multicast addresses are assigned by network operators.

RFC 7934 recommends that an interface has distinct IPv6 addresses for distinct functions (applications) on a given system.

IPv6 addresses are assigned to network interfaces in various ways, which are considered separately below:

• Using SLAAC

• Using Privacy Extensions for SLAAC

• DHCPv6

• Manually

The principal requirement for an interface identifier is that it must be unique in combination with the subnet identifier.

IPv6 is designed so that within-scope assignment of unique addresses to interfaces takes place automatically as far as possible.

SLAAC (Stateless Address Autoconfiguration) is the protocol for the auto-configuration of IPv6 addresses. It is used mainly for the interface identifiers of link-local unicast addresses (starting with fe80::) and unicast addresses that are unique within their scope.

Interface identifiers have traditionally been derived from the MAC address of the relevant interface (in Modified EUI-64 format). The uniqueness of each identifier is checked by following the Duplicate Address Detection (DAD) procedure (part of the Neighbor Discovery Protocol, NDP).

Finally, the interface identifiers are combined with the network prefixes to form unique unicast addresses.

The method allows the rapid, convenient automatic assignment of IPv6 addresses that are both unique and routable, where it doesn't matter exactly what addresses a host uses.

SLAAC is defined in RFC 4862.

Interface identifiers have traditionally been derived from the MAC address of the relevant interface (in Modified EUI-64 format). The uniqueness of each identifier is checked by following the Duplicate Address Detection (DAD) procedure (part of the Neighbor Discovery Protocol, NDP).

The procedure involves the node sending a Neighbor Solicitation message to the local multicast address of the IPv6 address that the node is 'tentatively' seeking to use. If the node gets one or more Neighbor Solicitation messages or Neighbor Advertisement messages from other nodes in response, the first node cannot use the tentative IPv6 address. An alternative address is generated and the check repeated.

The DAD procedure (which is used not only for SLAAC, but also for other forms of address assignment) is defined in RFC 4862, section 5.4.

The Neighbor Discovery Protocol (NDP) is a link-layer protocol (i.e. a multicast protocol) for IPv6. It is used in the DAD procedure to check the uniqueness of interface identifiers.

NDP is defined in RFC 4861.

IPv6 is designed so that, within their scope, the assignment of unique addresses to interfaces is performed automatically as far as possible.

SLAAC (Stateless Address Autoconfiguration) is the protocol for the auto-configuration of IPv6 addresses. It is used mainly for the interface identifiers of link-local unicast addresses (starting with fe80::) and unicast addresses that are unique within their scope.

Network prefixes are periodically published by the routers on the relevant network segment (by means of a Router Advertisement). Associated sub-prefixes can then be used by routers lower in the hierarchy for further distribution/assignment. The issue of sub-prefixes to subnetworks can be automated by means of DHCPv6-PD (prefix delegation) in accordance with RFC 3633 (typically by an access provider for CPEs).

Interface identifiers have traditionally been derived from the MAC address of the relevant interface (in Modified EUI-64 format). The uniqueness of each identifier is checked by following the Duplicate Address Detection (DAD) procedure (part of the Neighbor Discovery Protocol, NDP).

Finally, the interface identifiers are combined with the network prefixes to form unique unicast addresses.

With SLAAC, interface identifiers are derived directly from the more-or-less unique MAC addresses of the relevant interfaces. Consequently, the addresses can be used to monitor the online behaviour of users and the locations of mobile devices, since the identifiers remain the same, even if the network prefix changes.

The Privacy Extensions address that problem by, for example, the use of temporary (random) addresses generated on a daily basis. In that scenario, previously generated temporary addresses remain valid for inbound traffic for a further day. So the status of a temporary address goes from 'preferred' to 'deprecated', and ultimately to 'invalid'.

Note that, by using Privacy Extensions for example, interfaces can simultaneously have multiple IPv6 addresses with the same prefix.

In any case, RFC 7934 recommends that an interface has distinct IPv6 addresses for distinct functions (applications) on a given system.

The Privacy Extensions for SLAAC are defined in RFC 8981.

An alternative approach is put forward in RFC 7217, involving the generation and maintenance of a random interface identifier for each interface and subnet. So the IPv6 addresses remain constant for each network (prefix), but they can't be associated with one another on the basis of their interface identifiers.

RFC 8064 now advises against using hardware-dependent SLAAC addresses, in favour of using IPv6 addresses generated in accordance with RFC 7217 instead.

The security and privacy considerations associated with address assignment are considered in RFC 7721.

Network prefixes are periodically published by the routers on the relevant network segment (by means of a Router Advertisement). Associated sub-prefixes can then be used by routers lower in the hierarchy for further distribution/assignment. The issue of sub-prefixes to subnetworks can be automated by means of DHCPv6-PD (prefix delegation) in accordance with RFC 3633 (typically by an access provider for CPEs).

DHCPv6 is the IPv6 equivalent of DHCP for IPv4. The protocol provides more control over the IPv6 addresses in use than SLAAC. It is also useful for assigning additional IPv6 addresses to systems, typically using an IP Address Management (IPAM) solution.

DHCPv6 is also used to propagate various network and application parameters, e.g. for IPv4-IPv6 transition mechanisms.

The DAD procedure described above is also followed for addresses assigned by means of DHCPv6.

DHCPv6 is defined in RFC 8415.

With IPv6's automatic address assignment functionality, DHCPv6 is no longer really needed. Nor is the configuration of DNS resolvers: like the prefixes, the information can be propagated by the routers by means of NDP (as defined in RFC 8106).

However, DHCPv6 is also used to propagate various network and application parameters, e.g. for IPv4-IPv6 transition mechanisms.

Be on the alert for illegal DHCPv6 servers set up to distribute fake IP addresses.

RFC 8273 includes an address scheme where each end user is assigned a unique prefix, so that they can communicate with each other only via a router.

Like IPv4 addresses, IPv6 addresses can be assigned to network interfaces manually.

The DAD procedure is followed for manually assigned addresses as well.

Nevertheless, we advise against the manual assignment of generic link-local and global unicast addresses. IPv6 is designed so that the assignment of addresses to interfaces takes place automatically as far as possible. That makes it relatively easy to renumber an entire network (as discussed in RFC 7010), for example, since only the advertised prefixes need to be changed.

ICMPv6 is the IPv6 equivalent of ICMP for IPv4. The protocol is an integral component of IPv6, serving diagnostic and error-reporting functions.

For example, the Neighbor Discovery Protocol (NDP) uses ICMPv6 messages to communicate routes, prefixes and parameters. Also, if a router receives a packet that is too big to be processed, it sends an ICMPv6 message back to the sender requesting smaller packets.

In the DNS, IPv6 address assignment is performed in exactly the same way as IPv4 address assignment, but using the specially defined AAAA record.

In a dual-stack environment, therefore, the zone includes both an A record and an AAAA record for each host name:

www.example.nl IN A 192.0.2.3 IN AAAA 2001:db8::baad:b002:2:3

This DNS extension for IPv6 is defined in RFC 3596.

Reverse DNS lookup is specified in much the same way for IPv6 as for IPv4. However, because IPv6 addresses are longer, close attention is required: the order of the individual hexadecimal digits (nibbles) within the IPv6 address is reversed, and the digits are separated from each other by dots'.', followed by the 'ip6.arpa.' suffix.

So the reverse of the address 2001:db8::d06:f00d:567:89ab is:

b.a.9.8.7.6.5.0.d.0.0.f.6.0.d.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Note that the suffix must be 'ip6.arpa.', and that use of the old 'ip6.int.' suffix is no longer permitted (as stated in RFC 4159).

This DNS extension for IPv6 is defined in RFC 3596.

The Internet Protocol has never distinguished between clients and servers. From the start, it has recognised only hosts, all of which are peers. However, the near-universal use of (CG)NAT has fundamentally changed the nature of the internet. Today, the internet is a largely asymmetrical network, on which most end users' systems are no longer reachable directly from the internet. As a result, self-hosting and peer-to-peer protocols are no longer viable or fully functional.

With IPv6, every system is (or can be) assigned a public address. IPv6 therefore re-establishes the end-to-end principle underpinning the Internet Protocol.

The implications for the security of IPv6 networks are considered below.

NAT(44) is often (incorrectly) viewed as a firewall, because systems behind the gateway can't be addressed directly from the internet without explicit port forwarding. However, NAT isn't a firewall; it's merely an almost universally used workaround for the problems associated with IPv4, which has the unwanted side-effect of making systems behind the gateway inaccessible.

All generic IPv6 addresses are in principle routed (except for link-local and ULA addresses). That is not the case with addresses in private IPv4 blocks behind NAT gateways, which many present-day networks have.

Consequently, it's important to carefully record the internal routing of all IPv6 addresses on your network, because you don't want to unintentionally allow internal traffic through two firewalls and onto the public internet. Also, with IPv6, it's harder for a human to distinguish internal traffic from external traffic than when private IPv4 address blocks are used.

In short, removing NAT from the equation increases the importance of firewalls and screening routers. Another technology that comes into its own once more is the demilitarized zone (DMZ), where internal addresses are not advertised or routed externally but are accessible only via proxies. Outbound connections are handled in much the same way.

Another point is that the IPv6 address space is so vast that it's impractical to block individual addresses on the basis of their prefixes to combat abuse (blacklisting/whitelisting). Consequently, filtering has to be based more on domain name reputation.

It's worth noting that a similar situation exists where IPv4 in combination with CGNAT is concerned: blocking a single IPv4 address can affect a large group of predominantly legitimate users. Also, when multiple services are sharing a single IPv4 address (e.g. by means of SNI), if the shared host comes under attack, it's not immediately apparent which service has been targeted.

The operational security aspects of IPv6 are discussed in this article.

Down the years, a wide range of studies have compared the speeds of IPv4 and IPv6. However, no clear winner has emerged: in some studies IPv6 was faster, in others IPv4.

In theory, IPv6 should be slightly faster than IPv4, since it features certain optimisations to the packet headers, enabling IPv6 packets to be routed more quickly. What's more, (native) IPv6 connections don't require in-transit address translation of the kind needed with any IPv4 connection that involves (CG)NAT.

On the other hand, IPv6 support was added to network equipment later. That could mean that some ASIC hardware's IPv6 support isn't realised in an ideal way, and that router enhancements might tip the balance in favour of IPv4.

In short, using IPv6 generally makes no difference to communication speeds. Far and away the biggest argument for using IPv6 is its vast address space.

When IPv6 was developed, a number of functionalities that had been defined in extensions to version 4 of the Internet Protocol were incorporated into the protocol itself. Examples are IPsec (for the authentication of hosts and the encryption of connections), automatic address assignment, and various niche extensions covered by the Extension Headers.

However, few of the innovations in question were ultimately adopted in practice. For example, IPsec was initially a mandatory feature of IPv6 implementation, having been developed as part of IPv6, but was later made optional (see RFC 8504, section 13). And we have never come across Extension Headers in use on the internet, since they proved to cause packets routing problems (as explained in RFC 7872 and this presentation).

Of the three innovations mentioned above, only automatic address assignment by means of SLAAC and NDP has proved successful. And even there we now have an alternative in the form of DHCPv6.

IPv4 was not originally complex, but is nowadays complicated by all the workarounds that have been developed down the years to keep it going a little longer, despite the problematic address shortage: NAT, CGNAT, SNI, STUN, TURN and ICE.

For its part, IPv6 is currently complicated by all the transition mechanisms developed to help the world move smoothly from IPv4 to IPv6. In the future, however, when the world is IPv6-only, those complexities will disappear.

In the current period of transition from IPv4 to IPv6, therefore, things are complicated by both IPv4 workarounds and IPv4-IPv6 transition mechanisms. Once we're through the transitional phase – for which we need everyone to implement and adopt IPv6 as soon as possible – the complexity of an IPv6 network will be much the same as the simple IPv4 networks of the past.

Various technical gateway and transition mechanisms have been developed to facilitate the transition from IPv4 to IPv6. An overview is provided in the following figure.

https://images.ctfassets.net/yj8364fopk6s/2x1OhGcA26Yvk1vhWnRgSQ/d89f852cd2d73fc8da7a9ba702973051/Transition_mechanisms.svg

The information presented below is not the sort of information that you should know by heart. It's simply an overview of the transition mechanisms you might come across or might have cause to use.

As you will see, some of the transition mechanisms listed should no longer be used. They are nevertheless included because you may come across them in legacy networks, or because they form the basis for later/improved mechanisms.

Some of the IPv4-IPv6 transition mechanisms considered below should no longer be used. They are nevertheless included because you may come across them in legacy networks, or because they form the basis for later/improved mechanisms.

The following figure provides an overview of the mechanisms that can still be used for transitioning from IPv4 to IPv6 (as also considered in RFC 9313).

https://images.ctfassets.net/yj8364fopk6s/2x1OhGcA26Yvk1vhWnRgSQ/d89f852cd2d73fc8da7a9ba702973051/Transition_mechanisms.svg

Choosing a transition mechanism for the access network is now much simpler than it was. For security reasons, the NSA advises against using protocols that rely on tunnelling and translation, except for NAT64/DNS64 and 464XLAT in IPv6-only networks. An important objection to tunnelling is that a tunnel bypasses the security of the network perimeter – firewalls, screening routers, etc. Given that 464XLAT is based on NAT64 and DNS64, the only option remaining is 464XLAT.

What's more, it appears that peak IPv4 is now behind us. Consequently, a new group of transition mechanisms has acquired a central role. As we move towards an IPv6-mainly world, it's time for old mechanisms such as dual stack with NAT and CGNAT to make way for newer alternatives based on NAT64, DNS64 and 464XLAT.

The advantage of 464XLAT is that it addresses the main IPv4-related problem, namely the address shortage. What's more, unlike CGNAT with its shared IPv4 addresses, 464XLAT does not limit (segment) the port range for the individual user. With 464XLAT, therefore, malpractice by a single user doesn't lead to a large group of end users all being blocked, as often happens with CGNAT.

A system with a dual-stack configuration has two fully operational network stacks: an IPv4 stack and an IPv6 stack. Because the IPv6 network then operates in parallel to and independently from the IPv4 network, a dual-stack configuration is the easiest way of implementing IPv6 on an existing network. The good auto-configuration support in IPv6 means that realising such a set-up is usually less work than the configuration and management of IPv4:

• The IPv6 prefixes must be installed on the routers, firewalls and other network equipment.

• Where appropriate, IPv6 must be enabled on all hosts (in addition to IPv4).

Once network-level implementation of IPv6 is complete, the applications can also be converted to IPv6. Systems and services with full IPv6 support can be added to the DNS zone where appropriate.

Advantages:

• Two separate, independent IP networks, without the combinational complexity of the other transition mechanisms considered below

Disadvantages:

• Two IP networks operating in parallel, with all the associated costs, but no corresponding commercial return

• No solution for the IPv4 address shortage

Dual-stack is defined in RFC 4213, section 2, with additional guidance for content/service providers in RFC 6883.

Dual-stack systems are able to select the preferable IP version (usually IPv6 if available), or to use whichever connection is established first. In the latter scenario, a client simultaneously asks the relevant server for a domain's AAAA record and A record, with a view to establishing IPv6 and IPv4 connections as quickly as possible. The connection that's established first is the one that's used for the remainder of the session.

Because that method yields the best response for the end user, it is known as Happy Eyeballs. A preference for IPv6 is built into the algorithm by means of the sequence of actions and systems approached, and the intervals between the various elements. At the same time, the approach ensures that a situation can't arise where a user is unable get where they want to go as a consequence of the dual-stack infrastructure operator neglecting their IPv6 network ('IPv6 brokenness').

Happy Eyeballs is defined in RFC 8305.

6to4 is a means of giving an existing system a provisional 48-bit IPv6 prefix (and then a full IPv6 address/subnet) based on its public IPv4 address. The 2002::/16 prefix is reserved for the purpose. Combining that prefix with a public 32-bit IPv4 address results in a globally unique 48-bit IPv6 prefix.

IPv6 traffic is then packed into IPv4 packets and sent via the existing IPv4-only network. Traffic to native IPv6 networks goes via special relay routers that pack and unpack the IPv6-in-IPv4 packets.

The same mechanism can be used not only by individual hosts, but also by 'IPv4' routers to access the underlying local IPv6-only networks (so-called 'border-routers', equipped with 6to4 pseudo-interfaces).

The advantages of 6to4 are that existing systems can easily be provided with unique IPv6 addresses, and that IPv6-in-IPv4 packets can be sent via the existing IPv4-only network without the need to create separate tunnels.

The drawback of 6to4 is that it works only for clients with public IPv4 addresses, and not for IPv4 clients behind NAT gateways (because their IPv4 addresses aren't unique).

6to4 is defined in RFC 3056, with additional guidance on security in RFC 3964 and deployment guidelines in RFC 6343.

RFC 3068 previously defined the address 192.88.99.1 as the anycast address for (local) relay routers, via which 6to4 hosts can send traffic to native IPv6 networks. However, that option was subsequently scrapped (in RFC 7526).

6to4 is now outdated and should no longer be used for new implementations.

6in4 (also known as 'configured tunnelling') makes use of the same concepts and IPv6-in-IPv4 packaging as the 6to4 mechanism described above. However, whereas 6to4 derives a globally unique 48-bit IPv6 prefix from a system's public IPv4 address, with 6in4 the IPv6 endpoints are configured manually. The advantage being that unique IPv6 addresses can also be given to IPv4-only systems behind NAT gateways (i.e. systems without public IPv4 addresses).

Although the technology can be used for individual hosts as well, 6in4 is used mainly for routers, because of the need for manual configuration. However, technical resources are available for automating the assignment of IPv6 addresses in order to enable access to IPv4-only services behind NAT gateways.

6in4 is defined in RFC 4213, section 3.

6in4 is now outdated and should no longer be used for new implementations.

Like 6in4, IPv6 rapid deployment ('6rd') is based on the 6to4 mechanism described above. However, it uses an addressing scheme based on the ordinary IPv6 prefixes assigned to the organisation.

In principle, 6to4 provides every public IPv4 node with a unique IPv6 prefix and connects it to the rest of the IPv6-based internet via gateway routers. However, in order to be functional, the 6to4-specific IPv6 prefixes must be advertised and routed by everyone in the outside world.

With 6rd, an organisation uses one of its own ordinary IPv6 prefixes instead of the generic 2002::/16 prefix. In order to make a node accessible from the IPv6-based internet, its IPv4 address is combined with the 6rd IPv6 prefix.

The routing prefixes that Regional Internet Registries (RIR's) assign to their members are thirty-two bits long. Adding a complete 32-bit IPv4 address to a routing prefix leaves scope for assigning 64-bit prefixes to end users. 6rd routers can therefore omit the shared most significant bits of a public IPv4 address block, so that users can be assigned shorter prefixes and still have space left for subnetworks. Another or additional possibility is to use various IPv6 prefixes for various IPv4 networks.

In the context of 6rd, nodes are referred to as customer edge (CE) routers, which may be either CPEs (Customer-Premises Equipment) or application servers. The border relays (BRs), of which there may be one or more, are the routers that route 6rd packets to and from outside the 6rd domain.

The advantage of 6rd is that you have control over the entire 6rd domain, so you can be sure that your packets are routed all over the internet.

6rd is defined in RFC 5969.

6rd is now outdated and should no longer be used for new implementations.

6over4 (also known as 'virtual Ethernet') is a way of providing existing systems with link-local IPv6 addresses and connecting them together to form a local IPv6 network segment, on the basis of an IPv4 multicast network that functions as the underlying 'data link' layer for the IPv6 segment.

The process involves first building a link-local IPv6 address by combining the fe80::/96 prefix with the relevant system's 32-bit IPv4 address.

Note that the value of the Universal/Local flag at position 7 of the 64-bit interface identifier is now zero, indicating that the identifiers are not unique (in contrast to the Modified EUI-64-based identifiers considered above, in which the flag value is 1).

For NDP – an IPv6 'link-layer' protocol (i.e. a multicast protocol) – an existing or specially created IPv4 multicast network is used to connect the various 6over4-enabled systems 'directly' to each other.

The IPv6 packets are transported in the same IPv6-in-IPv4 packaging used with the 6to4 and 6in4 mechanisms.

6over4 is defined in RFC 2529.

6over4 is now outdated and should no longer be used for new implementations.

Public 4over6 is intended for use by access providers that want to enable end users to access the IPv4-based internet via an IPv6-only network (without the need for a complete dual-stack implementation).

The mechanism involves the delegation of public IPv4 addresses to users (CPEs), meaning that it can also be used to enable access to IPv4 application servers. Assignment is by means of DHCP(v4) over IPv6 where large numbers of users are concerned, and static where IPv4 application servers are concerned.

IPv4 packets are transported over the IPv6-only network by means of generic IPv4-in-IPv6 tunnelling in accordance with RFC 2473. The IPv6 tunnel then serves as a virtual 'data link' layer for the IPv4 traffic using it. IPv4-in-IPv6 tunnel packets are packed and unpacked by the routers/gateways at the ends of the tunnel. With this mechanism, IPv4 addresses are not incorporated into the corresponding IPv6 address. Consequently, the gateway at the provider's end (the tunnel concentrator) has to maintain a record of the linked IPv4 and IPv6 addresses.

Public 4over6 is defined in RFC 7040.

Public 4over6 is now outdated and should no longer be used for new implementations.

Access providers with limited public IPv4 address resources at their disposal are referred to the information immediately below about Dual-Stack Lite (a CGNAT-based alternative), or to the question about the more scalable Lightweight 4over6 further below.

Dual-Stack Lite (DS-Lite) combines the IPv4-in-IPv6 tunnelling of Public 4over6 with (CG)NAT. Then, instead of being assigned public IPv4 addresses, end users (CPEs) are assigned private IPv4 addresses.

The IPv4 network 192.0.0.0/29 is reserved for that purpose:

• The provider-side Address Family Transition Router (AFTR) (a combination of a tunnel concentrator and an NATP gateway) is always assigned the address 192.0.0.1.

• The Basic Bridging BroadBand (B4) interface on the CPE is always assigned the address 192.0.0.2.

• The IPv6 address of the AFTR gateway used to send IPv4-in-IPv6 tunnel packets (and other settings) are usually assigned to the B4 interface by means of DHCPv6.

IPv4-to-IPv4 translation for NATP is performed on the (provider-side) AFTR after the incoming IPv4-in-IPv6 tunnel packets have been unpacked and before outgoing tunnel packets are packed. Because the procedure involves use of the IPv6 address link, single-step translation is sufficient.

Not being dependent on the availability of sufficient public IPv4 addresses, DS-Lite is suitable for giving a large number of users access via an IPv6-only network. However, since the users are not then reachable from the internet, DS-Lite isn't suitable for providing application server access.

DS-Lite is defined in RFC 6333.

Lightweight 4over6 (lw4o6) is an extension to the DS-Lite mechanism described above, which shifts IPv4-IPv6 translation from the central tunnel concentrator (the AFTR) to the individual CPE.

Because the AFTR and B4 interface IPv4 addresses are always the same for all individual users, and the IPv4 packets travelling between the CPE and the NATP gateway don't have to be routed (since they are transported through the IPv6-tunnel), the IPv4-IPv4 translation of the IPv4 packets can easily be performed on the CPE (i.e. at the other end of the tunnel, the user's end).

All the CPE needs to know is what public IPv4 address and what port range are reserved for the CPE on the public side of the NATP gateway, so that the IPv4 packets can be compiled in the appropriate form for routing in the outside world (i.e. with the appropriate source/destination). That (additional) information is given to the lwAFTR's lwB4 interface using DHCP or the Port Control Protocol (PCP).

Lightweight 4over6 has the advantage of being more scalable than DS-Lite, due to the NATP function being transferred from the central AFTR to the individual CPE.

Lightweight 4over6 is defined in RFC 7596.

NAT64 is a (stateful) NAT technology that enables IPv6-only systems behind a NAT64 gateway to communicate with IPv4-only systems on the internet.

As a destination address, the clients behind the gateway use the 64:ff9b::/96 prefix (or a prefix from the 64:ff9b:1::/48 address space, or one of the organisation's own general prefixes), combined with the IPv4 address of the server. The special packets thus compiled are routed internally from and to the NAT64 gateway, where translation between IPv6 and IPv4 takes place (i.e. at the protocol level).

Like traditional IPv4-IPv4 NAT (NAT44), NAT64 works only for connections initiated by clients behind the gateway.

Furthermore, because only the headers of the IP packets are translated (in accordance with RFC 7915, previously RFC 6145), NAT64 does not work for application protocols that involve incorporation of literal IP addresses into packet payloads (e.g. the old FTP protocol). So, for example, if an IPv6-only client sends an IPv6 address-port combination to the IPv4-only server (e.g. because the server has an application-specific port open), the server will not be able to open it. Conversely, if an IPv4-only server sends an IPv4 address-port combination back to the IPv6-only client, the client will not be able to open it.

NAT64 is defined in RFC 6146, with deployment scenarios in RFC 6144.

Like NAT44, NAT64 currently supports only TCP, UDP and ICMP.

In the reply presented immediately below, we consider how NAT64 can be combined with DNS64 to form a comprehensive transition mechanism so that no modifications to individual IPv6-only systems are required.

DNS64 is a DNS function for compiling AAAA records (i.e. IPv6 records) from A records (IPv4 records), for use in combination with the NAT64 transition mechanism described above.

If a DNS64 server receives a request for the AAAA records for a domain name, but only A records are available, the server creates a (synthetic) AAAA resource record set. The synthesis process involves combining the A records with the 64:ff9b::/96 prefix (or a prefix from the 64:ff9b:1::/48 address space, or one of the organisation's own ordinary prefixes).

The combination of NAT64 and DNS64 yields a complete transition mechanism, for which no modifications to individual IPv6-only systems are required.

Although this network architecture is readily scalable, the NAT64 gateway does introduce a bottleneck to the network.

However, the main disadvantage of this solution is that it doesn't work in combination with end-to-end DNSSEC validation. The reason being that the DNS64 server (functioning as a recursive resolver) cannot generate a digital signature (RRSIG record) for the AAAA resource record set it has created for someone else's domain name.

A validating (DNS64-aware) resolver on the IPv6-only client could possibly perform IPv4 validation if it received in response a resource record set including a DNS64 prefix. In other cases, the DNS64 server could validate the IPv4 resource record set and possibly set the AD flag (if the client's (stub) resolver has set the AD flag but not the CD flag). However, in that scenario, the last mile would not be protected. Furthermore, the last of those options (setting an AD flag for a non-authentic resource record set) is not formally permitted by the DNSSEC standard.

DNS64 is defined in RFC 6147.

Like the NAT64-DNS64 combination described above, 464XLAT also makes it possible for IPv6-only systems behind a NAT64 gateways to communicate with IPv4-only systems on the internet.

With 464XLAT, the NAT64 gateway is combined with a customer-side translator (CLAT) installed on each client to provide a virtual IPv4 interface there (from a private address block). Then, if one of the clients contacts an IPv4-only server, the local CLAT makes an initial (stateless) translation, where outbound IPv4 packets are converted to the 64:ff9b::/96 prefix (or a prefix from the 64:ff9b:1::/48 address space, or one of the organisation's own ordinary prefixes) in accordance with RFC 7915. When the packets arrive at the NAT64 gateway (referred to in this context as the provider-side translator or PLAT) a second (stateful) translation is performed, from IPv6 back to IPv4. The packets are then sent to the relevant IPv4-only server.

Because both hosts are using IPv4, the problem of the incompatible literals is resolved. The limitations of NAT remain, however.

The prefix that the CLAT uses for the first translation is usually assigned by means of DHCPv6. Alternatively, an ordinary IPv6 prefix that's been assigned to the organisation can be used. However, that entails the risk that the packets may at some stage be mistaken for safe internal traffic.

Despite the resemblance, the 464XLAT mechanism is not a form of tunnelling: the IPv4 packets are not packed in IPv6, but actually converted to IPv6 and back again.

Although a DNS64 server isn't necessarily required for 464XLAT, one can still be used for traffic (i.e. applications) that definitely does not contain literals. Literal-free traffic requires only a single translation on the PLAT, exactly as described above in relation to the NAT64-DNS64 combination.

Advantages:

• Enables creation of a future-proof internal IPv6-only infrastructure and data centres, without loss of connectivity with the IPv4-only part of the internet.

• The number of public IPv4 addresses required is minimal.

• Only one IP network has to be maintained, implying less expense than with a dual-stack setup.

464XLAT is defined in RFC 6877, with additional guidance on data centres in RFC 7755 and RFC 7756 (SIIT-DC for inward-bound IPv4 traffic).

Mapping of Address and Port (MAP) is a method for making stateful gateways or the DS-Lite and NAT64 transition mechanisms as stateless as possible, and upscaling them. That is achieved by also including the (shared) IPv4 sender address within the IPv6 sender address.

IPv4 addresses may be shared by multiple end users (CPEs) by dividing the sixteen-bit port space into blocks and assigning the blocks to CPEs individually. Thus, a small number of globally/locally unique, port-restricted IPv4 addresses can be used for several times as many end users, without any need to share address-port combinations. In essence, that means the most significant bits of the port space being added to the IPv4 address space. Known as Address plus Port (A+P), the technology is defined in RFC 6346.

The MAP standards use the term Customer Edge (CE) for the CPE, Border Relay (BR) for the IPv4-IPv6 gateway, Port Set for the individual port blocks, Port Set ID (PSID) for the most-significant-port bits identifying a Port Set, IPv4 prefix for the shared bits in the IPv4 address, IPv4 suffix for the unique bits in the IPv4 address, Embedded Address (EA) bits for the compiled IPv4 suffix/PSID identification of a CE, and MAP domain for the address space created by the EA bits.

Every CE device is given an IPv6 address consisting of an ordinary IPv6 prefix that's been assigned to the organisation (typically thirty-two bits), followed by the EA bits (together sixty-four bits), followed by a 64-bit network interface identifier (containing the complete IPv4 address and PSID), resulting in a unique IPv6 sender address: <organisation prefix><EA bits>:0000:<IPv4 address><PSID>.

Note that the 64-bit network prefix (with possible overrun to the interface identifier) in the IPv6 sender address contains all the information needed to fully route packets from and to the relevant CPE. Consequently, the gateway can operate almost statelessly.

CPEs within a MAP domain (MAP nodes) can communicate with each other directly (in 'Mesh mode'). IPv4 traffic to the outside world travels through a point-to-point tunnel from the CPE to the Border Relay, by means of generic IPv4-in-IPv6 tunnelling according to RFC 2473 (for MAP with Encapsulation), or by means of the NAT64 translation function of the Border Relay (for MAP using Translation).

MAP is defined in RFC 7597 and RFC 7599.

The first of those RFCs defines MAP-E (MAP with Encapsulation), where IPv4 traffic is packed in IPv4-in-IPv6 tunnel packets. That makes MAP-E a stateless variant of the DS-Lite mechanism.

The second RFC defines MAP-T (MAP using Translation), where MAP is combined with NAT64 translation to make it stateless. In fact, the technology involves double NAT64 translation (for both the destination address and the source address).

All the information about IPv6 prefixes, IPv4 postfixes and Port Sets required by MAP-enabled CPEs is assigned by means of DHCPv6, as specified in RFC 7598. The NATP function on the CPE ensures that only ports from the CPE's own Port Set are used for the embedded IPv4 sender addresses of connections to the outside world. The MAP-specific configurations for CPEs and Border Relays are recorded and distributed in so-called mapping rule sets.

To a very large extent, the best way to implement IPv6 on an existing network infrastructure depends on the current landscape. Generally speaking, where a large and complex corporate network is concerned, the first step is to define a strategy and a roadmap based on the starting position and the commercial/technical objectives, and then to select the most appropriate IPv4-IPv6 transition mechanism. Next, the strategy and roadmap are used as the starting point for developing a definite network architecture blueprint, an addressing plan, a routing plan and security policies.

The following bulleted summary can help with the IPv6 implementation process:

• The starting position and commercial/technical objectives and considerations are used to perform the following task sequence:

  • Formulation of a strategy

  • For strategic considerations relevant to the implementation of IPv6 on a corporate network, see RFC 7381

  • Development of a roadmap

  • Selection of a transition mechanism

• The next steps involve formulation (i.e. explicit statement) of the following:

  • Network architecture

  • Addressing plan

    • For more information about the assignment of unicast IPv6 addresses, see RFC 5375.

  • Routing plan

  • Security policies for the network nodes and segments

  • Arrangements for security logging, analysis and processing

• It can be helpful to use software for network design and management and IP Address Management (IPAM).

We offer our registrars 2 e-learning modules about IPv6 via the SIDN Academy.

This FAQ resource includes information about IPv4-IPv6-transition mechanisms that should no longer be used. They are nevertheless described because you may come across them in legacy networks, or because they form the basis for later/improved mechanisms.

The following figure provides an overview of the mechanisms that can still be used for transitioning from IPv4 to IPv6 (as also considered in RFC 9313).

https://images.ctfassets.net/yj8364fopk6s/2x1OhGcA26Yvk1vhWnRgSQ/d89f852cd2d73fc8da7a9ba702973051/Transition_mechanisms.svg

Choosing a transition mechanism for the access network is now much simpler than it was. For security reasons, the NSA advises against using protocols that rely on tunnelling and translation, except for NAT64/DNS64 and 464XLAT in IPv6-only networks. An important objection to tunnelling is that a tunnel bypasses the security of the network perimeter – firewalls, screening routers, etc. Given that 464XLAT is based on NAT64 and DNS64, the only option remaining is 464XLAT.

What's more, it appears that peak IPv4 is now behind us. Consequently, a new group of transition mechanisms has acquired a central role. As we move towards an IPv6-mainly world, it's time for old mechanisms such as dual stack with NAT and CGNAT to make way for newer alternatives based on NAT64, DNS64 and 464XLAT.

The advantage of 464XLAT is that it addresses the main IPv4-related problem, namely the address shortage. What's more, unlike CGNAT with its shared IPv4 addresses, 464XLAT does not limit (segment) the port range for the individual user. With 464XLAT, therefore, malpractice by a single user doesn't lead to a large group of end users all being blocked, as often happens with CGNAT.

Yes. All mainstream network equipment supports IPv6. Interoperability is no longer a problem at all. Professional equipment no longer requires interoperability testing; all modern systems designed for business use support IPv6.

IPv6 is supported by all main network management software and tools as well. That includes provider platforms such as Plesk, cPanel and DirectAdmin.

Detailed (functional) requirements regarding IPv6 support in network equipment are provided by RFC 8504 (BCP 220) and the ripe-772 document published by RIPE NCC, for example.

IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Investment in and migration to IPv6 involve no technological risk.

Yes. IPv6 is supported by all the main operating systems, including both open-source and proprietary systems.

IPv6 is supported by all main network management software and tools as well. That includes provider platforms such as Plesk, cPanel and DirectAdmin.

Detailed (functional) requirements regarding IPv6 support in network equipment are provided by RFC 8504 (BCP 220) and the ripe-772 document published by RIPE NCC, for example.

IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Investment in and migration to IPv6 involve no technological risk.

Almost all application software with a network component now supports IPv6. If you do happen to have application software that doesn't support IPv6, we advise asking (again) for support to be added. The information in this FAQ resource may be useful in that context. If that doesn't work, you may have to consider switching to alternative software, if that's possible.

IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Investment in and migration to IPv6 involve no technological risk.

All mainstream network server software now supports IPv6. However, you may need to enable and configure IPv6 in your software's configuration files to work alongside IPv4.

IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Investment in and migration to IPv6 involve no technological risk.

If your server operator can't or won't help you with IPv6, we advise asking (again) for IPv6 support to be made available. The information in this FAQ resource may be useful in that context. If that doesn't work, you may have to consider switching to an alternative service provider, if that's possible.

IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Investment in and migration to IPv6 involve no technological risk.

In principle, the situation with (virtual) servers in the cloud is the same as with locally operated servers: all mainstream network server software now supports IPv6. However, you may need to enable and configure IPv6 in your software's configuration files to work alongside IPv4.

If your service provider can't or won't help you with IPv6, we advise asking (again) for IPv6 support to be made available. The information in this FAQ resource may be useful in that context. If that doesn't work, you may have to consider switching to an alternative service provider, if that's possible.

IPv6-related knowledge, experience and support are widespread amongst vendors and service providers.

Investment in and migration to IPv6 involve no technological risk.

In addition to the standard network utilities (e.g. ping6 and traceroute6), various online tools are available for testing the availability of IPv6. We also recommend the Internet.nl portal: all three tests (for your web domain, your mail domain and your internet connection) include an IPv6 support check.

Finally, there are two test portals specifically for IPv6: ip.bieringer.net and ipv6-test.com.

All generic IPv6 addresses are in principle routed (except for link-local and ULA addresses). That is not the case with addresses in private IPv4 blocks behind NATgateways, which many present-day networks have.

Consequently, it's important to carefully record the internal routing of all IPv6 addresses on your network, because you don't want to unintentionally allow internal traffic through two firewalls and onto the public internet. Also, with IPv6, it's harder for a human to distinguish internal traffic from external traffic than when private IPv4 address blocks are used.

In short, removing NAT from the equation increases the importance of firewalls and screening routers. Another technology that comes into its own once more is the demilitarized zone (DMZ), where internal addresses are not advertised or routed externally but are accessible only via proxies. Outbound connections are handled in much the same way.

Another point is that the IPv6 address space is so vast that it's impractical to block individual addresses on the basis of their prefixes to combat abuse (blacklisting/whitelisting). Consequently, filtering has to be based more on domain name reputation.

The security and privacy considerations associated with address assignment are considered in RFC 7721.

The operational security aspects of IPv6 are discussed in this article.

With SLAAC, interface identifiers are derived directly from the more-or-less unique MAC addresses of the relevant interfaces. Consequently, the addresses can be used to monitor the online behaviour of users and the locations of mobile devices, since the identifiers remain the same, even if the network prefix changes.

The Privacy Extensions for SLAAC address that problem by, for example, the use of temporary (random) addresses generated on a daily basis. In that scenario, previously generated temporary addresses remain valid for inbound traffic for a further day. So the status of a temporary address goes from 'preferred' to 'deprecated', and ultimately to 'invalid'.

An alternative approach is put forward in RFC 7217, involving the generation and maintenance of a random interface identifier for each interface and subnet. So the IPv6 addresses remain constant for each network (prefix), but they can't be associated with one another on the basis of their interface identifiers.

RFC 8064 now advises against using hardware-dependent SLAAC addresses, in favour of using IPv6 addresses generated in accordance with RFC 7217 instead.

The security and privacy considerations associated with address assignment are considered in RFC 7721.

The privacy aspects of IPv6 are also considered in this article.

Privacy Extensions for SLAAC can be generally configured for your users using network management-software such as IPAM and DHCPv6. On an individual computer system, you need to go to the network settings configuration screen.

IPv4 with CGNAT creates problems, not only for all IP address-based security mechanisms (e.g. blacklisting/whitelisting and reputation management), but also for law enforcement agencies. Back in 2017, for example, Europol reported that access providers using CGNAT were often no longer able to meet their legal obligation to provide details of the account holder linked to a given connection. As a result, the agency said, it was common for investigations to involve examining and tapping the connections of many more people than really necessary.

Around the same time, the European Commission published a letter entitled Resilience, Deterrence and Defence: Building strong cybersecurity for the EU, describing how it wanted to promote the adoption of IPv6. Ultimately, the Commission wanted to see a situation where an IP address only ever has one user, facilitating the accurate targeting of investigative activities by the police and security services. The Commission planned to pursue that aim through procurement policy, research and project funding, and covenants. Member states would also be required to negotiate (non-mandatory) covenants with their access providers.

Here in the Netherlands, in 2019 the Ministry of Justice and Security's Research and Documentation Centre (WODC) published the findings of research into the identification of individual IP address users for the purposes of criminal investigation and prosecution (as provided for in the Telecommunications Data Retention Act). Again, the general adoption of IPv6 was recommended as the most obvious solution.

Although end users sometimes voice privacy-based objections to the use of IPv6 – on the grounds that CGNAT unintentionally provides a degree of anonymity not dissimilar to the use of a VPN provider – the authors of the WODC report argue that IPv6 actually enhances privacy. The rationale being that criminal investigations can be targeted better, without large numbers of innocent users falling within their scope. Moreover, aside from the technical and commercial considerations, it is much easier for access providers to fulfil their compliance responsibilities with IPv6 than with IPv4 plus CGNAT.

As an end user, you are dependent on your access provider or network operator to provide you with an address from a (consisting of billions of addresses). Unfortunately, many access providers and corporate network operators in the Netherlands still don't yet offer IPv6 to their customers and users. The good news is that the country's 2 biggest access providers, KPN and Ziggo (part of VodafoneZiggo), have (finally) made considerable progress on IPv6 in recent years. However, smaller access providers and network operators don't appear to be making any progress with IPv6. There are some exceptions to that general picture, though: Freedom Internet, SURF, the University of Twente and Zeelandnet (part of Delta) all stand out. However, those players are well-established technological innovators who adopted IPv6 long ago. For them, use of the latest technology is integral to their identity and reputation.

If your access provider or network operator does support IPv6, it is probably enabled by default. If IPv6 isn't enabled, we suggest that you get in touch with your provider or operator.

If your access provider or network operator can't or won't help you with IPv6, we advise asking (again) for IPv6 support to be made available. The information in this FAQ resource may be useful in that context. If that doesn't work, you may have to consider switching to an alternative service provider, if that's possible.

Yes. If your access provider or network operator does support IPv6 but hasn't enabled it for you, you can ask them to do so.

If your access provider or network operator can't or won't help you with IPv6, we advise asking (again) for IPv6 support to be made available. The information in this FAQ resource may be useful in that context. If that doesn't work, you may have to consider switching to an alternative service provider, if that's possible.

If your access provider or network operator can't or won't help you with IPv6, we advise asking (again) for IPv6 support to be made available. The information in this FAQ resource may be useful in that context. If that doesn't work, you may have to consider switching to an alternative service provider, if that's possible.

In addition to the standard network utilities (e.g. ping6 and traceroute6), various online tools are available for testing the availability of IPv6. We also recommend the Internet.nl portal: all three tests (for your web domain, your mail domain and your internet connection) include an IPv6 support check.

Finally, there are two test portals specifically for IPv6: ip.bieringer.net and ipv6-test.com.

All generic IPv6 addresses are in principle routed (except for link-local and ULA addresses). That is not the case with addresses in private IPv4 blocks behind NAT gateways, which many present-day networks have. Consequently, when you use IPv6, you need to pay extra attention to the firewalls on your internet router and on your individual systems.

With SLAAC, interface identifiers are derived directly from the more-or-less unique MAC addresses of the relevant interfaces. Consequently, the can be used to monitor the online behaviour of users and the locations of mobile devices, since the identifiers remain the same, even if the network prefix changes.

The Privacy Extensions for SLAAC address that problem by, for example, the use of temporary (random) addresses generated on a daily basis. In that scenario, previously generated temporary addresses remain valid for inbound traffic for a further day. So the status of a temporary address goes from 'preferred' to 'deprecated', and ultimately to 'invalid'.

An alternative approach is put forward in RFC 7217, involving the generation and maintenance of a random interface identifier for each interface and subnet. So the IPv6 addresses remain constant for each network (prefix), but they can't be associated with one another on the basis of their interface identifiers.

RFC 8064 now advises against using hardware-dependent SLAAC addresses, in favour of using IPv6 addresses generated in accordance with RFC 7217 instead.

General configuration of Privacy Extensions for SLAAC can usually be done on your internet router. On an individual computer system, you need to go to the network settings configuration screen.

As an LAN operator, you are dependent on your (organisation's) access provider to provide you with an address from a (consisting of billions of addresses). To get IPv6 enabled on your network(s), therefore, you'll need to contact your access provider.

If your access provider can't or won't help you with IPv6, we advise asking (again) for IPv6 support to be made available. The information in this FAQ resource may be useful in that context. If that doesn't work, you may have to consider switching to an alternative service provider, if that's possible.

IPv6 is designed so that the assignment of addresses is performed automatically as far as possible. Interface identifiers are therefore generated automatically (by means of SLAAC) and prefixes are managed at the router level wherever possible. That makes it relatively easy to renumber an entire network (as discussed in RFC 7010), for example, since only the advertised prefixes need to be changed.

So, in order to enable IPv6 on your subnetworks as well, all you have to do is define a sub-prefix on the router for the relevant network segment. The routers in your network then share the relevant information with one another, enabling IPv6 for an entire segment at once.

The following illustration shows the prefix delegation settings on the FRITZ!Box 7590 (Home Network → Network → Network Settings → Additional Settings → IPv6 Settings):

In addition to the standard network utilities (e.g. ping6 and traceroute6), various online tools are available for testing the availability of IPv6. We also recommend the Internet.nl portal: all three tests (for your web domain, your mail domain and your internet connection) include an IPv6 support check.

Finally, there are two test portals specifically for IPv6: ip.bieringer.net and ipv6-test.com.

All generic IPv6 addresses are in principle routed (except for link-local and ULA addresses). That is not the case with addresses in private IPv4 blocks behind NAT gateways, which many present-day networks have. Consequently, when you use IPv6, you need to pay extra attention to the firewalls on your internet gateway and on your individual systems.

The security and privacy considerations associated with address assignment are considered in RFC 7721.

The operational security aspects of IPv6 are discussed in this article.

With SLAAC, interface identifiers are derived directly from the more-or-less unique MAC addresses of the relevant interfaces. Consequently, the can be used to monitor the online behaviour of users and the locations of mobile devices, since the identifiers remain the same, even if the network prefix changes.

The Privacy Extensions for SLAAC address that problem by, for example, the use of temporary (random) addresses generated on a daily basis. In that scenario, previously generated temporary addresses remain valid for inbound traffic for a further day. So the status of a temporary address goes from 'preferred' to 'deprecated', and ultimately to 'invalid'.

An alternative approach is put forward in RFC 7217, involving the generation and maintenance of a random interface identifier for each interface and subnet. So the IPv6 addresses remain constant for each network (prefix), but they can't be associated with one another on the basis of their interface identifiers.

RFC 8064 now advises against using hardware-dependent SLAAC addresses, in favour of using IPv6 addresses generated in accordance with RFC 7217 instead.

The security and privacy considerations associated with address assignment are considered in RFC 7721.

The privacy aspects of IPv6 are also considered in this article.

General configuration of Privacy Extensions for SLAAC for your users can usually be done on the internet gateway. On an individual computer system, you need to go to the network settings configuration screen.

We offer 2 e-learning modules about IPv6. We also publish a steady stream of IPv6-related news bulletins, technical articles, reports and case studies on sidn.nl.

More information

• Internet Society (ISOC): IPv6 https://www.internetsociety.org/deploy360/ipv6/ https://www.internetsociety.org/issues/ipv6/

• ARIN: IPv6 Information: https://www.arin.net/resources/guide/ipv6/

Statistics

• RIPE NCC: IPv6 Enabled Networks http://v6asns.ripe.net/v/6

• IPv6-Enabled Web Browsers: https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=be,de,us,lu,nl

• AAAA and IPv6 connectivity statistics of top websites according to Alexa: https://www.employees.org/~dwing/aaaa-stats/

• IPv6 Deployment Aggregated Status: https://www.vyncke.org/ipv6status/

• Global IPv6 Deployment Progress Report: https://bgp.he.net/ipv6-progress-report.cgi

• ipv6-overview.xyz: https://ipv6-overview.xyz/

Implementation

• Guidelines and Process: IPv6 for Public Administrations in Europe: https://joinup.ec.europa.eu/collection/egovernment/document/guidelines-and-process-ipv6-public-administrations-europe

• A Short IPv6 Guide for Home IPv4 Admins

Tools

• address calculator for IPv4 en IPv6: http://silmor.de/ipaddrcalc.html

• or the sipcalc command line tool: http://www.routemeister.net/projects/sipcalc/index.html

• Internet.nl: tests to check, for example, whether IPv6 is enabled on your web domain, mail domain and internet connection: https://www.internet.nl/

• IPv6 domain readiness tester: https://ip6.nl/

• ip.bieringer.net: https://ip.bieringer.net/

• IPv6-test.com: https://ipv6-test.com/

• IPv6 health check: https://www.mythic-beasts.com/ipv6/health-check

• Is your site IPv6 ready? https://ready.chair6.net/

• What is my IP Address? http://ip6.me/

• Test your Happy Eyeballs: http://he.test-ipv6.com/