--- title: RFC 5180 IPv6 benchmarking methodology | TEST4NET description: "RFC 5180 in CloudLAB: the RFC 2544 tests with IPv6 at 64 to 1518 B, extension headers, IPv4/IPv6 mixes and ACLs, next to an IPv4 baseline" image: https://test4net.com/hubfs/og/methodologies-rfc-5180.png --- [Skip to content](https://test4net.com/methodologies/rfc-5180#main-content) [![TEST4NET](https://test4net.com/hubfs/test4net-logo-fixed-2.svg)](https://test4net.com/?hsLang=en) - Services - Products - Resources - Company [News](https://test4net.com/news?hsLang=en) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=en) What we test By technology Industries [Load & Performance Testing Throughput, sessions and latency up to and past the rated limit](https://test4net.com/services/load-performance-testing?hsLang=en) [Functional & Conformance Testing Features against the spec, RFC compliance with evidence](https://test4net.com/services/functional-conformance-testing?hsLang=en) [Interoperability Testing Multi-vendor behaviour, before it reaches production](https://test4net.com/services/interoperability-testing?hsLang=en) [Security & Resilience Testing NGFW, IPS and VPN efficacy and performance with threats on the wire](https://test4net.com/services/security-resilience-testing?hsLang=en) [Test Plan & Methodology Design What to test, how, and what counts as a pass](https://test4net.com/services/test-plan-design?hsLang=en) [Test Automation & CI/CD Regression suites wired into your release pipeline](https://test4net.com/services/test-automation?hsLang=en) [Training Programs Hands-on courses for your test engineers](https://test4net.com/services#training) [Equipment Repair Diagnostics and repair of test equipment](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=en) [Routing & Switching RFC 2544 and RFC 2889 on real ports, 1G to 100G](https://test4net.com/solutions/routing-switching?hsLang=en) [Firewalls & NGFW RFC 9411 throughput with inspection switched on](https://test4net.com/solutions/firewalls-ngfw?hsLang=en) [SD-WAN & WAN Path selection and QoS under emulated WAN conditions](https://test4net.com/solutions/sd-wan?hsLang=en) [Cloud & NFV Virtual appliances and cloud services under load](https://test4net.com/solutions/cloud-nfv?hsLang=en) [5G & Mobile Core Transport and core functions under subscriber traffic](https://test4net.com/solutions/5g-mobile-core?hsLang=en) [Wi-Fi Wi-Fi 6 clients and access points, Wi-Fi 7 in progress](https://test4net.com/solutions/wi-fi?hsLang=en) [Storage & Infrastructure Storage networks and servers under realistic I/O](https://test4net.com/solutions/storage?hsLang=en) [AI / Switching Fabric (RoCEv2) Lossless Ethernet for GPU clusters: PFC, ECN, fabric load](https://test4net.com/solutions/ai-fabric-rocev2?hsLang=en) [All technologies](https://test4net.com/services#coverage) [Telecom Operators Pre-deployment acceptance and vendor comparison](https://test4net.com/solutions/industries#telecom) [Network & Security Vendors Independent validation of your product claims](https://test4net.com/solutions/industries#vendors) [System Integrators Proof for the customer before the rollout](https://test4net.com/solutions/industries#integrators) [Enterprise & Banks Upgrades and new platforms checked before production](https://test4net.com/solutions/industries#enterprise) [All industries](https://test4net.com/solutions/industries?hsLang=en) Not sure where to start? Test plan and quote in 1–3 business days Tell us what you run and what worries you. We propose the tests, tools and timeline. [Request a test plan](https://test4net.com/contacts?hsLang=en) CloudLAB [How It Works Pick a scenario, run it in the live lab, get the report](https://test4net.com/cloudlab#how) [Equipment & Capabilities L2-3 to 100G, L4-7 past 200G, Wi-Fi, WAN emulation](https://test4net.com/cloudlab#equipment) [Access Plans Hourly sessions, subscriptions, dedicated racks](https://test4net.com/cloudlab/plans?hsLang=en) [Hosted DUT Testing Ship the box or upload the VM, we run the tests](https://test4net.com/cloudlab/hosted-dut?hsLang=en) [Open the CloudLAB portal](https://lab.test4net.com) Our tools [Traffic Generator L4-7 and security traffic past 200 Gbit/s, app mix library](https://test4net.com/products/traffic-generator?hsLang=en) [WANemu Delay, jitter, loss and bandwidth shaping per link](https://test4net.com/products/wanemu?hsLang=en) [Book a demo](https://test4net.com/contacts?hsLang=en) New: our own test tools Our own tools, in beta this autumn Built in our lab, priced per gigabit. Join the beta list and see them first. [Join the beta list](https://test4net.com/products#lead-form) Read Technologies / Protocols Methodologies [Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=en) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=en) [FAQ How the lab, sessions and reports work](https://test4net.com/faq?hsLang=en) [All resources](https://test4net.com/resources?hsLang=en) [BGP Route exchange, policy and convergence](https://test4net.com/blog/how-we-test-bgp?hsLang=en) [OSPF & IS-IS IGP adjacency, flooding and SPF timing](https://test4net.com/blog/how-we-test-ospf-is-is?hsLang=en) [MPLS & SR LDP, RSVP‑TE and SR‑MPLS label paths](https://test4net.com/blog/how-we-test-mpls-and-segment-routing?hsLang=en) [EVPN / VXLAN Overlay fabrics, MAC/IP routes, multi-homing](https://test4net.com/blog/how-we-test-evpn-vxlan?hsLang=en) [IPsec & IKEv2 Tunnel setup, rekeying and throughput](https://test4net.com/blog/how-we-test-ipsec-and-ikev2?hsLang=en) [TLS / HTTPS Handshakes, cipher suites and inspection](https://test4net.com/blog/how-we-test-tls-and-https?hsLang=en) [RoCEv2 Lossless Ethernet, PFC and ECN for AI fabrics](https://test4net.com/blog/how-we-test-rocev2?hsLang=en) [Wi-Fi 6 / 6E / 7 802.11ax/be, OFDMA, MLO and roaming](https://test4net.com/blog/how-we-test-wi-fi-6-6e-7?hsLang=en) [All protocols](https://test4net.com/blog/tag/protocols?hsLang=en) [RFC 2544 Throughput, latency, frame loss and back-to-back](https://test4net.com/methodologies/rfc-2544?hsLang=en) [RFC 2889 LAN switch benchmarking: forwarding, MAC learning, congestion](https://test4net.com/methodologies/rfc-2889?hsLang=en) [RFC 9411 / RFC 3511 Firewall and NGFW performance benchmarking](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=en) [RFC 6349 TCP throughput and buffer delay testing](https://test4net.com/methodologies/rfc-6349?hsLang=en) [RFC 5180 IPv6 benchmarking methodology](https://test4net.com/methodologies/rfc-5180?hsLang=en) [ITU-T Y.1564 Ethernet service activation: CIR, EIR, KPIs per service](https://test4net.com/methodologies/y-1564?hsLang=en) [ITU-T Y.1731 Ethernet OAM: delay, jitter, loss and SLA monitoring](https://test4net.com/methodologies/y-1731?hsLang=en) [TR-398 Wi-Fi in-premises performance test plan](https://test4net.com/methodologies/tr-398?hsLang=en) [All methodologies](https://test4net.com/methodologies?hsLang=en) Read [Case studies, test insights and lab notes Blog](https://test4net.com/blog?hsLang=en) [What is changing in network testing and infrastructure Industry News](https://test4net.com/news?hsLang=en) [How the lab, sessions and reports work FAQ](https://test4net.com/faq?hsLang=en) [About Us Independent lab in Armenia, team and history](https://test4net.com/about?hsLang=en) [Why TEST4NET What you get that vendor slides never show](https://test4net.com/why-test4net?hsLang=en) [Lab & Certifications Bench capacity, methods and the standards we test against](https://test4net.com/lab?hsLang=en) [Partners Test tool vendors and IT partners we work with](https://test4net.com/partners?hsLang=en) [Contacts Talk to an engineer, not a sales bot](https://test4net.com/contacts?hsLang=en) [Support portal](https://test4net.com/support?hsLang=en) - Services What we test [Load & Performance Testing](https://test4net.com/services/load-performance-testing?hsLang=en) [Functional & Conformance Testing](https://test4net.com/services/functional-conformance-testing?hsLang=en) [Interoperability Testing](https://test4net.com/services/interoperability-testing?hsLang=en) [Security & Resilience Testing](https://test4net.com/services/security-resilience-testing?hsLang=en) [Test Plan & Methodology Design](https://test4net.com/services/test-plan-design?hsLang=en) [Test Automation & CI/CD](https://test4net.com/services/test-automation?hsLang=en) [Training Programs](https://test4net.com/services#training) [Equipment Repair](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=en) By technology [Routing & Switching](https://test4net.com/solutions/routing-switching?hsLang=en) [Firewalls & NGFW](https://test4net.com/solutions/firewalls-ngfw?hsLang=en) [SD-WAN & WAN](https://test4net.com/solutions/sd-wan?hsLang=en) [Cloud & NFV](https://test4net.com/solutions/cloud-nfv?hsLang=en) [5G & Mobile Core](https://test4net.com/solutions/5g-mobile-core?hsLang=en) [Wi-Fi](https://test4net.com/solutions/wi-fi?hsLang=en) [Storage & Infrastructure](https://test4net.com/solutions/storage?hsLang=en) [AI / Switching Fabric (RoCEv2)](https://test4net.com/solutions/ai-fabric-rocev2?hsLang=en) [All technologies](https://test4net.com/services#coverage) Industries [Telecom Operators](https://test4net.com/solutions/industries#telecom) [Network & Security Vendors](https://test4net.com/solutions/industries#vendors) [System Integrators](https://test4net.com/solutions/industries#integrators) [Enterprise & Banks](https://test4net.com/solutions/industries#enterprise) [All industries](https://test4net.com/solutions/industries?hsLang=en) [Not sure where to start? Test plan and quote in 1–3 business days](https://test4net.com/contacts?hsLang=en) - Products CloudLAB [How It Works](https://test4net.com/cloudlab#how) [Equipment & Capabilities](https://test4net.com/cloudlab#equipment) [Access Plans](https://test4net.com/cloudlab/plans?hsLang=en) [Hosted DUT Testing](https://test4net.com/cloudlab/hosted-dut?hsLang=en) [Open the CloudLAB portal](https://lab.test4net.com) Our tools [Traffic Generator](https://test4net.com/products/traffic-generator?hsLang=en) [WANemu](https://test4net.com/products/wanemu?hsLang=en) [Book a demo](https://test4net.com/contacts?hsLang=en) [New: our own test tools Our own tools, in beta this autumn](https://test4net.com/products#lead-form) - Resources Read [Blog](https://test4net.com/blog?hsLang=en) [Industry News](https://test4net.com/news?hsLang=en) [FAQ](https://test4net.com/faq?hsLang=en) [All resources](https://test4net.com/resources?hsLang=en) Technologies / Protocols [BGP](https://test4net.com/blog/how-we-test-bgp?hsLang=en) [OSPF & IS-IS](https://test4net.com/blog/how-we-test-ospf-is-is?hsLang=en) [MPLS & SR](https://test4net.com/blog/how-we-test-mpls-and-segment-routing?hsLang=en) [EVPN / VXLAN](https://test4net.com/blog/how-we-test-evpn-vxlan?hsLang=en) [IPsec & IKEv2](https://test4net.com/blog/how-we-test-ipsec-and-ikev2?hsLang=en) [TLS / HTTPS](https://test4net.com/blog/how-we-test-tls-and-https?hsLang=en) [RoCEv2](https://test4net.com/blog/how-we-test-rocev2?hsLang=en) [Wi-Fi 6 / 6E / 7](https://test4net.com/blog/how-we-test-wi-fi-6-6e-7?hsLang=en) [All protocols](https://test4net.com/blog/tag/protocols?hsLang=en) Methodologies [RFC 2544](https://test4net.com/methodologies/rfc-2544?hsLang=en) [RFC 2889](https://test4net.com/methodologies/rfc-2889?hsLang=en) [RFC 9411 / RFC 3511](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=en) [RFC 6349](https://test4net.com/methodologies/rfc-6349?hsLang=en) [RFC 5180](https://test4net.com/methodologies/rfc-5180?hsLang=en) [ITU-T Y.1564](https://test4net.com/methodologies/y-1564?hsLang=en) [ITU-T Y.1731](https://test4net.com/methodologies/y-1731?hsLang=en) [TR-398](https://test4net.com/methodologies/tr-398?hsLang=en) [All methodologies](https://test4net.com/methodologies?hsLang=en) Read [Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=en) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=en) [FAQ How the lab, sessions and reports work](https://test4net.com/faq?hsLang=en) - Company [About Us](https://test4net.com/about?hsLang=en) [Why TEST4NET](https://test4net.com/why-test4net?hsLang=en) [Lab & Certifications](https://test4net.com/lab?hsLang=en) [Partners](https://test4net.com/partners?hsLang=en) [Contacts](https://test4net.com/contacts?hsLang=en) [News](https://test4net.com/news?hsLang=en) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=en) 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](https://test4net.com/methodologies/rfc-5180#lead-form) [See the tests](https://test4net.com/methodologies/rfc-5180#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 sizes | 64, 128, 256, 512, 1024, 1280, 1518 B (§5.1.1) | Plus 1522 B tagged; 9216 B jumbo where supported | Small frames show the per-packet cost; the IPv6 header is 40 B against 20 B for IPv4 | | Smallest frame with headers | One common smallest size for plain and header traffic (§5.3) | 128 B with the default chain | A chain over 32 B does not fit in 64 B, so the comparison starts where both fit | | Extension headers | Each alone, then routing, destination options and fragment in a chain over 32 B (§5.3) | 8 to 48 B per packet | Most routers skip them; a filter on TCP or UDP ports has to walk the chain | | Hop-by-hop header | Offered at 1%, 10% and 50% of the interface rate, resources watched (§5.3) | CPU and memory sampled every second | Every router has to process it, so the result is the impact on the device, not a throughput | | IPv4/IPv6 mix | IPv4 only, IPv6 only, then 90/10, 50/50 and 10/90 (§7) | Same total rate and frame sizes | Enabling IPv6 must not cost IPv4 forwarding | | Addresses and prefixes | 2001:2::/48 range; DUT prefixes /126, or /64 and shorter (§5.2) | Destination prefixes /48, /64, /126, /128 | Lookup cost depends on prefix length; a single /64 hides it | | Neighbour discovery | Dynamic ND preferred, endpoints one hop beyond the DUT (§4) | 1 to 16,000 neighbours as agreed | An expired cache turns forwarding into address resolution, and loss follows | | Filters | 1 and 25 entries with upper-layer matching (§6.2) | 10, 100 or 1,000 entries as agreed | Matching 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, seconds**Neighbour caches refreshed on both test ports, streams and header set loaded, CPU poll started - **Learning, 2 s**Low-rate frames so the device has every route and neighbour in place before counting starts - **Trial, 60 s**Traffic at the rate under test, both directions, every frame counted and timed - **Settle, 2 s**Late 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](https://test4net.com/contacts?hsLang=en) ### 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](https://test4net.com/contacts?hsLang=en) ### 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](https://test4net.com/contacts?hsLang=en) ### 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](https://lab.test4net.com/) - 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 - [MethodologyRFC 2544: zero-loss benchmark for switches and routers](https://test4net.com/methodologies/rfc-2544?hsLang=en) - [MethodologyRFC 2889: the switch test where every port talks to every port](https://test4net.com/methodologies/rfc-2889?hsLang=en) - [MethodologyRFC 6349: TCP throughput the way a file transfer sees it](https://test4net.com/methodologies/rfc-6349?hsLang=en) - [SolutionRouting and switching testing](https://test4net.com/solutions/routing-switching?hsLang=en) - [MethodologiesAll methods we run on the bench](https://test4net.com/methodologies?hsLang=en) - [Why TEST4NETWhy an independent bench beats a vendor demo](https://test4net.com/why-test4net?hsLang=en) 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](https://test4net.com/methodologies/rfc-5180#lead-form) [Log in to CloudLAB](https://lab.test4net.com/) 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](https://wa.me/37491612709) We use what you send only to answer you. See our [Privacy Policy](https://test4net.com/privacy-policy?hsLang=en). [Send the shortlist](https://test4net.com/methodologies/rfc-5180#lead-form) [![TEST4NET LLC](https://test4net.com/hubfs/test4net-logo-fixed.svg)](https://test4net.com?hsLang=en) Independent testing and validation for telecom, information security and cloud infrastructure – real insights, not assumptions [mailto:sales@test4net.com](mailto:sales@test4net.com) #### Navigate - [Home](https://test4net.com/?hsLang=en) - [Why TEST4NET](https://test4net.com/why-test4net?hsLang=en) - [About us](https://test4net.com/about?hsLang=en) - [Contact](https://test4net.com/contacts?hsLang=en) - [Blog](https://test4net.com/blog?hsLang=en) - [Industry News](https://test4net.com/news?hsLang=en) #### Get in touch Sales [sales@test4net.com](mailto:sales@test4net.com) Support [support.test4net.com](https://support.test4net.com) © 2026 TEST4NET LLC. All rights reserved. [Privacy Policy](https://test4net.com/privacy-policy?hsLang=en) [Legal](https://test4net.com/legal?hsLang=en) ```json { "@context" : "https://schema.org", "@id" : "https://test4net.com/#organization", "@type" : "Organization", "address" : { "@type" : "PostalAddress", "addressCountry" : "AM", "addressLocality" : "Yerevan", "postalCode" : "0033", "streetAddress" : "3 Hakob Hakobyan Street (Mergelyan Hub)" }, "alternateName" : "TEST4NET", "contactPoint" : { "@type" : "ContactPoint", "availableLanguage" : [ "en", "ru", "hy" ], "contactType" : "sales", "email" : "sales@test4net.com", "telephone" : "+374-60-88-88-99" }, "description" : "Independent, vendor-neutral lab for testing network and cybersecurity products — NGFW, WAF, IPS, DLP and SASE — and an authorized distributor of test, measurement and network infrastructure solutions.", "email" : "sales@test4net.com", "foundingDate" : "2024", "image" : "https://test4net.com/hubfs/og-t4n.png", "logo" : "https://test4net.com/hubfs/test4net-logo-fixed-2.svg", "name" : "TEST4NET LLC", "sameAs" : [ "https://www.linkedin.com/company/test4net/", "https://t.me/TEST4NET", "https://www.facebook.com/people/Test4net-LLC/61591470856077/" ], "telephone" : "+374-60-88-88-99", "url" : "https://test4net.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://test4net.com/#website", "@type" : "WebSite", "inLanguage" : "en", "name" : "TEST4NET", "potentialAction" : { "@type" : "SearchAction", "query-input" : "required name=search_term_string", "target" : { "@type" : "EntryPoint", "urlTemplate" : "https://test4net.com/hs-search-results?term={search_term_string}" } }, "publisher" : { "@id" : "https://test4net.com/#organization" }, "url" : "https://test4net.com/" } ``` ```json { "@context" : "https://schema.org", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "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." }, "name" : "How is RFC 5180 different from RFC 2544?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "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." }, "name" : "Why does 64 bytes stay in the frame size list?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "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." }, "name" : "Why test extension headers if most traffic has none?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "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." }, "name" : "Which devices do you test with RFC 5180?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "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." }, "name" : "Is multicast part of RFC 5180?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "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." }, "name" : "How long does an RFC 5180 project take?" } ] } ```