[要約] RFC 8468は、IPパフォーマンスメトリクス（IPPM）フレームワークの更新であり、IPv4、IPv6、およびIPv4-IPv6の共存に関する情報を提供します。このRFCの目的は、IPネットワークのパフォーマンス測定に関するガイドラインを提供し、IPv4とIPv6の共存環境でのパフォーマンス評価を向上させることです。
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 Performance Metrics（IPPM）フレームワークを更新し、測定方法とテストに関する新しい考慮事項を追加します。標準形式のパケットの定義を更新してIPv6パケットを含め、最小限のIPパケットの定義を廃止し、RFC 2330のテストパケットのType-Pと呼ばれる特徴的な側面を強化します。このメモは、IPv4-IPv6の共存が可能であることを示しています。 IPPMフレームワークの範囲内で測定に挑戦します。使用例には、IPv4-IPv6変換、NAT、およびプロトコルのカプセル化が含まれますが、これらに限定されません。 IPv6ヘッダーの圧縮とIPv6 over Low-Power Wireless Area Networks（6LoWPAN）の使用は考慮され、標準形式のパケット評価から除外されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外で作成したりすることはできません。 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
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 Performance Metrics（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では、「標準形式」のパケットの概念が定義されています。ただし、[RFC2330]の作成者がセクション15でこの更新の必要性を明示的に示したとしても、定義はIPv6を含むように拡張されませんでした：「バージョンフィールドは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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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.
このメモの目的は、IPv6を含むようにIPPMの適用範囲を拡大し、テストパケットの追加の側面を強調し、それらを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のType-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.
多くのインターネットメトリックの基本的な特性は、メトリックの測定値が、測定に使用されたIPパケットの特性に依存することです。潜在的な影響要因には、IPヘッダーフィールドとその値、および上位層のプロトコルヘッダーとその値が含まれます。 IP接続性メトリックを検討します。たとえば、既知のTCPポートまたは予約されていないUDPポート宛てのパケット、無効なIPv4チェックサムを持つパケット、またはTTLまたはホップリミットを持つパケットの接続に関心があるかどうかによって、異なる結果が得られます。状況によっては、これらの違いにより、中間ノードとエンドシステムでパケットが特別に処理されます。たとえば、Diffserv [RFC2474]、明示的輻輳通知（ECN）[RFC3168]、ルーターアラート[RFC6398]、ホップ-by-Hop拡張[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.
この違いがあるため、「Type-Pのパケット」という一般的な概念を導入します。一部のコンテキストでは、Pは明示的に定義され（つまり、正確にどのタイプのパケットを意味するか）、部分的に定義されます（たとえば、「ペイロード付き」 of B octets "）、または左ジェネリック。したがって、一般的なIP-Type-P接続性またはより具体的なIP-port-HTTP接続性について話すことがあります。いくつかの測定基準と方法論は、一般的なType-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タイプP接続性」メトリックおよび/または「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 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.
ソースでType-Pを構成する情報が宛先で（または[RFC5644]のようにソースと宛先の間の測定ポイントで）変更されたことが判明した場合は、変更された値をメモして結果とともに報告する必要があります。一部の変更は、送信中に発生した状態（輻輳通知など）に応じて、または送信元から宛先へのパスのセグメントの要件が原因で発生します。たとえば、IPヘッダーが代替バージョン/アドレスファミリーに変換されたり、オプションの拡張ヘッダーが追加または削除されたりすると、パケット長が変化します。 TTL / Hop Limitのようなヘッダーフィールドでさえ、通常は転送中に変化するものでさえ、特定のテストに関連する場合があります。たとえば、Neighbor Discovery Protocol（NDP）[RFC4861]パケットはホップ制限値を255に設定して送信され、有効性テストでは、ホップ制限が受信機でも255でなければならないことを指定しています。したがって、他のテストでは、タイプP定義からTTL /ホップ制限値を意図的に除外する場合がありますが、この特定のテストでは、正しいホップ制限値は関連性が高く、タイプ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).
密接に関連する注記：特定のインターネットコンポーネント（ホスト、リンク、パスなど）が異なるタイプのパケットのクラス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.
パラレルパスでのロードバランシングは、そのようなクラスCがIPPM測定で決定するのがより複雑になる1つの特定の例です。ロードバランサーとルーターは、パケットが通過する利用可能な並列パスを決定するために、パケットヘッダーの（特定の部分の）ハッシュとして計算されるフロー識別子を使用することがよくあります。同一のハッシュを持つパケットは、同じフローに割り当てられ、ロードバランサー（またはルーター）のプール内の同じリソースに転送されます。パスをブラックボックスとして測定する場合、測定パス上のロードバランサーの存在、および転送の決定に使用される特定のヘッダーとフィールドは不明です。潜在的な評価シナリオには、いずれかの並列パスの測定、およびロードバランサーが使用できるすべての利用可能な並列パスの測定が含まれます。したがって、ロードバランサーのフロー定義（または、ハッシュ操作のスコープ内のヘッダーフィールドに関するクラス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を持っているか、最大TTLが255であるかのいずれかです。
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 ホップ制限が各ホップで1ずつ減らされる場合、パケットは送信元から宛先に移動するのに十分なホップ制限を持っているか、または最大ホップ制限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]で指定されている「インターネットプロトコルバージョン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.
2つのメカニズム、つまり標準形式のパケットのコンテキストでは、IPv6 over Low-Power Wireless Area Networks（6LowPAN）[RFC4944]とRobust Header Compression（ROHC）[RFC3095]について議論する必要があります。 [RFC4944]で定義され、[RFC6282]によってヘッダー圧縮と[RFC6775]によってネイバー探索最適化が更新された6LowPANは、リソースに制約のある環境でIPv6を使用するためのソリューションを提案します。アダプテーション層により、MTUが最小IPv6 MTUよりも小さいネットワークを介したIPv6パケットの転送が可能になります。 IPv6パケットの断片化と再構成、および中間ノードに格納される結果の状態は、測定に大きな課題をもたらします。同様に、ROHCはサブパスのヘッダーを圧縮してステートを中間ホストに保存することでステートフルに動作します。 ROHCおよび6LowPANによる測定パケットのType-Pの変更には、これら2つのプロトコルの標準形式のパケットの概念に関する要件と同様に、かなりの作業が必要です。これらの理由から、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拡張ヘッダーのトピックは現在の論争に焦点を当てています。ただし、エンタープライズ環境のin situ OAM [IOAM-DATA]など、IPPMフレームワークのコンテキストでの測定のユースケースは、測定パスに沿ったホストのIPv6拡張ヘッダーの検査、変更、追加、または削除からメリットを得ることができます。
[RFC8250] endorses the use of the IPv6 Destination Option for measurement purposes, consistent with other relevant and approved IETF specifications.
[RFC8250]は、他の関連する承認されたIETF仕様と一致する、測定目的でのIPv6宛先オプションの使用を推奨します。
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パケット全体を検査する場合があります。例外的なケースでは、次善のパスを介してパケットまたはルートをドロップする可能性があり、測定値の信頼性や再現性が低下する可能性があります。パケット（到着した場合）は、対応するType-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でエンコードされた一部のオプションは、転送中に中間ノードで変更することが許可される場合があります。結果のパケットは、対応するType-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 拡張ヘッダーの挿入または削除：このような動作は現在の標準では承認されていませんが、拡張ヘッダーをヘッダーチェーンに追加したり、ヘッダーチェーンから削除したりすることが可能です。結果のパケットは、対応するType-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 パケット長の変化（ソースで観測された対応するパケットから）またはヘッダーの変更は、インターネット測定の重要な要素であり、テスト結果とともに報告される新しいType-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.
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 Diffservフィールドが0に設定された標準形式のパケットのIP-Type-P-接続性、またはより簡潔に言えば、「IP-Type-P-標準形式はすでに慣例によって暗示されているため、IP Diffservフィールドを0に設定した接続。 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".
[RFC2330]は、「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フレームワークの2つの重要な規則、つまりType-Pのパケットと標準形式のパケットでIPv6を利用するための重要な考慮事項を追加します。 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ヘッダー圧縮などの使用例では、パスに沿った測定パケットのType-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ヘッダー圧縮メカニズムにより、測定パケットのType-Pも変更される場合があります。その結果、Type-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は、フローの最初のパケットに対して状態を作成する必要があり、NATがリソースを使い果たすと後で失われる可能性があるため、特定のタイプPのフローのパフォーマンスが不安定になる可能性があります。ただし、このシナリオではType-Pがテスト用に無効になることはありません。たとえば、テストの目的は、遅延変動に対するNATの影響を正確に定量化することです。 NATの存在は、Type-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移行メカニズムによる変更の副作用の1つは、中間ノードがヘッダー変更で経験する可変遅延です。 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 / RFC0791、1981年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.、Madhavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、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]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（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 Jumbograms」、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。、福島、H.、Hannu、H.、Jonsson、LE。、Hakenberg、R.、Koren、T.、Le、K.、Liu、 Z.、Martensson、A。、宮崎、A.、Svanbro、K.、Wiebke、T。、吉村、T。、およびH. Zheng、「RObust Header Compression（ROHC）：Framework and 4 profiles：RTP、UDP、 ESP、および非圧縮」、RFC 3095、DOI 10.17487 / RFC3095、2001年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]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「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、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006、<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、「Packetization Layer Path MTU Discovery」、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、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年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。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「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、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008、<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 Performance Metrics（IPPM）：Spatial and Multicast」、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]モートン、A。、エド。およびS. Van den Berghe編、「Framework for Metric Composition」、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 6144、DOI 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]ホイ、J。、エド。および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。、編、「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 Flow Label Specification」、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、「A Uniform Format for IPv6 Extension Headers」、RFC 6564、DOI 10.17487 / RFC6564、April 2012、< 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]シェルビー、Z。、編、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「ローパワーワイヤレスパーソナルエリアネットワーク（6LoWPANs）を介したIPv6のネイバー探索最適化」、RFC 6775、DOI 10.17487 / RFC6775、2012年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 / RFC7045、2013年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]アンダーソン、T。およびA.リーバポッパー、「ステートレス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、編、「Path MTU Discovery for IP version 6」、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] Elkins、N.、Hamilton、R。、およびM. Ackermann、「IPv6 Performance and Diagnostic Metrics（PDM）Destination Option」、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、「In-situ OAMのデータフィールド」、Work in Progress、draft-ietf-ippm-ioam-data-03、2018年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.
著者は、IPPMのフレームワークにIPv6カバレッジが不足していることを特定し、Type-Pのパケットを区別する追加の要素を列挙してくれたBrian Carpenterに感謝します。ブライアンとフレッドベイカーの両方が、共著者とIPv6の興味深い側面の多くについて話し合ったため、より強固な最初のドラフトが作成されました。 00より前のテキストを編集してくれたBill Jourisに感謝します。私たちが旅を終えたとき、Nevil Brownlee、Mike Heard、Spencer Dawkins、Warren Kumari、Suresh Krishnanのすべてが有益な提案をしてくれました。
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
アルモートンAT＆Tラボ200ローレルアベニューサウスミドルタウン、ニュージャージー07748アメリカ合衆国電話：+1 732 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/
Nalini Elkins Inside Products, Inc. Carmel Valley, CA 93924 United States of America Email: nalini.elkins@insidethestack.com
Nalini Elkins Inside Products、Inc. Carmel Valley、CA 93924 United States of Americaメール：nalini.elkins@insidethestack.com
Michael S. Ackermann Blue Cross Blue Shield of Michigan Email: mackermann@bcbsm.com
Michael S. Ackermann Blue Cross Blue Shield of Michiganメール：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コンサルタントBrama Ma Sun City、Wadgaon-Sheri Pune、Maharashtra 411014 India電話：+91 9449834401メール：vinayakh@gmail.com URI：http://www.vinayakhegde.com