[要約] RFC 3122は、IPv6 Neighbor Discoveryの逆探索仕様に関する拡張であり、逆探索のための新しいオプションを提供します。このRFCの目的は、IPv6ネットワークで逆探索をサポートするための標準化と、ネットワーク管理者がネットワーク内のノードを特定するための手段を提供することです。
Network Working Group A. Conta
Request for Comments: 3122 Transwitch Corporation
Category: Standards Track June 2001
Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
逆発見仕様のためのIPv6ネイバーディスカバリーへの拡張
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.
このメモは、IPv6ネイバーディスカバリーへの拡張機能について説明します。これにより、ノードが特定のリンク層アドレスに対応するIPv6アドレスを決定および宣伝します。これらの拡張は、逆隣接の発見と呼ばれます。逆隣接発見（IND）はもともとフレームリレーネットワーク用に開発されましたが、同様の動作を持つ他のネットワークにも適用される場合があります。
Table of Contents
目次
1. Introduction.................................................... 3
2. Inverse Neighbor Discovery Messages............................. 3
2.1 Inverse Neighbor Discovery Solicitation Message............. 3
2.2 Inverse Neighbor Discovery Advertisement Message............ 5
3. Inverse Neighbor Discovery Options Format....................... 6
3.1 Target Address List......................................... 6
4. Inverse Neighbor Discovery Protocol............................. 9
4.1 Sender Node Processing...................................... 9
4.2 Receiver Node Processing.................................... 9
4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
4.3 Message Validation......................................... 10
4.3.1 Validation of Inverse Neighbor Discovery Solicitations. 10
4.3.2 Validation of Inverse Neighbor Discovery Advertisements 11
5. Security Considerations........................................ 12
6. IANA Considerations............................................ 13
7. Acknowledgments................................................ 13
8. References..................................................... 13
9. Authors' Addresses............................................. 14
Appendix A........................................................ 15
Full Copyright Statement.......................................... 20
This document defines extensions to the IPv6 Neighbor Discovery (ND)[IPv6-IND]. The extensions are called IPv6 Inverse Neighbor Discovery (IND). The IPv6 Inverse Neighbor Discovery (IND) allows a node that knows the link-layer address of a directly connected remote node to learn the IPv6 addresses of that node. A node using IND sends solicitations and receives advertisements for one or more IPv6 addresses corresponding to a known link-layer address.
このドキュメントでは、拡張機能をIPv6 Neighbor Discovery（ND）[IPv6-Ind]に定義しています。拡張機能は、IPv6逆近隣発見（IND）と呼ばれます。IPv6 Inverse Neighter Discovery（IND）により、直接接続されたリモートノードのリンク層アドレスを把握して、そのノードのIPv6アドレスを学習することができます。INDを使用したノードは、勧誘を送信し、既知のリンク層アドレスに対応する1つ以上のIPv6アドレスの広告を受け取ります。
The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.
逆隣接発見（IND）はもともとフレームリレーネットワーク用に開発されましたが、同様の動作を持つ他のネットワークにも適用される場合があります。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [KEYWORDS].
キーワードは、[キーワード]で定義されていると解釈されるべきではありません。
There are a number of similarities and differences between the mechanisms described here and those defined for Inverse ARP for IPv4 in [INV-ARP] or its replacement documents.
ここで説明するメカニズムと、[Inv-arp]またはその置換ドキュメントのIPv4の逆ARPに対して定義されているメカニズムとの間には、多くの類似点と相違があります。
The following messages are defined:
次のメッセージが定義されています。
A node sends an Inverse Neighbor Discovery Solicitation message to request an IPv6 address corresponding to a link-layer address of the target node while also providing its own link-layer address to the target. Since the remote node IPv6 addresses are not known, Inverse Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level, an IND Solicitation is sent directly to the target node, identified by the known link-layer address.
ノードは、ターゲットノードのリンク層アドレスに対応するIPv6アドレスを要求する逆近隣ディスカバリー勧誘メッセージを送信し、ターゲットに独自のリンク層アドレスを提供します。リモートノードIPv6アドレスは知られていないため、IPv6 All-Node Multicasts [IPv6]、[IPv6-Fr]、[[Encaps]として、逆近隣発見（IND）の勧誘が送信されます。ただし、リンクレイヤーレベルでは、既知のリンク層アドレスによって識別されるIND勧誘がターゲットノードに直接送信されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Source Address
An IPv6 address assigned to the interface from which this message
is sent.
Destination Address The IPv6 all-node multicast address. This address is specified in its link-scope format, which is FF02::1.
宛先アドレスIPv6オールノードマルチキャストアドレス。このアドレスは、FF02 :: 1であるリンクスコープ形式で指定されています。
Hop Limit 255
ホップ制限255
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination, then the sender SHOULD include this header.
認証ヘッダー送信者と宛先の間にIP認証ヘッダーのセキュリティ協会が存在する場合、送信者にはこのヘッダーを含める必要があります。
ICMP Fields:
ICMPフィールド：
Type 141
タイプ141
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
ICMPチェックサムのチェックサム。[icmpv6]を参照してください。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約されたこのフィールドは未使用です。送信者はゼロに初期化する必要があり、受信機は無視する必要があります。
Required options:
必要なオプション：
The sender node MUST send the following options in the Solicitation message:
送信者ノードは、勧誘メッセージに次のオプションを送信する必要があります。
Source Link-Layer Address The link-layer address of the sender.
ソースリンク層アドレス送信者のリンク層アドレス。
Target Link-Layer Address The link-layer address of the target node.
ターゲットリンク層アドレスターゲットノードのリンク層アドレス。
Other valid options:
その他の有効なオプション：
The sender node MAY choose to add the following options in the Solicitation message:
送信者ノードは、勧誘メッセージに次のオプションを追加することを選択できます。
Source Address List The list of one or more IPv6 addresses of the interface identified by the Source Link-Layer Address. This option is defined in section 3.
ソースアドレスリストソースリンクレイヤーアドレスによって識別されたインターフェイスの1つ以上のIPv6アドレスのリスト。このオプションは、セクション3で定義されています。
MTU The MTU configured for this link [IPv6-ND].
MTUこのリンク用に構成されたMTU [IPv6-ND]。
Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは、他のオプションタイプを追加する場合があります。受信者は、メッセージを認識していないオプションを静かに無視し、メッセージを処理し続ける必要があります。
A node sends Inverse Neighbor Discovery Advertisements in response to Inverse Neighbor Discovery Solicitations.
ノードは、逆近隣の発見の勧誘に応じて逆近隣発見広告を送信します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address An address assigned to the interface from which the advertisement is sent.
ソースアドレス広告が送信されるインターフェイスに割り当てられたアドレス。
Destination Address The Source Address of an invoking Inverse Discovery Neighbor Solicitation.
宛先アドレスは、逆発見の隣接する勧誘の呼び出しのソースアドレス。
Hop Limit 255
ホップ制限255
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
認証ヘッダー送信者と宛先アドレスの間にIP認証ヘッダーのセキュリティ協会が存在する場合、送信者はこのヘッダーを含める必要があります。
ICMP Fields:
ICMPフィールド：
Type 142
タイプ142
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
ICMPチェックサムのチェックサム。[icmpv6]を参照してください。
Reserved 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約された32ビット未使用フィールド。送信者はゼロに初期化する必要があり、受信機は無視する必要があります。
Required options:
必要なオプション：
The sender node MUST send the following options in the Advertisement message:
送信者ノードは、広告メッセージに次のオプションを送信する必要があります。
Source Link-Layer Address The link-layer address of the sender.
ソースリンク層アドレス送信者のリンク層アドレス。
Target Link-Layer Address The link-layer address of the target, that is, the sender of the advertisement.
ターゲットリンク層アドレスターゲットのリンク層アドレス、つまり広告の送信者。
Target Address List The list of one or more IPv6 addresses of the interface identified by the Target Link-Layer Address in the Inverse Neighbor Discovery Solicitation message that prompted this advertisement. This option is defined in Section 3.
ターゲットアドレスリストこの広告を促した逆近隣ディスカバリー勧誘メッセージのターゲットリンク層アドレスによって識別されたインターフェイスの1つ以上のIPv6アドレスのリスト。このオプションは、セクション3で定義されています。
Other valid options:
その他の有効なオプション：
The sender node MAY choose to add the following option in the Advertisement message:
送信者ノードは、広告メッセージに次のオプションを追加することを選択できます。
MTU The MTU configured for this link [IPv6-ND].
MTUこのリンク用に構成されたMTU [IPv6-ND]。
Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは、他のオプションタイプを追加する場合があります。受信者は、メッセージを認識していないオプションを静かに無視し、メッセージを処理し続ける必要があります。
Inverse Neighbor Discovery messages include Neighbor Discovery options [IPv6-ND] as well as an Inverse Neighbor Discovery specific options: the Source Address List and the Target Address List.
逆近隣の発見メッセージには、近隣発見オプション[IPv6-ND]、および逆近隣ディスカバリー固有のオプション：ソースアドレスリストとターゲットアドレスリストが含まれます。
The Source Address List and the Target Address List option are TLV options (type, length, variable size field) (see Section 4.6 of [IPv6-ND] with the following fields:
ソースアドレスリストとターゲットアドレスリストオプションは、TLVオプション（タイプ、長さ、可変サイズフィールド）です（次のフィールドを持つ[IPv6-ND]のセクション4.6を参照してください。
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 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~
|
+-+-+-+-+...
Fields:
田畑：
Type 9 for Source Address List 10 for Target Address List
ターゲットアドレスリストのソースアドレスリスト10のタイプ9
Note: These Option Type values should be assigned from the IPv6 Neighbor Discovery family of values.
注：これらのオプションタイプの値は、IPv6 Neighbor Discoveryファミリファミリから割り当てる必要があります。
Length The length of the option (including the Type, Length, and the Reserved fields) in units of 8 octets. The minimum value for Length is 3, for one IPv6 address.
長さ8オクテットの単位でのオプションの長さ（タイプ、長さ、および予約磁場を含む）。長さの最小値は、1つのIPv6アドレスの場合は3です。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約されたこのフィールドは未使用です。送信者はゼロに初期化する必要があり、受信機は無視する必要があります。
IPv6 Addresses One or more IPv6 addresses of the interface.
IPv6は、インターフェイスの1つ以上のIPv6アドレスをアドレス指定します。
Description:
説明：
The Source Address List contains a list of IPv6 addresses of the interface identified by the Source Link-Layer Address.
ソースアドレスリストには、ソースリンクレイヤーアドレスによって識別されたインターフェイスのIPv6アドレスのリストが含まれています。
The Target Address List contains a list of IPv6 addresses of the interface identified by the Target Link-Layer Address.
ターゲットアドレスリストには、ターゲットリンク層アドレスによって識別されたインターフェイスのIPv6アドレスのリストが含まれています。
The number of addresses "n" in the list is calculated based on the length of the option:
リスト内のアドレス「n」の数は、オプションの長さに基づいて計算されます。
n = (Length - 1)/2 (Length is the number of groups of 8 octets)
The Source Address List MUST fit in one IND Solicitation message. Therefore in case all IPv6 addresses of an interface do not fit in one messages, the option does not contain a complete list. For a complete list of IPv6 addresses, a node should rely on the IND Advertisement message.
ソースアドレスリストは、1つのIND勧誘メッセージに適合する必要があります。したがって、インターフェイスのすべてのIPv6アドレスが1つのメッセージに適合しない場合、オプションには完全なリストが含まれていません。IPv6アドレスの完全なリストの場合、ノードはIND広告メッセージに依存する必要があります。
The Target Address List SHOULD be the complete list of addresses of the interface identified by the Target Link-Layer Address. If the list of IPv6 addresses of an interface does not fit in one IND Advertisement message, one or more IND Advertisement messages, with the same fields as the first message, SHOULD follow. The Target Address List option(s) of the second, and subsequent message(s) SHOULD contain the rest of the IPv6 addresses of the interface identified by the Target Link-Layer Address, which did not fit in the first message.
ターゲットアドレスリストは、ターゲットリンクレイヤーアドレスによって識別されるインターフェイスのアドレスの完全なリストである必要があります。インターフェイスのIPv6アドレスのリストが1つのIND広告メッセージに適合しない場合、最初のメッセージと同じフィールドを持つ1つまたは複数のIND広告メッセージが従う必要があります。2番目のメッセージおよび後続のメッセージのターゲットアドレスリストリストオプションは、最初のメッセージに適合しないターゲットリンク層アドレスによって識別されたインターフェイスのIPv6アドレスの残りの部分を含める必要があります。
Note 1: The scope of the Inverse Neighbor Discovery mechanism is limited to IPv6 address discovery, that is, providing address mapping information. Therefore, it does not make any provisions or rules regarding how a node uses the addresses that were returned in an Inverse Discovery message. Furthermore, it does not exclude any particular type of IPv6 address from the Source or Target Address
注1：逆近隣発見メカニズムの範囲は、IPv6アドレス発見、つまりアドレスマッピング情報を提供することに限定されています。したがって、ノードが逆発見メッセージで返されたアドレスをどのように使用するかに関して、規定やルールを作成しません。さらに、ソースまたはターゲットアドレスから特定のタイプのIPv6アドレスを除外しません
List. For example, if an interface has manually configured, and autoconfigured addresses, including temporary ones, unicast, multicast, etc..., the list should not exclude any.
リスト。たとえば、インターフェイスが手動で構成され、一時的なもの、ユニキャスト、マルチキャストなどを含むAutoConfiguredアドレスがある場合、リストは除外すべきではありません。
Note 2: An implementation MUST NOT send duplicates in the IPv6 address list.
注2：実装は、IPv6アドレスリストに複製を送信してはなりません。
IND operates essentially the same as ND [IPv6-ND]: the solicitor of a target IP address sends on an interface a solicitation message, the target node responds with an advertisement message containing the information requested. The information learned MAY be stored in the Neighbor Discovery cache [IPv6-ND], as well as IPv6 address structures which may be associated with the interface.
INDは本質的にND [IPv6-ND]と同じように動作します。ターゲットIPアドレスの弁護士は、インターフェイスに勧誘メッセージを送信します。ターゲットノードは、要求された情報を含む広告メッセージで応答します。学習した情報は、インターフェイスに関連付けられる可能性のあるIPv6アドレス構造と同様に、Neighbor Discoveryキャッシュ[IPv6-ND]に保存される場合があります。
A soliciting node formats an IND Solicitation message as defined in a previous section, encapsulates the packet for the specific link-layer and sends it directly to the target node. Although the destination IP address is the all-node multicast address, the message is sent only to the target node. The significant fields for the IND protocol are the Source IP address, the Source link-layer address, the Target link-layer address, and the MTU. The latter can be used in setting the optimum value of the MTU for the link.
勧誘ノードは、前のセクションで定義されているIND勧誘メッセージをフォーマットし、特定のリンク層のパケットをカプセル化し、ターゲットノードに直接送信します。宛先IPアドレスはAll-Node Multicastアドレスですが、メッセージはターゲットノードにのみ送信されます。INDプロトコルの重要なフィールドは、ソースIPアドレス、ソースリンク層アドレス、ターゲットリンク層アドレス、およびMTUです。後者は、リンクにMTUの最適値を設定する際に使用できます。
While awaiting a response, the sender SHOULD retransmit IND Solicitation messages approximately every RetransTimer (expiration)[IPv6-ND], even in the absence of additional traffic to the neighbor. Retransmissions MUST be rate-limited to at most one solicitation per neighbor every RetransTimer.
応答を待っている間、送信者は、隣人への追加のトラフィックがない場合でも、ほぼすべてのRetranStimer（有効期限）[IPv6-ND]にIND勧誘メッセージを再送信する必要があります。レトランミッションは、レトランスティマーごとに隣人ごとにせいぜい1つの勧誘に対して料金制限されなければなりません。
If no IND Advertisement is received after MAX_MULTICAST_SOLICIT [IPv6-ND] solicitations, inverse address resolution has failed. If the sending of the Solicitation was required by an upper-layer, the sender module MUST notify the error to the upper-layer through an appropriate mechanism (e.g., return value from a procedure call).
max_multicast_solicit [ipv6-nd]勧誘後にIND広告が受信されない場合、逆アドレス解決が失敗しました。勧誘の送信が上層層によって必要な場合、送信者モジュールは、適切なメカニズムを介して上層層にエラーに通知する必要があります（たとえば、手順呼び出しからの返品値）。
For every IND Solicitation, the receiving node SHOULD format in response a proper IND Advertisement using the link-layer source and target address pair as well as the IPv6 source address from the IND Solicitation message.
すべてのIND勧誘について、受信ノードは、IND SolicitationメッセージのIPv6ソースアドレスと同様に、リンク層ソースとターゲットアドレスペアを使用した適切なIND広告に応じてフォーマットする必要があります。
If a node updates the Neighbor Discovery Cache with information learned from IND messages, the receiver node of the IND Solicitation SHOULD put the sender's IPv6 address/link-layer address mapping - i.e., the source IP address and the Source link-layer address from the solicitation message - into its ND cache [IPv6-ND] as it would for a ND solicitation.
NodeがINDメッセージから学習した情報でNeighbor Discoveryキャッシュを更新する場合、IND勧誘の受信ノードは、送信者のIPv6アドレス/リンクレイヤーアドレスマッピング - つまり、ソースIPアドレスとソースリンクレイヤーアドレスを、勧誘メッセージ - nd勧誘のように、そのndキャッシュ[IPv6 -Nd]に。
Because IPv6 nodes may have multiple IPv6 addresses per interface, a node responding to an IND Solicitation SHOULD return in the Target Address List option a list containing one or more IPv6 addresses corresponding to the interface identified by the Target Link-Layer Address field in the solicitation message. The list MUST not contain duplicates.
IPv6ノードはインターフェイスごとに複数のIPv6アドレスを持っている可能性があるため、IND勧誘に応答するノードは、ターゲットアドレスリストオプションで返す必要があります。メッセージ。リストには複製を含めてはなりません。
If a node updates The Neighbor Discovery Cache with information learned from IND messages, the receiver node of the IND advertisement SHOULD put the sender's IPv6 address/link-layer address mapping - i.e., the IP addresses from Target addresses list and the Source link-layer address from the IND advertisement message - into its ND cache [IPv6-ND] as it would for a ND advertisement.
NodeがINDメッセージから学習した情報でNeighbor Discoveryキャッシュを更新する場合、IND広告のレシーバーノードは、送信者のIPv6アドレス/リンクレイヤーアドレスマッピング、つまりターゲットアドレスリストとソースリンクレイヤーのIPアドレスを配置する必要があります。Ind Advertisementメッセージからのアドレス-ND Cache [IPv6 -ND]には、ADND広告のように。
Inverse Neighbor Discovery messages are validated as follows:
逆近隣の発見メッセージは次のように検証されます。
A node MUST silently discard any received Inverse Neighbor Solicitation messages that do not satisfy all of the following validity checks:
ノードは、以下のすべての妥当性チェックを満たさない逆隣接する勧誘メッセージを静かに破棄する必要があります。
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IPホップリミットフィールドの値は255です。つまり、パケットはルーターによって転送される可能性がありませんでした。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
- ICMP Checksum is valid.
- ICMPチェックサムは有効です。
- ICMP Code is 0.
- ICMPコードは0です。
- ICMP length (derived from the IP length) is 24 or more octets.
- ICMPの長さ（IPの長さから派生）は24以上のオクテットです。
- The Target Link-Layer Address is a required option and MUST be present.
- ターゲットリンク層アドレスは必要なオプションであり、存在する必要があります。
- The Source Link-Layer Address is a required option and MUST be present.
- ソースリンク層アドレスは必要なオプションであり、存在する必要があります。
- All included options have a length that is greater than zero.
- 含まれるすべてのオプションには、ゼロより大きい長さがあります。
The content of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
予約済みのフィールドと認識されていないオプションのコンテンツは無視する必要があります。プロトコルの将来の後方互換の変更は、予約済みフィールドの内容を指定したり、新しいオプションを追加したりする場合があります。逆方向に不可能な変更は、異なるコード値を使用する場合があります。
The contents of any Neighbor Discovery [IPv6-ND] options that are not specified to be used with Inverse Neighbor Discovery Solicitation messages MUST be ignored and the packet processed as normal. The only defined option that may appear besides the required options is the MTU option.
逆近隣ディスカバリー勧誘メッセージで使用するように指定されていない隣接する[IPv6-ND]オプションの内容は無視し、パケットを通常どおり処理する必要があります。必要なオプション以外に表示される可能性のある定義されたオプションは、MTUオプションです。
An Inverse Neighbor Solicitation that passes the validity checks is called a "valid solicitation".
有効性チェックに合格する逆近隣の勧誘は、「有効な勧誘」と呼ばれます。
A node MUST silently discard any received Inverse Neighbor Discovery Advertisement messages that do not satisfy all of the following validity checks:
ノードは、以下のすべての有効性チェックを満たさない、受信した逆近隣発見広告メッセージを静かに破棄する必要があります。
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
- IPホップリミットフィールドの値は255です。つまり、パケットはルーターによって転送される可能性がありませんでした。
- If the message includes an IP Authentication Header, the message authenticates correctly.
- メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
- ICMP Checksum is valid.
- ICMPチェックサムは有効です。
- ICMP Code is 0.
- ICMPコードは0です。
- ICMP length (derived from the IP length) is 48 or more octets.
- ICMPの長さ（IPの長さから派生）は48以上のオクテットです。
- Source Link-Layer Address option is present.
- ソースリンク層アドレスオプションが存在します。
- Target Link-Layer Address option is present.
- ターゲットリンク層アドレスオプションが存在します。
- The Target Address List option is present.
- ターゲットアドレスリストオプションが存在します。
- The length of the Target Address List option is at least 3.
- ターゲットアドレスリストオプションの長さは少なくとも3です。
- All other included options have a length that is greater than zero.
- 他のすべてのオプションには、ゼロより大きい長さがあります。
The contents of the Reserved fields, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved fields or add new options; backward-incompatible changes may use different Code values.
予約済みのフィールドと認識されていないオプションの内容は無視する必要があります。プロトコルの将来の後方互換の変更は、予約済みフィールドの内容を指定したり、新しいオプションを追加したりする場合があります。逆方向に不可能な変更は、異なるコード値を使用する場合があります。
The contents of any defined options [IPv6-ND] that are not specified to be used with Inverse Neighbor Advertisement messages MUST be ignored and the packet processed as normal. The only defined option that may appear besides the required options is the MTU option.
逆近隣広告メッセージで使用するように指定されていない定義されたオプション[IPv6-ND]の内容は無視し、パケットを通常どおり処理する必要があります。必要なオプション以外に表示される可能性のある定義されたオプションは、MTUオプションです。
An Inverse Neighbor Advertisement that passes the validity checks is called a "valid advertisement".
有効性チェックに合格する逆近隣広告は、「有効な広告」と呼ばれます。
When being employed on point to point virtual circuits, as it is the case with Frame Relay networks, Inverse Neighbor Discovery messages are less sensitive to impersonation attacks from on-link nodes, as it would be the case with broadcast links.
Frame Relay Networksの場合と同様に、Point-to Point Virtual Circuitsで採用されている場合、逆近隣のディスカバリーメッセージは、放送リンクの場合のように、オンリンクノードからのなりすまし攻撃に敏感ではありません。
Like Neighbor Discovery, the protocol reduces the exposure to threats from off-link nodes in the absence of authentication by ignoring IND packets received from off-link senders. The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor.
近隣の発見と同様に、このプロトコルは、オフリンク送信者から受信したINDパケットを無視することにより、認証がない場合に、オフリンクノードからの脅威への暴露を減らします。受信したすべてのパケットのホップ制限フィールドは、最大法的価値である255を含むように確認されています。ルーターが転送されるすべてのパケットのホップ制限を減らすため、255のホップ制限を含むパケットを受け取ったパケットを受け取ったため、隣人から発信されている必要があります。
Inverse Neighbor Discovery protocol packet exchanges can be authenticated using the IP Authentication Header [IPSEC-Auth]. A node SHOULD include an Authentication Header when sending Inverse Neighbor Discovery packets 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認証ヘッダー[IPSEC-Auth]を使用して、逆近隣ディスカバリープロトコルパケット交換を認証できます。宛先アドレスにIP認証ヘッダーに使用するセキュリティアソシエーションが存在する場合、ノードには逆近隣ディスカバリーパケットを送信するときに認証ヘッダーを含める必要があります。セキュリティ協会は、手動構成またはいくつかの主要な管理プロトコルの操作を通じて作成された可能性があります。
Received Authentication Headers in Inverse Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored.
逆近隣ディスカバリーパケットの受信認証ヘッダーは、正確さを検証する必要があり、誤った認証を伴うパケットは無視する必要があります。
In case of use with Frame Relay, to avoid an IP Security Authentication verification failure, the Frame Relay specific preprocessing of a Neighbor Discovery Solicitation message that contains a DLCI format Source link-layer address option, MUST be done by the receiver node after it completed IP Security processing.
Frame Relayで使用した場合、IPセキュリティ認証検証の障害を回避するために、DLCI形式のソースリンクレイヤーアドレスオプションを含むNeighbor Discovery Solicitationメッセージのフレームリレー固有のプレセシングは、Receiverノードが完了した後に実行する必要があります。IPセキュリティ処理。
It SHOULD be possible for the system administrator to configure a node to ignore any Inverse Neighbor Discovery messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages.
システム管理者がノードを構成して、認証ヘッダーまたはセキュリティペイロードをカプセル化することを使用して認証されていない逆近隣ディスカバリーメッセージを無視することができるはずです。このようなスイッチは、不正なメッセージを許可するようにデフォルトでなければなりません。
Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC-ESP].
機密性の問題は、IPセキュリティアーキテクチャとセキュリティペイロードドキュメントをカプセル化するIPが対処します[IPSEC]、[IPSEC-ESP]。
IANA was requested to assign two new ICMPv6 type values, as described in Section 2.1 and 2.2. They were assigned from the Informational range of messages, as defined in Section 2.1 of RFC 2463. There were no ICMPv6 code values defined for these types (other than 0); future assignments are to be made under Standards Action as defined in RFC 2434.
IANAは、セクション2.1および2.2で説明されているように、2つの新しいICMPV6タイプの値を割り当てるように要求されました。これらは、RFC 2463のセクション2.1で定義されている情報の範囲から割り当てられました。これらのタイプに対して定義されたICMPV6コード値はありませんでした（0以外）。将来の割り当ては、RFC 2434で定義されている標準訴訟の下で行われます。
IANA was also requested to assign two new ICMPv6 Neighbor Discovery Option types as defined in Section 3.1. No outside reviewing was necessary.
IANAは、セクション3.1で定義されているように、2つの新しいICMPV6ネイバーディスカバリーオプションタイプを割り当てることも要求されました。外部のレビューは必要ありませんでした。
Thanks to Steve Deering, Thomas Narten and Erik Nordmark for discussing the idea of Inverse Neighbor Discovery. Thanks to Thomas Narten, and Erik Nordmark, and also to Dan Harrington, Milan Merhar, Barbara Fox, Martin Mueller, and Peter Tam for a thorough reviewing.
Steve Deering、Thomas Narten、Erik Nordmarkに感謝します。Thomas NartenとErik Nordmark、そしてDan Harrington、Milan Merhar、Barbara Fox、Martin Mueller、およびPeter Tamにも感謝します。
Also it should be acknowledged that parts of the text in this specification derived from the IPv6 Neighbor Discovery text [IPv6- ND].
また、この仕様のテキストの一部がIPv6 Neighbor Discoveryテキスト[IPv6-nd]から派生したことを認められるべきです。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998.
[IPv6] Deering、S。およびR. Hinden、「インターネットプロトコルバージョン6仕様」、RFC 2460、1998年12月。
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPv6-ND] Narten、T.、Nordmark、E。、およびW. Simpson「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[ICMPv6] Conta, A., and S. Deering "Internet Control Message Protocol for the Internet Protocol Version 6", RFC 2463, December 1998.
[ICMPV6] Conta、A。、およびS. Deering「インターネットプロトコルバージョン6のインターネット制御メッセージプロトコル」、RFC 2463、1998年12月。
[IPv6-FR] Conta, A., Malis, A. and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks", RFC 2590, May 1999. December 1997.
[IPv6-Fr] Conta、A.、Malis、A。、およびM. Mueller、「フレームリレーネットワーク上のIPv6パケットの送信」、RFC 2590、1999年5月。1997年12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Atkinson、R。およびS. Kent、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402, December 1998.
[Ipsec-auth] Atkinson、R。and S. Kent、「IP認証ヘッダー」、RFC 2402、1998年12月。
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[Ipsec-esp] Atkinson、R。and S. Kent、「IPがセキュリティプロトコル（ESP）をカプセル化する」、RFC 2406、1998年11月。
[ASSIGN] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, March 1994.
[割り当て] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年3月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, November 1998.
[Encaps] Brown、C。and A. Malis、「Multiprotocol Interconnect over Frame Relay」、RFC 2427、1998年11月。
[INV-ARP] Bradley, T., Brown, C. and A. Malis "Inverse Address Resolution Protocol", RFC 2390, August 1998.
[Inv-Arp] Bradley、T.、Brown、C。and A. Malis「逆住所解像度プロトコル」、RFC 2390、1998年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484
Alex Conta Transwitch Corporation 3エンタープライズドライブシェルトン、コネチカット06484
Phone: +1-203-929-8810
EMail: aconta@txc.com
A. Inverse Neighbor Discovery with Frame Relay Networks
A.フレームリレーネットワークを使用した逆近隣発見
This appendix documents the details of using the Inverse Neighbor Discovery on Frame Relay Networks, which were too specific to be part of the more general content of the previous sections.
この付録には、以前のセクションのより一般的なコンテンツの一部ではないほど具体的だったフレームリレーネットワークで逆近隣発見を使用する詳細を文書化しています。
The Inverse Neighbor Discovery (IND) specifically applies to Frame Relay nodes. Frame Relay permanent virtual circuits (PVCs) and switched virtual circuits (SVCs) are identified in a Frame Relay network by a Data Link Connection Identifier (DLCI). Each DLCI defines for a Frame Relay node a single virtual connection through the wide area network (WAN). A DLCI has in general a local significance.
逆近隣発見（IND）は、フレームリレーノードに特に適用されます。フレームリレー永久仮想回路（PVC）とスイッチ付き仮想回路（SVC）は、データリンク接続識別子（DLCI）によってフレームリレーネットワークで識別されます。各DLCIは、Frame Relayノードに対して、広い領域ネットワーク（WAN）を介して単一の仮想接続を定義します。DLCIには一般的に局所的な重要性があります。
By way of specific signaling messages, a Frame Relay network may announce to a node a new virtual circuit with its corresponding DLCI. The DLCI identifies to a node a virtual circuit, and can be used as the equivalent of a remote node link-layer address, allowing a node to identify at link layer level the node at the other end of the virtual circuit. For instance in Figure 1., node A (local node) identifies the virtual circuit to node B (remote node) by way of DLCI = 30. However, the signaling message does not contain information about the DLCI used by a remote node to identify the virtual circuit to the local node, which could be used as the equivalent of the local link-layer address. For instance in Figure 1., node B (remote node) may identify the virtual circuit to node A by way of DLCI = 62.
特定のシグナル伝達メッセージとして、フレームリレーネットワークは、対応するDLCIを備えた新しい仮想回路をノードに発表する場合があります。DLCIは仮想回路をノードに識別し、リモートノードリンクレイヤーアドレスに相当するものとして使用でき、ノードがリンクレイヤーレベルで仮想回路の反対側のノードを識別できるようにします。たとえば、図1のように、ノードA（ローカルノード）は、DLCI = 30でノードB（リモートノード）への仮想回路を識別します。ただし、シグナリングメッセージには、リモートノードが使用するDLCIに関する情報は含まれていません。ローカルノードへの仮想回路は、ローカルリンク層アドレスに相当するものとして使用できます。たとえば、図1の場合、ノードB（リモートノード）は、DLCI = 62を使用して、仮想回路をノードAに識別する場合があります。
Furthermore, the message being transmitted at link-layer level and completely independent of the IPv6 protocol does not include any IPv6 addressing information. The Inverse Neighbor Discovery is a protocol that allows a Frame Relay node to discover the equivalent of a local link layer address, that is, the identifier by way of which remote nodes identify the node, and more importantly discover the IPv6 addresses of the interface at the other end of the virtual circuit, identified by the remote link-layer address.
さらに、Link-Layerレベルで送信され、IPv6プロトコルとは完全に独立しているメッセージには、IPv6アドレス指定情報は含まれていません。逆近隣発見は、フレームリレーノードがローカルリンクレイヤーアドレスに相当するもの、つまりリモートノードがノードを識別し、より重要なことにインターフェイスのIPv6アドレスを発見する識別子を発見できるようにするプロトコルです。リモートリンク層アドレスで識別される仮想回路のもう一方の端。
~~~~~~~~~~~ Remote
{ } Node
+-----+ DLCI { } DLCI+-----+
| A |-30------{--+----+----+--}---------62-| B |
+-----+ { } +-----+
Local { } Frame Relay
Node ~~~~~~~~~~~ Network Cloud
Figure 1.
The IPv6 Inverse Neighbor Discovery (IND) protocol allows a Frame Relay node to discover dynamically the DLCI by which a remote node identifies the virtual circuit. It also allows a node to learn the IPv6 addresses of a node at the remote end of a virtual circuit.
IPv6 Inverse Neighter Discovery（IND）プロトコルにより、フレームリレーノードは、リモートノードが仮想回路を識別するDLCIを動的に発見できます。また、ノードが仮想回路のリモートエンドでノードのIPv6アドレスを学習することもできます。
Frame Relay nodes generate Inverse Neighbor Discovery messages as follows:
フレームリレーノードは、次のように逆近隣ディスカバリーメッセージを生成します。
The sender of an Inverse Neighbor Discovery Solicitation does not know the remote node's IPv6 addresses, but knows the equivalent of a remote node link-layer address. Inverse Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level, an IND Solicitation is sent directly to the target node, identified by the known link-layer address (DLCI).
逆隣接の発見勧誘の送信者は、リモートノードのIPv6アドレスを知らないが、リモートノードリンク層アドレスに相当するものを知っている。逆近隣発見（IND）の勧誘は、IPv6 All-Node Multicasts [IPv6]、[IPv6-Fr]、[cankaps]として送信されます。ただし、リンクレイヤーレベルでは、既知のリンク層アドレス（DLCI）によって識別されるIND勧誘がターゲットノードに直接送信されます。
The fields of the message, which are filled following considerations specific to Frame Relay are:
フレームリレーに固有の考慮事項に従って満たされているメッセージのフィールドは次のとおりです。
Source Link-Layer Address For the sender Frame Relay node, the Source Link-Layer Address is the equivalent of the link-layer address by which the remote node identifies the source of this message. The sender may have no knowledge of this information. If the sender knows the information, it SHOULD include it in the field, otherwise it SHOULD live it zero (empty). This information, if present, can be used for network debugging purposes. Regardless of the sender's action on this field, prior to any Inverse Neighbor Discovery processing, the receiver of this message replaces this field, whether filled in or not by the sender, with information carried by the Frame Relay header in the DLCI field. The field is encoded in DLCI format as defined by [IPv6-FR].
送信者フレームリレーノードのソースリンク層アドレス、ソースリンク層アドレスは、リモートノードがこのメッセージのソースを識別するリンク層アドレスに相当します。送信者は、この情報の知識がない場合があります。送信者が情報を知っている場合、それはフィールドにそれを含める必要があります。そうしないと、それをゼロ（空）に生きる必要があります。この情報は、存在する場合、ネットワークデバッグの目的で使用できます。このフィールドでの送信者のアクションに関係なく、逆近隣の発見処理の前に、このメッセージの受信者は、送信者が満たしているかどうかにかかわらず、このフィールドに置き換えられ、DLCIフィールドのフレームリレーヘッダーが掲載した情報を使用します。このフィールドは、[IPv6-Fr]で定義されているDLCI形式でエンコードされています。
Target Link-Layer Address For sender Frame Relay node, the Target Link-Layer Address field is filled with the value known as the equivalent of the target node link-layer address. This value is the DLCI of the VC to the target node. It is encoded in DLCI format [IPv6-FR].
Sender Frame Relayノードのターゲットリンク層アドレス、ターゲットリンクレイヤーアドレスフィールドは、ターゲットノードリンクレイヤーアドレスに相当する値と呼ばれる値で満たされています。この値は、ターゲットノードへのVCのDLCIです。DLCI形式[IPv6-Fr]でエンコードされています。
To illustrate the generating of a IND Solicitation message by a Frame Relay node, let's consider as an example Node A (Figure 1.) which sends an IND solicitation to Node B. The Solicitation message fields will have the following values:
フレームリレーノードによるIND勧誘メッセージの生成を説明するために、ノードBにIND勧誘を送信する例のノードA（図1.）として考えてみましょう。勧誘メッセージフィールドには次の値があります。
At Node A (sender of the IND solicitation message).
ノードA（IND勧誘メッセージの送信者）。
Source Link-Layer Address DLCI=unknown (overwritten by the receiver).
ソースリンク層アドレスDLCI =不明（レシーバーによって上書き）。
Target Link-Layer Address DLCI=30.
ターゲットリンク層アドレスDLCI = 30。
At Node B (receiver of the IND solicitation message).
ノードB（IND勧誘メッセージの受信者）。
Source Link-Layer Address DLCI=62 (filled in by the receiver).
ソースリンク層アドレスDLCI = 62（受信機が埋めます）。
Target Link-Layer Address DLCI=30.
ターゲットリンク層アドレスDLCI = 30。
Note: For Frame Relay, both the above addresses are in Q.922 format (DLCI), which can have 10 (default), or 23 significant addressing bits [IPv6-FR]. The option length (link-layer address) is expressed in 8 octet units, therefore, the DLCI will have to be extracted from the 8 bytes based on the EA field (bit 0) of the second, third, or forth octet (EA = 1). The C/R, FECN, BECN, DE fields in the Q.922 address have no significance for IND and are set to 0 [IPv6-FR].
注：フレームリレーの場合、上記のアドレスは両方ともQ.922形式（DLCI）で、10（デフォルト）または23の重要なアドレス指定ビット[IPv6-Fr]を持つことができます。オプションの長さ（リンク層アドレス）は8オクテット単位で表されるため、DLCIは、2番目、3番目、またはフォースオクテット（EA =のEAフィールド（ビット0）に基づいて8バイトから抽出する必要があります。1）。Q.922アドレスのC/R、FECN、BECN、DEフィールドは、INDにとって重要ではなく、0 [IPv6-Fr]に設定されています。
MTU The value filled in the MTU option is the MTU for the virtual circuit identified by the known DLCI [IPv6-FR].
MTU MTUオプションに記入された値は、既知のDLCI [IPv6-Fr]によって識別される仮想回路のMTUです。
A Frame Relay node sends Inverse Neighbor Discovery Advertisements in response to Inverse Neighbor Discovery Solicitations.
フレームリレーノードは、逆近隣の発見の勧誘に応じて逆近隣発見広告を送信します。
The fields of the message, which are filled following considerations specific to Frame Relay are: Source Link-Layer Address For Frame Relay, this field is copied from the Target link-layer address field of the Inverse Neighbor Discovery Solicitation. It is encoded in DLCI format [IPv6-FR].
フレームリレーに固有の考慮事項に従って埋めるメッセージのフィールドは次のとおりです。フレームリレーのソースリンクレイヤーアドレスでは、このフィールドは、逆近隣発見勧誘のターゲットリンクレイヤーアドレスフィールドからコピーされます。DLCI形式[IPv6-Fr]でエンコードされています。
Target Link-Layer Address For Frame Relay, this field is copied from the Source link-layer address field of the Inverse Neighbor Discovery Solicitation. It is encoded in DLCI format [IPv6-FR].
フレームリレーのターゲットリンクレイヤーアドレス、このフィールドは、逆隣接ディスカバリー勧誘のソースリンクレイヤーアドレスフィールドからコピーされます。DLCI形式[IPv6-Fr]でエンコードされています。
For example if Node B (Figure 1.) responds to an IND solicitation sent by Node A. with an IND advertisement, these fields will have the following values:
たとえば、ノードB（図1.）がノードAから送信されたIND勧誘に応答した場合、IND広告を使用して、これらのフィールドには次の値があります。
At Node B (sender of the advertisement message):
ノードB（広告メッセージの送信者）：
Source Link-Layer Address DLCI=30 (was Target in Solicitation Message).
ソースリンク層アドレスDLCI = 30（勧誘メッセージのターゲットでした）。
Target Link-Layer Address DLCI=62 (was Source in Solicitation Message).
ターゲットリンク層アドレスDLCI = 62（勧誘メッセージのソースでした）。
At Node A (receiver of the advertisement message from B).
ノードA（bからの広告メッセージの受信者）。
Source Link-Layer Address DLCI=30 (was Target in Solicitation Message).
ソースリンク層アドレスDLCI = 30（勧誘メッセージのターゲットでした）。
Target Link-Layer Address DLCI=62 (was Source in Solicitation Message).
ターゲットリンク層アドレスDLCI = 62（勧誘メッセージのソースでした）。
Target Address List The list of one or more IPv6 addresses of the interface identified by the Target Link-Layer Address in the Inverse Neighbor Discovery Solicitation message that prompted this advertisement.
ターゲットアドレスリストこの広告を促した逆近隣ディスカバリー勧誘メッセージのターゲットリンク層アドレスによって識別されたインターフェイスの1つ以上のIPv6アドレスのリスト。
MTU The MTU configured for this link (virtual circuit) [IPv6-ND].
MTUこのリンク用に構成されたMTU（仮想回路）[IPv6-ND]。
Note: In case of Frame Relay networks, the IND messages are sent on a virtual circuit, which acts like a virtual-link. If the virtual circuit breaks, all participants to the circuit receive appropriate link layer signaling messages, which can be propagated to the upper layers, including IPv6.
注：フレームリレーネットワークの場合、INDメッセージは仮想回路で送信され、仮想リンクのように機能します。仮想回路が壊れた場合、回路のすべての参加者は適切なリンク層シグナル伝達メッセージを受信します。これは、IPv6を含む上層に伝播できます。
This section of the appendix documents only the specific aspects of Inverse Neighbor Discovery with Frame Relay Networks.
付録のこのセクションは、フレームリレーネットワークを使用した逆隣接発見の特定の側面のみを文書化しています。
A soliciting Frame Relay node formats an IND solicitation message as defined in a previous section, encapsulates the packet for the Frame Relay link-layer [IPv6-FR] and sends it to the target Frame Relay node. Although the destination IP address is the IPv6 all-node multicast address, the message is sent only to the target Frame Relay node. The target node is the known remote node on the link represented by the virtual circuit.
勧誘フレームリレーノードは、前のセクションで定義されているIND勧誘メッセージをフォーマットし、フレームリレーリンク層[IPv6-Fr]のパケットをカプセル化し、ターゲットフレームリレーノードに送信します。宛先IPアドレスはIPv6 All-Nodeマルチキャストアドレスですが、メッセージはターゲットフレームリレーノードにのみ送信されます。ターゲットノードは、仮想回路で表されるリンク上の既知のリモートノードです。
A Frame Relay node, before further processing, is replacing in the Source link-layer address the existent DLCI value with the DLCI value from the Frame Relay header of the frame containing the message. The DLCI value has to be formatted appropriately in the Source link-layer address field [IPv6-FR]. This operation is required to allow a correct interpretation of the fields in the further processing of the IND solicitation message.
さらに処理する前に、フレームリレーノードは、メッセージを含むフレームのフレームリレーヘッダーのDLCI値に存在するDLCI値をソースリンク層アドレスに置き換えます。DLCI値は、ソースリンク層アドレスフィールド[IPv6-FR]で適切にフォーマットする必要があります。この操作は、IND勧誘メッセージのさらなる処理においてフィールドの正しい解釈を許可するために必要です。
For a Frame Relay node, the MTU value from the solicitation message MAY be used to set the receiver's MTU to a value that is more optimal, in case that was not already done at the interface configuration time.
フレームリレーノードの場合、勧誘メッセージのMTU値を使用して、インターフェイス構成時間でまだ行われていない場合に備えて、レシーバーのMTUをより最適な値に設定できます。
The receiver Frame Relay node of the IND Advertisement MAY put the sender's IPv6 address/link-layer address mapping - i.e., the Target IP addresses and the Source link-layer address from the IND advertisement message - into its ND cache [IPv6-ND] as it would for a ND Advertisement.
IND広告のレシーバーフレームリレーノードは、送信者のIPv6アドレス/リンクレイヤーアドレスマッピング - つまり、ターゲットIPアドレスとIND広告メッセージからのソースリンクレイヤーアドレスをndキャッシュに配置する場合があります[IPv6-ND]それはnd広告のためにそうです。
Further, the receiver Frame Relay node of the IND Advertisement MAY store the Target link-layer address from the message as the DLCI value at the remote end of the VC. This DLCI value is the equivalent of the link-layer address by which the remote node identifies the receiver.
さらに、IND広告のレシーバーフレームリレーノードは、VCのリモートエンドにDLCI値としてターゲットリンクレイヤーアドレスをメッセージから保存できます。このDLCI値は、リモートノードが受信機を識別するリンク層アドレスに相当します。
If the receiver node of the IND Advertisement has a pool of IPv6 addresses, and if the implementation allows, it may take decisions to pairing specific local IPv6 addresses to specific IPv6 addresses from the target list in further communications on the VC. More specifically, such a pairing may be based on IPv6 addresses being on the same subnet, that is having the same prefix.
IND広告のレシーバーノードにIPv6アドレスのプールがあり、実装が許可されている場合、VCのさらなる通信のターゲットリストから特定のローカルIPv6アドレスを特定のIPv6アドレスにペアリングすることを決定することができます。より具体的には、このようなペアリングは、同じ接頭辞を持っている同じサブネット上にあるIPv6アドレスに基づいている可能性があります。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。