Skip to content

Methodology · IPv6 benchmarking

RFC 5180: the RFC 2544 tests with traffic that looks like IPv6

RFC 5180 keeps the RFC 2544 suite and adds what IPv6 changes: a 40-byte header instead of 20, extension headers, neighbour discovery instead of ARP, and a router that forwards both protocols at once. Throughput, latency, frame loss, system recovery and reset are measured at 64, 128, 256, 512, 1024, 1280 and 1518 bytes plus jumbo, first with plain IPv6, then with each extension header and a chain of them, then in IPv4/IPv6 mixes from 90/10 to 10/90. Trials last 60 seconds, traffic flows both ways. This page shows the method as we apply it in CloudLAB and what the report contains.

  • Seven Ethernet frame sizes from 64 to 1518 B plus jumbo; the 40-byte IPv6 header leaves less room in a small frame than IPv4 does
  • Every test with plain IPv6, with single extension headers and with a chain over 32 bytes, next to an IPv4 baseline on the same ports
  • Report per frame size, header set and traffic mix, with CPU load read out of band and the capture behind each row
Request a test plan See the tests
THROUGHPUT BY FRAME SIZE 10 GbE · ACL ON UPLINK PLAIN IPv6 EXTENSION HEADER CHAIN · §5.3 BELOW 90% 100% 50% n/a 71 88 64 B 128 B 256 B 512 B 1024 B 1280 B 1518 B 9216 B Same ports, same ACL: the header chain costs 29% at 128 B

One router, one IPv6 ACL on the uplink. Plain IPv6 is forwarded at line rate at every frame size. With the extension header chain the ACL has to walk the headers to reach the port numbers: 71% at 128 B, 88% at 256 B, line rate from 1024 B. At 64 B the chain does not fit. Values are illustrative.

Where it fits

When RFC 5180 is the right method

RFC 2544 was written for IPv4. A device that forwards IPv4 at line rate can fall short on IPv6 at small frames, and the datasheet rarely says so. RFC 5180 is how that gap gets a number.

Router and switch selection

Before buying a core router, L3 switch or firewall for a dual-stack network: the same suite on each candidate, IPv4 and IPv6 at the same frame sizes, so the difference between them is measured, not a footnote

IPv6 rollout on existing gear

Before enabling IPv6 on a platform that carries IPv4 production: does IPv4 keep its rate when 10%, 50% or 90% of the traffic is IPv6, and do the ACLs still hold

Release and policy acceptance

After a software upgrade or a new ACL policy: the extension header and filter trials show whether IPv6 stays in hardware or goes to the CPU

Test bed

Two test ports, one device, both protocols

The generator sends IPv6 and IPv4 streams from addresses in the benchmarking range, the device forwards them, the second port counts and times every frame. Neighbour discovery stays live through the whole trial.

TEST PORT A · SOURCE GENERATOR PORT · ADDRESSES FROM 2001:2::/48 STREAMS, PER FRAME SIZE Plain IPv6, then each extension header Chain: routing, destination options, fragment IPv4 only, IPv6 only, 90/10, 50/50, 10/90 Sequence number and timestamp in every frame 60 s PER TRIAL · BINARY SEARCH 1G · 10G · 100G IPv6 + IPv4 FRAMES DEVICE UNDER TEST ROUTER · L3 SWITCH · FIREWALL · NAT64 ND CACHE LOOKUP HEADERS DYNAMIC ND /48 /64 /126 /128 CHAIN WALK HARDWARE PATH OR PUNTED TO THE CPU filters with 1 or 25 entries, matched on TCP and UDP IPv6 MUST NOT COST IPv4 FORWARDING 2001:2::/48 /126 OR /64 DYNAMIC ND IPv4 · IPv6 BOTH DIRECTIONS CPU OUT OF BAND 1G · 10G · 100G COUNTED · TIMED TEST PORT B · SINK SAME INSTRUMENT · ONE CLOCK FOR LATENCY COUNTED PER STREAM Received against sent, per header set Latency per frame size at the throughput rate Out-of-order and duplicate frames flagged Neighbour cache kept alive, no NS storms SENT − RECEIVED = LOST IPv4 BASELINE FIRST IPv4 only on the same ports and frame sizes, then plain IPv6, then headers and mixes · every IPv6 number sits next to its IPv4 twin

Traffic generator

Hardware generator ports at 1, 10 and 100 GbE in CloudLAB, chosen for the device and the rate, with no default vendor. Each frame carries a sequence number and a timestamp. That signature sets the smallest frame the tool can send, and the report states it.

Device under test

Router, L3 switch, firewall in forwarding mode, CGNAT or NAT64 gateway. Configured as in production: the same software release, ACLs and routing table size, interface addresses ending in ::1 on /126 or /64 prefixes.

Traffic profile

Bidirectional streams, one address pair first, then random destinations across the range. Plain IPv6, single extension headers, the chain and IPv4/IPv6 mixes, each at every frame size in the plan.

The CPU is read on its own wire

RFC 5180 asks for CPU and memory data to be collected out of band, never through the ports that carry test traffic. We poll the device over a separate management network every second. That is how a punt to the software path shows up: throughput drops and the CPU climbs in the same trial.

Test conditions

What RFC 5180 fixes and what we agree

Frame sizes, header sets and traffic mixes come from the RFC. Scale, filters and transition mechanisms come from your network. Both go into the plan before the first trial.

Parameter RFC 5180 Typical range Why it matters
Frame sizes64, 128, 256, 512, 1024, 1280, 1518 B (§5.1.1)Plus 1522 B tagged; 9216 B jumbo where supportedSmall frames show the per-packet cost; the IPv6 header is 40 B against 20 B for IPv4
Smallest frame with headersOne common smallest size for plain and header traffic (§5.3)128 B with the default chainA chain over 32 B does not fit in 64 B, so the comparison starts where both fit
Extension headersEach alone, then routing, destination options and fragment in a chain over 32 B (§5.3)8 to 48 B per packetMost routers skip them; a filter on TCP or UDP ports has to walk the chain
Hop-by-hop headerOffered at 1%, 10% and 50% of the interface rate, resources watched (§5.3)CPU and memory sampled every secondEvery router has to process it, so the result is the impact on the device, not a throughput
IPv4/IPv6 mixIPv4 only, IPv6 only, then 90/10, 50/50 and 10/90 (§7)Same total rate and frame sizesEnabling IPv6 must not cost IPv4 forwarding
Addresses and prefixes2001:2::/48 range; DUT prefixes /126, or /64 and shorter (§5.2)Destination prefixes /48, /64, /126, /128Lookup cost depends on prefix length; a single /64 hides it
Neighbour discoveryDynamic ND preferred, endpoints one hop beyond the DUT (§4)1 to 16,000 neighbours as agreedAn expired cache turns forwarding into address resolution, and loss follows
Filters1 and 25 entries with upper-layer matching (§6.2)10, 100 or 1,000 entries as agreedMatching on TCP or UDP forces the chain walk; this is where IPv6 rates drop

Line rate on 10 GbE does not depend on the IP version: 14.88 Mfps at 64 B, 8.45 Mfps at 128 B, 0.81 Mfps at 1518 B. What changes with IPv6 is how much of each frame the device has to read before it can forward it

Always in our runs

  • Plain IPv6 first, then each extension header, then the chain (§5.3)
  • One common smallest frame size for plain and header traffic (§5.3)
  • Traffic in both directions; one direction only on asymmetric devices (§5.4)
  • CPU and memory read out of band, never through the test ports (§4)
  • Addresses from the 2001:2::/48 benchmarking range (§8)
  • The suite clean first, then under each modifier on its own (§6)

These six hold in every project. They make an IPv6 result comparable with the IPv4 one next to it and with the next device on the bench.

Agreed per project

  • Jumbo frames of 4096, 8192 or 9216 B where the device takes them
  • Neighbour cache scale from 256 to 16,000 entries
  • IPv6 ACLs of 10, 100 and 1,000 entries beyond the RFC's 1 and 25
  • 6in4, 4in6, NAT64 with DNS64, per RFC 8219
  • IPv6 multicast with MLD, per RFC 3918
  • Back-to-back frames, dropped by RFC 5180, on request

Scale, filters, transition and multicast go into the plan per project. Defaults: 10 GbE, the seven Ethernet sizes, plain IPv6, the chain, the three mixes, 60-second trials, three repeats per point.

The tests

Eight blocks, from address plan to coexistence

Two preparation blocks fix the addresses and the header sets. Five tests come from RFC 2544, each with plain IPv6, single headers and the chain. The last block puts IPv4 and IPv6 on the same ports.

  1. 5.2Preparation

    Address plan and neighbours

    Source and destination addresses from the 2001:2::/48 benchmarking range, split between input and output ports. DUT prefixes /126 or /64, destination prefixes /48, /64, /126 and /128. Neighbour discovery runs live, endpoints one hop behind the device.

    Output: address plan, prefix set, ND state per port
  2. 5.3Preparation

    Extension header sets

    Each header alone: hop-by-hop, destination options, routing, fragment, authentication. Then the chain RFC 5180 recommends: routing, destination options and fragment, over 32 bytes. Hop-by-hop goes at 1%, 10% and 50% of the rate, because every router has to process it.

    Output: header sets and the smallest frame each fits in
  3. 7.1RFC 2544 test

    Throughput

    The highest rate with zero frames lost, found by binary search in 60-second trials, per frame size and header set. RFC 5180 keeps the RFC 2544 procedure; what changes is the traffic.

    Output: frames/s and % of line rate, per size and header set
  4. 7.2RFC 2544 test

    Latency

    Measured at the throughput rate for each frame size, plain and with headers. A gap that grows with the chain points at the software path, even while throughput holds.

    Output: latency per frame size, minimum, average, maximum
  5. 7.3RFC 2544 test

    Frame loss rate

    Loss over the range of offered rates, from line rate down in 10% steps until two steps in a row lose nothing. Shows how the device degrades above its throughput, not only where it stops.

    Output: loss % per offered rate and frame size
  6. 7.5RFC 2544 test

    System recovery

    Overload at 110% of the throughput rate for 60 seconds, then the rate drops to half. The time until frames pass again without loss is the recovery time.

    Output: recovery time per frame size, IPv4 and IPv6
  7. 7.6RFC 2544 test

    Reset

    Hardware reset, software reset and power interruption with traffic at the throughput rate. Measured from the last frame before the reset to the first one after it.

    Output: outage per reset type
  8. 7Coexistence

    IPv4 and IPv6 coexistence

    IPv4 only, IPv6 only, then mixes of 90/10, 50/50 and 10/90 on the same ports and frame sizes, with throughput and latency per protocol inside each mix. The point RFC 5180 makes: IPv6 switched on must not cost IPv4.

    Output: per-protocol throughput in each mix

Procedure

From address plan to signed report

Five steps, each with a check before the next one starts. IPv4 and plain IPv6 first, headers and mixes after, so every difference has a baseline to stand against.

  1. 00

    Agree the device, the role and the matrix

    Which device and release, which interfaces, how IPv6 will be used: native, dual stack or behind NAT64. Frame sizes, header sets, mixes and filters are fixed in the plan

  2. 01

    Address plan and neighbours

    Addresses from 2001:2::/48, interface IDs ::1, /126 or /64 on the device, destination prefixes from /48 to /128. Neighbour caches filled and stable before the first trial

  3. 02

    IPv4 and plain IPv6 baseline

    Throughput, latency and frame loss at every frame size, IPv4 only and IPv6 only, both directions. Any gap between the two is already a finding

  4. 03

    Extension headers

    Each header alone, then the chain, from the common smallest frame size up. Hop-by-hop at 1%, 10% and 50% of the rate with the CPU watched out of band

  5. 04

    Mixes, modifiers, recovery

    The three IPv4/IPv6 mixes, filters with 1 and 25 entries, management and routing traffic on, then system recovery and reset. The report is drafted while the bench is still up

FOUR CONDITIONS, ONE ROUTER · RFC 5180 §5.3 AND §7 10 GbE · 128 B · 60 s TRIALS · BOTH DIRECTIONS PLAIN IPv6 no extension headers · ACL on the port THROUGHPUT, 128 B LATENCY, 128 B CPU, OUT OF BAND 100% 4.2 µs 11% HARDWARE PATH · BASELINE ONE HEADER destination options, 8 B · no ACL THROUGHPUT, 128 B LATENCY, 128 B CPU, OUT OF BAND 100% 4.3 µs 11% HEADER NOT READ · SAME AS PLAIN CHAIN UNDER AN ACL routing, options, fragment · TCP ACL THROUGHPUT, 128 B LATENCY, 128 B CPU, OUT OF BAND 71% 38 µs 96% PUNTED TO THE CPU · TO THE VENDOR DUAL STACK 50/50 IPv4 and plain IPv6 · ACL on the port THROUGHPUT, 128 B LATENCY, 128 B CPU, OUT OF BAND 100% 4.4 µs 13% IPv4 HOLDS LINE RATE · ACCEPT THROUGHPUT DOWN AND CPU UP = SOFTWARE PATH ONE HEADER, NO FILTER = NOTHING TO READ, NO COST BOTH PROTOCOLS AT LINE RATE IN THE MIX = ACCEPT

One router, four conditions at 128 B. A single extension header without a filter costs nothing: the router does not read it. The chain under an ACL that matches TCP ports drops to 71% with the CPU near its limit. The 50/50 mix holds both protocols at line rate. Only the full matrix shows which case your network will hit.

4 checks a point must pass before it goes into the report

  • 0 loss

    Throughput is the highest rate with zero frames lost over the whole 60-second trial. One lost frame and the search steps down.

  • ND = 100%

    Every neighbour resolved and reachable for the whole trial. A trial with neighbour solicitation storms measures address resolution, not forwarding, and is repeated.

  • 3 trials

    Each point repeated three times; the spread goes into the report. A point that does not repeat is investigated before it is published.

  • IPv4 first

    The IPv4 baseline on the same ports and frame sizes comes before any IPv6 or mix trial. Without it a mix result has nothing to compare against.

Anatomy of one trial

  • Neighbours, secondsNeighbour caches refreshed on both test ports, streams and header set loaded, CPU poll started
  • Learning, 2 sLow-rate frames so the device has every route and neighbour in place before counting starts
  • Trial, 60 sTraffic at the rate under test, both directions, every frame counted and timed
  • Settle, 2 sLate frames counted, counters read on the device, CPU sample and capture saved with the trial

Report

What the report contains

Every number with the frame size, header set, traffic mix and software release it was taken at, so a later run on the next release or the next device compares line by line

Measured values

  • Throughput per frame size for IPv4, plain IPv6, each extension header and the chain, in frames/s and % of line rate
  • Latency at the throughput rate per frame size and header set
  • Frame loss per offered rate, as a curve per frame size
  • Hop-by-hop impact at 1%, 10% and 50% of the rate: CPU, memory, loss on other traffic
  • Throughput per protocol in each IPv4/IPv6 mix
  • System recovery and reset times, IPv4 and IPv6

Context, so the run can be repeated

  • Device: model, software release, licences, configuration export
  • Address plan: prefixes, interface IDs, destination prefix lengths
  • Neighbour discovery mode, timers and neighbour count
  • Header sets with their lengths, the common smallest frame size
  • Filters: entry count, match fields; management and routing traffic on or off
  • Generator: type, port speed, signature size, trial length, repeats
RFC 5180 · TEST REPORT 10 GbE · 60 s TRIALS 5.1.1Frame sizes, Ethernet 7.1Throughput, IPv4 only, 128 B 7.1Throughput, plain IPv6, 128 B 7.1Throughput, chain + ACL, 128 B 7.2Latency, plain IPv6, 1518 B 5.3Hop-by-hop at 10% of the rate 7Mix 50/50, 128 B, per protocol 7.5System recovery, plain IPv6 7 + 9216 100% 100% 71% 5.1 µs CPU 34% 100% 1.6 s 64 to 1518 B · jumbo where the device takes it binary search · 60 s trials · 3 repeats 8.45 Mfps · both directions CPU 96% out of band · punted to software min 4.8 · max 5.6 µs at the throughput rate no loss on other traffic at 1% and 10% IPv4 and IPv6 both at line rate 110% of throughput for 60 s, then 50% ATTACHED CONFIG EXPORT PCAP PER TRIAL CPU GRAPH PER-TRIAL CSV Values are illustrative. Your report carries your numbers, per frame size, header set and mix.

What we add on top

  • Captures of the failed and boundary trials, so the vendor can reproduce each finding
  • CPU and memory graphs from the out-of-band poll, aligned with the trial timeline
  • Per-trial table in CSV for your own analysis

From practice

A dual-stack core router: line rate on IPv4, 71% on IPv6

A typical case. An operator picks a core router for a dual-stack backbone. The datasheet promises line rate, and the IPv4 RFC 2544 run confirms it at every frame size. RFC 5180 on the same ports: plain IPv6 also at line rate. With the extension header chain and the uplink ACL in place, throughput at 128 B, the smallest frame the chain fits in, falls to 71%, and the out-of-band CPU graph climbs to 96% in the same trials. Every packet with extension headers went to the CPU, which walked the chain for the ACL.

The vendor reproduced it from our captures, and the next software release parsed the chain in hardware. The rerun on that release: line rate at every frame size, header set and mix, with the CPU flat. The router went into the network on that release, not on the one in the tender.

IPv6 at line rate is a claim until the headers are in the frame

SAME ROUTER · 10 GbE · 128 B · ACL ON THE UPLINK IPv4 · RFC 2544 BASELINE line rate at every frame size, CPU 9% 100% IPv6 + HEADER CHAIN · SHIPPED RELEASE 71% of line rate, CPU 96%: the chain walked in software 71% IPv6 + HEADER CHAIN · NEXT RELEASE line rate, CPU 12%: the chain parsed in hardware 100% Reproduced by the vendor from our captures, fixed in the next release.

What we run

RFC 5180 in CloudLAB

Four ways the method is used. Each ends with the same report: IPv4 and IPv6 numbers side by side, the captures, and the diagnosis where a point fails

Device selection, dual stack

The same RFC 5180 matrix on every candidate, IPv4 baseline included, so the comparison goes per frame size and header set, not per datasheet

Request a test plan

IPv6 rollout check

Your device, release, ACLs and routing table size. Shows whether IPv4 keeps its rate once IPv6 is on, and where IPv6 leaves the hardware path.

Discuss your rollout

Release acceptance

The extension header, filter and mix trials repeated on each new software release and compared line by line with the last report

Plan a regression check

Bench access in CloudLAB

Test ports at 1G, 10G and 100G, the device on a remote bench, our engineer on the call. You see every trial as it happens.

Log in to CloudLAB
  • Independent: we sell the test, not the router, the licence or the circuit
  • IPv4 and IPv6 on the same ports, the same frame sizes, the same day
  • Captures and CPU graphs attached, so every finding can be reproduced

Read next

FAQ

Questions we get before an RFC 5180 project

How is RFC 5180 different from RFC 2544?

RFC 5180 keeps the RFC 2544 tests and procedures and changes the traffic: IPv6 addresses from a benchmarking range, frame sizes that account for the 40-byte header, extension headers alone and in a chain, and IPv4/IPv6 mixes. It drops the back-to-back test because of its variance. Anything it does not cover falls back to RFC 2544.

Why does 64 bytes stay in the frame size list?

Small frames show the per-packet cost of a device, and 64 B is where that cost peaks. An IPv6 frame carries a 40-byte header instead of 20, so less room is left for the test signature, and some generators cannot go that low. RFC 5180 notes this, and our report states the smallest size the generator actually sent. Extension headers do not fit at 64 B at all, so header trials start from a common smallest size, usually 128 B.

Why test extension headers if most traffic has none?

Most routers forward a packet with extension headers without reading them, and then they cost nothing. The cost appears when something has to look past them: an ACL that matches TCP or UDP ports, a firewall policy, a NAT64 gateway. Then the device walks the chain, and on some platforms that walk happens in software. RFC 5180 asks for header trials for this reason.

Which devices do you test with RFC 5180?

Routers, L3 switches, firewalls in forwarding mode, CGNAT and NAT64 gateways. For NAT64 with DNS64, 6in4 and 4in6 tunnels we add the transition tests of RFC 8219, since RFC 5180 covers native IPv6 forwarding.

Is multicast part of RFC 5180?

No. RFC 5180 leaves IPv6 multicast out of scope. When multicast matters, MLD joins and multicast forwarding go into the plan as a separate block per RFC 3918, on the same bench and in the same report.

How long does an RFC 5180 project take?

The test plan is ready 1 to 3 business days after we have the device details. Bench time is 1 to 3 days: one for the IPv4 and plain IPv6 baseline, more for the full header and mix matrix, filters and transition tests.

Measure what IPv6 costs your device

Send the device, the software release, the interfaces and how IPv6 will be used: native, dual stack or behind NAT64. You get an RFC 5180 test plan back in 1 to 3 business days: tests, frame sizes, header sets, mixes, bench days and the quote. Test. Compare. Decide.

Request a test plan Log in to CloudLAB

Send the shortlist

You have the method. Now get the numbers.

Name the models and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.

Prefer to chat? Message an engineer on WhatsApp

We use what you send only to answer you. See our Privacy Policy.