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
                                                           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
                                                           November 2018

IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework




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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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.


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
1. Introduction
1. 介绍

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.


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)".


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


2. Requirements Language
2. 需求语言

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]所述进行解释。

3. Scope
3. 范围

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.


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.


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.


4. Packets of Type-P
4. P型数据包

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.


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.


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.


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.


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.


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


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.


5. Standard-Formed Packets
5. 标准格式包

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:


+ 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:


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:


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.


[RFC8250] endorses the use of the IPv6 Destination Option for measurement purposes, consistent with other relevant and approved IETF specifications.


The following additional considerations apply when IPv6 Extension Headers are present:


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

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.


[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".


6. NAT, IPv4-IPv6 Transition, and Compression Techniques
6. NAT、IPv4-IPv6转换和压缩技术

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


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:


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转换或报头压缩机制修改测量数据包的长度。分组大小的修改可以改变也可以不改变测量路径处理分组的方式。

7. Security Considerations
7. 安全考虑

The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [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.


8. IANA Considerations
8. IANA考虑

This document has no IANA actions.


9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <>.

[RFC791]Postel,J.,“互联网协议”,STD 5,RFC 791,DOI 10.17487/RFC07911981年9月<>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<>.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <>.

[RFC2330]Paxson,V.,Almes,G.,Mahdavi,J.,和M.Mathis,“IP性能度量框架”,RFC 2330,DOI 10.17487/RFC2330,1998年5月<>.

[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, <>.

[RFC2474]Nichols,K.,Blake,S.,Baker,F.,和D.Black,“IPv4和IPv6报头中区分服务字段(DS字段)的定义”,RFC 2474,DOI 10.17487/RFC2474,1998年12月<>.

[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, <>.

[RFC2675]Borman,D.,Deering,S.和R.Hinden,“IPv6巨型程序”,RFC 2675,DOI 10.17487/RFC2675,1999年8月<>.

[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, <>.

[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月<>.

[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, <>.

[RFC3168]Ramakrishnan,K.,Floyd,S.,和D.Black,“向IP添加显式拥塞通知(ECN)”,RFC 3168,DOI 10.17487/RFC3168,2001年9月<>.

[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, <>.

[RFC4656]Shalunov,S.,Teitelbaum,B.,Karp,A.,Boote,J.,和M.Zekauskas,“单向主动测量协议(OWAMP)”,RFC 4656,DOI 10.17487/RFC4656,2006年9月<>.

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <>.

[RFC4821]Mathis,M.和J.Heffner,“打包层路径MTU发现”,RFC 4821,DOI 10.17487/RFC4821,2007年3月<>.

[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, <>.

[RFC4861]Narten,T.,Nordmark,E.,Simpson,W.,和H.Soliman,“IP版本6(IPv6)的邻居发现”,RFC 4861,DOI 10.17487/RFC48612007年9月<>.

[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, <>.

[RFC4944]黑山,G.,Kushalnagar,N.,Hui,J.,和D.Culler,“通过IEEE 802.15.4网络传输IPv6数据包”,RFC 4944,DOI 10.17487/RFC4944,2007年9月<>.

[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, <>.

[RFC5357]Hedayat,K.,Krzanowski,R.,Morton,A.,Yum,K.,和J.Babiarz,“双向主动测量协议(TWAMP)”,RFC 5357,DOI 10.17487/RFC5357,2008年10月<>.

[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance Metrics (IPPM): Spatial and Multicast", RFC 5644, DOI 10.17487/RFC5644, October 2009, <>.

[RFC5644]Stephan,E.,Liang,L.,和A.Morton,“IP性能度量(IPPM):空间和多播”,RFC 5644,DOI 10.17487/RFC5644,2009年10月<>.

[RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 2010, <>.

[RFC5835]Morton,A.,Ed.和S.Van den Berghe,Ed.,“公制组合框架”,RFC 5835,DOI 10.17487/RFC5835,2010年4月<>.

[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <>.

[RFC6144]Baker,F.,Li,X.,Bao,C.,和K.Yin,“IPv4/IPv6转换框架”,RFC 6144DOI 10.17487/RFC6144,2011年4月<>.

[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, <>.

[RFC6282]Hui,J.,Ed.和P.Thubert,“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”,RFC 6282,DOI 10.17487/RFC6282,2011年9月<>.

[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, <>.

[RFC6398]Le Faucheur,F.,Ed.,“IP路由器警报注意事项和使用”,BCP 168,RFC 6398,DOI 10.17487/RFC6398,2011年10月<>.

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <>.

[RFC6437]Amante,S.,Carpenter,B.,Jiang,S.,和J.Rajahalme,“IPv6流标签规范”,RFC 6437,DOI 10.17487/RFC6437,2011年11月<>.

[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, <>.

[RFC6564]Krishnan,S.,Woodyatt,J.,Kline,E.,Hoagland,J.,和M.Bhatia,“IPv6扩展头的统一格式”,RFC 6564,DOI 10.17487/RFC6564,2012年4月<>.

[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, <>.

[RFC6775]Shelby,Z.,Ed.,Chakrabarti,S.,Nordmark,E.,和C.Bormann,“低功率无线个人区域网络(6LoWPANs)上IPv6邻居发现优化”,RFC 6775,DOI 10.17487/RFC67752012年11月<>.

[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <>.

[RFC7045]Carpenter,B.和S.Jiang,“IPv6扩展头的传输和处理”,RFC 7045,DOI 10.17487/RFC70452013年12月<>.

[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, <>.

[RFC7312]Fabini,J.和A.Morton,“IP性能度量的高级流和采样框架(IPPM)”,RFC 7312,DOI 10.17487/RFC7312,2014年8月<>.

[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <>.

[RFC7757]Anderson,T.和A.Leiva Popper,“无状态IP/ICMP转换的显式地址映射”,RFC 7757,DOI 10.17487/RFC7757,2016年2月<>.

[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <>.

[RFC7915]Bao,C.,Li,X.,Baker,F.,Anderson,T.,和F.Gont,“IP/ICMP翻译算法”,RFC 7915,DOI 10.17487/RFC7915,2016年6月<>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <>.

[RFC8174]Leiba,B.,“RFC 2119关键词中大写与小写的歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月<>.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <>.

[RFC8200]Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,STD 86,RFC 8200,DOI 10.17487/RFC8200,2017年7月<>.

[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, <>.

[RFC8201]McCann,J.,Deering,S.,Mogul,J.,和R.Hinden,编辑,“IP版本6的路径MTU发现”,STD 87,RFC 8201,DOI 10.17487/RFC8201,2017年7月<>.

[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, <>.

[RFC8250]北埃尔金斯、右汉密尔顿和M.阿克曼,“IPv6性能和诊断指标(PDM)目标选项”,RFC 8250,DOI 10.17487/RFC8250,2017年9月<>.

9.2. Informative References
9.2. 资料性引用

[IANA-6P] IANA, "Internet Protocol Version 6 (IPv6) Parameters", <>.


[IOAM-DATA] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R.,, d., and J. Lemon, "Data Fields for In-situ OAM", Work in Progress, draft-ietf-ippm-ioam-data-03, June 2018.


[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, <>.

[RFC7594]Eardley,P.,Morton,A.,Bagnulo,M.,Burbridge,T.,Aitken,P.,和A.Akhter,“宽带性能的大规模测量框架(LMAP)”,RFC 7594,DOI 10.17487/RFC7594,2015年9月<>.



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:

美国新泽西州劳雷尔大道南米德尔顿200号阿尔莫顿AT&T实验室07748电话:+1732 420 1571传真:+1 732 368 1192电子邮件

   Joachim Fabini
   TU Wien
   Gusshausstrasse 25/E389
   Vienna  1040
   Phone: +43 1 58801 38813
   Fax:   +43 1 58801 38898
   Joachim Fabini
   TU Wien
   Gusshausstrasse 25/E389
   Vienna  1040
   Phone: +43 1 58801 38813
   Fax:   +43 1 58801 38898

Nalini Elkins Inside Products, Inc. Carmel Valley, CA 93924 United States of America Email:

Nalini Elkins Inside Products,Inc.加利福尼亚州卡梅尔谷93924美利坚合众国电子邮件:Nalini。

Michael S. Ackermann Blue Cross Blue Shield of Michigan Email:

Michael S.Ackermann蓝十字蓝盾密歇根州电子邮件

Vinayak Hegde Consultant Brahma Sun City, Wadgaon-Sheri Pune, Maharashtra 411014 India Phone: +91 9449834401 Email: URI:

Vinayak Hegde顾问婆罗门太阳城,马哈拉施特拉邦瓦德冈谢里浦那411014印度电话:+91 9449834401电子邮件:vinayakh@gmail.comURI: