[要約] RFC 4950は、Multiprotocol Label Switching（MPLS）のためのICMP拡張に関する規格です。このRFCの目的は、MPLSネットワークでのエラー報告とトラブルシューティングを改善するためのICMPメッセージの拡張を提供することです。
Network Working Group R. Bonica
Request for Comments: 4950 Juniper Networks
Category: Standards Track D. Gan
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
August 2007
ICMP Extensions for Multiprotocol Label Switching
マルチプロトコルラベルスイッチング用のICMP拡張機能
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed.
このメモは、選択したマルチパートICMPメッセージに追加できる拡張オブジェクトを定義します。この拡張機能により、ラベルスイッチングルーターがMPLS情報をICMPメッセージに追加することを可能にし、すでに広く展開されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . . 3
4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. MPLS Label Stack Object . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
IP routers use the Internet Control Message Protocol, ICMPv4 [RFC0792] and ICMPv6 [RFC4443], to convey control information to source hosts. Network operators use this information to diagnose routing problems.
IPルーターは、インターネットコントロールメッセージプロトコル、ICMPv4 [RFC0792]およびICMPV6 [RFC4443]を使用して、コントロール情報をソースホストに伝えます。ネットワークオペレーターは、この情報を使用してルーティングの問題を診断します。
When a router receives an undeliverable IP datagram, it can send an ICMP message to the host that originated the datagram. The ICMP message indicates why the datagram could not be delivered. It also contains the IP header and leading payload octets of the "original datagram" to which the ICMP message is a response.
ルーターが配信不可能なIPデータグラムを受信すると、データグラムを発信したホストにICMPメッセージを送信できます。ICMPメッセージは、データグラムを配信できなかった理由を示します。また、ICMPメッセージが応答である「元のデータグラム」のIPヘッダーと主要なペイロードオクテットも含まれています。
MPLS Label Switching Routers (LSR) also use ICMP to convey control information to source hosts. Section 2.3 of [RFC3032] describes the interaction between MPLS and ICMP, and Sections 2.4 and 3 of [RFC3032] provide applications of that interaction.
MPLSラベルスイッチングルーター（LSR）もICMPを使用して、コントロール情報をホストをソースに伝えます。[RFC3032]のセクション2.3では、MPLSとICMP間の相互作用について説明し、[RFC3032]のセクション2.4および3はその相互作用の用途を提供します。
When an LSR receives an undeliverable MPLS-encapsulated datagram, it removes the entire MPLS label stack, exposing the previously encapsulated IP datagram. The LSR then submits the IP datagram to an error processing module. Error processing can include ICMP message generation.
LSRが配信不可能なMPLSカプセル化データグラムを受信すると、MPLSラベルスタック全体を削除し、以前にカプセル化されたIPデータグラムを公開します。次に、LSRはIPデータグラムをエラー処理モジュールに送信します。エラー処理には、ICMPメッセージ生成を含めることができます。
The ICMP message indicates why the original datagram could not be delivered. It also contains the IP header and leading octets of the original datagram.
The ICMP message, however, contains no information regarding the MPLS label stack that encapsulated the original datagram when it arrived at the LSR. This omission is significant because the LSR would have forwarded the original datagram based upon information contained by the MPLS label stack.
ただし、ICMPメッセージには、LSRに到達したときに元のデータグラムをカプセル化したMPLSラベルスタックに関する情報は含まれていません。LSRは、MPLSラベルスタックに含まれる情報に基づいて元のデータグラムを転送したため、この省略は重要です。
This memo defines an ICMP extension object that permits an LSR to append MPLS information to ICMP messages. Selected ICMP messages SHOULD include the MPLS label stack, as it arrived at the router that is sending the ICMP message. The ICMP message MUST also include the IP header and leading payload octets of the original datagram.
このメモは、LSRにMPLS情報をICMPメッセージに追加できるICMP拡張オブジェクトを定義します。選択したICMPメッセージには、ICMPメッセージを送信しているルーターに到達したMPLSラベルスタックを含める必要があります。ICMPメッセージには、元のデータグラムのIPヘッダーと主要なペイロードオクテットも含める必要があります。
The ICMP extensions defined in this document must be preceded by an ICMP Extension Structure Header and an ICMP Object Header. Both are defined in [RFC4884].
このドキュメントで定義されているICMP拡張機能の前には、ICMP拡張構造ヘッダーとICMPオブジェクトヘッダーが必要です。どちらも[RFC4884]で定義されています。
The ICMP extension defined in this document is equally applicable to ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. Throughout this document, unless otherwise specified, the acronym ICMP refers to multi-part ICMP messages, encompassing both ICMPv4 and ICMPv6.
このドキュメントで定義されているICMP拡張は、ICMPV4 [RFC0792]およびICMPV6 [RFC4443]に等しく適用できます。このドキュメント全体で、特に指定がない限り、頭字語ICMPは、ICMPv4とICMPv6の両方を含むマルチパートICMPメッセージを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC2119 [RFC2119]に記載されているように解釈される。
The ICMP extension defined in this memo supports enhancements to TRACEROUTE. Enhanced TRACEROUTE applications, like older implementations, indicate which nodes the original datagram visited en route to its destination. They differ from older implementations in that they also reflect the original datagram's MPLS encapsulation status as it arrived at each node.
このメモで定義されているICMP拡張は、Tracerouteの拡張機能をサポートしています。拡張されたTracerouteアプリケーションは、古い実装と同様に、目的地への途中で訪問した元のデータグラムがどのノードであるかを示します。これらは、各ノードに到達した元のデータグラムのMPLSカプセル化ステータスも反映するという点で、古い実装とは異なります。
Figure 1 contains sample output from an enhanced TRACEROUTE implementation.
図1には、拡張されたTraceroute実装からのサンプル出力が含まれています。
> traceroute 192.0.2.1
> Traceroute 192.0.2.1
traceroute to 192.0.2.1 (192.0.2.1), 30 hops max, 40 byte packets
192.0.2.1（192.0.2.1）へのTraceroute、30ホップ最大、40バイトパケット
1 192.0.2.13 (192.0.2.13) 0.661 ms 0.618 ms 0.579 ms
1 192.0.2.13（192.0.2.13）0.661 ms 0.618 ms 0.579 ms
2 192.0.2.9 (192.0.2.9) 0.861 ms 0.718 ms 0.679 ms
2 192.0.2.9（192.0.2.9）0.861 ms 0.718 ms 0.679 ms
MPLS Label=100048 Exp=0 TTL=1 S=1
3 192.0.2.5 (192.0.2.5) 0.822 ms 0.731 ms 0.708 ms
3 192.0.2.5（192.0.2.5）0.822 MS 0.731 MS 0.708 MS
MPLS Label=100016 Exp=0 TTL=1 S=1
4 192.0.2.1 (192.0.2.1) 0.961 ms 8.676 ms 0.875 ms
4 192.0.2.1（192.0.2.1）0.961 MS 8.676 MS 0.875 MS
Figure 1: Enhanced TRACEROUTE Sample Output
図1：強化されたトレーサーサンプル出力
This memo does not define the general relationship between ICMP and MPLS. Section 2.3 of [RFC3032] defines this relationship.
このメモは、ICMPとMPLSの一般的な関係を定義しません。[RFC3032]のセクション2.3は、この関係を定義しています。
The current memo does not define encapsulation-specific TTL (Time to Live) manipulation procedures. It defers to Section 5.4 of RFC 3034 [RFC3034] and Section 10 of [RFC3035] in this matter.
現在のメモは、カプセル化固有のTTL（ライブまでの時間）操作手順を定義していません。この問題では、RFC 3034 [RFC3034]のセクション5.4 [RFC3034]および[RFC3035]のセクション10に定ルします。
When encapsulation-specific TTL manipulation procedures defeat the basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE implementations.
カプセル化固有のTTL操作手順が基本的なトレーサーテアメカニズムを打ち負かすと、拡張されたトレーサーアウトの実装も倒されます。
The MPLS Label Stack Object can be appended to the ICMP Time Exceeded and Destination Unreachable messages. A single instance of the MPLS Label Stack Object represents the entire MPLS label stack, formatted exactly as it was when it arrived at the LSR that sends the ICMP message.
MPLSラベルスタックオブジェクトは、ICMP時間を超えて宛先の到達不可能なメッセージに追加できます。MPLSラベルスタックオブジェクトの単一インスタンスは、ICMPメッセージを送信するLSRに到着したときとまったく同じようにフォーマットされたMPLSラベルスタック全体を表します。
Figure 2 depicts the MPLS Label Stack Object. It must be preceded by an ICMP Extension Structure Header and an ICMP Object Header. Both are defined in [RFC4884].
図2は、MPLSラベルスタックオブジェクトを示しています。ICMP拡張構造ヘッダーとICMPオブジェクトヘッダーの前に先行する必要があります。どちらも[RFC4884]で定義されています。
In the object payload, octets 0-3 depict the first member of the MPLS label stack. Each remaining member of the MPLS label stack is represented by another 4 octets that share the same format.
オブジェクトペイロードでは、10〜3のオクテットがMPLSラベルスタックの最初のメンバーを示しています。MPLSラベルスタックの残りの各メンバーは、同じ形式を共有する別の4オクテットで表されます。
Class-Num = 1, MPLS Label Stack Class
C-Type = 1, Incoming MPLS Label Stack
Length = 4 + 4 * (number of MPLS LSEs)
0 1 2 3
+-------------+-------------+-------------+-------------+
| Label |EXP |S| TTL |
+-------------+-------------+-------------+-------------+
| |
| // Remaining MPLS Label Stack Entries // |
| |
+-------------+-------------+-------------+-------------+
Figure 2: MPLS Label Stack Object
Label: 20 bits
ラベル：20ビット
Exp: Experimental Use, 3 bits
Exp：実験的使用、3ビット
S: Bottom of Stack, 1 bit
S：スタックの下部、1ビット
TTL: Time to Live, 8 bits
TTL：ライブの時間、8ビット
This memo does not specify the conditions that trigger the generation of ICMP Messages for Labeled IP Packets. It does not define the interaction between MPLS and ICMP. However, this document defines an extension that allows an MPLS router to append MPLS information to multi-part ICMP messages, and therefore can provide the user of the TRACEROUTE application with additional information. Consequently, a network operator may wish to provide this information selectively based on some policy; for example, only include the MPLS extensions in ICMP messages destined to addresses within the network management blocks with administrative control over the router. An implementation could determine whether to include the MPLS Label Stack extensions based upon the destination address of the ICMP message, or based on a global configuration option in the router. Alternatively, an implementation may determine whether to include these MPLS extensions when TTL expires based on the number of label stack entries (depth of the label stack) of the incoming packet. Finally, an operator can make use of the TTL treatment on MPLS Pipe Model LSPs defined in [RFC3443] for a TTL-transparent mode of operation that would prevent ICMP Time Exceeded altogether when tunneled over the MPLS LSP.
このメモは、ラベル付きIPパケットのICMPメッセージの生成をトリガーする条件を指定しません。MPLとICMP間の相互作用を定義しません。ただし、このドキュメントでは、MPLSルーターがMPLS情報をマルチパートICMPメッセージに追加できるようにする拡張機能を定義しているため、Tracerouteアプリケーションのユーザーに追加情報を提供できます。したがって、ネットワークオペレーターは、いくつかのポリシーに基づいてこの情報を選択的に提供することを希望する場合があります。たとえば、ルーターを管理する管理制御を伴うネットワーク管理ブロック内のアドレスに向けられたICMPメッセージにMPLS拡張機能のみを含めます。実装により、ICMPメッセージの宛先アドレスに基づいてMPLSラベルスタック拡張機能を含めるか、ルーターのグローバル構成オプションに基づいて含めるかどうかを判断できます。あるいは、実装により、TTLが着信パケットのラベルスタックエントリの数（ラベルスタックの深さ）に基づいて期限切れになったときにこれらのMPLS拡張機能を含めるかどうかを決定する場合があります。最後に、オペレーターは、MPLS LSPを介してトンネル化されたときにICMP時間を完全に超えるTTL透明な動作モードのために、[RFC3443]で定義されたMPLSパイプモデルLSPでTTL処理を利用できます。
IANA has assigned the following object Class-num in the ICMP Extension Object registry:
IANAは、ICMP拡張オブジェクトレジストリに次のオブジェクトクラスNumを割り当てました。
Class-Num Description 1 MPLS Label Stack Class
クラス-Num説明1 MPLSラベルスタッククラス
IANA has established a registry for the corresponding class sub-type (C-Type) space, as follows:
IANAは、次のように、対応するクラスサブタイプ（Cタイプ）スペースのレジストリを確立しました。
MPLS Label Stack Class Sub-types:
MPLSラベルスタッククラスサブタイプ：
C-Type Description 0 Reserved 1 Incoming MPLS Label Stack 0x02-0xF6 Available for assignment 0xF7-0xFF Reserved for private use
Cタイプの説明0予約済み1着信MPLSラベルスタック0x02-0xf6が割り当てに利用可能です0xf7-0xffプライベート使用のために予約
C-Type values are assignable on a first-come-first-serve (FCFS) basis [RFC2434].
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884] Bonica、R.、Gan、D.、Tappan、D.、およびC. Pignataro、「マルチパートメッセージをサポートするためにICMPを拡張」、RFC 4884、2007年4月。
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[RFC3034] Conta、A.、Doolan、P。、およびA. Malis、「フレームリレーネットワーク仕様のラベルスイッチングの使用」、RFC 3034、2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035] Davie、B.、Lawrence、J.、McCloghrie、K.、Rosen、E.、Swallow、G.、Rekhter、Y.、およびP. Doolan、「LDPおよびATM VCスイッチングを使用したMPLS」、RFC 3035、2001年1月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでのライブ（TTL）処理」、RFC 3443、2003年1月。
Authors' Addresses
著者のアドレス
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon、VA 20171 US
EMail: rbonica@juniper.net
Der-Hwa Gan Consultant
der-hwa ganコンサルタント
EMail: derhwagan@yahoo.com
Daniel C. Tappan Consultant
ダニエルC.タッパンコンサルタント
EMail: Dan.Tappan@gmail.com
Carlos Pignataro Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 US
Carlos Pignataro Cisco Systems、Inc。7025 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: cpignata@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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エディター機能の資金は現在、インターネット協会によって提供されています。