Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 9790 Juniper Networks
Updates: 4928 S. Bryant
Category: Standards Track University of Surrey 5GIC
ISSN: 2070-1721 M. Bocci
Nokia
G. Mirsky, Ed.
Ericsson
L. Andersson
J. Dong
Huawei Technologies
July 2025
This document creates a new IANA registry (called the "Post-Stack First Nibble" registry) for the first nibble (4-bit field) immediately following an MPLS label stack. Furthermore, this document presents some requirements for registering new values and making the processing of MPLS packets easier and more robust.
このドキュメントは、MPLSラベルスタックの直後に最初のニブル（4ビットフィールド）の新しいIANAレジストリ（「ポストスタックファーストニブル」レジストリ）を作成します。さらに、このドキュメントでは、新しい値を登録し、MPLSパケットの処理をより簡単かつ堅牢にするためのいくつかの要件を提示します。
The relationship between the IANA "Post-Stack First Nibble" registry and the "IP Version Numbers" registry (RFC 2780) is described in this document.
IANAの「ポストスタックファーストナブル」レジストリと「IPバージョン番号」レジストリ（RFC 2780）の関係については、このドキュメントで説明しています。
This document updates RFC 4928 by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS.
このドキュメントは、MPLSでカプセル化されたパケットのタイプを識別するためのヒューリスティックな方法を非難することにより、RFC 4928を更新します。
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/rfc9790.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9790で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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. Requirements Language
1.2. Definitions
1.3. Abbreviations
1.4. Reference Figures
2. Rationale
2.1. Why Look at the First Nibble
2.1.1. ECMP Load Balancing
2.2. Updates to RFC 4928
2.3. Why Create a Registry
2.4. IP Version Numbers Versus Post-Stack First Nibble Values
2.5. Next Step to More Deterministic Load Balancing in MPLS
Networks
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgements
Authors' Addresses
An MPLS packet consists of a label stack, an optional Post-Stack Header (PSH), and an optional embedded packet (in that order). Examples of PSHs include existing headers such as control words [RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296] and the like, as well as new types of PSH being discussed by the MPLS Working Group. However, in the data plane, there are very few clues regarding the PSH and no clue as to the type of embedded packet; this information is communicated via other means, such as the routing protocols that signal the labels in the stack. Nonetheless, in order to better handle an MPLS packet in the data plane, it is common practice for network equipment to "guess" the type of embedded packet. Such equipment may also need to process the PSH. Both of these require parsing the data after the label stack. To do this, the "first nibble" (the top four bits of the first octet following the label stack) is often used. Although some existing network devices may use such a method, it needs to be stressed that the correct interpretation of the Post-stack First Nibble (PFN) in a PSH can be made only in the context established through the control or management plane with the Label Stack Entry (LSE) or group of LSEs in the preceding label stack that characterizes the type of the PSH. Any attempt to rely on the value in any other context is unreliable. Because the PFN value should not be used to deduce the type of PSH by itself and the space of PFN values is limited, the reuse of PFN values is encouraged when possible.
MPLSパケットは、ラベルスタック、オプションのポストスタックヘッダー（PSH）、およびオプションの埋め込みパケット（その順序で）で構成されています。PSHSの例には、コントロールワード[RFC4385]、BIER（ビットインデックス明示的複製）ヘッダー[RFC8296]などの既存のヘッダー、およびMPLSワーキンググループが議論する新しいタイプのPSHが含まれます。ただし、データプレーンでは、PSHに関する手がかりがほとんどなく、組み込みパケットの種類に関する手がかりはありません。この情報は、スタック内のラベルを通知するルーティングプロトコルなど、他の手段を介して伝達されます。それにもかかわらず、データプレーンのMPLSパケットをより適切に処理するために、ネットワーク機器が組み込みパケットのタイプを「推測」することが一般的な慣行です。このような機器は、PSHを処理する必要がある場合もあります。これらは両方とも、ラベルスタックの後にデータを解析する必要があります。これを行うには、「最初のニブル」（ラベルスタックに続く最初のオクテットの上位4ビット）がよく使用されます。一部の既存のネットワークデバイスはそのような方法を使用する場合がありますが、PSHのポストスタックファーストニブル（PFN）の正しい解釈は、PSHのタイプを特徴とする前述のラベルスタックのLSEのグループまたはLSEのグループを使用して、コントロールまたは管理プレーンを通じて確立されたコンテキストでのみ作成できることを強調する必要があります。他のコンテキストで価値に依存しようとする試みは信頼できません。PFN値を使用してPSHのタイプを単独で推定するために使用しないでください。PFN値の空間は限られているため、可能な場合はPFN値の再利用が奨励されます。
The semantics and usage of the first nibble are not well documented, nor are the assignments of values. This document serves four purposes:
最初のニブルのセマンティクスと使用は、十分に文書化されておらず、値の割り当てでもありません。このドキュメントは4つの目的を果たします。
* To document the values already in use.
* すでに使用されている値を文書化する。
* To provide a mechanism to document future assignments through the creation of a new IANA "Post-Stack First Nibble" registry and describe the relationship between it and the IANA "IP Version Numbers" registry [RFC2780].
* 新しいIANAの「ポストスタックファーストニブル」レジストリの作成を通じて将来の割り当てを文書化するメカニズムを提供し、ITとINAの「IPバージョン番号」レジストリ[RFC2780]との関係を説明します。
* Provide a method for tracking usage by requiring more detailed documentation.
* より詳細なドキュメントを必要とすることにより、使用を追跡する方法を提供します。
* To stress that any MPLS packet not carrying plain IPv4 or IPv6 packets contains a PSH. This also applies to packets of any new version of IP (see Section 2.4).
* プレーンIPv4またはIPv6パケットにはPSHが含まれていないMPLSパケットには、PSHが含まれていることを強調します。これは、IPの新しいバージョンのパケットにも適用されます（セクション2.4を参照）。
Section 2.1.1 of this document includes an analysis of load-balancing techniques; based on this, Section 2.1.1.1 introduces a requirement that deprecates the use of the heuristic method for identifying the type of packet encapsulated in MPLS and recommends using a dedicated label value for load balancing. The intent is for legacy routers to continue operating as they have, with no new problems introduced as a result of this document. However, new implementations that follow this document enable more robust network operation.
このドキュメントのセクション2.1.1には、負荷分散技術の分析が含まれています。これに基づいて、セクション2.1.1.1では、MPLSでカプセル化されたパケットのタイプを識別するためのヒューリスティック方法の使用を非推奨する要件を紹介し、負荷分散に専用のラベル値を使用することをお勧めします。目的は、レガシールーターがこの文書の結果として導入された新しい問題はありません。ただし、このドキュメントに従う新しい実装により、より堅牢なネットワーク操作が可能になります。
Furthermore, this document updates [RFC4928] by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS. This document clearly states that the type of encapsulated packet cannot be determined based on the PFN alone.
さらに、このドキュメントは、MPLSでカプセル化されたパケットのタイプを識別するためのヒューリスティックな方法を非難することにより、[RFC4928]を更新します。このドキュメントは、カプセル化されたパケットのタイプをPFNのみに基づいて決定できないことを明確に示しています。
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] で説明されているように解釈されます。
Deprecation:
非難：
Regardless of how the deprecation is understood in other IETF documents, the interpretation in this document is that if a practice has been deprecated, that practice should not be included in new implementations or deployed in new deployments.
他のIETFドキュメントで非推奨がどのように理解されるかに関係なく、このドキュメントの解釈は、実践が非推奨されている場合、その慣行を新しい実装に含めるか、新しい展開に展開すべきではないということです。
Embedded Packet:
埋め込みパケット：
A packet that follows immediately after the MPLS label stack and an optional PSH. The embedded packet could be an IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762] or EVPN [RFC7432]), or some other type of Layer 2 frame [RFC4446].
MPLSラベルスタックとオプションのPSHの直後に続くパケット。埋め込まれたパケットは、IPv4またはIPv6パケット、イーサネットパケット（仮想プライベートLANサービス（VPLS）[RFC4761] [RFC4762]またはEVPN [RFC7432]）、または他のタイプのレイヤー2フレーム[RFC4446]である可能性があります。
Label Stack:
ラベルスタック：
A label stack is represented as a consecutive sequence of "label stack entries" (four-octet fields) after the Layer 2 header but before any network layer header. The last label stack entry of a label stack has its Bottom of Stack bit set.
ラベルスタックは、レイヤー2ヘッダーの後では、ネットワークレイヤーヘッダーの前に「ラベルスタックエントリ」（4オクテットフィールド）の連続シーケンスとして表されます。ラベルスタックの最後のラベルスタックエントリには、スタックビットの下部が設定されています。
MPLS Packet:
MPLSパケット：
A packet whose Layer 2 header declares the type to be MPLS. For example, the Ethertype is 0x8847 or 0x8848 for Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.
レイヤー2ヘッダーがタイプをMPLSであると宣言するパケット。たとえば、EtherTypeはイーサネットの場合は0x8847または0x8848であり、PPPのプロトコルフィールドは0x0281または0x0283です。
MPLS Payload:
MPLSペイロード：
All data after the label stack and any optional PSHs. It is possible that more than one type of PSH may be present in a packet, and some PSH specifications might allow multiple PSHs of the same type. The presence rules for multiple PSHs are a matter for the documents that define those PSHs, e.g., [MNA-PS-HDR].
ラベルスタックとオプションのPSHの後のすべてのデータ。パケットに複数のタイプのPSHが存在する可能性があり、一部のPSH仕様では同じタイプの複数のPSHが許可される可能性があります。複数のPSHの存在ルールは、これらのPSHを定義するドキュメントの問題です。たとえば[MNA-PS-HDR]。
Post-stack First Nibble (PFN):
ポストスタックファーストニブル（PFN）：
The most significant four bits of the first octet following the label stack.
ラベルスタックに続く最初のオクテットの最も重要な4ビット。
Post-Stack Header (PSH):
ポストスタックヘッダー（PSH）：
A field containing information that may be of interest to the egress Label Switching Router (LSR) or transit LSRs. Examples include a control word [RFC4385] [RFC8964] or an associated channel header [RFC4385] [RFC5586] [RFC9546].
出口ラベルスイッチングルーター（LSR）またはトランジットLSRに興味がある可能性のある情報を含むフィールド。例には、コントロールワード[RFC4385] [RFC8964]または関連するチャネルヘッダー[RFC4385] [RFC5586] [RFC9546]が含まれます。
BIER:
ビア：
Bit Index Explicit Replication
ビットインデックス明示的な複製
FAT:
脂肪：
Flow-Aware Transport
流れの認識輸送
LSE:
LSE：
Label Stack Entry
ラベルスタックエントリ
LSR:
LSR：
Label Switching Router
ラベルスイッチングルーター
MNA:
MNA：
MPLS Network Action
MPLSネットワークアクション
PFN:
PFN：
Post-stack First Nibble
ポストスタックファーストニブル
PSH:
PSH：
Post-Stack Header
ポストスタックヘッダー
PW:
PW：
Pseudowire
擬似ワイヤー
SPL:
SPL：
Special-Purpose Label
特別な目的ラベル
Figure 1 echoes the format of MPLS packets as defined in [RFC3032] where TC indicates the Traffic Class field [RFC5462] that replaced the EXP (Experimental Use) field, S is the Bottom of Stack flag, and TTL is the Time to Live field.
図1は、[RFC3032]で定義されているMPLSパケットの形式をエコーします。ここで、TCはEXP（実験的使用）フィールドを置き換えるトラフィッククラスフィールド[RFC5462]を示し、Sはスタックフラグの底であり、TTLはライブフィールドまでの時間です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
X | Layer 2 Header | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
TC S TTL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
Y | Label-1 | TC |0| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label-2 | TC |0| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | TC |0| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label-n | TC |1| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
Figure 1: Example of an MPLS Packet with Label Stack
図1：ラベルスタックを備えたMPLSパケットの例
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
A | (PFN) | IP header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end of IP packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
B | (PFN) | non-IP packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end of non-IP packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
C | (PFN) | PSH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end of PSH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| embedded packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
Figure 2: Examples of an MPLS Packet Payload With and Without a Preceding Post-Stack Header
図2：前のポストスタックヘッダーの有無にかかわらず、MPLSパケットペイロードの例
Figure 1 shows an MPLS packet with a Layer 2 header X and a label stack Y ending with Label-n. Figure 2 displays three examples of an MPLS payload:
図1は、レイヤー2ヘッダーXを備えたMPLSパケットと、label-nで終わるラベルスタックyを示しています。図2は、MPLSペイロードの3つの例を示しています。
Example A:
例A：
The first payload is a bare IP packet, i.e., no PSH. The PFN in this case overlaps with the IP version number.
最初のペイロードは、裸のIPパケット、つまりPSHなしです。この場合のPFNは、IPバージョン番号と重複しています。
Example B:
例B：
The next payload is a bare non-IP packet; again, no PSH. The PFN here is the first nibble of the payload, whatever it happens to be.
次のペイロードは、むき出しの非IPパケットです。繰り返しますが、PSHはありません。ここのPFNは、それが何であれ、ペイロードの最初のニブルです。
Example C:
例C：
This example is an MPLS Payload that follows a PSH. Here, the embedded packet could be IP or non-IP.
この例は、PSHに続くMPLSペイロードです。ここでは、埋め込まれたパケットはIPまたは非IPである可能性があります。
Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or [X Y C].
したがって、完全なMPLSパケットは[x y a]、[x y b]、または[x y c]で構成されます。
An MPLS packet can contain one of many types of embedded packets. Three common types are:
MPLSパケットには、多くの種類の埋め込みパケットの1つを含めることができます。3つの一般的なタイプは次のとおりです。
1. An IPv4 packet (whose IP header has version number 4).
1. IPv4パケット（IPヘッダーにはバージョン番号4があります）。
2. An IPv6 packet (whose IP header has version number 6).
2. IPv6パケット（IPヘッダーにはバージョン番号6があります）。
3. A Layer 2 Ethernet frame (i.e., not including the Preamble or the Start frame delimiter), starting with the destination Media Access Control (MAC) address.
3. レイヤー2イーサネットフレーム（つまり、プリアンブルまたは開始フレームデリミッターを含まない）、宛先メディアアクセスコントロール（MAC）アドレスから始めます。
Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible. Indeed, at some points in time, packets of the Point-to-Point Protocol, Frame Relay, and Asynchronous Transfer Mode were reasonably common and may become so again.
他の多くのパケットタイプが可能です。原則として、レイヤー2埋め込みパケットは許容されます。実際、ある時点で、ポイントツーポイントプロトコル、フレームリレー、および非同期転送モードのパケットが合理的に一般的であり、再びそのようになる可能性があります。
In addition, there may be a PSH ahead of the embedded packet. The value of PFN is considered to ensure that the PSH can be correctly parsed.
さらに、埋め込まれたパケットの前にPSHがある場合があります。PFNの値は、PSHを正しく解析できるようにするために考慮されます。
There are four common ways to load balance an MPLS packet:
MPLSパケットのバランスバランスを読むには、4つの一般的な方法があります。
1. Use the top label alone.
1. トップレーベルだけを使用してください。
2. Use all of the non-SPLs [RFC7274] in the stack. This is better than using the top label alone.
2. スタック内のすべての非SPLS [RFC7274]を使用します。これは、トップレーベルだけを使用するよりも優れています。
3. "Divine" the type of embedded packet and use fields from the guessed header. The ramifications of using this load-balancing technique are discussed in detail in Section 2.1.1.1. This way is better than the two ways above.
3. 埋め込まれたパケットのタイプであり、推測されたヘッダーからフィールドを使用します。この負荷分散手法を使用することの影響については、セクション2.1.1.1で詳しく説明します。この方法は、上記の2つの方法よりも優れています。
4. Use either an Entropy Label [RFC6790] or a Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see Section 2.1.1.1). This is the best way.
4. エントロピーラベル[RFC6790]またはフローアウェアトランスポート（脂肪）の擬似ワイヤラベル[RFC6391]のいずれかを使用します（セクション2.1.1.1を参照）。これが最良の方法です。
Load balancing based on just the top label means that all packets with that top label will go the same way, which is far from ideal. Load balancing based on the entire label stack (not including SPLs) is better, but it may still be uneven. However, if the embedded packet is an IP packet, then the combination of (<source IP address>, <dest IP address>, <transport protocol>, <source port>, and <dest port>) from the IP header of the embedded packet forms an excellent basis for load balancing. This is what is typically used for load balancing IP packets.
トップレーベルのみに基づいてロードバランスは、そのトップラベルのあるすべてのパケットが同じように進むことを意味します。これは理想とはほど遠いものです。ラベルスタック全体（SPLを含まない）に基づいたロードバランスの方が優れていますが、それでも不均一である可能性があります。ただし、組み込みパケットがIPパケットである場合、埋め込みパケットのIPヘッダーからの（<ソースIPアドレス>、<Dest IPアドレス>、<Transport Protocol>、<Source Potocol>、<Dest Port>）の組み合わせは、負荷バランスの優れた基盤を形成します。これは、通常、ロードバランスIPパケットに使用されるものです。
An MPLS packet doesn't, however, carry a payload type identifier. There is a simple (but risky) heuristic that is commonly used to guess the type of the embedded packet. The first nibble of an IP header, i.e., the four most significant bits of the first octet, contains the IP version number. That, in turn, indicates where to find the relevant fields for load balancing. The heuristic goes roughly as described in Section 2.1.1.1.
ただし、MPLSパケットは、ペイロードタイプ識別子を持ちません。埋め込みパケットのタイプを推測するために一般的に使用される単純な（しかし危険な）ヒューリスティックがあります。IPヘッダーの最初のニブル、つまり、最初のオクテットの4つの最も重要なビットには、IPバージョン番号が含まれています。これは、荷重バランスに関連するフィールドをどこで見つけるかを示します。ヒューリスティックは、セクション2.1.1.1で説明されているように大まかに進みます。
1. If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet, and find the relevant fields for load balancing on that basis.
1. PFNが0x4（0100B）の場合、ペイロードをIPv4パケットとして扱い、それに基づいてロードバランスに関連するフィールドを見つけます。
2. If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet, and find the relevant fields for load balancing on that basis.
2. PFNが0x6（0110B）の場合、ペイロードをIPv6パケットとして扱い、それに基づいてロードバランスに関連するフィールドを見つけます。
3. If the PFN is anything else, the MPLS payload is not an IP packet; fall back to load balancing using the label stack.
3. PFNが他のものである場合、MPLSペイロードはIPパケットではありません。ラベルスタックを使用してロードバランスに戻ります。
This heuristic has been implemented in many (legacy) routers and performs well in the case of example A in Figure 2. However, this heuristic can work very badly for the non-IP packet as shown in example B in Figure 2. For example, if payload B is an Ethernet frame, then the PFN is the first nibble of the Organizationally Unique Identifier of the destination MAC address, which can be 0x4 or 0x6. This would lead to the packet being treated as an IPv4 or IPv6 packet such that data at the offsets of specific relevant fields would be used as input to the load-balancing heuristic, resulting in unpredictable load balancing. This behavior can happen to other types of non-IP payloads as well.
このヒューリスティックは、多くの（レガシー）ルーターで実装されており、図2の例Aの場合によく機能します。ただし、このヒューリスティックは、図2の例Bに示すように、非IPパケットのために非常にひどく機能します。たとえば、ペイロードBがイーサネットフレームの場合、PFNは組織的にユニークな識別子の最初のニブルです。これにより、パケットがIPv4またはIPv6パケットとして扱われるようになり、特定の関連フィールドのオフセットでのデータが荷重バランスヒューリスティックへの入力として使用され、予測不可能な負荷分散が生じます。この動作は、他のタイプの非IPペイロードにも発生する可能性があります。
That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire control word [RFC4385], a Deterministic Networking (DetNet) control word [RFC8964], a Network Service Header (NSH) [RFC8300], or a BIER header [RFC8296]) where the PFN is not 0x4 or 0x6; this explicitly prevents forwarding engines from confusing the MPLS payload with an IP packet. [RFC8469] recommends the use of a control word when the embedded packet is an Ethernet frame. [RFC8469] was published at the request of the operator community and the IEEE Registration Authority Committee as a result of operational difficulties with pseudowires that did not contain the control word.
次に、PSH（例えば、擬似ワイヤーコントロールワード[RFC4385]、決定論的ネットワーキング（デットネット）コントロールワード[RFC8964]、ネットワークサービスヘッダー（NSH）[RFC8300]、またはBIERヘッダー[RFC8296]）を挿入するという考えにつながりました。これにより、エンジンがMPLSペイロードをIPパケットと混同することを明示的に防止します。[RFC8469]埋め込まれたパケットがイーサネットフレームである場合、コントロールワードの使用を推奨します。[RFC8469]は、コントロールワードを含んでいない擬似ワイヤの運用上の困難の結果として、オペレーターコミュニティとIEEE登録局委員会の要求に応じて公開されました。
Where load balancing of MPLS packets is desired, it is RECOMMENDED that the load-balancing mechanism use the value of a dedicated label, for example, either an Entropy Label [RFC6790] or a FAT Pseudowire Label [RFC6391]. Furthermore, the heuristic of guessing the type of the embedded packet, as discussed above, SHOULD NOT be used.
MPLSパケットの負荷分散が望ましい場合、荷重バランスメカニズムは、エントロピーラベル[RFC6790]または脂肪の擬似ワイヤラベル[RFC6391]など、専用ラベルの値を使用することをお勧めします。さらに、上記で説明したように、埋め込まれたパケットのタイプを推測するヒューリスティックは使用しないでください。
A consequence of the heuristic approach is that while legacy routers may look for a PFN of 0x4 [RFC0791] or 0x6 [RFC8200], no legacy router will look for any other PFN for load-balancing purposes, regardless of what future IP version numbers will be. This means that the values 0x4 and 0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6 packets, but no other PFN values will be used to identify IP packets.
ヒューリスティックなアプローチの結果は、レガシールーターが0x4 [RFC0791]または0x6 [RFC8200]のPFNを探すことができますが、将来のIPバージョンの数字が何であるかに関係なく、Legacy Routerが負荷分散のために他のPFNを探すことはありません。これは、値0x4と0x6がIPv4およびIPv6パケットを識別するために（時には誤って）使用されることを意味しますが、IPパケットを識別するために他のPFN値は使用されません。
This document creates a new registry for all 16 possible values (see Section 3).
このドキュメントでは、16の可能な値すべてに新しいレジストリを作成します（セクション3を参照）。
The text in RFC 4928 [RFC4928] concerning the first nibble after the MPLS label stack has been updated by this document, and the heuristic for snooping this nibble has been deprecated. Section 3 of [RFC4928] is updated as follows:
MPLSラベルスタックの後の最初のニブルに関するRFC 4928 [RFC4928]のテキストは、このドキュメントによって更新され、このニブルをスヌーピングするためのヒューリスティックは非推奨されています。[RFC4928]のセクション3は次のように更新されます。
OLD TEXT:
古いテキスト：
It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. This will ensure that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version(s) of IP.
ただし、アプリケーションは、最初のニブル値を0x0および0x1に制限する順序のパケット配信に依存することが必要です。これにより、一部の将来のルーティング機器がIPの将来のバージョンで同様のスヌーピングを行う場合、トラフィックフローが影響を受けることが保証されます。
NEW TEXT:
新しいテキスト：
Network equipment MUST use a PSH (Post-Stack Header) with a PFN (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all cases where the MPLS payload is neither an IPv6 nor an IPv4 packet.
ネットワーク機器は、MPLSペイロードがIPv6でもIPv4パケットでもない場合、PFN（ポストスタックファーストニブル）値を備えたPFS（ポストスタックファーストニブル）値を備えたPSH（ポストスタックの最初のニブル）値を使用する必要があります。
The following requirement (discussed is Section 2.1.1.1) replaces paragraph 4 in Section 3 of [RFC4928] as follows:
次の要件（セクション2.1.1.1）は、[RFC4928]のセクション3のパラグラフ4を次のように置き換えます。
OLD TEXT:
古いテキスト：
This behavior implies that if in the future an IP version is defined with a version number of 0x0 or 0x1, then equipment complying with this BCP would be unable to look past one or more MPLS headers, and loadsplit traffic from a single LSP across multiple paths based on a hash of specific fields in the IPv0 or IPv1 headers. That is, IP traffic employing these version numbers would be safe from disturbances caused by inappropriate loadsplitting, but would also not be able to get the performance benefits.
この動作は、将来、IPバージョンが0x0または0x1のバージョン番号で定義されている場合、このBCPに準拠した機器が過去の1つ以上のMPLSヘッダーを見ることができず、IPV0またはIPv1ヘッダーの特定のフィールドのハッシュに基づいて複数のパスに基づく単一のパスにわたって単一のパスからのロードスプリットトラフィックを見ることができないことを意味します。つまり、これらのバージョン番号を採用するIPトラフィックは、不適切なロードスプリッティングによって引き起こされる障害から安全ですが、パフォーマンスの利点も得ることができません。
NEW TEXT:
新しいテキスト：
The practice of deducing the payload type based on the PFN value is deprecated to avoid inaccurate load balancing. This MUST NOT be part of new implementations or deployments. This also means that concerns about load balancing for future IP versions with a version number of 0x0 or 0x1 are no longer relevant.
PFN値に基づいてペイロードタイプを推測する慣行は、不正確な負荷分散を避けるために非推奨されます。これは、新しい実装や展開の一部であってはなりません。これはまた、0x0または0x1のバージョン番号を持つ将来のIPバージョンのロードバランスに関する懸念がもはや関連しないことを意味します。
Furthermore, the following text is appended to Section 1.1 of [RFC4928]:
さらに、次のテキストは[RFC4928]のセクション1.1に追加されます。
NEW TEXT:
新しいテキスト：
PSH:
PSH:
Post-Stack Header
ポストスタックヘッダー
PFN:
PFN:
Post-stack First Nibble
ポストスタックファーストニブル
The framework for MPLS Network Actions (MNAs) is described in [RFC9789] and is an enhancement to the MPLS architecture. The use of Post-Stack Data (PSD) to encode the MNA indicators and ancillary data (described in Section 3.6 of [RFC9789]) might place data in the PFN, which could conflict with other uses of that nibble. This issue is described in Section 3.6.1 of [RFC9789] and is further illustrated by the PFN value of 0x0, which has two different formats depending on whether the PSH is a pseudowire control word or a DetNet control word; disambiguation requires the context of the service label.
MPLSネットワークアクション（MNA）のフレームワークは[RFC9789]で説明されており、MPLSアーキテクチャの強化です。MNAインジケーターと補助データ（[RFC9789]のセクション3.6で説明）をエンコードするためにポストスタックデータ（PSD）を使用すると、PFNにデータが配置され、そのニブルの他の使用と競合する可能性があります。この問題は[RFC9789]のセクション3.6.1で説明されており、PFN値0x0でさらに説明されています。PSHは、PSHが擬似コントロールワードかデットネットコントロールワードであるかに応じて2つの異なる形式を持っています。曖昧性を除去するには、サービスラベルのコンテキストが必要です。
With a registry, PSHs become easier to identify and parse. In addition, they do not need a means outside the data plane to interpret them correctly, and their semantics and usage are documented and referenced in the registry.
レジストリを使用すると、PSHは識別して解析しやすくなります。さらに、データプレーンの外側に正しく解釈する手段は必要ありません。また、それらのセマンティクスと使用量は文書化され、レジストリで参照されます。
The use of the PFN stemmed from the desire to heuristically identify IP packets for load-balancing purposes. It was then discovered that non-IP packets, misidentified as IP when the heuristic failed, were being badly load balanced, leading to the scenario described in [RFC4928]. This situation may confuse some as to the relationship between the "Post-Stack First Nibble" registry and the "IP Version Numbers" registry. These registries are quite different:
PFNの使用は、ロードバランスの目的でIPパケットをヒューリスト的に識別したいという欲求に由来しています。その後、ヒューリスティックが失敗したときにIPと誤認されていない非IPパケットが、[RFC4928]で説明されているシナリオにつながることがひどく負荷のバランスが取れていることが発見されました。この状況は、「ポストスタックファーストニブル」レジストリと「IPバージョン番号」レジストリとの関係について一部を混同する可能性があります。これらのレジストリはまったく異なります：
1. The explicit purpose of the "IP Version Numbers" registry is to track IP version numbers in an IP header.
1. 「IPバージョン番号」レジストリの明示的な目的は、IPヘッダーのIPバージョン番号を追跡することです。
2. The purpose of the "Post-Stack First Nibble" registry is to track PSH types.
2. 「ポストスタックファーストニブル」レジストリの目的は、PSHタイプを追跡することです。
The only intersection points between the two registries are the values 0x4 and 0x6 (for backward compatibility).
2つのレジストリ間の唯一の交差点は、値0x4と0x6（後方互換性の場合）です。
Network evolution is impossible to control, but it develops over a period of time determined by various factors.
ネットワークの進化は制御することは不可能ですが、さまざまな要因によって決定される一定期間にわたって発生します。
This document discourages further proliferation of the implementations that could lead to undesired effects on data flows. In doing so, it limits the scope of future protocol developments and thus helps to ensure that future network evolution will be smoother.
このドキュメントは、データの流れに望ましくない影響につながる可能性のある実装のさらなる拡散を思いとどまらせます。そうすることで、将来のプロトコル開発の範囲を制限するため、将来のネットワークの進化がよりスムーズになるようにします。
Section 2 of [RFC4385] suggests the use of a PSH solely for the purpose of avoiding IP ECMP treatment of non-IP payloads encapsulated in MPLS. Obsoleting this use of a PSH would assist with the progress toward a simpler, more coherent system of MPLS data encapsulation. (Other uses of a PSH may still be valid.) However, before that can be done, it is important to collect sufficient evidence that there are no marketed or deployed implementations using the heuristic practice to load balance MPLS data flows.
[RFC4385]のセクション2は、MPLSにカプセル化された非IPペイロードのIP ECMP処理を避けるためだけにPSHの使用を示唆しています。このPSHの使用を廃止すると、MPLSデータカプセル化のよりシンプルでよりコヒーレントなシステムへの進捗状況が役立ちます。（PSHの他の使用はまだ有効かもしれません。）しかし、それを行う前に、Heuristic Practiceを使用してMPLSデータフローをロードするために、販売または展開された実装がないという十分な証拠を収集することが重要です。
Therefore, the next steps toward more deterministic load balancing in MPLS networks are to gradually deprecate non-PSH MPLS encapsulations of non-IP data, to cease using heuristic load balancing, and to survey the available and deployed implementations to determine when obsoletion may be achieved.
したがって、MPLSネットワークでのより決定的な負荷分散に向けた次のステップは、非PSHデータの非PSH MPLSカプセルを徐々に非難し、ヒューリスティックロードバランスを使用して停止し、利用可能な実装と展開された実装を調査して、時期が達成される可能性があることです。
Per this document, IANA has created a registry group called "Post-Stack First Nibble" that consists of a single registry called the "Post-Stack First Nibble" registry. The initial contents of the registry are shown in Table 1. The assignment policy is Standards Action [RFC8126]. It is important to note that the same PFN value can be used in more than one protocol. The correct interpretation of the PFN in a PSH can be made only in the context of the LSE or group of LSEs in the preceding label stack that characterizes the type of the PSH and, consequently, the PFN.
このドキュメントに従って、IANAは「ポストスタックファーストニブル」レジストリと呼ばれる単一のレジストリで構成される「ポストスタックファーストニブル」と呼ばれるレジストリグループを作成しました。レジストリの初期内容を表1に示します。割り当てポリシーは標準アクション[RFC8126]です。同じPFN値を複数のプロトコルで使用できることに注意することが重要です。PSHにおけるPFNの正しい解釈は、PSHのタイプ、およびその結果、PFNを特徴付ける前述のラベルスタックのLSEまたはLSEのグループのコンテキストでのみ行うことができます。
+==========+=======+=================================+===========+
| Protocol | Value | Description | Reference |
+==========+=======+=================================+===========+
| DetNet | 0x0 | DetNet Control Word | [RFC8964] |
+----------+-------+---------------------------------+-----------+
| NSH | 0x0 | NSH Base Header, payload | [RFC8300] |
+----------+-------+---------------------------------+-----------+
| PW | 0x0 | PW Control Word | [RFC4385] |
+----------+-------+---------------------------------+-----------+
| DetNet | 0x1 | DetNet Associated Channel | [RFC9546] |
+----------+-------+---------------------------------+-----------+
| MPLS | 0x1 | MPLS Generic Associated Channel | [RFC5586] |
+----------+-------+---------------------------------+-----------+
| PW | 0x1 | PW Associated Channel | [RFC4385] |
+----------+-------+---------------------------------+-----------+
| NSH | 0x2 | NSH Base Header, OAM | [RFC8300] |
+----------+-------+---------------------------------+-----------+
| | 0x3 | Unassigned | |
+----------+-------+---------------------------------+-----------+
| | 0x4 | Reserved | RFC 9790 |
+----------+-------+---------------------------------+-----------+
| BIER | 0x5 | BIER Header | [RFC8296] |
+----------+-------+---------------------------------+-----------+
| | 0x6 | Reserved | RFC 9790 |
+----------+-------+---------------------------------+-----------+
| | 0x7 - | Unassigned | |
| | 0xF | | |
+----------+-------+---------------------------------+-----------+
Table 1: Post-Stack First Nibble Registry
表1：ポストスタックの最初のニブルレジストリ
This document creates a new IANA registry for PFNs and specifies changes to the treatment of packets in the data plane based on the first nibble of data beyond the MPLS label stack. One intent of this is to reduce or eliminate errors in determining whether or not a packet being transported by MPLS is IP. While such errors have primarily caused unbalanced, and thus inefficient, multipathing, they have the potential to cause more severe security problems.
このドキュメントでは、PFNの新しいIANAレジストリを作成し、MPLSラベルスタックを超えたデータの最初のニブルに基づいて、データプレーン内のパケットの処理の変更を指定します。One intent of this is to reduce or eliminate errors in determining whether or not a packet being transported by MPLS is IP.このようなエラーは主に不均衡を引き起こし、したがって非効率的で多量化されていますが、より深刻なセキュリティの問題を引き起こす可能性があります。
For general security considerations involving the MPLS label stack, see [RFC3032].
MPLSラベルスタックを含む一般的なセキュリティに関する考慮事項については、[RFC3032]を参照してください。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<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>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<https://www.rfc-editor.org/info/rfc2780>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, DOI 10.17487/RFC4928, June 2007,
<https://www.rfc-editor.org/info/rfc4928>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network",
RFC 6391, DOI 10.17487/RFC6391, November 2011,
<https://www.rfc-editor.org/info/rfc6391>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[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>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to
Use the Ethernet Control Word", RFC 8469,
DOI 10.17487/RFC8469, November 2018,
<https://www.rfc-editor.org/info/rfc8469>.
[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
S., and J. Korhonen, "Deterministic Networking (DetNet)
Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
2021, <https://www.rfc-editor.org/info/rfc8964>.
[RFC9789] Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions (MNAs) Framework", RFC 9789,
DOI 10.17487/RFC9789, July 2025,
<https://www.rfc-editor.org/info/rfc9789>.
[MNA-PS-HDR]
Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Li,
T., and J. Dong, "Post-Stack MPLS Network Action (MNA)
Solution", Work in Progress, Internet-Draft, draft-ietf-
mpls-mna-ps-hdr-01, 30 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-ps-hdr-01>.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446,
DOI 10.17487/RFC4446, April 2006,
<https://www.rfc-editor.org/info/rfc4446>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014,
<https://www.rfc-editor.org/info/rfc7274>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,
Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet) with the MPLS Data Plane", RFC 9546,
DOI 10.17487/RFC9546, February 2024,
<https://www.rfc-editor.org/info/rfc9546>.
The authors express their appreciation and gratitude to Donald E. Eastlake 3rd for the review, insightful questions, and helpful comments. Also, the authors are grateful to Amanda Baber for helping organize the IANA registry in a clear and concise manner.
著者は、レビュー、洞察に満ちた質問、有用なコメントについて、ドナルドE.イーストレイク3に感謝と感謝を表明します。また、著者は、明確で簡潔な方法でIANAレジストリの整理を支援してくれたAmanda Baberに感謝しています。
Éric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and Gunter Van de Velde provided helpful comments during IESG review.
エリック・ヴィンケ、ジョン・スカダー、ウォーレン・クマリ、マレー・クチェラウィ、およびガンター・ヴァン・デ・ヴェルデは、IESGレビュー中に有益なコメントを提供しました。
The authors would also like to thank Adrian Farrel for his patient and careful shepherding and for helping to finalize the text.
著者はまた、エイドリアン・ファレルの患者と慎重な羊飼いとテキストの最終化を手伝ってくれたことに感謝したいと思います。
Kireeti Kompella
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: kireeti.ietf@gmail.com
Stewart Bryant
University of Surrey 5GIC
Email: sb@stewartbryant.com
Matthew Bocci
Nokia
Email: matthew.bocci@nokia.com
Greg Mirsky (editor)
Ericsson
Email: gregimirsky@gmail.com
Loa Andersson
Huawei Technologies
Email: loa@pi.nu
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: jie.dong@huawei.com