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
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
IPv6过渡技术的基准测试方法
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.
针对支持IPv4或IPv6的网络互连设备的性能的基准测试方法已经存在，但IPv6过渡技术超出了它们的范围。本文档提供了评估IPv6过渡技术性能的补充指南。更具体地说，本文档针对采用封装或转换机制的IPv6转换技术，因为可以使用RFCs 2544和5180的建议测试双堆栈节点。该方法还包括一个用于测试负载可伸缩性的指标。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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 ................................................30
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
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.
[RFC2544]和[RFC5180]中描述的方法有助于供应商和网络运营商分析支持IPv4和IPv6的网络设备的性能。[RFC2544]中介绍的方法主要与IP版本无关，而[RFC5180]中包含针对最新IP版本IPv6的补充建议。但是，[RFC5180]不包括IPv6转换技术。
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.
IPv6不向后兼容，这意味着仅IPv4的节点无法直接与仅IPv6的节点通信。为了解决这个问题，人们提出并实现了IPv6过渡技术。
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.
本文档介绍了专用于IPv6过渡技术的基准测试指南。基准测试可以深入了解这些技术的性能，这可以作为开发人员和网络运营商在IPv6过渡过程中的有用反馈。
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.
该文件还包括一种量化过载运行时性能的方法。过载可伸缩性可以定义为系统能够优雅地容纳比被测设备（DUT）能够正常运行的最大流数量更多的流。这里采用的方法是通过测量过多网络流产生的性能，并将性能与非过载情况进行比较，来量化过载可伸缩性。
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.
[RFC4213]中介绍了两种基本的转换技术，即双IP层（也称为双堆栈）和封装。[RFC6144]中介绍了IPv4/IPv6转换。大多数过渡技术至少采用这些机制的一种变体。在这种情况下，对过渡技术进行一般分类可能是有用的。
We can consider a production network transitioning to IPv6 as being constructed using the following IP domains:
我们可以考虑将生产网络转换成IPv6，因为使用以下IP域构建：
o Domain A: IPvX-specific domain
o 域A：IPvX特定域
o Core domain: IPvY-specific or dual-stack (IPvX and IPvY) domain
o 核心域：IPvY特定或双堆栈（IPvX和IPvY）域
o Domain B: IPvX-specific domain
o 域B：IPvX特定域
Note: X,Y are part of the set {4,6}, and X is NOT EQUAL to Y.
注：X，Y是集合{4,6}的一部分，X不等于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.
1. 双栈：核心域中的设备实现两种IP协议。
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.
2. 单一翻译：在这种情况下，生产网络假定只有两个域：域A和核心域。假设核心域是特定于IPvY的。IPvX数据包在域A和核心域之间的边缘转换为IPvY。
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.
3. 双重翻译：假设生产网络具有所有三个域；域A和B特定于IPvX，而核心域特定于IPvY。核心网络的遍历采用了转换机制。IPvX数据包在域A和核心域之间的边缘被转换为IPvY数据包。随后，IPvY数据包在核心域和域B之间的边缘被转换回IPvX。
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.
4. 封装：假设生产网络具有所有三个域；域A和B特定于IPvX，而核心域特定于IPvY。封装机制用于遍历核心域。IPvX数据包在域A和核心域之间的边缘封装为IPvY数据包。随后，IPvY分组在核心域和域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.
可以使用[RFC2544]和[RFC5180]提出的基准测试方法全面评估双堆栈转换技术的性能。因此，本文档重点关注其他三类：单翻译、双翻译和封装转换技术。
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
IPv6转换技术的另一个重要分类是使用有状态或无状态映射算法。使用有状态映射算法的技术（例如，有状态
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.
NAT64[RFC6146]）在存储在状态表中的IP地址或{IP地址、传输协议、传输端口号}元组之间创建动态关联。为便于参考，采用有状态映射算法的IPv6转换技术将被称为“有状态IPv6转换技术”。管理状态表的效率可以作为这些技术的一个重要性能指标。因此，建议对有状态IPv6转换技术进行额外的基准测试。
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.
表1包含IETF中提出的一些IPv6过渡技术的一般类别和关联。请注意，该列表并非详尽无遗。
+---+--------------------+------------------------------------+
| | 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] |
+---+--------------------+------------------------------------+
+---+--------------------+------------------------------------+
| | 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
表1:IPv6过渡技术类别
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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.
尽管这些术语通常与协议要求相关，但在本文件中，这些术语是对打算实施测试条件并声称符合本规范的用户和系统的要求。
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.
本备忘录中使用的许多术语已在其他RFC中定义。有关定义、测试程序和报告格式，请参考以下RFC。
o Throughput (Benchmark) [RFC2544]
o 吞吐量（基准）[RFC2544]
o Frame Loss Rate (Benchmark) [RFC2544]
o 帧丢失率（基准）[RFC2544]
o Back-to-Back Frames (Benchmark) [RFC2544]
o 背对背帧（基准）[RFC2544]
o System Recovery (Benchmark) [RFC2544]
o 系统恢复（基准）[RFC2544]
o Reset (Benchmark) [RFC6201]
o 重置（基准）[RFC6201]
o Concurrent TCP Connection Capacity (Benchmark) [RFC3511]
o 并发TCP连接容量（基准）[RFC3511]
o Maximum TCP Connection Establishment Rate (Benchmark) [RFC3511]
o 最大TCP连接建立速率（基准）[RFC3511]
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.
建议用于基准测试IPv6过渡技术的测试环境设置选项与[RFC2544]第6节中介绍的选项非常相似。在测试仪设置的情况下，[RFC2544]和[RFC5180]中提供的选项也可以应用于此处。但是，DUT设置选项应在IPv6转换技术的目标类别（单翻译、双翻译和封装）的上下文中进行解释。
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.
尽管单个测试仪和发送器/接收器设置均适用于此方法，但单个测试仪设置将用于描述DUT设置选项。
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.
对于本备忘录中介绍的测试设置，应采用动态路由。然而，路由和管理框架的存在可能表示可能影响基准测试结果的不需要的背景数据。为此，此处应使用[RFC2544]第11.2节和第11.3节中定义的与路由和管理框架相关的程序。此外，[RFC2544]第23节中提出的“试验说明”建议也适用于本备忘录。
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.
就路由设置而言，[RFC2544]第13节的建议适用于本文件，前提是使用支持IPv6的路由协议。
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.
对于单翻译转换技术的评估，应使用单DUT设置（见图1）。DUT负责将IPvX数据包转换为IPvY数据包。在这种情况下，测试仪设备应配置为同时支持IPvX和IPvY。
+--------------------+
| |
+------------|IPvX Tester IPvY|<-------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ |
| | | |
+----------->|IPvX DUT IPvY|--------------+
| |
+--------------------+
+--------------------+
| |
+------------|IPvX Tester IPvY|<-------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ |
| | | |
+----------->|IPvX DUT IPvY|--------------+
| |
+--------------------+
Figure 1: Test Setup 1 (Single DUT)
图1：测试设置1（单个DUT）
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.
为了评估封装和双转换转换技术的性能，应采用双DUT设置（见图2）。测试仪创建IPvX数据包的网络流。第一个DUT负责将IPvX数据包封装或转换为IPvY数据包。IPvY数据包由第二个DUT反封装/转换回IPvX数据包，并转发至测试仪。
+--------------------+
| |
+---------------------|IPvX Tester IPvX|<------------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ +--------------------+ |
| | | | | |
+----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+
| | | |
+--------------------+ +--------------------+
+--------------------+
| |
+---------------------|IPvX Tester IPvX|<------------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ +--------------------+ |
| | | | | |
+----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+
| | | |
+--------------------+ +--------------------+
Figure 2: Test Setup 2 (Dual DUT)
图2：测试设置2（双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.
双DUT设置的限制之一是无法反映DUT之间行为的不对称性。考虑到这一点，应使用单个DUT设置进行额外的性能测试。
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.
注：对于单个DUT设置中的封装IPv6转换技术，测试仪应能够发送封装为IPvY的IPvX数据包，以测试解封效率。
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.
测试流量代表实验工作量，应满足本节规定的要求。这些要求专用于单播IP流量。多播IP通信不在本文档的范围内。
[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.
[RFC5180]描述了两种常用媒体类型的帧大小要求：以太网和SONET（同步光网络）。[RFC2544]还包括其他媒体类型，如令牌环和光纤分布式数据接口（FDDI）。这两份文件的建议可用于双堆栈转换技术。对于其余的转换技术，必须考虑由转换或封装引入的帧开销。
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.
封装/转换过程在测试设置的不同段上生成不同大小的帧。例如，当IPvX数据包被转换为IPvY时，单一转换转换技术将在测试设置的接收段上创建不同的帧大小。如果未超过所使用媒体的带宽，则这不是问题。为了防止超过媒体施加的限制，在计算最大理论帧速率时，需要考虑帧大小开销。以太网的计算方法以及计算示例详见附录a。所有测试报告中必须注明基准测试所用介质的详细信息。
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.
在帧大小开销方面，需要MTU建议，以避免由于虚拟封装/转换接口和物理网络接口控制器（NIC）之间的MTU不匹配而导致的帧丢失。为避免这种情况，应为DUT和测试仪的所有接口设置物理NIC和虚拟封装/转换接口之间较大的MTU。
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.
更具体地说，对于物理接口和虚拟接口，建议使用最小IPv6 MTU大小（1280字节）加上封装/转换开销。
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.
根据[RFC5180]的建议，应使用以下帧大小对以太网链路上的IPvX/IPvY流量进行基准测试：64、128、256、512、768、1024、1280、1518、1522、2048、4096、8192和9216。
For Ethernet frames exceeding 1500 bytes in size, the [IEEE802.1AC] standard can be consulted.
对于尺寸超过1500字节的以太网帧，可参考[IEEE802.1AC]标准。
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.
注意：对于IPv6->IPv4转换方向的单转换转换技术（例如NAT64），64字节帧应替换为84字节帧。这将允许帧通过诸如[IEEE802.1Q]标准所述的媒体进行传输。此外，这还允许在UDP数据中实现帧标识符。
The theoretical maximum frame rates considering an example of frame overhead are presented in Appendix A.
附录A中给出了考虑帧开销示例的理论最大帧速率。
The selected protocol addresses should follow the recommendations of Section 5 of [RFC5180] for IPv6 and Section 12 of [RFC2544] for IPv4.
选定的协议地址应遵循[RFC5180]第5节对IPv6的建议和[RFC2544]第12节对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.
注意：对于采用转换的转换技术，使用扩展头测试流量可能是不可能的。提议的IPvX/IPvY转换算法，如IP/ICMP转换[RFC7915]不支持使用扩展头。
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.
按照[RFC5180]的建议，应使用双向通信量执行所述的所有测试。还可以执行单向流量测试以进行细粒度性能评估。
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.
由于UDP的简单性，UDP测量提供了比其他传输层协议更可靠的比较基础。因此，对于本文件第7节中描述的基准测试，应使用UDP通信。
Considering that a transition technology could process both native IPv6 traffic and translated/encapsulated traffic, the following traffic setups are recommended:
考虑到转换技术可以处理本机IPv6流量和转换/封装流量，建议采用以下流量设置：
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
i) 仅IPvX流量（其中IPvX流量由DUT转换/封装）ii）90%IPvX流量和10%IPvY本机流量iii）50%IPvX流量和50%IPvY本机流量iv）10%IPvX流量和90%IPvY本机流量
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].
对于本备忘录第8节（并发TCP连接容量和最大TCP连接建立率）中包含的有状态IPv6转换技术专用基准，流量应遵循[RFC3511]第5.2.2.2节和第5.3.2.2节的建议。
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.
[RFC2544]第11节首先介绍了在不同操作条件下进行测试的想法，它代表了基准网络元件的一个重要方面，因为它在一定程度上模拟了生产环境的条件。[RFC5180]第6节描述了特定于IPv6的补充测试条件。IPv6转换技术的测试也可以遵循[RFC2544]和[RFC5180]中的建议。
The following sub-sections describe all recommended benchmarking tests.
以下小节描述了所有推荐的基准测试。
Use Section 26.1 of [RFC2544] unmodified.
未经修改，使用[RFC2544]第26.1节。
Objective: To determine the latency. Typical latency is based on the definitions of latency from [RFC1242]. However, this memo provides a new measurement procedure.
目的：确定潜伏期。典型延迟基于[RFC1242]中的延迟定义。然而，本备忘录提供了一个新的测量程序。
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.
程序：与[RFC2544]类似，应确定每个所列帧尺寸下DUT的吞吐量。以确定的吞吐量通过DUT将特定帧大小的帧流发送到特定目的地。流的持续时间应至少为120秒。
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.
识别标签应在60秒后至少包含在500帧中。对于每个标记的帧，必须记录帧被完全传输的时间（时间戳A）和帧被接收的时间（时间戳B）。根据RFC 1242的相关定义，延迟是时间戳B减去时间戳A，即，为存储和转发设备定义的延迟或为比特转发设备定义的延迟。
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.
我们建议在帧的有效负载中对标识标记进行编码。更确切地说，标识符应该插入UDP头之后。
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:
根据产生的（至少500）延迟，应计算两个数量。一个是典型的延迟，应使用以下公式计算：
TL = Median(Li)
TL=中值（Li）
Where:
哪里：
o TL = the reported typical latency of the stream
o TL=报告的流的典型延迟
o Li = the latency for tagged frame i
o Li=标记帧i的延迟
The other measure is the worst-case latency, which SHOULD be calculated with the following formula:
另一个度量是最坏情况下的延迟，应使用以下公式计算：
WCL = L99.9thPercentile
WCL=L99.9百分位
Where:
哪里：
o WCL = the reported worst-case latency
o WCL=报告的最坏情况延迟
o L99.9thPercentile = the 99.9th percentile of the stream-measured latencies
o L99.9thPercentile=流测量潜伏期的99.9%
The test MUST be repeated at least 20 times with the reported value being the median of the recorded values for TL and WCL.
试验必须重复至少20次，报告值为TL和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
报告格式：报告必须说明此测试使用的延迟定义（来自RFC 1242）。应以表格的形式报告总结的延迟结果，表格中的每一个测试帧大小对应一行。应该有以下列：帧大小、针对该帧大小运行延迟测试的速率、测试的媒体类型、产生的典型延迟，以及测试的每种数据流类型的最坏情况延迟值。为了解释这种变化，20个样本中的第1个和第99个百分位
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.
迭代可以在两个单独的列中报告。对于细粒度分析，可显示其中一次迭代的直方图（如[RFC5481]第4.4节所示）。
[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.
[RFC5481]提出了两个指标：数据包延迟变化（PDV）和数据包间延迟变化（IPDV）。建议测量PDV；对于延迟变化的细粒度分析，可以执行IPDV测量。
Objective: To determine the Packet Delay Variation as defined in [RFC5481].
目标：确定[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:
程序：如[RFC2544]所述，首先确定所列帧尺寸下DUT的吞吐量。以确定的吞吐量通过DUT将特定帧大小的帧流发送到特定目的地。流的持续时间应至少为60秒。测量流中所有帧的单向延迟，如[RFC3393]所述。使用以下公式计算流的PDV：
PDV = D99.9thPercentile - Dmin
PDV=D99.9百分位-Dmin
Where:
哪里：
o D99.9thPercentile = the 99.9th percentile (as described in [RFC5481]) of the one-way delay for the stream
o D99.9thPercentile=流单向延迟的99.9%（如[RFC5481]中所述）
o Dmin = the minimum one-way delay in the stream
o Dmin=流中的最小单向延迟
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.
按照[RFC2544]中的建议，试验必须重复至少20次，报告值为记录值的中值。此外，应计算第1百分位和第99百分位，以说明数据集的变化。
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.
报告格式：PDV结果应报告在一个表格中，表格中的每一行用于测试的帧大小，列用于测试的媒体类型的帧大小和应用的帧速率。可显示第1和第99百分位值的两列。根据[RFC5481]的建议，建议的测量单位为毫秒。
Objective: To determine the Inter Packet Delay Variation as defined in [RFC5481].
目标：确定[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:
程序：如[RFC2544]所述，首先确定所列帧尺寸下DUT的吞吐量。以确定的吞吐量通过DUT将特定帧大小的帧流发送到特定目的地。流的持续时间应至少为60秒。测量流中所有帧的单向延迟，如[RFC3393]所述。使用以下公式计算每个帧的IPDV：
IPDV(i) = D(i) - D(i-1)
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）=流中第i帧的单向延迟
o D(i-1) = the one-way delay of (i-1)th frame in the stream
o D（i-1）=流中第（i-1）帧的单向延迟
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.
鉴于IPDV的性质，报告单个数字可能会导致过度汇总。在这种情况下，每个测量的报告应包括三个值：Dmin、Dmed和Dmax。
Where:
哪里：
o Dmin = the minimum IPDV in the stream
o Dmin=流中的最小IPDV
o Dmed = the median IPDV of the stream
o Dmed=流的中值IPDV
o Dmax = the maximum IPDV in the stream
o Dmax=流中的最大IPDV
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.
试验必须重复至少20次。为了总结这20次重复，对于三次重复中的每一次（Dmin、Dmed和Dmax），应报告中值。
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.
报告格式：应报告三个建议值的中值。IPDV结果应在一个表格中报告，每个测试帧尺寸对应一行。列应包括测试媒体类型的帧大小和相关帧速率，以及三个建议报告值的子列。根据[RFC5481]的建议，建议的测量单位为毫秒。
Use Section 26.3 of [RFC2544] unmodified.
未经修改，使用[RFC2544]第26.3节。
Use Section 26.4 of [RFC2544] unmodified.
未经修改，使用[RFC2544]第26.4节。
Use Section 26.5 of [RFC2544] unmodified.
未经修改，使用[RFC2544]第26.5节。
Use Section 4 of [RFC6201] unmodified.
未经修改，使用[RFC6201]的第4节。
8. Additional Benchmarking Tests for Stateful IPv6 Transition Technologies
8. 针对有状态IPv6转换技术的其他基准测试
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].
本节介绍专用于有状态IPv6转换技术的其他测试。对于本节所述的试验，DUT设备应遵循[RFC3511]第5.2节和第5.3节中提出的试验设置和试验参数建议。
The following additional tests SHOULD be performed.
应进行以下附加试验。
Use Section 5.2 of [RFC3511] unmodified.
使用未经修改的[RFC3511]第5.2节。
Use Section 5.3 of [RFC3511] unmodified.
使用未经修改的[RFC3511]第5.3节。
This section describes benchmarking tests dedicated to DNS64 (see [RFC6147]), used as DNS support for single-translation technologies such as NAT64.
本节描述了专用于DNS64（参见[RFC6147]）的基准测试，该测试用作对单一翻译技术（如NAT64）的DNS支持。
The test setup in Figure 3 follows the setup proposed for single-translation IPv6 transition technologies in Figure 1.
图3中的测试设置遵循图1中针对单翻译IPv6转换技术提出的设置。
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
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)
图3：测试设置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)
1. 查询域名的AAAA记录（从客户端到DNS64服务器）
2. Query for the AAAA record of the same domain name (from DNS64 server to authoritative DNS server)
2. 查询相同域名的AAAA记录（从DNS64服务器到权威DNS服务器）
3. Empty AAAA record answer (from authoritative DNS server to DNS64 server)
3. 空AAAA记录应答（从权威DNS服务器到DNS64服务器）
4. Query for the A record of the same domain name (from DNS64 server to authoritative DNS server)
4. 查询相同域名的A记录（从DNS64服务器到权威DNS服务器）
5. Valid A record answer (from authoritative DNS server to DNS64 server)
5. 有效的记录应答（从权威DNS服务器到DNS64服务器）
6. Synthesized AAAA record answer (from DNS64 server to client)
6. 合成AAAA记录应答（从DNS64服务器到客户端）
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.
测试人员扮演DNS客户端和权威DNS服务器的角色。它可以实现为单个物理设备，或者，可以使用两个物理设备。
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).
o 如果DNS64服务器实现缓存并且缓存命中，则步骤1之后是步骤6（省略步骤2到5）。
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 如果域名具有AAAA记录，则权威DNS服务器在步骤3中返回该记录，省略步骤4和5，并且DNS64服务器不合成AAAA记录，而是将接收到的AAAA记录返回给客户端。
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.
o 对于测试仪和DUT之间使用的IP版本，必须在客户端和DNS64服务器之间使用IPv6（因为DNS64服务器为仅限IPv6的客户端提供服务），但在DNS64服务器和权威DNS服务器之间可以使用IPv4或IPv6。
Objective: To determine DNS64 performance by means of the maximum number of successfully processed DNS requests per second.
目标：通过每秒成功处理的DNS请求的最大数量来确定DNS64性能。
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].
过程：以特定速率向DUT发送特定数量的DNS查询，然后统计及时收到的来自DUT的回复（在相应查询发送时间的预定义超时时间内，默认值为1秒）以及有效的回复（包含AAAA记录）。如果已发送查询的计数等于已接收回复的计数，则会提高查询的速率，并重新运行测试。如果收到的回复少于发送的查询，则查询的速率将降低，并重新运行测试。每次试验的持续时间应至少为60秒。这将降低DNS64服务器的潜在增益，该服务器能够通过存储请求并因此也利用超时时间来响应请求来展示更高的性能。出于同样的原因，不应使用超过1秒的超时时间。有关更多注意事项，请参见[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.
每秒处理的最大DNS查询数是DUT发送的DNS回复数等于测试设备发送给它的DNS查询数的最快速率。
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.
测试应至少重复20次，并应计算每秒处理的DNS查询数的中位数和第1/99个百分位数。
Details and parameters:
详情及参数：
1. Caching
1. 缓存
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
首先，所有DNS查询必须包含不同的域名（或者在DUT的缓存耗尽之前不得重复域名）。然后，当域名被20%、40%、60%、80%和100%缓存时，可能会执行新的测试。确保记录
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
2. AAAA记录的存在
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.
首先，所有DNS查询必须包含没有AAAA记录且只有一个a记录的域名。然后，当20%、40%、60%、80%和100%的域名具有AAAA记录时，可能会执行新的测试。
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.)
请注意，上述两个条件是正交的；因此，它们的所有组合都是可能的，并且可以进行测试。需要使用0%的缓存域名和0%的现有AAAA记录进行测试，其他组合是可选的。（当缓存所有域名时，结果并不取决于有多少百分比的域名具有AAAA记录；因此，这些组合不值得逐一测试。）
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.
报告格式：DNS64测试的主要结果是每秒使用上述“0%+0%组合”测量的已处理DNS查询数的中位数。中位数应与第1百分位和第99百分位进行补充，以显示结果的稳定性。如果进行了可选测试，中位数和第1和第99个百分位可以在二维表格中显示，其中维度是重复域名的比例和具有AAAA记录的DNS名称的比例。两个表格标题应包含这些百分比值。或者，结果可以表示为相应的二维图。在这种情况下，图表应显示以百分位为误差条的中值。从表格和图表中，可以在其他维度的任何给定固定百分比值下进行一维摘录。在这种情况下，固定值必须与一维表或图一起给出。
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.
在使用测试仪以每秒r次的速度测试DUT（超时时间为t秒）之前，它必须执行自检，以排除测试仪本身性能差影响结果的可能性。为了执行自检，测试仪被环回（不包括DUT），其权威DNS服务器子系统被配置为能够回答所有AAAA记录查询。为了通过自检，测试人员应该能够在0.25*t超时内以2*（r+delta）的速率回答AAAA记录查询，其中delta的值至少为0.1。
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.
说明：在执行DNS64测试时，每个AAAA记录查询最多可导致DUT发送两个查询：第一个查询AAAA记录，第二个查询a记录（它们都是在没有缓存命中且也不存在AAAA记录时发送的）。上述参数保证DUT的权威DNS服务器子系统能够以所需频率回答查询，最多使用不超过一半的超时时间。
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].
注：示例开源测试程序dns64perf++可从[dns64perf]获得，并记录在[Lencse2]中。它只实现测试仪的客户端部分，并且应该与权威DNS服务器实现（例如BIND、NSD或YADIFA）一起使用。其用于测试缓存的实验扩展可从[Lencse3]获得，并在[Lencse4]中进行了记录。
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.
以下小节描述了如何修改测试设置以创建网络增长，以及如何量化相关的性能下降。
The test setups defined in Section 4 have to be modified to create network growth.
必须修改第4节中定义的测试设置，以创建网络增长。
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).
在单翻译转换技术的情况下，可以通过增加测试机生成的网络流（NFs）数量来实现网络增长（见图4）。
+-------------------------+
+------------|NF1 NF1|<-------------+
| +---------|NF2 Tester NF2|<----------+ |
| | ...| | | |
| | +-----|NFn NFn|<------+ | |
| | | +-------------------------+ | | |
| | | | | |
| | | +-------------------------+ | | |
| | +---->|NFn NFn|-------+ | |
| | ...| DUT | | |
| +-------->|NF2 (translator) NF2|-----------+ |
+----------->|NF1 NF1|--------------+
+-------------------------+
+-------------------------+
+------------|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)
图4：测试设置4（网络流量增加的单个DUT）
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).
同样，对于封装和双转换转换技术，建议使用多流设置。考虑到多点对点场景，对于大多数过渡技术，一个边缘节点被设计为支持多个连接设备。因此，推荐的测试设置是n:1设计，其中n是连接到同一服务器DUT的客户端DUT的数量（见图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|-----------+
+-----------------+ +---------------+
+-------------------------+
+--------------------|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)
图5：测试设置5（网络流量增加的双DUT）
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.
此测试设置有助于量化服务器设备的可伸缩性。然而，为了测试客户端DUT的过载可伸缩性，还需要额外的建议。
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.
对于封装转换技术，可以创建m:n设置，其中m是应用于同一客户端设备的流的数量，n是连接到同一服务器设备的客户端设备的数量。
For translation-based transition technologies, the client devices can be separately tested with n network flows using the test setup presented in Figure 4.
对于基于翻译的转换技术，可以使用图4所示的测试设置，使用n个网络流分别测试客户端设备。
Objective: To quantify the performance degradation introduced by n parallel and simultaneous network flows.
目的：量化n个并行和同时网络流引起的性能下降。
Procedure: First, the benchmarking tests presented in Section 7 have to be performed for one network flow.
程序：首先，必须对一个网络流执行第7节中介绍的基准测试。
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:
必须对n个网络流重复相同的测试，其中网络流同时启动。X基准维度的性能退化应使用以下公式计算为单流（单流）结果和n流结果之间的相对性能变化：
Xn - X1
Xpd = ----------- * 100, where: X1 = result for 1-flow
X1 Xn = result for n-flows
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
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.
根据第4节规定的测试设置，通过测量[RFC3511]所述的并发TCP连接容量，可以推导出最大流量n的准则。
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.
报告格式：性能下降应以百分比表示。必须明确规定测试平行流n的数量。对于每个执行的基准测试，应该有一个表，其中包含每个帧大小的列。该表还应说明应用的帧速率。如果基准报告了一个以上的值（如第7.3.2节中讨论的IPDV），则应包括每个值的一列。
Objective: To quantify the performance degradation introduced by n parallel and incrementally started network flows.
目标：量化n个并行和增量启动的网络流导致的性能下降。
Procedure: First, the benchmarking tests presented in Section 7 have to be performed for one network flow.
程序：首先，必须对一个网络流执行第7节中介绍的基准测试。
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.
必须对n个网络流重复相同的测试，其中网络流在每次时间t之后连续递增地开始。换句话说，如果流i在时间x开始，那么流i+1将在时间x+t开始。考虑到时间t，每次迭代的持续时间必须延长到启动所有流所需的时间，即（n-1）xt。第一次流量的测量持续时间应至少为60秒。
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.
应使用第10.2.1节中给出的公式，将x基准维度的性能退化计算为1-flow结果和n-flow结果之间的相对性能变化。还可以执行1/4*n、1/2*n和3/4*n的中间退化点。
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.
报告格式：性能下降应以百分比表示。必须明确规定测试平行流n的数量。对于每个执行的基准测试，应该有一个表，其中包含每个帧大小的列。该表还应说明应用的帧速率和持续时间T，它用作网络流之间的增量步骤。T的测量单位应为秒。还可以显示中间退化点的列。如果基准报告了一个以上的值（如第7.3.2节中讨论的IPDV），则应包括每个值的一列。
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
尽管这些技术不是本文件的主要范围，但与第4.1节中定义的单一翻译技术相关的基准方法可用于
benchmark implementations that use NAT44 (as defined by [RFC2663] with the behavior described by [RFC7857]) and implementations that use NAT66 (as defined by [RFC6296]).
使用NAT44的基准实现（如[RFC2663]所定义，行为如[RFC7857]所描述）和使用NAT66的实现（如[RFC6296]所定义）。
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.
为确保使用第7节至第9节所述测试获得的基准测试分数的稳定性，建议进行多次测试迭代。使用总结函数（或中心趋势的度量）可以是比较不同迭代中获得的结果的简单有效的方法。然而，过度总结是报告单个数字的一种不必要的影响。
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].
为此，[ietf95pres]中提供的数据表明，中位数是一个合适的汇总函数，第1个和第99个百分位是DNS解析性能和PDV的变异度量。中位数和百分位计算函数应遵循[RFC2330]第11.3节的建议。
For a fine-grained analysis of the frequency distribution of the data, histograms or cumulative distribution function plots can be employed.
对于数据频率分布的细粒度分析，可以使用直方图或累积分布函数图。
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.
此外，基准测试是在“黑盒”基础上进行的，仅依赖于DUT或被测系统（SUT）外部可观察到的测量值。DUT/SUT中不应存在专门用于基准测试的特殊能力。DUT/SUT对网络安全的任何影响应在实验室和生产网络中相同。
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.
IANA已为IPv6基准测试分配前缀2001:2:：/48[RFC5180]。对于IPv4基准测试，保留了198.18.0.0/15前缀，如[RFC6890]中所述。这两个范围足以对IPv6过渡技术进行基准测试。因此，不要求采取任何行动。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <http://www.rfc-editor.org/info/rfc1242>.
[RFC1242]Bradner，S.，“网络互连设备的基准术语”，RFC 1242，DOI 10.17487/RFC1242，1991年7月<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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，DOI 10.17487/RFC2330，1998年5月<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>.
[RFC2544]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，DOI 10.17487/RFC2544，1999年3月<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>.
[RFC3393]Demichelis，C.和P.Chimento，“IP性能度量的IP数据包延迟变化度量（IPPM）”，RFC 3393，DOI 10.17487/RFC3393，2002年11月<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>.
[RFC3511]Hickman，B.，Newman，D.，Tadjudin，S.，和T.Martin，“防火墙性能的基准测试方法”，RFC 3511，DOI 10.17487/RFC3511，2003年4月<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>.
[RFC5180]Popoviciu，C.，Hamza，A.，Van de Velde，G.，和D.Dugatkin，“网络互连设备的IPv6基准测试方法”，RFC 5180，DOI 10.17487/RFC5180，2008年5月<http://www.rfc-editor.org/info/rfc5180>.
[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>.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 5481，DOI 10.17487/RFC5481，2009年3月<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>.
[RFC6201]Asati，R.，Pignataro，C.，Calabria，F.，和C.Olvera，“设备重置特征”，RFC 6201，DOI 10.17487/RFC6201，2011年3月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，DOI 10.17487/RFC2663，1999年8月<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>.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，DOI 10.17487/RFC4213，2005年10月<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>.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 4659，DOI 10.17487/RFC4659，2006年9月<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>.
[RFC4798]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，DOI 10.17487/RFC4798，2007年2月<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>.
[RFC5569]Despres，R.，“IPv4基础设施上的IPv6快速部署（第6次）”，RFC 5569，DOI 10.17487/RFC5569，2010年1月<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>.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 6144DOI 10.17487/RFC6144，2011年4月<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>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<http://www.rfc-editor.org/info/rfc6146>.
[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>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 6147，DOI 10.17487/RFC6147，2011年4月<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>.
[RFC6219]Li，X.，Bao，C.，Chen，M.，Zhang，H.，和J.Wu，“针对IPv4/IPv6共存和过渡的中国教育和研究网络（CERNET）IVI翻译设计和部署”，RFC 6219，DOI 10.17487/RFC6219，2011年5月<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>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 6296DOI 10.17487/RFC62962011年6月<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>.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 6333，DOI 10.17487/RFC6333，2011年8月<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>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，DOI 10.17487/RFC6877，2013年4月<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>.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 6890，DOI 10.17487/RFC6890，2013年4月<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>.
[RFC7596]Cui，Y.，Sun，Q.，Boucadair，M.，Tsou，T.，Lee，Y.，和I.Farrer，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年7月<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>.
[RFC7597]Troan，O.，Ed.，Dec，W.，Li，X.，Bao，C.，Matsushima，S.，Murakami，T.，和T.Taylor，Ed.，“地址和端口的封装映射（MAP-E）”，RFC 7597，DOI 10.17487/RFC7597，2015年7月<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>.
[RFC7599]Li，X.，Bao，C.，Dec，W.，Ed.，Troan，O.，Matsushima，S.，和T.Murakami，“地址和端口映射使用翻译（MAP-T）”，RFC 7599，DOI 10.17487/RFC7599，2015年7月<http://www.rfc-editor.org/info/rfc7599>.
[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>.
[RFC7857]Penno，R.，Perreault，S.，Boucadair，M.，Ed.，Sivakumar，S.，和K.Naito，“网络地址转换（NAT）行为要求的更新”，BCP 127，RFC 7857，DOI 10.17487/RFC7857，2016年4月<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>.
[RFC7915]Bao，C.，Li，X.，Baker，F.，Anderson，T.，和F.Gont，“IP/ICMP翻译算法”，RFC 7915，DOI 10.17487/RFC7915，2016年6月<http://www.rfc-editor.org/info/rfc7915>.
[Dns64perf] Bakai, D., "A C++11 DNS64 performance tester", <https://github.com/bakaid/dns64perfpp>.
[Dns64perf]Bakai，D.，“一个C++11 DNS64性能测试仪”<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>.
[ietf95pres]Georgescu，M.，“IPv6过渡技术的基准方法”，IETF 95会议记录，阿根廷布宜诺斯艾利斯，2016年4月<https://www.ietf.org/proceedings/95/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>
[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>.
[Lencse2]Lencse，G.和D.Bakai，“DNS64服务器基准测试程序的设计和实施”，IEICE通信交易，第E100-B卷，第6期，第948-954页，DOI 10.1587/transcom.2016EBN0007，2017年6月<https://www.jstage.jst.go.jp/article/transcom/E100.B/ 6/E100.B_2016EBN0007/_文章>。
[Lencse3] dns64perfppc, <http://www.hit.bme.hu/~lencse/dns64perfppc/>.
[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>.
[Lencse4]Lencse，例如，“启用Dns64perf++以对DNS64服务器的缓存性能进行基准测试”，未发布，审查版本<http://www.hit.bme.hu/~lencse/publications/IEICE-2016-dns64perfppc-for-review.pdf>。
[IEEE802.1AC] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Service Definition", IEEE 802.1AC.
[IEEE802.1AC]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）服务定义”，IEEE 802.1AC。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q.
[IEEE802.1Q]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，IEEE标准802.1Q。
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.
本附录描述了以太网上用作示例介质的理论最大帧速率的推荐计算公式。该公式考虑了封装或转换过程产生的帧大小开销。例如，[RFC4213]中描述的6in4封装为每个帧增加了20字节的开销。
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:
考虑到X是帧大小，O是封装或转换过程产生的帧大小开销，以太网的最大理论帧速率可以使用以下公式计算：
Line Rate (bps)
------------------------------------
(8 bits/byte) * (X+O+20) bytes/frame
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:
计算基于附录A.1中[RFC5180]推荐的公式。例如，建议在具有64字节帧的10 Mb/s以太网上测试6in4实现的帧速率为：
10,000,000 (bps)
-------------------------------------- = 12,019 fps
(8 bits/byte) * (64+20+20) bytes/frame
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:
下表列出了6in4封装的建议帧速率的完整列表：
+------------+---------+----------+-----------+------------+
| 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 |
+------------+---------+----------+-----------+------------+
+------------+---------+----------+-----------+------------+
| 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 |
+------------+---------+----------+-----------+------------+
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.
作者感谢Yuki Kadobayashi和Hiroaki Hazeyama的不断反馈和支持。感谢NECOMA项目成员的持续支持。我们感谢Emanuel Popa、Ionut Spirlea和RCS&RDS IP/MPLS骨干团队的支持和见解。我们感谢Scott Bradner提供的有用建议，并注意到本备忘录中使用了Scott文档中的部分文本（例如，“延迟”部分）。非常感谢Al Morton和Fred Baker对该文件的详细审查和非常有用的建议。布瓦尼瓦兰·文盖纳森、安德鲁·麦格雷戈、纳利尼·埃尔金斯、西泽康、大原康弘、马瓦塔里、科斯塔斯·彭蒂库西斯、贝拉·阿尔马西、蒂姆·周恩、保罗·埃默里奇和斯滕尼奥·费尔南德斯提出了其他有益的意见和建议。特别感谢RFC编辑团队进行了全面的编辑审查并提出了有益的建议。
Authors' Addresses
作者地址
Marius Georgescu RCS&RDS Strada Dr. Nicolae D. Staicovici 71-75 Bucharest 030167 Romania
Marius Georgescu RCS&RDS Strada博士Nicolae D.Staicovici 71-75罗马尼亚布加勒斯特030167
Phone: +40 31 005 0979
Email: marius.georgescu@rcs-rds.ro
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
Liviu Pislaru RCS&RDS Strada Nicolae D.Staicovici博士罗马尼亚布加勒斯特71-75 030167
Phone: +40 31 005 0979
Email: liviu.pislaru@rcs-rds.ro
Phone: +40 31 005 0979
Email: liviu.pislaru@rcs-rds.ro
Gabor Lencse Szechenyi Istvan University Egyetem ter 1. Gyor Hungary
Gabor Lencse Szechenyi Istvan大学第1学期。匈牙利首都
Phone: +36 20 775 8267
Email: lencse@sze.hu
Phone: +36 20 775 8267
Email: lencse@sze.hu