With emerging technologies such as 5G, IoT, streaming platforms and game consoles, we need to be vigilant so that we can support applications in a way that allows providing high-quality Internet access to end users. To serve this vast number of hosts, we must consider the use of the IPv6 protocol in new projects so that business growth prospects will not be affected. To minimize potential errors and consequently project failure, the entire infrastructure must be properly planned from the beginning. Below I will share four steps or main topics that will help us avoid these mistakes and achieve greater success in future network projects, whether at ISP, university, corporate, or government level.
1 – The IPv4 mindset
A common error among professionals is that they maintain some habits and practices while still thinking in terms of the IPv4 protocol. An example of this is the use of ICMP message blocks or packet filtering firewalls. While in the past some professionals used these blocks in the belief that they would keep their network safe (something that is not true), thanks to the IPv6 protocol, today we can no longer do this as we depend on ICMPv6 for the protocol and its neighbor discovery protocol (NDP) announcements to work.
(Free access, no subscription required)
We must understand that, today, with IPv6, we no longer assign an IP address, but an entire /64 network or more, and we don’t need to worry about the scarcity of addresses as we did in the past (economy of IPv4 addresses) — IPv6 addresses will last for hundreds of years. This change in mindset is very important, as some are still afraid that they are wasting IPv6 resources and will end up having to perform NAT on IPv6 addresses.
Choosing the method used to assign IPv6 addresses to hosts is essential, as DHCPv6 does not configure the default gateway and we must combine it with other techniques such as SLAAC. We need to understand that the main purpose of DHCP/DHCPv6 is assigning the hosts’ IP addresses and other configuration parameters, yet many use this service as a way to create records (logs) for their users.
2 – Not involving our systems development teams
We must understand that, today, with IPv6, we no longer assign an IP address, but an entire /64 network or more, and we don’t need to worry about the scarcity of addresses as we did in the past (economy of IPv4 addresses) — IPv6 addresses will last for hundreds of years. This change in mindset is very important, as some are still afraid that they are wasting IPv6 resources and will end up having to perform NAT on IPv6 addresses.
Choosing the method used to assign IPv6 addresses to hosts is essential, as DHCPv6 does not configure the default gateway and we must combine it with other techniques such as SLAAC. We need to understand that the main purpose of DHCP/DHCPv6 is assigning the hosts’ IP addresses and other configuration parameters, yet many use this service as a way to create records (logs) for their users.
2 – Not involving our systems development teams
The use of new services and applications must consider their compatibility with the IPv6 protocol. With ISPs assigning more and more IPv6 addresses, most still in dual-stack mode, users now connect to basic web services, email, DNS and most likely also to smartphone apps using IPv6. Thus, involving the entire systems development team and helping them understand the new network protocols is extremely important so that the code of new applications can handle addresses longer than the 32 bits allowed by IPv4, for example, in a database.
A simple example would be to make a habit of having the applications’ bind socket (Apache, Nginx, Tomcat, MySQL, PostgreSQL) at the ::1 address (localhost) so that our datacenter services will be prepared for an IPv6-only scenario and the elimination of IPv4 from our network.
Tomcat (server.xml) and PostgreSQL (database.yml) configuration files
Keep in mind that new products that offer audit reports, network monitoring, and access restrictions must consider IPv6 addresses in their development. In this sense, the DevOps movement is considered the key for breaking the barrier of 40% global IPv6 adoption we reached in 2022.
One of the biggest mistakes is to consider disabling IPv6 on a network. Despite the false sense of relief provided by the possible solution of a network or application error, this delays the mitigation of the problem even further.
Operating systems and major browsers prefer IPv6 connections through Happy Eyeballs (RFC 8305). Thus, the degradation of IPv6 traffic or any routing issues are perceived by users and can slow down Internet access in general. As a result, the number of complaints may increase, and users may finally give up and disable IPv6 on their hosts. Therefore, in addition to providing IPv6, an essential function of ISPs is to monitor and manage the dual-stack network so that this does not become a common practice and negatively affects IPv6 adoption.
We must also fight the fake news currently circulating in relation to IPv6, for example, that disabling IPv6 can speed up a network or that disabling IPv6 better protects a VPN. These conceptual errors make it very difficult to increase the speed of the transition to IPv6, so we need to create awareness about this.
4 – Ignoring IPv6
Finally, we should avoid dismissing concerns about or ignoring IPv6 on our network based on the notion that it is merely a fad. We should be aware that IPv6 is already present on our networks in some way, for example, through the ULA addresses of network interfaces, and even more serious is the fact that we may still not have noticed this.
By not monitoring or managing our network, 6to4 tunnels may be being created on Windows operating systems, causing us to have IPv6 traffic even if we still do not admit that we do. This may create a poor browsing experience for users who go through different paths, causing serious security problems, as our access controls and firewalls may not be dealing with such traffic.
Example of automatic 6to4 tunneling on Windows
In view of the above, the best way to solve this problem is to convince ourselves that IPv6 is a protocol that should be considered and enabled on our networks. However, if enabling IPv6 on your network is not yet in your plans, automatic tunnels can be dealt with easily (protocol 41) by managing group policies in a network on Active Directory in order to minimize the problem.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
