RFC4443 日本語訳
4443 Internet Control Message Protocol (ICMPv6) for the InternetProtocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M.Gupta, Ed.. March 2006. (Format: TXT=48969 bytes) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループA.コンタの要求をネットワークでつないでください: 4443Transwitchは以下を時代遅れにします。 2463秒間デアリングアップデート: 2780年のシスコシステムズカテゴリ: 規格は2006年3月にエドM.グプタ、Troposネットワークを追跡します。
Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
インターネットプロトコルバージョン6(IPv6)仕様のためのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)
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 Internet Society (2006).
Copyright(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(インターネット・コントロール・メッセージ・プロトコル)で使用される1セットのコントロールメッセージの形式について説明します。 ICMPv6はインターネットプロトコルバージョン6(IPv6)のためのインターネット・コントロール・メッセージ・プロトコルです。
Conta, et al. Standards Track [Page 1] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[1ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
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
1. 序論…2 2. ICMPv6(IPv6のためのICMP)…3 2.1. メッセージ一般形式…3 2.2. メッセージ源アドレス決断…5 2.3. メッセージチェックサム計算…5 2.4. メッセージ処理は統治されます…5 3. ICMPv6エラーメッセージ…8 3.1. 目的地の手の届かないメッセージ…8 3.2. パケット、大き過ぎるメッセージ…10 3.3. 時間はメッセージを超えていました…11 3.4. パラメタ問題メッセージ…12 4. ICMPv6、通報メッセージ…13 4.1. 要求メッセージを反映してください…13 4.2. 応答メッセージを反映してください…14 5. セキュリティ問題…15 5.1. ICMPメッセージの認証と秘密性…15 5.2. ICMPは攻撃します…16 6. IANA問題…17 6.1. 新しいICMPV6タイプとコード値課題のための手順。17 6.2. このドキュメントのための課題…18 7. 参照…19 7.1. 標準の参照…19 7.2. 有益な参照…19 8. 承認…20 付録A--RFC2463以来の変化…21
1. Introduction
1. 序論
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.
インターネットプロトコルバージョン6(IPv6)はIPv4[RFC-792]のために定義されるようにインターネット・コントロール・メッセージ・プロトコル(ICMP)を使用します、多くの変化で。 結果として起こるプロトコルは、ICMPv6と呼ばれて、58のIPv6 Next Header値を持っています。
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で使用される1セットのコントロールメッセージの形式について説明します。 それはPath MTU発見のような機能を獲得するこれらのメッセージを使用するための手順について説明しません。 これらの手順は他のドキュメント(例えば、[PMTU])で説明されます。 また、他のドキュメントは追加ICMPv6メッセージタイプを導入するかもしれません、このドキュメントのセクション2で与えられたICMPv6メッセージのための総則を条件としたNeighborディスカバリーメッセージ[IPv6-DISC]などのように。
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]に基づき定義された用語はまた、このドキュメントに適用されます。
Conta, et al. Standards Track [Page 2] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[2ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
This document obsoletes RFC 2463 [RFC-2463] and updates RFC 2780 [RFC-2780].
このドキュメントは、RFC2463[RFC-2463]を時代遅れにして、RFC2780[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
2. ICMPv6 (ICMP for IPv6)
2. ICMPv6(IPv6のためのICMP)
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はIPv6ノードによって使用されて、処理パケットで遭遇する誤りを報告して、他のインターネット層の機能を実行します、病気の特徴などのように(ICMPv6は「確認します」)。 ICMPv6はIPv6の不可欠の部分です、そして、あらゆるIPv6ノードでベースプロトコル(すべてのメッセージと振舞いがこの仕様が必要である)を完全に実装しなければなりません。
2.1. Message General Format
2.1. メッセージ一般形式
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ヘッダーとゼロか、より多くのIPv6拡張ヘッダーによって先行されています。 ICMPv6ヘッダーはすぐに前のヘッダーの58のNext Header値によって特定されます。 (これは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 +
| |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + メッセージ本体+| |
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.
チェックサム分野は、IPv6ヘッダーのICMPv6メッセージと一部にデータの汚染を検出するのに使用されます。
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つのクラスに分類されます: エラーメッセージと通報メッセージ。 エラーメッセージはそれらのメッセージType分野値の高位のビットのゼロによってそういうものとして特定されます。 したがって、エラーメッセージには、0〜127までメッセージタイプがあります。 通報メッセージには、128〜255までメッセージタイプがあります。
Conta, et al. Standards Track [Page 3] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[3ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
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)
1 大きい(セクション3.2を見ます)3時間の目的地の手の届かない(セクション3.1を見る)2パケットも4パラメタ問題を超えていました(セクション3.3を見ます)。(セクション3.4を見ます)
100 Private experimentation
101 Private experimentation
100 個人的な実験101兵士の実験
127 Reserved for expansion of ICMPv6 error messages
127 ICMPv6エラーメッセージの拡張のために、予約されました。
ICMPv6 informational messages:
ICMPv6、通報メッセージ:
128 Echo Request (see Section 4.1)
129 Echo Reply (see Section 4.2)
128 エコー要求(セクション4.1を見る)129エコー・リプライ(セクション4.2を見ます)
200 Private experimentation
201 Private experimentation
200 個人的な実験201兵士の実験
255 Reserved for expansion of ICMPv6 informational messages
255はICMPv6の拡張のために通報メッセージを予約しました。
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はICMPv6エラーメッセージタイプのために1〜4にメッセージ・フォーマットについて説明します、そして、通報メッセージは128と129をタイプします。
Conta, et al. Standards Track [Page 4] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[4ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
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エラーメッセージをもたらしたパケットの生成元がパケットを送った上側の層のプロトコルとプロセスを特定するのを許容することを意図します。
2.2. Message Source Address Determination
2.2. メッセージ源アドレス決断
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ヘッダーでSourceとDestination IPv6 Addressesの両方を決定しなければなりません。 ノードに1つ以上のユニキャストアドレスがあるなら、以下のメッセージのSource Addressを選ばなければなりません:
(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.
(a) メッセージがノードのユニキャストアドレスの1つに送られたメッセージへの応答であるなら、回答のSource Addressはその同じアドレスであるに違いありません。
(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
- または、マルチキャストグループアドレス--ノードによって実装されたanycastアドレス、--それがするaユニキャストアドレスがノードに属さない
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パケットのSource Addressはノードに属すユニキャストアドレスであるに違いありません。 ノードによって溯源されたいかなる他のパケットのためのソースアドレスも選択するのに使用される規則に従って選んで、パケットの送付先アドレスを与える場合、SHOULDを扱ってください。 しかしながら、これがICMPv6パケットの目的地から届いているアドレスの、より有益な選択に通じるなら、それは代替の方法で選択されるかもしれません。
2.3. Message Checksum Calculation
2.3. メッセージチェックサム計算
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メッセージタイプ野原から始まって、IPv6ヘッダーフィールドの「疑似ヘッダー」と共にprependedされた全体のICMPv6メッセージの1の補数合計の16ビットの1の補数です、[IPv6、セクション8.1]で指定されるように。 疑似ヘッダーで使用されるNext Header値は58です。 (ICMPv6チェックサムでの疑似ヘッダーの包含はIPv4からの変化です; この変化のために原理に関して[IPv6]を見てください。)
For computing the checksum, the checksum field is first set to zero.
チェックサムを計算するために、チェックサム分野はゼロへの第一セットです。
2.4. Message Processing Rules
2.4. メッセージ処理規則
Implementations MUST observe the following rules when processing ICMPv6 messages (from [RFC-1122]):
ICMPv6メッセージ([RFC-1122]からの)を処理するとき、実装は以下の規則を守らなければなりません:
Conta, et al. Standards Track [Page 5] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[5ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
(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)).
(a) 目的地に未知のタイプに関するICMPv6エラーメッセージを受け取るなら、これを特定できる誤りを引き起こしたパケットを溯源した上側の層のプロセスにそれを通過しなければなりません。(セクション2.4((d)))を見てください。
(b) If an ICMPv6 informational message of unknown type is received,
it MUST be silently discarded.
未知のタイプの通報メッセージが(b) ICMPv6であるなら受け取られている、静かにそれを捨てなければなりません。
(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) エラーメッセージパケットに最小のIPv6 MTU[IPv6]を超えさせないで、あらゆるICMPv6エラーメッセージ(<128をタイプする)がパケット(誤りを引き起こしたパケット)を怒らせる(呼び出します)できるだけ多くの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.
(d) インターネット層のプロトコルが上側の層のプロセスにICMPv6エラーメッセージを通過するのに必要である場合では、上側の層のプロトコルタイプは、オリジナルのパケット(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.
ICMPv6メッセージから上側の層のプロトコルタイプを救済するのが可能でない場合では、ICMPv6メッセージはどんなIPv6-層の処理の後にも静かに下げられます。 そのような場合に関する1つの例が最小のIPv6 MTU[IPv6]制限を順守するために上側の層のプロトコルタイプがオリジナルのパケットのトランケーションのためいない異常に多量の拡張ヘッダーがいるICMPv6メッセージです。 別の例はパケットを解読するのに必要な状態のトランケーションか使用不能のどちらかのためオリジナルのパケットを解読するのが可能でない超能力拡張ヘッダーがいるICMPv6メッセージです。
(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つの例外があります: (1) Path MTU発見がIPv6マルチキャスト、および(2)のためにParameter Problem Messageを扱うのを許容するPacket Too Big Message(セクション3.2)、Option Typeの最も高いオーダーを2ビット持っている認識されていないIPv6オプション([IPv6]のセクション4.2を見る)を報告するCode2(セクション3.4)が10にセットしました。)
(e.4) A packet sent as a link-layer multicast (the exceptions
from e.3 apply to this case, too).
(e.4) パケットはリンクレイヤマルチキャストとして発信しました(また、e.3からの例外は本件に適用されます)。
Conta, et al. Standards Track [Page 6] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[6ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
(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) ソースアドレスが唯一ただ一つのノードを特定しないパケット--IPv6 anycastアドレスであることがICMPメッセージ創始者によって知られていた例えば、IPv6 Unspecified Address、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.
この仕様の範囲の外に転送されたICMPメッセージのレート制限があります。
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に制限しますが、エラーメッセージが炸裂で伝えられるのをBまで許容して、長期の平均が超えられていない限り。そこでは、Nは、付属リンクの帯域幅のパケット/秒か部分のどちらかであるかもしれません。
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.
burstyトラフィック(例えば、トレースルート)を切り抜けることができないレートを制限するメカニズムが推薦されません。 例えば、エラーメッセージを許容する簡単なタイマベースの実装、あらゆる、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.
パラメタSHOULDをレートで制限して、構成可能であってください。 トークンバケツ実装の場合では、最も良いデフォルトは実装が(例えば、ハイエンドルータ対埋め込まれたホスト)であると配布されると予想されるところによります。 例えば、小さいか中型のデバイスでは、可能なデフォルトはB=10、N=10/sであるかもしれません。
NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR ORIGINATING ICMP ERROR MESSAGES.
以下に注意してください。 (e)と(f)上の下の制限は本書ではICMPエラーメッセージを溯源するためのほかの場所でどんな要件の上でも優先します。
The following sections describe the message formats for the above ICMPv6 messages.
以下のセクションは上記のICMPv6メッセージのためにメッセージ・フォーマットについて説明します。
Conta, et al. Standards Track [Page 7] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[7ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
3. ICMPv6 Error Messages
3. ICMPv6エラーメッセージ
3.1. Destination Unreachable Message
3.1. 送信不可能メッセージ
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] |
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[IPv6]を超えています。|
IPv6 Fields:
IPv6分野:
Destination Address
送付先アドレス
Copied from the Source Address field of the invoking
packet.
呼び出しパケットのSource Address分野から、コピーされます。
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へのルートがありません--目的地とのコミュニケーションは行政上ソースアドレス3の範囲を超えて2を禁止しました--手の届かない4を扱ってください--手の届かない5を移植してください--ソースアドレスはイングレス/出口方針6に失敗しました--目的地にルートを拒絶してください。
Unused This field is unused for all code values.
It must be initialized to zero by the originator
and ignored by the receiver.
Description
すべてのコード値において、未使用のThis分野は未使用です。 それは、創始者がゼロに初期化しなければならなくて、受信機で. 記述を無視しました。
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.)
混雑以外の理由による送付先アドレスに提供できないパケットに対応したSHOULDがルータによって生成されるか、または起因するノードでIPv6で層にするというDestination Unreachableメッセージ。 (パケットが混雑のため下げられるなら、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に設定されます。
Conta, et al. Standards Track [Page 8] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[8ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
(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.
配送しないことの理由が管理禁止(例えば、「ファイアウォールフィルタ」)であるなら、Code分野は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.
配送しないことの理由が目的地がソースアドレスの範囲を超えているということであるなら、Code分野は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.
配送しないことの理由を他のコードのどれかに写像できないなら、Code分野は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.
Destination Unreachableメッセージがコード3と共に送られるある特定の場合はルータによってその同じリンク(受信ルータの自己のアドレスの1つを除いた)に割り当てられたサブネットの中でアドレスに運命づけられたポイントツーポイント接続から受け取られたパケットに対応しています。 このような場合には、到着リンクにパケットを送って戻してはいけません。
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.
目的地ノードSHOULDはCode4と共にトランスポート・プロトコル(例えば、UDP)にはリスナーが全くいないパケットに対応してDestination Unreachableメッセージを溯源します、そのトランスポート・プロトコルに送付者に知らせるどんな代替の手段もないなら。
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.
配送しないことの理由がこのソースアドレスがあるパケットが方針をフィルターにかけるイングレスか出口のため許容されていないということであるなら、Code分野は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.
安全保障上の理由で、実装SHOULDがICMP送信不可能メッセージの発信を無効にさせるのは、お勧めです、望ましくは1インタフェースあたり1個のベースで。
Conta, et al. Standards Track [Page 9] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[9ページ]RFC4443ICMPv6(IPv6のための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 Destination Unreachableメッセージを受け取るノードは上側の層のプロセスに通知しなければなりません。(セクション2.4((d)))を見てください。
3.2. Packet Too Big Message
3.2. パケット、大き過ぎるメッセージ
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] |
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットを呼び出す多くとして| 可能であるとしてのICMPv6パケット+なしで+| 最小のIPv6 MTU[IPv6]を超えています。|
IPv6 Fields:
IPv6分野:
Destination Address
送付先アドレス
Copied from the Source Address field of the invoking
packet.
呼び出しパケットのSource Address分野から、コピーされます。
ICMPv6 Fields:
ICMPv6分野:
Type 2
2をタイプしてください。
Code Set to 0 (zero) by the originator and ignored by the
receiver.
創始者であって受信機で無視されることで0(ゼロ)にSetをコード化してください。
MTU The Maximum Transmission Unit of the next-hop link.
次のホップリンクのMTU Maximum Transmission Unit。
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より大きいので、ルータはそれが進めることができないパケットに対応してPacket Too Bigを送らなければなりません。 このメッセージの情報はPath MTUディスカバリープロセス[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.
Packet Too Big Messageを溯源すると、いつ起因するかに関する規則の1つへの例外はICMPv6エラーメッセージにします。 他のメッセージと異なって、IPv6マルチキャスト送付先アドレス、リンクレイヤマルチキャストまたはリンク層ブロードキャストアドレスで受け取られたパケットに対応してそれを送ります。
Conta, et al. Standards Track [Page 10] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[10ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
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)).
関連プロセスを特定できるなら、入って来るPacket Too Bigメッセージを上側の層のプロセスに通過しなければなりません。(セクション2.4((d)))を見てください。
3.3. Time Exceeded Message
3.3. 時間はメッセージを超えていました。
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] |
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[IPv6]を超えています。|
IPv6 Fields:
IPv6分野:
Destination Address
Copied from the Source Address field of the invoking
packet.
呼び出しパケットのSource Address分野からの目的地Address Copied。
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.
すべてのコード値において、未使用のThis分野は未使用です。 それを創始者によってゼロに初期化されて、受信機で無視しなければなりません。
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.
ルータがゼロのHop Limitと共にパケットを受けるか、またはルータがパケットのHop Limitをゼロまで減少させるなら、それは、Code0と共にパケットの源にパケットを捨てて、ICMPv6 Time Exceededメッセージを溯源しなければなりません。 これはルーティング輪か小さ過ぎる初期のHop Limit値のどちらかを示します。
An ICMPv6 Time Exceeded message with Code 1 is used to report fragment reassembly timeout, as specified in [IPv6, Section 4.5].
Code1があるICMPv6 Time Exceededメッセージは断片再アセンブリタイムアウトを報告するのに使用されます、[IPv6、セクション4.5]で指定されるように。
Conta, et al. Standards Track [Page 11] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[11ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
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)).
関連プロセスを特定できるなら、入って来るTime Exceededメッセージを上側の層のプロセスに通過しなければなりません。(セクション2.4((d)))を見てください。
3.4. Parameter Problem Message
3.4. パラメタ問題メッセージ
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] |
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[IPv6]を超えています。|
IPv6 Fields:
IPv6分野:
Destination Address
送付先アドレス
Copied from the Source Address field of the invoking
packet.
呼び出しパケットのSource Address分野から、コピーされます。
ICMPv6 Fields:
ICMPv6分野:
Type 4
4をタイプしてください。
Code 0 - Erroneous header field encountered
1 - Unrecognized Next Header type encountered
2 - Unrecognized IPv6 option encountered
コード0--誤ったヘッダーフィールドは認識されていないNext Headerタイプが2に遭遇したという認識されていないIPv6オプションが遭遇した1に遭遇しました。
Pointer Identifies the octet offset within the
invoking packet where the error was detected.
誤りが検出されたところで八重奏が呼び出しパケットの中で相殺した指針Identifies。
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.
間違い分野がICMPv6エラーメッセージの最大サイズをうまくはめ込むことができることを超えていると、指針はICMPv6パケットの端のときに指すでしょう。
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ヘッダーか拡張ヘッダーの分野に関する問題を見つけるなら、パケットを捨てなければなりません、そして、SHOULDはパケットのソースにICMPv6 Parameter Problemメッセージを溯源します、問題のタイプと位置を示して。
Conta, et al. Standards Track [Page 12] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[12ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
Codes 1 and 2 are more informative subsets of Code 0.
コード1と2はCode0の、より有益な部分集合です。
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のCode分野、および40のPointer分野があるICMPv6メッセージは、オリジナルのパケットのIPv6ヘッダーについて来るIPv6拡張ヘッダーが認識されていないNext Header分野価値を保持するのを示すでしょう。
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)))を見てください。
4. ICMPv6 Informational Messages
4. ICMPv6、通報メッセージ
4.1. Echo Request Message
4.1. エコー要求メッセージ
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 ...
+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+-
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.
合っているEcho RepliesでこのEcho Requestに支援する識別子An識別子。 ゼロであるかもしれません。
Conta, et al. Standards Track [Page 13] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[13ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
Sequence Number
一連番号
A sequence number to aid in matching Echo Replies
to this Echo Request. May be zero.
合っているEcho RepliesでこのEcho Requestに支援する一連番号。 ゼロであるかもしれません。
Data Zero or more octets of arbitrary data.
任意のデータのデータZeroか、より多くの八重奏。
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.
あらゆるノードがEcho Requestsを受けて、対応するEcho Repliesを溯源するICMPv6 Echo応答者機能を実装しなければなりません。 またEcho Requestsを溯源して、Echo Repliesを受ける診断目的のためにSHOULDが応用層インターフェースを実装するノード。
Upper Layer Notification
上側の層の通知
Echo Request messages MAY be passed to processes receiving ICMP messages.
エコーRequestメッセージはICMPメッセージを受け取るプロセスに通過されるかもしれません。
4.2. Echo Reply Message
4.2. エコー応答メッセージ
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 ...
+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+-
IPv6 Fields:
IPv6分野:
Destination Address
送付先アドレス
Copied from the Source Address field of the invoking
Echo Request packet.
呼び出しているEcho RequestパケットのSource Address分野から、コピーされています。
ICMPv6 Fields:
ICMPv6分野:
Type 129
129をタイプしてください。
Code 0
コード0
Identifier The identifier from the invoking Echo Request message.
呼び出しているEcho Requestからの識別子が通信させる識別子。
Conta, et al. Standards Track [Page 14] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[14ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
Sequence Number
一連番号
The sequence number from the invoking Echo Request
message.
呼び出しているEcho Requestメッセージからの一連番号。
Data The data from the invoking Echo Request message.
呼び出しているEcho Requestからのデータが通信させるデータ。
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.
あらゆるノードがEcho Requestsを受けて、対応するEcho Repliesを溯源するICMPv6 Echo応答者機能を実装しなければなりません。 またEcho Requestsを溯源して、Echo Repliesを受ける診断目的のためにSHOULDが応用層インターフェースを実装するノード。
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.
ユニキャストEcho Requestメッセージに対応して送られたEcho ReplyのソースアドレスはそのEcho Requestメッセージの送付先アドレスと同じであるに違いありません。
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.
Echo Reply SHOULDはIPv6マルチキャストに送られたEcho Requestメッセージに対応して送るか、またはアドレスをanycastします。 この場合、回答のソースアドレスはEcho Requestメッセージが受け取られたインタフェースに属すユニキャストアドレスであるに違いありません。
The data received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message.
ICMPv6 Echo Requestメッセージに受け取られたデータは、完全に返されて、ICMPv6 Echo Replyメッセージで変更されているはずがありません。
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メッセージを溯源したプロセスにエコーReplyメッセージを通過しなければなりません。 Echo ReplyメッセージはEcho Requestメッセージを溯源しなかったプロセスに通過されるかもしれません。
Note that there is no limitation on the amount of data that can be put in Echo Request and Echo Reply Messages.
制限が全くEcho RequestとEcho Reply Messagesに入れることができるデータ量にないことに注意してください。
5. Security Considerations
5. セキュリティ問題
5.1. Authentication and Confidentiality of ICMP Messages
5.1. ICMPメッセージの認証と秘密性
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].
IP Authentication Header[IPv6-AUTH]かIP Encapsulating Security有効搭載量Header[IPv6-超能力]を使用することでICMPプロトコルパケット交換を認証できます。 ICMPがパケット交換について議定書の中で述べるので、IP Encapsulating Security有効搭載量Header[IPv6-超能力]を使用することで秘密性を達成できます。
[SEC-ARCH] describes the IPsec handling of ICMP traffic in detail.
[SEC-ARCH]は詳細にICMPトラフィックのIPsec取り扱いについて説明します。
Conta, et al. Standards Track [Page 15] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[15ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
5.2. ICMP Attacks
5.2. ICMP攻撃
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 Security Architecture[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メッセージは受信機が、メッセージがメッセージ創始者のものからの異なったソースから来たと信じていることを引き起こすことを意図する動作を受けることがあるかもしれません。 IPv6 Authenticationメカニズム[IPv6-AUTH]をICMPメッセージに適用することによって、この攻撃に対する保護を達成できます。
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メッセージはメッセージかそれに関する回答がメッセージ創始者の意志のものと異なった目的地に行くことを引き起こすことを意図する動作を受けることがあるかもしれません。 Authentication Header[IPv6-AUTH]かEncapsulating Security有効搭載量Header[IPv6-超能力]を使用することによって、この攻撃に対する保護を達成できます。 Authentication HeaderはIPパケットのソースと送付先アドレスに変化に対する保護を提供します。 ICMPチェックサム計算はソースと送付先アドレスを含んでいます、そして、Encapsulating Security有効搭載量Headerはこの保護を提供しませんが、Encapsulating Security有効搭載量Headerはチェックサムを保護します。 したがって、ICMPチェックサムとEncapsulating Security有効搭載量Headerの組み合わせはこの攻撃に対する保護を提供します。 Encapsulating Security有効搭載量Headerによって提供された保護はAuthentication Headerによって提供された保護ほど強くないでしょう。
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-超能力]がそのような動作から守ります。
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
5. セクション2.4における、規則e.3の例外No.2はマルチキャストソースにサービス不能攻撃を引き起こす機会を悪意があるノードに与えます。 未知の目的地オプションが義務的であるとしてマークされている状態で、悪意があるノードはマルチキャストパケットを送ることができます、有効なマルチキャストソースのIPv6ソースアドレスで。 多くの目的地ノードがマルチキャストソースにICMP Parameter Problem Messageを送るでしょう、サービス不能攻撃を引き起こして。 マルチキャストルータでマルチキャストトラフィックを進める方法は、悪意があるノードが正しさの一部であることを必要とします。
Conta, et al. Standards Track [Page 16] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[16ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
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.
すなわち、マルチキャストソースに、近いマルチキャスト経路。 マルチキャストがトラフィックであると機密保護することによって、この攻撃を避けることができるだけです。 マルチキャストソースは目的地オプションが義務的であるとしてマークされている状態でマルチキャストトラフィックを送る間、慎重であるはずです、多くの目的地において、目的地オプションが未知であるなら自分たちにサービス不能攻撃を引き起こす場合があるので。
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エラーメッセージへの反応を誤りタイプとコードに依存するだけではなく、他の要素にも依存するかもしれません、エラーメッセージが報告されるネットワークエラー条件に関する受け取られていて、前の知識と、受信ホストが働いているネットワークシナリオに関する知識である時などのように。
6. IANA Considerations
6. IANA問題
6.1. Procedure for New ICMPV6 Type and Code Value Assignments
6.1. 新しいICMPV6タイプとコード値課題のための手順
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によって管理された名前空間から割り当てられた値を運ぶ以下の分野を含んでいます: タイプとコード。 コード分野値は特定のType値に比例して定義されます。
Values for the IPv6 ICMP Type fields are allocated using the following procedure:
以下の手順を用いることでIPv6 ICMP Type分野への値を割り当てます:
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タイプコードを割り当てて、永久に、示すはずです。 これはすべてのRFCタイプのためのものです、標準化過程、IETFから発して、公表のためにIESGによって承認された情報の、そして、実験している状態を含んでいて。
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ワーキンググループは、reclaimable ICMPV6がIANAからコード課題をタイプするよう要求できます。 IANAは「未来の開墾可能」として値にタグ付けをするでしょう。
Conta, et al. Standards Track [Page 17] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[17ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
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.
1で定義されるようにプロトコルを記録するRFCを発行するとき、「未来の開墾可能」タグを取り除くでしょう。 これは、課題を永久的にして、IANAウェブページで参照をアップデートするでしょう。
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.
3. IETFドキュメントの公表を通してIETFの外からの新しいICMPv6タイプ値の課題を求める要求をするだけです、上の1単位で。 また、「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.
本書では定義されたType値のための新しいCode値の課題は規格動作かIESG承認を必要とします。 本書では定義されなかった新しいIPv6 ICMP Typesのために値をCodeに割り当てるための方針は新しいType値を定義するドキュメントで定義されるべきです。
6.2. Assignments for This Document
6.2. このドキュメントのための課題
The following has updated assignments located at:
以下は以下に位置した課題をアップデートしました。
http://www.iana.org/assignments/icmpv6-parameters
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つの「目的地手の届かない」コード2をタイプさせます。(それは、[RFC-2463]で割り当てられませんでした)。
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のために以下の2つの新法に値を割り当てた、「目的地手の届かない」:
5 - Source address failed ingress/egress policy
6 - Reject route to destination
5(ソースアドレスの失敗したイングレス/出口方針6)は目的地にルートを拒絶します。
The IANA has assigned the following new type values:
IANAは以下の新しいタイプ値を割り当てました:
100 Private experimentation
101 Private experimentation
100 個人的な実験101兵士の実験
127 Reserved for expansion of ICMPv6 error messages
127 ICMPv6エラーメッセージの拡張のために、予約されました。
200 Private experimentation
201 Private experimentation
200 個人的な実験201兵士の実験
Conta, et al. Standards Track [Page 18] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[18ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
255 Reserved for expansion of ICMPv6 informational messages
255はICMPv6の拡張のために通報メッセージを予約しました。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[IPv6-DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[IPv6-ディスク]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC-792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、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] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
[RFC-1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC-1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC-3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3978, March 2005.
[RFC-3978] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、2005年3月。
7.2. Informative References
7.2. 有益な参照
[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.、および「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」、BCP37、RFC2780(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)アドレッシング体系」、RFC3513、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.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPv6-SA] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[IPv6-AUTH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[IPv6-AUTH] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
Conta, et al. Standards Track [Page 19] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[19ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4203, December 2005.
[IPv6-超能力] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4203、2005年12月。
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[SEC-アーチ] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[TCP-attack] Gont, F., "ICMP attacks against TCP", Work in Progress.
[TCP-攻撃] Gont、F.、「TCPに対するICMP攻撃」、ProgressのWork。
8. Acknowledgements
8. 承認
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ワーキンググループ、特にロバートElz、ジムBound、ビル・シンプソン、トーマスNarten、チャーリーリン、ビルFink、スコット・ブラドナー、Dimitriハスキン、ボブHinden、6月-ichiro Itojun Hagino、Tatuya Jinmei、ブライアンZill、ペッカSavola、フレッド・テンプリン、およびElwynデイヴィース(年代順に)は大規模なレビュー情報とフィードバックを提供しました。
Bob Hinden was the document editor for this document.
ボブHindenはこのドキュメントのためのドキュメントエディタでした。
Conta, et al. Standards Track [Page 20] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[20ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
Appendix A - Changes since RFC 2463
付録A--RFC2463以来の変化
The following changes were made from RFC 2463:
以下の変更はRFC2463から行われました:
- 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.
- セクション2.4の直っている誤植。そこでは、サブ弾丸e.2の参照はe.3の参照であるべきでした。
- 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エラーメッセージのためにレートを制限する例のメカニズムからTimerベースとBandwidthベースのメソッドを取り除きました。 加えられたToken-バケツはメソッドを基礎づけました。
- 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メッセージTypeを認識さえしないとき、受信機が、タイプ特有のデータ埋め込まれた呼び出しがパケットであることを確かに見つけることができるように、すべての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).
- Destination Unreachableの記述では、メッセージ(Code3)はポイントからポイントへのそれらが受け取られたリンクへのパケットの規則禁止推進を加えました、それらの送付先アドレスがリンク(「反ピングの悪臭」規則)自体に属すなら。
- Added description of Time Exceeded Code 1 (fragment reassembly
timeout).
- Time Exceeded Code1(断片再アセンブリタイムアウト)の記述を加えました。
- 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.
- セクション2.4(発生していないICMPエラーメッセージがことである場合の(e))のリストへの加えられたICMP REDIRECT。
- 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では、エコー応答メッセージに関してはっきりさせられます。 anycast Echo RequestへのEcho Replyのソースアドレスはユニキャストアドレスであるべきです、マルチキャストに関するケースのように。
Conta, et al. Standards Track [Page 21] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[21ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
- 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.
- Security Considerations部を改訂しました。 Encapsulating Security有効搭載量Headerの認証の使用を加えました。 SHOULDから5月までの「unauthenticated 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.
- 「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」というRFC2780の参照を加えました。 また、このドキュメントがRFC2780をアップデートするというメモを加えました。
- Added a procedure for new ICMPv6 Type and Code value assignments in
the IANA Considerations section.
- 新しいICMPv6 Typeのための手順とIANA Considerations部のCode値の課題を加えました。
- 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.
- アップデートされた超能力とAHドキュメントの超能力とAH参照を変えました。
- Added reference to the updated IPsec Security Architecture
document.
- アップデートされたIPsec Security Architectureドキュメントの参照を加えました。
- 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によって潜在的に引き起こされる場合があったトランスポート・プロトコルに攻撃に関するテキストを追加しました。
Conta, et al. Standards Track [Page 22] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[22ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
Authors' Addresses
作者のアドレス
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 USA
CT06484米国のアレックスコンタTranswitch社3のエンタープライズDriveシェルトン
EMail: aconta@txc.com
メール: aconta@txc.com
Stephen Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
西タスマン・DriveスティーブンデアリングシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Mukesh Gupta, Ed. Tropos Networks 555 Del Rey Avenue Sunnyvale, CA 94085
Mukeshグプタ、デル・レイAvenueサニーベル、エドTroposネットワーク555カリフォルニア 94085
Phone: +1 408-331-6889 EMail: mukesh.gupta@tropos.com
以下に電話をしてください。 +1 408-331-6889 メールしてください: mukesh.gupta@tropos.com
Conta, et al. Standards Track [Page 23] RFC 4443 ICMPv6 (ICMP for IPv6) March 2006
コンタ、他 2006年の標準化過程[23ページ]RFC4443ICMPv6(IPv6のためのICMP)行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Conta, et al. Standards Track [Page 24]
コンタ、他 標準化過程[24ページ]
一覧
スポンサーリンク
