RFC4884 日本語訳
4884 Extended ICMP to Support Multi-Part Messages. R. Bonica, D. Gan,D. Tappan, C. Pignataro. April 2007. (Format: TXT=42169 bytes) (Updates RFC0792, RFC4443) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Bonicaがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4884年の杜松はアップデートをネットワークでつなぎます: 792、4443D.ガンカテゴリ: 標準化過程コンサルタントD.タッパンコンサルタントC.PignataroシスコシステムズInc.2007年4月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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ビットを割り当てます。
Bonica, et al. Standards Track [Page 1] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[1ページ]RFC4884
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.
このメモはRFC792とRFC4443をアップデートします。
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
1. 序論…3 2. このドキュメントで中古のコンベンション…4 3. ICMPへの変化の概要…4 4. ICMP伸展性…4 4.1. ICMPv4の目的地手の届かない…7 4.2. 超えられていたICMPv4時間…8 4.3. ICMPv4パラメタ問題…8 4.4. ICMPv6の目的地手の届かない…9 4.5. 超えられていたICMPv6時間…9 4.6. 広げることができるICMPメッセージ…10 5. 遅れている互換性…10 5.1. 古典的なアプリケーションは拡大でICMPメッセージを受け取ります…12 5.2. 不従順なアプリケーションは拡大なしでICMPメッセージを受け取ります…12 5.3. 不従順なアプリケーションは対応する拡大でICMPメッセージを受け取ります…13 5.4. 対応するアプリケーションは拡大なしでICMPメッセージを受け取ります…14 5.5. 対応するアプリケーションは不従順な拡大でICMPメッセージを受け取ります…14 6. ネットワークアドレス変換との相互作用…14 7. ICMP拡大構造…15 8. ICMP拡大オブジェクト…16 9. セキュリティ問題…16 10. IANA問題…17 11. 承認…17 12. 参照…17 12.1. 標準の参照…17 12.2. 有益な参照…17
Bonica, et al. Standards Track [Page 2] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[2ページ]RFC4884
1. Introduction
1. 序論
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拡大オブジェクトも定義しません。 それはすべての拡大オブジェクトが共有する拡張ヘッダーと一般的なヘッダーだけを定義します。 [UNNUMBERED]、[ルート設定-INST]、および[MPLS-ICMP]はICMP Extension Objectのサンプル利用を提供します。
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 Time Expiredメッセージに情報を追加します。 この場合、多くの他のもののように、既存のICMP Time Expired Messageに情報を追加するのはパケットがTTL満了のため下げられるときはいつも、新しいメッセージを定義して、2つのメッセージを放つより望ましいです。
Bonica, et al. Standards Track [Page 3] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[3ページ]RFC4884
2. Conventions Used in This Document
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Summary of Changes to ICMP
3. ICMPへの変化の概要
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.
ICMPv4 Destination Unreachable、Time Exceeded、およびParameter ProblemメッセージにICMP Extension Structureを追加するかもしれません。
An ICMP Extension Structure MAY be appended to ICMPv6 Destination
Unreachable, and Time Exceeded messages.
ICMPv6 Destination Unreachable、およびTime ExceededメッセージにICMP Extension Structureを追加するかもしれません。
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 Extension Structureを追加して、その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.
ICMPv4メッセージにICMP Extension Structureを追加して、その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.
ICMPv6メッセージにICMP Extension Structureを追加して、その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メッセージは、SHOULDが示す未来にそれらがこの仕様に基づき定義された拡張機能をサポートするかどうかを定義しました。 すべての新しいメッセージが拡大をサポートするのは、お勧めです。
4. ICMP Extensibility
4. ICMP伸展性
RFC 792 defines the following ICMPv4 message types:
RFC792は以下のICMPv4メッセージタイプを定義します:
- Destination Unreachable
- 目的地手が届きません。
- Time Exceeded
- 超えられていた時間
Bonica, et al. Standards Track [Page 4] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[4ページ]RFC4884
- 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]はDestination Unreachableメッセージの「次のホップMTU」分野へのビットを予約します。
RFC 4443 defines the following ICMPv6 message types:
RFC4443は以下の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)
Bonica, et al. Standards Track [Page 5] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[5ページ]RFC4884
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メッセージが応答であるデータグラムの主な八重奏を表す「オリジナルのデータグラム」分野を含んでいます。 RFC792はICMPv4メッセージのために「オリジナルのデータグラム」分野を定義します。 RFC792では、「オリジナルのデータグラム」分野はオリジナルのデータグラムのIPヘッダーと次の8つの八重奏を含んでいます。 [RFC1812]は、できるだけ最小のIPv4 reassemblyバッファサイズ(すなわち、576の八重奏)を超えるICMPメッセージを引き起こさないで多くの八重奏を含むように「オリジナルのデータグラム」分野を広げています。 RFC4443はICMPv6メッセージのために「オリジナルのデータグラム」分野を定義します。 RFC4443では、「オリジナルのデータグラム」分野はいつもできるだけ最小の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 Extension Structureを追加すると、長さ属性は指定していなければなりません。
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
ICMPv4メッセージに関しては、長さ属性は32ビットの言葉を表します。 長さ属性が指定されるとき、「オリジナルのデータグラム」分野はゼロが最も近い32ビットの境界にそっと歩いたということであるに違いありません。 the
Bonica, et al. Standards Track [Page 6] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[6ページ]RFC4884
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メッセージの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 Extension Structureを追加して、そのICMPメッセージが「オリジナルのデータグラム」分野を含んでいると互換性を後方に獲得するために、「オリジナルのデータグラム」分野は少なくとも128の八重奏を含まなければなりません。 オリジナルのデータグラムが128の八重奏を含まなかったなら、「オリジナルのデータグラム」分野はゼロが128の八重奏にそっと歩いたということであるに違いありません。 (原理に関してセクション5.1を見てください。)
The following sub-sections depict length attribute as it has been introduced to selected ICMP messages.
それが選択されたICMPメッセージに取り入れられたとき、以下の小区分は長さ属性について表現します。
4.1. ICMPv4 Destination Unreachable
4.1. ICMPv4の目的地手が届きません。
Figure 1 depicts the ICMPv4 Destination Unreachable Message.
図1はICMPv4 Destination Unreachable Messageについて表現します。
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 |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| 長さ| 次のホップMTU*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オリジナルのデータグラムのインターネットのHeader+主な八重奏| | | | // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
すべての分野の構文と意味論はRFC792から変わりがありません。 しかしながら、長さ属性は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.
* Next-ホップMTU分野はすべての場合で必要ではありません。 それは表現されますが、それらのビットがこのメモにおける課題に有効でないことを示します。
Bonica, et al. Standards Track [Page 7] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[7ページ]RFC4884
4.2. ICMPv4 Time Exceeded
4.2. 超えられていたICMPv4時間
Figure 2 depicts the ICMPv4 Time Exceeded Message.
図2はICMPv4 Time Exceeded Messageについて表現します。
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 |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| 長さ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オリジナルのデータグラムのインターネットのHeader+主な八重奏| | | | // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
すべての分野の構文と意味論はRFC792から変わりがありません、2番目の単語に追加される長さ属性を除いて。 長さ属性は32ビットの単語で測定されたそっと歩いている「オリジナルのデータグラム」分野の長さを表します。
4.3. ICMPv4 Parameter Problem
4.3. ICMPv4パラメタ問題
Figure 3 depicts the ICMPv4 Parameter Problem Message.
図3はICMPv4 Parameter Problem Messageについて表現します。
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 |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 指針| 長さ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オリジナルのデータグラムのインターネットのHeader+主な八重奏| | | | // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
すべての分野の構文と意味論はRFC792から変わりがありません、2番目の単語に追加される長さ属性を除いて。 長さ属性は32ビットの単語で測定されたそっと歩いている「オリジナルのデータグラム」分野の長さを表します。
Bonica, et al. Standards Track [Page 8] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[8ページ]RFC4884
4.4. ICMPv6 Destination Unreachable
4.4. ICMPv6の目的地手が届きません。
Figure 4 depicts the ICMPv6 Destination Unreachable Message.
図4はICMPv6 Destination Unreachable Messageについて表現します。
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] |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットを呼び出す多くとして| 可能であるとしてのICMPv6パケット+なしで+| 最小の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.
すべての分野の構文と意味論はRFC4443から変わりがありません。 しかしながら、長さ属性は2番目の単語に追加されます。 長さ属性は64ビットの単語で測定されたそっと歩いている「オリジナルのデータグラム」分野の長さを表します。
4.5. ICMPv6 Time Exceeded
4.5. 超えられていたICMPv6時間
Figure 5 depicts the ICMPv6 Time Exceeded Message.
図5はICMPv6 Time Exceeded Messageについて表現します。
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] |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットを呼び出す多くとして| 可能であるとしてのICMPv6パケット+なしで+| 最小の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.
すべての分野の構文と意味論はRFC4443から変わりがありません、2番目の単語に追加される長さ属性を除いて。 長さ属性は64ビットの単語で測定されたそっと歩いている「オリジナルのデータグラム」分野の長さを表します。
Bonica, et al. Standards Track [Page 9] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[9ページ]RFC4884
4.6. ICMP Messages That Can Be Extended
4.6. 広げることができるICMPメッセージ
The ICMP Extension Structure MAY be appended to messages of the following types:
以下のタイプに関するメッセージにICMP Extension Structureを追加するかもしれません:
- 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.
セクション4で言及された他のICMPメッセージのいずれにもICMP Extension Structureを追加してはいけません。 拡大がICMPv6のために定義されなかった、「パケット、」 これらが通信するのでメッセージが長さ属性のためのスペースを欠くことにおける大き過ぎる「パラメタ問題。」
5. Backwards Compatibility
5. 遅れている互換性
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拡張子の不従順なバージョンを送るかもしれません。 明確に、これらの実装はTime ExceededとDestination UnreachableメッセージにICMP Extension Structureを追加するかもしれません。 彼らがこれをすると、必要なら、彼らはまさに128の八重奏にオリジナルのデータグラム、水増しでないのを表させます。 また、彼らは本書では説明されるようにチェックサムについて計算します。 しかしながら、彼らは、「オリジナルのデータグラム」分野に関連しているように長さ属性を指定しません。
It is assumed that ICMP implementations produced in the future will send ICMP extensions that are compliant with this specification.
将来生産されたICMP実装がこの仕様で対応である拡大をICMPに送ると思われます。
Bonica, et al. Standards Track [Page 10] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[10ページ]RFC4884
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.
不従順な実装はこのメモ、しかし、単にTime Expiredと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.
逆に互換性を示すために、Table1はそれぞれのアプリケーションカテゴリのメンバーがどう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 | | | | +----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+ | | 拡大がありません。| 不従順| 言いなりになる| | | | 拡大| 拡大| +----------------+----------------+----------------+----------------+ | クラシック| - | セクション5.1| セクション5.1| | アプリケーション| | | | | | | | | | 不従順| セクション5.2| - | セクション5.3| | アプリケーション| | | | | | | | | | 言いなりになる| セクション5.4| セクション5.5| - | | アプリケーション| | | | +----------------+----------------+----------------+----------------+
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メッセージタイプが「超えられていた時間」であると思います。
Bonica, et al. Standards Track [Page 11] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[11ページ]RFC4884
5.1. Classic Application Receives ICMP Message with Extensions
5.1. 古典的なアプリケーションは拡大で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.)
彼らがICMPメッセージを受け取るとき、いくつかのTCPスタックが元のデータグラム分野[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接続を作動させることを引き起こして。 このシナリオは、TCPヘッダーが八重奏において、または、元のデータグラム分野と次に、拡大がいつだけ有効なTCPヘッダーに近似するかに関する128番目の八重奏を超えて現れる場合にだけ起こるので、非常にありそうもないです。
5.2. Non-Compliant Application Receives ICMP Message with No Extensions
5.2. 不従順なアプリケーションは拡大なしでICMPメッセージを受け取ります。
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.
ICMPv4 Time Exceededメッセージの最初の2つの単語のための8つの八重奏、「オリジナルのデータグラム」分野への128の八重奏、ICMP Extension Headerのための4つの八重奏、および独身のICMP Objectヘッダーのための4つの八重奏から144八重奏の合計を得ます。 拡大が存在しているなら、これらの八重奏のすべてが必要でしょうに。
Bonica, et al. Standards Track [Page 12] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[12ページ]RFC4884
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 Extension Headerを表すかどうか決定する137番目の八重奏を調べなければなりません。 有効なExtension Headerを表すために、それは有効なバージョン番号とチェックサムを含まなければなりません。 有効なバージョン番号とチェックサムを含んでいないなら、アプリケーションは、メッセージが少しの拡大も含まないことを正しく決定します。
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 Extension StructureがTime Exceededメッセージの137番目の八重奏のときに始まると仮定します、そっと歩いている「オリジナルのデータグラム」メッセージを表す128八重奏の分野の後に。
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アプリケーションとの互換性を必要としない人は、より多くの八重奏を含むかもしれません。
Bonica, et al. Standards Track [Page 13] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[13ページ]RFC4884
5.4. Compliant Application Receives ICMP Message with No Extensions
5.4. 対応するアプリケーションは拡大なしで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.
対応するアプリケーションが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八重奏の「オリジナルのデータグラム」分野を仮定して。 アプリケーションが有効なバージョンとチェックサムを検出すると、それは拡大構造として続く八重奏を扱うでしょう。
6. Interaction with Network Address Translation
6. ネットワークアドレス変換との相互作用
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拡張子はNetwork Address Translationを妨げません。 [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実装がRFC3022の制限を踏み越えて、このメモで指定された長さ属性を上書きするのが想像できます。 NAT実装がゼロで長さ属性を上書きすることであったなら、結果として起こるパケットは不従順なICMP実装によって生成されたパケットから区別がつかなくなるでしょう。 パケットの詳細と遅れている互換性の議論に関してセクション5.5を見てください。
Bonica, et al. Standards Track [Page 14] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[14ページ]RFC4884
7. The ICMP Extension Structure
7. ICMP拡大構造
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 Extension Structureを提案します。
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.
Extension Structureはちょうど1Extension Headerを含んでいます、続いて、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 Extension Headerについて表現します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| (予約される)です。 | チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ICMP Extension Header
図6: ICMP拡張ヘッダー
The fields of the ICMP Extension Header are as follows:
ICMP Extension Headerの分野は以下の通りです:
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を見てください。
Bonica, et al. Standards Track [Page 15] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[15ページ]RFC4884
8. ICMP Extension Objects
8. ICMP拡大オブジェクト
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) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| クラスヌム| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | //(オブジェクトペイロード)//| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
オブジェクトサブタイプを特定します。
9. Security Considerations
9. セキュリティ問題
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メッセージが送られるレートを制限する必要があるかもしれません。
Bonica, et al. Standards Track [Page 16] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[16ページ]RFC4884
10. IANA Considerations
10. IANA問題
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 Extension Objectヘッダーは2つの8ビットの分野を含んでいます: Class-ヌムはオブジェクトのクラスを特定します、そして、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は私的使用目的で予約されます。 オブジェクト階級値は最初に最初に役立ちに来ているベースで「割り当て-可能」です。 サブタイプに値を割り当てるための方針は新しい階級値を定義するドキュメントで定義されるべきです。
11. Acknowledgments
11. 承認
Thanks to Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt, and Sharon Chrisholm for their comments regarding this document.
このドキュメントの彼らのコメントをペッカNikander、マークDoll、フェルナンドGont、ジョーTouch、クリスチャンのVoiqt、およびシャロンChrisholmをありがとうございます。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC0792] Postel, J., "Internet Control Message Protocol", STD
5, RFC 792, September 1981.
[RFC0792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)仕様を議定書の中で述べます」、RFC4443、2006年3月。
12.2. Informative References
12.2. 有益な参照
[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.、川(JR)、シン、N.、およびE.チェン、「無数のインタフェースのためのICMP拡張子」は進行中(2007年3月)で働いています。
Bonica, et al. Standards Track [Page 17] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[17ページ]RFC4884
[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、「MultiProtocolラベルの切り換えのためのICMP拡張子」が進行中(2007年1月)で働いています。
[ATTACKS] Gont, F., "ICMP attacks against TCP", Work in
Progress, October 2006.
[ATTACKS]Gont、F.、「TCPに対するICMP攻撃」、Progress、2006年10月のWork。
[ROUTING-INST] Shen, N. and E. Chen, "ICMP Extensions for Routing
Instances", Work in Progress, November 2006.
[ルーティング-INST] 「ルート設定インスタンスのためのICMP拡張子」というシン、N.、およびE.チェンは進歩、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)」、RFC3022、2001年1月。
Authors' Addresses
作者のアドレス
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
ロナルドP.Bonica杜松は米国でDriveハーンドン、2251の法人のParkヴァージニア 20171をネットワークでつなぎます。
EMail: rbonica@juniper.net
メール: rbonica@juniper.net
Der-Hwa Gan Consultant
Der-Hwaガンのコンサルタント
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シスコシステムズInc.7025キットクリーク道路リサーチトライアングル公園、NC27709米国
EMail: cpignata@cisco.com
メール: cpignata@cisco.com
Bonica, et al. Standards Track [Page 18] RFC 4884 Multi-Part ICMP Messages April 2007
Bonica、他 ICMPメッセージ2007年4月の複合の標準化過程[18ページ]RFC4884
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Bonica, et al. Standards Track [Page 19]
Bonica、他 標準化過程[19ページ]
一覧
スポンサーリンク
