この文書はRFC3122の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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. 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 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. IANAの考慮 7. Acknowledgments 7. 謝辞 8. References 8. 参考文献 9. Authors' Addresses 9. 著者のアドレス Appendix A 付録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近隣探索(ND)[IPv6-IND]への拡張を定義します。拡 張はIPv6逆近隣探索(IND)と呼ばれます。IPv6逆近隣探索(I ND)は直接接続された遠隔ノードのリンクレイヤアドレスを知っているノー ドにそのノードの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]. キーワード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]あるいはその置換え文書にIPv4の逆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アドレスがわか らないので、逆近隣探索(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認証ヘッダのセキュリティアソシエーションが送信者と宛先の 間に存在するなら、送信者はこのヘッダーを含むべきです(SHOULD)。 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. 予約 このフィールドは使われていません。これは送信者はゼ ロに初期化し(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. ソースアドレスリスト ソースリンクレイヤアドレスによって識別されたインタフェースの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. このプロトコルの将来のバージョンが新しいオプションタイプを定義しても よいです。受信者は認識できないオプションを静かに無視して、メッセージ を処理し続けなくてはなりません(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: 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認証ヘッダのセキュリティアソシエーションが送信者と宛先ア ドレスの間に存在するなら、送信者はこのヘッダーを含むべきです (SHOULD)。 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. 予約 このフィールドは使われていません。これは送信者はゼ ロに初期化し(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. 目標アドレスリスト。 この広告を呼び起こした逆近隣探索要請メッセージの目標リンクレイ ヤアドレスで識別されたインタフェースの1つ以上のIPv6アドレ スのリスト。このオプションは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]. 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. このプロトコルの将来のバージョンが新しいオプションタイプを定義しても よいです。受信者は認識できないオプションを静かに無視して、メッセージ を処理し続けなくてはなりません(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: ソースアドレスリストと目標アドレスリストオプションはTVLオプショ ン(タイプ、長さ、可変長フィールド)で、次のフィールドを持ちます ([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 タイプ 9 ソースアドレスリスト 10 for Target Address List 10 目標アドレスリスト 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つのIP v6アドレスの場合で、3です。 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. 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) (長さは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要請メッセージに入らなければなりま せん(MUST)。それ故にインタフェースのすべての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. 目標アドレスリストは目標リンクレイヤアドレスによって識別されるインタ フェースのアドレスの完全なリストであるべきです(SHOULD)。もしインタフェー スのIPv6アドレスのリストが1つのIND広告メッセージに入らなけれ ば、最初のメッセージと同じフィールドを含むメッセージが続くべきです (SHOULD)。2番目の目標アドレスリストオプションは目標リンクレイヤアドレ スによって識別されたインタフェースの、最初のメッセージに入らなかった残 りのIPv6アドレスを含むべきです(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. メモ1: 逆近隣探索メカニズムの範囲はアドレスマップ作成情報の供給、 すなわち、IPv6アドレス探索に限定されています。そのために、どのよ うにノードが逆ディスカバリーメッセージで返されたアドレスを使うかに関 して、条項あるいは規則を作りません。さらに、ソースあるいは目標アドレ スリストはどんなタイプのIPv6アドレスでも除外しません。例えば、も しインタフェースが手設定アドレスと自動設定アドレスを持ち、一時的なも の、ユニキャスト、マルチキャストなどを含むなら、リストはどれも除去す るべきではありません。 Note 2: An implementation MUST NOT send duplicates in the IPv6 address list. メモ2:実装が重複をIPv6アドレスリストで送ってはなりません (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. INDは本質的にND[IPv6-ND]と同じ操作します:目標IPアドレスの要請 者はインタフェース上に要請メッセージを送ります、目標ノードが広告メッ セージに求められた情報を含めて答えます。学ばれた情報は、インタフェー スと結付いてるIPv6アドレス構造と同様に、近隣探索キャッシュ [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. 要請ノードが、前章で定義されるように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. 回答を待ち受ける間、追加のトラフィックがない近隣に対しても、送り主は 再送タイマー[IPv6-ND]が切れる毎にIND要請メッセージを再送すべきで す(SHOULD)。再送はは近隣毎と再送タイマー毎に最大1にレート制限します (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). もしIND広告が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. すべてのIND要請で、受信ノードは、リンクレイヤのソースと目標アド レス対とIND要請メッセージからのIPv6ソースアドレスを使って、 回答する適切なIND広告を作るべきです(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. もしノードがINDメッセージから学んだ情報で近隣探索キャッシュを更新 するなら、IND要請の受信ノードはND要請の場合同様に送信者のIPv 6アドレス/リンクレイヤアドレスのマッピング−すなわちソースIPアド レスと要請メッセージのソースリンクレイヤアドレス−をNDキャッシュ [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. IPv6ノードがインタフェース毎に多数のIPv6アドレスを持つかもし れないから、IND要請に返答するノードが目標アドレスリストオプション で要請メッセージの目標リンクレイヤアドレスフィールドで識別されたイン タフェースに対応している1つ以上のIPv6アドレスを含んでいるリスト を返すべきです(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. もしノードがINDメッセージから学んだ情報で近隣探索キャッシュを更新 するなら、IND広告の受信ノードはND広告の場合同様に送信者のIPv 6アドレス/リンクレイヤアドレスのマッピング−すなわち目標アドレスの IPアドレスとIND広告メッセージからのソースリンクレイヤアドレスア ドレス−をNDキャッシュ[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. - 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. - 目標リンク層アドレスは必要なオプションで、存在しているに違いあ りません(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)、パケットは正常に処理されます。必要なオプショ ン以外であるかもしれない唯一の定義されたオプションはMTUオプション です。 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. - 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. 予約フィールドの内容と、認識できないオプションは無視しなければなりま せん(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)、パケットは正常に処理されます。必要 なオプション以外であるかもしれない唯一の定義されたオプションはMT Uオプションです。 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. 近隣探索のように、プロトコルはリンク外の送信者から来た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認証ヘッダに使用するセキュリティア ソシエーションが宛先アドレスに対して存在するなら、逆近隣探索パケット を送る時、認証ヘッダを含めるべきです(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. フレームリレーで使用する場合、IPセキュリティ認証の失敗を避けるため、 DLCIフォーマットソースリンクレイヤアドレスオプションを含む近隣探 索要請メッセージのフレームリレー特有処理が、IPセキュリティ処理を完 了した後に、受信ノードによって行われなければなりません(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]. 機密性問題がIPセキュリティアーキテクチャとIP暗号化セキュリティペ イロード文書[IPSEC], [IPSEC- ESP]によって扱われます。 6. IANA Considerations 6. IANAの考慮 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つの新しいICMP v6タイプ値の割り当てを求められました。彼らは、RFC2463の2.1章で定 義されるように、メッセージ情報的範囲から割り当てられました。(0以外 に)これらのタイプのために定義されたICMPv6コード値がありません でした;将来の割当てが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. IANAは3.1章で、定義されるように、2つの新しいICMPv6近隣 探索オプションタイプを割り当てることが同じく求められました。他のレ ビューは必要ありません。 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近隣探索テキスト[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 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)は特にフレームリレーノードに適用します。フレーム リレーネットワークではデータリンク接続識別子(DLCI)によって、フ レームリレー永住仮想回路(PVC)と切替仮想回路(SVC)が識別され ます。フレームリレーノードの各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. 特定の信号メッセージによって、フレームリレーネットワークがノードにD LCIに対応する新しい仮想回路を発表するかもしれません。DLCIはノー ドの仮想回路を識別し、ノードにリンクレイヤレベルで仮想の回路の他の終 端ノードを識別することを許し、遠いノードリンクレイヤアドレスの同等物 として用いることができます。例えば図1で、ノードA(ローカルノード) がノードB(遠隔ノード)への仮想回路をDLCI= 30で識別します。 しかしながら、信号メッセージはローカルノードの仮想回路を識別するため に遠隔ノードによって使われた、ローカルリンクレイヤアドレスの同等物と して用いられる、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. さらに、メッセージはリンクレイヤレベルで伝達され、完全に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アドレスを知りませんが、 遠隔ノードリンクレイヤアドレスの同等物を知っています。逆近隣探索(I ND)要請がIPv6全ノードマルチキャストとして送られます[IPv6], [IPv6-FR], [ENCAPS]。しかしながら、リンクレイヤレベルにおいて、IN D要請が直接既知のリンクレイヤアドレス(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]. ソースリンク層アドレス 送信者フレームリレーノードのソースリンクレイヤアドレスは、遠隔のノー ドがこのメッセージのソースを識別できるリンクレイヤアドレスの同等物 です。送信者はこの情報の知識を持っていないかもしれません。もし送信 者が情報を知っているなら、フィールドに含めるべきで(SHOULD)、さもな ければゼロ(空)にするべきです(SHOULD)。この情報は、もしあるなら、 ネットワークをデバッグする目的で使うことができます。送信者のフィー ルド上の行動にかかわらず、逆近隣探索処理の前に、このメッセージの受 信者は、送信者が設定したかに関わらず、このフィールドをフレームリレー ヘッダーの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要請メッセージを生成することを例と して、ノードA(図1)がIND要請をノードBに送ると考えます。要請 メッセージフィールドは次の値を持つでしょう: 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オクテット 単位で表現されため、第2と第3と第4オクテットのEAフィールド(ビッ ト0)に基づいてDLCIは8バイトに拡張されます。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で識別される仮想回路のMTU です[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]. ソースリンク層アドレス フレームリレーで、このフィールドは逆近隣探索要請の目標リンクレイヤ アドレスフィールドからコピーされます。これは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を含む上位レイヤに伝えられることができ ます。 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に使われるかもしれません(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. IND広告の受信フレームリレーノードは送信者のIPv6アドレス/リン クレイヤアドレスのマッピング−すなわち目標IPアドレスとIND広告メッ セージのソースリンクレイヤアドレス−を、ND広告同様に、NDキャッシュ に置くかもしれません(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. さらに、IND広告の受信フレームリレーノードはVCの遠隔終端のDLC I値としてメッセージからの目標リンクレイヤアドレスを記憶するかもしれ ません(MAY)。この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アドレスのプールを持っていて、そ してもし実装が許すなら、特定のローカルIPv6アドレスと、VC上の将 来の通信の目標リストの特定の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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。