[要約] RFC 4884は、複数のパートからなるメッセージをサポートするためにICMPを拡張するためのものです。その目的は、大きなメッセージを分割して送信し、再構築することで、ネットワーク上の制約を克服することです。
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
マルチパートメッセージをサポートするために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 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エラーメッセージを引き出すデータグラムの初期オクテットが含まれています。元のDatagramフィールドはさまざまな長さですが、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拡張オブジェクトを定義しません。すべての拡張オブジェクトが共有する拡張ヘッダーと共通のヘッダーのみを定義します。[NENSUMBERED]、[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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宛先到達不可能（type = 3）
- ICMPv4 Time Exceeded (type = 11)
- ICMPV4時間を超えた（タイプ= 11）
- ICMPv4 Parameter Problem (type = 12)
- ICMPV4パラメーターの問題（タイプ= 12）
- ICMPv6 Destination Unreachable (type = 1)
- icmpv6宛先到達不可能（type = 1）
- ICMPv6 Packet Too Big (type = 2)
- ICMPV6パケットが大きすぎる（タイプ= 2）
- ICMPv6 Time Exceeded (type = 3)
- icmpv6時間を超えた（タイプ= 3）
- ICMPv6 Parameter Problem (type = 4)
- ICMPV6パラメーター問題（Type = 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]は、「元のデータグラム」フィールドを拡張して、ICMPメッセージを最小IPv4再組み立てバッファーサイズ（つまり、576オクテット）を超えることなく、できるだけ多くのオクテットを含むように拡張します。RFC 4443は、ICMPV6メッセージの「元のデータグラム」フィールドを定義します。RFC 4443では、「元のデータグラム」フィールドには、ICMPメッセージに最小IPv6 MTU（つまり、1280オクテット）を超えることなく、常にできるだけ多くのオクテットが含まれていました。
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メッセージのそれぞれの6番目のオクテットは、将来の使用のために予約されていたため、このオクテットは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メッセージの5番目のオクテットは将来の使用のために予約されていたため、このオクテットは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.
すべてのフィールドの構文とセマンティクスは、RFC 792から変更されていません。ただし、2番目の単語に長さの属性が追加されます。長さの属性は、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.
すべてのフィールドの構文とセマンティクスは、RFC 4443から変更されていません。ただし、2番目の単語に長さの属性が追加されます。長さの属性は、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拡張構造は、セクション4に記載されている他のICMPメッセージのいずれかに追加されてはなりません。拡張機能は、これらのメッセージが長さの属性のスペースがないため、ICMPv6「パケット」および「パラメーター問題」メッセージについて定義されていません。
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拡張機能の非準拠バージョンを送信する場合があります。具体的には、これらの実装は、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
- 古典的なアプリケーション
- 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.
クラシックアプリケーションは、このメモで定義されている拡張機能を解析しません。それらは、「元のデータグラム」フィールドに関連付けられている長さの属性に鈍感です。
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.
非準拠の実装は、このメモで定義されている拡張機能を解析しますが、期限切れと宛先の到達不可能なメッセージとのみ併用します。「元のデータグラム」フィールドに正確に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メッセージを受信したときに、元のデータグラムフィールド[攻撃]のチェックサムを確認します。チェックサムが正しくない場合、TCPスタックはセキュリティ上の理由でICMPメッセージを破棄します。元のDatagramフィールドの後続のオクテットが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接続を動作させると、非常に不可能なシナリオが発生します。このシナリオは、TCPヘッダーが元のDatagramフィールドの128番目のオクテットまたはその向こうに現れ、拡張機能が有効なTCPヘッダーに近似した場合にのみ発生するため、非常にありそうにありません。
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-OCTET合計は、ICMPV4時間の最初の2つの単語の8オクテット、メッセージを超えた8オクテット、「オリジナルデータグラム」フィールドの128オクテット、ICMP拡張ヘッダーの4オクテット、1つのICMPオブジェクトヘッダーの4オクテットから派生します。拡張機能が存在する場合、これらのすべてのオクテットが必要になります。
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オクテット以上が含まれている場合、アプリケーションは137番目のオクテットを調べて、有効なICMPV4拡張ヘッダーを表すかどうかを判断する必要があります。有効な拡張機能ヘッダーを表すには、有効なバージョン番号とチェックサムを含める必要があります。有効なバージョン番号とチェックサムが含まれていない場合、アプリケーションはメッセージに拡張機能が含まれていないことを正しく決定します。
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についても同様の分析を実行できます。ただし、数値定数は必要に応じて変化します。
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メッセージを受信すると、「元のデータグラム」フィールドに関連付けられている長さ属性を調べます。長さの属性がゼロの場合、準拠アプリケーションはメッセージに拡張機能が含まれていないと判断する必要があります。
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アプリケーションが、長さの属性を指定しない十分に長い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]は、従来のNATデバイスがICMPメッセージ内の選択したフィールドを変更できるようにします。これらのフィールドには、上記の「元のデータグラム」フィールドが含まれます。ただし、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
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.
チェックサムフィールドは、チェックサムを計算するためにチェックサムフィールドをゼロに置き換え、データ構造の補完合計を補完します。全ゼロ値は、チェックサムが送信されなかったことを意味します。このフィールドの使用方法の説明については、セクション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
クラスナム：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は、私的使用のために予約されています。オブジェクトクラスの値は、先着順で割り当てることができます。サブタイプの値を割り当てるためのポリシーは、新しいクラス値を定義するドキュメントで定義する必要があります。
Thanks to Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt, and Sharon Chrisholm for their comments regarding this document.
Pekka Nikander、Mark Doll、Fernando Gont、Joe Touch、Christian Voigt、Sharon Chisholmに、この文書に関するコメントをありがとう。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Conta、A.、Deering、S。、およびM. Gupta、ed。、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、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.
[不自由な] Atlas、A.、Bonica、R.、Rivers、Jr。、Shen、N。、およびE. Chen、「Unnumbered Interfacesの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.、Gan、D.、Tappan、D.、およびC. Pignataro、「Multiprotocol Label SwitchingのICMP拡張」、2007年1月の進行中。
[ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[攻撃] Gont、F。、「TCPに対するICMP攻撃」、2006年10月、進行中の作業。
[ROUTING-INST] Shen, N. and E. Chen, "ICMP Extensions for Routing Instances", Work in Progress, November 2006.
[Routing-Inst] Shen、N。およびE. Chen、「ルーティングインスタンスの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
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).
著作権（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.
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エディター機能の資金は現在、インターネット協会によって提供されています。