IPv6 Introduction
The Internet Protocol version 4 (IPv4) has been the basis for communication on the Internet since 1983. As early as 1990, however, it was foreseeable that the 4.3 billion IP addresses available with IPv4 would be exhausted in the foreseeable future. The Internet Engineering Task Force (IETF) therefore began developing a new generation of the Internet Protocol (IPng), which reached an important step in 1996 with the standardization of the basic protocol as Internet Protocol Version 6 (IPv6).
The development of IPv6 focused on the following requirements
- Extended address space thanks to longer addresses
- More efficient routing and smaller routing tables thanks to simpler merging of networks (route summary, supranetting)
- Faster packet forwarding thanks to less data in the standard header
- Additional routing options thanks to a flow label in the header
- Simpler subnetting as different subnets are hardly necessary and should even be avoided
- Greater security by dispensing with old auxiliary protocols (e.g. ARP)
Since the beginning of 2011, the IPv4 address pool of the IANA (Internet Assigned Numbers Authority, a department of the Internet Corporation for Assigned Names and Numbers, ICANN for short), the organization responsible for managing the Internet, has been exhausted and the regional administrative units (IP registries, e.g. RIPE NCC in Europe) cannot "reorder" IPv4 network areas. At the same time, there is growing pressure from new types of devices (Internet of Things, SmartHome), which also need to be connected to the Internet across the board and often also accessible from outside. Various providers, especially in the cable network, are therefore only providing their end customers with IPv6 addresses natively (DSLite). The connections are then centrally translated to IPv4 at the provider (Carrier Grade NAT, CGN for short). In many cases, it would be simpler if a native IPv6 connection were possible to the desired services. Abroad, especially in Asia with a particular address shortage, customers sometimes only get IPv6 access and no IPv4 at all.
Motivation for the Introduction of IPv6
From a company perspective, many factors are driving the migration to IPv6:
- New technologies, e.g. Microsoft Direct Access, a proprietary VPN-like access solution similar to a remote access VPN, already require IPv6. These technologies cannot be used without the introduction of IPv6.
- Individual systems, especially Microsoft Windows Server, are only fully supported by the manufacturer if IPv6 is at least active. The preference of IPv6 for connection selection can only be changed incompletely or with errors using registry settings. However, the complete deactivation of IPv6 can lead to systems in this form no longer running in a supported configuration.
- Fourth and fifth generation mobile networks (4G, LTE and 5G) are struggling with the IPv4 address shortage due to the large number of users. IPv6 is therefore mandatory for 4th generation networks and later.
- Employees as well as users abroad, especially in Asia, may only have IPv6-only network access when using the (mobile) Internet. The direct use of IPv4-only services is therefore not possible.
- Due to the technological change to "Anything-over-IP", there is a trend towards using the Internet Protocol. Here, too, the large number of systems that will be used in the future, e.g. in the Internet of Things, makes IPv6 use urgently necessary.
- Logical end-to-end accessibility requires all communication partners involved to have a public IP address that is unique on the Internet. This cannot always be guaranteed with IPv4 in the future. In fact, there are already repeated problems and failures with Internet access via cable modem and Carrier Grade NAT (CGN).
- Transition techniques that route IPv6 packets through a tunnel via an IPv4 network can also lead to security deficits if, for example, there are no firewall rules for IPv6 communication. Tunnel protocols must therefore usually either be blocked completely or the additional risks accepted.
IPv6 Introduction
A D-Day, i.e. switching the infrastructure from IPv4 to IPv6 on a fixed date, is practically unfeasible. On the one hand, there are still many services, servers and clients that do not support IPv6, and on the other hand, the introduction is so complex that not everything can be successfully tested on a changeover date. Every company must therefore be prepared to use both IPv4 and IPv6 in parallel over a longer period of several years.
Many central services, e.g. DNS, time synchronization, Active Directory, e-mail, etc. must be offered for both IPv4 clients and IPv6 clients. However, setting up the infrastructure twice is not economically viable, which is why critical systems will have to offer IPv4 and IPv6 in a dual-stack configuration at the same time.
Core to Edge
The term "core to edge" refers to a strategy in which, starting from the "core", i.e. the backbone of the infrastructure, essential services are first expanded to include IPv6 and then other components, servers and finally clients are converted from the inside out.
The aim of the core-to-edge strategy is to make all essential services such as name resolution, time synchronization, mail servers, web servers, file servers and, of course, all network components such as routers, switches and firewalls IPv6-capable in the background before the first clients are converted. This is to ensure that all services that previously worked via IPv4 also run via IPv6 and that clients switching to IPv6 do not encounter problems if IPv6 is preferred by the operating system but individual services do not yet work with IPv6.
The core-to-edge strategy also has the advantage that firewall and network administrators can gain initial experience with IPv6 before IPv6 is rolled out to a larger number of users.
Edge to Core
"Edge to core" refers to a strategy in which the infrastructure is converted from the outside in, i.e. starting with the clients.
An edge-to-core strategy may make sense if the client systems are due for an upgrade anyway and can be configured with IPv6 in addition to IPv4. However, this strategy harbors the risk that essential services are not yet or not yet fully and correctly available via IPv6. As most client operating systems prefer IPv6 when IPv6 is available, there is a risk that previously functioning services will suddenly stop working or that unusual errors will occur from time to time.
Spam filters on mail servers are a typical example. Most mail servers today use various mechanisms to authenticate the sending mail server and to be able to reject spam at an early stage. For example, they check whether the sending mail server has a valid DNS name for reverse lookup, whether the sending mail server is entered as authoritative for the domain in the SPF record, etc. If the changeover of mail delivery takes place before essential services such as DNS have been prepared for IPv6, it can happen that the delivery of emails no longer works for mail servers with IPv6 mail reception, as the spam filter rejects emails delivered via IPv6. For these and similar reasons, the introduction of IPv6 from the outside to the inside has not proved successful.
IPv6 Islands
IPv6 islands arise when individual departments already introduce IPv6, typically to meet customer requirements, although the rest of the company's infrastructure is not yet prepared for this. Such an IPv6 island can be web services that must be offered via IPv6 in addition to IPv4 or video conferencing systems that must also be accessible from Asia, for example, where only IPv6 addresses are available in some cases.
The major disadvantage of IPv6 islands is that often no consistent IPv6 strategy is developed, but the planned IPv6 project must be implemented as quickly as possible. As a result, technologies are often developed and used that are not suitable for the company as a whole. When IPv6 is introduced company-wide at a later date, the IPv6 island must also be migrated again. IPv6 islands can be connected to each other and to the IPv6 Internet using IPsec tunnels, for example, until IPv6 is available everywhere. However, IPv6 islands should be avoided wherever possible.
Our Service
With our many years of experience in the use of IPv6 on all common operating systems, routers and switches, we can put together a customized, detailed concept for the introduction of IPv6. In addition, we offer the necessary knowledge transfer in the form of seminars and workshops to make your employees fit for IPv6.
Of course, we are also happy to help you with the actual introduction of IPv6. We configure and test systems and applications and analyze errors and problems.