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
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).
著作権（C）インターネット協会（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の明示的なNULL」および「IPv6の明示的なNULL」として知られている予約ラベル値として知られている予約ラベル値を定義します。彼らは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の明示的なNULL」および「IPv6の明示的なNULL」[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.
それは実際にはどこか他のラベルスタックの最下部に比べて発生明示的なNULLを持つ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.
前述の2つのラベル値がラベルスタックで法的どこにでもあるように、不必要な制限を除去することにより、この文書を更新するRFC 3032。
RFC 3032 states on page 4:
RFC 3032は、4ページの状態：
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.
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明示的NULLラベル」を表しています。このラベル値は、ラベルスタックの最下部にのみ法的です。それはラベルスタックをポップする必要があることを示し、及びパケットの転送は、その後、IPv6ヘッダーに基づいていなければなりません。
Paragraph i is hereby changed to read:
段落は、私はここに読むために変更されます。
i. A value of 0 represents the "IPv4 Explicit NULL Label".
私。 0の値は、「IPv4明示的NULLラベル」を表しています。
An IPv4 Explicit NULL at the top of the label stack means that the stack must be popped.
ラベルスタックの最上部にはIPv4明示的NULLは、スタックをポップしなければならないことを意味しています。
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.
NULLは、スタック上のラベルだけではなかった場合、これはその下にラベルがスタックの一番上に上昇するようになります。パケットの処分は、現在トップに上昇しているラベルに基づいています。
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.
一方、NULLがスタック上のラベルだけだった場合は、スタックが空になっています。得られたパケットをIPv4パケットとして扱われ、その配置は、IPv4ヘッダに基づいています。
Paragraph iii is hereby changed to read:
段落IIIは、ここに読み取るために変更されます。
iii. A value of 2 represents the "IPv6 Explicit NULL Label".
III。 2の値は「IPv6明示的NULLラベル」を表しています。
An IPv6 Explicit NULL at the top of the label stack means that the stack must be popped.
ラベルスタックの最上部にあるIPv6の明示的なNULLは、スタックをポップしなければならないことを意味しています。
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.
NULLは、スタック上のラベルだけではなかった場合、これはその下にラベルがスタックの一番上に上昇するようになります。パケットの処分は、現在トップに上昇しているラベルに基づいています。
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.
一方、NULLがスタック上のラベルだけだった場合は、スタックが空になっています。得られたパケットは、IPv6パケットとして扱われ、その配置は、IPv6ヘッダに基づいています。
Restricting Explicit NULL to the bottom of the stack has caused some problems in practice.
スタックの底に明示的なNULLを制限すると、実際にはいくつかの問題を引き起こしています。
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）に、特定のラベル配布ピアに、明示的なNULLのバインディングを配布するべきではありません：すべてのパケットをMPLS単一のラベルスタックのエントリを含むそのFECに対応する入ラベルとそのピアによって受信されました。明示的なNULLがFECにバインドされていますが、コンディションLが成立しない場合は、ピアが不正なパケットを作成するために要求されています。 MPLSの仕様はいずれも、ピアが実際にこのケースで行うことになっているものを言いません。この状況は、実際に、条件Lはほとんど保持していない、事実によって、より厄介作られ、それが成立するか否かを判断するために、一般的には、可能ではありません。
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.
1は、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:
「トンネルパケットは、差分-Servの情報の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のDiff-Servの情報」と呼ぶ）LSP出口を含むLSPスパンに沿った中間ノードに意味のある相違-SERV情報。このLSPのDiff-Servの情報は、LSP出口を越えては意味がありません：LSPスパンの中間ノードでのトラフィック調整がLSPのDiff-Servの情報に影響を与えるかどうかは、この更新のDiff-Servの情報は、LSP出口を超えて意味のあるとみなされているされていません無視。
- 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."
- （私たちは「トンネル化のDiff-Servの情報」と呼ぶ）LSP出口を超えて意味があるのDiff-Servの情報。この情報は、LSP出口にLSPイングレスによって搬送されます。この差分-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出口がトンネルのFECへの明示的なヌルをバインドするための一般的な方法です。意図はLSPのDiff-Servの情報は、明示的ヌルラベルスタックエントリのEXPビットに運ばれることで、トンネル化のDiff-Servの情報はすなわち、「以下」明示的ヌルラベルスタックエントリが何であれで運ばれます、 DSビットIPヘッダまたは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が成立しない場合）に使用されている場合もちろん、この方法は問題を引き起こします。 RFC 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.
一部の実装では、単に違法なパケットを送信します。他の人はそれを送信する前に明示的なNULLを剥離することにより、法律上のパケットに変換してみてください。しかし、それは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をバインドするために強要されていません。通常のラベルを代わりに使用することができます。しかし、明示的な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.
明示的なヌルのみがスタックの底で発生する制限を削除すると、パイプモデルの適切な動作を容易にするための最も簡単な方法です。
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.
この仕様に準拠していない実装は相互運用しない場合があります。具体的には、ルータがアドバタイズする場合、明示的なNULLの結合、およびそのルータがスタックの一番上に明示的ヌルを持つ複数のラベルスタックのエントリを持つパケットを送信しないであろう上流LDPピアを有する場合、それはできなくなります上流のLDPピアは、この仕様に準拠させられるまで、パイプモデルをサポートするために、明示的なNULLを使用します。
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.
複数のラベルスタックエントリと明示的なヌルの上部ラベル値を有する任意の受信したパケットを廃棄するこの仕様を、先行、ルータ実装が存在し得ることが可能です。彼らが明示的ヌルへのバインディングをアドバタイズしないように、そのようなルータを設定することをお勧めします。
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.
彼らの有益なコメントのためのラウール・アガーウォール、フランソワLeFaucheur、ヤコフ・レックター、ダンタッパンに感謝します。
[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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
Author's Address
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。