IPv6 Testing White Paper
Interest in IPv6 has resurged with the assignment of the last IPv4 address. While the transition from IPv4 to IPv6 networks has been under way for many years, there are still issues to be addressed in the long interim period. This white paper looks at some of the transitional technologies in use and offers a set of test cases to assure the performance and functionality of their implementations.
The Internet Assigned Numbers Authority assigned the last blocks in the IPv4 address pool in February of 2011 and suddenly it was Y2K all over again. IPv6 was in the headlines. Articles and analysts expressed concerns with IPv6 performance, availability, scalability, security, and interoperability, about dualstack environments, tunneling and translation.
But just how dire is the exhaustion of IPv4 addresses? Is IPv6 ready to step up to the plate or is the Internet in danger of collapsing?
IPV6 TESTING
June 2011
Rev. A 06/11
SPIRENT
1325 Borregas Avenue
Sunnyvale, CA 94089 USA
Email: sales@spirent.com
Web: www.spirent.com
AMERICAS 1-800-SPIRENT • +1-818-676-2683 • sales@spirent.com
EUROPE AND THE MIDDLE EAST +44 (0) 1293 767979 • emeainfo@spirent.com
ASIA AND THE PACIFIC +86-10-8518-2539 • salesasia@spirent.com
© 2011 Spirent. All Rights Reserved.
All of the company names and/or brand names and/or product names referred to in this document, in particular,
the name “Spirent” and its logo device, are either registered trademarks or trademarks of Spirent plc and its
subsidiaries, pending registration in accordance with relevant national laws. All other registered trademarks or
trademarks are the property of their respective owners.
The information contained in this document is subject to change without notice and does not represent a
commitment on the part of Spirent. The information in this document is believed to be accurate and reliable;
however, Spirent assumes no responsibility or liability for any errors or inaccuracies that may appear in the
document.
IPv6 Testing
Table of Contents
i • SPIRENT WHITE PAPER
Executive Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Is the Sky Falling? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Why IPv6 Now? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
IPv6 Queuing/Fabric Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Frame Size and Rate for IPv6 Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
IPv4/IPv6 Transition Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Outstanding Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Assumptions of Testing IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
IPv6 and the Mixed Core:QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
IPv6 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
IP Throughput and Latency for IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Dual Stack Ipv4 and IPv6 Jitter Test with Microburst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Testing DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Packet Loss, Sequencing and Latency for IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Back-to-Back (Burst Size) Test for IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
IPv4/IPv6 Dual Stack Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
IPv6/IPv4: Dynamic DS-Lite scale and performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
IPv6/IPv4: 6to4Tunneling Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
IPv6 Packet Loss and Latency for NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
IPv6 Prefix Length Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Router Performance Impact of IPv6 FIB Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
NAT64 and NAT444 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
IPv4 and IPv6 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
IPv4 and IPv6 Compared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
More information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
IPv6 Testing
1 • SPIRENT WHITE PAPER
EXECUTIVE OVERVIEW
Interest in IPv6 has resurged with the assignment of the last IPv4 address . While
the transition from IPv4 to IPv6 networks has been under way for many years,
there are still issues to be addressed in the long interim period . This white paper
looks at some of the transitional technologies in use and offers a set of test
cases to assure the performance and functionality of their implementations .
IS THE SKY FALLING?
The Internet Assigned Numbers Authority assigned the last blocks in the IPv4
address pool in February of 2011 and suddenly it was Y2K all over again . IPv6
was in the headlines . Articles and analysts expressed concerns with IPv6
performance, availability, scalability, security, and interoperability, about dual-
stack environments, tunneling and translation .
But just how dire is the exhaustion of IPv4 addresses? Is IPv6 ready to step up
to the plate or is the Internet in danger of collapsing? Is the sky falling, yet?
The short answer is: No .
IPv6 has been around for over a decade . RFC 2460, Internet Protocol Version
6 (IPv6) Specification, was published in 1998 . For over half a decade, network
equipment manufacturers (NEMs) have been working on IPv6 implementations
of various types and Spirent has been testing them .
WHY IPV6 NOW?
There are many reasons why IPv6 has come to the forefront at this time .
• It has expanded routing and addressing capabilities to address the end
of unallocated IPv4 addresses .
• IPv6 increases the IP address size from 32 bits to 128 bits to support
more levels of addressing hierarchy, a much greater number of
addressable nodes, and simpler auto-configuration of addresses .
• The scalability of multicast routing is improved by adding a scope field
to multicast addresses, enabling publicly-routable multicast .
• A new type of address, called a anycast address, identifies sets of nodes
such that a packet sent to an anycast address is delivered to one of the
nodes . The use of anycast addresses in the IPv6 source route allows
nodes to control the path through which their traffic flows .
• Header format simplification provides for routing optimization .
• Some IPv4 header fields have been dropped or made optional to reduce
the common-case processing cost of packet handling and to keep the
bandwidth cost of the IPv6 header as low as possible, despite the
increased size of the addresses . Even though IPv6 addresses are four
time longer than IPv4 addresses, the IPv6 header is only twice the size of
the IPv4 header .
IPv6 Testing
SPIRENT WHITE PAPER • 2
• Improved support for options allows for more intelligent routing .
• Changes in the way IP header options are encoded allows for more efficient forwarding,
less stringent limits on the length of options, and greater flexibility for introducing new
options in the future .
• Quality of Service (QoS) capabilities and embedded encrypted tunneling, even on the
public Internet .
• A new capability is added to enable the labeling of packets belonging to particular
traffic flows for which the sender requests special handling, such as non-default quality
of service or real- time service, similar to an MPLS tunnel .
• Authentication and privacy capabilities are defined for authentication at Layer 3 .
• IPv6 includes the definition of extensions that provide support for authentication,
data integrity, and confidentiality as a basic element of IPv6 and included in all
implementations .
• The IPv6 protocol consists of two parts, the basic IPv6 header and IPv6 extension
headers for routing optimization .
IPV6 QUEUING/FABRIC CONSIDERATIONS
IPv6 offers direct challenges for the switch fabric . First, the IPv6 is 128-bits long as opposed to
32 bits . Even with super-netting and summarization, algorithms that are hardware-optimized
for 32-bit IPv4 addresses must be retuned and reintroduced to hardware . If the CPU soft
switches the packet, then scale and capacity may become an issue . Second, an IPv6 address
is in a different format, so algorithms used to optimize performance based on fixed one-byte
octets must be tested . Capacity testing reveals the scale of IPv6 address the fabric is capable
of handling . Rate testing reveals how fast the system can add addresses to the Forwarding
Information Base (FIB) .
In addition, RFC 4814 L2 addressing and shuffle VFD variablization in the IPv6 source and
destination addresses should be used in conjunction with traffic patterns . When used,
randomly addressed frames populate the FIB table without summarization .
FRAME SIZE AND RATE FOR IPV6 CONSIDERATION
Frame sizes for IPv6 are tested differently than classic IPv4 testing . In IPv6, the effective
minimum frame size is 1280 bytes (including the L2 header and CRC) and are much more likely
to be tested to 16K frame sizes . Given this limit, test cases should range from 64 bytes to 16K
Bytes to test the full range of possible frame sizes . Especially when running dual stack tests,
using the iMIX traffic type is a critical part of testing . Using an iMIX pattern will place additional
forwarding stress on the FIB .
In addition, it is critical to test IPv6 with microbursting . A microburst is a sudden, and
momentary increase in rate and address density . Microburst conditions can happen in storage,
real-time, and video environments . IPv6 should be able to be forwarded at full line rate at any
frame size .
IPv6 Testing
3 • SPIRENT WHITE PAPER
IPV4/IPV6 TRANSITION SOLUTIONS
Service providers (SPs) have already deployed solutions to allow IPv4 and IPv6 to coexist .
• NAT-PT (RFC 2766 Network Address Translation - Protocol Translation) . An IPv4 address
is assigned a unique IPv6 address dynamically as sessions are initiated across IPv4/
IPv6 boundaries . As a message comes into the IPv4 network, the NAT server translates
the IPv6 address into the internal IPv4 address . The reverse process happens as a
message leaves the IPv4 network .
• 6to4 (RFC 3056 Connection of IPv6 Domains via IPv4 Clouds) . Disparate IPv6 networks
communicate over an IPv4 cloud network by encapsulating IPv6 packets inside IPv4
packets to tunnel through the IPv4 network using the well-known prefix 2002::/16 .
• 6rd (RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures Protocol Specification) . An
adaptation of 6to4 that uses a SP’s own IPv6 address prefix rather than the well-known
prefix . This constrains the operational domain of 6rd to the SP network rather than having to
rely on an external 6to4 relay router outside of its control to do the IPv6/IPv4 encapsulation .
With one of these mechanisms in place, a SP can operate off an existing IPv4 backbone
indefinitely, implementing IPv6 at the ends to accommodate new addresses . The sky isn’t
falling . It’s not even storming .
OUTSTANDING CHALLENGES
So, if SPs have it covered, what’s the fuss all about? The issue is that these are all transitional
solutions in the long journey from pure IPv4 networks to pure IPv6 networks . They are
workarounds requiring translation or tunneling, which introduce extra processing steps in the
path and the latency that goes along with it . For some end users it’s just an inconvenience, for
others, such as financial services, it’s potentially disastrous for the top and bottom lines . For
SPs, low latency is a competitive differentiator .
As IPv6 deployment grows, those who cling to legacy transitional solutions rather than have
a migration strategy in place become increasingly marginalized due to performance and
functional limitations .
The answer is to assure the efficiency and performance of tunneling or translation mechanism
while planning for and testing an end-to-end native IPv6 network for performance, availability,
security and scalability .
To that end, twelve IPv6 test cases are summarized below . The details of topologies and test
steps are available in the IPv6 edition of the Spirent Test Methodology Journal .
http://www .spirent .com/Networks-and-Applications/IPv6 .aspx .
IPv6 Testing
SPIRENT WHITE PAPER • 4
RISK IN DEPLOYING IPV6
IPv6 is substantially different from IPv4 . CPUs, ASICs, queues, buffers, RIBs, microcode, drivers,
and OS Code are at high risk for:
• Unexpected data plane performance / forwarding optimization
• Inefficient queuing algorithms and unoptimized queue hash management
• Decreased stability and reliabilityand increased security breaches
• Loss of QoS and QoE, and the ability to sell SLAs
• Poor performance, compliance, and scale of control plane protocols
The same testing techniques for testing IPv4, developed a decade ago now only provide
marginal value at the acceptance test phase . To properly and thoroughly test IPv6, we must
augment, improve and establish new testing techniques
ASSUMPTIONS OF TESTING IPV6
IPV6 AND THE MIXED CORE:QoS
IPv6 also has QoS testing concerns . The IPv6 Traffic Class field tags traffic with DiffServ
Codepoint according to RFC 2474 . In the mixed Layer 3 core, IPv4 and IPv6 compete for the
same system resources . Each protocol could be separated by VLAN tags or just flow untagged .
The DUT must store, queue, process and forward the datagrams intermixed, where QoS is
always a factor in the core
Metrics can be mapped into acceptable Codepoint minimums .
ASSUMPTIONS OF TESTING IPV6
Old Assumptions New Realities
Synthetic ‘In the lab’ patterns are sufficient
to test the Device Under Test (DUT)
(Ex. RFC-2544, RFC-2889)
Real world, field derived patterns are the best way to test for
breakability
Static configurations are sufficient The DUT is most likely to break when under live change under scale
QoS/QoE and how we measure them are
‘Nice to Have’ metrics of performance
QoS/QoE must be written into every test case, even at the beginning
of testing
Single metrics, like bandwidth, are sufficient
to measure passability
Even in the basic test, QoS policy adherence across many metrics is
required from the start
Data plane and control plane are separate
test suites
Data and control plane are inherently linked together and interrelated
Transmission can be steady state
(i.e., line rate) and come from a single
traffic source
Transmission must be a mix of burst, steady state, and microburst
under prioritization to fully stimulate the DUT to find issues
IPv6 Testing
5 • SPIRENT WHITE PAPER
0Bits
IPv4/IPv6 DiffServ|
DS-Field DSCP
Class Selector
Codepoints
Differentiated Services Codepoint (DSCP)
RFC 2474
Currently
Unused
CU
1 2 3 4 5 6 7
Codepoint
Max Jitter
(mSec)
Max Latency
(mSec)
Max Loss
(Frames)
Max
Duplicate
(Frames)
Max
Reordered
(Frames)
Max Late
(Frames)
EF 0 >=1 0 0 0 0
AF31 0 2 0 0 0 0
AF21 2 5 0 1 1 1
AF11 3 5 1 1 1 1
BE ANY ANY ANY ANY ANY ANY
DSCP VALUE DF CODEPOINT
EQUIVALENT IP
PRECEDENT DESCRIPTION
000 000 00 BE 000 – Routine Best Effort, Unclassified Quality
001 010 10 AF11 001 – Priority High-Throughput Transactions with high loss senstivity
001 100 12 AF12 001 – Priority High-Throughput Transactions with some loss senstivity
001 110 14 AF13 001 – Priority High-Throughput Transactions with loss resiliency
001 010 18 AF21 001 – Immediate Low-Latency Transactions with high loss sensitivity
010 100 20 AF22 001 – Immediate Low-Latency Transactions with some loss sensitivity
010 119 22 AF23 001 – Immediate Low-Latency Transactions with loss resiliency
011 010 26 AF31 011 – Flash Broadcast Media with high loss sensitivity
011 110 28 AF32 011 – Flash Broadcast Media with some loss sensitivity
011 110 30 AF33 011 – Flash Broadcast Media with loss resiliency
100 010 34 AF41 100 – Flash Override Live Media with high loss sensitivity
100 110 36 AF42 100 – Flash Override Live Media with some loss sensitivity
100 110 38 AF43 100 – Flash Override Live Media with loss resiliency
101 110 46 EF 101 – Critical Mission Critical Transactions or VoIP
IPv6 Testing
SPIRENT WHITE PAPER • 6
IPV6 TEST CASES
IP Throughput and Latency for IPv4 and IPv6
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
Objective
This data plane test provides throughput and latency information for a single router
(device under test or DUT) or for a system of interconnected routers (system under test or SUT) .
The throughput of a device or system is the maximum packet-forwarding rate for which
the device or system does not drop any of the offered packets . Any packet loss can induce
significant delays in the execution of higher layer applications . Knowing the maximum data rate
a device or system can support without any packet loss is of crucial importance when judging
the performance of a router or system of interconnected routers .
This test also determines the latency of a device or system (the time it takes a packet to travel
through the device or the system), calculated at the maximum forwarding rate for which no
packet loss is experienced (throughput rate) .
The test methodology applies to IPv4 and IPv6 configurations .
Overview
To determine the throughput and latency of a DUT/SUT, a minimum of two test ports is required .
All ports are connected to the DUT/SUT .
One or more test ports act as data transmitters and offer traffic to the DUT/SUT . The other ports
act as data receivers and accept traffic from the DUT/SUT . The DUT/SUT must be configured
such that traffic offered by the data transmitters is forwarded toward the data receivers .
The transmitter test ports offer a predetermined number of packets to the DUT/SUT . The
DUT/SUT forwards the packets to the receiver test ports . The number of packets accepted at
the receiver test ports is compared to the number of packets offered . If packet loss occurs,
then the offered load is decreased and the test is repeated . If packet loss is not observed, the
test is repeated with an increased number of offered packets . By implementing a binary search
pattern, the maximum rate for which no packet loss occurs is recorded . This rate corresponds to
the DUT/SUT’s throughput, or the first measurement of the test .
To calculate latency, a predefined test stream is delivered to the DUT/SUT from the transmitter
test ports at the calculated throughput rate . The transmitting timestamp, corresponding
to when the test packet is sent by a transmitter test port, is subtracted from the receiving
timestamp that corresponds to when the packet arrives at a receiver test port . The difference
between the receiving timestamp and the transmitting timestamp gives the latency for a test
packet . The test is run for a determined period of time, which should be long enough to collect
sufficient data for an accurate representation of the system’s latency .
IPv6 Testing
7 • SPIRENT WHITE PAPER
Dual Stack Ipv4 and IPv6 Jitter Test with Microburst
RFC 4689: Benchmarking Network-layer Traffic Control Mechanisms
Objective
This data plane test measures the effects of a continuous microburst across the switch fabric
with the effects of increased jitter .
Overview
On the transmitting ports, set the port mode to manual-based scheduling and create a schedule
that send 10 percent nominal traffic for both IPv4 and IPv6 for three seconds, then creates a
microburst of IPv4 for one second at line rate, increasing the source and destination addresses
by ten times . Perform the same operation for IPv6, but offset the traffic by two seconds . Use
incrementing variables in the source and destination and RFC 4814 L2 addressing .
Transmit traffic for a minimum of 24 hours and measure the maximum and average jitter
across the transmitted streams . The average and maximum jitter should be within 0 .3 sigma
distribution of each other, with a distribution median near zero .
Testing DNS64
Objective
DNS protocols are a key determining factor of overall user experience . This test measures the
ability of DNS servers to respond in a predictable manner under extreme load . This test allow
the user to determine the scale to which DNS may be provisioned in the network .
Overview
Domain Name System (or Service or Server) is an Internet service that translates domain names
into IP addresses . Because domain names are alphabetic, they’re easier to remember than IP
addresses . The Internet however, is really based on IP addresses . Every time you use a domain
name, therefore, a DNS service must translate the name into the corresponding IP address .
For example, the domain name www .example .com might translate to 198 .105 .232 .4 . The DNS
system is, in fact, its own network . If one DNS server doesn’t know how to translate a particular
domain name, it asks another one, and so on, until the correct IP address is returned .
This test measures the capacity of DNS A Record and DNSv6 AAAA Record requests against a
live set of the top internet sites . Begin by setting up live DNS server to accept both A and AAAA
record requests . The server should be attached to the domain name system .
Next, set up user profiles with a minimum of 256 users per profile of mixed class stack .
Setup a loading profile that ramps up to 10,000 A Record Requests, then burst an addition
10,000 AAAA Record lookups at five-second intervals . This test should run for a minimum of 3
hours . When examining the results, look for excessive spikes in DNS A Record or AAAA record
response times . Look for maximum response time with no errors of one mSec or less for both A
and AAAA records .
IPv6 Testing
SPIRENT WHITE PAPER • 8
Packet Loss, Sequencing and Latency for IPv4 and IPv6
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Terminology for Network Interconnect Devices
Objective
This data plane test determines the packet loss rate and latency for a single router
(device under test or DUT) or for a system of interconnected routers (system under test or SUT)
for various input data rates and packet sizes .
The packet loss rate of a device or system is the percentage of Layer 3 frames that were offered
at the input of the device or system but were not forwarded by the device or system due to
hardware and software limitations . Calculating the packet loss rate of a system under different
load conditions (input data rate and packet size) serves to evaluate how the system perform
under similar conditions in real-life operation .
This test also determines the latency of a device or system (the time it takes a packet to travel
through the device or the system) calculated for the various input data rates, for which packet
loss may or may not be experienced .
The test methodology applies to IPv4 and IPv6 configurations .
Overview
To determine the packet loss rate and latency of a DUT or SUT, a minimum of two test ports are
required . All ports are connected to the DUT/SUT .
One or more test ports act as data transmitters and offer traffic to the DUT/SUT . The other ports
act as data receivers and accept traffic from the DUT/SUT . The DUT/SUT must be configured
such they forward the traffic offered by the data transmitters toward the data receivers .
The data transmitters offer a predetermined number of packets to the DUT/SUT for a given
amount of time . The DUT/SUT forwards the packets to the receiver test ports . The number of
packets accepted at the receiver test ports (RxPacketCount) is compared to the number of
packets offered from the transmitter ports (TxPacketCount) .
The packet loss rate is calculated using the following formula:
[(TxPacketCount – RxPacketCount) x 100] ÷ TxPacketCount
The packet loss is calculated for input data rates starting with 100 percent of the maximum rate
that can be offered from the transmitter test ports . The input data rate is decremented and the
test repeated until there are two successive trials without packet loss . The test may be stopped
when the input data rate reaches a user-selected threshold beyond which no measurements are
required . The amount by which the input data rate is decremented should be at most 10 percent
of the maximum input data rate and can be as low as 1 percent .
IPv6 Testing
9 • SPIRENT WHITE PAPER
System latency is measured at every trial, thus, for every value of the input data rate .
To calculate latency, the transmitter test ports deliver a predefined test stream to the
DUT/SUT at the calculated throughput rate . The transmitting timestamp, corresponding to
when a transmitter test port sends a test packet, is subtracted from the receiving timestamp
that corresponds to when the packet arrives at a receiver test port . The difference between the
receiving timestamp and the transmitting timestamp gives the latency for a test packet . The test
is run for a period of time long enough to collect sufficient data for an accurate representation
of the system’s latency .
Back-to-Back (Burst Size) Test for IPv4 and IPv6
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Terminology for Network Interconnect Devices
Objective
This data plane test determines the maximum number of packets a router (device under test or DUT),
or system of interconnected routers (system under test or SUT), can forward back-to-back without
packet loss . The number of packets in the longest burst that does not cause packet loss is the
back-to-back value .
In a back-to-back test, the transmitter test ports deliver packets at full line rate with no pause
between successive packets, except the required legal separation for a given technology and
physical medium .
The test methodology applies to IPv4 and IPv6 configurations .
Overview
To determine the back-to-back value of a device under test (DUT) or system under test (SUT)
requires a minimum of two test ports . All ports are connected to the DUT/SUT .
One or more test ports act as data transmitters and offer traffic bursts to the DUT/SUT . The other
ports act as data receivers and accept traffic from the DUT/SUT . The DUT/SUT must be configured
such that it forwards the traffic offered by the data transmitters toward the data receivers .
The transmitter test ports offer a burst of back-to-back packets to the DUT/SUT . The DUT/SUT
forwards the packets to the receiver test ports . The number of packets accepted at the receiver
test ports is compared to the number of packets offered . If packet loss occurs, then the burst
size is decreased (the number of back-to-back packets is decreased) and the test is repeated . If
no packet loss is observed in the next iteration, then the burst size is increased and the test is
repeated . By implementing a binary search, the back-to-back value is determined .
IPv6 Testing
SPIRENT WHITE PAPER • 10
IPv4/IPv6 Dual Stack Performance
RFC 2893: Transition Mechanisms for IPv6 Hosts and Routers
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
Objective
This data plane test determines the ability of the device under test (DUT) to forward both IPv4 and
IPv6 packets . Devices operating in this mode are commonly referred to as running a dual stack .
RFC 2893 also covers 6over4 tunneling . This topic is dealt with in a separate performance test .
The key measurement areas are packet loss and latency . The packet loss rate of a device or
system is the percentage of Layer 3 frames that offered at the ingress of the device or system
that were not forwarded by the device or system due to hardware and software limitations .
Calculating the packet loss rate of a system under different load conditions (input data rate
and packet size) serves to evaluate system performance under similar conditions in real-life
operation .
Packet latency is also determined for a device or system (the time it takes a packet to travel
through the device or system) . Packet latency is calculated for the various input data rates and
packet sizes for which packet loss may or may not be experienced .
Overview
Many routers and switches are capable of running a dual stack . Adopters of IPv6 should,
however, be aware of possible performance limitations when operating in this mode . Not all
devices exploit their hardware to assist in switching or routing . Many of these functions may be
provided by software only . It is prudent to characterize the performance of devices operating in
this mode before deployment .
To determine the packet loss rate and latency of a DUT or system under test (SUT), a minimum
of two test ports are required . All ports are connected to the DUT/SUT .
One or more test ports act as data transmitters and offer traffic to the DUT/SUT . The other ports
act as data receivers and accept traffic from the DUT/SUT . The DUT/SUT must be configured
such that it forwards the traffic offered by the data transmitters to the data receivers .
The data transmitters offer a predetermined number of packets to the DUT/SUT for a given
amount of time . The DUT/SUT forwards the packets to the receiver test ports . The number of
packets accepted at the receiver test ports (RxPacketCount) is compared to the number of
packets offered from the transmitter ports (TxPacketCount) .
The packet loss rate is calculated using the following formula:
[(TxPacketCount – RxPacketCount)×100] ÷ TxPacketCount
The packet loss is calculated for input data rates starting with 100 percent of the maximum
rate that can be offered from the transmitter test ports . The input data rate is decremented
and the test repeated until there are two successive trials where there is no packet loss .
IPv6 Testing
11 • SPIRENT WHITE PAPER
The test may be stopped when the input data rate reaches a user-selected threshold beyond
which no measurements are required . The amount by which the input data rate is decremented
should be at most 10 percent of the maximum input data rate and can be as low as 1 percent .
System latency is measured at every trial, thus, for every value of the input data rate .
To calculate latency, the transmitter test ports deliver a predefined test stream to the
DUT/SUT at the calculated throughput rate . The transmitting time stamp, corresponding to
when a transmitter test port sends a test packet, is subtracted from the receiving time stamp
that corresponds to when the packet arrives at a receiver test port . The difference between the
receiving time stamp and the transmitting time stamp give the latency for a test packet . The test
is run for a period of time long enough to collect sufficient data for an accurate representation
of the system’s latency .
IPv6/IPv4: Dynamic DS-Lite scale and performance
Objective
DS-Lite (Dual-stack lite) is a transition technology that allows a service provider to roll out both
IPv4 and IPv6 addresses to subscribers . By encapsulating and splitting traffic based in IPv4 and
IPv6, the service provider canroute traffic accordingly .
Overview
This test uses the scalable nature of host and stream blocks . Since a DS-Lite implantation
in a production network is most likely to fail when there is dynamic change under load, the
test changes content in real time . Connect the test ports on the subscriber and core sides of
the DS-Lite gateway . On the core facing interface, create a pool of hosts with a net mask of
/16 for IPv4 and a /64 subnet for IPv6 . Install HTTP, video, and SIP servers on the emulated
hosts . Next, create a subscriber cloud whereby a single host creates Layer 3 IPv4 over IPv6 and
IPv6 traffic native to their respective subnets at an iMIX pattern of (IPv4: 64:50%, 576:25%,
1518:25%) and (IPv6: 1280:50%, 1340:25%, 1518:25%) . Add HTTP client, SIP and video
endpoints on the same hosts . Begin servers and subscribers . Measure L3 QoS and QoE as a
baseline . Include jitter, rate, max latency, sequencing errors, HTTP goodput, voice MOS-LQ, and
video MOS-AV . Now, changed the host count in the following order without stopping traffic:
(1,5,10,20,100,200,201, 500, 1000, 10000, 500, 200, 100,20,20,5,1)
Record the QoS and QoE metrics for each host count . Graph and compare the variance of
results . The DUT passes if the variance is greater than 0 .1 percent .
IPv6 Testing
SPIRENT WHITE PAPER • 12
IPv6/IPv4: 6to4 Tunneling Performance
RFC 3056: Connection of IPv6 Domains via IPv4 Clouds
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
Objective
This data plane test determines the ability of the device under test (DUT) or system under test
(SUT) to encapsulate IPv6 packets on the ingress port with an IPv4 header for transport across
an IPv4 network . Prior to arriving at the destination IPv6 network, this IPv4 header must be
removed by a router to expose the original IPv6 packet .
The key measurement areas are packet loss and latency . The packet loss rate of a device or
system is the percentage of Layer 3 frames offered at the ingress of the device or system but
not forwarded due to hardware and software limitations . Calculating the packet loss rate of
a system under different load conditions (input data rate and packet size) serves to evaluate
system performance under similar conditions in real-life operation .
Packet latency is also determined for a device or system (the time it takes a packet to travel
through the device or system) . Packet latency is calculated for the various input data rates and
packet sizes, for which packet loss may or may not be experienced .
Overview
There are a number of tunneling mechanisms available for IPv6 . This test focuses on 6to4 .
This mechanism has a well-known prefix of 2002 followed by the IPv4 address of the tunnel
destination . A common syntax for this address is 2002:V4ADDR::/48 . The Internet Assigned
Numbers Authority (IANA) assigned the 2002 prefix . This is a well-known address that routers
recognize, indicating this packet must be encapsulated with IPv4 .
To determine the packet loss rate and latency of a DUT or SUT, a minimum of two test ports are
required . All ports are connected to the DUT/SUT .
One or more test ports act as data transmitters and offer traffic to the DUT/SUT . The other ports
act as data receivers and accept traffic from the DUT/SUT . The DUT/SUT must be configured
such that it forwards the traffic offered by the data transmitters toward the data receivers .
The data transmitters offer a predetermined number of packets to the DUT/SUT for a given
amount of time . The DUT/SUT forwards the packets to the receiver test ports . The number of
packets accepted at the receiver test ports (RxPacketCount) is compared to the number of
packets offered from the transmitter ports (TxPacketCount) .
The packet loss rate is calculated using the following formula:
[(TxPacketCount – RxPacketCount)×100] ÷ TxPacketCount
The packet loss is calculated for input data rates starting with 100 percent of the maximum
rate that can be offered from the transmitter test ports . The input data rate is decremented
and the test repeated, until there are two successive trials where there is no packet loss .
IPv6 Testing
13 • SPIRENT WHITE PAPER
The test may be stopped when the input data rate reaches a user-selected threshold beyond
which no measurements are required . The amount by which the input data rate is decremented
should be at most 10 percent of the maximum input data rate and can be as low as 1 percent .
System latency is measured at every trial, thus, for every value of the input data rate .
To calculate latency, a predefined test stream is delivered to the DUT/SUT from the transmitter
test ports at the calculated throughput rate . The transmitting time stamp, corresponding to
when a test packet is sent by a transmitter test port, is subtracted from the receiving time
stamp that corresponds to when the packet is accepted by a receiver test port . The difference
between the receiving time stamp and the transmitting time stamp gives the latency for a test
packet . The test is run for a period of time long enough to collect sufficient data for an accurate
representation of the system’s latency .
IPv6 Packet Loss and Latency for NAT-PT
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
RFC 2766: Network Address Translation - Protocol Translation (NAT-PT)
Objective
This data plane test measures the number of packets a device under test (DUT) loses (packet loss)
and the increase in delay (latency) when using Network Address Translation - Protocol Translation
(NAT-PT) . The measurements used in this test are based on formulas in the Packet Loss and
Latency for IPv4 and IPv6 test case .
Overview
NAT-PT is an enabler technology in which IPv4 and IPv6 devices can communicate . Based on
IPv4 NAT, NAT-PT takes packets from either an IPv4 or IPv6 network and creates the appropriate
address to communicate on the other network . As with NAT, this process involves time to make
the conversion . However, unlike NAT, NAT-PT always requires the additional processing required
from the larger address (IPv4 = 32 bits, IPv6 = 128 bits) and recalculation of header and
checksum information .
Determining the impact of NAT-PT on the DUT requires a minimum of two test ports with one
port being able to transmit IPv6 and the other port being able to receive IPv4 . Both ports
need the ability to track packets using a signature tag, since the IP address are different on
each side .
One or more ports act as data transmitters and offer traffic to the DUT . The other ports act as
data receivers and receive traffic from the DUT . It is important to configure the DUT to allow
traffic to be forwarded between the test ports .
The data transmitter test ports offer IPv6 packets to the DUT . The DUT replaces the IPv6
addresses with IPv4 addresses and then forwards them to the receiver ports . The number of
IPv4 packets accepted at the receiver ports is compared to the number of IPv6 packets offered .
Any packet loss and the amount of latency are recorded as the test is repeated while adjusting
variables such as packet rate and packet size .
IPv6 Testing
SPIRENT WHITE PAPER • 14
IPv6 Prefix Length Performance
RFC 2460: Internet Protocol Version 6 (IPv6) Specification
RFC 2374: IPv6 Aggregatable Global Unicast Address Format
RFC 2373: IP Version 6 Addressing Architecture
Objective
This data- and control-plane test measures the IPv6 data forwarding performance of a device
under test (DUT) that has an IPv6 route table of varying prefix lengths .
A test device port sends IPv6 routes with varying prefix lengths to the DUT using an IPv6
routing protocol . A second test device port sends data packets to the DUT . These data packets
utilize each of the different prefix lengths . Performance measurements per prefix length are
then taken .
Overview
Routing protocols have been modified to carry the longer 128-bit IPv6 address . Compared to
IPv4, routers need to look further into IP address to determine the destination network for
each packet . With IPv6, network prefix lengths can range from /4 to /64 . Data forwarding tests
require a routing table with varying IPv6 network prefix lengths .
Router manufacturers can use BGP-4+, OSPFv3, IS-ISv6 and RIPv6 to advertise the IPv6 routes .
Users should be aware of possible performance limitations, especially on the longer prefix
lengths . Heavier processing burdens placed on the router determine longest prefix match and
more memory is required to store the longer addresses . Not all devices implement hardware
assist for IPv6 packet forwarding . Many of these functions may be provided by software only . It
is prudent to characterize the performance of such devices before deployment .
Measurements of the IPv6 forwarding rate, latency and packet loss per prefix length are taken
to see if they are as consistent in conformance, functionality and performance
IPv6 Testing
15 • SPIRENT WHITE PAPER
Router Performance Impact of IPv6 FIB Size
RFC 2460: Internet Protocol Version 6 (IPv6) Specification
Objective
This data- and control-plane test measures the effect of data packet performance when the
device under test (DUT) has different numbers of IPv6 routes in its Forwarding Information Base
(FIB) table .
A test device port sends a fixed number of IPv6 routes to the DUT using an IPv6 routing
protocol . A second test device port sends data packets to the DUT that utilize routes in the FIB
table . Performance measurements of throughput, latency and packet loss of the data packets
are taken . The test is then repeated using more IPv6 routes in the router FIB table .
Overview
Today’s routers need more memory and processing power to both store the IPv6 network
prefixes and parse the IPv6 data packets to determine longest prefix match, and then
forward them .
Makers and testers of IPv6 routers that use protocols BGP-4+, OSPFv3, IS-ISv6 and RIPv6
should be aware of possible performance limitations, as many of these IPv6-related functions
may be provided by software only . Tests need to ensure IPv6 routing protocols and IPv6 data
forwarding engines are consistent in conformance, functionality and performance as their
IPv4 counterparts .
IPv6 Testing
SPIRENT WHITE PAPER • 16
NAT64 and NAT444
NAT64–RFC 4787: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
NAT444: ISP Shared Address/draft-shirasaki-nat444-isp-shared-addr-02
Objective
NAT (Network Address Translation) is another transition strategy for carriers to move to IPv6 .
There are two approaches to NAT—use NAT to translate private IPv4 address to an IPv6 network,
or bypass IPv6 and extend IPv4 addressing with carrier-grade NAT . Carrier-grade NAT444
performs a double NAT operation and is used exclusively to preserve IPv4 addressing .
Both NAT64 and NAT444 present substantial technical risk to the traffic . The double NAT
operation may severely impair QoS in the network by adding excessive jitter, loss and
sequencing problems, rate problems, and latency spikes . Both NAT64 and NAT444 break the
OSI model by placing some hosts in a non-direct routable state . In addition, services such as
streaming DVDs tend to be broken with double NAT (NAT444) and gaming services tend to also
not like double NAT configurations .
Overview
To test NAT64, connect two interfaces to the DUT . Configure the DUT to translate IPv4 to IPv6 .
On the core facing interface, configure an IPv4 and an IPv6 cloud . Set up at least a /16 subnet
IPv4 and a /64 IPv6 cloud . Install HTTP, video, and SIP servers on the emulated server hosts .
Next, create a subscriber cloud whereby a single host creates Layer 3 IPv4 and IPv6 traffic
destined to their native respective subnets with an iMIX pattern of (IPv4: 64:50%, 576:25%,
1518:25%) and (IPv6: 1280:50%, 1340:25%, 1518:25%) . Then, add HTTP client, SIP and video
endpoints on the same hosts . Begin servers and subscribers . Measure L3 QoS and QoE as a
baseline . Include jitter, rate, max latency, sequencing errors, HTTP goodput, voice MOS-LQ, and
video MOS-AV . Now, changed the host count in the following order without stopping traffic:
(1,5,10,20,100,200,201, 500, 1000, 10000, 500, 200, 100,20,20,5,1)
Record the QoS and QoE metrics for each host count . Graph and compare the variance of
results . The DUT passes if the variance is greater than 0 .1 percent .
To test NAT444, connect two interfaces to the DUT . Configure the DUT to translate IPv4 . On the
core-facing interface, configure an IPv4 . Set up at least a /16 subnet IPv4 . Install HTTP, video,
and SIP servers on the emulated server hosts . Next, create a subscriber cloud whereby a single
host creates Layer 3 IPv4 traffic at line rate with an iMIX pattern of (IPv4: 64:50%, 576:25%,
1518:25%) . Then, add HTTP client, SIP and video endpoints on the same hosts . Begin servers
and subscribers . Measure L3 QoS and QoE as a baseline . Include jitter, rate, max latency,
sequencing errors, HTTP goodput, voice MOS-LQ, and video MOS-AV . Now, changed the host
count in the following order without stopping traffic:
(1,5,10,20,100,200,201, 500, 1000, 10000, 500, 200, 100,20,20,5,1)
Record the QoS and QoE metrics for each host count . Graph and compare the variance of
results . The DUT passes if the variance is greater than 0 .1 percent .
IPv6 Testing
17 • SPIRENT WHITE PAPER
IPv4 AND IPv6 HEADERS
0 4 8 12 16 20 24 28 31
Version IHL
Identification Flags Fragment Offset
Header ChecksumProtocol
Source Address
Destination Address
IPv4 Header
0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 63
IPv6 Header
Time to Live
Type of Service Total Length
Version Traffic Class Payload Length Next Header Hop LimitFlow Label
Source Address
Destination Address
IPv6 Testing
SPIRENT WHITE PAPER • 18
IPv4 AND IPv6 COMPARED
IPv4 AND IPv6 COMPARED
IPv4 IPv6
Source and destination address are 32 bits (4bytes)
in length
Source and destination addresses are 128bits (16 bytes)
in length
IPSec support is optional IPSec support is required .
IPv4 header does not identify packet flow or QoS
handling by routers
IPv6 header contains Flow Label field, which identifies
packet flow for QoS handling by router
Both routers and the sending host fragment packets Only the sending host fragments packets; routers do not
Header includes a checksum Headers does not include a checksum
Header includes options All optional data is moved to IPv6 extension headers
Address Resolution Protocol (ARP) uses broadcast
ARP Request frames to resolve an IP address to a l
ink-layer address
Multicast Neighbor Solicitation messages resolve Ip
addresses to link-layer addresses
Internet Group Management Protocol (IGMP) manages
membership in local subnet groups
Multicast Listener Discovery (MLD) messages manage
membership in local subnet groups
ICMP Router Discovery is used to determine the IPv4
address of the best default gateway and it is optional
ICMPv6 Router Solicitations and Router Advertisement
messages are used to determine the IP address of the best
default gateway and they are required
Broadcast addresses are used to send traffic to all
nodes on a subnet
IPv6 uses a link-local scope all-nodes multicast address
Must be configured either manually or through DHCP Does not require manual configuration or DHCP
Use host address (A) resource records in Domain Name
System (DNS) to map host names ot IPv4 addresses
Uses host address (AAAA) resource records in DNS to map
host names to IPv6 addresses
Use pointer (PTR) resource records in the IN-ADDR ARPA
DNS domain to map IPv4 addresses to host names
Uses pointer (PTR) resource records in the IP6 ARPA DNS
domain to map IPv6 addresses to host names
Must support a 576-byte packet size
(possibly Fragmented)
Must support a 1280-byte packet size
(without fragmentation)
MORE INFORMATION
For more information on testing IPv6, and transition strategies to IPv6, please visit:
http://www .spirent .com/Networks-and-Applications/IPv6 .aspx
