この文書は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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So