RFC 8219
Benchmarking Methodology for IPv6 Transition Technologies
Pages: 30
Informational
Informational
Part 1 of 2 – Pages 1 to 11
Internet Engineering Task Force (IETF) M. Georgescu Request for Comments: 8219 L. Pislaru Category: Informational RCS&RDS ISSN: 2070-1721 G. Lencse Szechenyi Istvan University August 2017 Benchmarking Methodology for IPv6 Transition TechnologiesAbstract
Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8219.
Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4 1.1. IPv6 Transition Technologies ...............................4 2. Conventions Used in This Document ...............................6 3. Terminology .....................................................7 4. Test Setup ......................................................7 4.1. Single-Translation Transition Technologies .................8 4.2. Encapsulation and Double-Translation Transition Technologies ...............................................8 5. Test Traffic ....................................................9 5.1. Frame Formats and Sizes ....................................9 5.1.1. Frame Sizes to Be Used over Ethernet ...............10 5.2. Protocol Addresses ........................................10 5.3. Traffic Setup .............................................10 6. Modifiers ......................................................11 7. Benchmarking Tests .............................................11 7.1. Throughput ................................................11 7.2. Latency ...................................................11 7.3. Packet Delay Variation ....................................13 7.3.1. PDV ................................................13 7.3.2. IPDV ...............................................14 7.4. Frame Loss Rate ...........................................15 7.5. Back-to-Back Frames .......................................15 7.6. System Recovery ...........................................15 7.7. Reset .....................................................15 8. Additional Benchmarking Tests for Stateful IPv6 Transition Technologies ...................................................15 8.1. Concurrent TCP Connection Capacity ........................15 8.2. Maximum TCP Connection Establishment Rate .................15 9. DNS Resolution Performance .....................................15 9.1. Test and Traffic Setup ....................................16 9.2. Benchmarking DNS Resolution Performance ...................17 9.2.1. Requirements for the Tester ........................18 10. Overload Scalability ..........................................19 10.1. Test Setup ...............................................19 10.1.1. Single-Translation Transition Technologies ........19 10.1.2. Encapsulation and Double-Translation Transition Technologies ...........................20 10.2. Benchmarking Performance Degradation .....................21 10.2.1. Network Performance Degradation with Simultaneous Load .................................21 10.2.2. Network Performance Degradation with Incremental Load ..................................22 11. NAT44 and NAT66 ...............................................22 12. Summarizing Function and Variation ............................23 13. Security Considerations .......................................23 14. IANA Considerations ...........................................24
15. References ....................................................24 15.1. Normative References .....................................24 15.2. Informative References ...................................25 Appendix A. Theoretical Maximum Frame Rates........................29 Acknowledgements...................................................30 Authors' Addresses ................................................301. Introduction
The methodologies described in [RFC2544] and [RFC5180] help vendors and network operators alike analyze the performance of IPv4 and IPv6-capable network devices. The methodology presented in [RFC2544] is mostly IP version independent, while [RFC5180] contains complementary recommendations that are specific to the latest IP version, IPv6. However, [RFC5180] does not cover IPv6 transition technologies. IPv6 is not backwards compatible, which means that IPv4-only nodes cannot directly communicate with IPv6-only nodes. To solve this issue, IPv6 transition technologies have been proposed and implemented. This document presents benchmarking guidelines dedicated to IPv6 transition technologies. The benchmarking tests can provide insights about the performance of these technologies, which can act as useful feedback for developers and network operators going through the IPv6 transition process. The document also includes an approach to quantify performance when operating in overload. Overload scalability can be defined as a system's ability to gracefully accommodate a greater number of flows than the maximum number of flows that the Device Under Test (DUT) can operate normally. The approach taken here is to quantify the overload scalability by measuring the performance created by an excessive number of network flows and comparing performance to the non-overloaded case.1.1. IPv6 Transition Technologies
Two of the basic transition technologies, dual IP layer (also known as dual stack) and encapsulation, are presented in [RFC4213]. IPv4/IPv6 translation is presented in [RFC6144]. Most of the transition technologies employ at least one variation of these mechanisms. In this context, a generic classification of the transition technologies can prove useful.
We can consider a production network transitioning to IPv6 as being
constructed using the following IP domains:
o Domain A: IPvX-specific domain
o Core domain: IPvY-specific or dual-stack (IPvX and IPvY) domain
o Domain B: IPvX-specific domain
Note: X,Y are part of the set {4,6}, and X is NOT EQUAL to Y.
The transition technologies can be categorized according to the
technology used for traversal of the core domain:
1. Dual stack: Devices in the core domain implement both IP
protocols.
2. Single translation: In this case, the production network is
assumed to have only two domains: Domain A and the core domain.
The core domain is assumed to be IPvY specific. IPvX packets are
translated to IPvY at the edge between Domain A and the core
domain.
3. Double translation: The production network is assumed to have all
three domains; Domains A and B are IPvX specific, while the core
domain is IPvY specific. A translation mechanism is employed for
the traversal of the core network. The IPvX packets are
translated to IPvY packets at the edge between Domain A and the
core domain. Subsequently, the IPvY packets are translated back
to IPvX at the edge between the core domain and Domain B.
4. Encapsulation: The production network is assumed to have all
three domains; Domains A and B are IPvX specific, while the core
domain is IPvY specific. An encapsulation mechanism is used to
traverse the core domain. The IPvX packets are encapsulated to
IPvY packets at the edge between Domain A and the core domain.
Subsequently, the IPvY packets are de-encapsulated at the edge
between the core domain and Domain B.
The performance of dual-stack transition technologies can be fully
evaluated using the benchmarking methodologies presented by [RFC2544]
and [RFC5180]. Consequently, this document focuses on the other
three categories: single-translation, double-translation, and
encapsulation transition technologies.
Another important aspect by which IPv6 transition technologies can be
categorized is their use of stateful or stateless mapping algorithms.
The technologies that use stateful mapping algorithms (e.g., Stateful
NAT64 [RFC6146]) create dynamic correlations between IP addresses or {IP address, transport protocol, transport port number} tuples, which are stored in a state table. For ease of reference, IPv6 transition technologies that employ stateful mapping algorithms will be called "stateful IPv6 transition technologies". The efficiency with which the state table is managed can be an important performance indicator for these technologies. Hence, additional benchmarking tests are RECOMMENDED for stateful IPv6 transition technologies. Table 1 contains the generic categories and associations with some of the IPv6 transition technologies proposed in the IETF. Please note that the list is not exhaustive. +---+--------------------+------------------------------------+ | | Generic category | IPv6 Transition Technology | +---+--------------------+------------------------------------+ | 1 | Dual stack | Dual IP Layer Operations [RFC4213] | +---+--------------------+------------------------------------+ | 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] | +---+--------------------+------------------------------------+ | 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] | +---+--------------------+------------------------------------+ | 4 | Encapsulation | DS-Lite [RFC6333], MAP-E [RFC7597],| | | | Lightweight 4over6 [RFC7596], | | | | 6rd [RFC5569], 6PE [RFC4798], | | | | 6VPE [RFC4659] | +---+--------------------+------------------------------------+ Table 1: IPv6 Transition Technologies Categories2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Although these terms are usually associated with protocol requirements, in this document, the terms are requirements for users and systems that intend to implement the test conditions and claim conformance with this specification.
3. Terminology
A number of terms used in this memo have been defined in other RFCs. Please refer to the RFCs below for definitions, testing procedures, and reporting formats. o Throughput (Benchmark) [RFC2544] o Frame Loss Rate (Benchmark) [RFC2544] o Back-to-Back Frames (Benchmark) [RFC2544] o System Recovery (Benchmark) [RFC2544] o Reset (Benchmark) [RFC6201] o Concurrent TCP Connection Capacity (Benchmark) [RFC3511] o Maximum TCP Connection Establishment Rate (Benchmark) [RFC3511]4. Test Setup
The test environment setup options recommended for benchmarking IPv6 transition technologies are very similar to the ones presented in Section 6 of [RFC2544]. In the case of the Tester setup, the options presented in [RFC2544] and [RFC5180] can be applied here as well. However, the DUT setup options should be explained in the context of the targeted categories of IPv6 transition technologies: single translation, double translation, and encapsulation. Although both single Tester and sender/receiver setups are applicable to this methodology, the single Tester setup will be used to describe the DUT setup options. For the test setups presented in this memo, dynamic routing SHOULD be employed. However, the presence of routing and management frames can represent unwanted background data that can affect the benchmarking result. To that end, the procedures defined in Sections 11.2 and 11.3 of [RFC2544] related to routing and management frames SHOULD be used here. Moreover, the "trial description" recommendations presented in Section 23 of [RFC2544] are also valid for this memo. In terms of route setup, the recommendations of Section 13 of [RFC2544] are valid for this document, assuming that IPv6-capable routing protocols are used.
4.1. Single-Translation Transition Technologies
For the evaluation of single-translation transition technologies, a single DUT setup (see Figure 1) SHOULD be used. The DUT is responsible for translating the IPvX packets into IPvY packets. In this context, the Tester device SHOULD be configured to support both IPvX and IPvY. +--------------------+ | | +------------|IPvX Tester IPvY|<-------------+ | | | | | +--------------------+ | | | | +--------------------+ | | | | | +----------->|IPvX DUT IPvY|--------------+ | | +--------------------+ Figure 1: Test Setup 1 (Single DUT)4.2. Encapsulation and Double-Translation Transition Technologies
For evaluating the performance of encapsulation and double- translation transition technologies, a dual DUT setup (see Figure 2) SHOULD be employed. The Tester creates a network flow of IPvX packets. The first DUT is responsible for the encapsulation or translation of IPvX packets into IPvY packets. The IPvY packets are de-encapsulated/translated back to IPvX packets by the second DUT and forwarded to the Tester. +--------------------+ | | +---------------------|IPvX Tester IPvX|<------------------+ | | | | | +--------------------+ | | | | +--------------------+ +--------------------+ | | | | | | | +----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+ | | | | +--------------------+ +--------------------+ Figure 2: Test Setup 2 (Dual DUT)
One of the limitations of the dual DUT setup is the inability to reflect asymmetries in behavior between the DUTs. Considering this, additional performance tests SHOULD be performed using the single DUT setup. Note: For encapsulation IPv6 transition technologies in the single DUT setup, the Tester SHOULD be able to send IPvX packets encapsulated as IPvY in order to test the de-encapsulation efficiency.5. Test Traffic
The test traffic represents the experimental workload and SHOULD meet the requirements specified in this section. The requirements are dedicated to unicast IP traffic. Multicast IP traffic is outside of the scope of this document.5.1. Frame Formats and Sizes
[RFC5180] describes the frame size requirements for two commonly used media types: Ethernet and SONET (Synchronous Optical Network). [RFC2544] also covers other media types, such as token ring and Fiber Distributed Data Interface (FDDI). The recommendations of those two documents can be used for the dual-stack transition technologies. For the rest of the transition technologies, the frame overhead introduced by translation or encapsulation MUST be considered. The encapsulation/translation process generates different size frames on different segments of the test setup. For instance, the single- translation transition technologies will create different frame sizes on the receiving segment of the test setup, as IPvX packets are translated to IPvY. This is not a problem if the bandwidth of the employed media is not exceeded. To prevent exceeding the limitations imposed by the media, the frame size overhead needs to be taken into account when calculating the maximum theoretical frame rates. The calculation method for the Ethernet, as well as a calculation example, are detailed in Appendix A. The details of the media employed for the benchmarking tests MUST be noted in all test reports. In the context of frame size overhead, MTU recommendations are needed in order to avoid frame loss due to MTU mismatch between the virtual encapsulation/translation interfaces and the physical network interface controllers (NICs). To avoid this situation, the larger MTU between the physical NICs and virtual encapsulation/translation interfaces SHOULD be set for all interfaces of the DUT and Tester.
To be more specific, the minimum IPv6 MTU size (1280 bytes) plus the encapsulation/translation overhead is the RECOMMENDED value for the physical interfaces as well as virtual ones.5.1.1. Frame Sizes to Be Used over Ethernet
Based on the recommendations of [RFC5180], the following frame sizes SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links: 64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192, and 9216. For Ethernet frames exceeding 1500 bytes in size, the [IEEE802.1AC] standard can be consulted. Note: For single-translation transition technologies (e.g., NAT64) in the IPv6 -> IPv4 translation direction, 64-byte frames SHOULD be replaced by 84-byte frames. This would allow the frames to be transported over media such as the ones described by the [IEEE802.1Q] standard. Moreover, this would also allow the implementation of a frame identifier in the UDP data. The theoretical maximum frame rates considering an example of frame overhead are presented in Appendix A.5.2. Protocol Addresses
The selected protocol addresses should follow the recommendations of Section 5 of [RFC5180] for IPv6 and Section 12 of [RFC2544] for IPv4. Note: Testing traffic with extension headers might not be possible for the transition technologies that employ translation. Proposed IPvX/IPvY translation algorithms such as IP/ICMP translation [RFC7915] do not support the use of extension headers.5.3. Traffic Setup
Following the recommendations of [RFC5180], all tests described SHOULD be performed with bidirectional traffic. Unidirectional traffic tests MAY also be performed for a fine-grained performance assessment. Because of the simplicity of UDP, UDP measurements offer a more reliable basis for comparison than other transport-layer protocols. Consequently, for the benchmarking tests described in Section 7 of this document, UDP traffic SHOULD be employed.
Considering that a transition technology could process both native
IPv6 traffic and translated/encapsulated traffic, the following
traffic setups are recommended:
i) IPvX only traffic (where the IPvX traffic is to be
translated/encapsulated by the DUT)
ii) 90% IPvX traffic and 10% IPvY native traffic
iii) 50% IPvX traffic and 50% IPvY native traffic
iv) 10% IPvX traffic and 90% IPvY native traffic
For the benchmarks dedicated to stateful IPv6 transition
technologies, included in Section 8 of this memo (Concurrent TCP
Connection Capacity and Maximum TCP Connection Establishment Rate),
the traffic SHOULD follow the recommendations of Sections 5.2.2.2 and
5.3.2.2 of [RFC3511].
6. Modifiers
The idea of testing under different operational conditions was first
introduced in Section 11 of [RFC2544] and represents an important
aspect of benchmarking network elements, as it emulates, to some
extent, the conditions of a production environment. Section 6 of
[RFC5180] describes complementary test conditions specific to IPv6.
The recommendations in [RFC2544] and [RFC5180] can also be followed
for testing of IPv6 transition technologies.
(page 11 continued on part 2)