While IPv6 was standardized in 1998 and its deployment is progressing to overcome the depletion of the pool of IPv4 addresses, the way IP addresses are used today remains identical to the early days of the Internet.
In our recent paper, my fellow researchers from the ICTEAM at UCLouvain and ICube at the University of Strasbourg and I argue that several changes in the Internet infrastructure in the last decade combined with the large addressing space of IPv6 enables opportunities in privacy, mobility, server performance, multihoming, segment routing, differentiated routing and multicast.
During the last decade, applications and transport protocols became further decoupled from the network layer. Firstly, multipath transport protocols such as SCTP, MPTCP, QUIC and MPQUIC are able to use several network paths in the same transport connection. Secondly, applications leverage TLS to secure their communications and rarely use IP addresses to authenticate their users and services. These two can be combined to reconsider the semantics of IPv6 addresses further than simply identifying a network interface.
In this post, we will explore the roles that IPv6 addresses can play to improve the load-balancing and performance of servers as well as solve the multihoming problem in a more efficient and scalable way.
Multicore dataplane
Over the last decade, servers have also greatly evolved and now reach hundreds of CPU cores. Today, when the network card has a single IP address, incoming traffic is spread between the cores using techniques such as RSS that hashes the 4-tuple of incoming packets to assign a CPU core to each flow. This represents an additional burden on the NIC and CPUs, but can also lead to a high load imbalance. Using IPv6, one IPv6 address can be assigned per CPU core. Then the NIC can forward packets directly to the right CPU core without requiring them to go through dispatching CPU cores first.
Figure 1 illustrates the throughput of a modified QUIC implementation using the Data Plane Development Kit (DPDK) and two variants of IPv6 usage in our test bed when serving 128 clients. First, the Single IP variant represents the usage of a single server IPv6 address as widely used on the Internet today. In this case, the server uses RSS to dispatch packets to cores.
Second, the One IP per core variant represents our usage of one IPv6 address per core. In this case, the clients use the DNS to randomly select one of the IPv6 addresses. When incoming packets arrive at the server NIC, it simply addresses them at their corresponding core. We can observe that with eight CPU cores, the throughput can be increased by 25%.
Multihoming with Provider-Aggregatable IPv6 addresses
The growth of the Internet is also reflected in the growth of Autonomous Systems (ASes). Today, a BGP router can interact with more than 70k ASes and has to process a million routes towards the prefixes that they announce. While most networks are usually first connected to the Internet through a single provider, many enterprise and organization networks are becoming multihomed. To achieve this, they obtain an AS number and use BGP to advertise their own prefix to the global Internet. This approach is not scalable as it contributes to the growth of BGP routing tables.
IPv6 enables us to reconsider this problem. Let us consider Figure 2, which depicts an enterprise network becoming multihomed using two providers. With IPv6, the network obtains one Provider-Aggregatable IPv6 prefix from each of its providers. It does not need to become an AS or use BGP. It also enables hosts to use different interdomain paths to communicate.
Figure 2 illustrates two such paths between a client in the enterprise network and a server connected to AS5. Multipath transport protocols can select the best-performing one given some application requirements and use the two paths simultaneously. They also improve the resiliency of hosts, as when a link fails, for instance, the link towards AS2, the multipath transport connection can continue via AS3.
Switching from BGP to host-based multihoming would also greatly reduce the number of BGP messages coming from stub ASes, as the ASes solely existing for multihoming purposes could disappear. From a security perspective, this could also improve the relative adoption of RPKI, as stub ASes have a lower RPKI adoption than transit ASes.
Learn more
If you’re interested in reading more on how IPv6 enables opportunities in privacy, mobility, segment routing, differentiated routing and multicast, please refer to our article published in the July 2022 issue of the ACM SIGCOMM Computer Communication Review.
Maxime Piraux is a PhD student and computer networks researcher at UCLouvain.
Adapted from the original post at NCS UCLouvain.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Insightful contribution. In my view, it represents a strategic roadmap towards the resolution of some of the endemic challenges of effective and secured Network functionality and data protection.
Warm regards,
Chris
Due to absence of NAT and essentially unlimited public addresses, we can now deploy fully decentralized messaging – directly from any IPv6 node to any other IPv6 node – no need for intermediary servers. It is even possible to implement “PeerTLS” between two such nodes for real end-to-end encryption and strong mutual authentication (both nodes use client certs). This will require a nextgen secure address registry to scale to billions of highly mobile nodes.