There have been several calls to action for organisations to deploy the newer version of the Internet Protocol, IPv6, which is designed to eventually replace the IPv4 protocol. The Internet Society strongly supports such calls for action. In fact, the Internet Society-led World IPv6 Launch on 6 June 2012 was a major catalyst for IPv6 deployment.
If deployment is delayed, the future growth and global connectivity of the Internet will be negatively impacted. The information below is intended to assist in answering some of the frequently asked questions associated with exhaustion of the IPv4 address pool and the adoption of IPv6.
This list of FAQs is intended to be a “living document.” It will continue to be updated and expanded. In addition, read these additional documents:
- NEW: IPv6 Security Frequently Asked Questions (FAQ)
- Who Makes the Internet Work? The Internet Ecosystem
- A short Guide to IP Addressing
Table of Contents
- Is the Internet about to run out of IPv4 addresses?
- What is IPv6?
- Who created IPv6 and how long has IPv6 been available?
- What happened to IPv5??
- How does IPv6 solve the problem of IPv4 address exhaustion?
- What happens when the IPv4 address pool is finally depleted?
- When will IPv4 addresses actually run out?
- What’s the difference between IPv4 and IPv6? Will users be able to tell the difference?
- I’ve heard some people say IPv6 is more secure than IPv4, while others say it is less secure than IPv4. What is this about?
- Is IPv6 ready for deployment now?
- Why has it taken so long for IPv6 to be implemented?
- Has IPv6 been added to the root servers?
- How much will the transition to IPv6 cost?
- I have enough IPv4 addresses today. Why should I bother implementing IPv6?
- Is there a specific date when everything needs to be upgraded to IPv6?
- Will IPv6 addresses run out eventually?
- When will I need to turn off IPv4?
- Will IPv4 address depletion mean that services will get switched off?
- Isn’t address sharing the answer? We introduced NAT last time addresses were becoming scarce.
- Without NAT, won’t my network be less secure?
- I run an ISP with a block of IPv4 address space. Can I just convert that into IPv6 space?
- I run IT services. What should I be doing now to get ready?
A qualified ‘yes’ to this.
As of October 2018, all the RIRs are assigning addresses from their last /8 block. An up-to-date report on IPv4 address assignment can be found here.
To put IPv4 address exhaustion into perspective, there are an estimated 11 billion devices connected to the Internet (Gartner), and this number is estimated to increase to 20 billion by 2020. There are also estimated to be 3.2 billion Internet users in the world (ITU), but the global population is 7.2 billion, so it is clear there are insufficient public IPv4 addresses to service future requirements. It is currently expected that the public IPv4 address pool will be entirely depleted by 2021.
There is a substantial amount of IPv4 address space (so-called legacy addresses) that was previously assigned to organisations and never used, or were assigned for experimental purposes and are no longer required. Some of this has been returned or recovered by IANA who in turn re-allocates it to the RIRs, whilst Local Internet Registries (LIRs) are also able to trade IPv4 address blocks that exceed requirements to other LIRs, therefore encouraging more efficient usage. The typical cost of a /24 block of 255 addresses is currently in the order of USD $12-14 per address (IPv4 Market Group).
Another widely used technique to facilitate connectivity is Network Address Translation (NAT), which uses specifically allocated IPv4 blocks (typically 10.x.x.x or 192.168.x.x) that are reserved for private networks. This allows nodes to use private IPv4 addresses in the internal network, while sharing a single public IPv4 address when communicating with the public Internet. However, NAT requires IP packets to be rewritten by a router, which can impose a performance penalty and cause problems with certain higher level protocols that employ IPv4 address literals (as opposed to domain names) in the application protocol. Some large ISPs that are running Carrier-Grade NAT (CGN) are also finding that even the 16.7 million addresses available in the largest private IPv4 block are insufficient to service their customers, and are therefore having to run multiple layers of CGN which causes substantial performance and network management issues.
In the European (served by RIPE NCC) and North American (served by ARIN) regions, IPv4 addresses are no longer freely available and there is a wait list (https://www.arin.net/resources/request/waiting_list.html) for recovered addresses. The Asia-Pacific (APNIC) and Latin America and the Caribbean (LACNIC) regions have implemented strict rationing measures to conserve availability whereby new LIRs are only eligible for a /22 block of 1,024 addresses, with only the African (AfriNIC) region not considered to have depleted their address pool.
The Internet Society, ICANN, and the RIRs encourage network operators to adopt IPv6, which enables 340 trillion trillion trillion IP addresses to be used. That’s enough for millions of addresses to be assigned to every person on Earth for hundreds of years, and solves the problem of an insufficient number of IPv4 addresses to meet the needs of a growing Internet.
IPv6 is a new version of the Internet Protocol that will eventually replace IPv4, the version that is most widely used on the Internet today. IPv6 is a well established protocol that is seeing growing usage and deployment, particularly in mobile phone markets.
IPv6 was created by the Internet Engineering Task Force (IETF), an international group that develops technical standards for the Internet. The core specification for the IPv6 protocol was first published in 1995 as RFC 1883, and has seen a number of enhancements and updates since then. It formally became a full standard (as opposed to a draft standard) in 2017 with the publication of RFC 8200, although IPv6 had already been deployed for many years.
Version 5 of the IP family was an experimental protocol developed in the 1980s. IPv5 (also called the Internet Stream Protocol) was never widely deployed, and since the number 5 was already allocated, this number was not considered for the successor to IPv4. Several proposals were suggested as the IPv4 successor, and each was assigned a number. In the end, the one with version number 6 was selected.
IPv6 uses 128-bit addresses as opposed to the 32-bit addresses used by IPv4, allowing for a substantially larger number of possible addresses. With each bit corresponding to a ‘0’ or ‘1’, this theoretically allows 2^128 combinations or 340 trillion, trillion, trillion addresses. By contrast, IPv4 permits 2^32 combinations for a maximum of approximately 4.7 billion addresses.
In practice, the actual number of usable addresses is slightly less as IPv6 addresses are structured for routing and other purposes, whilst certain ranges are reserved for special use. The number of IPv6 addresses available, though, is still extremely large.
Network operators and large enterprises are typically expected to be assigned a /32 address block, smaller enterprises a /48, and home users a /56 (when they would typically get a single IPv4 address). This allows for scalability and future subnetting, and a virtually-unlimited number of addresses in each /64 subnet.
There is an erroneous perception that the assignment of large IPv6 prefixes to end customers is wasteful, but the IPv6 address space is so huge that it has been calculated (by Tony Hain) that a /48 could be assigned to every human for the next 480 years before they run out.
Existing devices and networks connected to the Internet using IPv4 addresses should continue to work as they do now. In fact, IPv4-based networks are expected to co-exist with IPv6-based networks at the same time.
However, for network operators and other entities that rely on Internet address assignments, it will become increasingly difficult and expensive (and eventually prohibitively so) to obtain new IPv4 address space to grow their networks. The cost and complexity associated with keeping track of and managing remaining IPv4 address space efficiently will also increase, so network operators and enterprises will need to implement IPv6 in order to ensure long-term network growth and global connectivity.
There are various translation mechanisms available to allow hosts that support only IPv4 or IPv6 to communicate with each other. For example, NAT64 facilitates communication using a form of Network Address Translation (NAT) whereby multiple IPv6 addresses can be mapped onto one IPv4 address, thus allowing traffic using the different protocols to be exchanged while conserving IPv4 address space. NAT64 uses a gateway that routes traffic from an IPv6 network to an IPv4 one, and performs the necessary translations for transferring packets between the two networks. 464XLAT extends this functionality by allowing IPv4-only applications to communicate over a IPv6-only network, making an IPv4 address unnecessary on the host device.
Many well-known enterprises are already deploying IPv6-only services and networks, which reduces the network management burden as there is no longer any IPv4 on the network. The need to translate from an IPv6-only environment to IPv4-only hosts on the Internet will reduce as IPv6 is more widely deployed around the world.
Of course, it will still be possible to use existing IPv4 addresses for the foreseeable future, even though their usage is expected to decline as devices and services increasingly support IPv6.
The last IPv4 address blocks have already been allocated to the Regional Internet Registries (RIRs) and have either been depleted or are very close to depletion. Some legacy address blocks may be recovered and reallocated, and some previously assigned address blocks will be traded by their holders, but it will no longer be possible to get new address blocks to meet the future growth of the Internet. An up-to-date report on IPv6 assignment is available here.
The key difference between the versions of the protocol is that IPv6 has significantly more address space. Users should not be aware of any difference.
The addresses do look different though. The IPv6 address notation is eight groups of four hexadecimal digits with the groups separated by colons, for example 2001:db8:1f70:999:de8:7648:3a49:6e8, although there are methods to abbreviate this notation. For comparison, the IPv4 notation is four groups of decimal digits with the groups separated by dots, for example 198.51.100.1.
The expanded addressing capacity of IPv6 will enable the trillions of new Internet addresses needed to support connectivity for a huge range of new devices such as phones, household appliances and vehicles.
I’ve heard some people say IPv6 is more secure than IPv4, while others say it is less secure than IPv4. What is this about?
Debates concerning IPv4 versus IPv6 security often focus on different aspects of network deployment.
It has been said that IPv6 supports improved security because the IP Security (IPsec) was originally developed for IPv6 and it implementation was intended to be a mandatory part of the protocol. However, IPsec can also be used with IPv4, and is now simply recommended for use with IPv6 because it was considered impractical to require full IPsec implementations for all types of devices that may use IPv6. The benefits of using IPsec are similar with both IPv4 and IPv6.
On the other hand, the increased address space offered by IPv6 does largely eliminate the need to use NAT devices, which are pervasive in many IPv4 networks and implicitly enforce a filtering policy of “only allowing outgoing communications”. As a result, it has been expected that IPv6 would increase host exposure. However, host exposure can be reduce with the use of network firewalls e.g. at the same point of the network topology where one would employ a NAT device (in an IPv4 network).
Many of the reported IPv6 security issues had to do with vulnerabilities in individual products rather than the IPv6 protocol. IPv4 is widely deployed and individual IPv4 products have gone through the recurring cycle of discovering and fixing security vulnerabilities and other bugs. Many IPv6 products are comparatively newer and have fewer users, and have therefore not benefited from similar experience. As with any Internet product, security vulnerabilities will need to be discovered and repaired for IPv6 products.
Operational practices built up over many years for IPv4 networks are being adapted for IPv6, and this will accelerate as more network operators deploy IPv6 and continue to exchange information about experience and best practices through established operator groups, the IETF, and other forums.
Maintaining network security is a challenging undertaking for both IPv4 and IPv6. Neither protocol provides a simple solution to the complexities associated with securing networks, and network operators should familiarise themselves with IPv6 security practices and stay up-to-date with developments as they deploy and operate IPv6.
IPv6 is a tried and tested technology that has been operationally deployed since 2002.
The core IPv6 specifications have benefited from over 20 years of development within the Internet Engineering Task Force (IETF), and have been implemented in many Internet products and services. IPv6 officially became a standard in 2017 (RFC 8200).
IPv6 also includes a large number of individual standards that have a more limited applicability and are only needed in specialised environments, and as with the continuing evolution of IPv4, there will always be updates and additions to IPv6-related specifications in response to deployment-specific experience.
All major operating systems such as Microsoft Windows, MacOS, Linux, iOS and Android support IPv6, more-and-more software applications are IPv6-ready, and those available on Apple’s App Store must be IPv6 capable. Unfortunately, some products and services (including some from major vendors) do not fully support IPv6, and it is best to check with specific vendors on the readiness of their individual products and services, as well as their migration timeline. In addition, in-house software or custom code that interfaces with the network will likely need updating for IPv6.
If developers and vendors have no plans to support IPv6, then it is advisable to look for alternative products and services. Translation mechanisms such as NAT64 and 464XLAT also exist to support IPv4-only services and applications on IPv6 networks.
Operational practices built up over many years for IPv4 networks will have to be adapted for IPv6. Whilst IPv6 has been successfully deployed in production networks for many years, many network operators still have little or no experience in running IPv6. This situation is improving along with the increasing IPv6 deployment, and as experience and best practices are exchanged through the IETF, operator groups and other forums.
The problem was that transitioning to IPv6 did not offer network operators, enterprises, or vendors any clear advantages in the short term, required some expenditure, and was another protocol to manage when few IPv6 services were available. In addition, the introduction of Network Address Translation (NAT) and Classless Internet Domain Routing (CIDR) greatly extended the IPv4 address space to support many more devices without the need for upgrading or replacing them.
However, the IPv4 address space is now close to depletion, it is no longer possible to easily and cheaply obtain more IPv4 addresses, and the complexity of running NATs is starting to outweigh the costs of deploying IPv6. Many ISPs and content providers also now support IPv6, and so the lack of services running on IPv6 is no longer a disincentive to deployment. IPv6 implementation is necessary and no longer something that organisations can put off until tomorrow.
Yes. IPv6 support was incrementally added to the root servers starting with A, F, H, J, K and M on 4 February 2008. The L root server was added on 12 December 2008, with G being the last on 20 October 2016, meaning all 13 root servers are able to support IPv6 queries and responses.
Around 98% of the TLD (Top-Level Domain) servers also support IPv6, and it is an ICANN requirement for all new TLDs to do so.
The costs of transitioning to IPv6 depend on the nature of the organisation and business. All major operating systems, as well as many software applications and hardware devices are IPv6 ready, allowing organisations to deploy it as part of routine upgrade cycles.
For many organisations, operational costs such as training for network/system operators and adding IPv6 to management databases and documentation are likely to constitute the majority of the cost of upgrading to IPv6. Organisations running in-house customised software will have likely have additional costs to upgrade such software to IPv6, whilst enterprises that have test/release processes will see a marginal additional cost for the IPv6 configuration tests.
End-users should not notice when they are using IPv6 instead of IPv4, so there should be no additional training and documentation costs required for them. However, it may be necessary to provide extra training for help desk staff who are required to troubleshoot end user systems running IPv6.
IPv6 is already supported by many major network operators and content providers, and as more and more deploy IPv6, native IPv6 access will not only become the norm, but more sites will only support IPv6. Whilst translation mechanisms exist that allow access to IPv6-only sites for those that only have IPv4, these have an impact on performance and can be difficult to troubleshoot.
It is also worth considering what services and devices may need to be supported over the next few years. Your existing IPv4 address allocations may be insufficient to support a sudden increase in the number of connected devices, as many organisations experienced with the rapid deployment of IP-enabled wireless handheld products and similar devices a few years ago.
There is no specific date when everything must be upgraded to IPv6, although some organisations, including governments, have already identified target dates for their own IPv6 implementation. IPv6 and its transition mechanisms have been designed for a long period of co-existence with IPv4, and it is expected that IPv4-only systems and applications will survive for many years. However, IPv6-only systems are expected to arise and many of these users are likely to be in emerging business markets and developing countries.
Implementing IPv6 requires planning and with the IPv4 address space nearly exhausted, network operators should already be incorporating IPv6 into their upgrade and procurement plans.
In practical terms, no. There are 2^128 or 340 trillion, trillion, trillion IPv6 addresses, which is more than 100 times the number of atoms on the surface of the Earth. This will be more than sufficient to support trillions of Internet devices for the forseeable future.
Possibly never. The purpose of deploying IPv6 is to ensure network growth and continued interconnectivity when IPv4 address space becomes depleted and difficult to obtain. In addition, as the global Internet continues to expand, it is likely that an increasing number of Internet sites will only be available via IPv6.
To avoid problems, networks and connected devices should be fully IPv6-enabled to take advantage of IPv6-only sites, but IPv4 can co-exist with these until enterprises determine that it is no longer needed or cost effective to maintain. In practice, it may never be cost-effective or possible to upgrade certain legacy systems, but translation mechanisms such as NAT64 and 464XLAT are available to support these for as long as these are required and in use.
No. Both IPv4 and IPv6 will run in parallel until there is no longer any need to do so.
Network Address Translation (NAT) relies on using UDP/TCP port numbers to identify packets sent to one public IPv4 address, but destined for different private IPv4 addresses. These port numbers are 16 bits, which means a theoretical maximum of 65,535 private IPv4 addresses can be associated with each public IPv4 address. In practice though, a host will have multiple simultaneous traffic flows which means it’s impractical to have more than about 4,000 hosts behind one public IPv4 address, and will result in reduced performance and increased management complexity.
Some large ISPs are even running into problems with the IPv4 address space reserved for private addresses, as the largest block (10.x.x.x) is limited to 16.7 million addresses. This then means that multiple layers of NAT are required, which further adds to the performance and management complexity issues.
NAT can also cause problems with certain higher level protocols that were designed for end-to-end connectivity or that employ IP addresses in the application data stream, and so should really only be considered a temporary solution. IPv6 needs to be deployed to ensure the Internet continues to perform well and is able to scale into the future.
Translating addresses does not provide any security benefits. In many cases NATs require an outgoing connection to be present before they will allow an incoming connection to succeed. This ‘stateful packet filtering’ can be enabled for IPv6 by means of an IPv6 firewalls.
You will need to obtain new IPv6 addresses from your Regional Internet Registry (RIR). You can keep any IPv4 address space that you have today, and it can still be used in a dual IPv4-IPv6 environment.
The RIRs all have policies that make it straightforward for an ISP with IPv4 space to apply for and receive IPv6 address space. You should contact the RIR for your region, or alternatively your own Internet connectivity provider for more information on how to acquire IPv6 addresses.
It may also be good idea to use this opportunity to redesign your addressing plan, taking advantage of the greater flexibility of IPv6 to assign subscriber address blocks more optimally. Similarly, customer sites may use IPv6 as an opportunity to redesign and optimise their internal addressing plan.
Plan for IPv6 as you would for any major service upgrade.
Do an audit of your current IPv6 capabilities and readiness. Assess the level of IPv6 technical knowledge within your organisation and make plans for staff development and training to support IPv6 implementation.
Think about which of your services will lose business if they are only accessible to IPv4 users and make them a priority for IPv6 capability. For example, you may plan to implement an IPv6-enabled web server for external customers before converting your internal network.
Remove obstacles to enabling IPv6 including identifying any legacy systems that can not be upgraded, and choose a solution for them. Plan upgrades and purchases so that you don’t find that a key system dependency is not IPv6 capable when you do migrate to IPv6.
Contact your vendors to find out about IPv6 support in their current products and future releases and ask your ISP about their plans to support IPv6.
Use the Deploy360 IPv6 Resources for help along the way.