Network Working Group A. Conta
Request for Comments: 4443 Transwitch
Obsoletes: 2463 S. Deering
Updates: 2780 Cisco Systems
Category: Standards Track M. Gupta, Ed.
Tropos Networks
March 2006
Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6).
このドキュメントは、ICMPv6の（インターネット制御メッセージプロトコル）で使用される制御メッセージのセットの形式について説明します。 ICMPv6のは、インターネットプロトコルバージョン6（IPv6）のためにインターネット制御メッセージプロトコルです。
Table of Contents
目次
1. Introduction ....................................................2
2. ICMPv6 (ICMP for IPv6) ..........................................3
2.1. Message General Format .....................................3
2.2. Message Source Address Determination .......................5
2.3. Message Checksum Calculation ...............................5
2.4. Message Processing Rules ...................................5
3. ICMPv6 Error Messages ...........................................8
3.1. Destination Unreachable Message ............................8
3.2. Packet Too Big Message ....................................10
3.3. Time Exceeded Message .....................................11
3.4. Parameter Problem Message .................................12
4. ICMPv6 Informational Messages ..................................13
4.1. Echo Request Message ......................................13
4.2. Echo Reply Message ........................................14
5. Security Considerations ........................................15
5.1. Authentication and Confidentiality of ICMP Messages .......15
5.2. ICMP Attacks ..............................................16
6. IANA Considerations ............................................17
6.1. Procedure for New ICMPV6 Type and Code Value Assignments ..17
6.2. Assignments for This Document .............................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................19
8. Acknowledgements ...............................................20
Appendix A - Changes since RFC 2463................................21
The Internet Protocol version 6 (IPv6) uses the Internet Control Message Protocol (ICMP) as defined for IPv4 [RFC-792], with a number of changes. The resulting protocol is called ICMPv6 and has an IPv6 Next Header value of 58.
変更の数と、のIPv4 [RFC-792]について定義されたとおり、インターネットプロトコルバージョン6（IPv6）は、インターネット制御メッセージプロトコル（ICMP）を使用します。得られたプロトコルは、ICMPv6のと呼ばれ、58のIPv6の次のヘッダ値を有しています。
This document describes the format of a set of control messages used in ICMPv6. It does not describe the procedures for using these messages to achieve functions like Path MTU discovery; these procedures are described in other documents (e.g., [PMTU]). Other documents may also introduce additional ICMPv6 message types, such as Neighbor Discovery messages [IPv6-DISC], subject to the general rules for ICMPv6 messages given in Section 2 of this document.
このドキュメントは、ICMPv6のに使用される制御メッセージのセットの形式について説明します。これは、パスMTUディスカバリのような機能を実現するために、これらのメッセージを使用するための手順を説明していません。これらの手順は、他の文書（例えば、[PMTU]）に記載されています。他の文書はまた、このドキュメントのセクション2で与えられたICMPv6メッセージのための一般的な規則に従う近隣探索メッセージ[たIPv6-DISC]、などの追加のICMPv6メッセージタイプを導入してもよいです。
Terminology defined in the IPv6 specification [IPv6] and the IPv6 Routing and Addressing specification [IPv6-ADDR] applies to this document as well.
IPv6仕様【のIPv6]とIPv6ルーティングとAddressing仕様〔のIPv6-ADDR]で定義された用語は、同様に、この文書に適用されます。
This document obsoletes RFC 2463 [RFC-2463] and updates RFC 2780 [RFC-2780].
この文書は、RFC 2463 [RFC-2463]とアップデートRFC 2780 [RFC-2780]を廃止します。
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 [RFC-2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC-2119]に記載されているように解釈されます。
ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics (ICMPv6 "ping"). ICMPv6 is an integral part of IPv6, and the base protocol (all the messages and behavior required by this specification) MUST be fully implemented by every IPv6 node.
ICMPv6の処理パケットで発生したエラーを報告するために、そのような診断（ICMPv6の「ピング」）のような他のインターネットレイヤ機能を実行するためにIPv6ノードによって使用されます。 ICMPv6のは、IPv6の不可欠な部分であり、ベースプロトコル（本明細書で必要とされるすべてのメッセージと動作）は、完全にすべてのIPv6ノードによって実装されなければなりません。
Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header. (This is different from the value used to identify ICMP for IPv4.)
すべてのICMPv6メッセージは、IPv6ヘッダと0個以上のIPv6拡張ヘッダが先行します。 ICMPv6のヘッダは、直前のヘッダ58の次ヘッダ値によって識別されます。 （これは、IPv4のためのICMPを識別するために使用される値とは異なります。）
The ICMPv6 messages have the following general format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Message Body +
| |
The type field indicates the type of the message. Its value determines the format of the remaining data.
タイプフィールドは、メッセージの種類を示します。その値は、残りのデータのフォーマットを決定します。
The code field depends on the message type. It is used to create an additional level of message granularity.
コードフィールドは、メッセージの種類に依存します。メッセージの粒度の追加レベルを作成するために使用されます。
The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header.
チェックサムフィールドは、ICMPv6メッセージとIPv6ヘッダの部分にデータの破損を検出するために使用されます。
ICMPv6 messages are grouped into two classes: error messages and informational messages. Error messages are identified as such by a zero in the high-order bit of their message Type field values. Thus, error messages have message types from 0 to 127; informational messages have message types from 128 to 255.
エラーメッセージと情報メッセージ：ICMPv6メッセージは、2つのクラスに分類されています。エラーメッセージは、そのメッセージタイプフィールド値の上位ビットにゼロによってそのように識別されます。したがって、エラーメッセージは0から127までのメッセージタイプを有します。情報メッセージは、128から255へのメッセージの種類を持っています。
This document defines the message formats for the following ICMPv6 messages:
このドキュメントは以下のICMPv6メッセージのメッセージ・フォーマットを定義します。
ICMPv6 error messages:
ICMPv6エラーメッセージ：
1 Destination Unreachable (see Section 3.1)
2 Packet Too Big (see Section 3.2)
3 Time Exceeded (see Section 3.3)
4 Parameter Problem (see Section 3.4)
100 Private experimentation 101 Private experimentation
100プライベート実験101プライベート実験
127 Reserved for expansion of ICMPv6 error messages
ICMPv6エラーメッセージの拡張のために予約127
ICMPv6 informational messages:
ICMPv6の情報メッセージ：
128 Echo Request (see Section 4.1)
129 Echo Reply (see Section 4.2)
200 Private experimentation 201 Private experimentation
200プライベート実験201プライベート実験
255 Reserved for expansion of ICMPv6 informational messages
ICMPv6の情報メッセージの拡張のために予約済み255
Type values 100, 101, 200, and 201 are reserved for private experimentation. They are not intended for general use. It is expected that multiple concurrent experiments will be done with the same type values. Any wide-scale and/or uncontrolled usage should obtain real allocations as defined in Section 6.
タイプ100、101、200、及び201は、プライベートの実験のために予約された値。これらは一般的な使用のために意図されていません。複数の同時実験は、同じ型の値を使用して行われることが期待されます。セクション6で定義されるような任意の大規模及び/又は制御されていない使用法は、実際の割り当てを取得する必要があります。
Type values 127 and 255 are reserved for future expansion of the type value range if there is a shortage in the future. The details of this are left for future work. One possible way of doing this that would not cause any problems with current implementations is that if the type equals 127 or 255, the code field should be used for the new assignment. Existing implementations would ignore the new assignments as specified in Section 2.4, (b). The new messages using these expanded type values could assign fields in the message body for its code values.
タイプは、将来的に不足がある場合127及び255は、タイプ値の範囲の将来の拡張のために予約された値。これの詳細は今後の作業のために残されています。現在の実装で問題が発生することはありませんこれを行う1つの可能な方法は、タイプが127または255に等しい場合、コードフィールドは、新規割り当てのために使用すべきであるということです。セクション2.4、（B）に指定されている既存の実装は、新しい割り当てを無視します。これらの拡大型の値を使用して、新しいメッセージは、そのコード値のためにメッセージ本文のフィールドを割り当てることができます。
Sections 3 and 4 describe the message formats for the ICMPv6 error message types 1 through 4 and informational message types 128 and 129.
セクション3と4は、4と情報メッセージ・タイプ128および129を介してICMPv6エラーメッセージタイプ1のメッセージフォーマットを記載しています。
Inclusion of, at least, the start of the invoking packet is intended to allow the originator of a packet that has resulted in an ICMPv6 error message to identify the upper-layer protocol and process that sent the packet.
、の包含は、少なくとも、自パケットの開始がパケットを送信した上位層プロトコルとプロセスを識別するために、ICMPv6エラーメッセージをもたらしたパケットの発信を可能にするように意図されています。
A node that originates an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows:
ICMPv6メッセージを発信したノードは、チェックサムを計算する前に、IPv6ヘッダーのソースおよび宛先IPv6アドレスの両方を決定しなければなりません。ノードが複数のユニキャストアドレスを持っている場合は、次のように、それはメッセージの送信元アドレスを選択する必要があります。
(a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address.
メッセージがノードのユニキャストアドレスの1つに送られたメッセージに対する応答である場合（A）、返信の送信元アドレスは、同じアドレスである必要があります。
(b) If the message is a response to a message sent to any other address, such as
（B）メッセージのような任意の他のアドレスに送信されたメッセージに対する応答である場合
- a multicast group address,
- an anycast address implemented by the node, or
- a unicast address that does not belong to the node
the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to select the source address for any other packet originated by the node, given the destination address of the packet. However, it MAY be selected in an alternative way if this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet.
ICMPv6パケットの送信元アドレスは、ノードに属するユニキャストアドレスであるに違いありません。アドレスは、パケットの宛先アドレスが与えられると、ノードによって発信され、他のパケットの送信元アドレスを選択するために使用される規則に従って選択されるべきです。これはのICMPv6パケットの宛先から到達可能なアドレスより多くの有益な選択につながる場合は、それは別の方法で選択することができます。
The checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message, starting with the ICMPv6 message type field, and prepended with a "pseudo-header" of IPv6 header fields, as specified in [IPv6, Section 8.1]. The Next Header value used in the pseudo-header is 58. (The inclusion of a pseudo-header in the ICMPv6 checksum is a change from IPv4; see [IPv6] for the rationale for this change.)
チェックサムは、ICMPv6メッセージタイプフィールドから開始して、全体のICMPv6メッセージの1の補数和の16ビットの1の補数であり、[IPv6のセクション8.1で指定されるように、IPv6ヘッダフィールドの「疑似ヘッダ」と付加しました]。疑似ヘッダで使用される次ヘッダ値は58（のICMPv6チェックサムに疑似ヘッダを含めることは、IPv4からの変化であり、この変更の根拠のために【のIPv6]を参照。）されています
For computing the checksum, the checksum field is first set to zero.
チェックサムを計算するために、チェックサムフィールドは、最初にゼロに設定されています。
Implementations MUST observe the following rules when processing ICMPv6 messages (from [RFC-1122]):
（[RFC-1122]から）ICMPv6メッセージを処理する際の実装は、以下の規則を守らなければなりません。
(a) If an ICMPv6 error message of unknown type is received at its destination, it MUST be passed to the upper-layer process that originated the packet that caused the error, where this can be identified (see Section 2.4, (d)).
未知のタイプのICMPv6エラーメッセージがその宛先で受信された場合（A）、これは同定することができるエラーの原因となったパケットを、発信上位層プロセスに渡さなければならない（セクション2.4、（d）を参照） 。
(b) If an ICMPv6 informational message of unknown type is received, it MUST be silently discarded.
未知のタイプのICMPv6の情報メッセージを受信した場合（B）、これを静かに捨てなければなりません。
(c) Every ICMPv6 error message (type < 128) MUST include as much of the IPv6 offending (invoking) packet (the packet that caused the error) as possible without making the error message packet exceed the minimum IPv6 MTU [IPv6].
（C）すべてのICMPv6エラーメッセージ（タイプ<128）は、エラーメッセージパケットが最小のIPv6 MTU [IPv6を】超えることなく、可能な限りのIPv6問題（起動）パケット（エラーの原因となったパケット）のできるだけ多くを含まなければなりません。
(d) In cases where the internet-layer protocol is required to pass an ICMPv6 error message to the upper-layer process, the upper-layer protocol type is extracted from the original packet (contained in the body of the ICMPv6 error message) and used to select the appropriate upper-layer process to handle the error.
インターネット層プロトコルは、上位層プロセスにICMPv6エラーメッセージを渡すために必要とされる場合には（D）は、上位層プロトコルタイプは、（ICMPv6エラーメッセージの本体に含まれている）元のパケットから抽出されエラーを処理するために適切な上位層処理を選択するために使用されます。
In cases where it is not possible to retrieve the upper-layer
protocol type from the ICMPv6 message, the ICMPv6 message is
silently dropped after any IPv6-layer processing. One example of
such a case is an ICMPv6 message with an unusually large amount
of extension headers that does not have the upper-layer protocol
type due to truncation of the original packet to meet the minimum
IPv6 MTU [IPv6] limit. Another example is an ICMPv6 message with
an ESP extension header for which it is not possible to decrypt
the original packet due to either truncation or the
unavailability of the state necessary to decrypt the packet.
(e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following:
（E）ICMPv6エラーメッセージは、次を受信した結果として発信してはいけません。
(e.1) An ICMPv6 error message.
（E.1）ICMPv6エラーメッセージ。
(e.2) An ICMPv6 redirect message [IPv6-DISC].
（E.2）アンのICMPv6メッセージ[たIPv6-DISC]をリダイレクトします。
(e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2) to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 (Section 3.4) reporting an unrecognized IPv6 option (see Section 4.2 of [IPv6]) that has the Option Type highest-order two bits set to 10).
（E.3）IPv6マルチキャストアドレス宛てのパケット。 （この規則には、2つの例外があります：パスMTUディスカバリがIPv6マルチキャストのために働くことを可能にする（1）パケット過大メッセージを（3.2節）は、および（2）パラメータ問題メッセージ、コード2（3.4）が認識されないを報告しますIPv6のオプション（[たIPv6]のセクション4.2を参照）オプションタイプ最上位10に設定された2つのビットを有します）。
(e.4) A packet sent as a link-layer multicast (the exceptions from e.3 apply to this case, too).
（E.4）リンク層マルチキャストとして送信されたパケットは（E.3から例外も、この場合に適用します）。
(e.5) A packet sent as a link-layer broadcast (the exceptions from e.3 apply to this case, too).
（E.5）リンク層ブロードキャストとして送信されたパケットは（E.3から例外も、この場合に適用します）。
(e.6) A packet whose source address does not uniquely identify a single node -- e.g., the IPv6 Unspecified Address, an IPv6 multicast address, or an address known by the ICMP message originator to be an IPv6 anycast address.
（E.6）、ソースアドレス一意に単一のノードを識別しないパケットは、 - 例えば、ICMPメッセージ発信者によって知られているIPv6の未指定アドレス、IPv6マルチキャストアドレス、又はアドレスは、IPv6エニーキャストアドレスです。
(f) Finally, in order to limit the bandwidth and forwarding costs incurred by originating ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it originates. This situation may occur when a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error messages.
（F）最後に、ICMPv6エラーメッセージを発信することによって発生し、帯域幅および転送コストを制限するために、IPv6ノードは、それが由来するICMPv6エラーメッセージのレートを制限しなければなりません。誤ったパケットのストリームを送信元が結果のICMPv6エラーメッセージに耳を傾けるに失敗した場合に、このような状況が発生することがあります。
Rate-limiting of forwarded ICMP messages is out of scope of this
specification.
A recommended method for implementing the rate-limiting function is a token bucket, limiting the average rate of transmission to N, where N can be either packets/second or a fraction of the attached link's bandwidth, but allowing up to B error messages to be transmitted in a burst, as long as the long-term average is not exceeded.
速度制限機能を実現するための推奨される方法は、Nが第二のいずれかのパケット/又は添付のリンクの帯域幅の一部であることができるNへの送信の平均速度を制限するトークンバケット、、が、であることBエラーメッセージまで可能長期平均を超えない限り、バーストで送信されます。
Rate-limiting mechanisms that cannot cope with bursty traffic (e.g., traceroute) are not recommended; for example, a simple timer-based implementation, allowing an error message every T milliseconds (even with low values for T), is not reasonable.
バーストトラフィック（例えば、トレースルート）に対応できない速度制限機構は推奨されません。例えば、エラーメッセージ（さえTに対して低い値を有する）すべてのTミリ秒を可能にする単純なタイマーベースの実装は、合理的ではありません。
The rate-limiting parameters SHOULD be configurable. In the case of a token-bucket implementation, the best defaults depend on where the implementation is expected to be deployed (e.g., a high-end router vs. an embedded host). For example, in a small/mid-size device, the possible defaults could be B=10, N=10/s.
レート制限のパラメータが設定可能であるべきです。トークンバケットの実装の場合、最良のデフォルト値は実装が展開されると予想される場所に依存する（例えば、埋め込まれたホスト対ハイエンドルータ）。例えば、小/中型装置において、可能なデフォルトはN = 10 / S、B = 10とすることができます。
NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR ORIGINATING ICMP ERROR MESSAGES.
注：（e）に基づく制限事項および（f）はORIGINATING ICMPエラーメッセージのこのドキュメントの別の場所にあるどのような要件を引き継ぐ優先ABOVE。
The following sections describe the message formats for the above ICMPv6 messages.
以下のセクションでは、上記の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6のフィールド：
Destination Address
宛先アドレス
Copied from the Source Address field of the invoking
packet.
ICMPv6 Fields:
ICMPv6のフィールド：
Type 1
タイプ1
Code 0 - No route to destination 1 - Communication with destination administratively prohibited 2 - Beyond scope of source address 3 - Address unreachable 4 - Port unreachable 5 - Source address failed ingress/egress policy 6 - Reject route to destination
コード0 - 先1へのルートがない - 先との通信が管理上禁止2 - アドレス到達不能4 - - ポート到達不能5 - ソースアドレス失敗した入口/出口政策6 - 送信元アドレス3の範囲を超えて目的地までのルートを拒否
Unused This field is unused for all code values. It must be initialized to zero by the originator and ignored by the receiver. Description
未使用このフィールドはすべてのコード値に対して未使用です。これは、創始によってゼロに初期化し、受信機で無視しなければなりません。説明
A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.)
宛先到達不能メッセージは、輻輳以外の理由で、その宛先アドレスに配信することができないパケットに応答して、ルータによって、または発信元ノード内のIPv6層によって生成されるべきです。 （パケットは、輻輳が原因でドロップされた場合にICMPv6メッセージを生成してはいけません。）
If the reason for the failure to deliver is lack of a matching entry in the forwarding node's routing table, the Code field is set to 0.
お届けする失敗の理由が転送ノードのルーティングテーブルに一致するエントリの不足がある場合は、Codeフィールドは0に設定されています。
(This error can occur only in nodes that do not hold a "default route" in their routing tables.)
（このエラーは、ルーティングテーブルに「デフォルトルート」を保持しないノードで発生する可能性があります。）
If the reason for the failure to deliver is administrative prohibition (e.g., a "firewall filter"), the Code field is set to 1.
お届けする失敗の理由は、行政の禁止（例えば、「ファイアウォールフィルタ」）であれば、コードフィールドが1に設定されています。
If the reason for the failure to deliver is that the destination is beyond the scope of the source address, the Code field is set to 2. This condition can occur only when the scope of the source address is smaller than the scope of the destination address (e.g., when a packet has a link-local source address and a global-scope destination address) and the packet cannot be delivered to the destination without leaving the scope of the source address.
お届けする失敗の理由は、宛先が送信元アドレスの範囲を超えて、コードフィールドは、送信元アドレスのスコープは、宛先アドレスの範囲よりも小さい場合にのみ、この状態が発生する可能性が2に設定されていることであるならば（例えば、パケットがリンクローカルソースアドレスとグローバルスコープの宛先アドレスを有する場合）、パケットは、送信元アドレスの範囲を逸脱することなく、先に配信することができません。
If the reason for the failure to deliver cannot be mapped to any of other codes, the Code field is set to 3. Example of such cases are an inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort.
配信に失敗した理由は、他のコードのいずれかにマッピングできない場合、コードフィールドは、このような場合の3例に設定されている対応するリンクアドレスにIPv6宛先アドレスを解決できない、またはリンク固有の問題ですある種の。
One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link.
宛先到達不能メッセージが符号3で送信されたもので、特定の場合には、同じリンクに割り当てられたサブネット内のアドレスを宛先ポイントツーポイントリンクからルータによって受信されたパケットに応答している（他の受信したルータ自身のアドレス）。そのような場合には、パケットが到着リンクに戻って転送されてはなりません。
A destination node SHOULD originate a Destination Unreachable message with Code 4 in response to a packet for which the transport protocol (e.g., UDP) has no listener, if that transport protocol has no alternative means to inform the sender.
宛先ノードは、トランスポートプロトコル（例えば、UDP）がNOリスナーを持たないためにパケットに応答してコード4と宛先到達不能メッセージを発信すべきである、そのトランスポートプロトコルが全く代替を持っていない場合、送信者に通知することを意味します。
If the reason for the failure to deliver is that the packet with this source address is not allowed due to ingress or egress filtering policies, the Code field is set to 5.
お届けする失敗の理由は、この送信元アドレスを持つパケットが原因入力または出力のフィルタリングポリシーに許可されていないということであれば、コードフィールドが5に設定されています。
If the reason for the failure to deliver is that the route to the destination is a reject route, the Code field is set to 6. This may occur if the router has been configured to reject all the traffic for a specific prefix.
お届けする失敗の理由は、目的地へのルートが拒否した経路であるということであるならば、Codeフィールドは、ルータが特定のプレフィックスのためのすべてのトラフィックを拒否するように設定されている場合、これが発生する可能性が6に設定されています。
Codes 5 and 6 are more informative subsets of code 1.
符号5及び6は、コード1の、より有益なサブセットです。
For security reasons, it is recommended that implementations SHOULD allow sending of ICMP destination unreachable messages to be disabled, preferably on a per-interface basis.
セキュリティ上の理由から、実装が、好ましくは、インターフェイスごとに、無効にするために、ICMP宛先到達不能メッセージの送信を許可することが推奨されます。
Upper Layer Notification
上位層の通知
A node receiving the ICMPv6 Destination Unreachable message MUST notify the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
関連するプロセスを識別することができるかどうかのICMPv6宛先到達不能メッセージを受信したノードは、（セクション2.4、（d）を参照）上位層プロセスに通知しなければなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6のフィールド：
Destination Address
宛先アドレス
Copied from the Source Address field of the invoking
packet.
ICMPv6 Fields:
ICMPv6のフィールド：
Type 2
タイプ2
Code Set to 0 (zero) by the originator and ignored by the receiver.
コードは、発信者によって0（ゼロ）に設定し、受信側では無視されます。
MTU The Maximum Transmission Unit of the next-hop link.
次ホップリンクのMTUザ・最大伝送単位。
Description
説明
A Packet Too Big MUST be sent by a router in response to a packet that it cannot forward because the packet is larger than the MTU of the outgoing link. The information in this message is used as part of the Path MTU Discovery process [PMTU].
パケット過大パケットが発信リンクのMTUよりも大きいため、それは転送できないことをパケットに応じて、ルータによって送らなければなりません。このメッセージの情報は、Path MTU Discoveryプロセス[PMTU]の一部として使用されます。
Originating a Packet Too Big Message makes an exception to one of the rules as to when to originate an ICMPv6 error message. Unlike other messages, it is sent in response to a packet received with an IPv6 multicast destination address, or with a link-layer multicast or link-layer broadcast address.
パケット過大メッセージを発信することはICMPv6エラーメッセージを発信する必要がある場合のルールのいずれかに例外を作ります。他のメッセージとは異なり、それは、またはリンク層マルチキャスト又はリンク層ブロードキャストアドレスとIPv6マルチキャスト宛先アドレスで受信されたパケットに応答して送信されます。
Upper Layer Notification
上位層の通知
An incoming Packet Too Big message MUST be passed to the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
関連するプロセスを識別することができれば、着信パケット過大メッセージ（セクション2.4、（d）を参照）上位層プロセスに渡さなければなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6のフィールド：
Destination Address Copied from the Source Address field of the invoking packet.
宛先アドレスは、呼び出し元のパケットの送信元アドレスフィールドからコピーされます。
ICMPv6 Fields:
ICMPv6のフィールド：
Type 3
タイプ3
Code 0 - Hop limit exceeded in transit 1 - Fragment reassembly time exceeded
コード0 - ホップ制限がトランジット1に超えて - フラグメント再アセンブリ時間超過
Unused This field is unused for all code values. It must be initialized to zero by the originator and ignored by the receiver.
未使用このフィールドはすべてのコード値に対して未使用です。これは、創始によってゼロに初期化し、受信機で無視しなければなりません。
Description
説明
If a router receives a packet with a Hop Limit of zero, or if a router decrements a packet's Hop Limit to zero, it MUST discard the packet and originate an ICMPv6 Time Exceeded message with Code 0 to the source of the packet. This indicates either a routing loop or too small an initial Hop Limit value.
ルータがゼロのホップ制限を持つパケットを受信した場合、ルータがゼロにパケットのホップ制限をデクリメント場合、または、それがパケットを破棄し、パケットの送信元にコード0でICMPv6の時間超過メッセージを発信する必要があります。これは、ルーティングループまたは小さすぎる初期ホップ制限値のいずれかを示しています。
An ICMPv6 Time Exceeded message with Code 1 is used to report fragment reassembly timeout, as specified in [IPv6, Section 4.5].
[IPv6のセクション4.5]で指定されるようにコード1のICMPv6時間超過メッセージは、フラグメント再構成タイムアウトを報告するために使用されます。
Upper Layer Notification
上位層の通知
An incoming Time Exceeded message MUST be passed to the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
関連するプロセスを識別することができれば、着信時間超過メッセージ（セクション2.4、（d）を参照）上位層プロセスに渡さなければなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6のフィールド：
Destination Address
宛先アドレス
Copied from the Source Address field of the invoking
packet.
ICMPv6 Fields:
ICMPv6のフィールド：
Type 4
タイプ4
Code 0 - Erroneous header field encountered 1 - Unrecognized Next Header type encountered 2 - Unrecognized IPv6 option encountered
コード0 - 未認識のIPv6オプションに遭遇 - 認識されない次のヘッダタイプ2に遭遇 - 誤ったヘッダーフィールドは1に遭遇しました
Pointer Identifies the octet offset within the invoking packet where the error was detected.
ポインタは、エラーが検出された呼び出しパケット内のオフセットのオクテットを識別します。
The pointer will point beyond the end of the ICMPv6
packet if the field in error is beyond what can fit
in the maximum size of an ICMPv6 error message.
Description
説明
If an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension headers such that it cannot complete processing the packet, it MUST discard the packet and SHOULD originate an ICMPv6 Parameter Problem message to the packet's source, indicating the type and location of the problem.
パケットを処理するIPv6ノードは、それがパケットの処理を完了できないようなIPv6ヘッダーまたは拡張ヘッダー内のフィールドに問題が見つかった場合、そのパケットを破棄しなければならないとタイプを示す、パケットのソースにICMPv6のパラメータ問題メッセージを発信すべきですそして、問題の場所。
Codes 1 and 2 are more informative subsets of Code 0.
コード1と2はコード0のより有益なサブセットです。
The pointer identifies the octet of the original packet's header where the error was detected. For example, an ICMPv6 message with a Type field of 4, Code field of 1, and Pointer field of 40 would indicate that the IPv6 extension header following the IPv6 header of the original packet holds an unrecognized Next Header field value.
ポインタは、エラーが検出された元のパケットのヘッダのオクテットを識別する。例えば、4のTypeフィールド、1のコードフィールド、及び40のポインタフィールドとICMPv6メッセージは、元のパケットのIPv6ヘッダーの次のIPv6拡張ヘッダが認識されていない次ヘッダフィールド値を保持していることを示すであろう。
Upper Layer Notification
上位層の通知
A node receiving this ICMPv6 message MUST notify the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
関連するプロセスを識別することができる場合は、このICMPv6メッセージを受信したノードは、（セクション2.4、（d）を参照）上位層プロセスに通知しなければなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
IPv6 Fields:
IPv6のフィールド：
Destination Address
宛先アドレス
Any legal IPv6 address.
法的なIPv6アドレス。
ICMPv6 Fields:
ICMPv6のフィールド：
Type 128
タイプ128
Code 0
コード0
Identifier An identifier to aid in matching Echo Replies to this Echo Request. May be zero.
エコーは、このエコー要求に応答マッチングを補助するための識別子を識別子。 0であってもよいです。
Sequence Number
シーケンス番号
A sequence number to aid in matching Echo Replies
to this Echo Request. May be zero.
Data Zero or more octets of arbitrary data.
データゼロまたは任意のデータのより多くのオクテット。
Description
説明
Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies. A node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes.
すべてのノードがエコー要求を受信し、エコー応答を対応する発信ICMPv6エコー応答機能を実装しなければなりません。ノードはまた、エコー要求を発信し、診断目的のために、エコー応答を受信するためのアプリケーション層インタフェースを実装する必要があります。
Upper Layer Notification
上位層の通知
Echo Request messages MAY be passed to processes receiving ICMP messages.
エコー要求メッセージは、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
IPv6 Fields:
IPv6のフィールド：
Destination Address
宛先アドレス
Copied from the Source Address field of the invoking
Echo Request packet.
ICMPv6 Fields:
ICMPv6のフィールド：
Type 129
タイプ129
Code 0
コード0
Identifier The identifier from the invoking Echo Request message.
呼び出しエコー要求メッセージから識別子を識別子。
Sequence Number
シーケンス番号
The sequence number from the invoking Echo Request
message.
Data The data from the invoking Echo Request message.
データ元のエコー要求メッセージからのデータ。
Description
説明
Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies. A node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes.
すべてのノードがエコー要求を受信し、エコー応答を対応する発信ICMPv6エコー応答機能を実装しなければなりません。ノードはまた、エコー要求を発信し、診断目的のために、エコー応答を受信するためのアプリケーション層インタフェースを実装する必要があります。
The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message.
ユニキャストエコー要求メッセージに応答して送信されたエコー応答の送信元アドレスは、エコー要求メッセージの宛先アドレスと同じでなければなりません。
An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received.
エコー応答は、IPv6マルチキャストまたはエニーキャストアドレスに送信されたエコー要求メッセージに応答して送信されるべきです。この場合には、返信の送信元アドレスは、エコー要求メッセージを受信したインタフェースに属するユニキャストアドレスでなければなりません。
The data received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message.
ICMPv6エコー要求メッセージで受信したデータは、ICMPv6エコー応答メッセージに完全かつ未修飾戻さなければなりません。
Upper Layer Notification
上位層の通知
Echo Reply messages MUST be passed to the process that originated an Echo Request message. An Echo Reply message MAY be passed to processes that did not originate the Echo Request message.
返信メッセージエコーエコー要求メッセージを発信したプロセスに渡さなければなりません。エコー応答メッセージは、Echo Requestメッセージを発信していないプロセスに渡すことができます。
Note that there is no limitation on the amount of data that can be put in Echo Request and Echo Reply Messages.
エコー要求とエコー応答メッセージに入れることができるデータ量に制限がないことに注意してください。
ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH] or IP Encapsulating Security Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol packet exchanges can be achieved using the IP Encapsulating Security Payload Header [IPv6-ESP].
ICMPプロトコルパケット交換はIP認証ヘッダ[たIPv6-AUTH]またはIPカプセル化セキュリティペイロードヘッダ[たIPv6-ESP]を使用して認証することができます。 ICMPプロトコルパケット交換のための機密性は、IPカプセル化セキュリティペイロードヘッダ[IPv6の-ESP]を使用して達成することができます。
[SEC-ARCH] describes the IPsec handling of ICMP traffic in detail.
[SEC-ARCH]は詳細にICMPトラフィックのIPsecの処理を記述します。
ICMP messages may be subject to various attacks. A complete discussion can be found in the IP Security Architecture [IPv6-SA]. A brief discussion of these attacks and their prevention follows:
ICMPメッセージは様々な攻撃を受ける可能性があります。完全な議論は、IPセキュリティアーキテクチャ[IPv6の-SA]で見つけることができます。簡単にこれらの攻撃の議論とその予防は次のとおりです。
1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source from that of the message originator. The protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message.
1. ICMPメッセージは、メッセージが、メッセージ発信とは異なるソースから来たと信じるに受信機を引き起こすことを意図したアクションを受ける可能性があります。この攻撃に対する保護は、ICMPメッセージにIPv6の認証メカニズム[IPv6の-AUTH]を適用することによって達成することができます。
2. ICMP messages may be subject to actions intended to cause the message or the reply to it to go to a destination different from that of the message originator's intention. The protection against this attack can be achieved by using the Authentication Header [IPv6-AUTH] or the Encapsulating Security Payload Header [IPv6-ESP]. The Authentication Header provides the protection against change for the source and the destination address of the IP packet. The Encapsulating Security Payload Header does not provide this protection, but the ICMP checksum calculation includes the source and the destination addresses, and the Encapsulating Security Payload Header protects the checksum. Therefore, the combination of ICMP checksum and the Encapsulating Security Payload Header provides protection against this attack. The protection provided by the Encapsulating Security Payload Header will not be as strong as the protection provided by the Authentication Header.
2. ICMPメッセージは、メッセージの発信者の意図とは異なる目的地に行くためにメッセージやそれへの応答を引き起こすことを意図したアクションを受ける可能性があります。この攻撃に対する保護は、認証ヘッダ[IPv6の-AUTH]またはカプセル化セキュリティペイロードヘッダ[IPv6の-ESP]を使用することによって達成することができます。認証ヘッダーは、ソースとIPパケットの宛先アドレスの変更に対する保護を提供します。カプセル化セキュリティペイロードヘッダはこの保護を提供していませんが、ICMPチェックサム計算は、送信元と送信先のアドレスが含まれており、カプセル化セキュリティペイロードヘッダのチェックサムを保護します。したがって、ICMPチェックサムとカプセル化セキュリティペイロードヘッダの組み合わせは、この攻撃に対する保護を提供します。カプセル化セキュリティペイロードヘッダによって提供される保護は、認証ヘッダによって提供される保護ほど強くはありません。
3. ICMP messages may be subject to changes in the message fields, or payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message protects against such actions.
3. ICMPメッセージは、メッセージフィールドの変更、またはペイロードを受けることができます。 ICMPメッセージの認証[IPv6の-AUTH]または暗号化[IPv6の-ESP]は、そのような行為から保護します。
4. ICMP messages may be used to attempt denial-of-service attacks by sending back to back erroneous IP packets. An implementation that correctly followed Section 2.4, paragraph (f), of this specification, would be protected by the ICMP error rate limiting mechanism.
4. ICMPメッセージは、誤ったIPパケットを背中合わせに送信することにより、サービス拒否攻撃を試みるために使用することができます。正確に2.4節、段落（f）に続い実装は、この仕様の、制限機構ICMPエラーレートによって保護されます。
5. The exception number 2 of rule e.3 in Section 2.4 gives a malicious node the opportunity to cause a denial-of-service attack to a multicast source. A malicious node can send a multicast packet with an unknown destination option marked as mandatory, with the IPv6 source address of a valid multicast source. A large number of destination nodes will send an ICMP Parameter Problem Message to the multicast source, causing a denial-of-service attack. The way multicast traffic is forwarded by the multicast routers requires that the malicious node be part of the correct multicast path, i.e., near to the multicast source. This attack can only be avoided by securing the multicast traffic. The multicast source should be careful while sending multicast traffic with the destination options marked as mandatory, because they can cause a denial-of-service attack to themselves if the destination option is unknown to a large number of destinations.
5.セクション2.4でのルールE.3の例外番号2は、悪意のあるノードマルチキャストソースへのDoS攻撃を引き起こす機会を与えてくれます。未知の宛先オプションが必須としてマークされて悪意のあるノードは有効なマルチキャストソースのIPv6送信元アドレスと、マルチキャストパケットを送信することができます。宛先ノードの多数のサービス拒否攻撃を引き起こす、マルチキャストソースにICMPパラメータ問題メッセージを送信します。マルチキャストトラフィックは、マルチキャストルータによって転送された方法は、悪意のあるノードがマルチキャストソースに近く、すなわち、正しいマルチキャスト経路の一部であることを必要とします。この攻撃は、マルチキャストトラフィックを確保することで回避することができます。必須としてマークされたデスティネーションオプションでマルチキャストトラフィックを送信しているときに、宛先オプションは、送信先の多数に知られていない場合、彼らは自分自身にDoS攻撃を引き起こす可能性があるので、マルチキャストソースは、注意する必要があります。
6. As the ICMP messages are passed to the upper-layer processes, it is possible to perform attacks on the upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. It is recommended that the upper layers perform some form of validation of ICMP messages (using the information contained in the payload of the ICMP message) before acting upon them. The actual validation checks are specific to the upper layers and are out of the scope of this specification. Protecting the upper layer with IPsec mitigates these attacks.
6. ICMPメッセージは上位層プロセスに渡されるように、ICMP [TCP攻撃]と上位層プロトコル（例えば、TCP）への攻撃を行うことが可能です。上位層がそれらに作用する前に、ICMPメッセージ（ICMPメッセージのペイロードに含まれる情報を使用して）の検証のいくつかのフォームを行うことが推奨されます。実際の検証チェックは、上位レイヤに固有のものであり、この仕様の範囲外です。 IPsecで上層を保護することは、これらの攻撃を軽減します。
ICMP error messages signal network error conditions that were encountered while processing an internet datagram. Depending on the particular scenario, the error conditions being reported might or might not get solved in the near term. Therefore, reaction to ICMP error messages may depend not only on the error type and code but also on other factors, such as the time at which the error messages are received, previous knowledge of the network error conditions being reported, and knowledge of the network scenario in which the receiving host is operating.
ICMPエラーメッセージは、インターネットデータグラムを処理している間に遭遇したネットワークのエラー状況を知らせます。特定のシナリオに応じて、報告されたエラー条件は、あるいは短期的には解決されないことがあります可能性があります。したがって、ICMPエラーメッセージに対する反応は、エラーのタイプとコードにもエラーメッセージが受信される時間などの他の要因だけでなく報告されているネットワークエラー状態の以前の知識に依存し、ネットワークの知識もよいです受信ホストが動作しているシナリオ。
The IPv6 ICMP header defined in this document contains the following fields that carry values assigned from IANA-managed name spaces: Type and Code. Code field values are defined relative to a specific Type value.
タイプとコード：この文書で定義されたIPv6 ICMPヘッダはIANAが管理する名前空間から割り当てられた値を運ぶ以下のフィールドが含まれています。コード・フィールド値は、特定のタイプの値に対して定義されています。
Values for the IPv6 ICMP Type fields are allocated using the following procedure:
IPv6のICMPタイプフィールドの値は、次の手順を使用して割り当てられます。
1. The IANA should allocate and permanently register new ICMPv6 type codes from IETF RFC publication. This is for all RFC types, including standards track, informational, and experimental status, that originate from the IETF and have been approved by the IESG for publication.
1. IANAは割り当て、永久にIETF RFC刊行物から新規のICMPv6タイプコードを登録しなければなりません。これは、それがIETFに由来し、公表のためにIESGによって承認されている、標準化トラック、情報、および実験的なステータスなど、すべてのRFCタイプのためです。
2. IETF working groups with working group consensus and area director approval can request reclaimable ICMPV6 type code assignments from the IANA. The IANA will tag the values as "reclaimable in future".
ワーキンググループのコンセンサスと地域ディレクターの承認を得て2 IETFワーキンググループは、IANAから再利用可能ICMPV6タイプコードの割り当てを要求することができます。 IANAは、「将来的に再利用可能」として値をタグ付けします。
The "reclaimable in the future" tag will be removed when an RFC is published that documents the protocol as defined in 1. This will make the assignment permanent and update the reference on the IANA web pages.
RFCは、これは、割り当ては永続的なものとIANAのWebページ上の参照を更新する1で定義されたプロトコルを文書化している公開されたときに、「将来的に再利用可能」タグが削除されます。
At the point where the ICMPv6 type values are 85% assigned, the IETF will review the assignments tagged "reclaimable in the future" and inform the IANA which ones should be reclaimed and reassigned.
ICMPv6のタイプの値が85％に割り当てられている時点で、IETFは、「将来的に再利用可能」タグ付きの割り当てを見直し、ものを再利用および再割り当てする必要があるIANAに通知します。
3. Requests for new ICMPv6 type value assignments from outside the IETF are only made through the publication of an IETF document, per 1 above. Note also that documents published as "RFC Editor contributions" [RFC-3978] are not considered IETF documents.
IETF外部から新規のICMPv6タイプ値の割り当て3.要求は、上記1あたり、IETF文書の公開を介して行われます。 「RFC Editorの貢献」[RFC-3978]として公開文書はIETFの文書を考慮されていないことにも注意してください。
The assignment of new Code values for the Type values defined in this document require standards action or IESG approval. The policy for assigning Code values for new IPv6 ICMP Types not defined in this document should be defined in the document defining the new Type values.
この文書で定義された型の値のための新しいコード値の割り当ては標準アクションまたはIESGの承認を必要とします。この文書で定義されていない新しいIPv6のICMPタイプのコード値を割り当てるためのポリシーは、新しいタイプの値を定義する文書で定義する必要があります。
The following has updated assignments located at:
以下は、次の場所の割り当てを更新しました：
http://www.iana.org/assignments/icmpv6-parameters
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／いｃｍｐｖ６ーぱらめてｒｓ
The IANA has reassigned ICMPv6 type 1 "Destination Unreachable" code 2, which was unassigned in [RFC-2463], to:
IANAはICMPv6のタイプ1 [RFC-2463]、の内の未割り当てた「到達不能宛先」コード2を、再割り当てました：
2 - Beyond scope of source address
2 - ソースアドレスの範囲を超え
The IANA has assigned the following two new codes values for ICMPv6 type 1 "Destination Unreachable":
IANAはICMPv6のタイプ1「宛先到達不能」のために、次の二つの新しいコード値が割り当てられています：
5 - Source address failed ingress/egress policy
6 - Reject route to destination
The IANA has assigned the following new type values:
IANAは、次の新しい型の値を割り当てています：
100 Private experimentation
101 Private experimentation
127 Reserved for expansion of ICMPv6 error messages
ICMPv6エラーメッセージの拡張のために予約127
200 Private experimentation 201 Private experimentation
200プライベート実験201プライベート実験
255 Reserved for expansion of ICMPv6 informational messages
ICMPv6の情報メッセージの拡張のために予約済み255
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[IPv6-DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
【のIPv6-DISC] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC-792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC-2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
、RFC 2463、1998年12月 "インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）" [RFC-2463]コンタ、A.、およびS.デアリング、。
[RFC-1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC-1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC-3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC-3978]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。
[RFC-2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC-2780]ブラドナーの、S.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC 2780、2000年3月。
[IPv6-ADDR] Hinden, R. and S. Deering, "Intpernet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6の-ADDR] HindenとR.とS.デアリング、 "Intpernetプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[PMTU] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PMTU]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPv6の-SA]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[IPv6-AUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[IPv6の-AUTH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4203, December 2005.
[IPv6の-ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4203、2005年12月。
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[SEC-ARCH]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[TCP-attack] Gont, F., "ICMP attacks against TCP", Work in Progress.
[TCP-攻撃] Gont、F.、 "TCPに対するICMP攻撃" が進行中で働いています。
The document is derived from previous ICMP documents of the SIPP and IPng working group.
文書はSIPPとIPngのワーキンググループの前のICMP文書から導出されます。
The IPng working group, and particularly Robert Elz, Jim Bound, Bill Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner, Dimitri Haskin, Bob Hinden, Jun-ichiro Itojun Hagino, Tatuya Jinmei, Brian Zill, Pekka Savola, Fred Templin, and Elwyn Davies (in chronological order) provided extensive review information and feedback.
IPngのワーキンググループ、特にロバート・エルツ、ジム・バウンド、ビル・シンプソン、トーマスNarten氏、チャーリー・リン、ビル・フィンク、スコット・ブラッドナー、ディミトリHaskin、ボブHindenと、6月-一郎いとぢゅん萩野、達也神明、ブライアンZill、ペッカSavola、フレッドテンプリン、及び（時系列順）エルウィン・デイヴィスは、広範なレビュー情報とフィードバックを提供しました。
Bob Hinden was the document editor for this document.
ボブHindenと、この文書の文書エディタでした。
Appendix A - Changes since RFC 2463
付録A - RFC 2463からの変更点
The following changes were made from RFC 2463:
次の変更は、RFC 2463で行われました。
- Edited the Abstract to make it a little more elaborate.
- それはもう少し手の込んだ作るために要約を編集。
- Corrected typos in Section 2.4, where references to sub-bullet e.2 were supposed to be references to e.3.
- サブ弾丸E.2への参照がE.3に言及することになったセクション2.4、中に誤字を修正しました。
- Removed the Timer-based and the Bandwidth-based methods from the example rate-limiting mechanism for ICMP error messages. Added Token-bucket based method.
- タイマベース除去し、ICMPエラーメッセージの例律速機構からの帯域に基づく方法。トークンバケットベースの方法を追加しました。
- Added specification that all ICMP error messages shall have exactly 32 bits of type-specific data, so that receivers can reliably find the embedded invoking packet even when they don't recognize the ICMP message Type.
- 彼らはICMPメッセージタイプを認識しない場合でも、受信機が確実に埋め込まれた呼び出しパケットを見つけることができるように、すべてのICMPエラーメッセージは、型固有のデータの正確32ビットを持たなければならない仕様を追加しました。
- In the description of Destination Unreachable messages, Code 3, added rule prohibiting forwarding of packets back onto point-to-point links from which they were received, if their destination addresses belong to the link itself ("anti-ping-ponging" rule).
- 彼らの宛先アドレスがリンク自体（「抗ピンポン」のルールに属している場合は宛先到達不能メッセージの説明では、コード3は、バックそれらが受信されたから、ポイントツーポイントリンク上にパケットの転送を禁止するルールを追加しました）。
- Added description of Time Exceeded Code 1 (fragment reassembly timeout).
- 時間の追加された記述は、コード1（フラグメント再構成タイムアウト）を超え。
- Added "beyond scope of source address", "source address failed ingress/egress policy", and "reject route to destination" messages to the family of "unreachable destination" type ICMP error messages (Section 3.1).
- 「送信元アドレスの範囲を超えて」を追加、「送信元アドレスは、入口/出口政策の失敗」、および「到達不能先」タイプICMPエラーメッセージ（3.1節）の家族へのメッセージ「を目的地までのルートを拒否する」。
- Reserved some ICMP type values for experimentation.
- 実験のためのいくつかのICMPタイプ値を予約。
- Added a NOTE in Section 2.4 that specifies ICMP message processing rules precedence.
- ICMPメッセージ処理ルールの優先順位を指定するセクション2.4で注意を追加しました。
- Added ICMP REDIRECT to the list in Section 2.4, (e) of cases in which ICMP error messages are not to be generated.
- ICMPエラーメッセージが生成されるされない例セクション2.4、（e）の中リストに追加ICMPリダイレクトします。
- Made minor editorial changes in Section 2.3 on checksum calculation, and in Section 5.2.
- チェックサムの計算上のセクション2.3であり、5.2節ではマイナーな編集上の変更を行いました。
- Clarified in Section 4.2, regarding the Echo Reply Message; the source address of an Echo Reply to an anycast Echo Request should be a unicast address, as in the case of multicast.
- エコー応答メッセージについては、4.2節で明らかに。エニーキャストエコー要求に対するエコー応答の送信元アドレスは、マルチキャストの場合のように、ユニキャストアドレスであるべきです。
- Revised the Security Considerations section. Added the use of the Encapsulating Security Payload Header for authentication. Changed the requirement of an option of "not allowing unauthenticated ICMP messages" to MAY from SHOULD.
- セキュリティの考慮事項のセクションを改訂。認証のためのカプセル化セキュリティペイロードヘッダーの使用を追加しました。 SHOULDからMAYに「未認証のICMPメッセージを許可しない」のオプションの要件を変更しました。
- Added a new attack in the list of possible ICMP attacks in Section 5.2.
- セクション5.2で可能なICMP攻撃のリストに新しい攻撃を追加しました。
- Separated References into Normative and Informative.
- 規範的で有益に分け参照。
- Added reference to RFC 2780 "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers". Also added a note that this document updates RFC 2780.
- RFC 2780「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」への参照を追加。また、この文書はRFC 2780を更新することを注記を追加しました。
- Added a procedure for new ICMPv6 Type and Code value assignments in the IANA Considerations section.
- IANAの考慮事項のセクションで新しいICMPv6のタイプとコード値の割り当てのための手順を追加しました。
- Replaced word "send" with "originate" to make it clear that ICMP packets being forwarded are out of scope of this specification.
- 置き換え単語がで「送信」「発信」、それは明確なICMPパケットが転送されることを確認するために、この仕様の範囲外です。
- Changed the ESP and AH references to the updated ESP and AH documents.
- 更新ESPとAHの文書にESPとAHの参照を変更しました。
- Added reference to the updated IPsec Security Architecture document.
- 更新されたIPsecセキュリティアーキテクチャ文書への参照を追加。
- Added a SHOULD requirement for allowing the sending of ICMP destination unreachable messages to be disabled.
- 無効にするICMP宛先到達不能メッセージの送信を可能にするためのSHOULD要件を追加しました。
- Simplified the source address selection of the ICMPv6 packet.
- のICMPv6パケットの送信元アドレス選択を簡素化。
- Reorganized the General Message Format (Section 2.1).
- 一般的なメッセージフォーマット（2.1節）改組。
- Removed the general packet format from Section 2.1. It refers to Sections 3 and 4 for packet formats now.
- セクション2.1から一般的なパケットフォーマットを削除しました。今では、パケットのフォーマットのためのセクション3と4を参照します。
- Added text about attacks to the transport protocols that could potentially be caused by ICMP.
- 潜在的にICMPが原因で発生することがトランスポートプロトコルへの攻撃に関する追加されたテキスト。
Authors' Addresses
著者のアドレス
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 USA
アレックス・コンタTranSwitch社株式会社3エンタープライズ・ドライブシェルトン、CT 06484 USA
EMail: aconta@txc.com
メールアドレス：aconta@txc.com
Stephen Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
スティーブンデアリングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Mukesh Gupta, Ed. Tropos Networks 555 Del Rey Avenue Sunnyvale, CA 94085
ムケシュ・グプタ、エド。 94085のTropos Networksの555デルレイAvenuaサニーベール、
Phone: +1 408-331-6889 EMail: mukesh.gupta@tropos.com
電話：+1 408-331-6889電子メール：mukesh.gupta@tropos.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。