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
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.
著作権（C）インターネット協会（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近隣探索（ND）のIPv6-IND]への拡張を定義します。拡張機能は、IPv6の逆近隣探索（IND）と呼ばれています。 IPv6の逆近隣探索（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].
[KEYWORDS]で定義されるように、キーワード推奨なければならならず、MAY、OPTIONAL、REQUIREDは、、、、、解釈されるべきではないべきでないものとSHALL。
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アドレスが知られていないので、逆近隣探索（IND）要請は、IPv6のすべてのノードがマルチキャスト[IPv6の]、として送信される[たIPv6-FR]、[ENCAPS]。しかしながら、リンク層レベルで、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.
ソースは、このメッセージが送られるインタフェースに割り当てられたIPv6アドレス。
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.
送信元アドレスリストソースリンク層アドレスによって識別されるインターフェイスの一の以上の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.
ターゲットアドレス一覧この広告を促し逆近隣探索要請メッセージにターゲットリンク層アドレスによって識別されるインターフェイスの一の以上の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:
送信元アドレスリストと目標アドレスリストオプション、次のフィールドで（[IPv6の-ND]のセクション4.6を参照してくださいTLVのオプション（タイプ、長さ、可変サイズのフィールド）は次のとおりです。
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の近隣探索家族から割り当てる必要があります。
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は、インタフェースの一つまたは複数の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)
N =（長さ - 1）/ 2（長さが8つのオクテットのグループの数です）
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 Advertisementメッセージに依存している必要があります。
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広告メッセージ、一つ以上のIND広告メッセージに収まらない場合は、従うべきです。ターゲットアドレス一覧の第二の選択肢（複数可）、およびその後のメッセージ（複数可）の最初のメッセージに適合していないターゲットリンク層アドレス、によって識別されるインターフェイスの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.
リスト。インターフェイスは手動で構成、およびなど一時的なもの、ユニキャスト、マルチキャスト、を含む、アドレスを自動設定している場合たとえば、...、リストには、いずれかを除外するべきではありません。
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の-ND]、ならびにIPv6アドレス構造体に格納されてもよいです。
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アドレスは、全ノードマルチキャストアドレスであるが、メッセージがターゲット・ノードにのみ送信されます。 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要請メッセージを再送信すべきです。再送は、あらゆるRetransTimerレート制限隣人あたり最大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).
何IND広告がMAX_MULTICAST_SOLICIT [たIPv6-ND]要請した後に受信されない場合、逆アドレス解決が失敗しました。要請の送信上位層により要求された場合、送信側モジュールは、適切な機構（プロシージャ・コールから、例えば、戻り値）を介して上位層にエラーを通知しなければなりません。
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要請メッセージから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.
ノードはINDメッセージから学んだ情報で近隣探索キャッシュを更新した場合は、IND要請の受信ノードは、送信元のIPv6アドレス/リンク層アドレスのマッピングを置くべきである - すなわち、送信元IPアドレスからのソースリンク層アドレス要請メッセージ - そのNDキャッシュ[IPv6の-ND]それは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要請に応答ノードは、目標アドレスリストオプションで勧誘にターゲットリンク層アドレスフィールドによって識別されるインターフェイスに対応する1つの以上のIPv6アドレスを含むリストを返すべきですメッセージ。リストには、重複を含めることはできません。
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.
ノード情報と近隣探索キャッシュがINDメッセージから学んだ更新した場合は、IND広告の受信ノードが送信元のIPv6アドレス/リンク層アドレスのマッピングに置く必要があります - すなわち、ターゲットからのIPアドレスがリストとソース・リンク層を扱いますIND広告メッセージからアドレス - そのNDキャッシュ[IPv6の-ND]それはNDの広告の場合と同じように。
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.
- （IP長に由来する）ICMP長さは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.
- （IP長に由来する）ICMP長さは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.
それはフレームリレーネットワークの場合のように、仮想回路をポイントツーポイントに採用された場合には、ブロードキャストリンクの場合のように、逆近隣探索メッセージは、上のリンクのノードからのなりすまし攻撃にあまり敏感ではありません。
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.
それが完了した後、フレームリレーで使用する場合は、IPセキュリティ認証の検証の失敗を避けるために、DLCIフォーマットソースリンク層アドレスオプションが含まれている近隣探索要請メッセージのフレームリレーの特定の前処理は、受信ノードによって行われなければなりませんIP Securityの処理。
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.
セクション2.1および2.2に記載されるようにIANAは、二つの新しいのICMPv6タイプ値を割り当てるように要求しました。 （0を除く）これらのタイプのために定義されたICMPv6コード値はなかったRFC 2463.のセクション2.1で定義されるように、それらは、メッセージの情報の範囲から割り当てました。将来の割り当ては、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.
逆近隣探索のアイデアを議論するためのスティーブデアリング、トーマスNarten氏とエリックNordmarkとに感謝します。徹底的な見直しのためのトーマスNarten氏、およびエリックNordmarkとする、ともダン・ハリントン、ミラノMerhar、バーバラ・フォックス、マーティン・ミューラー、そしてピーター・タムに感謝します。
Also it should be acknowledged that parts of the text in this specification derived from the IPv6 Neighbor Discovery text [IPv6- ND].
また、それは認められるべきであるのIPv6近隣探索テキスト[IPv6- ND]に由来し、この仕様のテキストの一部。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998.
[IPv6の]デアリング、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.
、RFC 2461 [たIPv6-ND] Narten氏、T.、Nordmarkと、E.およびW.シンプソン "IPバージョン6（IPv6）のための近隣探索"、1998年12月。
[ICMPv6] Conta, A., and S. Deering "Internet Control Message Protocol for the Internet Protocol Version 6", RFC 2463, December 1998.
[ICMPv6の]コンタ、A.、およびS.デアリング "インターネットプロトコルバージョン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]コンタ、A.、Malis、A.とM.ミューラー、 "フレームリレーネットワークの上のIPv6パケットのトランスミッション"、RFC 2590、1997、1999年5月12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]アトキンソン、R.とS.ケント、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402, December 1998.
[IPSEC-AUTH]アトキンソン、R.とS.ケント、 "IP認証ヘッダー"、RFC 2402、1998年12月。
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[IPSEC-ESP]アトキンソン、R.とS.ケント、 "IPカプセル化セキュリティプロトコル（ESP）"、RFC 2406、1998年11月。
[ASSIGN] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, March 1994.
[ASSIGN]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年3月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, November 1998.
[ENCAPS]ブラウン、C.とA. Malis、 "フレームリレー上のマルチインターコネクト"、RFC 2427、1998年11月。
[INV-ARP] Bradley, T., Brown, C. and A. Malis "Inverse Address Resolution Protocol", RFC 2390, August 1998.
[INV-ARP]ブラッドリー、T.、ブラウン、C.と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.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484
アレックス・コンタTranSwitch社株式会社3エンタープライズ・ドライブシェルトン、CT 06484
Phone: +1-203-929-8810 EMail: aconta@txc.com
電話：+ 1-203-929-8810 Eメール：aconta@txc.com
Appendix A
付録A
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.
この付録では、前のセクションのより一般的なコンテンツの一部であるには余りにも特異的であったフレームリレーネットワーク上で逆近隣探索を使用しての詳細を説明します。
A.1 Introduction
A.1はじめに
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フレームリレーノードのワイドエリアネットワーク（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に関する情報が含まれていないDLCI = 30を経由してB（リモートノード）をノードAに仮想回線を識別するローカルリンク層アドレスの同等物として使用することができるローカル・ノード、仮想回路。図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.
また、リンク層レベルで送信されるメッセージと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の逆近隣探索（IND）プロトコル、フレームリレーノードが動的にリモートノードが仮想回線を識別するためのDLCIを発見することを可能にします。また、ノードは仮想回線のリモートエンドのノードのIPv6アドレスを学習することができます。
A.2. Inverse Neighbor Discovery Messages
A.2。逆近隣探索メッセージ
Frame Relay nodes generate Inverse Neighbor Discovery messages as follows:
次のようにフレームリレーノードが逆近隣探索メッセージを生成します。
A.2.1. Inverse Neighbor Discovery Solicitation Message
A.2.1。逆近隣探索要請メッセージ
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オールノードマルチキャスト[IPv6の]、[IPv6の-FR]、[ENCAPS]。しかしながら、リンク層レベルで、IND要請は、公知のリンク層アドレス（DLCI）によって識別されるターゲットノードに直接送信されます。
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].
送信者フレームリレーノードのターゲットリンク層アドレス、ターゲットリンク層アドレスフィールドには、ターゲットノードのリンクレイヤアドレスの同等として知られている値で満たされています。この値は、ターゲット・ノードへの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).
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).
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].
注：フレームリレーの場合、両方の上記アドレスが10（デフォルト）を有することができるQ.922フォーマット（DLCI）、であるか、または[IPv6の-FR] 23重大アドレッシングビット。オプション長（リンク層アドレス）は、8オクテット単位で表され、従って、DLCIはEAフィールドに基づいて、8バイトから抽出される第2の（ビット0）を有し、第三の、または記載オクテット（EA = 1）。 C / R、FECN、BECN、Q.922アドレスにおける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.2.2 Inverse Neighbor Discovery Advertisement Message
A.2.2逆近隣探索広告メッセージ
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）はIND広告とノードAによって送信されたIND要請に応答する場合、例えば、これらのフィールドは以下の値を有することになります。
At Node B (sender of the advertisement message):
ノードB（広告メッセージの送信者）で：
Source Link-Layer Address
DLCI=30 (was Target in Solicitation Message).
Target Link-Layer Address DLCI=62 (was Source in Solicitation Message).
= 62ターゲットリンク層アドレスDLCIは（要請メッセージに出所しました）。
At Node A (receiver of the advertisement message from B).
ノードAにおける（Bから広告メッセージの受信）。
Source Link-Layer Address
DLCI=30 (was Target in Solicitation Message).
Target Link-Layer Address DLCI=62 (was Source in Solicitation Message).
= 62ターゲットリンク層アドレスDLCIは（要請メッセージに出所しました）。
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.
ターゲットアドレス一覧この広告を促し逆近隣探索要請メッセージにターゲットリンク層アドレスによって識別されるインターフェイスの一の以上の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を含む上位層に伝播することができ、適切なリンク層シグナリングメッセージを受け取ります。
A.3. Inverse Neighbor Discovery Protocol
A.3。逆近隣探索プロトコル
This section of the appendix documents only the specific aspects of Inverse Neighbor Discovery with Frame Relay Networks.
フレームリレーネットワークと逆近隣探索の付録文書のこのセクションでは、唯一の特定の側面。
A.3.1 Sender Node Processing
A.3.1送信者ノード処理
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全ノードマルチキャストアドレスですが、メッセージがターゲットフレームリレーノードにのみ送信されます。ターゲットノードは、仮想回路で表すリンク上の既知のリモート・ノードです。
A.3.2 Receiver Node Processing
A.3.2レシーバノードの処理
A.3.2.1 Processing Inverse Neighbor Solicitation Messages
A.3.2.1処理逆近隣要請メッセージ
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を設定するために使用され得ます。
A.3.2.2 Processing Inverse Neighbor Advertisement Messages
A.3.2.2処理逆近隣広告メッセージ
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.
すなわち、ターゲットのIPアドレスとIND広告メッセージからソースリンク層アドレス - - IND広告の受信機のフレームリレーノードが送信元のIPv6アドレス/リンク層アドレスのマッピングを出してもよいの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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。