RFC1885 日本語訳
1885 Internet Control Message Protocol (ICMPv6) for the InternetProtocol Version 6 (IPv6). A. Conta, S. Deering. December 1995. (Format: TXT=32214 bytes) (Obsoleted by RFC2463) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Conta, Digital Equipment Corporation Request for Comments: 1885 S. Deering, Xerox PARC Category: Standards Track December 1995
ワーキンググループのA.コンタ、コメントを求めるDEC要求をネットワークでつないでください: 1885秒間デアリング、ゼロックスPARCカテゴリ: 標準化過程1995年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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document.
このドキュメントはインターネットプロトコル(IPv6)のバージョン6で1セットの使用へのインターネット・コントロール・メッセージ・プロトコル(ICMP)メッセージを指定します。 STD5で指定されたインターネットGroup Managementプロトコル(IGMP)メッセージ、RFC1112はIPv6のためのICMPに合併されて、本書では含められています。
Conta & Deering Standards Track [Page 1] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[1ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
Table of Contents
目次
1. Introduction........................................3
1. 序論…3
2. ICMPv6 (ICMP for IPv6)..............................3
2. ICMPv6(IPv6のためのICMP)…3
2.1 Message General Format.......................3
2.1 メッセージ一般形式…3
2.2 Message Source Address Determination.........4
2.2 メッセージ源アドレス決断…4
2.3 Message Checksum Calculation.................5
2.3 メッセージチェックサム計算…5
2.4 Message Processing Rules.....................5
2.4 メッセージ処理は統治されます…5
3. ICMPv6 Error Messages...............................8
3. ICMPv6エラーメッセージ…8
3.1 Destination Unreachable Message..............8
3.1送信不可能メッセージ…8
3.2 Packet Too Big Message......................10
3.2パケット、大き過ぎるメッセージ…10
3.3 Time Exceeded Message.......................11
3.3 時間はメッセージを超えていました…11
3.4 Parameter Problem Message...................12
3.4パラメタ問題メッセージ…12
4. ICMPv6 Informational Messages......................14
4. ICMPv6、通報メッセージ…14
4.1 Echo Request Message........................14
4.1 要求メッセージを反映してください…14
4.2 Echo Reply Message..........................15
4.2 応答メッセージを反映してください…15
4.3 Group Membership Messages...................17
4.3 会員資格メッセージを分類してください…17
5. References.........................................19
5. 参照…19
6. Acknowledgements...................................19
6. 承認…19
7. Security Considerations............................19
7. セキュリティ問題…19
Authors' Addresses....................................20
作者のアドレス…20
Conta & Deering Standards Track [Page 2] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[2ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
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 Internet Group Membership Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised and has been absorbed into ICMP for IPv6. The resulting protocol is called ICMPv6, and has an IPv6 Next Header value of 58.
インターネットプロトコル、バージョン6(IPv6)はIPの新しいバージョンです。 IPv6はIPv4[RFC-792]のために多くの変化で定義されるようにインターネット・コントロール・メッセージ・プロトコル(ICMP)を使用します。 IPv4[RFC-1112]に指定されたインターネットGroup Membershipプロトコル(IGMP)を、また、改訂して、IPv6のために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 or multicast group membership maintenance; such procedures are described in other documents (e.g., [RFC-1112, RFC-1191]). 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発見やマルチキャストグループ会員資格メインテナンスのような機能を獲得するこれらのメッセージを使用するための手順について説明しません。 そのような手順は他のドキュメント(例えば、[RFC-1112、RFC-1191])で説明されます。 また、他のドキュメントは追加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]に基づき定義された用語はまた、このドキュメントに適用されます。
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") and multicast membership reporting. 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 3] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[3ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年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)
130 Group Membership Query (see section 4.3)
131 Group Membership Report (see section 4.3)
132 Group Membership Reduction (see section 4.3)
128 エコーRequest(セクション4.1を見る)129Echo Reply(セクション4.2を見る)130Group Membership Query(セクション4.3を見る)131Group Membership Report(セクション4.3を見る)132Group Membership Reduction(セクション4.3を見ます)
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を選ばなければなりません:
Conta & Deering Standards Track [Page 4] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[4ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
(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 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であるなら受け取られている、静かにそれを捨てなければなりません。
Conta & Deering Standards Track [Page 5] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[5ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
(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 576 octets.
(c) あらゆるICMPv6エラーメッセージ(<128をタイプする)がエラーメッセージパケットに576の八重奏を超えさせないで発作のようにパケット(誤りを引き起こしたパケット)を怒らせる(呼び出します)IPv6の同じくらい多くを含んでいます。
(d) In those cases where the internet-layer protocol is required to
pass an ICMPv6 error message to the upper-layer protocol, 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 protocol entity 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 576-octet limit. In that
case, the error message is silently dropped after any IPv6-layer
processing.
オリジナルのパケットに異常に多量の拡張ヘッダーがいたなら、576八重奏の制限を順守するのはオリジナルのパケットのトランケーションのために上側の層のプロトコルタイプに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, to each sender of an erroneous data packet, an IPv6
node MUST limit the rate of ICMPv6 error messages sent, in order
to limit the bandwidth and forwarding costs incurred by the
error messages when a generator of erroneous packets does not
respond to those error messages by ceasing its transmissions.
(f) 最終的に、誤ったデータパケットの各送付者に、IPv6ノードは、トランスミッションをやめることによって、誤ったパケットのジェネレータが反応しないとき、帯域幅を制限するために送られて、エラーメッセージによって被られたコストを進めるICMPv6エラーメッセージ対それらのエラーメッセージのレートを制限しなければなりません。
Conta & Deering Standards Track [Page 6] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[6ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
There are a variety of ways of implementing the rate-limiting
function, for example:
例えば、レートを制限する機能を実装するさまざまな方法があります:
(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に制限する、ミリセカンド。
(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メッセージのためにメッセージ・フォーマットについて説明します。
Conta & Deering Standards Track [Page 7] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[7ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
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 576 octets |
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パケット+のない発作のように| 上回っている576の八重奏|
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 a neighbor
3 - address unreachable
4 - port unreachable
コード0--隣人3ではなく、目的地とのコミュニケーションが行政上2を禁止したという目的地1--アドレス手の届かない4--ポートに手の届かないルートがありません。
Unused This field is unused for all code values.
It must be initialized to zero by the sender
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 (NOTE: this error can occur only in nodes that do not hold a "default route" in their routing tables).
配送しないことの理由が推進ノードの経路指定テーブルの合っているエントリーの不足であるなら、Code分野は0に設定されます(注意: この誤りはそれらの経路指定テーブルに「デフォルトルート」を保持しないノードだけに発生できます)。
Conta & Deering Standards Track [Page 8] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[8ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
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 next destination address in the Routing header is not a neighbor of the processing node but the "strict" bit is set for that address, then the Code field is set to 2.
理由が配送しないことがルート設定ヘッダーの次の送付先アドレスが処理ノードの隣人ではなく、「厳しい」ビットであるということであるのでそのアドレスに設定されるなら、Code分野は2に設定されます。
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 protocol.
ICMPv6 Destination Unreachableメッセージを受け取るノードは上側の層のプロトコルに通知しなければなりません。
Conta & Deering Standards Track [Page 9] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[9ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年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 576 octets |
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パケット+のない発作のように| 上回っている576の八重奏|
IPv6 Fields:
IPv6分野:
Destination Address
送付先アドレス
Copied from the Source Address field of the invoking
packet.
呼び出しパケットのSource Address分野から、コピーされます。
ICMPv6 Fields:
ICMPv6分野:
Type 2
2をタイプしてください。
Code 0
コード0
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 [RFC-1191].
パケットが出発しているリンクのMTUより大きいので、ルータはそれが進めることができないパケットに対応してPacket Too Bigを送らなければなりません。 このメッセージの情報はPath MTUディスカバリープロセス[RFC-1191]の一部として使用されます。
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 protocol.
入って来るPacket Too Bigメッセージを上側の層のプロトコルに通過しなければなりません。
Conta & Deering Standards Track [Page 10] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[10ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年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 576 octets |
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パケット+のない発作のように| 上回っている576の八重奏|
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 router sending an ICMPv6 Time Exceeded message with Code 0 SHOULD consider the receiving interface of the packet as the interface on which the packet forwarding failed in following rule (d) for selecting the Source Address of the message.
0SHOULDがパケット推進がメッセージのSource Addressを選択するための次の規則(d)に失敗したインタフェースとしてパケットの受信インタフェースであると考えるCodeがあるICMPv6 Time Exceededメッセージを送るルータ。
Upper layer notification
上側の層の通知
An incoming Time Exceeded message MUST be passed to the upper-layer protocol.
入って来るTime Exceededメッセージを上側の層のプロトコルに通過しなければなりません。
Conta & Deering Standards Track [Page 11] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[11ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年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 576 octets |
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パケット+のない発作のように| 上回っている576の八重奏|
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 576-byte limit of an ICMPv6 error message.
間違い分野がICMPv6エラーメッセージの576バイトの限界をうまくはめ込むことができることを超えていると、指針は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 12] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[12ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年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 protocol.
このICMPv6メッセージを受け取るノードは上側の層のプロトコルに通知しなければなりません。
Conta & Deering Standards Track [Page 13] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[13ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
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か、より多くの八重奏。
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
上側の層の通知
A node receiving this ICMPv6 message MAY notify the upper-layer protocol.
このICMPv6メッセージを受け取るノードは上側の層のプロトコルに通知するかもしれません。
Conta & Deering Standards Track [Page 14] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[14ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
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からのデータが通信させるデータ。
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メッセージが受け取られたインタフェースに属すユニキャストアドレスであるに違いありません。
Conta & Deering Standards Track [Page 15] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[15ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
The data received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message, unless the Echo Reply would exceed the MTU of the path back to the Echo requester, in which case the data is truncated to fit that path MTU.
Echo Replyが経路のMTUをEchoリクエスタに超えて戻していないなら、ICMPv6 Echo Requestメッセージに受け取られたデータが完全に返されて、ICMPv6 Echo Replyメッセージで変更されているはずがない、その場合、データは、その経路MTUに合うように先端を切られます。
Upper layer notification
上側の層の通知
Echo Reply messages MUST be passed to the ICMPv6 user interface, unless the corresponding Echo Request originated in the IP layer.
エコーReplyメッセージをICMPv6ユーザーインタフェースに通過しなければなりません、対応するEcho RequestがIP層で起こらなかったなら。
Conta & Deering Standards Track [Page 16] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[16ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
4.3 Group Membership Messages
4.3 グループ会員資格メッセージ
The ICMPv6 Group Membership Messages have the following format:
ICMPv6 Group Membership Messagesには、以下の形式があります:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Delay | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Multicast |
+ +
| Address |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
送付先アドレス
In a Group Membership Query message, the multicast
address of the group being queried, or the Link-Local
All-Nodes multicast address.
Group Membership Queryメッセージ、質問されるグループのマルチキャストアドレス、またはLinkローカルのAll-ノードマルチキャストアドレスで。
In a Group Membership Report or a Group Membership
Reduction message, the multicast address of the
group being reported or terminated.
報告されるか、または終えられるグループのGroup Membership ReportかGroup Membership Reductionメッセージ、マルチキャストアドレスで。
Hop Limit 1
ホップ限界1
ICMPv6 Fields:
ICMPv6分野:
Type 130 - Group Membership Query
131 - Group Membership Report
132 - Group Membership Reduction
タイプ130--グループ会員資格質問131--グループ会員資格レポート132--グループ会員資格減少
Code 0
コード0
Maximum Response Delay
最大の応答遅れ
In Query messages, the maximum time that responding
Report messages may be delayed, in milliseconds.
Queryメッセージ、Reportメッセージを反応させるのがミリセカンドで遅れるかもしれない最大の時間で。
Conta & Deering Standards Track [Page 17] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[17ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
In Report and Reduction messages, this field is
is initialized to zero by the sender and ignored by
receivers.
ReportとReductionメッセージでは、この分野は、ゼロに送付者によって初期化されて受信機によって無視されています。
Unused Initialized to zero by the sender; ignored by receivers.
送付者によるゼロへの未使用のInitialized。 受信機で、無視されます。
Multicast Address
マルチキャストアドレス
The address of the multicast group about which the
message is being sent. In Query messages, the Multicast
Address field may be zero, implying a query for all
groups.
メッセージが送られるマルチキャストグループのアドレス。 Queryメッセージでは、すべてのグループのために質問を含意して、Multicast Address分野はゼロであるかもしれません。
Description
記述
The ICMPv6 Group Membership messages are used to convey information about multicast group membership from nodes to their neighboring routers. The details of their usage is given in [RFC-1112].
ICMPv6 Group Membershipメッセージは、マルチキャストグループ会員資格に関してノードから隣接しているそれらのルータまで情報を伝達するのに使用されます。 それらの用法の詳細は[RFC-1112]で明らかにされます。
Conta & Deering Standards Track [Page 18] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[18ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
5. References
5. 参照
[IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version
6, Specification", RFC 1883, Xerox PARC, Ipsilon
Networks, December 1995.
[IPv6]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6、仕様」、RFC1883、ゼロックスPARC、Ipsilonネットワーク、12月1995
[IPv6-ADDR] Hinden, R., and S. Deering, Editors, "IP Version 6
Addressing Architecture", RFC 1884, Ipsilon Networks,
Xerox PARC, December 1995.
[IPv6-ADDR] Hinden、R.とS.デアリング、エディターズ、「IPバージョン6アドレッシング体系」、RFC1884、Ipsilonネットワーク、ゼロックスPARC、1995年12月。
[IPv6-DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", Work in Progress.
T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」という[IPv6-ディスク]Nartenは進行中で働いています。
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, USC/Information Sciences Institute, September
1981.
[RFC-792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、科学が1981年9月に設けるUSC/情報。
[RFC-1112] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC 1112, Stanford University, August 1989.
[RFC-1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
[RFC-1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, USC/Information
Sciences Institute, October 1989.
[RFC-1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、科学が設けるUSC/情報、10月1989日
[RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC
1191, DECWRL, Stanford University, November 1990.
[RFC-1191] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、DECWRL、スタンフォード大学、1990年11月。
6. Acknowledgements
6. 承認
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, and Scott Bradner (in chronological order) provided extensive review information and feedback.
IPngワーキンググループ、特にロバートElz、ジムBound、ビル・シンプソン、トーマスNarten、チャーリーリン、ビルFink、およびスコット・ブラドナーは(年代順に)大規模なレビュー情報とフィードバックを提供しました。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Conta & Deering Standards Track [Page 19] RFC 1885 ICMPv6 (ICMP for IPv6) December 1995
コンタとデアリング標準化過程[19ページ]RFC1885ICMPv6(IPv6のためのICMP)1995年12月
Authors' Addresses:
作者のアドレス:
Alex Conta Stephen Deering Digital Equipment Corporation Xerox Palo Alto Research Center 110 Spitbrook Rd 3333 Coyote Hill Road Nashua, NH 03062 Palo Alto, CA 94304
アレックスコンタスティーブンデアリングディジタルイクイップメント社ゼロックスパロアルト研究センター110Spitbrook3333コヨーテヒル・Road第ナッシュア(ニューハンプシャー)03062パロアルト(カリフォルニア)94304
Phone: +1-603-881-0744 Phone: +1-415-812-4839 EMail: conta@zk3.dec.com EMail: deering@parc.xerox.com
以下に電話をしてください。 +1-603-881-0744 以下に電話をしてください。 +1-415-812-4839 メールしてください: conta@zk3.dec.com メール: deering@parc.xerox.com
Conta & Deering Standards Track [Page 20]
コンタとデアリング標準化過程[20ページ]
一覧
スポンサーリンク
