Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 8468 AT&T Labs
Updates: 2330 J. Fabini
Category: Informational TU Wien
ISSN: 2070-1721 N. Elkins
Inside Products, Inc.
M. Ackermann
Blue Cross Blue Shield of Michigan
V. Hegde
Consultant
November 2018
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 8468 AT&T Labs
Updates: 2330 J. Fabini
Category: Informational TU Wien
ISSN: 2070-1721 N. Elkins
Inside Products, Inc.
M. Ackermann
Blue Cross Blue Shield of Michigan
V. Hegde
Consultant
November 2018
IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework
IPv4、IPv6和IPv4-IPv6共存：IP性能度量（IPPM）框架的更新
Abstract
摘要
This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation.
本备忘录更新了RFC 2330定义的IP性能指标（IPPM）框架，并对测量方法和测试提出了新的注意事项。它更新了标准格式数据包的定义，以包括IPv6数据包，反对最小IP数据包的定义，并增加了RFC 2330中测试数据包的区别方面（称为P型）。此备忘录指出，IPv4-IPv6共存可能会对IPPM框架范围内的度量提出质疑。示例用例包括但不限于IPv4-IPv6转换、NAT和协议封装。IPv6报头压缩和IPv6在低功率无线局域网（6LoWPAN）上的使用被考虑在内，并被排除在标准形成的分组评估之外。
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 candidates 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 https://www.rfc-editor.org/info/rfc8468.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8468.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 4
5. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5
6. NAT, IPv4-IPv6 Transition, and Compression Techniques . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 4
5. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5
6. NAT, IPv4-IPv6 Transition, and Compression Techniques . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
The IETF IP Performance Metrics (IPPM) working group first created a framework for metric development in [RFC2330]. This framework has stood the test of time and enabled development of many fundamental metrics. It has been updated in the area of metric composition [RFC5835] and in several areas related to active stream measurement of modern networks with reactive properties [RFC7312].
IETF IP性能度量（IPPM）工作组在[RFC2330]中首次创建了度量开发框架。该框架经受了时间的考验，并支持许多基本指标的开发。它在度量组成领域[RFC5835]以及与具有无功特性的现代网络的有功流测量相关的几个领域[RFC7312]中进行了更新。
The IPPM framework [RFC2330] recognized (in Section 13) that many aspects of an IP packet can influence its processing during transfer across the network.
IPPM框架[RFC2330]认识到（在第13节中）IP分组的许多方面可以在网络传输期间影响其处理。
In Section 15 of [RFC2330], the notion of a "standard-formed" packet is defined. However, the definition was never expanded to include IPv6, even though the authors of [RFC2330] explicitly identified the need for this update in Section 15: "the version field is 4 (later, we will expand this to include 6)".
在[RFC2330]的第15节中，定义了“标准格式”数据包的概念。然而，该定义从未扩展到包括IPv6，尽管[RFC2330]的作者在第15节中明确指出需要进行此更新：“版本字段为4（稍后，我们将扩展到包括6）”。
In particular, IPv6 Extension Headers and protocols that use IPv6 header compression are growing in use. This memo seeks to provide the needed updates to the original definition in [RFC2330].
特别是，使用IPv6报头压缩的IPv6扩展报头和协议的使用正在增长。本备忘录旨在对[RFC2330]中的原始定义进行必要的更新。
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]所述进行解释。
The purpose of this memo is to expand the coverage of IPPM to include IPv6, highlight additional aspects of test packets, and make them part of the IPPM framework.
本备忘录旨在扩大IPPM的覆盖范围，以包括IPv6，突出测试数据包的其他方面，并使其成为IPPM框架的一部分。
The scope is to update key sections of [RFC2330], adding considerations that will aid the development of new measurement methodologies intended for today's IP networks. Specifically, this memo expands the Type-P examples in Section 13 of [RFC2330] and expands the definition (in Section 15 of [RFC2330]) of a standard-formed packet to include IPv6 header aspects and other features.
其范围是更新[RFC2330]的关键章节，添加有助于开发适用于当今IP网络的新测量方法的注意事项。具体而言，本备忘录扩展了[RFC2330]第13节中的P型示例，并扩展了标准格式数据包的定义（在[RFC2330]第15节中），以包括IPv6报头方面和其他特性。
Other topics in [RFC2330] that might be updated or augmented are deferred to future work. This includes the topics of passive and various forms of hybrid active/passive measurements.
[RFC2330]中可能更新或扩充的其他主题将推迟到以后的工作中。这包括被动和各种形式的混合主动/被动测量的主题。
A fundamental property of many Internet metrics is that the measured value of the metric depends on characteristics of the IP packet(s) used to make the measurement. Potential influencing factors include IP header fields and their values, as well as higher-layer protocol headers and their values. Consider an IP-connectivity metric: one obtains different results depending on whether one is interested in, for example, connectivity for packets destined for well-known TCP ports or unreserved UDP ports, those with invalid IPv4 checksums, or those with TTL or Hop Limit of 16. In some circumstances, these distinctions will result in special treatment of packets in intermediate nodes and end systems -- for example, if Diffserv [RFC2474], Explicit Congestion Notification (ECN) [RFC3168], Router Alert [RFC6398], Hop-by-Hop extensions [RFC7045], or Flow Labels [RFC6437] are used, or in the presence of firewalls or RSVP reservations.
许多Internet度量的一个基本属性是度量的测量值取决于用于进行测量的IP数据包的特征。潜在影响因素包括IP头字段及其值，以及更高层协议头及其值。考虑IP连接性度量：一个获得不同的结果，这取决于人们是否感兴趣，例如，针对已知TCP端口或未保留UDP端口的分组的连通性，那些具有无效IPv4校验和的那些，或者那些具有TTL或跳数限制为16的那些结果。在某些情况下，这些区别将导致对中间节点和终端系统中的数据包进行特殊处理——例如，如果使用Diffserv[RFC2474]、显式拥塞通知（ECN）[RFC3168]、路由器警报[RFC6398]、逐跳扩展[RFC7045]或流标签[RFC6437]，或者在存在防火墙或RSVP预订的情况下。
Because of this distinction, we introduce the generic notion of a "packet of Type-P", where in some contexts P will be explicitly defined (i.e., exactly what type of packet we mean), partially defined (e.g., "with a payload of B octets"), or left generic. Thus, we may talk about generic IP-Type-P-connectivity or more specific IP-port-HTTP-connectivity. Some metrics and methodologies may be fruitfully defined using generic Type-P definitions, which are then made specific when performing actual measurements.
由于这一区别，我们引入了“P型数据包”的一般概念，在某些上下文中，P将被明确定义（即，我们所指的确切数据包类型）、部分定义（例如，“有效载荷为B个八位组”）或保持通用。因此，我们可以讨论通用IP-Type-P-connectivity或更具体的IP端口HTTP连接。一些度量和方法可以使用通用的P型定义进行有效的定义，然后在执行实际测量时将其具体化。
Whenever a metric's value depends on the type of the packets involved, the metric's name will include either a specific type or a phrase such as "Type-P". Thus, we will not define an "IP-connectivity" metric but instead an "IP-Type-P-connectivity" metric and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming convention serves as an important reminder that one must be conscious of the exact type of traffic being measured.
当度量值取决于所涉及的数据包类型时，度量名称将包括特定类型或短语，如“type-P”。因此，我们将不定义“IP连接”度量，而是定义“IP-Type-P-connectivity”度量和/或“IP端口HTTP连接”度量。这种命名约定是一个重要的提醒，提醒人们必须意识到所测量的流量的确切类型。
If the information constituting Type-P at the Source is found to have changed at the Destination (or at a measurement point between the Source and Destination, as in [RFC5644]), then the modified values MUST be noted and reported with the results. Some modifications occur according to the conditions encountered in transit (such as congestion notification) or due to the requirements of segments of the Source-to-Destination path. For example, the packet length will change if IP headers are converted to the alternate version/address family or optional Extension Headers are added or removed. Even header fields like TTL/Hop Limit that typically change in transit may be relevant to specific tests. For example, Neighbor Discovery Protocol (NDP) [RFC4861] packets are transmitted with the Hop Limit value set to 255, and the validity test specifies that the Hop Limit
如果发现在源处构成P型的信息在目的地（或在源和目的地之间的测量点，如[RFC5644]）发生了变化，则必须记录修改后的值并与结果一起报告。根据在运输过程中遇到的条件（如拥堵通知）或源到目的地路径段的要求，会发生一些修改。例如，如果将IP头转换为备用版本/地址系列或添加或删除可选扩展头，则数据包长度将更改。甚至像TTL/Hop Limit这样通常在传输过程中更改的头字段也可能与特定测试相关。例如，传输邻居发现协议（NDP）[RFC4861]数据包时，跳数限制值设置为255，有效性测试指定跳数限制
MUST have a value of 255 at the receiver, too. So, while other tests may intentionally exclude the TTL/Hop Limit value from their Type-P definition, for this particular test, the correct Hop Limit value is of high relevance and MUST be part of the Type-P definition.
接收器上的值也必须为255。因此，尽管其他测试可能有意将TTL/Hop限制值从其Type-P定义中排除，但对于该特定测试，正确的Hop限制值具有高度相关性，并且必须是Type-P定义的一部分。
Local policies in intermediate nodes based on examination of IPv6 Extension Headers may affect measurement repeatability. If intermediate nodes follow the recommendations of [RFC7045], repeatability may be improved to some degree.
基于IPv6扩展头检查的中间节点中的本地策略可能会影响测量的可重复性。如果中间节点遵循[RFC7045]的建议，可在一定程度上提高重复性。
A closely related note: It would be very useful to know if a given Internet component (like a host, link, or path) treats equally a class C of different types of packets. If so, then any one of those types of packets can be used for subsequent measurement of the component. This suggests we should devise a metric or suite of metrics that attempt to determine class C (a designation that has no relationship to address assignments, of course).
一个密切相关的注意事项：了解给定的Internet组件（如主机、链接或路径）是否平等地对待不同类型的数据包的C类是非常有用的。如果是这样，那么这些类型的包中的任何一种都可以用于组件的后续测量。这意味着我们应该设计一个或一套试图确定C类的指标（当然，这个指标与解决作业无关）。
Load-balancing over parallel paths is one particular example where such a class C would be more complex to determine in IPPM measurements. Load balancers and routers often use flow identifiers, computed as hashes (of specific parts) of the packet header, for deciding among the available parallel paths a packet will traverse. Packets with identical hashes are assigned to the same flow and forwarded to the same resource in the load balancer's (or router's) pool. The presence of a load balancer on the measurement path, as well as the specific headers and fields that are used for the forwarding decision, are not known when measuring the path as a black box. Potential assessment scenarios include the measurement of one of the parallel paths, and the measurement of all available parallel paths that the load balancer can use. Therefore, knowledge of a load balancer's flow definition (alternatively, its class-C-specific treatment in terms of header fields in scope of hash operations) is a prerequisite for repeatable measurements. A path may have more than one stage of load-balancing, adding to class C definition complexity.
并行路径上的负载平衡是一个特殊的例子，在IPPM测量中，此类C类的确定将更加复杂。负载均衡器和路由器通常使用流标识符（作为数据包头的（特定部分的）散列计算）来决定数据包将要穿越的可用并行路径。具有相同哈希的数据包被分配到相同的流，并转发到负载平衡器（或路由器）池中的相同资源。当将路径测量为黑盒时，测量路径上是否存在负载平衡器，以及用于转发决策的特定头和字段都是未知的。潜在的评估场景包括测量一条并行路径，以及测量负载平衡器可以使用的所有可用并行路径。因此，了解负载平衡器的流定义（或者，根据哈希操作范围内的头字段对其进行C类特定处理）是可重复测量的先决条件。一条路径可能有多个阶段的负载平衡，这增加了C类定义的复杂性。
Unless otherwise stated, all metric definitions that concern IP packets include an implicit assumption that the packet is standard-formed. A packet is standard-formed if it meets all of the following REQUIRED criteria:
除非另有说明，否则与IP分组有关的所有度量定义都包括一个隐式假设，即分组是标准形式的。如果数据包满足以下所有要求标准，则为标准数据包：
+ It includes a valid IP header. See below for version-specific criteria.
+ 它包括一个有效的IP头。有关特定于版本的标准，请参见下文。
+ It is not an IP fragment.
+ 它不是IP片段。
+ The Source and Destination addresses correspond to the intended Source and Destination, including Multicast Destination addresses.
+ 源和目标地址对应于预期的源和目标，包括多播目标地址。
+ If a transport header is present, it contains a valid checksum and other valid fields.
+ 如果存在传输标头，则它包含有效的校验和以及其他有效字段。
For an IPv4 packet (as specified in [RFC791] and the RFCs that update it) to be standard-formed, the following additional criteria are REQUIRED:
对于标准形式的IPv4数据包（如[RFC791]和更新该数据包的RFC中所述），需要以下附加标准：
o The version field is 4.
o 版本字段为4。
o The Internet Header Length (IHL) value is >= 5; the checksum is correct.
o 互联网报头长度（IHL）值>=5；校验和是正确的。
o Its total length as given in the IPv4 header corresponds to the size of the IPv4 header plus the size of the payload.
o IPv4报头中给出的总长度对应于IPv4报头的大小加上有效负载的大小。
o Either the packet possesses sufficient TTL to travel from the Source to the Destination if the TTL is decremented by one at each hop or it possesses the maximum TTL of 255.
o 如果TTL在每个跃点减少1，则数据包拥有足够的TTL从源传输到目的地，或者它拥有255的最大TTL。
o It does not contain IP options unless explicitly noted.
o 除非明确说明，否则它不包含IP选项。
For an IPv6 packet (as specified in [RFC8200] and any future updates) to be standard-formed, the following criteria are REQUIRED:
对于标准格式的IPv6数据包（如[RFC8200]和任何未来更新中所述），需要以下标准：
o The version field is 6.
o 版本字段为6。
o Its total length corresponds to the size of the IPv6 header (40 octets) plus the length of the payload as given in the IPv6 header.
o 其总长度对应于IPv6报头的大小（40个八位字节）加上IPv6报头中给定的有效负载长度。
o The payload length value for this packet (including Extension Headers) conforms to the IPv6 specifications.
o 此数据包（包括扩展头）的有效负载长度值符合IPv6规范。
o Either the packet possesses sufficient Hop Limit to travel from the Source to the Destination if the Hop Limit is decremented by one at each hop or it possesses the maximum Hop Limit of 255.
o 如果在每个跃点处跃点限制减小一，则数据包具有足够的跃点限制从源移动到目的地，或者它具有255的最大跃点限制。
o Either the packet does not contain IP Extension Headers or it contains the correct number and type of headers as specified in the packet and the headers appear in the standard-conforming order (Next Header).
o 数据包不包含IP扩展报头，或者包含数据包中指定的正确数量和类型的报头，并且报头以标准一致性顺序出现（下一个报头）。
o All parameters used in the header and Extension Headers are found in the "Internet Protocol Version 6 (IPv6) Parameters" registry specified in [IANA-6P].
o 在[IANA-6P]中指定的“Internet协议版本6（IPv6）参数”注册表中可以找到标头和扩展标头中使用的所有参数。
Two mechanisms require some discussion in the context of standard-formed packets, namely IPv6 over Low-Power Wireless Area Networks (6LowPAN) [RFC4944] and Robust Header Compression (ROHC) [RFC3095]. 6LowPAN, as defined in [RFC4944] and updated by [RFC6282] with header compression and [RFC6775] with neighbor discovery optimizations, proposes solutions for using IPv6 in resource-constrained environments. An adaptation layer enables the transfer of IPv6 packets over networks having an MTU smaller than the minimum IPv6 MTU. Fragmentation and reassembly of IPv6 packets, as well as the resulting state that would be stored in intermediate nodes, poses substantial challenges to measurements. Likewise, ROHC operates statefully in compressing headers on subpaths, storing state in intermediate hosts. The modification of measurement packets' Type-P by ROHC and 6LowPAN requires substantial work, as do requirements with respect to the concept of standard-formed packets for these two protocols. For these reasons, we consider ROHC and 6LowPAN packets to be out of the scope of the standard-formed packet evaluation.
有两种机制需要在标准格式数据包的上下文中进行讨论，即低功率无线局域网上的IPv6（6LowPAN）[RFC4944]和鲁棒报头压缩（ROHC）[RFC3095]。6LowPAN，如[RFC4944]中所定义，并由[RFC6282]通过标头压缩和[RFC6775]通过邻居发现优化进行更新，提出了在资源受限环境中使用IPv6的解决方案。自适应层允许在MTU小于最小IPv6 MTU的网络上传输IPv6数据包。IPv6数据包的碎片化和重组，以及由此产生的存储在中间节点中的状态，给测量带来了巨大的挑战。类似地，ROHC在压缩子路径上的报头时有状态地运行，将状态存储在中间主机中。ROHC和6LowPAN对测量数据包类型P的修改需要大量的工作，这两个协议关于标准格式数据包概念的要求也是如此。由于这些原因，我们认为ROHC和6LoWPAN分组超出标准形成的分组评估的范围。
The topic of IPv6 Extension Headers brings current controversies into focus, as noted by [RFC6564] and [RFC7045]. However, measurement use cases in the context of the IPPM framework, such as in situ OAM [IOAM-DATA] in enterprise environments, can benefit from inspection, modification, addition, or deletion of IPv6 extension headers in hosts along the measurement path.
正如[RFC6564]和[RFC7045]所指出的，IPv6扩展头的主题将当前的争议集中在一起。但是，IPPM框架上下文中的度量用例，例如企业环境中的原位OAM[IOAM-DATA]，可以受益于沿着度量路径在主机中检查、修改、添加或删除IPv6扩展头。
[RFC8250] endorses the use of the IPv6 Destination Option for measurement purposes, consistent with other relevant and approved IETF specifications.
[RFC8250]认可将IPv6目标选项用于测量目的，与其他相关且经批准的IETF规范保持一致。
The following additional considerations apply when IPv6 Extension Headers are present:
当存在IPv6扩展标头时，以下附加注意事项适用：
o Extension Header inspection: Some intermediate nodes may inspect Extension Headers or the entire IPv6 packet while in transit. In exceptional cases, they may drop the packet or route via a suboptimal path, and measurements may be unreliable or unrepeatable. The packet (if it arrives) may be standard-formed, with a corresponding Type-P.
o 扩展头检查：一些中间节点可能会在传输过程中检查扩展头或整个IPv6数据包。在特殊情况下，他们可能通过次优路径丢弃数据包或路由，并且测量可能不可靠或不可重复。包（如果它到达）可以是标准形式的，具有相应的类型P。
o Extension Header modification: In Hop-by-Hop headers, some TLV-encoded options may be permitted to change at intermediate nodes while in transit. The resulting packet may be standard-formed, with a corresponding Type-P.
o 扩展头修改：在逐跳头中，一些TLV编码的选项可能允许在传输过程中在中间节点上更改。产生的分组可以是标准形成的，具有对应的类型P。
o Extension Header insertion or deletion: Although such behavior is not endorsed by current standards, it is possible that Extension Headers could be added to, or removed from, the header chain. The resulting packet may be standard-formed, with a corresponding Type-P. This point simply encourages measurement system designers to be prepared for the unexpected and notify users when such events occur. There are issues with Extension Header insertion and deletion, of course, such as exceeding the path MTU due to insertion, etc.
o 扩展头插入或删除：虽然当前标准不支持这种行为，但扩展头可以添加到头链中，也可以从头链中删除。产生的数据包可能是标准格式的，具有相应的P型。这一点只是鼓励测量系统设计人员为意外事件做好准备，并在此类事件发生时通知用户。当然，在插入和删除扩展标头时会出现问题，例如由于插入而超出路径MTU等。
o A change in packet length (from the corresponding packet observed at the Source) or header modification is a significant factor in Internet measurement and REQUIRES a new Type-P to be reported with the test results.
o 数据包长度的变化（从源处观察到的相应数据包）或报头修改是互联网测量中的一个重要因素，需要在测试结果中报告一个新的P型。
It is further REQUIRED that if a packet is described as having a
"length of B octets", then 0 <= B <= 65535; and if B is the payload
length in octets, then B <= (65535-IP header size in octets,
including any Extension Headers). The jumbograms defined in
[RFC2675] are not covered by the above length analysis, but if the
IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a
packet with corresponding length MUST be considered standard-formed.
In practice, the path MTU will restrict the length of standard-formed
packets that can successfully traverse the path. Path MTU Discovery
for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU
Discovery (PLPMTUD, [RFC4821]) is recommended to prevent
fragmentation.
It is further REQUIRED that if a packet is described as having a
"length of B octets", then 0 <= B <= 65535; and if B is the payload
length in octets, then B <= (65535-IP header size in octets,
including any Extension Headers). The jumbograms defined in
[RFC2675] are not covered by the above length analysis, but if the
IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a
packet with corresponding length MUST be considered standard-formed.
In practice, the path MTU will restrict the length of standard-formed
packets that can successfully traverse the path. Path MTU Discovery
for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU
Discovery (PLPMTUD, [RFC4821]) is recommended to prevent
fragmentation.
So, for example, one might imagine defining an IP-connectivity metric as "IP-Type-P-connectivity for standard-formed packets with the IP Diffserv field set to 0", or, more succinctly, "IP-Type-P-connectivity with the IP Diffserv field set to 0", since standard-formed is already implied by convention. Changing the contents of a field, such as the Diffserv Code Point, ECN bits, or Flow Label may have a profound effect on packet handling during transit, but does not affect a packet's status as standard-formed. Likewise, the addition, modification, or deletion of extension headers may change the handling of packets in transit hosts.
因此，例如，可以想象将IP连接性度量定义为“IP区分服务字段设置为0的标准格式分组的IP-Type-P-connectivity”，或者更简洁地说，“IP区分服务字段设置为0的IP-Type-P-connectivity”，因为约定已经暗示了标准格式。更改字段的内容（如Diffserv代码点、ECN位或流标签）可能会对传输期间的数据包处理产生深远的影响，但不会影响数据包作为标准格式的状态。同样，扩展头的添加、修改或删除可能会改变传输主机中数据包的处理。
[RFC2330] defines the "minimal IP packet from A to B" as a particular type of standard-formed packet often useful to consider. When defining IP metrics, no packet smaller or simpler than this can be transmitted over a correctly operating IP network. However, the concept of the minimal IP packet has not been employed (since typical active measurement systems employ a transport layer and a payload), and its practical use is limited. Therefore, this memo deprecates the concept of the "minimal IP packet from A to B".
[RFC2430]定义了“从A到B的最小IP分组”作为一种特殊类型的标准形成的分组，通常是值得考虑的。在定义IP指标时，没有比这更小或更简单的数据包可以通过正确运行的IP网络传输。然而，最小IP分组的概念尚未被采用（因为典型的主动测量系统采用传输层和有效载荷），其实际应用受到限制。因此，本备忘录不赞成“从A到B的最小IP数据包”的概念。
This memo adds the key considerations for utilizing IPv6 in two critical conventions of the IPPM framework, namely packets of Type-P and standard-formed packets. The need for coexistence of IPv4 and IPv6 has originated transitioning standards like the framework for IPv4/IPv6 translation in [RFC6144] or the IP/ICMP translation algorithms in [RFC7915] and [RFC7757].
本备忘录增加了在IPPM框架的两个关键约定中使用IPv6的关键注意事项，即P型数据包和标准格式数据包。IPv4和IPv6共存的需要产生了过渡标准，如[RFC6144]中的IPv4/IPv6转换框架或[RFC7915]和[RFC7757]中的IP/ICMP转换算法。
The definition and execution of measurements within the context of the IPPM framework is challenged whenever such translation mechanisms are present along the measurement path. In use cases like IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header compression may result in modification of the measurement packet's Type-P along the path. All these changes MUST be reported. Example consequences include, but are not limited to:
在IPPM框架的背景下，当测量路径上存在此类转换机制时，测量的定义和执行就会受到质疑。在IPv4-IPv6转换、NAT、协议封装或IPv6报头压缩等用例中，可能会导致沿路径修改测量数据包的类型P。必须报告所有这些变化。示例后果包括但不限于：
o Modification or addition of headers or header field values in intermediate nodes. IPv4-IPv6 transitioning or IPv6 header compression mechanisms may result in changes of the measurement packets' Type-P, too. Consequently, hosts along the measurement path may treat packets differently because of the Type-P modification. Measurements at observation points along the path may also need extra context to uniquely identify a packet.
o 在中间节点中修改或添加标题或标题字段值。IPv4-IPv6转换或IPv6报头压缩机制也可能导致测量数据包类型P的更改。因此，由于P型修改，沿着测量路径的主机可以不同地处理分组。沿路径的观测点处的测量也可能需要额外的上下文来唯一地标识数据包。
o Network Address Translators (NAT) on the path can have an unpredictable impact on latency measurement (in terms of the amount of additional time added) and possibly other types of measurements. It is not usually possible to control this impact as testers may not have any control of the underlying network or middleboxes. There is a possibility that stateful NAT will lead to unstable performance for a flow with specific Type-P, since state needs to be created for the first packet of a flow and state may be lost later if the NAT runs out of resources. However, this scenario does not invalidate the Type-P for testing; for example, the purpose of a test might be exactly to quantify the NAT's impact on delay variation. The presence of NAT may mean that the measured performance of Type-P will change between the source and the destination. This can cause an issue when attempting to correlate measurements conducted on segments of the path that include or exclude the NAT. Thus, it is a factor to be aware of when conducting measurements.
o 路径上的网络地址转换器（NAT）可能会对延迟测量（就增加的额外时间量而言）以及其他类型的测量产生不可预测的影响。通常不可能控制这种影响，因为测试人员可能无法控制底层网络或中间盒。有状态NAT可能会导致具有特定类型P的流的性能不稳定，因为需要为流的第一个数据包创建状态，并且如果NAT耗尽资源，状态可能稍后丢失。但是，该场景不会使P型测试无效；例如，测试的目的可能是准确地量化NAT对延迟变化的影响。NAT的存在可能意味着P型的测量性能将在源和目标之间发生变化。当试图关联在包括或排除NAT的路径段上进行的测量时，这可能会导致问题。因此，这是进行测量时需要注意的一个因素。
o Variable delay due to internal state. One side effect of changes due to IPv4-IPv6 transitioning mechanisms is the variable delay that intermediate nodes experience for header modifications. Similar to NAT, the allocation of internal state and establishment of context within intermediate nodes may cause variable delays, depending on the measurement stream pattern and position of a packet within the stream. For example, the first packet in a stream will typically trigger allocation of internal state in an intermediate IPv4-IPv6 transition host. Subsequent packets can benefit from lower processing delay due to the existing internal state. However, large interpacket delays in the measurement stream may result in the intermediate host deleting the associated state and needing to re-establish it on arrival of another stream packet. It is worth noting that this variable delay due to internal state allocation in intermediate nodes can be an explicit use case for measurements.
o 内部状态导致的可变延迟。IPv4-IPv6转换机制引起的更改的一个副作用是中间节点在修改报头时经历的可变延迟。与NAT类似，内部状态的分配和中间节点内上下文的建立可能导致可变延迟，这取决于测量流模式和流中分组的位置。例如，流中的第一个数据包通常会触发中间IPv4-IPv6转换主机中的内部状态分配。由于存在内部状态，后续数据包可以从较低的处理延迟中获益。然而，测量流中的大分组间延迟可能导致中间主机删除关联状态，并且需要在另一个流分组到达时重新建立关联状态。值得注意的是，由于中间节点中的内部状态分配而导致的可变延迟可以是测量的一个显式用例。
o Variable delay due to packet length. IPv4-IPv6 transitioning or header compression mechanisms modify the length of measurement packets. The modification of the packet size may or may not change how the measurement path treats the packets.
o 由于数据包长度而导致的可变延迟。IPv4-IPv6转换或报头压缩机制修改测量数据包的长度。分组大小的修改可以改变也可以不改变测量路径处理分组的方式。
The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [RFC5357].
适用于活动路径的任何主动测量的安全注意事项也与此相关。参见[RFC4656]和[RFC5357]。
When considering the privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques that are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) framework [RFC7594], which covers active and passive techniques.
当考虑到参与测量的人或其流量被测量的人的隐私时，当使用此工作范围内的主动技术时，潜在观察者可用的敏感信息会大大减少。出于测量目的对用户流量进行被动观测会引起许多隐私问题。我们建议读者参考大规模宽带性能测量（LMAP）框架[RFC7594]中描述的隐私注意事项，该框架涵盖主动和被动技术。
This document has no IANA actions.
本文档没有IANA操作。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，DOI 10.17487/RFC2330，1998年5月<https://www.rfc-editor.org/info/rfc2330>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<https://www.rfc-editor.org/info/rfc2474>.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.
[RFC2675]Borman，D.，Deering，S.和R.Hinden，“IPv6巨型程序”，RFC 2675，DOI 10.17487/RFC2675，1999年8月<https://www.rfc-editor.org/info/rfc2675>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, July 2001, <https://www.rfc-editor.org/info/rfc3095>.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，内政部10.17487/RFC30952001年7月<https://www.rfc-editor.org/info/rfc3095>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zekauskas，“单向主动测量协议（OWAMP）”，RFC 4656，DOI 10.17487/RFC4656，2006年9月<https://www.rfc-editor.org/info/rfc4656>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<https://www.rfc-editor.org/info/rfc4821>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<https://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<https://www.rfc-editor.org/info/rfc4944>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357]Hedayat，K.，Krzanowski，R.，Morton，A.，Yum，K.，和J.Babiarz，“双向主动测量协议（TWAMP）”，RFC 5357，DOI 10.17487/RFC5357，2008年10月<https://www.rfc-editor.org/info/rfc5357>.
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance Metrics (IPPM): Spatial and Multicast", RFC 5644, DOI 10.17487/RFC5644, October 2009, <https://www.rfc-editor.org/info/rfc5644>.
[RFC5644]Stephan，E.，Liang，L.，和A.Morton，“IP性能度量（IPPM）：空间和多播”，RFC 5644，DOI 10.17487/RFC5644，2009年10月<https://www.rfc-editor.org/info/rfc5644>.
[RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 2010, <https://www.rfc-editor.org/info/rfc5835>.
[RFC5835]Morton，A.，Ed.和S.Van den Berghe，Ed.，“公制组合框架”，RFC 5835，DOI 10.17487/RFC5835，2010年4月<https://www.rfc-editor.org/info/rfc5835>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 6144DOI 10.17487/RFC6144，2011年4月<https://www.rfc-editor.org/info/rfc6144>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282]Hui，J.，Ed.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，DOI 10.17487/RFC6282，2011年9月<https://www.rfc-editor.org/info/rfc6282>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC6398]Le Faucheur，F.，Ed.，“IP路由器警报注意事项和使用”，BCP 168，RFC 6398，DOI 10.17487/RFC6398，2011年10月<https://www.rfc-editor.org/info/rfc6398>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，DOI 10.17487/RFC6437，2011年11月<https://www.rfc-editor.org/info/rfc6437>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, DOI 10.17487/RFC6564, April 2012, <https://www.rfc-editor.org/info/rfc6564>.
[RFC6564]Krishnan，S.，Woodyatt，J.，Kline，E.，Hoagland，J.，和M.Bhatia，“IPv6扩展头的统一格式”，RFC 6564，DOI 10.17487/RFC6564，2012年4月<https://www.rfc-editor.org/info/rfc6564>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775]Shelby，Z.，Ed.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功率无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 6775，DOI 10.17487/RFC67752012年11月<https://www.rfc-editor.org/info/rfc6775>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.
[RFC7045]Carpenter，B.和S.Jiang，“IPv6扩展头的传输和处理”，RFC 7045，DOI 10.17487/RFC70452013年12月<https://www.rfc-editor.org/info/rfc7045>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, <https://www.rfc-editor.org/info/rfc7312>.
[RFC7312]Fabini，J.和A.Morton，“IP性能度量的高级流和采样框架（IPPM）”，RFC 7312，DOI 10.17487/RFC7312，2014年8月<https://www.rfc-editor.org/info/rfc7312>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <https://www.rfc-editor.org/info/rfc7757>.
[RFC7757]Anderson，T.和A.Leiva Popper，“无状态IP/ICMP转换的显式地址映射”，RFC 7757，DOI 10.17487/RFC7757，2016年2月<https://www.rfc-editor.org/info/rfc7757>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://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月<https://www.rfc-editor.org/info/rfc7915>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201]McCann，J.，Deering，S.，Mogul，J.，和R.Hinden，编辑，“IP版本6的路径MTU发现”，STD 87，RFC 8201，DOI 10.17487/RFC8201，2017年7月<https://www.rfc-editor.org/info/rfc8201>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, <https://www.rfc-editor.org/info/rfc8250>.
[RFC8250]北埃尔金斯、右汉密尔顿和M.阿克曼，“IPv6性能和诊断指标（PDM）目标选项”，RFC 8250，DOI 10.17487/RFC8250，2017年9月<https://www.rfc-editor.org/info/rfc8250>.
[IANA-6P] IANA, "Internet Protocol Version 6 (IPv6) Parameters", <https://www.iana.org/assignments/ipv6-parameters>.
[IANA-6P]IANA，“互联网协议版本6（IPv6）参数”<https://www.iana.org/assignments/ipv6-parameters>.
[IOAM-DATA] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", Work in Progress, draft-ietf-ippm-ioam-data-03, June 2018.
[IOAM-DATA]Brockners，F.，Bhandari，S.，Pignataro，C.，Gredler，H.，Leddy，J.，Youell，S.，Mizrahi，T.，Mozes，D.，Lapukhov，P.，Chang，R.，daniel。bernier@bell.ca，d.和J.Lemon，“现场OAM的数据字段”，正在进行的工作，草稿-ietf-ippm-ioam-Data-032018年6月。
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7594]Eardley，P.，Morton，A.，Bagnulo，M.，Burbridge，T.，Aitken，P.，和A.Akhter，“宽带性能的大规模测量框架（LMAP）”，RFC 7594，DOI 10.17487/RFC7594，2015年9月<https://www.rfc-editor.org/info/rfc7594>.
Acknowledgements
致谢
The authors thank Brian Carpenter for identifying the lack of IPv6 coverage in IPPM's framework and listing additional distinguishing factors for packets of Type-P. Both Brian and Fred Baker discussed many of the interesting aspects of IPv6 with the coauthors, leading to a more solid first draft: thank you both. Thanks to Bill Jouris for an editorial pass through the pre-00 text. As we completed our journey, Nevil Brownlee, Mike Heard, Spencer Dawkins, Warren Kumari, and Suresh Krishnan all contributed useful suggestions.
作者感谢Brian Carpenter指出IPPM框架中IPv6覆盖范围的不足，并列出了P型数据包的其他区别因素。Brian和Fred Baker与合著者讨论了IPv6的许多有趣方面，形成了一个更为坚实的初稿：谢谢你们。感谢Bill Jouris对00前文本的编辑传递。当我们完成旅程时，内维尔·布朗利、迈克·赫德、斯宾塞·道金斯、沃伦·库马里和苏雷什·克里希南都提出了有用的建议。
Authors' Addresses
作者地址
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acm@researh.att.com
美国新泽西州劳雷尔大道南米德尔顿200号阿尔莫顿AT&T实验室07748电话：+1732 420 1571传真：+1 732 368 1192电子邮件：acm@researh.att.com
Joachim Fabini
TU Wien
Gusshausstrasse 25/E389
Vienna 1040
Austria
Phone: +43 1 58801 38813
Fax: +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Joachim Fabini
TU Wien
Gusshausstrasse 25/E389
Vienna 1040
Austria
Phone: +43 1 58801 38813
Fax: +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Nalini Elkins Inside Products, Inc. Carmel Valley, CA 93924 United States of America Email: nalini.elkins@insidethestack.com
Nalini Elkins Inside Products，Inc.加利福尼亚州卡梅尔谷93924美利坚合众国电子邮件：Nalini。elkins@insidethestack.com
Michael S. Ackermann Blue Cross Blue Shield of Michigan Email: mackermann@bcbsm.com
Michael S.Ackermann蓝十字蓝盾密歇根州电子邮件：mackermann@bcbsm.com
Vinayak Hegde Consultant Brahma Sun City, Wadgaon-Sheri Pune, Maharashtra 411014 India Phone: +91 9449834401 Email: vinayakh@gmail.com URI: http://www.vinayakhegde.com
Vinayak Hegde顾问婆罗门太阳城，马哈拉施特拉邦瓦德冈谢里浦那411014印度电话：+91 9449834401电子邮件：vinayakh@gmail.comURI:http://www.vinayakhegde.com