[要約] 要約：RFC 4182は、MPLS Explicit NULLの使用制限を取り除くためのガイドラインです。 目的：MPLSネットワークでのExplicit NULLの柔軟な使用を促進し、ネットワークの効率性と柔軟性を向上させることを目指しています。
Network Working Group E. Rosen
Request for Comments: 4182 Cisco Systems, Inc.
Updates: 3032 September 2005
Category: Standards Track
Removing a Restriction on the use of MPLS Explicit NULL
MPLS明示的なヌルの使用に関する制限を削除する
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.
マルチプロトコルラベルスイッチング（MPLS）用のラベルスタックエンコードは、「IPv4明示ヌル」と呼ばれる予約されたラベル値と、「IPv6明示ヌル」として知られる予約ラベル値を定義します。以前は、これらのラベルは、MPLSラベルスタックの下部で発生した場合にのみ合法でした。この制限は、これらのラベル値がスタック内のどこでも法的に発生するようにするため、この制限が削除されました。
This document updates RFC 3032.
このドキュメントは、RFC 3032を更新します。
Table of Contents
目次
1. Introduction ....................................................2
2. Detail of Change ................................................2
3. Reasons for Change ..............................................3
4. Deployment Considerations .......................................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................5
7. Normative References ............................................5
8. Informative References ..........................................5
RFC 3032 defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL" [RFC3032]. It states that these label values are only legal at the bottom of the MPLS label stack. However, no reason is given for this restriction.
RFC 3032は、「IPv4明示的ヌル」として知られる予約されたラベル値と、「IPv6明示的ヌル」[RFC3032]として知られる予約ラベル値を定義します。これらのラベル値は、MPLSラベルスタックの下部でのみ合法であると述べています。ただし、この制限の理由はありません。
It has turned out that in practice there are some situations in which it is useful to send MPLS packets that have Explicit NULL occur somewhere other than at that bottom of the label stack. While the intended semantics are obvious enough, the fact that such packets are gratuitously declared by RFC 3032 to be illegal has made it difficult to handle these situations in an interoperable manner.
実際には、ラベルスタックのその下部以外の場所に明示的なヌルが発生するMPLSパケットを送信することが有用な状況がいくつかあることが判明しました。意図されたセマンティクスは十分に明らかですが、そのようなパケットがRFC 3032によって違法であると無償で宣言されているという事実により、これらの状況を相互運用可能な方法で処理することが困難になりました。
This document updates RFC 3032 by removing the unnecessary restriction, so that the two aforementioned label values are legal anywhere in the label stack.
このドキュメントは、不必要な制限を削除することによりRFC 3032を更新します。これにより、前述の2つのラベル値がラベルスタックのどこでも合法になります。
RFC 3032 states on page 4:
4ページのRFC 3032州：
There are several reserved label values:
いくつかの予約されたラベル値があります：
i. A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header.
i. 0の値は、「IPv4明示的なヌルラベル」を表します。このラベル値は、ラベルスタックの下部でのみ合法です。これは、ラベルスタックをポップする必要があり、パケットの転送がIPv4ヘッダーに基づいている必要があることを示しています。
iii. A value of 2 represents the "IPv6 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header.
iii。2の値は、「IPv6明示的なヌルラベル」を表します。このラベル値は、ラベルスタックの下部でのみ合法です。これは、ラベルスタックをポップする必要があり、パケットの転送がIPv6ヘッダーに基づいている必要があることを示しています。
Paragraph i is hereby changed to read:
パラグラフIは、これにより読み取りに変更されています。
i. A value of 0 represents the "IPv4 Explicit NULL Label".
i. 0の値は、「IPv4明示的なヌルラベル」を表します。
An IPv4 Explicit NULL at the top of the label stack means that the stack must be popped.
ラベルスタックの上部にあるIPv4の明示的なヌルは、スタックをポップする必要があることを意味します。
If the NULL was not the only label on the stack, this will cause the label beneath it to rise to the top of the stack. The disposition of the packet is based on the label that has now risen to the top.
ヌルがスタック上の唯一のラベルではなかった場合、これにより、その下のラベルがスタックの上部に上昇します。パケットの処分は、現在トップに上昇しているラベルに基づいています。
If, on the other hand, the NULL was the only label on the stack, then the stack is now empty. The resulting packet is treated as an IPv4 packet, and its disposition is based on the IPv4 header.
一方、ヌルがスタック上の唯一のラベルである場合、スタックは空になります。結果のパケットはIPv4パケットとして扱われ、その処分はIPv4ヘッダーに基づいています。
Paragraph iii is hereby changed to read:
パラグラフIIIは、これにより読み取りに変更されます。
iii. A value of 2 represents the "IPv6 Explicit NULL Label".
iii。2の値は、「IPv6明示的なヌルラベル」を表します。
An IPv6 Explicit NULL at the top of the label stack means that the stack must be popped.
ラベルスタックの上部にあるIPv6明示的ヌルは、スタックをポップする必要があることを意味します。
If the NULL was not the only label on the stack, this will cause the label beneath it to rise to the top of the stack. The disposition of the packet is based on the label that has now risen to the top.
ヌルがスタック上の唯一のラベルではなかった場合、これにより、その下のラベルがスタックの上部に上昇します。パケットの処分は、現在トップに上昇しているラベルに基づいています。
If, on the other hand, the NULL was the only label on the stack, then the stack is now empty. The resulting packet is treated as an IPv6 packet, and its disposition is based on the IPv6 header.
一方、ヌルがスタック上の唯一のラベルである場合、スタックは空になります。結果のパケットはIPv6パケットとして扱われ、その処分はIPv6ヘッダーに基づいています。
Restricting Explicit NULL to the bottom of the stack has caused some problems in practice.
明示的なヌルをスタックの下部に制限することで、実際にいくつかの問題が発生しました。
With this restriction in place, one should not distribute, to a particular label distribution peer, a binding of Explicit NULL to a particular Forwarding Equivalence Class (FEC), unless the following condition (call it "Condition L") holds: all MPLS packets received by that peer with an incoming label corresponding to that FEC contain only a single label stack entry. If Explicit NULL is bound to the FEC, but Condition L doesn't hold, the peer is being requested to create illegal packets. None of the MPLS specifications say what the peer is actually supposed to do in this case. This situation is made more troublesome by the facts that, in practice, Condition L rarely holds, and it is not possible, in general, to determine whether it holds or not.
この制限が整っていると、特定のラベル分布ピアに配布してはなりません。次の条件（「条件L」を呼び出す）が保持されない限り、特定の転送等価クラス（FEC）に明示的なヌルを拘束する必要はありません：すべてのMPLSパケットそのピアは、そのFECに対応する着信ラベルで受信して、単一のラベルスタックエントリのみが含まれています。明示的なヌルがFECにバインドされているが、条件Lが保持されない場合、ピアは違法なパケットを作成するように要求されています。MPLS仕様はどれも、この場合、ピアが実際に何をすべきかを言っていません。この状況は、実際には条件がめったに保持されないという事実によってより厄介になり、一般的には、それが保持されるかどうかを判断することは不可能です。
Further, if one is supporting the Pipe Model of RFC 3270 [RFC3270], there are good reasons to create label stacks in which Explicit NULL is at the top of the label stack, but a non-null label is at the bottom.
さらに、RFC 3270 [RFC3270]のパイプモデルをサポートしている場合、明示的なnullがラベルスタックの上部にあるが、非ヌルラベルが下部にあるラベルスタックを作成する正当な理由があります。
RFC 3270 specifies the procedures for MPLS support of Differentiated Services. In particular, it defines a "Pipe Model" in which (quoting from RFC 3270, Section 2.6.2):
RFC 3270差別化されたサービスのMPLSサポートの手順を指定します。特に、「パイプモデル」を定義します（RFC 3270、セクション2.6.2から引用）：
"tunneled packets must convey two meaningful pieces of Diff-Serv information:
「トンネルパケットは、2つの意味のある違い情報を伝える必要があります。
- the Diff-Serv information which is meaningful to intermediate nodes along the LSP span including the LSP Egress (which we refer to as the 'LSP Diff-Serv Information'). This LSP Diff-Serv Information is not meaningful beyond the LSP Egress: Whether Traffic Conditioning at intermediate nodes on the LSP span affects the LSP Diff-Serv information or not, this updated Diff-Serv information is not considered meaningful beyond the LSP Egress and is ignored.
- LSP Egress（「LSP Diff-Serv情報」と呼ばれるLSPスパンに沿った中間ノードにとって意味のあるDiff-Serv情報。このLSP Diff-Serv情報は、LSPの出口を超えて意味がありません。LSPスパンの中間ノードでのトラフィックコンディショニングがLSP Diff-Serv情報に影響するかどうかにかかわらず、この更新されたDiff-Serv情報はLSP Egressを超えて意味があるとは見なされず、無視した。
- the Diff-Serv information which is meaningful beyond the LSP Egress (which we refer to as the 'Tunneled Diff-Serv Information'). This information is to be conveyed by the LSP Ingress to the LSP Egress. This Diff-Serv information is not meaningful to the intermediate nodes on the LSP span."
- LSPの出口を超えて意味のあるdif-serv情報（これは「トンネル違いのdif-serv情報」と呼ばれます）。この情報は、LSPの侵入によってLSP出力に伝えられます。このdiff-serv情報は、LSPスパンの中間ノードにとって意味がありません。」
When the Pipe Model is in use, it is common practice for the LSP Egress to bind Explicit Null to the tunnel's FEC. The intention is that the LSP Diff-Serv information will be carried in the EXP bits of the Explicit Null label stack entry, and the tunneled Diff-Serv information will be carried in whatever is "below" the Explicit Null label stack entry, i.e., in the IP header DS bits or in the EXP bits of the next entry on the MPLS label stack.
パイプモデルが使用されている場合、LSP EgressがトンネルのFECに明示的なヌルを結合することが一般的な慣行です。意図は、LSP Diff-Serv情報が明示的なNullラベルスタックエントリのEXPビットに持ち込まれ、トンネル付きDiff-Serv情報は、明示的なNullラベルスタックエントリ、つまり、「以下」の「以下」で運ばれることです。IPヘッダーDSビットまたはMPLSラベルスタックの次のエントリのEXPビット。
Naturally, this practice causes a problem if the Pipe Model LSP is being used to tunnel MPLS packets (i.e., if Condition L does not hold). With strict adherence to RFCs 3031 and 3036, this practice results in an MPLS packet where Explicit NULL is at the top of the label stack, even though it is not the only entry in the label stack. However, RFC 3032 makes this packet illegal.
当然のことながら、パイプモデルLSPがMPLSパケットのトンネルに使用されている場合（つまり、条件Lが保持されない場合）、このプラクティスは問題を引き起こします。RFCS 3031および3036を厳密に順守すると、この練習により、ラベルスタックの唯一のエントリではありませんが、明示的なnullがラベルスタックの一番上にあるMPLSパケットが得られます。ただし、RFC 3032はこのパケットを違法にしています。
Some implementations simply transmit the illegal packet. Others try to convert it to a legal packet by stripping off the Explicit NULL before transmitting it. However, that breaks the Pipe Model by discarding the LSP Diff-Serv information. It is conceivable that there may be an implementation that drops the illegal packet entirely; this would also break the Pipe Model, as it would lose not only the LSP Diff-Serv information, but the entire packet.
一部の実装は、違法なパケットを単に送信するだけです。他の人は、それを送信する前に明示的なヌルを剥がすことにより、それを法的パケットに変換しようとします。ただし、LSP Diff-Serv情報を破棄することにより、パイプモデルが破損します。違法なパケットを完全にドロップする実装があるかもしれないと考えられます。これは、LSP Diff-Serv情報だけでなく、パケット全体を失うため、パイプモデルも破損します。
Of course the LSP egress is not compelled to bind Explicit NULL to the tunnel's FEC; an ordinary label could be used instead. However, using Explicit NULL enables the egress to determine immediately (i.e., without need for lookup in the Label Information Base) that the further forwarding of the packet is to be determined by whatever is below the label. Avoiding this lookup can have favorable implications on forwarding performance.
もちろん、LSPの出口は、明示的なヌルをトンネルのFECに結合することを余儀なくされていません。代わりに通常のラベルを使用できます。ただし、明示的なnullを使用すると、出口は、パケットのさらなる転送がラベルの下にあるものによって決定されることをすぐに（つまり、ラベル情報ベースの検索を必要とせずに）すぐに決定できます。この検索を避けることは、転送パフォーマンスに好意的な意味を持つ可能性があります。
Removing the restriction that Explicit Null only occur at the bottom of the stack is the simplest way to facilitate the proper operation of the Pipe Model.
明示的なnullがスタックの下部にのみ発生するという制限を削除することは、パイプモデルの適切な動作を容易にする最も簡単な方法です。
Implementations that adhere to this specification will interoperate correctly, and will correctly support the Pipe Model.
この仕様に付着する実装は、正しく相互操作し、パイプモデルを正しくサポートします。
Implementations that do not adhere to this specification may not interoperate. In particular, if a router advertises a binding of Explicit NULL, and if that router has an upstream LDP peer that will not transmit a packet that has multiple label stack entries with Explicit Null at top of the stack, then it will not be possible to use Explicit NULL to support the Pipe Model until the upstream LDP peer is brought into compliance with this specification.
この仕様に従わない実装は、相互運用しない場合があります。特に、ルーターが明示的なヌルのバインディングを宣伝する場合、およびそのルーターに上流のLDPピアがある場合、スタックの上部に明示的なヌルを備えた複数のラベルスタックエントリを持つパケットを送信しない場合、それはできません。明示的なヌルを使用して、上流のLDPピアがこの仕様に準拠するまでパイプモデルをサポートします。
It is possible that there may be a router implementation, preceding this specification, which will discard any received packet with multiple label stack entries and a top label value of Explicit Null. It is advisable to configure any such routers so that they do not advertise any bindings to Explicit Null.
この仕様に先行するルーターの実装が存在する可能性があります。これにより、受信したパケットは、複数のラベルスタックエントリと明示的なNULLのトップレーベル値を備えています。このようなルーターが明示的なnullにバインディングを宣伝しないように構成することをお勧めします。
This document updates RFC 3032 by allowing Explicit NULL to occur at any position in the label stack. This modification does not impose any new security considerations beyond those discussed in RFC 3032.
このドキュメントは、ラベルスタック内の任意の位置で明示的なnullが発生するようにすることにより、RFC 3032を更新します。この変更は、RFC 3032で議論されているもの以外の新しいセキュリティ上の考慮事項を課しません。
Thanks to Rahul Aggarwal, Francois LeFaucheur, Yakov Rekhter, and Dan Tappan for their helpful comments.
Rahul Aggarwal、Francois Lefaucheur、Yakov Rekhter、およびDan Tappanの有益なコメントに感謝します。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
Author's Address
著者の連絡先
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。