Network Working Group R. Bonica
Request for Comments: 4884 Juniper Networks
Updates: 792, 4443 D. Gan
Category: Standards Track Consultant
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
April 2007
Extended ICMP to Support Multi-Part Messages
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）IETFトラスト（2007）。
Abstract
抽象
This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
この文書では、マルチパートの操作をサポートするために、ICMPメッセージを選択し再定義します。マルチパートICMPメッセージは、ICMPメッセージが以前に行ったという情報、ならびにアプリケーションが必要とするかもしれない付加的な情報のすべてを運びます。
Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.
マルチパートメッセージは、ICMP拡張構造によって支持されています。延長構造は、ICMPメッセージの最後に位置しています。これは、1つのまたは複数の拡張オブジェクトに続く拡張ヘッダを含みます。各拡張オブジェクトは、オブジェクトヘッダとオブジェクトペイロードを含みます。すべてのオブジェクトのヘッダーは、共通フォーマットを共有しています。
This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.
さらにこの文書では、長さ属性を指定することにより、前述したICMPメッセージを再定義します。拡張構造を付加することができるため、現在定義されてICMPメッセージの全ては、「オリジナルのデータグラム」フィールドを含みます。 「オリジナルのデータグラム」フィールドには、ICMPエラーメッセージを誘発したデータグラムの最初のオクテットが含まれています。元のデータグラムのフィールドは可変長であるが、ICMPメッセージは、その長さを指定するフィールドが含まれていません。したがって、メッセージの解析を容易にするために、この文書は、「オリジナルのデータグラム」フィールドの長さを反映する8つの以前に予約ビットを割り当てます。
The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.
提案された変更は、ICMPのコンプライアンスの要件を変更します。準拠した実装でこれらの変更の影響が議論されており、将来の実装のための新たな要件が提示されています。
This memo updates RFC 792 and RFC 4443.
このメモは、RFC 792およびRFC 4443を更新します。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of Changes to ICMP ......................................4
4. ICMP Extensibility ..............................................4
4.1. ICMPv4 Destination Unreachable .............................7
4.2. ICMPv4 Time Exceeded .......................................8
4.3. ICMPv4 Parameter Problem ...................................8
4.4. ICMPv6 Destination Unreachable .............................9
4.5. ICMPv6 Time Exceeded .......................................9
4.6. ICMP Messages That Can Be Extended ........................10
5. Backwards Compatibility ........................................10
5.1. Classic Application Receives ICMP Message with
Extensions ................................................12
5.2. Non-Compliant Application Receives ICMP Message
with No Extensions ........................................12
5.3. Non-Compliant Application Receives ICMP Message
with Compliant Extensions .................................13
5.4. Compliant Application Receives ICMP Message with
No Extensions .............................................14
5.5. Compliant Application Receives ICMP Message with
Non-Compliant Extensions ..................................14
6. Interaction with Network Address Translation ...................14
7. The ICMP Extension Structure ...................................15
8. ICMP Extension Objects .........................................16
9. Security Considerations ........................................16
10. IANA Considerations ...........................................17
11. Acknowledgments ...............................................17
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
This document redefines selected ICMPv4 [RFC0792] and ICMPv6 [RFC4443] messages to include an extension structure and a length attribute. The extension structure supports multi-part ICMP operation. Protocol designers can make an ICMP message carry additional information by encoding that information in the extension structure.
この文書では、拡張構造および長さ属性を含むようにICMPv4の[RFC0792]とのICMPv6 [RFC4443]メッセージを選択し再定義します。エクステンション構造は、マルチパートICMP操作をサポートしています。プロトコル設計者は、ICMPメッセージが拡張構造にその情報を符号化することにより、追加情報を搬送することができます。
This document also addresses a fundamental problem in ICMP extensibility. All of the ICMP messages addressed by this memo include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the "original datagram" field is of variable length, the ICMP message does not include a field that specifies its length.
また、このドキュメントでは、ICMPの拡張性に根本的な問題に対処します。このメモによって対処ICMPメッセージのすべてが「オリジナルのデータグラム」フィールドが含まれます。 「オリジナルのデータグラム」フィールドには、ICMPエラーメッセージを誘発したデータグラムの最初のオクテットが含まれています。 「オリジナルのデータグラム」分野は、可変長のですが、ICMPメッセージは、その長さを指定するフィールドが含まれていません。
Application software infers the length of the "original datagram" field from the total length of the ICMP message. If an extension structure were appended to the message without adding a length attribute for the "original datagram" field, the message would become unparsable. Specifically, application software would not be able to determine where the "original datagram" field ends and where the extension structure begins. Therefore, this document proposes a length attribute as well as an extension structure that is appended to the ICMP message.
アプリケーションソフトウェアは、ICMPメッセージの全長から「オリジナルのデータグラム」フィールドの長さを推定します。拡張構造「は、元のデータグラム」フィールドの長さ属性を追加することなく、メッセージに追加された場合、メッセージは解析できないとなります。具体的には、アプリケーション・ソフトウェアは、「オリジナルのデータグラム」フィールドの終了位置と延長構造が開始する場所を決定することはできないであろう。したがって、この文書は、長さ属性ならびにICMPメッセージに付加された拡張構造を提案しています。
The current memo also addresses backwards compatibility with existing ICMP implementations that either do not implement the extensions defined herein or implement them without adding the required length attributes. In particular, this document addresses backwards compatibility with certain, widely deployed, MPLS-aware ICMPv4 implementations that send the extensions defined herein without adding the required length attribute.
現在のメモはまた、いずれかが、本明細書に定義された拡張を実装したり、必要な長さの属性を追加することなく、それらを実装していない既存のICMP実装との後方互換性に対処しています。特に、この文書は、必要な長さ属性を追加することなく、本明細書で定義される拡張機能を送信する特定の、広く展開されている、MPLS対応ICMPv4の実装との後方互換性に対処します。
The current memo does not define any ICMP extension objects. It defines only the extension header and a common header that all extension objects share. [UNNUMBERED], [ROUTING-INST], and [MPLS-ICMP] provide sample applications of the ICMP Extension Object.
現在のメモはどんなICMP拡張オブジェクトを定義していません。それだけ拡張ヘッダとすべての拡張は、共有オブジェクトの共通ヘッダを定義します。 【無数]は、[ROUTING-INST]、および[MPLS-ICMP] ICMP拡張オブジェクトのサンプル・アプリケーションを提供します。
The above mentioned memos share a common characteristic. They all append information to the ICMP Time Expired message for consumption by TRACEROUTE. In this case, as in many others, appending information to the existing ICMP Time Expired Message is preferable to defining a new message and emitting two messages whenever a packet is dropped due to TTL expiration.
上記メモは、共通の特性を共有します。彼らはすべてのTRACEROUTEによる消費のためにICMP時間期限切れメッセージに情報を追加します。この場合には、他の多くのように、既存のICMP時間期限切れメッセージに情報を追加すると、新しいメッセージを定義し、パケットがTTLの期限切れに起因落とされるたびに2つのメッセージを放出することが好ましいです。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following is a summary of changes to ICMP that are introduced by this memo:
以下は、このメモで導入されたICMPへの変更の概要です：
An ICMP Extension Structure MAY be appended to ICMPv4 Destination Unreachable, Time Exceeded, and Parameter Problem messages.
ICMP拡張モジュールの構造は、到達不能ICMPv4の先、超過時間、およびパラメータ問題メッセージに付加されてもよいです。
An ICMP Extension Structure MAY be appended to ICMPv6 Destination Unreachable, and Time Exceeded messages.
ICMP拡張モジュールの構造はのICMPv6宛先到達不能、および時間超過メッセージに付加されてもよいです。
The above mentioned messages include an "original datagram" field, and the message formats are updated to specify a length attribute for the "original datagram" field.
上記メッセージは、「オリジナルのデータグラム」フィールドを含み、メッセージフォーマットは、「オリジナルのデータグラム」フィールドの長さ属性を指定するように更新されます。
When the ICMP Extension Structure is appended to an ICMP message and that ICMP message contains an "original datagram" field, the "original datagram" field MUST contain at least 128 octets.
ICMP拡張構造はICMPメッセージおよびICMPメッセージが「オリジナルのデータグラム」フィールドが含まれていることを付加した場合には、「オリジナルのデータグラム」フィールドは、少なくとも128個のオクテットを含まなければなりません。
When the ICMP Extension Structure is appended to an ICMPv4 message and that ICMPv4 message contains an "original datagram" field, the "original datagram" field MUST be zero padded to the nearest 32-bit boundary.
ICMP拡張構造はICMPv4のメッセージおよびICMPv4のメッセージは、「オリジナルのデータグラム」フィールドが含まれていることを付加した場合には、「オリジナルのデータグラム」フィールドは、最も近い32ビット境界にゼロ詰めなければなりません。
When the ICMP Extension Structure is appended to an ICMPv6 message and that ICMPv6 message contains an "original datagram" field, the "original datagram" field MUST be zero padded to the nearest 64-bit boundary.
ICMP拡張構造はICMPv6メッセージおよびICMPv6メッセージは、「オリジナルのデータグラム」フィールドが含まれていることを付加した場合には、「オリジナルのデータグラム」フィールドは、最も近い64ビット境界にゼロ埋めなければなりません。
ICMP messages defined in the future SHOULD indicate whether or not they support the extension mechanism defined in this specification. It is recommended that all new messages support extensions.
将来的に定義されたICMPメッセージは、彼らがこの仕様で定義された拡張メカニズムをサポートするかどうかを示す必要があります。すべての新しいメッセージが拡張をサポートすることをお勧めします。
RFC 792 defines the following ICMPv4 message types:
RFC 792は次のICMPv4メッセージタイプを定義します。
- Destination Unreachable
- 宛先到達不能
- Time Exceeded
- 時間超過
- Parameter Problem
- パラメータの問題
- Source Quench
- ソースクエンチ
- Redirect
- リダイレクト
- Echo Request/Reply
- エコー要求/応答
- Timestamp/Timestamp Reply
- タイムスタンプ/タイムスタンプ応答
- Information Request/Information Reply
- 情報リクエスト/情報返信
[RFC1191] reserves bits for the "Next-Hop MTU" field in the Destination Unreachable message.
[RFC1191]は宛先到達不能メッセージの「ネクストホップMTU」フィールドのビットを予約します。
RFC 4443 defines the following ICMPv6 message types:
RFC 4443は、次のICMPv6メッセージタイプを定義します。
- Destination Unreachable
- 宛先到達不能
- Packet Too Big
- パケット過大
- Time Exceeded
- 時間超過
- Parameter Problem
- パラメータの問題
- Echo Request/Reply
- エコー要求/応答
Many ICMP messages are extensible as currently defined. Protocol designers can extend ICMP messages by simply appending fields or data structures to them.
現在定義されているように、多くのICMPメッセージは拡張可能です。プロトコルの設計者は、単にそれらにフィールドまたはデータ構造を付加することにより、ICMPメッセージを拡張することができます。
However, the following ICMP messages are not extensible as currently defined:
現在定義されているようしかし、以下のICMPメッセージは拡張可能ではありません。
- ICMPv4 Destination Unreachable (type = 3)
- ICMPv4の宛先到達不能（タイプ= 3）
- ICMPv4 Time Exceeded (type = 11)
- ICMPv4の時間超過（タイプ= 11）
- ICMPv4 Parameter Problem (type = 12)
- ICMPv4のパラメータ問題（タイプ= 12）
- ICMPv6 Destination Unreachable (type = 1)
- ICMPv6の宛先到達不能（タイプ= 1）
- ICMPv6 Packet Too Big (type = 2)
- ICMPv6のパケット過大（タイプ= 2）
- ICMPv6 Time Exceeded (type = 3)
- ICMPv6の時間超過（タイプ= 3）
- ICMPv6 Parameter Problem (type = 4)
- ICMPv6のパラメータ問題（タイプ= 4）
These messages contain an "original datagram" field which represents the leading octets of the datagram to which the ICMP message is a response. RFC 792 defines the "original datagram" field for ICMPv4 messages. In RFC 792, the "original datagram" field includes the IP header plus the next eight octets of the original datagram. [RFC1812] extends the "original datagram" field to contain as many octets as possible without causing the ICMP message to exceed the minimum IPv4 reassembly buffer size (i.e., 576 octets). RFC 4443 defines the "original datagram" field for ICMPv6 messages. In RFC 4443, the "original datagram" field always contained as many octets as possible without causing the ICMP message to exceed the minimum IPv6 MTU (i.e., 1280 octets).
これらのメッセージは、ICMPメッセージが応答されたデータグラムの主要なオクテットを表し、「オリジナルのデータグラム」フィールドが含まれています。 RFC 792は、ICMPv4のメッセージの「オリジナルのデータグラム」フィールドを定義します。 RFC 792において、「オリジナルのデータグラム」フィールドは、IPヘッダを加え、元のデータグラムの次の8つのオクテットを含んでいます。 [RFC1812]は、最小IPv4の再アセンブリバッファサイズ（すなわち、576オクテット）を超えるようにICMPメッセージを発生させることなく、できるだけ多くのオクテットを含むように「オリジナルのデータグラム」フィールドを拡張します。 RFC 4443は、ICMPv6メッセージのための「オリジナルのデータグラム」フィールドを定義します。 RFC 4443においては、「オリジナルのデータグラム」フィールドは常に最小のIPv6 MTU（すなわち1280オクテット）を超えるようにICMPメッセージを発生させることなく、できるだけ多くのオクテットを含んでいました。
Unfortunately, the "original datagram" field lacks a length attribute. Application software infers the length of this field from the total length of the ICMP message. If an extension structure were appended to the message without adding a length attribute for the "original datagram" field, the message would become unparsable. Specifically, application software would not be able to determine where the "original datagram" field ends and where the extension structure begins.
残念ながら、「オリジナルのデータグラム」フィールドには、長さ属性を欠いています。アプリケーションソフトウェアは、ICMPメッセージの全長からこのフィールドの長さを推定します。拡張構造「は、元のデータグラム」フィールドの長さ属性を追加することなく、メッセージに追加された場合、メッセージは解析できないとなります。具体的には、アプリケーション・ソフトウェアは、「オリジナルのデータグラム」フィールドの終了位置と延長構造が開始する場所を決定することはできないであろう。
In order to solve this problem, this memo introduces an 8-bit length attribute to the following ICMPv4 messages.
この問題を解決するために、このメモは、次のICMPv4メッセージに8ビット長の属性を紹介します。
- Destination Unreachable (type = 3)
- 宛先到達不能（タイプ= 3）
- Time Exceeded (type = 11)
- 時間超過（タイプ= 11）
- Parameter Problem (type = 12)
- パラメータ問題（タイプ= 12）
It also introduces an 8-bit length attribute to the following ICMPv6 messages.
また、次のICMPv6メッセージに8ビット長の属性を紹介します。
- Destination Unreachable (type = 1)
- 宛先到達不能（タイプ= 1）
- Time Exceeded (type = 3)
- 時間超過（タイプ= 3）
The length attribute MUST be specified when the ICMP Extension Structure is appended to the above mentioned ICMP messages.
ICMP拡張構造は、上述したICMPメッセージに付加されたときに長さ属性を指定する必要があります。
The length attribute represents the length of the "original datagram" field. Space for the length attribute is claimed from reserved octets, whose value was previously required to be zero.
長さ属性は、「オリジナルのデータグラム」フィールドの長さを表しています。長さ属性のための空間は、値が以前にゼロであることが要求された予約オクテットから、請求されています。
For ICMPv4 messages, the length attribute represents 32-bit words. When the length attribute is specified, the "original datagram" field MUST be zero padded to the nearest 32-bit boundary. Because the sixth octet of each of the impacted ICMPv4 messages was reserved for future use, this octet was selected as the location of the length attribute in ICMPv4.
ICMPv4のメッセージの場合、長さ属性は、32ビットワードを表します。長さ属性が指定されている場合、「オリジナルのデータグラム」フィールドは、最も近い32ビット境界にパディングゼロでなければなりません。影響ICMPv4のメッセージのそれぞれの第六のオクテットは将来の使用のために予約されたため、このオクテットはICMPv4の長さ属性の場所として選択しました。
For ICMPv6 messages, the length attribute represents 64-bit words. When the length attribute is specified, the "original datagram" field MUST be zero padded to the nearest 64-bit boundary. Because the fifth octet of each of the impacted ICMPv6 messages was reserved for future use, this octet was selected as the location of the length attribute in ICMPv6.
ICMPv6メッセージの場合は、長さ属性は64ビットワードを表します。長さ属性が指定されている場合、「オリジナルのデータグラム」フィールドは、最も近い64ビット境界にパディングゼロでなければなりません。影響ICMPv6メッセージのそれぞれの第五のオクテットは将来の使用のために予約されたため、このオクテットは、ICMPv6の長さ属性の場所として選択しました。
In order to achieve backwards compatibility, when the ICMP Extension Structure is appended to an ICMP message and that ICMP message contains an "original datagram" field, the "original datagram" field MUST contain at least 128 octets. If the original datagram did not contain 128 octets, the "original datagram" field MUST be zero padded to 128 octets. (See Section 5.1 for rationale.)
ICMP拡張構造はICMPメッセージに、その追加されたときに下位互換性を実現するために、ICMPメッセージが「オリジナルのデータグラム」フィールドを含む、「オリジナルのデータグラム」フィールドは、少なくとも128個のオクテットを含まなければなりません。元のデータグラムが128個のオクテットが含まれていなかった場合は、「オリジナルのデータグラム」フィールドは128個のオクテットにゼロパディングでなければなりません。 （根拠については、セクション5.1を参照してください。）
The following sub-sections depict length attribute as it has been introduced to selected ICMP messages.
それは選択されたICMPメッセージに導入されているように、次のサブセクションでは、長さ属性を示しています。
Figure 1 depicts the ICMPv4 Destination Unreachable Message.
図1は、ICMPv4の送信先到達不能メッセージを描いています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | Next-Hop MTU* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ICMPv4 Destination Unreachable
図1：ICMPv4の宛先到達不能
The syntax and semantics of all fields are unchanged from RFC 792. However, a length attribute is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 32-bit words.
構文とすべてのフィールドのセマンティクスは、しかし、長さ属性が2番目の単語に追加されたRFC 792から変更されていません。長さ属性は32ビットワードで測定されたパディング「オリジナルのデータグラム」フィールドの長さを表します。
* The Next-Hop MTU field is not required in all cases. It is depicted only to demonstrate that those bits are not available for assignment in this memo.
*次ホップMTUフィールドは、すべての場合に必要とされていません。これらのビットは、このメモで割り当て可能でないことを証明するためにのみ描かれています。
Figure 2 depicts the ICMPv4 Time Exceeded Message.
図2は、ICMPv4の時間超過メッセージを描いています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ICMPv4 Time Exceeded
図2：ICMPv4の時間超過
The syntax and semantics of all fields are unchanged from RFC 792, except for a length attribute which is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 32-bit words.
すべてのフィールドの構文と意味論は、2番目の単語に追加された長さ属性を除き、RFC 792から変更されていません。長さ属性は32ビットワードで測定されたパディング「オリジナルのデータグラム」フィールドの長さを表します。
Figure 3 depicts the ICMPv4 Parameter Problem Message.
図3は、ICMPv4のパラメータ問題メッセージを描いています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICMPv4 Parameter Problem
図3：ICMPv4のパラメータ問題
The syntax and semantics of all fields are unchanged from RFC 792, except for a length attribute which is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 32-bit words.
すべてのフィールドの構文と意味論は、2番目の単語に追加された長さ属性を除き、RFC 792から変更されていません。長さ属性は32ビットワードで測定されたパディング「オリジナルのデータグラム」フィールドの長さを表します。
Figure 4 depicts the ICMPv6 Destination Unreachable Message.
図4は、ICMPv6の宛先到達不能メッセージを描いています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |
Figure 4: ICMPv6 Destination Unreachable
図4：ICMPv6の宛先到達不能
The syntax and semantics of all fields are unchanged from RFC 4443. However, a length attribute is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 64-bit words.
すべてのフィールドの構文とセマンティクスは、長さ属性が2番目の単語に追加された、しかし、RFC 4443から変更されていません。長さ属性は、64ビット・ワードで測定されたパディング「オリジナルのデータグラム」フィールドの長さを表します。
Figure 5 depicts the ICMPv6 Time Exceeded Message.
図5は、ICMPv6の時間超過メッセージを描いています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |
Figure 5: ICMPv6 Time Exceeded
図5：ICMPv6の時間超過
The syntax and semantics of all fields are unchanged from RFC 4443, except for a length attribute which is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 64-bit words.
すべてのフィールドの構文と意味論は、2番目の単語に追加された長さ属性を除き、RFC 4443から変更されていません。長さ属性は、64ビット・ワードで測定されたパディング「オリジナルのデータグラム」フィールドの長さを表します。
The ICMP Extension Structure MAY be appended to messages of the following types:
ICMP拡張モジュールの構造は、以下のタイプのメッセージに追加されることがあります。
- ICMPv4 Destination Unreachable
- ICMPv4の宛先到達不能
- ICMPv4 Time Exceeded
- ICMPv4の時間超過
- ICMPv4 Parameter Problem
- ICMPv4のパラメータ問題
- ICMPv6 Destination Unreachable
- ICMPv6の宛先到達不能
- ICMPv6 Time Exceeded
- ICMPv6の時間超過
The ICMP Extension Structure MUST NOT be appended to any of the other ICMP messages mentioned in Section 4. Extensions were not defined for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages because these messages lack space for a length attribute.
ICMPエクステンション構造は、これらのメッセージは、長さ属性のためのスペースが不足しているため、拡張機能がICMPv6の「パケット過大」と「パラメータ問題」メッセージのために定義されていなかった第4節で述べた他のICMPメッセージのいずれにも追加されてはなりません。
ICMP messages can be categorized as follows:
次のようにICMPメッセージを分類できます。
- Messages that do not include any ICMP extensions
- すべてのICMPの機能拡張が含まれていないメッセージ
- Messages that include non-compliant ICMP extensions
- 非準拠ICMPの拡張が含まれたメッセージ
- Messages that includes compliant ICMP extensions
- 準拠したICMPの拡張機能が含まれたメッセージ
Any ICMP implementation can send a message that does not include extensions. ICMP implementations produced prior to 1999 are not known to send ICMP extensions.
どれICMPの実装では、拡張子が含まれていないメッセージを送信することができます。 1999年以前に生産さICMP実装はICMP拡張を送信することが知られていません。
Some ICMP implementations, produced between 1999 and the time of this publication, may send a non-compliant version of ICMP extensions described in this memo. Specifically, these implementations may append the ICMP Extension Structure to the Time Exceeded and Destination Unreachable messages. When they do this, they send exactly 128 octets representing the original datagram, zero padding if required. They also calculate checksums as described in this document. However, they do not specify a length attribute to be associated with the "original datagram" field.
1999この出版物の時間の間に生じるいくつかのICMP実装は、このメモに記載のICMP拡張の非準拠バージョンを送信することができます。具体的には、これらの実装は、時間超過とDestination UnreachableメッセージにICMPエクステンション構造を追加することがあります。彼らはこれを行うと、彼らが必要な場合は、元のデータグラム、ゼロパディングを表す正確に128オクテットを送信します。この文書で説明したように彼らはまた、チェックサムを計算します。しかし、彼らは「オリジナルのデータグラム」フィールドに関連付けられる長さ属性を指定しないでください。
It is assumed that ICMP implementations produced in the future will send ICMP extensions that are compliant with this specification.
将来的には生産ICMPの実装は、この仕様に準拠しているICMPの拡張子を送信することが想定されます。
Likewise, applications that consume ICMP messages can be categorized as follows:
次のように同様に、ICMPメッセージを消費するアプリケーションを分類できます。
- Classic applications
- Classicアプリケーション
- Non-compliant applications
- 非対応のアプリケーション
- Compliant applications
- 準拠のアプリケーション
Classic applications do not parse extensions defined in this memo. They are insensitive to the length attribute that is associated with the "original datagram" field.
Classicアプリケーションは、このメモで定義された拡張を解析しません。彼らは、「オリジナルのデータグラム」フィールドに関連付けられている長さ属性の影響を受けません。
Non-compliant implementations parse the extensions defined in this memo, but only in conjunction with the Time Expired and Destination Unreachable messages. They require the "original datagram" field to contain exactly 128 octets and are insensitive to the length attribute that is associated with the "original datagram" field. Non-compliant applications were produced between 1999 and the time of publication of this memo.
非準拠の実装は、このメモでは、唯一の時間期限切れとDestination Unreachableメッセージと一緒に定義された拡張を解析します。彼らは正確に128オクテットを含むように「オリジナルのデータグラム」フィールドを必要とし、「オリジナルのデータグラム」フィールドに関連付けられている長さ属性の影響を受けません。非対応のアプリケーションは、1999年とこのメモの発行時点の間で生産されました。
Compliant applications comply fully with the specifications of this document.
準拠したアプリケーションは、このドキュメントの仕様に完全に準拠します。
In order to demonstrate backwards compatibility, Table 1 describes how members of each application category would parse each category of ICMP message.
下位互換性を実証するために、表1は、各アプリケーションカテゴリのメンバーは、ICMPメッセージの各カテゴリを解析する方法を説明します。
+----------------+----------------+----------------+----------------+
| | No Extensions | Non-compliant | Compliant |
| | | Extensions | Extensions |
+----------------+----------------+----------------+----------------+
| Classic | - | Section 5.1 | Section 5.1 |
| Application | | | |
| | | | |
| Non-compliant | Section 5.2 | - | Section 5.3 |
| Application | | | |
| | | | |
| Compliant | Section 5.4 | Section 5.5 | - |
| Application | | | |
+----------------+----------------+----------------+----------------+
Table 1
表1
In the table above, cells that contain a dash represent the nominal case and require no explanation. In the following sections, we assume that the ICMP message type is "Time Exceeded".
上記の表において、ダッシュを含むセルは、公称ケースを表しており、何の説明を必要としません。次のセクションでは、ICMPメッセージタイプは、「時間が超過」であることを前提としています。
When a classic application receives an ICMP message that includes extensions, it will incorrectly interpret those extensions as being part of the "original datagram" field. Fortunately, the extensions are guaranteed to begin at least 128 octets beyond the beginning of the "original datagram" field. So, only those ICMP applications that process the 129th octet of the "original datagram" field will be adversely effected. To date, only two applications falling into this category have been identified, and the degree to which they are effected is minimal.
古典的なアプリケーションは、拡張機能が含まICMPメッセージを受信すると、それは間違って「オリジナルのデータグラム」フィールドの一部としてこれらの拡張子を解釈します。幸いなことに、拡張子は「オリジナルのデータグラム」フィールドの先頭を超えて少なくとも128個のオクテットを開始することが保証されています。だから、「オリジナルのデータグラム」分野の129番目のオクテットを処理のみICMPアプリケーションに悪影響をもたらされます。現在までに、このカテゴリに陥るだけで2つのアプリケーションが同定されており、それらが行われる度合いが最小限です。
Some TCP stacks, when they receive an ICMP message, verify the checksum in the original datagram field [ATTACKS]. If the checksum is incorrect, the TCP stack discards the ICMP message for security reasons. If the trailing octets of the original datagram field are overwritten by ICMP extensions, the TCP stack will discard an ICMP message that it would not otherwise have discarded. The impact of this issue is considered to be minimal because many ICMP messages are discarded for other reasons (e.g., ICMP filtering, network congestion, checksum was incorrect because original datagram field was truncated.)
いくつかのTCPスタック、彼らはICMPメッセージを受信したときに、元のデータグラムのフィールドにチェックサムを確認し、[ATTACKS]。チェックサムが間違っている場合、TCPスタックは、セキュリティ上の理由から、ICMPメッセージを破棄します。元のデータグラムのフィールドの末尾のオクテットは、ICMPの拡張によって上書きされている場合、TCPスタックは、それがそうでなければ廃棄されていませんでしICMPメッセージを破棄します。多くのICMPメッセージが他の理由で破棄されるため、この問題の影響は最小限であると考えられている（元のデータグラムのフィールドを切り捨てたため、例えば、ICMPフィルタリング、ネットワークの輻輳、チェックサムが正しくありませんでした。）
Another theoretically possible, but highly improbably scenario occurs when ICMP extensions overwrite the portion of the original datagram field that represents the TCP header, causing the TCP stack to operate upon the wrong TCP connection. This scenario is highly unlikely because it occurs only when the TCP header appears at or beyond the 128th octet of the original datagram field and then only when the extensions approximate a valid TCP header.
ICMP拡張はTCPスタックが間違ったTCP接続時に動作させる、TCPヘッダを表す元のデータグラムのフィールドの一部を上書きするときに、別の理論的に可能ではなく、高度にimprobablyシナリオが発生します。 TCPヘッダは拡張が有効なTCPヘッダを近似する場合にのみ、元のデータグラムのフィールドの128オクテットで、またはを超えて表示された場合にのみ発生するため、このシナリオは非常に低いです。
When a non-compliant ICMPv4 application receives a message that contains no extensions, the application examines the total length of the ICMPv4 message. If the total ICMPv4 message length is less than the length of its IP header plus 144 octets, the application correctly determines that the message does not contain any extensions.
非準拠ICMPv4のアプリケーションが何の拡張が含まれていないメッセージを受信した場合、アプリケーションは、ICMPv4のメッセージの全長を調べます。総ICMPv4のメッセージの長さは、そのIPヘッダの長さを加えた144オクテット未満である場合、アプリケーションが正しくメッセージは、任意の拡張子が含まれていないと判断します。
The 144-octet sum is derived from 8 octets for the first two words of the ICMPv4 Time Exceeded message, 128 octets for the "original datagram" field, 4 octets for the ICMP Extension Header, and 4 octets for a single ICMP Object header. All of these octets would be required if extensions were present.
144オクテットの合計がICMPv4の時間超過メッセージ、「オリジナルのデータグラム」フィールド128オクテット、ICMP拡張ヘッダの4つのオクテット、及び単一ICMPオブジェクトヘッダの4つのオクテットの最初の二つの単語のための8つのオクテットから誘導されます。拡張子が存在した場合は、これらのオクテットのすべてが必要とされるであろう。
If the ICMPv4 payload contains 144 octets or more, the application must examine the 137th octet to determine whether it represents a valid ICMPv4 Extension Header. In order to represent a valid Extension Header, it must contain a valid version number and checksum. If it does not contain a valid version number and checksum, the application correctly determines that the message does not contain any extensions.
ICMPv4のペイロードが144オクテット以上が含まれている場合、アプリケーションは、それが有効なICMPv4の拡張ヘッダを表しているかどうかを決定するために第137オクテットを調べる必要があります。有効な拡張ヘッダを表現するためには、有効なバージョン番号とチェックサムが含まれている必要があります。それが有効なバージョン番号とチェックサムが含まれていない場合、アプリケーションが正しくメッセージが任意の拡張子が含まれていないと判断しました。
Non-compliant applications assume that the ICMPv4 Extension Structure begins on the 137th octet of the Time Exceeded message, after a 128-octet field representing the padded "original datagram" message.
非対応のアプリケーションは、ICMPv4のエクステンション構造がパディング「オリジナルのデータグラム」のメッセージを表す128オクテットフィールドの後、時間超過メッセージの第137オクテットに開始できることを前提としています。
It is possible that a non-compliant application will parse an ICMPv4 message incorrectly under the following conditions:
非準拠のアプリケーションは、以下の条件で間違ってICMPv4のメッセージを解析することが可能です。
- the message does not contain extensions
- メッセージは、拡張子が含まれていません
- the original datagram field contains 144 octets or more
- 元のデータグラムのフィールドは144オクテット以上が含まれています
- selected octets of the original datagram field represent the correct values for an extension header version number and checksum
- 元のデータグラムのフィールドの選択されたオクテットは拡張ヘッダのバージョン番号とチェックサムのための正しい値を表します
Although this is possible, it is very unlikely.
これは可能ですが、それは非常に低いです。
A similar analysis can be performed for ICMPv6. However, the numeric constants would change as appropriate.
同様の分析は、ICMPv6のために行うことができます。しかし、数値定数は、必要に応じて変化するであろう。
5.3. Non-Compliant Application Receives ICMP Message with Compliant Extensions
5.3. 非準拠のアプリケーションは、準拠の拡張でICMPメッセージを受け取ります
When a non-compliant application receives a message that contains compliant ICMP extensions, it will parse those extensions correctly only if the "original datagram" field contains exactly 128 octets. This is because non-compliant applications are insensitive to the length attribute that is associated with the "original datagram" field. (They assume its value to be 128.)
非対応アプリケーションが対応ICMP拡張を含むメッセージを受信すると、それは「オリジナルのデータグラム」分野は正確に128オクテットが含まれている場合にのみ正しくこれらの拡張子を解析します。非準拠のアプリケーションは、「オリジナルのデータグラム」フィールドに関連付けられている長さ属性の影響を受けないためです。 （彼らは、その値は128であることを前提とし）
Provided that the entire ICMP message does not exceed the minimum reassembly buffer size (576 octets for ICMPv4 or 1280 octets for ICMPv6), there is no upper limit upon the length of the "original datagram" field. However, each implementation will decide how many octets to include. Those wishing to be backward compatible with non-compliant TRACEROUTE implementations will include exactly 128 octets. Those not requiring compatibility with non-compliant TRACEROUTE applications may include more octets.
全体のICMPメッセージは最小再アセンブリバッファサイズ（ICMPv4のための576オクテットまたはICMPv6の1280オクテット）を超えないという条件で、「オリジナルのデータグラム」フィールドの長さに上限はありません。しかし、それぞれの実装が含まれるようにどのように多くのオクテットを決定します。非準拠TRACEROUTE実装との後方互換性があるように希望される方は、正確に128オクテットが含まれます。非準拠TRACEROUTEアプリケーションとの互換性を必要としないものがよりオクテットを含んでいてもよいです。
When a compliant application receives an ICMP message, it examines the length attribute that is associated with the "original datagram" field. If the length attribute is zero, the compliant application MUST determine that the message contains no extensions.
準拠アプリケーションはICMPメッセージを受信すると、それは「オリジナルのデータグラム」フィールドに関連付けられた長さ属性を調べます。長さ属性がゼロの場合は、対応アプリケーションは、メッセージが全く機能拡張が含まれていないことを決定しなければなりません。
5.5. Compliant Application Receives ICMP Message with Non-Compliant Extensions
5.5. 対応アプリケーションは、非準拠の拡張機能でICMPメッセージを受け取ります
When a compliant application receives an ICMP message, it examines the length attribute that is associated with the "original datagram" field. If the length attribute is zero, the compliant application MUST determine that the message contains no extensions. In this case, that determination is technically correct, but not backwards compatible with the non-compliant implementation that originated the ICMP message.
準拠アプリケーションはICMPメッセージを受信すると、それは「オリジナルのデータグラム」フィールドに関連付けられた長さ属性を調べます。長さ属性がゼロの場合は、対応アプリケーションは、メッセージが全く機能拡張が含まれていないことを決定しなければなりません。この場合には、その決意は、技術的に正しいが、ICMPメッセージを発信し、非準拠の実装との下位互換性がありません。
So, to ease transition yet encourage compliant implementation, compliant TRACEROUTE implementations MUST include a non-default operation mode to also interpret non-compliant responses. Specifically, when a TRACEROUTE application operating in non-compliant mode receives a sufficiently long ICMP message that does not specify a length attribute, it will parse for a valid extension header at a fixed location, assuming a 128-octet "original datagram" field. If the application detects a valid version and checksum, it will treat the octets that follow as an extension structure.
だから、移行を容易にまだ準拠した実装を奨励するために、対応のTRACEROUTE実装はまた、非準拠の応答を解釈するために、デフォルト以外の動作モードを含まなければなりません。非準拠モードで動作TRACEROUTEアプリケーションは、長さ属性が指定されていない十分に長いICMPメッセージを受信すると具体的には、128オクテット「オリジナルのデータグラム」フィールドを想定し、固定位置で有効な拡張ヘッダの解析します。アプリケーションが有効なバージョンとチェックサムを検出した場合には、エクステンション構造として続くオクテットを扱います。
The ICMP extensions defined in this memo do not interfere with Network Address Translation. [RFC3022] permits traditional NAT devices to modify selected fields within ICMP messages. These fields include the "original datagram" field mentioned above. However, if a NAT device modifies the "original datagram" field, it should modify only the leading octets of that field, which represent the outermost IP header. Because the outermost IP header is guaranteed to be contained by the first 128 octets of the "original datagram" field, ICMP extensions and NAT will not interfere with one another.
このメモで定義されたICMPの拡張は、ネットワークアドレス変換を妨げることはありません。 [RFC3022]はICMPメッセージ内の選択したフィールドを変更するために、伝統的なNATデバイスを許可します。これらのフィールドは、前述した「オリジナルのデータグラム」フィールドが含まれます。 NATデバイスは、「オリジナルのデータグラム」フィールドを変更する場合は、それだけで、最も外側のIPヘッダを表し、そのフィールドの先頭オクテットを変更すべきです。最も外側のIPヘッダが「オリジナルのデータグラム」フィールドの最初の128個のオクテットに含まれることが保証されているので、ICMPの拡張とNATは、互いに干渉しないであろう。
It is conceivable that a NAT implementation might overstep the restrictions of RFC 3022 and overwrite the length attribute specified by this memo. If a NAT implementation were to overwrite the length attribute with zeros, the resulting packet will be indistinguishable from a packet that was generated by a non-compliant ICMP implementation. See Section 5.5 for packet details and a discussion of backwards compatibility.
NATの実装は、RFC 3022の制限を踏み越えし、このメモで指定された長さ属性が上書きされるかもしれないと考えられます。 NAT実装はゼロで長さ属性を上書きした場合、結果として得られるパケットは、非準拠ICMP実装によって生成されたパケットと区別できないであろう。パケットの詳細については、セクション5.5との後方互換性の説明を参照してください。
This memo proposes an optional ICMP Extension Structure that can be appended to the ICMP messages referenced in Section 4.6 of this document.
このメモは、このドキュメントのセクション4.6で参照ICMPメッセージに追加できるオプションのICMPエクステンション構造を提案しています。
The Extension Structure contains exactly one Extension Header followed by one or more objects. Having received an ICMP message with extensions, application software MAY process selected objects while ignoring others. The presence of an unrecognized object does not imply that an ICMP message is malformed.
エクステンション構造は、1つの拡張ヘッダは、1つまたは複数のオブジェクトが続く含まれています。他人を無視して拡張子を持つICMPメッセージを受信したアプリケーション・ソフトウェアは、選択したオブジェクトを処理することができます。認識されない物体の存在は、ICMPメッセージが不正であることを意味するものではありません。
As stated above, the total length of the ICMP message, including extensions, MUST NOT exceed the minimum reassembly buffer size. Figure 6 depicts the ICMP Extension Header.
上述したように、拡張を含むICMPメッセージの全長は、最小の再アセンブリバッファサイズを超えてはなりません。図6は、ICMP拡張ヘッダを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ICMP Extension Header
図6：ICMP拡張ヘッダ
The fields of the ICMP Extension Header are as follows:
次のようにICMP拡張ヘッダのフィールドは、次のとおりです。
Version: 4 bits
バージョン：4ビット
ICMP extension version number. This is version 2.
ICMP拡張のバージョン番号。これは、バージョン2です。
Reserved: 12 bits
予約：12ビット
Must be set to 0.
0に設定する必要があります。
Checksum: 16 bits
チェックサム：16ビット
The one's complement of the one's complement sum of the data structure, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. See Section 5.2 for a description of how this field is used.
チェックサムフィールドを持つデータ構造の1の補数和の1の補数は、チェックサムを計算する目的のためにゼロに置き換え。すべてのゼロ値にはチェックサムが送信されなかったことを意味します。このフィールドの使用方法の説明については、5.2節を参照してください。
Each extension object contains one or more 32-bit words, representing an object header and payload. All object headers share a common format. Figure 7 depicts the object header and payload.
各拡張オブジェクトは、オブジェクトのヘッダおよびペイロードを表す1つまたは複数の32ビット・ワードを含みます。すべてのオブジェクトのヘッダーは、共通フォーマットを共有しています。図7は、オブジェクトのヘッダおよびペイロードを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| // (Object payload) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Object Header and Payload
図7：オブジェクトのヘッダーとペイロード
An object header has the following fields:
オブジェクトヘッダは、以下のフィールドを有します。
Length: 16 bits
長さ：16ビット
Length of the object, measured in octets, including the object header and object payload.
オブジェクトの長さは、オブジェクトヘッダとオブジェクトペイロードを含む、オクテット単位で測定します。
Class-Num: 8 bits
クラスのNum：8ビット
Identifies object class.
オブジェクトのクラスを識別します。
C-Type: 8 bits
C型：8ビット
Identifies object sub-type.
識別は、サブタイプオブジェクト。
Upon receipt of an ICMP message, application software must check it for syntactic correctness. The extension checksum must be verified. Improperly specified length attributes and other syntax problems may result in buffer overruns.
ICMPメッセージを受信すると、アプリケーションソフトウェアは、構文上の正しさのためにそれをチェックする必要があります。拡張チェックサムが検証されなければなりません。不適切指定された長さの属性と他の構文問題は、バッファオーバーランをもたらすことができます。
This memo does not define the conditions under which a router sends an ICMP message. Therefore, it does not expose routers to any new denial-of-service attacks. Routers may need to limit the rate at which ICMP messages are sent.
このメモは、ルータはICMPメッセージを送信する条件を定義していません。したがって、それはどんな新しいサービス拒否攻撃にルーターを公開しません。ルータはICMPメッセージが送信される速度を制限する必要があるかもしれません。
The ICMP Extension Object header contains two 8-bit fields: The Class-Num identifies the object class, and the C-Type identifies the class sub-type. Sub-type values are defined relative to a specific object class value, and are defined per class.
ICMP拡張オブジェクトヘッダは、2つの8ビットフィールドを含む：クラス-numがオブジェクトクラスを識別し、そしてC型は、クラスのサブタイプを識別する。サブタイプ値は、特定のオブジェクトクラス値に対して定義され、クラスごとに定義されています。
IANA has established a registry of ICMP extension objects classes and class sub-types. There are no values assigned within this document to maintain. Object classes 0xF7 - 0xFF are reserved for private use. Object class values are assignable on a first-come-first-serve basis. The policy for assigning sub-type values should be defined in the document defining new class values.
IANAは、ICMPの拡張子のレジストリは、クラスとクラスのサブタイプのオブジェクト確立しています。維持するために、この文書の中に割り当てられた項目は適用されません。オブジェクトクラス0xF7 - 0xFFのは、私的使用のために予約されています。 Objectクラスの値は、先着順に割り当て可能です。サブタイプ値を割り当てるためのポリシーは、新しいクラスの値を定義する文書で定義されるべきです。
Thanks to Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt, and Sharon Chrisholm for their comments regarding this document.
この文書に関する彼らのコメントについてペッカNikander、マーク・人形、フェルナンドGont、ジョー・タッチ、クリスチャン・フォークト、そしてシャロンチザムに感謝します。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、エド。、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様について"、RFC 4443、2006年3月。
[UNNUMBERED] Atlas, A., Bonica, R., Rivers, JR., Shen, N., and E. Chen, "ICMP Extensions for Unnumbered Interfaces", Work in Progress, March 2007.
[アンナンバード]アトラス、A.、Bonica、R.、川、JR。、シェン、N.、およびE.チェン、 "アンナンバードインターフェイスのICMP拡張機能"、進歩、2007年3月に作業。
[MPLS-ICMP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for MultiProtocol Label Switching", Work in Progress, January 2007.
[MPLS-ICMP] Bonica、R.、ガン、D.、タッパン、D.、およびC. Pignataro、進歩、2007年1月の作業 "ICMP拡張機能は、マルチプロトコルラベルスイッチングのために"。
[ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[ATTACKS] Gont、F.、 "TCPに対するICMP攻撃"、進歩、2006年10月に作業。
[ROUTING-INST] Shen, N. and E. Chen, "ICMP Extensions for Routing Instances", Work in Progress, November 2006.
[ルーティングINST]シェン、N.とE.チェン、「ルーティングインスタンスのためのICMP拡張機能」、進歩、2006年11月に作業。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
Authors' Addresses
著者のアドレス
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
ロナルドP. Bonicaジュニパーネットワークスの2251年コーポレートパークドライブハーンドン、VA 20171米国
EMail: rbonica@juniper.net
メールアドレス：rbonica@juniper.net
Der-Hwa Gan Consultant
ファ - ガンコンサルタント
EMail: derhwagan@yahoo.com
メールアドレス：derhwagan@yahoo.com
Daniel C. Tappan Consultant
ダニエル・C.タッパンコンサルタント
EMail: Dan.Tappan@gmail.com
メールアドレス：Dan.Tappan@gmail.com
Carlos Pignataro Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 US
カルロスPignataroシスコシステムズ株式会社7025キットクリーク道路リサーチトライアングルパーク、ノースカロライナ州27709米国
EMail: cpignata@cisco.com
メールアドレス：cpignata@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。