[要約] RFC 9343は、IPv6ドメインでのパッシブな性能測定ツールとしてAlternate-Marking Methodを使用する方法を説明し、Hop-by-Hop Options HeaderとDestination Options HeaderにAlternate-Marking情報をエンコードするための拡張ヘッダーオプションを定義しています。
Internet Engineering Task Force (IETF) G. Fioccola
Request for Comments: 9343 T. Zhou
Category: Standards Track Huawei
ISSN: 2070-1721 M. Cociglio
Telecom Italia
F. Qin
China Mobile
R. Pang
China Unicom
December 2022
This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header.
このドキュメントでは、IPv6ドメインのパッシブパフォーマンス測定ツールとして代替マークメソッドをどのように使用できるかについて説明します。ホップバイホップオプションヘッダーと宛先オプションヘッダーの両方で、代替マーク情報をエンコードする拡張ヘッダーオプションを定義します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9343.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9343で取得できます。
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
1.2. Requirements Language
2. Alternate-Marking Application to IPv6
2.1. Controlled Domain
2.1.1. Alternate-Marking Measurement Domain
3. Definition of the AltMark Option
3.1. Data Fields Format
4. Use of the AltMark Option
5. Alternate-Marking Method Operation
5.1. Packet Loss Measurement
5.2. Packet Delay Measurement
5.3. Flow Monitoring Identification
5.4. Multipoint and Clustered Alternate Marking
5.5. Data Collection and Calculation
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
[RFC9341] and [RFC9342] describe a passive performance measurement method, which can be used to measure packet loss, latency, and jitter on live traffic. Since this method is based on marking consecutive batches of packets, the method is often referred to as the Alternate-Marking Method.
[RFC9341]および[RFC9342]は、ライブトラフィックのパケット損失、待ち時間、およびジッターを測定するために使用できるパッシブパフォーマンス測定方法を説明しています。この方法はパケットの連続バッチをマークすることに基づいているため、この方法は多くの場合、代替マークメソッドと呼ばれます。
This document defines how the Alternate-Marking Method can be used to measure performance metrics in IPv6. The rationale is to apply the Alternate-Marking methodology to IPv6 and therefore allow detailed packet loss, delay, and delay variation measurements both hop by hop and end to end to exactly locate the issues in an IPv6 network.
このドキュメントでは、IPv6のパフォーマンスメトリックを測定するために代替マークメソッドを使用する方法を定義しています。理論的根拠は、代替マーキング方法論をIPv6に適用するため、ホップごとに詳細なパケット損失、遅延、および遅延変動測定値が、IPv6ネットワーク内の問題を正確に見つけるためにホップとエンドの両方で終了することです。
Alternate Marking is an on-path telemetry technique and consists of synchronizing the measurements in different points of a network by switching the value of a marking bit and therefore dividing the packet flow into batches. Each batch represents a measurable entity recognizable by all network nodes along the path. By counting the number of packets in each batch and comparing the values measured by different nodes, it is possible to precisely measure the packet loss. Similarly, the alternation of the values of the marking bits can be used as a time reference to calculate the delay and delay variation. The Alternate-Marking operation is further described in Section 5.
代替マーキングは、パス上のテレメトリ手法であり、マーキングビットの値を切り替えることにより、ネットワークの異なるポイントの測定値を同期することで構成され、したがってパケットフローをバッチに分割します。各バッチは、パスに沿ったすべてのネットワークノードによって認識可能な測定可能なエンティティを表します。各バッチ内のパケットの数をカウントし、異なるノードで測定された値を比較することにより、パケットの損失を正確に測定することができます。同様に、マーキングビットの値の代替は、遅延と遅延の変動を計算するための時間参照として使用できます。代替マーキング操作については、セクション5でさらに説明します。
This document introduces a TLV (type-length-value) that can be encoded in the Options Headers (Hop-by-Hop or Destination), according to [RFC8200], for the purpose of the Alternate-Marking Method application in an IPv6 domain.
このドキュメントでは、[RFC8200]に従って、IPv6ドメインでの代替マークメソッドアプリケーションの目的で、[RFC8200]に従って、オプションヘッダー（ホップバイホップまたは宛先）でエンコードできるTLV（タイプ長値）を紹介します。。
The Alternate-Marking Method MUST be applied to IPv6 only in a controlled environment, as further described in Section 2.1. [RFC8799] provides further discussion of network behaviors that can be applied only within limited domains.
セクション2.1でさらに説明したように、制御された環境でのみ、代替マークメソッドをIPv6に適用する必要があります。[RFC8799]は、限られたドメイン内でのみ適用できるネットワーク動作のさらなる議論を提供します。
The threat model for the application of the Alternate-Marking Method in an IPv6 domain is reported in Section 6.
IPv6ドメインでの代替マーク法を適用するための脅威モデルは、セクション6で報告されています。
This document uses the terms related to the Alternate-Marking Method as defined in [RFC9341] and [RFC9342].
このドキュメントでは、[RFC9341]および[RFC9342]で定義されている代替マーク法に関連する用語を使用します。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The Alternate-Marking Method requires a marking field. Several alternatives could be considered such as IPv6 Extension Headers, IPv6 Address, and Flow Label. But, it is necessary to analyze the drawbacks for all the available possibilities, more specifically:
代替マーキング方法には、マーキングフィールドが必要です。IPv6拡張ヘッダー、IPv6アドレス、フローラベルなど、いくつかの選択肢を考慮することができます。しかし、利用可能なすべての可能性の欠点をより具体的に分析する必要があります。
* reusing an existing Extension Header for Alternate Marking leads to a non-optimized implementation;
* 既存の拡張機能ヘッダーを代替マーキングのために再利用すると、最適化されていない実装につながります。
* using the IPv6 destination address to encode the Alternate-Marking processing is very expensive; and
* IPv6宛先アドレスを使用して代替マーク処理をエンコードするのは非常に高価です。そして
* using the IPv6 Flow Label for Alternate Marking conflicts with the utilization of the Flow Label for load distribution purposes [RFC6438].
* 代替マーキングのためにIPv6フローラベルを使用して、負荷分布の目的でフローラベルの使用と競合します[RFC6438]。
In the end, a Hop-by-Hop or a Destination Option is the best choice.
最終的に、ホップバイホップまたは宛先オプションが最良の選択です。
The approach for the Alternate-Marking application to IPv6 specified in this memo is compliant with [RFC8200]. It involves the following operations:
このメモで指定されたIPv6への代替マーキングアプリケーションのアプローチは、[RFC8200]に準拠しています。次の操作が含まれます。
* The source node is the only one that writes the Options Header to mark alternately the flow (for both the Hop-by-Hop and Destination Option). The intermediate nodes and destination node MUST only read the marking values of the Option without modifying the Options Header.
* ソースノードは、フローを交互にマークするオプションヘッダーを書き込む唯一のものです（ホップバイホップと宛先オプションの両方）。中間ノードと宛先ノードは、オプションヘッダーを変更せずにオプションのマーキング値のみを読み取る必要があります。
* In case of a Hop-by-Hop Options Header carrying Alternate-Marking bits, the Options Header is not inserted or deleted on the path, but it can be read by any node along the path. The intermediate nodes may be configured to support this Option or not, and the measurement can be done only for the nodes configured to read the Option. As further discussed in Section 4, the presence of the Hop-by-Hop Option should not affect the traffic throughput both on nodes that do not recognize this Option and on the nodes that support it. However, it is worth mentioning that there is a difference between theory and practice. Indeed, in a real implementation, it is possible for packets with a Hop-by-Hop Option to be skipped or processed in the slow path. While some proposals are trying to address this problem and make Hop-by-Hop Options more practical (see [PROC-HBH-OPT-HEADER] and [HBH-OPTIONS-PROCESSING]), these aspects are out of the scope for this document.
* 代替マークビットを運ぶホップバイホップオプションヘッダーの場合、オプションヘッダーはパスに挿入または削除されませんが、パスに沿ったノードで読み取ることができます。中間ノードは、このオプションをサポートするかどうかを構成することができ、測定はオプションを読み取るように構成されたノードに対してのみ実行できます。セクション4でさらに説明したように、ホップバイホップオプションの存在は、このオプションを認識しないノードとそれをサポートするノードの両方でトラフィックスループットに影響を及ぼさないはずです。ただし、理論と実践には違いがあることに言及する価値があります。実際、実際の実装では、ホップバイホップオプションを備えたパケットがスローパスでスキップまたは処理される可能性があります。いくつかの提案は、この問題に対処し、ホップバイホップオプションをより実用的にしようとしていますが（[proc-hbh-opt-header]および[hbh-options-crocessing]）、これらの側面はこのドキュメントの範囲外です。
* In case of a Destination Options Header carrying Alternate-Marking bits, it is not processed, inserted, or deleted by any node along the path until the packet reaches the destination node. Note that, if there is also a Routing Header (RH), any visited destination in the route list can process the Options Header.
* 代替マークビットを運ぶ宛先オプションヘッダーの場合、パケットが宛先ノードに到達するまで、パスに沿ってノードによって処理、挿入、または削除されません。ルーティングヘッダー（RH）もある場合、ルートリストに訪問された宛先はオプションヘッダーを処理できることに注意してください。
A Hop-by-Hop Options Header is also useful to signal to routers on the path to process the Alternate Marking. However, as said, routers will only examine this Option if properly configured.
ホップバイホップオプションヘッダーは、交代マーキングを処理するパス上のルーターに信号を送信するのにも役立ちます。ただし、言われたように、ルーターは適切に構成された場合にのみこのオプションを調べます。
The optimization of both implementation and the scaling of the Alternate-Marking Method is also considered, and a way to identify flows is required. The Flow Monitoring Identification (FlowMonID) field, as introduced in Section 5.3, goes in this direction, and it is used to identify a monitored flow.
実装と代替マルキング方法のスケーリングの両方の最適化も考慮され、フローを識別する方法が必要です。セクション5.3で導入されたフロー監視識別（FlowMonid）フィールドは、この方向に進み、監視されたフローを識別するために使用されます。
The FlowMonID is different from the Flow Label field of the IPv6 header [RFC6437]. The Flow Label field in the IPv6 header is used by a source to label sequences of packets to be treated in the network as a single flow and, as reported in [RFC6438], it can be used for load balancing (LB) and equal-cost multipath (ECMP). The reuse of the Flow Label field for identifying monitored flows is not considered because it may change the application intent and forwarding behavior. Also, the Flow Label may be changed en route, and this may also invalidate the integrity of the measurement. Those reasons make the definition of the FlowMonID necessary for IPv6. Indeed, the FlowMonID is designed and only used to identify the monitored flow. Flow Label and FlowMonID within the same packet are totally disjoint, have different scopes, are used to identify flows based on different criteria, and are intended for different use cases.
Flowmonidは、IPv6ヘッダー[RFC6437]のフローラベルフィールドとは異なります。IPv6ヘッダーのフローラベルフィールドは、ソースによって使用されて、ネットワーク内で単一のフローとして扱われるパケットのシーケンスをラベル付けし、[RFC6438]で報告されているように、ロードバランス（LB）および等しいものに使用できます。コストマルチパス（ECMP）。監視されたフローを識別するためのフローラベルフィールドの再利用は、アプリケーションの意図と転送の動作を変更する可能性があるため、考慮されません。また、フローラベルは途中で変更される場合があり、これは測定の完全性を無効にする可能性もあります。これらの理由は、IPv6に必要なフローモニドの定義を作成します。実際、Flowmonidは設計されており、監視対象の流れを識別するためにのみ使用されます。同じパケット内のフローラベルとフローモニドは完全にばらばらであり、異なるスコープを持ち、異なる基準に基づいてフローを識別するために使用され、異なるユースケースを対象としています。
The rationale for the FlowMonID is further discussed in Section 5.3. This 20-bit field allows easy and flexible identification of the monitored flow and enables improved measurement correlation and finer granularity since it can be used in combination with the conventional TCP/IP 5-tuple to identify a flow. An important point that will be discussed in Section 5.3 is the uniqueness of the FlowMonID and how to allow disambiguation of the FlowMonID in case of collision.
Flowmonidの理論的根拠については、セクション5.3でさらに説明します。この20ビットフィールドは、監視されたフローの簡単で柔軟な識別を可能にし、従来のTCP/IP 5タプルと組み合わせてフローを識別できるため、測定相関とより細かい粒度を改善できます。セクション5.3で議論される重要なポイントは、Flowmonidの独自性と、衝突の場合にFlowmonidの曖昧性を掘り下げる方法です。
The following section highlights an important requirement for the application of the Alternate Marking to IPv6. The concept of the controlled domain is explained and is considered an essential precondition, as also highlighted in Section 6.
次のセクションでは、IPv6に代替マーキングを適用するための重要な要件を強調しています。制御されたドメインの概念が説明されており、セクション6で強調されているように、本質的な前提条件と見なされます。
IPv6 has much more flexibility than IPv4 and innovative applications have been proposed, but for security and compatibility reasons, some of these applications are limited to a controlled environment. This is also the case of the Alternate-Marking application to IPv6 as assumed hereinafter. In this regard, [RFC8799] reports further examples of specific limited domain solutions.
IPv6はIPv4よりもはるかに柔軟性があり、革新的なアプリケーションが提案されていますが、セキュリティと互換性の理由により、これらのアプリケーションの一部は制御された環境に限定されています。これは、以下に想定されているIPv6への代替マーキングアプリケーションの場合でもあります。この点で、[RFC8799]は、特定の限定ドメインソリューションのさらなる例を報告しています。
The IPv6 application of the Alternate-Marking Method MUST be deployed in a controlled domain. It is not common that the user traffic originates and terminates within the controlled domain, as also noted in Section 2.1.1. For this reason, it will typically only be applicable in an overlay network, where user traffic is encapsulated at one domain border and decapsulated at the other domain border, and the encapsulation incorporates the relevant extension header for Alternate Marking. This requirement also implies that an implementation MUST filter packets that carry Alternate-Marking data and are entering or leaving the controlled domain.
代替マーキング法のIPv6アプリケーションは、制御ドメインに展開する必要があります。セクション2.1.1でも述べているように、ユーザートラフィックが制御ドメイン内で発生および終了することは一般的ではありません。このため、通常、オーバーレイネットワークでのみ適用できます。オーバーレイネットワークでは、ユーザートラフィックが1つのドメインボーダーでカプセル化され、他のドメイン境界で脱カプセル化され、カプセル化には、代替マーキングに関連する拡張ヘッダーが組み込まれます。また、この要件は、実装が代替マークデータを運ぶパケットをフィルタリングし、制御されたドメインを入力または離れる必要があることを意味します。
A controlled domain is a managed network where it is required to select, monitor, and control the access to the network by enforcing policies at the domain boundaries in order to discard undesired external packets entering the domain and check the internal packets leaving the domain. It does not necessarily mean that a controlled domain is a single administrative domain or a single organization. A controlled domain can correspond to a single administrative domain or can be composed by multiple administrative domains under a defined network management. Indeed, some scenarios may imply that the Alternate-Marking Method involves more than one domain, but in these cases, it is RECOMMENDED that the multiple domains create a whole controlled domain while traversing the external domain by employing IPsec [RFC4301] authentication and encryption or other VPN technology that provides full packet confidentiality and integrity protection. In a few words, it must be possible to control the domain boundaries and eventually use specific precautions if the traffic traverses the Internet.
制御されたドメインは、ドメインの境界でポリシーを強制することにより、ドメインに入る不要な外部パケットを破棄し、ドメインを離れる内部パケットをチェックすることにより、ネットワークへのアクセスを選択、監視、制御する必要がある管理ネットワークです。制御されたドメインが単一の管理ドメインまたは単一の組織であることを必ずしも意味するものではありません。制御されたドメインは、単一の管理ドメインに対応するか、定義されたネットワーク管理の下で複数の管理ドメインによって構成できます。実際、いくつかのシナリオは、代替マルキング方法に複数のドメインが関与することを意味する場合がありますが、これらの場合、複数のドメインがIPSEC [RFC4301]認証と暗号化または暗号化を使用して外部ドメインを通過しながら、制御ドメイン全体を作成することをお勧めします。完全なパケットの機密性と整合性保護を提供する他のVPNテクノロジー。いくつかの言葉では、ドメインの境界を制御し、トラフィックがインターネットを横断する場合、最終的に特定の注意事項を使用することが可能である必要があります。
The security considerations reported in Section 6 also highlight this requirement.
セクション6で報告されているセキュリティ上の考慮事項も、この要件を強調しています。
The Alternate-Marking measurement domain can overlap with the controlled domain or may be a subset of the controlled domain. The typical scenarios for the application of the Alternate-Marking Method depend on the controlled domain boundaries; in particular:
代替マーキング測定ドメインは、制御ドメインと重複するか、制御ドメインのサブセットである場合があります。代替マーク法を適用するための典型的なシナリオは、制御されたドメイン境界に依存します。特に：
* The user equipment can be the starting or ending node only when/if it is fully managed and belongs to the controlled domain. In this case, the user-generated IPv6 packets contain the Alternate-Marking data. But, in practice, this is not common due to the fact that the user equipment cannot be totally secured in the majority of cases.
* ユーザー機器は、完全に管理され、制御ドメインに属している場合にのみ、開始ノードまたは終了ノードにすることができます。この場合、ユーザーが生成したIPv6パケットには、代替マークデータが含まれています。しかし、実際には、これは、ほとんどの場合にユーザー機器を完全に保護できないという事実のために一般的ではありません。
* The Customer Premises Equipment (CPE) or the Provider Edge (PE) routers are most likely to be the starting or ending nodes since they can be border routers of the controlled domain. For instance, the CPE, which connects the user's premises with the service provider's network, belongs to a controlled domain only if it is managed by the service provider and if additional security measures are taken to keep it trustworthy. Typically, the CPE or the PE can encapsulate a received packet in an outer IPv6 header, which contains the Alternate-Marking data. They are also able to filter and drop packets from outside of the domain with inconsistent fields to make effective the relevant security rules at the domain boundaries; for example, a simple security check can be to insert the Alternate-Marking data if and only if the destination is within the controlled domain.
* Customer Premsiseの機器（CPE）またはプロバイダーエッジ（PE）ルーターは、制御ドメインのボーダールーターになる可能性があるため、開始ノードまたは終了ノードになる可能性が最も高くなります。たとえば、ユーザーの施設をサービスプロバイダーのネットワークに接続するCPEは、サービスプロバイダーによって管理されている場合のみ、およびそれを信頼できるものに保つために追加のセキュリティ対策が取られた場合にのみ、制御ドメインに属します。通常、CPEまたはPEは、代替マークデータを含む外側のIPv6ヘッダーの受信したパケットをカプセル化できます。また、ドメインの外側から一貫性のないフィールドを備えたパケットをフィルタリングおよびドロップして、ドメインの境界で関連するセキュリティルールを効果的にすることもできます。たとえば、簡単なセキュリティチェックは、宛先が制御ドメイン内にある場合にのみ、代替マークデータを挿入することです。
The definition of a TLV for the Extension Header Option, carrying the data fields dedicated to the Alternate-Marking Method, is reported below.
拡張ヘッダーオプションのTLVの定義は、代替マーキング方法専用のデータフィールドを運ぶことを以下に報告します。
The following figure shows the data fields format for enhanced Alternate-Marking TLV (AltMark). This AltMark data can be encapsulated in the IPv6 Options Headers (Hop-by-Hop or Destination Option).
次の図は、拡張された代替マークTLV（Altmark）のためのデータフィールド形式を示しています。このAltmarkデータは、IPv6オプションヘッダー（ホップバイホップまたは宛先オプション）にカプセル化できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowMonID |L|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
ただし：
Option Type:
オプションタイプ：
8-bit identifier of the type of Option that needs to be allocated. Unrecognized Types MUST be ignored on processing. For the Hop-by-Hop Options Header or Destination Options Header, [RFC8200] defines how to encode the three high-order bits of the Option Type field. The two high-order bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type; for AltMark, these two bits MUST be set to 00 (skip over this Option and continue processing the header). The third-highest-order bit specifies whether the Option Data can change en route to the packet's final destination; for AltMark, the value of this bit MUST be set to 0 (Option Data does not change en route). In this way, since the three high-order bits of the AltMark Option are set to 000, it means that nodes can simply skip this Option if they do not recognize it and that the data of this Option does not change en route; indeed the source is the only one that can write it.
割り当てる必要があるオプションのタイプの8ビット識別子。処理時に認識されていないタイプを無視する必要があります。ホップバイホップオプションヘッダーまたは宛先オプションヘッダーの場合、[RFC8200]は、オプションタイプフィールドの3つの高次ビットをエンコードする方法を定義します。2つの高次ビットは、処理IPv6ノードがオプションタイプを認識しない場合に実行する必要があるアクションを指定します。Altmarkの場合、これら2つのビットを00に設定する必要があります（このオプションをスキップして、ヘッダーの処理を続けます）。3番目に高いオーダービットは、オプションデータがパケットの最終目的地に向けて変更できるかどうかを指定します。Altmarkの場合、このビットの値は0に設定する必要があります（オプションデータは途中で変更されません）。このように、Altmarkオプションの3つの高次ビットは000に設定されているため、ノードがそれを認識せず、このオプションのデータが途中で変更されない場合、ノードはこのオプションを単純にスキップできることを意味します。確かに、それを書くことができる唯一のソースはソースです。
Opt Data Len:
Opt DataLen：
4. It is the length of the Option Data Fields of this Option in bytes.
4. これは、バイト内のこのオプションのオプションデータフィールドの長さです。
FlowMonID:
Flowmonid：
20-bit unsigned integer. The FlowMon identifier is described in Section 5.3. As further discussed below, it has been picked as 20 bits since it is a reasonable value and a good compromise in relation to the chance of collision. It MUST be set pseudo-randomly by the source node or by a centralized controller.
20ビットの符号なし整数。Flowmon識別子は、セクション5.3で説明されています。以下でさらに説明するように、それは衝突の可能性に関連する合理的な価値と良い妥協であるため、20ビットとして選ばれました。ソースノードまたは集中コントローラーによって擬似ランダムリーを設定する必要があります。
L:
L：
Loss flag for Packet Loss Measurement as described in Section 5.1.
セクション5.1で説明されているパケット損失測定の損失フラグ。
D:
D：
Delay flag for Single Packet Delay Measurement as described in Section 5.2.
セクション5.2で説明されているように、単一パケット遅延測定の遅延フラグ。
Reserved:
予約済み：
Reserved for future use. These bits MUST be set to zero on transmission and ignored on receipt.
将来の使用のために予約されています。これらのビットは、送信時にゼロに設定し、受領時に無視する必要があります。
The AltMark Option is the best way to implement the Alternate-Marking Method, and it is carried by the Hop-by-Hop Options Header and the Destination Options Header. In case of Destination Option, it is processed only by the source and destination nodes: the source node inserts it and the destination node processes it. In case of the Hop-by-Hop Option, it may be examined by any node along the path if explicitly configured to do so.
Altmarkオプションは、代替マーキング方法を実装する最良の方法であり、ホップバイホップオプションヘッダーと宛先オプションヘッダーによって運ばれます。宛先オプションの場合、ソースノードと宛先ノードによってのみ処理されます。ソースノードはそれを挿入し、宛先ノードが処理します。ホップバイホップオプションの場合、そのように明示的に構成されている場合、パスに沿ったノードで調べることができます。
It is important to highlight that the Option Layout can be used both as the Destination Option and as the Hop-by-Hop Option depending on the use cases, and it is based on the chosen type of performance measurement. In general, it is needed to perform both end-to-end and hop-by-hop measurements, and the Alternate-Marking methodology allows, by definition, both performance measurements. In many cases, the end-to-end measurement may not be enough, and the hop-by-hop measurement is required. To meet this need, the most complete choice is the Hop-by-Hop Options Header.
オプションレイアウトは、ユースケースに応じて、宛先オプションとホップバイホップオプションとして使用できることを強調することが重要です。また、選択したタイプのパフォーマンス測定に基づいています。一般に、エンドツーエンドとホップバイホップの両方の測定を実行する必要があり、代替マーキング方法論により、定義上、両方のパフォーマンス測定が可能になります。多くの場合、エンドツーエンドの測定では十分ではなく、ホップバイホップ測定が必要です。このニーズを満たすために、最も完全な選択は、ホップバイホップオプションヘッダーです。
IPv6, as specified in [RFC8200], allows nodes to optionally process Hop-by-Hop headers. Specifically, the Hop-by-Hop Options Header is not inserted or deleted, but it may be examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes in the case of multicast) identified in the Destination Address field of the IPv6 header. Also, it is expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options Header if explicitly configured to do so.
[RFC8200]で指定されているIPv6では、ノードがオプションでホップバイホップヘッダーを処理できます。具体的には、ホップバイホップオプションヘッダーは挿入または削除されませんが、パケットがノードに到達するまで（またはの場合、ノードのセットの各セットに到達するまで、パケットの配信パスに沿って任意のノードで調べまたは処理される場合があります。Multicast）IPv6ヘッダーの宛先アドレスフィールドで識別されます。また、パケットの配信パスに沿ったノードは、明示的に設定されている場合にのみ、ホップバイホップオプションヘッダーを調べて処理することが予想されます。
Another scenario is the presence of a Routing Header. Both Hop-by-Hop Options and Destination Options Headers can be used when a Routing Header is present. Depending on where the Destination Options are situated in the header chain (before or after the Routing Header if any), Destination Options Headers can be processed by either intermediate routers specified in the Routing Header or the destination node. As an example, a type of Routing Header, referred to as a Segment Routing Header (SRH), has been defined in [RFC8754] for the Segment Routing over IPv6 (SRv6) data place, and more details about the SRv6 application can be found in [SRv6-AMM].
別のシナリオは、ルーティングヘッダーの存在です。ルーティングヘッダーが存在する場合、ホップバイホップオプションと宛先オプションヘッダーの両方を使用できます。宛先オプションがヘッダーチェーン内にある場所（ルーティングヘッダーがある場合は、ルーティングヘッダーの前または後）に応じて、宛先オプションヘッダーは、ルーティングヘッダーまたは宛先ノードで指定された中間ルーターによって処理できます。例として、セグメントルーティングヘッダー（SRH）と呼ばれるルーティングヘッダーのタイプは、IPv6（SRV6）データプレイスを介してセグメントルーティングの[RFC8754]で定義されており、SRV6アプリケーションの詳細については、見つけることができます。[srv6-amm]で。
In summary, using these tools, it is possible to control on which nodes measurement occurs:
要約すると、これらのツールを使用して、どのノード測定が発生するかを制御することができます。
* Destination Option not preceding a Routing Header => measurement only by node in Destination Address
* ルーティングヘッダーの前にない宛先オプション=>宛先アドレスのノードのみでのみ測定
* Hop-by-Hop Option => every router on the path with feature enabled
* ホップバイホップオプション=>機能が有効になっているパス上のすべてのルーター
* Destination Option preceding a Routing Header => every destination node in the route list
* ルーティングヘッダーの前に宛先オプション=>ルートリスト内のすべての宛先ノード
In general, Hop-by-Hop and Destination Options are the most suitable ways to implement Alternate Marking.
一般に、ホップバイホップと目的地のオプションは、代替マーキングを実装する最も適切な方法です。
It is worth mentioning that Hop-by-Hop Options are not strongly recommended in [RFC7045] and [RFC8200], unless there is a clear justification to standardize it, because nodes may be configured to ignore the Options Header or drop or assign packets containing an Options Header to a slow processing path. In case of the AltMark Data Fields described in this document, the motivation to standardize a Hop-by-Hop Option is that it is needed for Operations, Administration, and Maintenance (OAM). An intermediate node can read it or not, but this does not affect the packet behavior. The source node is the only one that writes the Hop-by-Hop Option to alternately mark the flow; therefore, the performance measurement can be done for those nodes configured to read this Option, while the others are simply not considered for the metrics.
ノードは、[RFC7045]および[RFC8200]では[RFC7045]および[RFC8200]では強く推奨されていないことを言及する価値があります。遅い処理パスへのオプションヘッダー。このドキュメントで説明されているAltmarkデータフィールドの場合、ホップバイホップオプションを標準化する動機は、運用、管理、およびメンテナンス（OAM）に必要であることです。中間ノードはそれを読み取るかどうかを読むことができますが、これはパケット動作に影響しません。ソースノードは、フローを交互にマークするホップバイホップオプションを書き込む唯一のものです。したがって、このオプションを読み取るように構成されたノードでは、パフォーマンス測定を実行できますが、他のノードは単にメトリックでは考慮されません。
The Hop-by-Hop Option defined in this document is designed to take advantage of the property of how Hop-by-Hop Options are processed. Nodes that do not support this Option would be expected to ignore it if encountered, according to the procedures of [RFC8200]. This can mean that, in this case, the performance measurement does not account for all links and nodes along a path. The definition of the Hop-by-Hop Options in this document is also designed to minimize throughput impact both on nodes that do not recognize the Option and on nodes that support it. Indeed, the three high-order bits of the Options Header defined in this document are 000 and, in theory, as per [RFC8200] and [HBH-OPTIONS-PROCESSING], this means "skip if not recognized and data does not change en route". [RFC8200] also mentions that the nodes only examine and process the Hop-by-Hop Options Header if explicitly configured to do so. For these reasons, this Hop-by-Hop Option should not affect the throughput. However, in practice, it is important to be aware that things may be different in the implementation, and it can happen that packets with Hop by Hop are forced onto the slow path, but this is a general issue, as also explained in [HBH-OPTIONS-PROCESSING]. It is also worth mentioning that the application to a controlled domain should avoid the risk of arbitrary nodes dropping packets with Hop-by-Hop Options.
このドキュメントで定義されているホップバイホップオプションは、ホップバイホップオプションの処理方法のプロパティを活用するように設計されています。[RFC8200]の手順に従って、このオプションをサポートしていないノードは、遭遇した場合にそれを無視すると予想されます。これは、この場合、パフォーマンス測定がパスに沿ったすべてのリンクとノードを考慮していないことを意味します。このドキュメントのホップバイホップオプションの定義は、オプションを認識しないノードとそれをサポートするノードの両方にスループットの影響を最小限に抑えるように設計されています。実際、このドキュメントで定義されているオプションヘッダーの3つの高次ビットは000であり、理論的には[RFC8200]および[HBH-Options-Processing]に従って、これは「認識されない場合はスキップし、データは変わらないことを意味します。ルート"。[RFC8200]は、明示的に設定されている場合にのみノードがホップバイホップオプションヘッダーを調べて処理することのみを述べています。これらの理由により、このホップバイホップオプションはスループットに影響しないはずです。ただし、実際には、実装では事態が異なる可能性があることに注意することが重要であり、ホップバイホップ付きのパケットがスローパスに強制されることが起こる可能性がありますが、これは[HBHでも説明されている一般的な問題です。-options-processing]。また、制御されたドメインへのアプリケーションは、ホップバイホップオプションでパケットをドロップする任意のノードのリスクを回避する必要があることに言及する価値があります。
This section describes how the method operates. [RFC9341] introduces several applicable methods, which are reported below, and an additional field is introduced to facilitate the deployment and improve the scalability.
このセクションでは、メソッドの動作方法について説明します。[RFC9341]は、以下に報告されているいくつかの適用可能な方法を導入し、展開を容易にし、スケーラビリティを改善するために追加のフィールドが導入されています。
The measurement of the packet loss is really straightforward in comparison to the existing mechanisms, as detailed in [RFC9341]. The packets of the flow are grouped into batches, and all the packets within a batch are marked by setting the L bit (Loss flag) to a same value. The source node can switch the value of the L bit between 0 and 1 after a fixed number of packets or according to a fixed timer, and this depends on the implementation. The source node is the only one that marks the packets to create the batches, while the intermediate nodes only read the marking values and identify the packet batches. By counting the number of packets in each batch and comparing the values measured by different network nodes along the path, it is possible to measure the packet loss that occurred in any single batch between any two nodes. Each batch represents a measurable entity recognizable by all network nodes along the path.
[RFC9341]で詳述されているように、パケット損失の測定は、既存のメカニズムと比較して非常に簡単です。フローのパケットはバッチにグループ化され、バッチ内のすべてのパケットはLビット（損失フラグ）を同じ値に設定することでマークされます。ソースノードは、固定数のパケット数または固定タイマーに従って、Lビットの値を0〜1の間に切り替えることができ、これは実装に依存します。ソースノードは、バッチを作成するためにパケットをマークする唯一のものであり、中間ノードはマーキング値を読み取り、パケットバッチを識別するだけです。各バッチ内のパケットの数をカウントし、パスに沿った異なるネットワークノードで測定された値を比較することにより、任意の2つのノード間の任意のバッチで発生したパケット損失を測定することができます。各バッチは、パスに沿ったすべてのネットワークノードによって認識可能な測定可能なエンティティを表します。
Both fixed number of packets and a fixed timer can be used by the source node to create packet batches. But, as also explained in [RFC9341], the timer-based batches are preferable because they are more deterministic than the counter-based batches. Unlike the timer-based batches, there is no definitive rule for counter-based batches, which are not considered in [RFC9341]. Using a fixed timer for the switching offers better control over the method; indeed, the length of the batches can be chosen large enough to simplify the collection and the comparison of the measures taken by different network nodes. In the implementation, the counters can be sent out by each node to the controller that is responsible for the calculation. It is also possible to exchange this information by using other on-path techniques, but this is out of scope for this document.
固定数のパケット数と固定タイマーの両方をソースノードで使用して、パケットバッチを作成できます。しかし、[RFC9341]で説明されているように、タイマーベースのバッチは、カウンターベースのバッチよりも決定的であるため、好ましいです。タイマーベースのバッチとは異なり、[RFC9341]では考慮されていないカウンターベースのバッチには決定的なルールはありません。スイッチングに固定タイマーを使用すると、メソッドをより適切に制御できます。実際、バッチの長さは、さまざまなネットワークノードで取られたメジャーのコレクションと比較を簡素化するのに十分な大きさに選択できます。実装では、各ノードで計算を担当するコントローラーにカウンターを送信できます。他のパス上のテクニックを使用してこの情報を交換することもできますが、これはこのドキュメントの範囲外です。
Packets with different L values may get swapped at batch boundaries, and in this case, it is required that each marked packet can be assigned to the right batch by each router. It is important to mention that for the application of this method, there are two elements to consider: the clock error between network nodes and the network delay. These can create offsets between the batches and out-of-order packets. The mathematical formula on timing aspects, explained in Section 5 of [RFC9341], must be satisfied, and it takes into consideration the different causes of reordering such as clock error and network delay. The assumption is to define the available counting interval to get stable counters and to avoid these issues. Specifically, if the effects of network delay are ignored, the condition to implement the methodology is that the clocks in different nodes MUST be synchronized to the same clock reference with an accuracy of +/- B/2 time units, where B is the fixed time duration of the batch. In this way, each marked packet can be assigned to the right batch by each node. Usually, the counters can be taken in the middle of the batch period to be sure to read quiescent counters. In a few words, this implies that the length of the batches MUST be chosen large enough so that the method is not affected by those factors. The length of the batches can be determined based on the specific deployment scenario.
異なるL値を持つパケットはバッチ境界に交換される場合があり、この場合、各ルーターによってマークされた各パケットを右バッチに割り当てることが必要です。この方法を適用するためには、考慮すべき2つの要素があることに言及することが重要です。ネットワークノードとネットワークの遅延の間のクロックエラーです。これらは、バッチとオーダーアウトオブオーダーパケットの間にオフセットを作成できます。[RFC9341]のセクション5で説明されているタイミングの側面に関する数学的式は満たされなければならず、クロックエラーやネットワーク遅延などの並べ替えのさまざまな原因を考慮します。仮定は、利用可能なカウント間隔を定義して、安定したカウンターを取得し、これらの問題を回避することです。具体的には、ネットワーク遅延の効果が無視されている場合、方法論を実装する条件は、異なるノードのクロックを /-b /2時間単位の精度で同じクロック参照に同期する必要があるということです。ここで、Bは固定時間です。バッチの期間。このようにして、各ノードでマークされた各パケットを右バッチに割り当てることができます。通常、カウンターをバッチ期間の途中で取得して、静止カウンターを必ず読み取ることができます。いくつかの言葉で、これは、方法がこれらの要因の影響を受けないように、バッチの長さを十分に大きく選択する必要があることを意味します。バッチの長さは、特定の展開シナリオに基づいて決定できます。
L bit=1 ----------+ +-----------+ +----------
| | | |
L bit=0 +-----------+ +-----------+
Batch n ... Batch 3 Batch 2 Batch 1
<---------> <---------> <---------> <---------> <--------->
Traffic Flow
===========================================================>
L bit ...1111111111 0000000000 11111111111 00000000000 111111111...
===========================================================>
Figure 1: Packet Loss Measurement and Single-Marking Methodology Using L Bit
図1：lビットを使用したパケット損失測定とシングルマーク方法論
It is worth mentioning that the duration of the batches is considered stable over time in the previous figure. In theory, it is possible to change the length of batches over time and among different flows for more flexibility. But, in practice, it could complicate the correlation of the information.
前の図では、バッチの持続時間が時間の経過とともに安定していると見なされることに言及する価値があります。理論的には、より柔軟性のために、時間の経過とともに、さまざまなフローの間でバッチの長さを変更することができます。しかし、実際には、情報の相関関係を複雑にする可能性があります。
The same principle used to measure packet loss can also be applied to one-way delay measurement. Delay metrics MAY be calculated using the following two possibilities:
パケットの損失を測定するために使用されるのと同じ原則は、一元配置遅延測定にも適用できます。遅延メトリックは、次の2つの可能性を使用して計算できます。
Single-Marking Methodology:
シングルマーク方法論：
This approach uses only the L bit to calculate both packet loss and delay. In this case, the D flag MUST be set to zero on transmit and ignored by the monitoring points. The alternation of the values of the L bit can be used as a time reference to calculate the delay. Whenever the L bit changes and a new batch starts, a network node can store the timestamp of the first packet of the new batch; that timestamp can be compared with the timestamp of the first packet of the same batch on a second node to compute packet delay. But, this measurement is accurate only if no packet loss occurs and if there is no packet reordering at the edges of the batches. A different approach can also be considered, and it is based on the concept of the mean delay. The mean delay for each batch is calculated by considering the average arrival time of the packets for the relative batch. There are limitations also in this case indeed; each node needs to collect all the timestamps and calculate the average timestamp for each batch. In addition, the information is limited to a mean value.
このアプローチでは、Lビットのみを使用して、パケットの損失と遅延の両方を計算します。この場合、Dフラグは送信時にゼロに設定し、監視ポイントによって無視する必要があります。Lビットの値の代替は、遅延を計算するための時間参照として使用できます。Lビットが変更され、新しいバッチが起動するたびに、ネットワークノードは新しいバッチの最初のパケットのタイムスタンプを保存できます。そのタイムスタンプは、2番目のノードの同じバッチの最初のパケットのタイムスタンプと比較して、パケット遅延を計算することができます。ただし、この測定は、パケットの損失が発生しない場合と、バッチの端にパケットの並べ替えがない場合にのみ正確です。別のアプローチを考慮することもでき、平均遅延の概念に基づいています。各バッチの平均遅延は、相対バッチのパケットの平均到着時間を考慮することにより計算されます。この場合、実際にも制限があります。各ノードは、すべてのタイムスタンプを収集し、各バッチの平均タイムスタンプを計算する必要があります。さらに、情報は平均値に制限されています。
Double-Marking Methodology:
ダブルマーキング方法論：
This approach is more complete and uses the L bit only to calculate packet loss, and the D bit (Delay flag) is fully dedicated to delay measurements. The idea is to use the first marking with the L bit to create the alternate flow and, within the batches identified by the L bit, a second marking is used to select the packets for measuring delay. The D bit creates a new set of marked packets that are fully identified over the network so that a network node can store the timestamps of these packets; these timestamps can be compared with the timestamps of the same packets on a second node to compute packet delay values for each packet. The most efficient and robust mode is to select a single double-marked packet for each batch; in this way, there is no time gap to consider between the double-marked packets to avoid their reorder. Regarding the rule for the selection of the packet to be double-marked, the same considerations in Section 5.1 also apply here, and the double-marked packet can be chosen within the available counting interval that is not affected by factors such as clock errors. If a double-marked packet is lost, the delay measurement for the considered batch is simply discarded, but this is not a big problem because it is easy to recognize the problematic batch and skip the measurement just for that one. So in order to have more information about the delay and to overcome out-of-order issues, this method is preferred.
このアプローチはより完全であり、Lビットを使用してパケットの損失を計算し、Dビット（遅延フラグ）は測定の遅延に完全に専念しています。アイデアは、Lビットで最初のマーキングを使用して代替フローを作成することです。また、Lビットで識別されたバッチ内で、2番目のマーキングを使用して、遅延を測定するためにパケットを選択します。Dビットは、ネットワークノードがこれらのパケットのタイムスタンプを保存できるように、ネットワーク上で完全に識別されるマークされたパケットの新しいセットを作成します。これらのタイムスタンプは、各パケットのパケット遅延値を計算するために、2番目のノードの同じパケットのタイムスタンプと比較できます。最も効率的で堅牢なモードは、バッチごとに単一の二重マークパケットを選択することです。このようにして、再注文を避けるために、二重マークされたパケット間で考慮すべき時間の隙間はありません。パケットの選択のルールについては、二重マーク化することについては、セクション5.1の同じ考慮事項もここに適用され、二重マークされたパケットは、クロックエラーなどの要因の影響を受けない利用可能なカウント間隔内で選択できます。二重マークのパケットが失われた場合、考慮されたバッチの遅延測定は単純に破棄されますが、問題のあるバッチを認識して測定をスキップするのは簡単であるため、これは大きな問題ではありません。したがって、遅延に関するより多くの情報を持ち、オーダーの外れの問題を克服するためには、この方法が推奨されます。
In summary, the approach with Double Marking is better than the approach with Single Marking. Moreover, the two approaches provide slightly different pieces of information, and the data consumer can combine them to have a more robust data set.
要約すると、二重マーキングを使用したアプローチは、単一マーキングを使用したアプローチよりも優れています。さらに、2つのアプローチはわずかに異なる情報を提供し、データ消費者はそれらを組み合わせて、より堅牢なデータセットを持つことができます。
Similar to what is said in Section 5.1 for the packet counters, in the implementation, the timestamps can be sent out to the controller that is responsible for the calculation or exchanged using other on-path techniques. But, this is out of scope for this document.
パケットカウンターのセクション5.1で言われていることと同様に、実装では、タイムスタンプをコントローラーに送信することができます。これは、計算を担当したり、他のパスでの手法を使用して交換したりできます。しかし、これはこのドキュメントの範囲外です。
L bit=1 ----------+ +-----------+ +----------
| | | |
L bit=0 +-----------+ +-----------+
D bit=1 + + + + +
| | | | |
D bit=0 ------+----------+----------+----------+------------+-----
Traffic Flow
===========================================================>
L bit ...1111111111 0000000000 11111111111 00000000000 111111111...
D bit ...0000010000 0000010000 00000100000 00001000000 000001000...
===========================================================>
Figure 2: Double-Marking Methodology Using L Bit and D Bit
図2：LビットとDビットを使用した二重マーキング方法論
Likewise, to packet delay measurement (both for Single Marking and Double Marking), the method can also be used to measure the inter-arrival jitter.
同様に、パケット遅延測定（単一マーキングと二重マーキングの両方）には、この方法を使用して到着間ジッターを測定することもできます。
The Flow Monitoring Identification (FlowMonID) identifies the flow to be measured and is required for some general reasons:
フロー監視識別（FlowMonid）は、測定するフローを識別し、いくつかの一般的な理由で必要です。
* First, it helps to reduce the per-node configuration. Otherwise, each node needs to configure an access control list (ACL) for each of the monitored flows. Moreover, using a flow identifier allows a flexible granularity for the flow definition; indeed, it can be used together with other identifiers (e.g., 5-tuple).
* まず、ノードごとの構成を減らすのに役立ちます。それ以外の場合、各ノードは、監視されている各フローに対してアクセス制御リスト（ACL）を構成する必要があります。さらに、フロー識別子を使用すると、フロー定義に柔軟な粒度が得られます。実際、それは他の識別子（5タプルなど）と一緒に使用できます。
* Second, it simplifies the counters handling. Hardware processing of flow tuples (and ACL matching) is challenging and often incurs into performance issues, especially in tunnel interfaces.
* 第二に、カウンターの処理を簡素化します。フロータプル（およびACLマッチング）のハードウェア処理は挑戦的であり、特にトンネルインターフェイスでパフォーマンスの問題に巻き込まれます。
* Third, it eases the data export encapsulation and correlation for the collectors.
* 第三に、コレクターのデータエクスポートと相関関係を容易にします。
The FlowMonID MUST only be used as a monitored flow identifier in order to determine a monitored flow within the measurement domain. This entails not only an easy identification but improved correlation as well.
Flowmonidは、測定ドメイン内の監視対象の流れを決定するために、監視されたフロー識別子としてのみ使用する必要があります。これには、簡単な識別だけでなく、相関も改善されます。
The FlowMonID allocation procedure can be stateful or stateless. In case of a stateful approach, it is required that the FlowMonID historic information can be stored and tracked in order to assign unique values within the domain. This may imply a complex procedure, and it is considered out of scope for this document. The stateless approach is described hereinafter where FlowMonID values are pseudo-randomly generated.
Flowmonid割り当て手順は、ステートフルまたはステートレスにすることができます。ステートフルなアプローチの場合、フローモニドの歴史的な情報を保存および追跡して、ドメイン内に一意の値を割り当てる必要があります。これは複雑な手順を意味する可能性があり、このドキュメントの範囲外と見なされます。ステートレスアプローチについては、フローモニド値が擬似ランダムに生成される場所で説明されています。
The value of 20 bits has been selected for the FlowMonID since it is a good compromise and implies a low rate of ambiguous FlowMonIDs that can be considered acceptable in most of the applications. The disambiguation issue can be solved by tagging the pseudo-randomly generated FlowMonID with additional flow information. In particular, it is RECOMMENDED to consider the 3-tuple FlowMonID, source, and destination addresses:
20ビットの値は、より良い妥協であり、ほとんどのアプリケーションで受け入れられると考えられる曖昧なフローモニドの低い速度を意味するため、20ビットの値が選択されています。曖昧性の問題は、擬似ランダムに生成されたフローモニドに追加のフロー情報をタグ付けすることで解決できます。特に、3タプルのフローモニド、ソース、および宛先アドレスを考慮することをお勧めします。
* If the 20-bit FlowMonID is set independently and pseudo-randomly in a distributed way, there is a chance of collision. Indeed, by using the well-known birthday problem in probability theory, if the 20-bit FlowMonID is set independently and pseudo-randomly without any additional input entropy, there is a 50% chance of collision for 1206 flows. So, for more entropy, FlowMonID is combined with source and destination addresses. Since there is a 1% chance of collision for 145 flows, it is possible to monitor 145 concurrent flows per host pairs with a 1% chance of collision.
* 20ビットのflowmonidが独立して設定され、分布した方法で擬似ランダムリーが設定されている場合、衝突の可能性があります。確かに、確率理論でよく知られている誕生日の問題を使用することにより、20ビットのフローモニドが独立して設定され、追加の入力エントロピーなしで擬似ランダムリーが設定されている場合、1206フローの衝突の可能性が50％あります。そのため、より多くのエントロピーのために、FlowMonidはソースアドレスと宛先アドレスと組み合わされます。145のフローの衝突の可能性が1％あるため、ホストペアごとに145の同時フローを監視し、衝突の可能性が1％監視することができます。
* If the 20-bit FlowMonID is set pseudo-randomly but in a centralized way, the controller can instruct the nodes properly in order to guarantee the uniqueness of the FlowMonID. With 20 bits, the number of combinations is 1048576, and the controller should ensure that all the FlowMonID values are used without any collision. Therefore, by considering source and destination addresses together with the FlowMonID, it is possible to monitor 1048576 concurrent flows per host pairs.
* 20ビットのflowmonidが擬似ランダムに設定されているが、集中型の方法で設定されている場合、コントローラーはフローモニドの一意性を保証するためにノードを適切に指示できます。20ビットでは、組み合わせの数は1048576であり、コントローラーは衝突せずにすべてのフローモニド値を使用することを保証する必要があります。したがって、FlowMonidと一緒にソースおよび宛先アドレスを考慮することにより、ホストペアごとに1048576同時フローを監視することができます。
A consistent approach MUST be used in the Alternate-Marking deployment to avoid the mixture of different ways of identifying. All the nodes along the path and involved in the measurement SHOULD use the same mode for identification. As mentioned, it is RECOMMENDED to use the FlowMonID for identification purposes in combination with source and destination addresses to identify a flow. By considering source and destination addresses together with the FlowMonID, it is possible to monitor 145 concurrent flows per host pairs with a 1% chance of collision in case of pseudo-randomly generated FlowMonID, or 1048576 concurrent flows per host pairs in case of a centralized controller. It is worth mentioning that the solution with the centralized control allows finer granularity and therefore adds even more flexibility to the flow identification.
さまざまな識別方法の混合を避けるために、代替マーク展開で一貫したアプローチを使用する必要があります。パスに沿ったすべてのノードと測定に関係するすべてのノードは、識別に同じモードを使用する必要があります。前述のように、FlowMonidをソースアドレスと宛先アドレスと組み合わせて識別目的で使用して、フローを識別することをお勧めします。FlowMonidと一緒にソースおよび宛先アドレスを考慮することにより、擬似ランダムに生成されたフローモニドの場合、衝突の可能性が1％、または集中型のペアごとの1048576の同時フローで衝突の可能性を伴うホストペアごとに145の同時フローを監視することができます。コントローラ。集中制御を備えたソリューションはより細かい粒度を可能にし、したがってフロー識別によりさらに柔軟性を追加することに言及する価値があります。
The FlowMonID field is set at the source node, which is the ingress point of the measurement domain, and can be set in two ways:
flowmonidフィールドは、測定ドメインの侵入点であるソースノードに設定されており、2つの方法で設定できます。
* It can be algorithmically generated by the source node, which can set it pseudo-randomly with some chance of collision. This approach cannot guarantee the uniqueness of FlowMonID since conflicts and collisions are possible. But, considering the recommendation to use FlowMonID with source and destination addresses, the conflict probability is reduced due to the FlowMonID space available for each endpoint pair (i.e., 145 flows with 1% chance of collision).
* ソースノードによってアルゴリズム的に生成される可能性があります。これにより、衝突の可能性があるため、擬似ランダムに設定できます。このアプローチは、競合や衝突が可能であるため、フローモニドの独自性を保証することはできません。しかし、ソースアドレスと宛先アドレスを使用してFlowMonidを使用することを推奨することを考慮すると、各エンドポイントペアで利用可能なFlow MonyIDスペース（つまり、145が衝突の可能性が1％のフロー）のために競合確率が低下します。
* It can be assigned by the central controller. Since the controller knows the network topology, it can allocate the value properly to avoid or minimize ambiguity and guarantee the uniqueness. In this regard, the controller can verify that there is no ambiguity between different pseudo-randomly generated FlowMonIDs on the same path. The conflict probability is really small given that the FlowMonID is coupled with source and destination addresses, and up to 1048576 flows can be monitored for each endpoint pair. When all values in the FlowMonID space are consumed, the centralized controller can keep track and reassign the values that are not used any more by old flows.
* 中央コントローラーによって割り当てることができます。コントローラーはネットワークトポロジを知っているため、曖昧さを回避または最小限に抑え、一意性を保証するために、値を適切に割り当てることができます。この点で、コントローラーは、同じパス上の異なる擬似ランダムに生成されたフローモニドの間に曖昧さがないことを確認できます。Flow MonyIDがソースおよび宛先アドレスと結合されており、各エンドポイントペアの最大1048576フローを監視できることを考えると、競合の確率は非常に少ないです。Flowmonidスペース内のすべての値が消費されると、集中コントローラーは追跡を維持し、古いフローでは使用されていない値を再割り当てできます。
If the FlowMonID is set by the source node, the intermediate nodes can read the FlowMonIDs from the packets in flight and act accordingly. If the FlowMonID is set by the controller, both possibilities are feasible for the intermediate nodes, which can learn by reading the packets or can be instructed by the controller.
FlowMonidがソースノードによって設定されている場合、中間ノードは飛行中のパケットからFlowMonidsを読み取り、それに応じて動作します。FlowMonidがコントローラーによって設定されている場合、両方の可能性は中間ノードで実行可能であり、パケットを読み取ることで学習したり、コントローラーによって指示されたりすることができます。
The FlowMonID setting by the source node may seem faster and more scalable than the FlowMonID setting by the controller. But, it is supposed that the controller does not slow the process since it can enable the Alternate-Marking Method and its parameters (like FlowMonID) together with the flow instantiation, as further described in [BGP-SR-POLICY-IFIT] and [PCEP-IFIT].
ソースノードによるフローモニド設定は、コントローラーによるフローモニド設定よりも高速でスケーラブルに見える場合があります。ただし、[BGP-SR-Policy-IPIT]と[[Flowインスタンス化]と[フローインスタンス化とともに、代替マーキング方法とそのパラメーター（FlowMonidなど）を有効にできるため、コントローラーはプロセスを遅らせないと考えられています。pcep-ifit]。
The Alternate-Marking Method can be extended to any kind of multipoint-to-multipoint paths. [RFC9341] only applies to point-to-point unicast flows, while the Clustered Alternate-Marking Method, introduced in [RFC9342], is valid for multipoint-to-multipoint unicast flows, anycast, and ECMP flows.
代替マルキング方法は、あらゆる種類のマルチポイントからマルチポイントのパスに拡張できます。[RFC9341]はポイントツーポイントユニキャストフローにのみ適用されますが、[RFC9342]で導入されたクラスター化された代替マークメソッドは、マルプポイントツーマルチポイントユニキャストフロー、Anycast、およびECMPフローに有効です。
[RFC9342] describes the network clustering approach, which allows a flexible and optimized performance measurement. A cluster is the smallest identifiable non-trivial subnetwork of the entire network graph that still satisfies the condition that the number of packets that goes in is the same number that goes out. With network clustering, it is possible to partition the network into clusters at different levels in order to perform the needed degree of detail.
[RFC9342]は、柔軟で最適化されたパフォーマンス測定を可能にするネットワーククラスタリングアプローチを説明しています。クラスターは、ネットワークグラフ全体の最も小さい識別可能な非自明なサブネットワークであり、入力されるパケットの数が外出するのと同じ条件をまだ満たしています。ネットワーククラスタリングを使用すると、必要な詳細を実行するために、ネットワークをさまざまなレベルのクラスターに分割することができます。
For Multipoint Alternate Marking, FlowMonID can identify in general a multipoint-to-multipoint flow and not only a point-to-point flow.
マルチポイントの代替マーキングの場合、FlowMonidは一般に、マルチポイントからマルチポイントの流れを識別でき、ポイントツーポイントフローだけでなく、
The nodes enabled to perform performance monitoring collect the value of the packet counters and timestamps. There are several alternatives to implement data collection and calculation, but this is not specified in this document.
パフォーマンス監視を実行できるノードは、パケットカウンターとタイムスタンプの値を収集します。データ収集と計算を実装するためのいくつかの選択肢がありますが、これはこのドキュメントでは指定されていません。
There are documents on the control plane mechanisms of Alternate Marking, e.g., [BGP-SR-POLICY-IFIT] and [PCEP-IFIT].
[BGP-SR-Policy-Ifit]および[PCEP-IFIT]など、代替マーキングの制御面メカニズムに関するドキュメントがあります。
This document aims to apply a method to the performance measurements that does not directly affect Internet security nor applications that run on the Internet. However, implementation of this method must be mindful of security and privacy concerns.
このドキュメントは、インターネットセキュリティやインターネット上で実行されるアプリケーションに直接影響しないパフォーマンス測定にメソッドを適用することを目的としています。ただし、この方法の実装は、セキュリティとプライバシーの懸念に留意する必要があります。
There are two types of security concerns: potential harm caused by the measurements and potential harm to the measurements.
セキュリティの懸念には、測定によって引き起こされる潜在的な害と測定への潜在的な害の2つのタイプがあります。
Harm caused by the measurement:
測定によって引き起こされる害：
Alternate Marking implies the insertion of an Options Header to the IPv6 packets by the source node, but this must be performed in a way that does not alter the quality of service experienced by the packets and that preserves stability and performance of routers doing the measurements. As already discussed in Section 4, the design of the AltMark Option has been chosen with throughput in mind, such that it can be implemented without affecting the user experience.
代替マーキングとは、ソースノードによるIPv6パケットへのオプションヘッダーの挿入を意味しますが、これはパケットが経験するサービスの品質を変更せず、測定を行うルーターの安定性とパフォーマンスを保持する方法で実行する必要があります。セクション4ですでに説明したように、Altmarkオプションの設計は、ユーザーエクスペリエンスに影響を与えることなく実装できるように、スループットを念頭に置いて選択されています。
Harm to the measurement:
測定への害：
Alternate-Marking measurements could be harmed by routers altering the fields of the AltMark Option (e.g., marking of the packets or FlowMonID) or by a malicious attacker adding the AltMark Option to the packets in order to consume the resources of network devices and entities involved. As described above, the source node is the only one that writes the Options Header while the intermediate nodes and destination node only read it without modifying the Options Header. But, for example, an on-path attacker can modify the flags, whether intentionally or accidentally, or deliberately insert an Option to the packet flow or delete the Option from the packet flow. The consequent effect could be to give the appearance of loss or delay or to invalidate the measurement by modifying Option identifiers, such as FlowMonID. The malicious implication can be to cause actions from the network administrator where an intervention is not necessary or to hide real issues in the network. Since the measurement itself may be affected by network nodes intentionally altering the bits of the AltMark Option or injecting Options Headers as a means for Denial of Service (DoS), the Alternate Marking MUST be applied in the context of a controlled domain, where the network nodes are locally administered and this type of attack can be avoided. For this reason, the implementation of the method is not done on the end node if it is not fully managed and does not belong to the controlled domain. Packets generated outside the controlled domain may consume router resources by maliciously using the Hop-by-Hop Option, but this can be mitigated by filtering these packets at the controlled domain boundary. This can be done because if the end node does not belong to the controlled domain, it is not supposed to add the AltMark Hop-by-Hop Option, and it can be easily recognized.
代替マーク測定は、Altmarkオプションのフィールドを変更するルーター（パケットやFlowmonidのマーキングなど）を変更するか、関連するネットワークデバイスとエンティティのリソースを消費するためにPacketsにAltmarkオプションを追加する悪意のある攻撃者によって害を受ける可能性があります。。上記のように、ソースノードはオプションヘッダーを書き込む唯一のものですが、中間ノードと宛先ノードはオプションヘッダーを変更せずにのみ読み取ります。ただし、たとえば、パス上の攻撃者は、意図的であろうと偶然であろうと、パケットフローにオプションを故意に挿入するか、パケットフローからオプションを削除するかどうかにかかわらず、フラグを変更できます。結果としての効果は、FlowMonidなどのオプション識別子を変更することにより、損失または遅延の外観を与えること、または測定を無効にすることです。悪意のある意味は、介入が必要ない場合、ネットワーク管理者からアクションを引き起こしたり、ネットワーク内の実際の問題を隠すことです。測定自体は、Altmarkオプションのビットを意図的に変更するネットワークノードの影響を受ける可能性があるため、サービスの拒否（DOS）の手段としてオプションヘッダーを注入することは、ネットワークが制御されたドメインのコンテキストで適用する必要があります。ノードはローカルで管理されており、このタイプの攻撃は回避できます。このため、メソッドの実装は、完全に管理されておらず、制御ドメインに属していない場合、エンドノードで行われません。制御されたドメインの外側で生成されたパケットは、ホップバイホップオプションを悪意を持って使用してルーターリソースを消費する場合がありますが、これは制御されたドメイン境界でこれらのパケットをフィルタリングすることで軽減できます。これは、エンドノードが制御ドメインに属していない場合、Altmark Hop-by-Hopオプションを追加することになっていないため、簡単に認識できるためです。
An attacker that does not belong to the controlled domain can maliciously send packets with the AltMark Option. But, if Alternate Marking is not supported in the controlled domain, no problem happens because the AltMark Option is treated as any other unrecognized Option and will not be considered by the nodes since they are not configured to deal with it; so, the only effect is the increased packet size (by 48 bits). If Alternate Marking is supported in the controlled domain, it is necessary to keep the measurements from being affected, and external packets with the AltMark Option MUST be filtered. As any other Hop-by-Hop Options or Destination Options, it is possible to filter AltMark Options entering or leaving the domain, e.g., by using ACL extensions for filtering.
制御されたドメインに属さない攻撃者は、Altmarkオプションでパケットを悪意を持って送信できます。ただし、制御ドメインで代替マーキングがサポートされていない場合、Altmarkオプションは他の認識されていないオプションとして扱われ、ノードが処理するように構成されていないため、ノードによって考慮されないため、問題は発生しません。したがって、唯一の効果は、パケットサイズの増加（48ビット）です。制御されたドメインで代替マーキングがサポートされている場合、測定値が影響を受けないようにする必要があり、Altmarkオプションを使用した外部パケットをフィルタリングする必要があります。他のホップバイホップオプションや宛先オプションと同様に、ACL拡張子をフィルタリングに使用することにより、ドメインを入力または離れるAltMarkオプションをフィルタリングすることができます。
The flow identifier (FlowMonID), together with the two marking bits (L and D), comprises the AltMark Option. As explained in Section 5.3, there is a chance of collision if the FlowMonID is set pseudo-randomly, but there is a solution for this issue. In general, this may not be a problem, and a low rate of ambiguous FlowMonIDs can be acceptable since this does not cause significant harm to the operators or their clients, and this harm may not justify the complications of avoiding it. But, for large scale measurements, a big number of flows could be monitored and the probability of a collision is higher; thus, the disambiguation of the FlowMonID field can be considered.
フロー識別子（FlowMonid）と2つのマーキングビット（LおよびD）とともに、AltMarkオプションが含まれます。セクション5.3で説明したように、Flowmonidが擬似ランダムリーに設定されている場合、衝突の可能性がありますが、この問題の解決策があります。一般に、これは問題ではない可能性があり、これはオペレーターやそのクライアントに大きな害を及ぼさないため、曖昧なフローモニドの割合が受け入れられる可能性があり、この害はそれを避けることの合併症を正当化しないかもしれません。しかし、大規模な測定では、多数のフローを監視することができ、衝突の確率が高くなります。したがって、flowmonidフィールドの乱用を考慮することができます。
The privacy concerns also need to be analyzed even if the method only relies on information contained in the Options Header without any release of user data. Indeed, from a confidentiality perspective, although the AltMark Option does not contain user data, the metadata can be used for network reconnaissance to compromise the privacy of users by allowing attackers to collect information about network performance and network paths. The AltMark Option contains two kinds of metadata: the marking bits (L and D) and the flow identifier (FlowMonID).
また、ユーザーデータをリリースせずにオプションヘッダーに含まれる情報のみに依存している場合でも、プライバシーの懸念も分析する必要があります。実際、機密性の観点からは、Altmarkオプションにはユーザーデータが含まれていませんが、メタデータはネットワーク偵察に使用して、攻撃者がネットワークパフォーマンスとネットワークパスに関する情報を収集できるようにすることでユーザーのプライバシーを妥協できます。Altmarkオプションには、2種類のメタデータが含まれています。マーキングビット（LおよびD）とフロー識別子（FlowMonid）です。
* The marking bits are the small information that is exchanged between the network nodes. Therefore, due to this intrinsic characteristic, network reconnaissance through passive eavesdropping on data plane traffic is difficult. Indeed, an attacker cannot gain information about network performance from a single monitoring point. The only way for an attacker can be to eavesdrop on multiple monitoring points at the same time, because they have to do the same kind of calculation and aggregation as Alternate Marking requires.
* マーキングビットは、ネットワークノード間で交換される小さな情報です。したがって、この固有の特性により、データプレーントラフィックの受動的な盗聴によるネットワーク偵察は困難です。実際、攻撃者は単一の監視ポイントからネットワークパフォーマンスに関する情報を取得することはできません。攻撃者にとっての唯一の方法は、代替マーキングが必要とするのと同じ種類の計算と集約を行う必要があるため、複数の監視ポイントを同時に盗聴することです。
* The FlowMonID field is used in the AltMark Option as the identifier of the monitored flow. It represents more sensitive information for network reconnaissance and may allow a flow tracking type of attack because an attacker could collect information about network paths.
* Flowmonidフィールドは、監視されたフローの識別子としてAltmarkオプションで使用されます。ネットワーク偵察のためのより機密情報を表しており、攻撃者がネットワークパスに関する情報を収集できるため、フロー追跡型の攻撃を可能にする可能性があります。
Furthermore, in a pervasive surveillance attack, the information that can be derived over time is more. But, as further described hereinafter, the application of the Alternate Marking to a controlled domain helps to mitigate all the above aspects of privacy concerns.
さらに、広範な監視攻撃では、時間の経過とともに導き出すことができる情報がもっとあります。しかし、以下にさらに説明したように、制御されたドメインへの代替マーキングの適用は、プライバシーの懸念のすべての側面を軽減するのに役立ちます。
At the management plane, attacks can be set up by misconfiguring or by maliciously configuring the AltMark Option. Thus, AltMark Option configuration MUST be secured in a way that authenticates authorized users and verifies the integrity of configuration procedures. Solutions to ensure the integrity of the AltMark Option are outside the scope of this document. Also, attacks on the reporting of the statistics between the monitoring points and the network management system (e.g., centralized controller) can interfere with the proper functioning of the system. Hence, the channels used to report back flow statistics MUST be secured.
管理面では、誤って構成するか、Altmarkオプションを悪意を持って構成することにより、攻撃を設定できます。したがって、Altmarkオプション構成は、認可されたユーザーを認証し、構成手順の整合性を検証する方法で保護する必要があります。Altmarkオプションの整合性を確保するためのソリューションは、このドキュメントの範囲外です。また、監視ポイントとネットワーク管理システムの間の統計の報告に対する攻撃（たとえば、集中コントローラー）は、システムの適切な機能を妨げる可能性があります。したがって、バックフロー統計を報告するために使用されるチャネルを確保する必要があります。
As stated above, the precondition for the application of the Alternate Marking is that it MUST be applied in specific controlled domains, thus confining the potential attack vectors within the network domain. A limited administrative domain provides the network administrator with the means to select, monitor, and control the access to the network, making it a trusted domain. In this regard, it is expected to enforce policies at the domain boundaries to filter both external packets with the AltMark Option entering the domain and internal packets with the AltMark Option leaving the domain. Therefore, the trusted domain is unlikely subject to the hijacking of packets since packets with AltMark Option are processed and used only within the controlled domain.
上記のように、代替マーキングの適用の前提条件は、特定の制御ドメインに適用する必要があるため、ネットワークドメイン内の潜在的な攻撃ベクトルを閉じ込めることです。限られた管理ドメインは、ネットワーク管理者にネットワークへのアクセスを選択、監視、制御する手段を提供し、信頼できるドメインにします。この点で、ドメイン境界でポリシーを実施して、Altmarkオプションを使用して両方の外部パケットをフィルタリングし、ドメインを出てドメインを離れるAltmarkオプションを使用して内部パケットをフィルタリングすることが期待されています。したがって、Altmarkオプションを備えたパケットが処理され、制御ドメイン内でのみ使用されるため、信頼できるドメインはパケットのハイジャックの対象となる可能性は低いです。
As stated, the application to a controlled domain ensures control over the packets entering and leaving the domain, but despite that, leakages may happen for different reasons such as a failure or a fault. In this case, nodes outside the domain are expected to ignore packets with the AltMark Option since they are not configured to handle it and should not process it.
述べたように、制御されたドメインへのアプリケーションは、ドメインに入ると離れるパケットを制御することを保証しますが、それにもかかわらず、障害や障害などのさまざまな理由で漏れが発生する可能性があります。この場合、ドメインの外側のノードは、それを処理するように構成されておらず、処理すべきではないため、Altmarkオプションでパケットを無視することが期待されます。
Additionally, note that the AltMark Option is carried by the Options Header and it will have some impact on the packet sizes for the monitored flow and on the path MTU since some packets might exceed the MTU. However, the relative small size (48 bits in total) of these Options Headers and its application to a controlled domain help to mitigate the problem.
さらに、Altmarkオプションはオプションヘッダーによって運ばれ、一部のパケットがMTUを超える可能性があるため、監視されたフローのパケットサイズとPATH MTUにある程度の影響があることに注意してください。ただし、これらのオプションヘッダーの比較的小さいサイズ（合計48ビット）と制御されたドメインへのアプリケーションは、問題を軽減するのに役立ちます。
It is worth mentioning that the security concerns may change based on the specific deployment scenario and related threat analysis, which can lead to specific security solutions that are beyond the scope of this document. As an example, the AltMark Option can be used as a Hop-by-Hop or Destination Option and, in case of a Destination Option, multiple administrative domains may be traversed by the AltMark Option that is not confined to a single administrative domain. In this case, the user, who is aware of the kind of risks, may still want to use Alternate Marking for telemetry and test purposes, but the controlled domain must be composed by more than one administrative domain. To this end, the inter-domain links need to be secured (e.g., by IPsec or VPNs) in order to avoid external threats and realize the whole controlled domain.
セキュリティの懸念は、特定の展開シナリオと関連する脅威分析に基づいて変更される可能性があり、このドキュメントの範囲を超えた特定のセキュリティソリューションにつながる可能性があることに言及する価値があります。例として、Altmarkオプションはホップバイホップまたは宛先オプションとして使用できます。また、宛先オプションの場合、単一の管理ドメインに限定されないAltMarkオプションによって複数の管理ドメインが横断される場合があります。この場合、リスクの種類を認識しているユーザーは、テレメトリーとテストの目的で代替マーキングを使用したい場合がありますが、制御されたドメインは複数の管理ドメインで構成される必要があります。この目的のために、外部の脅威を回避し、制御されたドメイン全体を実現するために、ドメイン間リンクを保護する必要があります（たとえば、IPSECまたはVPNによって）。
It might be theoretically possible to modulate the marking or the other fields of the AltMark Option to serve as a covert channel to be used by an on-path observer. This may affect both the data and management plane, but, here too, the application to a controlled domain helps to reduce the effects.
マークまたはAltmarkオプションの他のフィールドを調整することが理論的に可能である可能性があります。これはデータと管理プレーンの両方に影響する可能性がありますが、ここでも制御されたドメインへのアプリケーションは、効果を減らすのに役立ちます。
The Alternate-Marking application described in this document relies on a time synchronization protocol. Thus, by attacking the time protocol, an attacker can potentially compromise the integrity of the measurement. A detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC7384]. Network Time Security (NTS), described in [RFC8915], is a mechanism that can be employed. Also, the time, which is distributed to the network nodes through the time protocol, is centrally taken from an external accurate time source such as an atomic clock or a GPS clock. By attacking the time source, it is possible to compromise the integrity of the measurement as well. There are security measures that can be taken to mitigate the GPS spoofing attacks, and a network administrator should certainly employ solutions to secure the network domain.
このドキュメントで説明されている代替マーキングアプリケーションは、時間同期プロトコルに依存しています。したがって、TIMEプロトコルを攻撃することにより、攻撃者は測定の完全性を潜在的に損なう可能性があります。時間プロトコルに対する脅威とそれらを緩和する方法に関する詳細な議論は、[RFC7384]に示されています。[RFC8915]に記載されているネットワークタイムセキュリティ（NTS）は、使用できるメカニズムです。また、時間プロトコルを介してネットワークノードに分散される時間は、原子時計やGPSクロックなどの外部の正確な時間源から中央に採取されます。時間源を攻撃することにより、測定の完全性も妥協することができます。GPSスプーフィング攻撃を軽減するために実行できるセキュリティ対策があり、ネットワーク管理者は確実にネットワークドメインを保護するためのソリューションを使用する必要があります。
IANA has allocated the Option Type in the "Destination Options and Hop-by-Hop Options" subregistry of the "Internet Protocol Version 6 (IPv6) Parameters" registry (<https://www.iana.org/assignments/ ipv6-parameters/>) as follows:
IANAは、「インターネットプロトコルバージョン6（IPv6）パラメーター」レジストリ（<https://www.iana.org/assignments/ ipv6-parametersの「宛先オプションとホップバイホップオプション」にオプションタイプを割り当てました。/>）次のように：
+===========+===================+=============+===========+
| Hex Value | Binary Value | Description | Reference |
+===========+=====+=====+=======+=============+===========+
| | act | chg | rest | | |
+===========+=====+=====+=======+=============+===========+
| 0x12 | 00 | 0 | 10010 | AltMark | RFC 9343 |
+-----------+-----+-----+-------+-------------+-----------+
Table 1: Destination Options and Hop-by-Hop Options Registry
表1：宛先オプションとホップバイホップオプションレジストリ
[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>.
[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>.
[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>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
[BGP-SR-POLICY-IFIT]
Qin, F., Yuan, H., Yang, S., Zhou, T., and G. Fioccola,
"BGP SR Policy Extensions to Enable IFIT", Work in
Progress, Internet-Draft, draft-ietf-idr-sr-policy-ifit-
05, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-ifit-05>.
[HBH-OPTIONS-PROCESSING]
Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-04, 21 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-04>.
[PCEP-IFIT]
Yuan, H., Wang, X., Yang, P., Li, W., and G. Fioccola,
"Path Computation Element Communication Protocol (PCEP)
Extensions to Enable IFIT", Work in Progress, Internet-
Draft, draft-ietf-pce-pcep-ifit-01, 3 August 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-ifit-01>.
[PROC-HBH-OPT-HEADER]
Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra,
"Operational Issues with Processing of the Hop-by-Hop
Options Header", Work in Progress, Internet-Draft, draft-
ietf-v6ops-hbh-02, 21 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
hbh-02>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[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>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[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>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
[SRv6-AMM] Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing
Header encapsulation for Alternate Marking Method", Work
in Progress, Internet-Draft, draft-fz-spring-srv6-alt-
mark-03, 5 August 2022,
<https://datatracker.ietf.org/doc/html/draft-fz-spring-
srv6-alt-mark-03>.
The authors would like to thank Bob Hinden, Ole Troan, Martin Duke, Lars Eggert, Roman Danyliw, Alvaro Retana, Eric Vyncke, Warren Kumari, Benjamin Kaduk, Stewart Bryant, C. A. Wood, Yoshifumi Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky, and Ron Bonica for their valuable comments and suggestions.
著者は、ボブ・ヒンデン、オレ・トローン、マーティン・デューク、ラース・エガート、ロマン・ダニリウ、アルバロ・レタナ、エリック・ヴィンケ、ウォーレン・クマリ、ベンジャミン・カドゥク、スチュワート・ブライアント、C。A。ウッド、ヨシフミ・ニシダ、トム・ハーバート、ステファノ・プリンス、、グレッグ・ミルスキーとロン・ボニカの貴重なコメントと提案について。
Giuseppe Fioccola
Huawei
Riesstrasse, 25
80992 Munich
Germany
Email: giuseppe.fioccola@huawei.com
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: zhoutianran@huawei.com
Mauro Cociglio
Telecom Italia
Email: mauro.cociglio@outlook.com
Fengwei Qin
China Mobile
32 Xuanwumenxi Ave.
Beijing
100032
China
Email: qinfengwei@chinamobile.com
Ran Pang
China Unicom
9 Shouti South Rd.
Beijing
100089
China
Email: pangran@chinaunicom.cn