tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 8219

Informational
Pages: 30
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: BMWG

Benchmarking Methodology for IPv6 Transition Technologies

Part 1 of 2, p. 1 to 11
None       Next Section

 


Top       ToC       Page 1 
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 Technologies

Abstract

   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.

Top      ToC       Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
   15. References ....................................................24
      15.1. Normative References .....................................24
      15.2. Informative References ...................................25
   Appendix A. Theoretical Maximum Frame Rates........................29
   Acknowledgements...................................................30
   Authors' Addresses ................................................30

1.  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.

Top      ToC       Page 5 
   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

Top      ToC       Page 6 
   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 Categories

2.  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.

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
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)

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
   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)

Next Section