Although convenient, dual-stack has several inconveniences, including the need for double maintenance (configurations, updates, diagnosis and troubleshooting) and the associated cost with this. As such, other transition mechanisms have begun to evolve, including:

• IPv6-over-IPv4 (6over4, 6rd, 6in4) — These technologies make it easier to try out IPv6 on legacy IPv4 infrastructure or to reach an IPv6 host over an IPv4-only network.

• IPv4-over-IPv6 (DS-Lite, lw4o6, MAP-E, 464XLAT) — Also known as IPv4aaS (IPv4 as a service), its goal is to provide IPv4 connectivity over IPv6-only networks.

IPv4 address space exhaustion is a reality, and it’s only mitigated by a slow but gradual transition to IPv6 and the deployment of NAT444. As such, whatever transition mechanism carriers decide to use, they should aim to eventually deploy an IPv6-only network — something that Lightweight 4over6 (lw4o6) enables.

Introducing Lightweight 4over6

lw4o6 (RFC 7596) is a newly proposed transition mechanism based on a previous mechanism known as Dual-Stack Lite (DS-Lite, RFC 6333) — it borrows some of its concepts and nomenclature.

In DS-Lite, IPv4 compatibility is provided by using a combination of tunnelling technologies and two software components:

• B4 (Basic Bridging Broadband Border) — It runs at the CPE or home router, where it encapsulates IPv4 packets on IPv6.

• AFTR (Address Family Translation Router) — It decapsulates IPv4-in-IPv6 packets arriving from the B4. It also performs a NAT44 on decapsulated packets and annotates the IPv6 address of the home router on the NAT binding table  (useful for the reverse process).

In lw4o6, the B4 and AFTR functions are actually known as lwB4 and lwAFTR.

Figure 1:  

Dual-Stack Light is hard to scale due to how the mapping between IPv4 and IPv6 addresses is per network-flow.

The main issue with DS-Lite is the Network Address Translation (NAT) function that’s deployed at the carriers’ network. Since mapping between IPv4 and IPv6 addresses is per network-flow, DS-Lite is hard to scale. To solve this problem, lw4o6 proposes maintaining the per-subscriber state and moves the NAT function back to the customer premises equipment (CPE).

To enable address sharing among many network subscribers, lw4o6 relies on an architecture known as A+P (Address + Port) sharing. Every CPE is provided with an IPv6 address and an IPv4 address and port range. The NAT function at the CPE maps a customer’s private address to a public address and port within the assigned range. The AFTR at the carrier is going to maintain a binding table that maps the IPv4 addresses plus port range and the IPv6 addresses. If there’s a match, the packet gets decapsulated and it’s forwarded to the Internet.

Figure 2: To enable address sharing among many network subscribers, lw4o6 relies on an architecture known as A+P (Address + Port) sharing.

You can watch a recording of my presentation at RIPE 76, in which I discuss the development of the lwAFTR function through several phases, from prototype to production quality. The solution is completely open-source and runs on commodity hardware (Intel Xeon 10G NICs).

Working with Snabb

The implementation of the lwAFTR function was done using a toolkit called Snabb. This toolkit eases the development of high-performance network functions — it works similarly to other user-space toolkits such as VPP or DPDK. In addition, Snabb features a wide range of network-functions (IPSec, L2VPN, IPFix) and can be used as a standalone application.

Besides the fully-compliant implementation of RFC 7596, this development has brought many improvements to Snabb too. Some of these improvements include:

• Better benchmarking tooling that allows finding the performance peak of a network function.

• A native YANG library implementation, which allows networks to parse and consume YANG models. Until now all Snabb network functions used custom configuration files. Now they can consume standardised YANG models.

• A NETCONF client, to enable querying and modification of Snabb data models from an external program.

• Multiprocess architecture. The lwAFTR runs as a multiprocess program with a leader that manages the data model and one or multiple workers that execute the data-plane.

• Libraries for text streaming and green-threading (fibres).

Many of these improvements have already benefitted Snabb built-in programs and will do so in the future.

Challenges and next steps

The main challenge of building a working implementation of RFC 7596 is performance. Since lw4o6 is a per-subscriber stateful solution, it needs to maintain and consult a rather large binding table. This binds performance to available last-level caches. On the other hand, since lw4o6 is a per-subscriber and not a per-connection solution, it’s easy to scale by deploying new lw4o6 instances that share the same binding table.

We are continuing to work and evolve Snabb’s lw4o6 implementation, largely thanks to the support of DT and Juniper. Recently, we were able to work with country-size binding tables (40 million entries) as well as using RRDTool to plot time travel statistics — you can follow our work on GitHub.

It’s worth mentioning this project was funded by Deutsche Telekom, which is using lw4o6 on its new next-generation network known as Terastream. In an upcoming article, Kostas Zorbadelos from OTE Greece, will share their experience with lw4o6.