How we test IPv6 and transition: dual stack, NAT64, 464XLAT

A router datasheet shows IPv6 as a tick next to IPv4, with one throughput figure for both. On the bench the two protocols often part ways: at small packets, with an extension header, behind an ACL that matches ports, inside a NAT64 gateway that rewrites every header. We look for the point where the fast path hands IPv6 to the CPU.

The bench

The router, L3 switch, firewall, CGNAT or NAT64 gateway goes onto the CloudLAB bench with the software release, ACLs and routing table from production. The generator sends IPv4 and IPv6 from the benchmarking ranges on 1G, 10G or 100G ports (400G and faster per project), counts and timestamps every frame and keeps neighbour discovery live through the whole trial. The device CPU is polled every second out of band, so a punt to software shows in the same trial: throughput drops, the CPU climbs.

For transition the bench plays both sides: IPv6-only clients behind a NAT64 gateway with DNS64, the CLAT side of 464XLAT, the B4 side of DS-Lite with IPv4 inside IPv6 tunnels, MAP-T customer edges, IPv4 servers at the far end. Native forwarding follows RFC 5180, the transition cases follow RFC 8219. The IPv4 to IPv6 ratio comes from your traffic, or in steps of 90/10, 50/50 and 10/90 while the rollout is still a plan.

What we check

• Dual stack: IPv4 and IPv6 throughput and latency per frame size on the same ports, then the mixes; IPv6 switched on must not cost IPv4 a single frame
• Extension headers: each alone, then a chain over 32 bytes from 128 B up, with and without an ACL that matches TCP or UDP ports; hop-by-hop at 1, 10 and 50 % of the rate
• Fragments: fragmented IPv6 through filters and through the translator, and what a dropped ICMPv6 Packet Too Big does to large transfers
• Neighbour discovery: neighbours a port holds before loss starts, and how long thousands of them take to resolve after a link flap
• NAT64 with DNS64: new translations per second, concurrent bindings, throughput per packet size against native IPv6, DNS64 answers per second and their latency
• 464XLAT, DS-Lite, MAP-T: the same numbers for each mechanism in the design, per subscriber and in total, with the overhead per packet size
• Failover: the translator pair switched under load; bindings that survive and how long new flows wait

What usually breaks

The filter. In a typical acceptance a router forwards plain IPv6 at line rate at every frame size. An extension header chain under an ACL that matches TCP ports takes it to about 70 % at 128 B with the CPU near its limit. Without the ACL the same chain costs nothing, because the router never reads it. Production has the ACL.

The translator's slow lane. NAT64 gateways and MAP-T border relays are sized from TCP throughput with large packets. Fragmented UDP, the first packet of every new binding and ICMP errors often go to software. In a typical project fragmented UDP crossed the gateway at about a third of the plain rate.

Path MTU. A filter that drops ICMPv6 Packet Too Big passes every ping and every small request. IPv6 routers do not fragment, so a large transfer through a tunnel or a translator stalls at the first full-size packet.

Neighbour churn. A port with a few thousand hosts holds them in steady state. After a flap the device resolves all of them at once, and in a typical project the last hosts got traffic back several seconds after the first.

What is in the report

Throughput, latency and loss per frame size for IPv4, plain IPv6, each extension header and the chain, with the CPU per trial. Per-protocol numbers inside each mix. Translations per second, bindings and throughput for each transition mechanism, next to native forwarding on the same routing ports. ND scale and recovery after a flap. The configuration, address plan and header sets, so the run repeats on the next release. When the same box also does NAT444, port blocks and logging are in the CGNAT post.

Where to start

Send us the device, the software release and how IPv6 will run: native, dual stack or behind NAT64. We answer with a draft test plan: the items, the bench layout and the dates. The report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.