doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc8219.txt b/doc/rfc/rfc8219.txt
new file mode 100644
index 0000000..3e9919c
--- /dev/null
+++ b/doc/rfc/rfc8219.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                     [Page 1]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                     [Page 2]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+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
+
+
+
+Georgescu, et al.             Informational                     [Page 3]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   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.
+
+
+
+
+
+
+Georgescu, et al.             Informational                     [Page 4]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   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
+
+
+
+Georgescu, et al.             Informational                     [Page 5]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   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.
+
+
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                     [Page 6]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+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.
+
+
+
+
+
+
+Georgescu, et al.             Informational                     [Page 7]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+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)
+
+
+
+
+
+
+Georgescu, et al.             Informational                     [Page 8]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   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.
+
+
+
+
+
+Georgescu, et al.             Informational                     [Page 9]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   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.
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 10]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   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.
+
+7.  Benchmarking Tests
+
+   The following sub-sections describe all recommended benchmarking
+   tests.
+
+7.1.  Throughput
+
+   Use Section 26.1 of [RFC2544] unmodified.
+
+7.2.  Latency
+
+   Objective: To determine the latency.  Typical latency is based on the
+   definitions of latency from [RFC1242].  However, this memo provides a
+   new measurement procedure.
+
+   Procedure: Similar to [RFC2544], the throughput for DUT at each of
+   the listed frame sizes SHOULD be determined.  Send a stream of frames
+   at a particular frame size through the DUT at the determined
+   throughput rate to a specific destination.  The stream SHOULD be at
+   least 120 seconds in duration.
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 11]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   Identifying tags SHOULD be included in at least 500 frames after 60
+   seconds.  For each tagged frame, the time at which the frame was
+   fully transmitted (timestamp A) and the time at which the frame was
+   received (timestamp B) MUST be recorded.  The latency is timestamp B
+   minus timestamp A as per the relevant definition from RFC 1242,
+   namely, latency as defined for store and forward devices or latency
+   as defined for bit forwarding devices.
+
+   We recommend encoding the identifying tag in the payload of the
+   frame.  To be more exact, the identifier SHOULD be inserted after the
+   UDP header.
+
+   From the resulted (at least 500) latencies, two quantities SHOULD be
+   calculated.  One is the typical latency, which SHOULD be calculated
+   with the following formula:
+
+   TL = Median(Li)
+
+   Where:
+
+   o  TL = the reported typical latency of the stream
+
+   o  Li = the latency for tagged frame i
+
+   The other measure is the worst-case latency, which SHOULD be
+   calculated with the following formula:
+
+   WCL = L99.9thPercentile
+
+   Where:
+
+   o  WCL = the reported worst-case latency
+
+   o  L99.9thPercentile = the 99.9th percentile of the stream-measured
+      latencies
+
+   The test MUST be repeated at least 20 times with the reported value
+   being the median of the recorded values for TL and WCL.
+
+   Reporting Format:  The report MUST state which definition of latency
+   (from RFC 1242) was used for this test.  The summarized latency
+   results SHOULD be reported in the format of a table with a row for
+   each of the tested frame sizes.  There SHOULD be columns for the
+   frame size, the rate at which the latency test was run for that frame
+   size, the media types tested, and the resultant typical latency, and
+   the worst-case latency values for each type of data stream tested.
+   To account for the variation, the 1st and 99th percentiles of the 20
+
+
+
+
+Georgescu, et al.             Informational                    [Page 12]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   iterations MAY be reported in two separated columns.  For a fine-
+   grained analysis, the histogram (as exemplified in Section 4.4 of
+   [RFC5481]) of one of the iterations MAY be displayed.
+
+7.3.  Packet Delay Variation
+
+   [RFC5481] presents two metrics: Packet Delay Variation (PDV) and
+   Inter Packet Delay Variation (IPDV).  Measuring PDV is RECOMMENDED;
+   for a fine-grained analysis of delay variation, IPDV measurements MAY
+   be performed.
+
+7.3.1.  PDV
+
+   Objective: To determine the Packet Delay Variation as defined in
+   [RFC5481].
+
+   Procedure: As described by [RFC2544], first determine the throughput
+   for the DUT at each of the listed frame sizes.  Send a stream of
+   frames at a particular frame size through the DUT at the determined
+   throughput rate to a specific destination.  The stream SHOULD be at
+   least 60 seconds in duration.  Measure the one-way delay as described
+   by [RFC3393] for all frames in the stream.  Calculate the PDV of the
+   stream using the formula:
+
+   PDV = D99.9thPercentile - Dmin
+
+   Where:
+
+   o  D99.9thPercentile = the 99.9th percentile (as described in
+      [RFC5481]) of the one-way delay for the stream
+
+   o  Dmin = the minimum one-way delay in the stream
+
+   As recommended in [RFC2544], the test MUST be repeated at least 20
+   times with the reported value being the median of the recorded
+   values.  Moreover, the 1st and 99th percentiles SHOULD be calculated
+   to account for the variation of the dataset.
+
+   Reporting Format: The PDV results SHOULD be reported in a table with
+   a row for each of the tested frame sizes and columns for the frame
+   size and the applied frame rate for the tested media types.  Two
+   columns for the 1st and 99th percentile values MAY be displayed.
+   Following the recommendations of [RFC5481], the RECOMMENDED units of
+   measurement are milliseconds.
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 13]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+7.3.2.  IPDV
+
+   Objective: To determine the Inter Packet Delay Variation as defined
+   in [RFC5481].
+
+   Procedure: As described by [RFC2544], first determine the throughput
+   for the DUT at each of the listed frame sizes.  Send a stream of
+   frames at a particular frame size through the DUT at the determined
+   throughput rate to a specific destination.  The stream SHOULD be at
+   least 60 seconds in duration.  Measure the one-way delay as described
+   by [RFC3393] for all frames in the stream.  Calculate the IPDV for
+   each of the frames using the formula:
+
+   IPDV(i) = D(i) - D(i-1)
+
+   Where:
+
+   o  D(i) = the one-way delay of the i-th frame in the stream
+
+   o  D(i-1) = the one-way delay of (i-1)th frame in the stream
+
+   Given the nature of IPDV, reporting a single number might lead to
+   over-summarization.  In this context, the report for each measurement
+   SHOULD include three values: Dmin, Dmed, and Dmax.
+
+   Where:
+
+   o  Dmin = the minimum IPDV in the stream
+
+   o  Dmed = the median IPDV of the stream
+
+   o  Dmax = the maximum IPDV in the stream
+
+   The test MUST be repeated at least 20 times.  To summarize the 20
+   repetitions, for each of the three (Dmin, Dmed, and Dmax), the median
+   value SHOULD be reported.
+
+   Reporting format: The median for the three proposed values SHOULD be
+   reported.  The IPDV results SHOULD be reported in a table with a row
+   for each of the tested frame sizes.  The columns SHOULD include the
+   frame size and associated frame rate for the tested media types and
+   sub-columns for the three proposed reported values.  Following the
+   recommendations of [RFC5481], the RECOMMENDED units of measurement
+   are milliseconds.
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 14]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+7.4.  Frame Loss Rate
+
+   Use Section 26.3 of [RFC2544] unmodified.
+
+7.5.  Back-to-Back Frames
+
+   Use Section 26.4 of [RFC2544] unmodified.
+
+7.6.  System Recovery
+
+   Use Section 26.5 of [RFC2544] unmodified.
+
+7.7.  Reset
+
+   Use Section 4 of [RFC6201] unmodified.
+
+8.  Additional Benchmarking Tests for Stateful IPv6 Transition
+    Technologies
+
+   This section describes additional tests dedicated to stateful IPv6
+   transition technologies.  For the tests described in this section,
+   the DUT devices SHOULD follow the test setup and test parameters
+   recommendations presented in Sections 5.2 and 5.3 of [RFC3511].
+
+   The following additional tests SHOULD be performed.
+
+8.1.  Concurrent TCP Connection Capacity
+
+   Use Section 5.2 of [RFC3511] unmodified.
+
+8.2.  Maximum TCP Connection Establishment Rate
+
+   Use Section 5.3 of [RFC3511] unmodified.
+
+9.  DNS Resolution Performance
+
+   This section describes benchmarking tests dedicated to DNS64 (see
+   [RFC6147]), used as DNS support for single-translation technologies
+   such as NAT64.
+
+
+
+
+
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 15]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+9.1.  Test and Traffic Setup
+
+   The test setup in Figure 3 follows the setup proposed for single-
+   translation IPv6 transition technologies in Figure 1.
+
+      1:AAAA query    +--------------------+
+         +------------|                    |<-------------+
+         |            |IPv6   Tester   IPv4|              |
+         |  +-------->|                    |----------+   |
+         |  |         +--------------------+ 3:empty  |   |
+         |  | 6:synt'd                         AAAA,  |   |
+         |  |   AAAA  +--------------------+ 5:valid A|   |
+         |  +---------|                    |<---------+   |
+         |            |IPv6     DUT    IPv4|              |
+         +----------->|       (DNS64)      |--------------+
+                      +--------------------+ 2:AAAA query, 4:A query
+
+                   Figure 3: Test Setup 3 (DNS64)
+
+   The test traffic SHOULD be composed of the following messages.
+
+   1.  Query for the AAAA record of a domain name (from client to DNS64
+       server)
+
+   2.  Query for the AAAA record of the same domain name (from DNS64
+       server to authoritative DNS server)
+
+   3.  Empty AAAA record answer (from authoritative DNS server to DNS64
+       server)
+
+   4.  Query for the A record of the same domain name (from DNS64 server
+       to authoritative DNS server)
+
+   5.  Valid A record answer (from authoritative DNS server to DNS64
+       server)
+
+   6.  Synthesized AAAA record answer (from DNS64 server to client)
+
+   The Tester plays the role of DNS client as well as authoritative DNS
+   server.  It MAY be realized as a single physical device, or
+   alternatively, two physical devices MAY be used.
+
+   Please note that:
+
+   o  If the DNS64 server implements caching and there is a cache hit,
+      then step 1 is followed by step 6 (and steps 2 through 5 are
+      omitted).
+
+
+
+
+Georgescu, et al.             Informational                    [Page 16]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   o  If the domain name has a AAAA record, then it is returned in step
+      3 by the authoritative DNS server, steps 4 and 5 are omitted, and
+      the DNS64 server does not synthesize a AAAA record but returns the
+      received AAAA record to the client.
+
+   o  As for the IP version used between the Tester and the DUT, IPv6
+      MUST be used between the client and the DNS64 server (as a DNS64
+      server provides service for an IPv6-only client), but either IPv4
+      or IPv6 MAY be used between the DNS64 server and the authoritative
+      DNS server.
+
+9.2.  Benchmarking DNS Resolution Performance
+
+   Objective: To determine DNS64 performance by means of the maximum
+   number of successfully processed DNS requests per second.
+
+   Procedure: Send a specific number of DNS queries at a specific rate
+   to the DUT, and then count the replies from the DUT that are received
+   in time (within a predefined timeout period from the sending time of
+   the corresponding query, having the default value 1 second) and that
+   are valid (contain a AAAA record).  If the count of sent queries is
+   equal to the count of received replies, the rate of the queries is
+   raised, and the test is rerun.  If fewer replies are received than
+   queries were sent, the rate of the queries is reduced, and the test
+   is rerun.  The duration of each trial SHOULD be at least 60 seconds.
+   This will reduce the potential gain of a DNS64 server, which is able
+   to exhibit higher performance by storing the requests and thus also
+   utilizing the timeout time for answering them.  For the same reason,
+   no higher timeout time than 1 second SHOULD be used.  For further
+   considerations, see [Lencse1].
+
+   The maximum number of processed DNS queries per second is the fastest
+   rate at which the count of DNS replies sent by the DUT is equal to
+   the number of DNS queries sent to it by the test equipment.
+
+   The test SHOULD be repeated at least 20 times, and the median and
+   1st/99th percentiles of the number of processed DNS queries per
+   second SHOULD be calculated.
+
+   Details and parameters:
+
+   1.  Caching
+
+       First, all the DNS queries MUST contain different domain names
+       (or domain names MUST NOT be repeated before the cache of the DUT
+       is exhausted).  Then, new tests MAY be executed when domain names
+       are 20%, 40%, 60%, 80%, and 100% cached.  Ensuring that a record
+
+
+
+
+Georgescu, et al.             Informational                    [Page 17]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+       is cached requires repeating a domain name both "late enough"
+       after the first query to be already resolved and be present in
+       the cache and "early enough" to be still present in the cache.
+
+   2.  Existence of a AAAA record
+
+       First, all the DNS queries MUST contain domain names that do not
+       have a AAAA record and have exactly one A record.  Then, new
+       tests MAY be executed when 20%, 40%, 60%, 80%, and 100% of domain
+       names have a AAAA record.
+
+   Please note that the two conditions above are orthogonal; thus, all
+   their combinations are possible and MAY be tested.  The testing with
+   0% cached domain names and with 0% existing AAAA records is REQUIRED,
+   and the other combinations are OPTIONAL.  (When all the domain names
+   are cached, then the results do not depend on what percentage of the
+   domain names have AAAA records; thus, these combinations are not
+   worth testing one by one.)
+
+   Reporting format: The primary result of the DNS64 test is the median
+   of the number of processed DNS queries per second measured with the
+   above mentioned "0% + 0% combination".  The median SHOULD be
+   complemented with the 1st and 99th percentiles to show the stability
+   of the result.  If optional tests are done, the median and the 1st
+   and 99th percentiles MAY be presented in a two-dimensional table
+   where the dimensions are the proportion of the repeated domain names
+   and the proportion of the DNS names having AAAA records.  The two
+   table headings SHOULD contain these percentage values.
+   Alternatively, the results MAY be presented as a corresponding two-
+   dimensional graph.  In this case, the graph SHOULD show the median
+   values with the percentiles as error bars.  From both the table and
+   the graph, one-dimensional excerpts MAY be made at any given fixed-
+   percentage value of the other dimension.  In this case, the fixed
+   value MUST be given together with a one-dimensional table or graph.
+
+9.2.1.  Requirements for the Tester
+
+   Before a Tester can be used for testing a DUT at rate r queries per
+   second with t seconds timeout, it MUST perform a self-test in order
+   to exclude the possibility that the poor performance of the Tester
+   itself influences the results.  To perform a self-test, the Tester is
+   looped back (leaving out DUT), and its authoritative DNS server
+   subsystem is configured to be able to answer all the AAAA record
+   queries.  To pass the self-test, the Tester SHOULD be able to answer
+   AAAA record queries at rate of 2*(r+delta) within a 0.25*t timeout,
+   where the value of delta is at least 0.1.
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 18]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   Explanation: When performing DNS64 testing, each AAAA record query
+   may result in at most two queries sent by the DUT: the first for a
+   AAAA record and the second for an A record (they are both sent when
+   there is no cache hit and also no AAAA record exists).  The
+   parameters above guarantee that the authoritative DNS server
+   subsystem of the DUT is able to answer the queries at the required
+   frequency using up not more than half of the timeout time.
+
+   Note: A sample open-source test program, dns64perf++, is available
+   from [Dns64perf] and is documented in [Lencse2].  It implements only
+   the client part of the Tester and should be used together with an
+   authoritative DNS server implementation, e.g., BIND, NSD, or YADIFA.
+   Its experimental extension for testing caching is available from
+   [Lencse3] and is documented in [Lencse4].
+
+10.  Overload Scalability
+
+   Scalability has been often discussed; however, in the context of
+   network devices, a formal definition or a measurement method has not
+   yet been proposed.  In this context, we can define overload
+   scalability as the ability of each transition technology to
+   accommodate network growth.  Poor scalability usually leads to poor
+   performance.  Considering this, overload scalability can be measured
+   by quantifying the network performance degradation associated with an
+   increased number of network flows.
+
+   The following subsections describe how the test setups can be
+   modified to create network growth and how the associated performance
+   degradation can be quantified.
+
+10.1.  Test Setup
+
+   The test setups defined in Section 4 have to be modified to create
+   network growth.
+
+10.1.1.  Single-Translation Transition Technologies
+
+   In the case of single-translation transition technologies, the
+   network growth can be generated by increasing the number of network
+   flows (NFs) generated by the Tester machine (see Figure 4).
+
+
+
+
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 19]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+                        +-------------------------+
+           +------------|NF1                   NF1|<-------------+
+           |  +---------|NF2      Tester       NF2|<----------+  |
+           |  |      ...|                         |           |  |
+           |  |   +-----|NFn                   NFn|<------+   |  |
+           |  |   |     +-------------------------+       |   |  |
+           |  |   |                                       |   |  |
+           |  |   |     +-------------------------+       |   |  |
+           |  |   +---->|NFn                   NFn|-------+   |  |
+           |  |      ...|           DUT           |           |  |
+           |  +-------->|NF2    (translator)   NF2|-----------+  |
+           +----------->|NF1                   NF1|--------------+
+                        +-------------------------+
+
+                 Figure 4: Test Setup 4 (Single DUT with Increased
+                              Network Flows)
+
+10.1.2.  Encapsulation and Double-Translation Transition Technologies
+
+   Similarly, for the encapsulation and double-translation transition
+   technologies, a multi-flow setup is recommended.  Considering a
+   multipoint-to-point scenario, for most transition technologies, one
+   of the edge nodes is designed to support more than one connecting
+   device.  Hence, the recommended test setup is an n:1 design, where n
+   is the number of client DUTs connected to the same server DUT (see
+   Figure 5).
+
+                          +-------------------------+
+     +--------------------|NF1                   NF1|<--------------+
+     |  +-----------------|NF2      Tester       NF2|<-----------+  |
+     |  |              ...|                         |            |  |
+     |  |   +-------------|NFn                   NFn|<-------+   |  |
+     |  |   |             +-------------------------+        |   |  |
+     |  |   |                                                |   |  |
+     |  |   |    +-----------------+    +---------------+    |   |  |
+     |  |   +--->| NFn  DUT n  NFn |--->|NFn         NFn| ---+   |  |
+     |  |        +-----------------+    |               |        |  |
+     |  |     ...                       |               |        |  |
+     |  |        +-----------------+    |     DUT n+1   |        |  |
+     |  +------->| NF2  DUT 2  NF2 |--->|NF2         NF2|--------+  |
+     |           +-----------------+    |               |           |
+     |           +-----------------+    |               |           |
+     +---------->| NF1  DUT 1  NF1 |--->|NF1         NF1|-----------+
+                 +-----------------+    +---------------+
+
+                Figure 5: Test Setup 5 (DUAL DUT with Increased
+                             Network Flows)
+
+
+
+
+Georgescu, et al.             Informational                    [Page 20]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   This test setup can help to quantify the scalability of the server
+   device.  However, for testing the overload scalability of the client
+   DUTs, additional recommendations are needed.
+
+   For encapsulation transition technologies, an m:n setup can be
+   created, where m is the number of flows applied to the same client
+   device and n the number of client devices connected to the same
+   server device.
+
+   For translation-based transition technologies, the client devices can
+   be separately tested with n network flows using the test setup
+   presented in Figure 4.
+
+10.2.  Benchmarking Performance Degradation
+
+10.2.1.  Network Performance Degradation with Simultaneous Load
+
+   Objective: To quantify the performance degradation introduced by n
+   parallel and simultaneous network flows.
+
+   Procedure: First, the benchmarking tests presented in Section 7 have
+   to be performed for one network flow.
+
+   The same tests have to be repeated for n network flows, where the
+   network flows are started simultaneously.  The performance
+   degradation of the X benchmarking dimension SHOULD be calculated as
+   relative performance change between the 1-flow (single flow) results
+   and the n-flow results, using the following formula:
+
+               Xn - X1
+       Xpd = ----------- * 100, where: X1 = result for 1-flow
+                  X1                   Xn = result for n-flows
+
+   This formula SHOULD be applied only for "lower is better" benchmarks
+   (e.g., latency).  For "higher is better" benchmarks (e.g.,
+   throughput), the following formula is RECOMMENDED:
+
+               X1 - Xn
+       Xpd = ----------- * 100, where: X1 = result for 1-flow
+                  X1                   Xn = result for n-flows
+
+   As a guideline for the maximum number of flows n, the value can be
+   deduced by measuring the Concurrent TCP Connection Capacity as
+   described by [RFC3511], following the test setups specified by
+   Section 4.
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 21]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   Reporting Format: The performance degradation SHOULD be expressed as
+   a percentage.  The number of tested parallel flows n MUST be clearly
+   specified.  For each of the performed benchmarking tests, there
+   SHOULD be a table containing a column for each frame size.  The table
+   SHOULD also state the applied frame rate.  In the case of benchmarks
+   for which more than one value is reported (e.g., IPDV, discussed in
+   Section 7.3.2), a column for each of the values SHOULD be included.
+
+10.2.2.  Network Performance Degradation with Incremental Load
+
+   Objective: To quantify the performance degradation introduced by n
+   parallel and incrementally started network flows.
+
+   Procedure: First, the benchmarking tests presented in Section 7 have
+   to be performed for one network flow.
+
+   The same tests have to be repeated for n network flows, where the
+   network flows are started incrementally in succession, each after
+   time t.  In other words, if flow i is started at time x, flow i+1
+   will be started at time x+t.  Considering the time t, the time
+   duration of each iteration must be extended with the time necessary
+   to start all the flows, namely, (n-1)xt.  The measurement for the
+   first flow SHOULD be at least 60 seconds in duration.
+
+   The performance degradation of the x benchmarking dimension SHOULD be
+   calculated as relative performance change between the 1-flow results
+   and the n-flow results, using the formula presented in
+   Section 10.2.1.  Intermediary degradation points for 1/4*n, 1/2*n,
+   and 3/4*n MAY also be performed.
+
+   Reporting Format: The performance degradation SHOULD be expressed as
+   a percentage.  The number of tested parallel flows n MUST be clearly
+   specified.  For each of the performed benchmarking tests, there
+   SHOULD be a table containing a column for each frame size.  The table
+   SHOULD also state the applied frame rate and time duration T, which
+   is used as an incremental step between the network flows.  The units
+   of measurement for T SHOULD be seconds.  A column for the
+   intermediary degradation points MAY also be displayed.  In the case
+   of benchmarks for which more than one value is reported (e.g., IPDV,
+   discussed in Section 7.3.2), a column for each of the values SHOULD
+   be included.
+
+11.  NAT44 and NAT66
+
+   Although these technologies are not the primary scope of this
+   document, the benchmarking methodology associated with single-
+   translation technologies as defined in Section 4.1 can be employed to
+
+
+
+
+Georgescu, et al.             Informational                    [Page 22]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   benchmark implementations that use NAT44 (as defined by [RFC2663]
+   with the behavior described by [RFC7857]) and implementations that
+   use NAT66 (as defined by [RFC6296]).
+
+12.  Summarizing Function and Variation
+
+   To ensure the stability of the benchmarking scores obtained using the
+   tests presented in Sections 7 through 9, multiple test iterations are
+   RECOMMENDED.  Using a summarizing function (or measure of central
+   tendency) can be a simple and effective way to compare the results
+   obtained across different iterations.  However, over-summarization is
+   an unwanted effect of reporting a single number.
+
+   Measuring the variation (dispersion index) can be used to counter the
+   over-summarization effect.  Empirical data obtained following the
+   proposed methodology can also offer insights on which summarizing
+   function would fit better.
+
+   To that end, data presented in [ietf95pres] indicate the median as a
+   suitable summarizing function and the 1st and 99th percentiles as
+   variation measures for DNS Resolution Performance and PDV.  The
+   median and percentile calculation functions SHOULD follow the
+   recommendations of Section 11.3 of [RFC2330].
+
+   For a fine-grained analysis of the frequency distribution of the
+   data, histograms or cumulative distribution function plots can be
+   employed.
+
+13.  Security Considerations
+
+   Benchmarking activities as described in this memo are limited to
+   technology characterization using controlled stimuli in a laboratory
+   environment, with dedicated address space and the constraints
+   specified in the sections above.
+
+   The benchmarking network topology will be an independent test setup
+   and MUST NOT be connected to devices that may forward the test
+   traffic into a production network or misroute traffic to the test
+   management network.
+
+   Further, benchmarking is performed on a "black-box" basis, relying
+   solely on measurements observable external to the DUT or System Under
+   Test (SUT).  Special capabilities SHOULD NOT exist in the DUT/SUT
+   specifically for benchmarking purposes.  Any implications for network
+   security arising from the DUT/SUT SHOULD be identical in the lab and
+   in production networks.
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 23]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+14.  IANA Considerations
+
+   The IANA has allocated the prefix 2001:2::/48 [RFC5180] for IPv6
+   benchmarking.  For IPv4 benchmarking, the 198.18.0.0/15 prefix was
+   reserved, as described in [RFC6890].  The two ranges are sufficient
+   for benchmarking IPv6 transition technologies.  Thus, no action is
+   requested.
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC1242]  Bradner, S., "Benchmarking Terminology for Network
+              Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
+              July 1991, <http://www.rfc-editor.org/info/rfc1242>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+              "Framework for IP Performance Metrics", RFC 2330,
+              DOI 10.17487/RFC2330, May 1998,
+              <http://www.rfc-editor.org/info/rfc2330>.
+
+   [RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
+              Network Interconnect Devices", RFC 2544,
+              DOI 10.17487/RFC2544, March 1999,
+              <http://www.rfc-editor.org/info/rfc2544>.
+
+   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
+              Metric for IP Performance Metrics (IPPM)", RFC 3393,
+              DOI 10.17487/RFC3393, November 2002,
+              <http://www.rfc-editor.org/info/rfc3393>.
+
+   [RFC3511]  Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
+              "Benchmarking Methodology for Firewall Performance",
+              RFC 3511, DOI 10.17487/RFC3511, April 2003,
+              <http://www.rfc-editor.org/info/rfc3511>.
+
+   [RFC5180]  Popoviciu, C., Hamza, A., Van de Velde, G., and D.
+              Dugatkin, "IPv6 Benchmarking Methodology for Network
+              Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180,
+              May 2008, <http://www.rfc-editor.org/info/rfc5180>.
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 24]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
+              Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
+              March 2009, <http://www.rfc-editor.org/info/rfc5481>.
+
+   [RFC6201]  Asati, R., Pignataro, C., Calabria, F., and C. Olvera,
+              "Device Reset Characterization", RFC 6201,
+              DOI 10.17487/RFC6201, March 2011,
+              <http://www.rfc-editor.org/info/rfc6201>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <http://www.rfc-editor.org/info/rfc8174>.
+
+15.2.  Informative References
+
+   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations",
+              RFC 2663, DOI 10.17487/RFC2663, August 1999,
+              <http://www.rfc-editor.org/info/rfc2663>.
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213,
+              DOI 10.17487/RFC4213, October 2005,
+              <http://www.rfc-editor.org/info/rfc4213>.
+
+   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
+              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
+              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
+              <http://www.rfc-editor.org/info/rfc4659>.
+
+   [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
+              "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
+              Provider Edge Routers (6PE)", RFC 4798,
+              DOI 10.17487/RFC4798, February 2007,
+              <http://www.rfc-editor.org/info/rfc4798>.
+
+   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4
+              Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
+              January 2010, <http://www.rfc-editor.org/info/rfc5569>.
+
+   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
+              April 2011, <http://www.rfc-editor.org/info/rfc6144>.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
+              April 2011, <http://www.rfc-editor.org/info/rfc6146>.
+
+
+
+Georgescu, et al.             Informational                    [Page 25]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+              Beijnum, "DNS64: DNS Extensions for Network Address
+              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+              DOI 10.17487/RFC6147, April 2011,
+              <http://www.rfc-editor.org/info/rfc6147>.
+
+   [RFC6219]  Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
+              China Education and Research Network (CERNET) IVI
+              Translation Design and Deployment for the IPv4/IPv6
+              Coexistence and Transition", RFC 6219,
+              DOI 10.17487/RFC6219, May 2011,
+              <http://www.rfc-editor.org/info/rfc6219>.
+
+   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
+              Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
+              <http://www.rfc-editor.org/info/rfc6296>.
+
+   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
+              <http://www.rfc-editor.org/info/rfc6333>.
+
+   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
+              Combination of Stateful and Stateless Translation",
+              RFC 6877, DOI 10.17487/RFC6877, April 2013,
+              <http://www.rfc-editor.org/info/rfc6877>.
+
+   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
+              "Special-Purpose IP Address Registries", BCP 153,
+              RFC 6890, DOI 10.17487/RFC6890, April 2013,
+              <http://www.rfc-editor.org/info/rfc6890>.
+
+   [RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
+              Farrer, "Lightweight 4over6: An Extension to the Dual-
+              Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
+              July 2015, <http://www.rfc-editor.org/info/rfc7596>.
+
+   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
+              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
+              Port with Encapsulation (MAP-E)", RFC 7597,
+              DOI 10.17487/RFC7597, July 2015,
+              <http://www.rfc-editor.org/info/rfc7597>.
+
+   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
+              and T. Murakami, "Mapping of Address and Port using
+              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
+              2015, <http://www.rfc-editor.org/info/rfc7599>.
+
+
+
+
+Georgescu, et al.             Informational                    [Page 26]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   [RFC7857]  Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
+              S., and K. Naito, "Updates to Network Address Translation
+              (NAT) Behavioral Requirements", BCP 127, RFC 7857,
+              DOI 10.17487/RFC7857, April 2016,
+              <http://www.rfc-editor.org/info/rfc7857>.
+
+   [RFC7915]  Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
+              "IP/ICMP Translation Algorithm", RFC 7915,
+              DOI 10.17487/RFC7915, June 2016,
+              <http://www.rfc-editor.org/info/rfc7915>.
+
+   [Dns64perf]
+              Bakai, D., "A C++11 DNS64 performance tester",
+              <https://github.com/bakaid/dns64perfpp>.
+
+   [ietf95pres]
+              Georgescu, M., "Benchmarking Methodology for IPv6
+              Transition Technologies", IETF 95 Proceedings, Buenos
+              Aires, Argentina, April 2016,
+              <https://www.ietf.org/proceedings/95/slides/
+              slides-95-bmwg-2.pdf>.
+
+   [Lencse1]  Lencse, G., Georgescu, M., and Y. Kadobayashi,
+              "Benchmarking Methodology for DNS64 Servers", Computer
+              Communications, vol. 109, no. 1, pp. 162-175,
+              DOI 10.1016/j.comcom.2017.06.004, September 2017,
+              <http://www.sciencedirect.com/science/article/pii/
+              S0140366416305904?via%3Dihub>
+
+   [Lencse2]  Lencse, G. and D. Bakai, "Design and Implementation of a
+              Test Program for Benchmarking DNS64 Servers", IEICE
+              Transactions on Communications, Vol. E100-B, No. 6,
+              pp. 948-954, DOI 10.1587/transcom.2016EBN0007, June 2017,
+              <https://www.jstage.jst.go.jp/article/transcom/E100.B/
+              6/E100.B_2016EBN0007/_article>.
+
+   [Lencse3]  dns64perfppc,
+              <http://www.hit.bme.hu/~lencse/dns64perfppc/>.
+
+   [Lencse4]  Lencse, G., "Enabling Dns64perf++ for Benchmarking the
+              Caching Performance of DNS64 Servers", unpublished, review
+              version, <http://www.hit.bme.hu/~lencse/publications/
+              IEICE-2016-dns64perfppc-for-review.pdf>.
+
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 27]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+   [IEEE802.1AC]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks -- Media Access Control (MAC) Service
+              Definition", IEEE 802.1AC.
+
+   [IEEE802.1Q]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks -- Bridges and Bridged Networks", IEEE Std
+              802.1Q.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 28]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+Appendix A.  Theoretical Maximum Frame Rates
+
+   This appendix describes the recommended calculation formulas for the
+   theoretical maximum frame rates to be employed over Ethernet as
+   example media.  The formula takes into account the frame size
+   overhead created by the encapsulation or translation process.  For
+   example, the 6in4 encapsulation described in [RFC4213] adds 20 bytes
+   of overhead to each frame.
+
+   Considering X to be the frame size and O to be the frame size
+   overhead created by the encapsulation or translation process, the
+   maximum theoretical frame rate for Ethernet can be calculated using
+   the following formula:
+
+                Line Rate (bps)
+         ------------------------------------
+         (8 bits/byte) * (X+O+20) bytes/frame
+
+   The calculation is based on the formula recommended by [RFC5180] in
+   Appendix A.1.  As an example, the frame rate recommended for testing
+   a 6in4 implementation over 10 Mb/s Ethernet with 64 bytes frames is:
+
+                10,000,000 (bps)
+         --------------------------------------  = 12,019 fps
+         (8 bits/byte) * (64+20+20) bytes/frame
+
+   The complete list of recommended frame rates for 6in4 encapsulation
+   can be found in the following table:
+
+   +------------+---------+----------+-----------+------------+
+   | Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s |
+   | (bytes)    | (fps)   | (fps)    | (fps)     | (fps)      |
+   +------------+---------+----------+-----------+------------+
+   | 64         | 12,019  | 120,192  | 1,201,923 | 12,019,231 |
+   | 128        | 7,440   | 74,405   | 744,048   | 7,440,476  |
+   | 256        | 4,223   | 42,230   | 422,297   | 4,222,973  |
+   | 512        | 2,264   | 22,645   | 226,449   | 2,264,493  |
+   | 678        | 1,740   | 17,409   | 174,094   | 1,740,947  |
+   | 1024       | 1,175   | 11,748   | 117,481   | 1,174,812  |
+   | 1280       | 947     | 9,470    | 94,697    | 946,970    |
+   | 1518       | 802     | 8,023    | 80,231    | 802,311    |
+   | 1522       | 800     | 8,003    | 80,026    | 800,256    |
+   | 2048       | 599     | 5,987    | 59,866    | 598,659    |
+   | 4096       | 302     | 3,022    | 30,222    | 302,224    |
+   | 8192       | 152     | 1,518    | 15,185    | 151,846    |
+   | 9216       | 135     | 1,350    | 13,505    | 135,048    |
+   +------------+---------+----------+-----------+------------+
+
+
+
+
+Georgescu, et al.             Informational                    [Page 29]
+
+RFC 8219      Benchmarking for IPv6 Transition Technologies  August 2017
+
+
+Acknowledgements
+
+   The authors thank Youki Kadobayashi and Hiroaki Hazeyama for their
+   constant feedback and support.  The thanks should be extended to the
+   NECOMA project members for their continuous support.  We thank
+   Emanuel Popa, Ionut Spirlea, and the RCS&RDS IP/MPLS Backbone Team
+   for their support and insights.  We thank Scott Bradner for the
+   useful suggestions and note that portions of text from Scott's
+   documents were used in this memo (e.g., the "Latency" section).  A
+   big thank you to Al Morton and Fred Baker for their detailed review
+   of the document and very helpful suggestions.  Other helpful comments
+   and suggestions were offered by Bhuvaneswaran Vengainathan, Andrew
+   McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka
+   Mawatari, Kostas Pentikousis, Bela Almasi, Tim Chown, Paul Emmerich,
+   and Stenio Fernandes.  A special thank you to the RFC Editor Team for
+   their thorough editorial review and helpful suggestions.
+
+Authors' Addresses
+
+   Marius Georgescu
+   RCS&RDS
+   Strada Dr. Nicolae D. Staicovici 71-75
+   Bucharest 030167
+   Romania
+
+   Phone: +40 31 005 0979
+   Email: marius.georgescu@rcs-rds.ro
+
+
+   Liviu Pislaru
+   RCS&RDS
+   Strada Dr. Nicolae D. Staicovici 71-75
+   Bucharest 030167
+   Romania
+
+   Phone: +40 31 005 0979
+   Email: liviu.pislaru@rcs-rds.ro
+
+
+   Gabor Lencse
+   Szechenyi Istvan University
+   Egyetem ter 1.
+   Gyor
+   Hungary
+
+   Phone: +36 20 775 8267
+   Email: lencse@sze.hu
+
+
+
+
+Georgescu, et al.             Informational                    [Page 30]
+