RFC2463 日本語訳
2463 Internet Control Message Protocol (ICMPv6) for the InternetProtocol Version 6 (IPv6) Specification. A. Conta, S. Deering. December 1998. (Format: TXT=34190 bytes) (Obsoletes RFC1885) (Obsoleted by RFC4443) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Conta
Request for Comments: 2463 Lucent
Obsoletes: 1885 S. Deering
Category: Standards Track Cisco Systems
December 1998
コメントを求めるワーキンググループA.コンタの要求をネットワークでつないでください: 2463、透明である、時代遅れにします: 1885秒間デアリングカテゴリ: 標準化過程シスコシステムズ1998年12月
Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification
インターネットプロトコルバージョン6(IPv6)仕様のためのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)
Status of this Memo
この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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6).
このドキュメントはインターネットプロトコル(IPv6)のバージョン6で1セットの使用へのインターネット・コントロール・メッセージ・プロトコル(ICMP)メッセージを指定します。
Table of Contents
目次
1. Introduction........................................2
2. ICMPv6 (ICMP for IPv6)..............................2
2.1 Message General Format.......................2
2.2 Message Source Address Determination.........3
2.3 Message Checksum Calculation.................4
2.4 Message Processing Rules.....................4
3. ICMPv6 Error Messages...............................6
3.1 Destination Unreachable Message..............6
3.2 Packet Too Big Message...................... 8
3.3 Time Exceeded Message....................... 9
3.4 Parameter Problem Message...................10
4. ICMPv6 Informational Messages......................11
4.1 Echo Request Message........................11
4.2 Echo Reply Message..........................12
5. Security Considerations............................13
6. References.........................................14
7. Acknowledgments....................................15
1. 序論…2 2. ICMPv6(IPv6のためのICMP)…2 2.1 メッセージ一般形式…2 2.2 メッセージ源アドレス決断…3 2.3 メッセージチェックサム計算…4 2.4 メッセージ処理は統治されます…4 3. ICMPv6エラーメッセージ…6 3.1送信不可能メッセージ…6 3.2 パケット、大き過ぎるメッセージ… 8 3.3 時間はメッセージを超えていました… 9 3.4パラメタ問題メッセージ…10 4. ICMPv6、通報メッセージ…11 4.1 要求メッセージを反映してください…11 4.2 応答メッセージを反映してください…12 5. セキュリティ問題…13 6. 参照…14 7. 承認…15
Conta & Deering Standards Track [Page 1] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[1ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
8. Authors' Addresses.................................16
Appendix A - Changes since RFC 1885...................17
Full Copyright Statement..............................18
8. 作者のアドレス…16 付録A--RFC1885以来の変化…17 完全な著作権宣言文…18
1. Introduction
1. 序論
The Internet Protocol, version 6 (IPv6) is a new version of IP. 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)はIPの新しいバージョンです。 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; such 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]に基づき定義された用語はまた、このドキュメントに適用されます。
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 MUST be fully implemented by every IPv6 node.
ICMPv6はIPv6ノードによって使用されて、処理パケットで遭遇する誤りを報告して、他のインターネット層の機能を実行します、病気の特徴などのように(ICMPv6は「確認します」)。 ICMPv6をIPv6の不可欠の部分であり、あらゆるIPv6ノードで完全に実装しなければなりません。
2.1 Message General Format
2.1 メッセージ一般形式
ICMPv6 messages are grouped into two classes: error messages and informational messages. Error messages are identified as such by having 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までメッセージTypesがあります。 通報メッセージには、128〜255までメッセージTypesがあります。
This document defines the message formats for the following ICMPv6 messages:
このドキュメントは以下のICMPv6メッセージのためにメッセージ・フォーマットを定義します:
Conta & Deering Standards Track [Page 2] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[2ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
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 目的地Unreachable(セクション3.1を見る)2Packet Too Big(セクション3.2を見る)3Time Exceeded(セクション3.3を見る)4Parameter Problem(セクション3.4を見ます)
ICMPv6 informational messages:
ICMPv6、通報メッセージ:
128 Echo Request (see section 4.1)
129 Echo Reply (see section 4.2)
128 エコーRequest(セクション4.1を見る)129Echo Reply(セクション4.2を見ます)
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. (NOTE: this is different than 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メッセージと一部にデータの汚染を検出するのに使用されます。
2.2 Message Source Address Determination
2.2 メッセージ源アドレス決断
A node that sends 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はその同じアドレスであるに違いありません。
Conta & Deering Standards Track [Page 3] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[3ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
(b) If the message is a response to a message sent to a multicast or
anycast group in which the node is a member, the Source Address
of the reply must be a unicast address belonging to the
interface on which the multicast or anycast packet was received.
(b) メッセージがノードがメンバーであるマルチキャストかanycastグループに送られたメッセージへの応答であるなら、回答のSource Addressはマルチキャストかanycastパケットが受け取られたインタフェースに属すユニキャストアドレスであるに違いありません。
(c) If the message is a response to a message sent to an address
that does not belong to the node, the Source Address should be
that unicast address belonging to the node that will be most
helpful in diagnosing the error. For example, if the message is
a response to a packet forwarding action that cannot complete
successfully, the Source Address should be a unicast address
belonging to the interface on which the packet forwarding
failed.
(c) メッセージがノードに属さないアドレスに送られたメッセージへの応答であるなら、Source Addressは誤りを診断するのに最も有用なノードに属すそのユニキャストアドレスであるべきです。 例えば、メッセージがそれを動作に送るのが首尾よく完成できないパケットへの応答であるなら、Source Addressはパケット推進が失敗したインタフェースに属すユニキャストアドレスであるべきです。
(d) Otherwise, the node's routing table must be examined to
determine which interface will be used to transmit the message
to its destination, and a unicast address belonging to that
interface must be used as the Source Address of the message.
(d) さもなければ、どのインタフェースがメッセージを目的地に送るのに使用されるかを決定するためにノードの経路指定テーブルを調べなければなりません、そして、メッセージのSource Addressとしてそのインタフェースに属すユニキャストアドレスを使用しなければなりません。
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, 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. (NOTE: the inclusion of a pseudo-header in the ICMPv6 checksum is a change from IPv4; see [IPv6] for the rationale for this change.)
チェックサムは[IPv6、セクション8.1]で指定されるようにIPv6ヘッダーフィールドの「疑似ヘッダー」と共にprependedされたICMPv6メッセージタイプ野原から始まる全体のICMPv6メッセージの1の補数合計の16ビットの1の補数です。 疑似ヘッダーで使用されるNext Header値は58です。 (注意: ICMPv6チェックサムでの疑似ヘッダーの包含はIPv4からの変化です; この変化のために原理に関して[IPv6]を見てください。)
For computing the checksum, the checksum field is 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]からの)を処理するとき、実装は以下の規則を守らなければなりません:
(a) If an ICMPv6 error message of unknown type is received, it MUST
be passed to the upper layer.
(a) 未知のタイプのICMPv6エラーメッセージが受信されているなら、上側の層にそれを通過しなければなりません。
(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) includes as much of the
IPv6 offending (invoking) packet (the packet that caused the
error) as will fit without making the error message packet
exceed the minimum IPv6 MTU [IPv6].
(c) あらゆるICMPv6エラーメッセージ(<128をタイプする)がエラーメッセージパケットに最小のIPv6 MTU[IPv6]を超えさせないで発作のようにパケット(誤りを引き起こしたパケット)を怒らせる(呼び出します)IPv6の同じくらい多くを含んでいます。
Conta & Deering Standards Track [Page 4] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[4ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
(d) In those 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エラーメッセージのボディーでは、含まれている)から抜粋されて、誤りを扱うために適切な上側の層のプロセスを選択するのに使用されます。
If the original packet had an unusually large amount of
extension headers, it is possible that the upper-layer protocol
type may not be present in the ICMPv6 message, due to truncation
of the original packet to meet the minimum IPv6 MTU [IPv6]
limit. In that case, the error message is silently dropped
after any IPv6-layer processing.
オリジナルのパケットに異常に多量の拡張ヘッダーがいたなら、最小のIPv6 MTU[IPv6]制限を順守するのはオリジナルのパケットのトランケーションのために上側の層のプロトコルタイプにICMPv6メッセージに出席していないかもしれないのが可能です。 その場合、エラーメッセージはどんなIPv6-層の処理の後にも静かに下げられます。
(e) An ICMPv6 error message MUST NOT be sent as a result of
receiving:
(e) 受信の結果、ICMPv6エラーメッセージを送ってはいけません:
(e.1) an ICMPv6 error message, or
または(e.1) ICMPv6エラーメッセージ。
(e.2) 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 that has the Option Type highest-order two
bits set to 10), or
または(e.2) パケットがIPv6マルチキャストアドレスに運命づけられた、(この規則への2つの例外があります: (1) Path MTU発見がIPv6マルチキャスト、および(2)のためにParameter Problem Messageを扱うのを許容するPacket Too Big Message(セクション3.2)(Option Typeの最も高いオーダーを2ビット持っている認識されていないIPv6オプションを報告するCode2(セクション3.4))は10にセットしました)。
(e.3) a packet sent as a link-layer multicast, (the exception
from e.2 applies to this case too), or
または(e.3) パケットがリンクレイヤマルチキャストとして発信した、(e.2からの例外は本件にも適用されます)。
(e.4) a packet sent as a link-layer broadcast, (the exception
from e.2 applies to this case too), or
または(e.4) リンクレイヤが放送されたようにパケットが発信した、(e.2からの例外は本件にも適用されます)。
(e.5) 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 sender to be an IPv6 anycast address.
(e.5) ソースアドレスが唯一ただ一つのノードを特定しないパケット--IPv6 anycastアドレスであることがICMPメッセージ送付者によって知られていた例えば、IPv6 Unspecified Address、IPv6マルチキャストアドレス、またはアドレス。
(f) Finally, in order to limit the bandwidth and forwarding costs
incurred sending ICMPv6 error messages, an IPv6 node MUST limit
the rate of ICMPv6 error messages it sends. This situation may
occur when a source sending a stream of erroneous packets fails
to heed the resulting ICMPv6 error messages. There are a
variety of ways of implementing the rate-limiting function, for
example:
(f) 最終的に、エラーメッセージをICMPv6に送りながら被られた帯域幅と推進コストを制限するために、IPv6ノードはそれが送るICMPv6エラーメッセージのレートを制限しなければなりません。 誤ったパケットの流れを送るソースが結果として起こるICMPv6エラーメッセージを意に介さないと、この状況は起こるかもしれません。 例えば、レートを制限する機能を実装するさまざまな方法があります:
(f.1) Timer-based - for example, limiting the rate of
transmission of error messages to a given source, or to
any source, to at most once every T milliseconds.
(f.1) タイマベース--、例えば、与えられたソース、または、エラーメッセージの伝達対どんなソースの速度を高々一度あらゆるTに制限する、ミリセカンド。
Conta & Deering Standards Track [Page 5] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[5ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
(f.2) Bandwidth-based - for example, limiting the rate at which
error messages are sent from a particular interface to
some fraction F of the attached link's bandwidth.
(f.2)、帯域幅ベース、--例えば、エラーメッセージが特定のインタフェースから付属リンクの帯域幅のある部分Fに送られるレートを制限すること。
The limit parameters (e.g., T or F in the above examples) MUST
be configurable for the node, with a conservative default value
(e.g., T = 1 second, NOT 0 seconds, or F = 2 percent, NOT 100
percent).
ノードに、限界パラメタ(上記の例の例えば、TかF)は構成可能であるに違いありません、保守的なデフォルト値(100パーセントではなく、0秒、または2F=パーセントではなく、1例えば、T=秒)で。
The following sections describe the message formats for the above ICMPv6 messages.
以下のセクションは上記のICMPv6メッセージのためにメッセージ・フォーマットについて説明します。
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 will fit 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 - (not assigned)
3 - address unreachable
4 - port unreachable
コード0--目的地1へのルートがありません--行政上禁止された2--(割り当てられません)3(手の届かない4を扱う)ポート手が届かない目的地とのコミュニケーション
Unused This field is unused for all code values.
It must be initialized to zero by the sender
and ignored by the receiver.
すべてのコード値において、未使用のThis分野は未使用です。 それを送付者によってゼロに初期化されて、受信機で無視しなければなりません。
Conta & Deering Standards Track [Page 6] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[6ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
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.)
混雑以外の理由による送付先アドレスに提供できないパケットに対応した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 (NOTE: this error can occur only in nodes that do not hold a "default route" in their routing tables).
配送しないことの理由が推進ノードの経路指定テーブルの合っているエントリーの不足であるなら、Code分野は0に設定されます(注意: この誤りはそれらの経路指定テーブルに「デフォルトルート」を保持しないノードだけに発生できます)。
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 there is any other reason for the failure to deliver, e.g., inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort, then the Code field is set to 3.
配送しないことの他の理由があるか、そして、例えば、IPv6送付先アドレスに対応するリンクアドレスに変えることができないこと、またはある種のリンク特有の問題、そして、Code分野は3に設定されます。
A destination node SHOULD send 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がトランスポート・プロトコル(例えば、UDP)にはリスナーが全くいないパケットに対応してCode4があるDestination Unreachableメッセージを送る目的地ノード。
Upper layer notification
上側の層の通知
A node receiving the ICMPv6 Destination Unreachable message MUST notify the upper-layer process.
ICMPv6 Destination Unreachableメッセージを受け取るノードは上側の層のプロセスに通知しなければなりません。
Conta & Deering Standards Track [Page 7] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[7ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
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 will fit 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 sender 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]の一部として使用されます。
Sending a Packet Too Big Message makes an exception to one of the rules of when to send an ICMPv6 error message, in that unlike other messages, it is sent in response to a packet received with an IPv6 multicast destination address, or a link-layer multicast or link- layer broadcast address.
Packet Too Big Messageを送ると、いつICMPv6エラーメッセージを送るかに関する規則の1つへの例外は利かせます、他のメッセージと異なってIPv6マルチキャスト送付先アドレス、リンクレイヤマルチキャストまたはリンク層の放送アドレスで受け取られたパケットに対応してそれを送るので。
Upper layer notification
上側の層の通知
An incoming Packet Too Big message MUST be passed to the upper-layer process.
入って来るPacket Too Bigメッセージを上側の層のプロセスに通過しなければなりません。
Conta & Deering Standards Track [Page 8] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[8ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
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 will fit 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
コード0--トランジットで超えられていたホップ限界
1 - fragment reassembly time exceeded
再アセンブリ時間が超えていた1--断片
Unused This field is unused for all code values.
It must be initialized to zero by the sender
and ignored by the receiver.
すべてのコード値において、未使用のThis分野は未使用です。 それを送付者によってゼロに初期化されて、受信機で無視しなければなりません。
Description
記述
If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it MUST discard the packet and send 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値のどちらかを示します。
The rules for selecting the Source Address of this message are defined in section 2.2.
このメッセージのSource Addressを選択するための規則はセクション2.2で定義されます。
Upper layer notification
上側の層の通知
An incoming Time Exceeded message MUST be passed to the upper-layer process.
入って来るTime Exceededメッセージを上側の層のプロセスに通過しなければなりません。
Conta & Deering Standards Track [Page 9] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[9ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
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 will fit 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
コード0--遭遇する誤ったヘッダーフィールド
1 - unrecognized Next Header type encountered
1--遭遇する認識されていないNext Headerタイプ
2 - unrecognized IPv6 option encountered
2--遭遇する認識されていないIPv6オプション
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 send an ICMPv6 Parameter Problem message to the packet's source, indicating the type and location of the problem.
それが、パケットを処理するのを完了できないようにパケットを処理するIPv6ノードがIPv6ヘッダーか拡張ヘッダーの分野に関する問題を見つけるなら、それはパケットを捨てなければなりません、そして、SHOULDはICMPv6 Parameter Problemメッセージをパケットのソースに送ります、問題のタイプと位置を示して。
The pointer identifies the octet of the original packet's header where the error was detected. For example, an ICMPv6 message with Type field = 4, Code field = 1, and Pointer field = 40 would indicate
指針は誤りが検出されたオリジナルのパケットのヘッダーの八重奏を特定します。 例えば、Code分野=のType分野=4があるICMPv6メッセージ、1、およびPointerは40が示す=をさばきます。
Conta & Deering Standards Track [Page 10] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[10ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
that the IPv6 extension header following the IPv6 header of the original packet holds an unrecognized Next Header field value.
オリジナルのパケットのIPv6ヘッダーについて来るIPv6拡張ヘッダーは認識されていないNext Header分野価値を保持します。
Upper layer notification
上側の層の通知
A node receiving this ICMPv6 message MUST notify the upper-layer process.
このICMPv6メッセージを受け取るノードは上側の層のプロセスに通知しなければなりません。
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識別子。 ゼロであるかもしれません。
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か、より多くの八重奏。
Conta & Deering Standards Track [Page 11] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[11ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
Description
記述
Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending 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からの識別子が通信させる識別子。
Sequence The sequence number from the invoking Echo Request Number message.
Echo Request Numberが通信させる呼び出しから一連番号を配列してください。
Data The data from the invoking Echo Request message.
呼び出しているEcho Requestからのデータが通信させるデータ。
Conta & Deering Standards Track [Page 12] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[12ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
Description
記述
Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending 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 address. The source address of the reply MUST be a unicast address belonging to the interface on which the multicast Echo Request message was received.
Echo Reply SHOULD、IPv6マルチキャストアドレスに送られたEcho Requestメッセージに対応して、送ってください。 回答のソースアドレスはマルチキャスト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. It may be passed to processes that did not originate the Echo Request message.
Echo Requestメッセージを溯源したプロセスにエコーReplyメッセージを通過しなければなりません。 それはEcho Requestメッセージを溯源しなかったプロセスに通過されるかもしれません。
5. Security Considerations
5. セキュリティ問題
5.1 Authentication and Encryption of ICMP messages
5.1 ICMPメッセージの認証とEncryption
ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an Authentication Header when sending ICMP messages if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol.
IP Authentication Header[IPv6-AUTH]を使用することでICMPプロトコルパケット交換を認証できます。 IP Authentication Headerとの使用のためのセキュリティ協会が送付先アドレスのために存在するならメッセージをICMPに送るとき、ノードSHOULDはAuthentication Headerを含んでいます。 セキュリティ協会は手動の構成を通して、または、何らかのかぎ管理プロトコルの操作を通して創設されたかもしれません。
Received Authentication Headers in ICMP packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored and discarded.
正当性のためにICMPパケットの容認されたAuthentication Headersについて確かめなければならなくて、不正確な認証があるパケットを無視されて、捨てなければなりません。
It SHOULD be possible for the system administrator to configure a node to ignore any ICMP messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages.
それ、SHOULD、システム管理者がAuthentication HeaderかEncapsulating Security有効搭載量を使用することで認証されないどんなICMPメッセージも無視するためにノードを構成するのにおいて、可能であってください。 許容へのそのようなスイッチSHOULDデフォルトはメッセージを非認証しました。
Conta & Deering Standards Track [Page 13] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[13ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- ESP].
IP Security ArchitectureとIP Encapsulating Security有効搭載量ドキュメント[IPv6IPv6-SA、超能力]によって秘密性問題は扱われます。
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 such attacks and their prevention is as follows:
ICMPメッセージは様々な攻撃を受けることがあるかもしれません。 IP Security Architecture[IPv6-SA]で完全な議論を見つけることができます。 そのような攻撃と彼らの防止の簡潔な議論は以下の通りです:
1. ICMP messages may be subject to actions intended to cause the
receiver believe the message came from a different source than 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 go to a destination different than the
message originator's intention. The ICMP checksum calculation
provides a protection mechanism against changes by a malicious
interceptor in the destination and source address of the IP packet
carrying that message, provided the ICMP checksum field is
protected against change by authentication [IPv6-Auth] or
encryption [IPv6-ESP] of the ICMP message.
2. ICMPメッセージはメッセージを引き起こすことを意図する動作かそれに関する回答を条件としてメッセージ創始者の意志と異なった目的地に行くことであるかもしれません。 ICMPチェックサム分野が変化に対して保護されるなら、ICMPメッセージの認証[IPv6-Auth]か暗号化[IPv6-超能力]でICMPチェックサム計算は、そのメッセージを伝えながら、IPパケットの目的地とソースアドレスの悪意がある迎撃戦闘機で変化に対して保護メカニズムを提供します。
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 is a protection against such actions.
3. ICMPメッセージはメッセージ分野、またはペイロードにおける変化を被りやすいかもしれません。 ICMPメッセージの認証[IPv6-Auth]か暗号化[IPv6-超能力]がそのような動作に対する保護です。
4. ICMP messages may be used as attempts to perform denial of service
attacks by sending back to back erroneous IP packets. An
implementation that correctly followed section 2.4, paragraph (f)
of this specifications, would be protected by the ICMP error rate
limiting mechanism.
4. 発信することによってサービス不能攻撃を実行する試みが逆誤ったIPにパケットを支持するとき、ICMPメッセージは使用されるかもしれません。 正しくセクション2.4に従った実装(この仕様のパラグラフ(f))はICMP誤り率制限メカニズムによって保護されるでしょう。
6. References
6. 参照
[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-ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[IPv6-ADDR] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[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月。
Conta & Deering Standards Track [Page 14] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[14ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC-792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC-1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 5, RFC 1122, August 1989.
[RFC-1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD5、RFC1122、8月1989日
[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月。
[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月。
[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. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[IPv6-Auth] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[IPv6-超能力] ケントとS.とR.アトキンソン、「セキュリティがプロトコル(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
7. Acknowledgments
7. 承認
The document is derived from previous ICMP drafts 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, and Bob Hinden (in chronological order) provided extensive review information and feedback.
IPngワーキンググループ、特にロバートElz、ジムBound、ビル・シンプソン、トーマスNarten、チャーリーリン、ビルFink、スコット・ブラドナー、Dimitriハスキン、およびボブHinden(年代順に)は大規模なレビュー情報とフィードバックを提供しました。
Conta & Deering Standards Track [Page 15] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[15ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
8. Authors' Addresses
8. 作者のアドレス
Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 USA
スイート100一致、MA01742米国のアレックスコンタルーセントテクノロジーズ株式会社300のパン屋Ave
Phone: +1 978 287-2842 EMail: aconta@lucent.com
以下に電話をしてください。 +1 978 287-2842 メールしてください: aconta@lucent.com
Stephen Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
西タスマン・DriveスティーブンデアリングシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 527-8213 EMail: deering@cisco.com
以下に電話をしてください。 +1 408 527-8213 メールしてください: deering@cisco.com
Conta & Deering Standards Track [Page 16] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[16ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
Appendix A - Changes from RFC 1885
付録A--RFC1885からの変化
Version 2-02
バージョン2-02
- Excluded mentioning informational replies from paragraph (f.2) of
section 2.4.
- In "Upper layer notification" sections changed "upper-layer
protocol" and "User Interface" to "process".
- Changed section 5.2, item 2 and 3 to also refer to AH
authentication.
- Removed item 5. from section 5.2 on denial of service attacks.
- Updated phone numbers and Email addresses in the "Authors'
Addresses" section.
- セクション2.4のパラグラフ(f.2)から情報の回答について言及しながら、除かれます。 - 「上側の層の通知」では、セクションは、「処理する」ために「上側の層のプロトコル」と「ユーザーインタフェース」を変えました。 - また、AH認証について言及するためにセクション5.2、項目2と3を変えました。 - サービスの否定でのセクション5.2からの取り外された項目5は攻撃されます。 - 「作者のアドレス」セクションのアップデートされた電話番号とメールアドレス。
Version 2-01
バージョン2-01
- Replaced all references to "576 octets" as the maximum for an ICMP
message size with "minimum IPv6 MTU" as defined by the base IPv6
specification.
- Removed rate control from informational messages.
- Added requirement that receivers ignore Code value in Packet Too
Big message.
- Removed "Not a Neighbor" (code 2) from destination unreachable
message.
- Fixed typos and update references.
- ICMPメッセージサイズのための最大としてベースIPv6仕様で定義される「最小のIPv6 MTU」に「576の八重奏」のすべての参照を置き換えました。 - 通報メッセージから速度制御を取り除きました。 - 受信機がPacket Too BigメッセージのCode値を無視するという要件を加えました。 - 送信不可能メッセージから「隣人でない」(コード2)を取り除きました。 - 固定誤植とアップデート参照。
Version 2-00
バージョン2-00
- Applied rate control to informational messages
- Removed section 2.4 on Group Management ICMP messages
- Removed references to IGMP in Abstract and Section 1.
- Updated references to other IPv6 documents
- Removed references to RFC-1112 in Abstract, and Section 1, and to
RFC-1191 in section 1, and section 3.2
- Added security section
- Added Appendix A - changes
- 通報メッセージへの適用された速度制御(Group Management ICMPメッセージの取り外されたセクション2.4)は要約とセクション1でIGMPの参照を取り除きました。 - 他のIPv6ドキュメントのアップデートされた参照(要約、およびセクション1におけるRFC-1112とセクション1、およびセクション3.2のRFC-1191の取り除かれた参照)はセキュリティ部--加えられたAppendix A--変化を加えました。
Conta & Deering Standards Track [Page 17] RFC 2463 ICMPv6 (ICMP for IPv6) December 1998
コンタとデアリング標準化過程[17ページ]RFC2463ICMPv6(IPv6のためのICMP)1998年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Conta & Deering Standards Track [Page 18]
コンタとデアリング標準化過程[18ページ]
一覧
スポンサーリンク
