この文書はRFC3122の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
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.
このメモはノードに所定のリンクレイヤアドレスに対応しているＩＰｖ６ア
ドレスを決定して、広告することを許すＩＰｖ６近隣探索の拡張を記述しま
す。この拡張は逆近隣探索と呼ばれます。逆近隣探索（ＩＮＤ）は元々フレー
ムリレーネットワークのために開発されましたが、しかし類似の動作の他の
ネットワークに適用してもよいです。
Table of Contents
目次
1. Introduction
1. はじめに
2. Inverse Neighbor Discovery Messages
2. 逆近隣探索メッセージ
2.1 Inverse Neighbor Discovery Solicitation Message
2.1 逆近隣探索要請メッセージ
2.2 Inverse Neighbor Discovery Advertisement Message
2.2 逆近隣探索広告メッセージ
3. Inverse Neighbor Discovery Options Formats
3. 逆近隣探索選択オプションフォーマット
3.1 Source/Target Address List
3.1 ソース／目標アドレスリスト。
4. Inverse Neighbor Discovery Protocol
4. 逆近隣探索プロトコル
4.1 Sender Node Processing
4.1 送信者ノード処理
4.2 Receiver Node Processing
4.2 受信ノード処理
4.2.1 Processing Inverse Neighbor Solicitation Messages
4.2.1 逆近隣要請メッセージ処理
4.2.2 Processing Inverse Neighbor Advertisement Messages
4.2.2 逆近隣広告メッセージ処理
4.3 Message Validation
4.3 メッセージ検査
4.3.1 Validation of Inverse Neighbor Discovery Solicitations
4.3.1 逆近隣探索要請の検査
4.3.2 Validation of Inverse Neighbor Discovery Advertisements
4.3.2 逆近隣探索広告の検査
5. Security Considerations
5. セキュリティの考察
6. IANA Considerations
6. ＩＡＮＡの考慮
7. Acknowledgments
7. 謝辞
8. References
8. 参考文献
9. Authors' Addresses
9. 著者のアドレス
Appendix A
付録Ａ
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
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-IND]への拡張を定義します。拡
張はＩＰｖ６逆近隣探索（ＩＮＤ）と呼ばれます。ＩＰｖ６逆近隣探索（Ｉ
ＮＤ）は直接接続された遠隔ノードのリンクレイヤアドレスを知っているノー
ドにそのノードのＩＰｖ６アドレスを学習することを許します。ＩＮＤを使っ
ているノードが要求を送り、既知のリンクレイヤアドレスに対応する１つ以
上のＩＰｖ６アドレスの広告を受け取ります。
The Inverse Neighbor Discovery (IND) was originally developed for
Frame Relay networks, but may also apply to other networks with
similar behavior.
逆近隣探索（ＩＮＤ）は元々フレームリレーネットワークのために開発されま
したが、類似の動作の他のネットワークに適用してもよいです。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
in [KEYWORDS].
キーワードMUSTとMUST NOTとMAYとOPTIONALとREQUIREDとRECOMMENDEDとSHALL
とSHALL NOTとSHOULDとSHOULD NOTは[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]あるいはその置換え文書にＩＰｖ４の逆ARPのための定義と、ここ
で記述されたメカニズムの間に、多くの類似性との相違があります。
2. Inverse Neighbor Discovery Messages
2. 逆近隣探索メッセージ
The following messages are defined:
次のメッセージが定義されます：
2.1. Inverse Neighbor Discovery Solicitation Message
2.1. 逆近隣探索要請メッセージ
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-FR][ENCAPS]として送られます。しかし、リンクレイヤレベルで
は、ＩＮＤ要請が直接既知のリンクレイヤアドレスで識別された目標ノード
に送られます。
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.
宛先アドレス
ＩＰｖ６全ノードマルチキャストアドレス。このアドレスはリンク範囲の
フォーマットでFF02::1です。
Hop Limit 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.
認証ヘッダー
もしＩＰ認証ヘッダのセキュリティアソシエーションが送信者と宛先の
間に存在するなら、送信者はこのヘッダーを含むべきです(SHOULD)。
ICMP Fields:
ＩＣＭＰフィールド：
Type 141
タイプ 141
Code 0
コード 0
Checksum The ICMP checksum. See [ICMPv6].
チェックサム ＩＣＭＰチェックサム。[ICMPv6]参照。
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
予約 このフィールドは使われていません。これは送信者はゼ
ロに初期化し(MUST)、受信者は無視しなければなりませ
ん(MUST)。
Required options:
要求されるオプション
The sender node MUST send the following options in the Solicitation
message:
送信者ノードは次のオプションを要請メッセージで送らなくてはなりません
(MUST)：
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:
送信者ノードは要請メッセージに次のオプションを加えると決めるかもしれま
せん(MAY)：
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.
ソースアドレスリスト
ソースリンクレイヤアドレスによって識別されたインタフェースの１つ以
上のＩＰｖ６アドレスのリスト。このオプションは３章で定義されます。
MTU
The MTU configured for this link [IPv6-ND].
ＭＴＵ
このリンクに設定されたＭＴＵ[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.
このプロトコルの将来のバージョンが新しいオプションタイプを定義しても
よいです。受信者は認識できないオプションを静かに無視して、メッセージ
を処理し続けなくてはなりません(MUST)。
2.2 Inverse Neighbor Discovery Advertisement Message
2.2 逆近隣探索広告メッセージ
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:
ＩＰフィールド：
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
ホップ限界 ２５５
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.
認証ヘッダー
もしＩＰ認証ヘッダのセキュリティアソシエーションが送信者と宛先ア
ドレスの間に存在するなら、送信者はこのヘッダーを含むべきです
(SHOULD)。
ICMP Fields:
ＩＣＭＰフィールド：
Type 142
タイプ 142
Code 0
コード 0
Checksum The ICMP checksum. See [ICMPv6].
チェックサム ＩＣＭＰチェックサム。[ICMPv6]参照。
Reserved 32-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
予約 このフィールドは使われていません。これは送信者はゼ
ロに初期化し(MUST)、受信者は無視しなければなりませ
ん(MUST)。
Required options:
要求されるオプション
The sender node MUST send the following options in the Advertisement
message:
送信者ノードは次のオプションを広告メッセージで送らなくてはなりません
(MUST)：
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.
目標アドレスリスト。
この広告を呼び起こした逆近隣探索要請メッセージの目標リンクレイ
ヤアドレスで識別されたインタフェースの１つ以上のＩＰｖ６アドレ
スのリスト。このオプションは３章で定義されます。
Other valid options:
他の効力のあるオプション
The sender node MAY choose to add the following option in the
Advertisement message:
送信者ノードは広告メッセージに次のオプションを加えると決めるかもしれま
せん(MAY)：
MTU
The MTU configured for this link [IPv6-ND].
ＭＴＵ
このリンクに設定されたＭＴＵ[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.
このプロトコルの将来のバージョンが新しいオプションタイプを定義しても
よいです。受信者は認識できないオプションを静かに無視して、メッセージ
を処理し続けなくてはなりません(MUST)。
3. Inverse Neighbor Discovery Options Formats
3. 逆近隣探索選択オプションフォーマット
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]と逆近隣探索特有の
オプションを含みます：ソースアドレスリストと目標アドレスリスト
3.1 Source/Target Address List
3.1 ソース／目標アドレスリスト。
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]の４.６章参照）：
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
タイプ 9 ソースアドレスリスト
10 for Target Address List
10 目標アドレスリスト
Note: These Option Type values should be assigned from the IPv6
Neighbor Discovery family of values.
メモ：これらのオプションタイプ値はＩＰｖ６近隣探索ファミリーから
割り当てられるべきです。
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.
長さ （タイプと長さと予約フィールドを含む）８オクテット
単位のオプションの長さ。長さの最小値は、１つのＩＰ
ｖ６アドレスの場合で、３です。
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
予約 このフィールドは使われていません。これは送信者がゼ
ロに初期化しなくてはならなくて(MUST)、受信者に無視
されなくてはなりません(MUST)。
IPv6 Addresses One or more IPv6 addresses of the interface.
ＩＰｖ６アドレス １つ以上のインタフェースのＩＰｖ６アドレス。
Description:
記述：
The Source Address List contains a list of IPv6 addresses of the
interface identified by the Source Link-Layer Address.
ソースアドレスリストはソースリンクレイヤアドレスによって識別されたイ
ンタフェースのＩＰｖ６アドレスのリストを含んでいます。
The Target Address List contains a list of IPv6 addresses of the
interface identified by the Target Link-Layer Address.
目標アドレスリストは目標リンクレイヤアドレスによって識別されたインタ
フェースのＩＰｖ６アドレスのリストを含んでいます。
The number of addresses "n" in the list is calculated based on the
length of the option:
リスト内のアドレスの数「ｎ」はオプション長を基に計算します：
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.
ソースアドレスリストは１つのＩＮＤ要請メッセージに入らなければなりま
せん(MUST)。それ故にインタフェースのすべてのＩＰｖ６アドレスが１つの
メッセージに入らない場合に備えて、オプションは完全なリストを含んでい
ません。ＩＰｖ６アドレスの完全なリストは、ノードのＩＮＤ広告メッセー
ジに頼るべきです。
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.
目標アドレスリストは目標リンクレイヤアドレスによって識別されるインタ
フェースのアドレスの完全なリストであるべきです(SHOULD)。もしインタフェー
スのＩＰｖ６アドレスのリストが１つのＩＮＤ広告メッセージに入らなけれ
ば、最初のメッセージと同じフィールドを含むメッセージが続くべきです
(SHOULD)。2番目の目標アドレスリストオプションは目標リンクレイヤアドレ
スによって識別されたインタフェースの、最初のメッセージに入らなかった残
りのＩＰｖ６アドレスを含むべきです(SHOULD)。
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
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.
メモ２：実装が重複をＩＰｖ６アドレスリストで送ってはなりません
(MUST NOT)。
4. Inverse Neighbor Discovery Protocol
4. 逆近隣探索プロトコル
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.
ＩＮＤは本質的にＮＤ[IPv6-ND]と同じ操作します：目標ＩＰアドレスの要請
者はインタフェース上に要請メッセージを送ります、目標ノードが広告メッ
セージに求められた情報を含めて答えます。学ばれた情報は、インタフェー
スと結付いてるＩＰｖ６アドレス構造と同様に、近隣探索キャッシュ
[IPv6-ND]に記憶されるかもしれません(MAY)。
4.1 Sender Node Processing
4.1 送信者ノード処理
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.
要請ノードが、前章で定義されるようにＩＮＤ要請メッセージを組立て、特
定のリンクレイヤのパケットにカプセル化して、直接目標ノードに送ります。
宛先ＩＰアドレスが全ノードマルチキャストアドレスであるけれども、メッ
セージは目標ノードにだけ送られます。ＩＮＤプロトコルの重要なフィール
ドはソースＩＰアドレスとソースリンクレイヤアドレスと目標リンクレイヤ
アドレスとＭＴＵです。後者はリンクのＭＴＵの最適値を設定する際に使う
ことができます。
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.
回答を待ち受ける間、追加のトラフィックがない近隣に対しても、送り主は
再送タイマー[IPv6-ND]が切れる毎にＩＮＤ要請メッセージを再送すべきで
す(SHOULD)。再送はは近隣毎と再送タイマー毎に最大１にレート制限します
(MUST)。
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]回の要請の後に受け取ら
れないなら、逆アドレス解決は失敗です。もし要請の送信が上位レイヤにとっ
て必要なら、送信者モジュールは適切なメカニズムを通して上位レイヤにエ
ラーを知らせなくてはなりません（例えば、プロシージャコールの返り値）。
4.2 Receiver Node Processing
4.2 受信ノード処理
4.2.1 Processing Inverse Neighbor Solicitation Messages
4.2.1 逆近隣要請メッセージ処理
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.
すべてのＩＮＤ要請で、受信ノードは、リンクレイヤのソースと目標アド
レス対とＩＮＤ要請メッセージからのＩＰｖ６ソースアドレスを使って、
回答する適切なＩＮＤ広告を作るべきです(SHOULD)。
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.
もしノードがＩＮＤメッセージから学んだ情報で近隣探索キャッシュを更新
するなら、ＩＮＤ要請の受信ノードはＮＤ要請の場合同様に送信者のＩＰｖ
６アドレス／リンクレイヤアドレスのマッピング−すなわちソースＩＰアド
レスと要請メッセージのソースリンクレイヤアドレス−をＮＤキャッシュ
[IPv6-ND]に置くべきです(SHOULD)。
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.
ＩＰｖ６ノードがインタフェース毎に多数のＩＰｖ６アドレスを持つかもし
れないから、ＩＮＤ要請に返答するノードが目標アドレスリストオプション
で要請メッセージの目標リンクレイヤアドレスフィールドで識別されたイン
タフェースに対応している１つ以上のＩＰｖ６アドレスを含んでいるリスト
を返すべきです(SHOULD)。リストは重複を含んでいてはなりません(MUST)。
4.2.2 Processing Inverse Neighbor Advertisement Messages
4.2.2 逆近隣広告メッセージ処理
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.
もしノードがＩＮＤメッセージから学んだ情報で近隣探索キャッシュを更新
するなら、ＩＮＤ広告の受信ノードはＮＤ広告の場合同様に送信者のＩＰｖ
６アドレス／リンクレイヤアドレスのマッピング−すなわち目標アドレスの
ＩＰアドレスとＩＮＤ広告メッセージからのソースリンクレイヤアドレスア
ドレス−をＮＤキャッシュ[IPv6-ND]に置くべきです(SHOULD)。
4.3 Message Validation
4.3 メッセージ検査
Inverse Neighbor Discovery messages are validated as follows:
逆近隣探索メッセージが次のように検査されます：
4.3.1 Validation of Inverse Neighbor Discovery Solicitations
4.3.1 逆近隣探索要請の検査
A node MUST silently discard any received Inverse Neighbor
Solicitation messages that do not satisfy all of the following
validity checks:
ノードは以下の正常性検査のいずれかを満たさない逆近隣探索要請を静かに
捨てなくてはなりません(MUST)：
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- ＩＰホップ限界フィールドの値は２５５、すなわちパケットはルーター
によって転送さていないはずです。
- If the message includes an IP Authentication Header, the
message authenticates correctly.
- もしメッセージがＩＰ認証ヘッダを含むなら、メッセージを正確に検
査します。
- ICMP Checksum is valid.
- ＩＣＭＰチェックサムは合っています。
- ICMP Code is 0.
- ＩＣＭＰコードは０です。
- ICMP length (derived from the IP length) is 24 or more
octets.
- （ＩＰ長さから得られる）ＩＣＭＰ長さは２４オクテット以上です。
- The Target Link-Layer Address is a required option and MUST
be present.
- 目標リンク層アドレスは必要なオプションで、存在しているに違いあ
りません(MUST)。
- The Source Link-Layer Address is a required option and MUST
be present.
- ソースリンク層アドレスは必要なオプションで、存在しているに違い
ありません(MUST)。
- 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.
予約フィールドの内容と、認識できないオプションは無視しなければなりま
せん(MUST)。プロトコルに対する将来の後方互換性がある変更が予約のフィー
ルドの中身を指定するか、新しいオプションを加えるかもしれません；後方
互換性がない変更が異なったコード値を使うかもしれません。
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]オプショ
ンの中身が無視され(MUST)、パケットは正常に処理されます。必要なオプショ
ン以外であるかもしれない唯一の定義されたオプションはＭＴＵオプション
です。
An Inverse Neighbor Solicitation that passes the validity checks is
called a "valid solicitation".
正常性検査を通過した逆近隣要請が「有効な要請」と呼ばれます。
4.3.2 Validation of Inverse Neighbor Discovery Advertisements
4.3.2 逆近隣探索広告の検査
A node MUST silently discard any received Inverse Neighbor Discovery
Advertisement messages that do not satisfy all of the following
validity checks:
ノードは以下の正常性検査のいずれかを満たさない逆近隣探索要請を静かに
捨てなくてはなりません(MUST)：
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- ＩＰホップ限界フィールドの値は２５５、すなわちパケットはルーター
によって転送さていないはずです。
- If the message includes an IP Authentication Header, the
message authenticates correctly.
- もしメッセージがＩＰ認証ヘッダを含むなら、メッセージを正確に検
査します。
- ICMP Checksum is valid.
- ＩＣＭＰチェックサムは合っています。
- ICMP Code is 0.
- ＩＣＭＰコードは０です。
- ICMP length (derived from the IP length) is 48 or more
octets.
- （ＩＰ長さから得られる）ＩＣＭＰ長さは４８オクテット以上です。
- 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.
- 目標アドレスリストオプションの長さは３以上です。
- 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.
予約フィールドの内容と、認識できないオプションは無視しなければなりま
せん(MUST)。プロトコルに対する将来の後方互換性がある変更が予約のフィー
ルドの中身を指定するか、新しいオプションを加えるかもしれません；後方
互換性がない変更が異なったコード値を使うかもしれません。
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]の中身が無視され(MUST)、パケットは正常に処理されます。必要
なオプション以外であるかもしれない唯一の定義されたオプションはＭＴ
Ｕオプションです。
An Inverse Neighbor Advertisement that passes the validity checks is
called a "valid advertisement".
正常性検査を通過した逆近隣広告が「有効な広告」と呼ばれます。
5. Security Considerations
5. セキュリティの考察
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.
近隣探索のように、プロトコルはリンク外の送信者から来たＩＮＤパケット
を無視することによって認証がないことによる脅威の危険性を下げます。す
べての受信パケットのホップ限界フィールドは２５５で、可能な最大値を含
む事で検証されます。ルーターが転送するすべてのパケットのホップ限度を
減少させるから、２５５のホップ限界を含んでいる受信パケットが近隣から
来たに違いありません。
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.
逆近隣探索プロトコルパケット交換がＩＰ認証ヘッダ[IPSEC-Auth]を使って
認証できます。ノードが、、もしＩＰ認証ヘッダに使用するセキュリティア
ソシエーションが宛先アドレスに対して存在するなら、逆近隣探索パケット
を送る時、認証ヘッダを含めるべきです(SHOULD)。セキュリティアソシエー
ションは手動の設定を通してかある鍵管理プロトコルのオペレーションを通
して作られたかもしれません。
Received Authentication Headers in Inverse Neighbor Discovery packets
MUST be verified for correctness and packets with incorrect
authentication MUST be ignored.
受信した逆近隣探索パケットの認証ヘッダが正当性の確認をされなくてはな
らず(MUST)、正しくない認証を持つパケットが無視されなくてはなりません
(MUST)。
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.
フレームリレーで使用する場合、ＩＰセキュリティ認証の失敗を避けるため、
ＤＬＣＩフォーマットソースリンクレイヤアドレスオプションを含む近隣探
索要請メッセージのフレームリレー特有処理が、ＩＰセキュリティ処理を完
了した後に、受信ノードによって行われなければなりません(MUST)。
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.
システム管理者が、認証ヘッダか暗号化セキュリティペイロードを使って本
物と証明されたのではない逆近隣探索メッセージでも無視するように、ノー
ドを設定することが可能であるべきです(SHOULD)。このようなスイッチはデ
フォルトでは本物と証明されていないメッセージを許すべきです(SHOULD)。
Confidentiality issues are addressed by the IP Security Architecture
and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC-
ESP].
機密性問題がＩＰセキュリティアーキテクチャとＩＰ暗号化セキュリティペ
イロード文書[IPSEC], [IPSEC- ESP]によって扱われます。
6. IANA Considerations
6. ＩＡＮＡの考慮
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.
ＩＡＮＡは、２.１章と２.２章で記述されるように、２つの新しいＩＣＭＰ
ｖ６タイプ値の割り当てを求められました。彼らは、RFC2463の２.１章で定
義されるように、メッセージ情報的範囲から割り当てられました。（０以外
に）これらのタイプのために定義されたＩＣＭＰｖ６コード値がありません
でした；将来の割当てがRFC2434で定義されるように、標準行動下でされる
はずです。
IANA was also requested to assign two new ICMPv6 Neighbor Discovery
Option types as defined in Section 3.1. No outside reviewing was
necessary.
ＩＡＮＡは３.１章で、定義されるように、２つの新しいＩＣＭＰｖ６近隣
探索オプションタイプを割り当てることが同じく求められました。他のレ
ビューは必要ありません。
7. Acknowledgments
7. 謝辞
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- ND]
から生じたことは認められるべきです。
8. References
8. 参考文献
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[ICMPv6] Conta, A., and S. Deering "Internet Control Message
Protocol for the Internet Protocol Version 6", RFC
2463, December 1998.
[IPv6-FR] Conta, A., Malis, A. and M. Mueller, "Transmission of
IPv6 Packets over Frame Relay Networks", RFC 2590, May
1999. December 1997.
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header",
RFC 2402, December 1998.
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[ASSIGN] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, March 1994.
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect
over Frame Relay", RFC 2427, November 1998.
[INV-ARP] Bradley, T., Brown, C. and A. Malis "Inverse Address
Resolution Protocol", RFC 2390, August 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Authors' Addresses
9. 著者のアドレス
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
Phone: +1-203-929-8810
EMail: aconta@txc.com
Appendix 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.
逆近隣探索（ＩＮＤ）は特にフレームリレーノードに適用します。フレーム
リレーネットワークではデータリンク接続識別子（ＤＬＣＩ）によって、フ
レームリレー永住仮想回路（ＰＶＣ）と切替仮想回路（ＳＶＣ）が識別され
ます。フレームリレーノードの各ＤＬＣＩが広域ネットワーク（ＷＡＮ）を
通るひとつの仮想の接続を定義します。ＤＬＣＩが一般に局所的に意味を持
ちます。
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.
特定の信号メッセージによって、フレームリレーネットワークがノードにＤ
ＬＣＩに対応する新しい仮想回路を発表するかもしれません。ＤＬＣＩはノー
ドの仮想回路を識別し、ノードにリンクレイヤレベルで仮想の回路の他の終
端ノードを識別することを許し、遠いノードリンクレイヤアドレスの同等物
として用いることができます。例えば図１で、ノードＡ（ローカルノード）
がノードＢ（遠隔ノード）への仮想回路をＤＬＣＩ＝ ３０で識別します。
しかしながら、信号メッセージはローカルノードの仮想回路を識別するため
に遠隔ノードによって使われた、ローカルリンクレイヤアドレスの同等物と
して用いられる、ＤＬＣＩの情報を含みません。例えば図１で、ノードＢ
（遠隔ノード）がＤＬＣＩ＝６２によってノードＡへの仮想回路を識別しま
す。
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.
さらに、メッセージはリンクレイヤレベルで伝達され、完全にＩＰｖ６プロ
トコルから独立していて、ＩＰｖ６アドレス情報を含みません。逆近隣探索
はフレームリレーノードにローカルリンクレイヤアドレスの等価物、すなわ
ち遠隔ノードが自ノードを識別する識別子を発見し、そしてもっと重要なこ
とは、他の遠隔リンクレイヤアドレスによって識別された仮想回路の終端の
インタフェースのＩＰｖ６アドレスを発見することを許すプロトコルです。
~~~~~~~~~~~ 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.
ＩＰｖ６逆近隣探索（ＩＮＤ）プロトコルはフレームリレーノードが動的に
遠隔ノードが仮想回路を識別するＤＬＣＩを発見することを許します。これ
は同じくノードに仮想回路の遠隔終端ノードのＩＰｖ６アドレスを学習する
ことを許します。
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],
[IPv6-FR], [ENCAPS]。しかしながら、リンクレイヤレベルにおいて、ＩＮ
Ｄ要請が直接既知のリンクレイヤアドレス（ＤＬＣＩ）によって識別された
目標ノードに送られます。
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].
ソースリンク層アドレス
送信者フレームリレーノードのソースリンクレイヤアドレスは、遠隔のノー
ドがこのメッセージのソースを識別できるリンクレイヤアドレスの同等物
です。送信者はこの情報の知識を持っていないかもしれません。もし送信
者が情報を知っているなら、フィールドに含めるべきで(SHOULD)、さもな
ければゼロ（空）にするべきです(SHOULD)。この情報は、もしあるなら、
ネットワークをデバッグする目的で使うことができます。送信者のフィー
ルド上の行動にかかわらず、逆近隣探索処理の前に、このメッセージの受
信者は、送信者が設定したかに関わらず、このフィールドをフレームリレー
ヘッダーのＤＬＣＩフィールドに記入された値に置き換えます。フィール
ドは、[IPv6-FR]で定義されるように、ＤＬＣＩフォーマットでコード化
されます。
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].
目標リンク層アドレス
送信者フレームリレーノードは、目標リンクレイヤアドレスフィールドは
目標ノードリンクレイヤアドレスの同等物として知られている値で満たさ
れます。この値は目標ノードのＶＣのＤＬＣＩです。これはＤＬＣＩ
フォーマット[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:
フレームリレーノードによるＩＮＤ要請メッセージを生成することを例と
して、ノードＡ（図１）がＩＮＤ要請をノードＢに送ると考えます。要請
メッセージフィールドは次の値を持つでしょう：
At Node A (sender of the IND solicitation message).
ノードＡ（ＩＮＤ要請メッセージの送信者）において
Source Link-Layer Address
ソースリンク層アドレス
DLCI=unknown (overwritten by the receiver).
ＤＬＣＩ＝未知（受信者によって上書きされる）
Target Link-Layer Address
目標リンク層アドレス
DLCI=30.
ＤＬＣＩ＝３０
At Node B (receiver of the IND solicitation message).
ノードＢ（ＩＮＤ要請メッセージの受信者）において
Source Link-Layer Address
ソースリンク層アドレス
DLCI=62 (filled in by the receiver).
ＤＬＣＩ＝６２（受信者によって埋められる）
Target Link-Layer Address
目標リンク層アドレス
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.９２２フォーマット
（ＤＬＣＩ）で、これは１０（デフォルト）か２３の有効アドレスビット
[IPv6-FR]です。オプション長さ（リンクレイヤアドレス）は、８オクテット
単位で表現されため、第２と第３と第４オクテットのＥＡフィールド（ビッ
ト０）に基づいてＤＬＣＩは８バイトに拡張されます。Q.９２２アドレスの
C/RとFECNとBECNとDEフィールドがＩＮＤで重要な意味がなく、０を設定し
ます[IPv6-FR]。
MTU
The value filled in the MTU option is the MTU for the virtual
circuit identified by the known DLCI [IPv6-FR].
ＭＴＵ
ＭＴＵオプションの値は既知のＤＬＣＩで識別される仮想回路のＭＴＵ
です[IPv6-FR]。
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].
ソースリンク層アドレス
フレームリレーで、このフィールドは逆近隣探索要請の目標リンクレイヤ
アドレスフィールドからコピーされます。これはＤＬＣＩフォーマット
[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].
目標リンク層アドレス
フレームリレーで、このフィールドは逆近隣探索要請のソースリンクレイ
ヤアドレスフィールドからコピーされます。これはＤＬＣＩフォーマット
[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:
例えばもしノードＢ（図１）がノードＡから送られたＩＮＤ要請に返答すると
します。ＩＮＤ広告で、これらのフィールドは次の値を持つでしょう：
At Node B (sender of the advertisement message):
ノードＢ（広告メッセージの送信者）において
Source Link-Layer Address
ソースリンク層アドレス
DLCI=30 (was Target in Solicitation Message).
ＤＬＣＩ＝３０（は要請メッセージの目標です）
Target Link-Layer Address
目標リンク層アドレス
DLCI=62 (was Source in Solicitation Message).
ＤＬＣＩ＝６２（は要請メッセージのソースです）
At Node A (receiver of the advertisement message from B).
ノードＡ（Ｂからの広告メッセージの受信者）において
Source Link-Layer Address
ソースリンク層アドレス
DLCI=30 (was Target in Solicitation Message).
ＤＬＣＩ＝３０（は要請メッセージの目標です）
Target Link-Layer Address
目標リンク層アドレス
DLCI=62 (was Source in Solicitation Message).
ＤＬＣＩ＝６２（は要請メッセージのソースです）
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.
目標アドレスリスト
この広告を呼び起こした逆近隣探索懇願メッセージの目標リンクレイヤア
ドレスによって識別されたインタフェースの１つ以上のＩＰｖ６アドレス
のリスト。
MTU The MTU configured for this link (virtual circuit) [IPv6-ND].
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.
ノード：フレームリレーネットワークの場合に、ＩＮＤメッセージは仮想
回路上に送られ、これは仮想のリンクのように動作します。もし仮想回路
が壊れるなら、すべての回路の関係者は適切なリンクレイヤ信号メッセー
ジを受け取り、これはＩＰｖ６を含む上位レイヤに伝えられることができ
ます。
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.
要請しているフレームリレーノードが、前章で定義されるように、ＩＮＤ要
請メッセージを生成し、フレームリレーリンクレイヤ[IPv6-FR]のパケット
内にカプセル化し、目標フレームリレーノードに送ります。宛先ＩＰアドレ
スがＩＰｖ６全ノードマルチキャストアドレスであるが、メッセージは目標
フレームリレーノードにだけ送られます。目標ノードは仮想回路によって表
されるリンク上の既知の遠隔のノードです。
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.
フレームリレーノードが、他の処理の前に、ソースリンクレイヤアドレスの
現存のＤＬＣＩ値を、メッセージを含んでいるフレームのフレームリレーヘッ
ダーのＤＬＣＩ値に、置き換えます。ＤＬＣＩ値は適切なフォーマットでソー
スリンクレイヤアドレスフィールドに設定しなければなりません[IPv6-FR]。
このオペレーションはＩＮＤ要請メッセージの以降の処理でフィールドの
正しい解釈を許すために必要です。
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.
フレームリレーノードは、要請メッセージからのＭＴＵ値が、インタフェー
ス設定時にされていなかった場合に備えて値をより適切にするため、受信者
のＭＴＵに使われるかもしれません(MAY)。
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.
ＩＮＤ広告の受信フレームリレーノードは送信者のＩＰｖ６アドレス／リン
クレイヤアドレスのマッピング−すなわち目標ＩＰアドレスとＩＮＤ広告メッ
セージのソースリンクレイヤアドレス−を、ＮＤ広告同様に、ＮＤキャッシュ
に置くかもしれません(MAY)[IPv6-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.
さらに、ＩＮＤ広告の受信フレームリレーノードはＶＣの遠隔終端のＤＬＣ
Ｉ値としてメッセージからの目標リンクレイヤアドレスを記憶するかもしれ
ません(MAY)。このＤＬＣＩ値は遠隔のノードが受信者を識別するリンクレ
イヤアドレスの同等物です。
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.
もしＩＮＤ広告の受信ノードがＩＰｖ６アドレスのプールを持っていて、そ
してもし実装が許すなら、特定のローカルＩＰｖ６アドレスと、ＶＣ上の将
来の通信の目標リストの特定のＩＰｖ６アドレスを対にする決定をするかも
しれません。特に、このような組合せは同じサブネット上にあるＩＰｖ６ア
ドレスに基づいているかもしれません、それは同じプレフィックスを持って
います。
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００１）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。