[要約] RFC 2491は、IPv6を非ブロードキャストの複数アクセス（NBMA）ネットワーク上で使用するためのガイドラインです。このRFCの目的は、NBMAネットワーク上でのIPv6の効果的な展開と運用を支援することです。
Network Working Group G. Armitage
Request for Comments: 2491 Lucent Technologies
Category: Standards Track P. Schulter
Bright Tiger Technologies
M. Jork
Digital Equipment GmbH
G. Harter
Compaq
January 1999
IPv6 over Non-Broadcast Multiple Access (NBMA) networks
Non-Broadcast Multiple Access（NBMA）ネットワーク上の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 (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described.
このドキュメントでは、NBMAネットワーク上のIPv6の一般的なアーキテクチャについて説明します。これは、さまざまな特定のNBMAテクノロジ（ATMやフレームリレーなど）の詳細を説明する付属の付属文書の基礎を形成します。 IPv6 over NBMAアーキテクチャは、IPv6近隣探索プロトコルの従来のホスト側の操作を可能にすると同時に、動的にシグナリングされるNBMAリンクが利用可能な場合に「ショートカット」NBMA転送パスの確立をサポートします。管理上構成されたポイントツーポイントNBMAリンクを介した操作についても説明します。
Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor Discovery protocol operation within Logical Links, and inter-router NHRP for the discovery of off-Link NBMA destinations. Both flow-triggered and explicitly source-triggered shortcuts are supported.
ダイナミックNBMAショートカットは、論理リンク内のIPv6近隣探索プロトコル操作と、オフリンクNBMA宛先の発見のためのルーター間NHRPを使用して実現されます。フローによってトリガーされるショートカットと明示的にソースによってトリガーされるショートカットの両方がサポートされています。
1. Introduction.
1. 前書き。
Non Broadcast Multiple Access (NBMA) networks may be utilized in a variety of ways. At one extreme, they can be used to simply provide administratively configurable point to point service, sufficient to interconnect IPv6 routers (and even IPv6 hosts, in certain situations). At the other extreme, NBMA networks that support dynamic establishment and teardown of Virtual Circuits (or functional equivalents) may be used to emulate the service provided to the IPv6 layer by conventional broadcast media such as Ethernet. Typically this emulation requires complex convergence protocols, particularly to support IPv6 multicast.
Non Broadcast Multiple Access（NBMA）ネットワークは、さまざまな方法で利用できます。極端な例として、IPv6ルーター（および特定の状況ではIPv6ホスト）を相互接続するのに十分な管理上構成可能なポイントツーポイントサービスを提供するために使用できます。反対に、仮想回線（または同等の機能）の動的な確立と破棄をサポートするNBMAネットワークは、イーサネットなどの従来のブロードキャストメディアによってIPv6レイヤーに提供されるサービスをエミュレートするために使用できます。通常、このエミュレーションには、特にIPv6マルチキャストをサポートするために、複雑な収束プロトコルが必要です。
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for companion documents that provide details specific to various NBMA technologies (for example, ATM [17] or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths (when dynamically signaled NBMA links are available).
このドキュメントでは、NBMAネットワーク上のIPv6の一般的なアーキテクチャについて説明します。これは、さまざまなNBMAテクノロジ（ATM [17]やフレームリレーなど）に固有の詳細を提供する関連ドキュメントの基礎を形成します。 IPv6 over NBMAアーキテクチャーは、IPv6近隣探索プロトコルの従来のホスト側の操作を可能にすると同時に、「ショートカット」NBMA転送パスの確立をサポートします（動的にシグナリングされるNBMAリンクが利用可能な場合）。
The majority of this document focuses on the use of dynamically managed point to point and point to multipoint calls between interfaces on an NBMA network. These will be generically referred to as "SVCs" in the rest of the document. The use of administratively configured point to point calls will also be discussed. Such calls will be generically referred to as "PVCs". Depending on context, either may be shortened to "VC".
このドキュメントの大部分は、NBMAネットワーク上のインターフェイス間で動的に管理されるポイントツーポイントおよびポイントツーマルチポイントコールの使用に焦点を当てています。本書では、これらを総称して「SVC」と呼びます。管理上構成されたポイントツーポイントコールの使用についても説明します。このような呼び出しは、一般的に「PVC」と呼ばれます。コンテキストによっては、どちらも「VC」に短縮される場合があります。
Certain NBMA networks may provide a form of connectionless service (e.g. SMDS). In these cases, a "call" or "VC" shall be considered to implicitly exist if the sender has an NBMA destination address to which it can transmit packets whenever it desires.
特定のNBMAネットワークは、ある種のコネクションレスサービス（SMDSなど）を提供する場合があります。これらの場合、送信者が希望するときにいつでもパケットを送信できるNBMA宛先アドレスを持っている場合、「呼び出し」または「VC」は暗黙的に存在すると見なされます。
1.1 Neighbor Discovery.
1.1 近隣探索。
A key difference between this architecture and previous IP over NBMA protocols is its mechanism for supporting IPv6 Neighbor Discovery.
このアーキテクチャと以前のIP over NBMAプロトコルの主な違いは、IPv6近隣探索をサポートするメカニズムです。
The IPv4 world evolved an approach to address resolution that depended on the operation of an auxiliary protocol operating at the 'link layer' - starting with Ethernet ARP (RFC 826 [14]). In the world of NBMA (Non Broadcast, Multiple Access) networks ARP has been applied to IPv4 over SMDS (RFC 1209 [13]) and IPv4 over ATM (RFC 1577 [3]). More recently the ION working group has developed NHRP (Next Hop Resolution Protocol [8]), a general protocol for performing intra-subnet and inter-subnet address resolution applicable to a range of NBMA network technologies.
IPv4の世界は、イーサネットARP（RFC 826 [14]）から始まる「リンク層」で動作する補助プロトコルの動作に依存するアドレス解決へのアプローチを進化させました。 NBMA（Non Broadcast、Multiple Access）ネットワークの世界では、ARPはIPv4 over SMDS（RFC 1209 [13]）およびIPv4 over ATM（RFC 1577 [3]）に適用されています。最近では、IONワーキンググループがNHRP（Next Hop Resolution Protocol [8]）を開発しました。これは、一連のNBMAネットワークテクノロジーに適用可能なサブネット内およびサブネット間アドレス解決を実行するための一般的なプロトコルです。
IPv6 developers opted to migrate away from a link layer specific approach, chosing to combine a number of tasks into a protocol known as Neighbor Discovery [7], intended to be non-specific across a number of link layer technologies. A key assumption made by Neighbor Discovery's actual protocol is that the link technology underlying a given IP interface is capable of native multicasting. This is not particularly true of most NBMA network services, and usually requires convergence protocols to emulate the desired service. (The MARS protocol, RFC 2022 [5], is an example of such a convergence protocol.) This document augments and optimizes the MARS protocol for use in support of IPv6 Neighbor Discovery, generalizing the applicability of RFC 2022 beyond ATM networks.
IPv6開発者は、リンクレイヤー固有のアプローチから移行することを選択し、多数のタスクを複数のリンクレイヤーテクノロジー全体で非固有であることが意図されたNeighbor Discovery [7]と呼ばれるプロトコルに結合することを選択しました。 Neighbor Discoveryの実際のプロトコルによって行われた主要な前提は、特定のIPインターフェースの基礎となるリンクテクノロジーがネイティブマルチキャストに対応していることです。これは、ほとんどのNBMAネットワークサービスには特に当てはまりません。通常、目的のサービスをエミュレートするには、コンバージェンスプロトコルが必要です。 （MARSプロトコル、RFC 2022 [5]は、そのような収束プロトコルの例です。）このドキュメントは、IPv6近隣探索のサポートで使用するためにMARSプロトコルを拡張および最適化し、ATMネットワークを超えたRFC 2022の適用性を一般化します。
1.2 NBMA Shortcuts.
1.2 NBMAショートカット。
A shortcut is an NBMA level call (VC) directly connecting two IP endpoints that are logically separated by one or more routers at the IP level. IPv6 packets traversing this VC are said to 'shortcut' the routers that are in the logical IPv6 path between the VC's endpoints.
ショートカットとは、IPレベルで1つ以上のルーターによって論理的に分離された2つのIPエンドポイントを直接接続するNBMAレベルの呼び出し（VC）です。このVCを通過するIPv6パケットは、VCのエンドポイント間の論理IPv6パスにあるルーターを「ショートカット」すると言われています。
NBMA shortcuts are a mechanism for minimizing the consumption of resources within an IP over NBMA cloud (e.g. router hops and NBMA VCs).
NBMAのショートカットは、IP over NBMAクラウド内のリソース（ルーターホップやNBMA VCなど）の消費を最小限に抑えるためのメカニズムです。
It is important that NBMA shortcuts are supported whenever IP is deployed across NBMA networks capable of supporting dynamic establishment of calls (SVCs or functional equivalent). For IPv6 over NBMA, shortcut discovery and management is achieved through a mixture of Neighbor Discovery and NHRP.
コールの動的確立をサポートできるNBMAネットワーク（SVCまたは同等の機能）全体にIPが配備されている場合は常に、NBMAショートカットがサポートされていることが重要です。 NBMA上のIPv6の場合、ショートカットの発見と管理は、近隣探索とNHRPの混合によって実現されます。
1.3 Key components of the IPv6 over NBMA architecture.
1.3 IPv6 over NBMAアーキテクチャの主要コンポーネント。
1.3.1 NBMA networks providing PVC support.
1.3.1 PVCサポートを提供するNBMAネットワーク。
When the NBMA network is used in PVC mode, each PVC will connect exactly two nodes and the use of Neighbor Discovery and other IPv6 features is limited. IPv6/NBMA interfaces have only one neighbor on each Link. The MARS and NHRP protocols are NOT necessary, since multicast and broadcast operations collapse down to an NBMA level unicast operation. Dynamically discovered shortcuts are not supported.
NBMAネットワークがPVCモードで使用される場合、各PVCは2つのノードを正確に接続し、近隣探索およびその他のIPv6機能の使用が制限されます。 IPv6 / NBMAインターフェイスは、各リンクに1つだけのネイバーを持っています。マルチキャストおよびブロードキャスト操作はNBMAレベルのユニキャスト操作に集約されるため、MARSおよびNHRPプロトコルは必要ありません。動的に検出されたショートカットはサポートされていません。
The actual details of encapsulations and link token generation SHALL be covered by companion documents covering specific NBMA technology. They SHALL conform to the following guidelines:
カプセル化とリンクトークン生成の実際の詳細は、特定のNBMAテクノロジーをカバーする関連ドキュメントでカバーする必要があります。それらは以下のガイドラインに準拠する必要があります。
Both unicast and multicast IPv6 packets SHALL be transmitted over PVC links using the encapsulation described in section 4.4.1.
ユニキャストとマルチキャストの両方のIPv6パケットは、セクション4.4.1で説明されているカプセル化を使用して、PVCリンク上で送信されるものとします（SHALL）。
Interface tokens for PVC links SHALL be constructed as described in section 5. Interface tokens need only be unique between the two nodes on the PVC link.
PVCリンクのインターフェイストークンは、セクション5の説明に従って構築する必要があります。インターフェイストークンは、PVCリンク上の2つのノード間でのみ一意である必要があります。
This use of PVC links does not mandate, nor does it prohibit the use of extensions to the Neighbor Discovery protocol which may be developed for either general use of for use in PVC connections (for example, Inverse Neighbor Discovery).
このPVCリンクの使用は必須ではありません。また、PVC接続で使用するために一般的に使用するために開発されたネイバーディスカバリプロトコルの拡張機能の使用を禁止するものでもありません（たとえば、逆ネイバーディスカバリー）。
NBMA-specific companion documents MAY additionally specify the concatenation of IPv6 over PPP and PPP over NBMA mechanisms as an OPTIONAL approach to point to point IPv6.
NBMA固有の関連ドキュメントは、IPv6 over PPPおよびPPP over NBMAメカニズムの連結を、ポイントツーポイントIPv6へのオプションのアプローチとしてさらに指定する場合があります。
Except where noted above, the remainder of this document focuses on the SVC case.
上記を除いて、このドキュメントの残りの部分ではSVCのケースに焦点を当てています。
1.3.2 NBMA networks providing SVC support.
1.3.2 SVCサポートを提供するNBMAネットワーク。
When the NBMA network is used in SVC mode, the key components are:
NBMAネットワークがSVCモードで使用される場合、主要なコンポーネントは次のとおりです。
- The IPv6 Neighbor model, where neighbors are discovered through the use of messages multicast to members of an IPv6 interface's local IPv6 Link. - The MARS model, allowing emulation of general multicast using multipoint calls provided by the underlying NBMA network. - The NHRP service for seeking out the NBMA identities of IP interfaces who are logically distant in an IP topological sense. - The modeling of IP traffic as 'flows', and optionally using the existence of a flow as the basis for attempting to set up a shortcut link level connection.
- IPv6ネイバーモデル。ネイバーは、IPv6インターフェイスのローカルIPv6リンクのメンバーにマルチキャストされるメッセージを使用して検出されます。 -MARSモデル。基礎となるNBMAネットワークによって提供されるマルチポイントコールを使用して、一般的なマルチキャストのエミュレーションを可能にします。 -IPトポロジー的に論理的に離れているIPインターフェースのNBMA IDを探すためのNHRPサービス。 -「フロー」としてのIPトラフィックのモデリング。オプションで、ショートカットリンクレベル接続のセットアップを試行するための基礎としてフローの存在を使用します。
In summary:
要約すれば：
The IPv6 "Link" is generalized to "Logical Link" (LL) in NBMA environments (analogous to the generalization of IPv4 IP Subnet to Logical IP Subnet in RFC 1209 and subsequently RFC 1577).
IPv6の「リンク」は、NBMA環境では「論理リンク」（LL）に一般化されています（IPv4 IPサブネットからRFC 1209およびその後のRFC 1577の論理IPサブネットへの一般化に類似）。
IPv6/NBMA interfaces utilize RFC 2022 (MARS) for general intra-Logical Link multicasting. The MARS itself is used to optimally distribute discovery messages within the Logical Link.
IPv6 / NBMAインターフェイスは、一般的な論理リンク内マルチキャストにRFC 2022（MARS）を利用します。 MARS自体は、論理リンク内でディスカバリメッセージを最適に分散するために使用されます。
For destinations not currently considered to be Neighbors, a host sends the packets to one of its default routers.
現在ネイバーと見なされていない宛先の場合、ホストはデフォルトルーターの1つにパケットを送信します。
When appropriately configured, the egress router from a Logical Link is responsible for detecting the existence of an IP packet flow through it that might benefit from a shortcut connection.
論理リンクからの出力ルーターは、適切に構成されている場合、ショートカット接続の恩恵を受ける可能性のある、IPパケットフローの存在を検出します。
While continuing to conventionally forward the flow's packets, the router initiates an NHRP query for the flow's destination IP address.
従来の方法でフローのパケットを転送し続けている間に、ルーターはフローの宛先IPアドレスのNHRPクエリを開始します。
The last router/NHS before the target of the NHRP query ascertains the target interface's preferred NBMA address.
NHRPクエリのターゲットの前の最後のルーター/ NHSは、ターゲットインターフェイスの優先NBMAアドレスを確認します。
The originally querying router then issues a Redirect to the IP source, identifying the flow's destination as a transient Neighbor.
次に、元々クエリを行っているルーターがIP送信元にリダイレクトを発行し、フローの宛先を一時的な隣接ルーターとして識別します。
Host-initiated triggering of shortcut discovery, regardless of the existence of a packet flow, is also supported through specific Neighbor Solicitations sent to a source host's default router.
パケットフローの存在に関係なく、ホストが開始したショートカット検出のトリガーは、送信元ホストのデフォルトルーターに送信される特定の近隣要請によってもサポートされます。
A number of key advantages are claimed for this approach. These are:
このアプローチには、いくつかの重要な利点があります。これらは：
The IPv6 stacks on hosts do not implement separate ND protocols for each link layer technology.
ホスト上のIPv6スタックは、リンクレイヤーテクノロジごとに個別のNDプロトコルを実装していません。
When the destination of a flow is solicited as a transient neighbor, the returned NBMA address will be the one chosen by the destination when the flow was originally established through hop-by-hop processing. This supports the existing ND ability for IPv6 destinations to perform their own dynamic interface load sharing.
フローの宛先が一時的なネイバーとして要請されている場合、返されるNBMAアドレスは、ホップバイホップ処理によってフローが最初に確立されたときに宛先によって選択されたアドレスになります。これは、IPv6宛先が独自の動的インターフェースロードシェアリングを実行するための既存のND機能をサポートします。
1.4 Terminology.
1.4 用語。
The bit-pattern or numeric value used to identify a particular NBMA interface at the NBMA level will be referred to as an "NBMA address". (An example would be an ATM End System Address, AESA, when applying this architecture to ATM networks, or an E.164 number when applying this architecture to SMDS networks.)
NBMAレベルで特定のNBMAインターフェイスを識別するために使用されるビットパターンまたは数値は、「NBMAアドレス」と呼ばれます。 （この例は、このアーキテクチャをATMネットワークに適用する場合のATMエンドシステムアドレス、AESA、またはこのアーキテクチャをSMDSネットワークに適用する場合のE.164番号です。）
The call that, once established, is used to transfer IP packets from one NBMA interface to another will be referred to as an SVC or PVC depending on whether the call is dynamically established through some signaling mechanism, or administratively established. The specific signaling mechanisms used to establish or tear down an SVC will be defined in the NBMA-specific companion specifications. Certain NBMA networks may provide a form of connectionless service (e.g. SMDS). In these cases, a "call" or "SVC" shall be considered to implicitly exist if the sender has an NBMA destination address to which it can transmit packets whenever it desires.
いったん確立されると、あるNBMAインターフェイスから別のNBMAインターフェイスにIPパケットを転送するために使用されるコールは、コールが何らかのシグナリングメカニズムを通じて動的に確立されるか、管理上確立されるかに応じて、SVCまたはPVCと呼ばれます。 SVCの確立または破棄に使用される特定のシグナリングメカニズムは、NBMA固有のコンパニオン仕様で定義されます。特定のNBMAネットワークは、ある種のコネクションレスサービス（SMDSなど）を提供する場合があります。これらの場合、送信者が希望するときにいつでもパケットを送信できるNBMA宛先アドレスを持っている場合、「呼び出し」または「SVC」は暗黙的に存在すると見なされます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [16].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [16]で説明されているように解釈されます。
1.5 Document Structure.
1.5 ドキュメント構造。
The remainder of this document is structured as follows: Section 2 explains the generalization of IPv6 Link to "Logical Link" when used over NBMA networks, and introduces the notion of the Transient Neighbor. Section 3 describes the modifications to the MARS protocol for efficient distribution of ND messages within a Logical Link, and the rules and mechanisms for discovering Transient Neighbors. Section 4 covers the basic rules governing IPv6/NBMA interface initialization, packet and control message encapsulations, and rules for SVC management. Section 5 describes the general rules for constructing Interface Tokens, the Link Layer Address Option, and Link Local addresses. Section 6 concludes the normative sections of the document. Appendix A provides some non-normative descriptive text regarding the operation of Ipv6 Neighbor Discovery. Appendix B describes some sub-optimal solutions for emulating the multicasting of Neighbor Discovery messages around a Logical Link. Appendix C discusses shortcut suppression and briefly reviews the future relationships between flow detection and mapping of flows onto SVCs of differing qualities of service.
このドキュメントの残りの部分は、次のように構成されています。セクション2では、NBMAネットワークで使用する場合の「論理リンク」へのIPv6リンクの一般化について説明し、一時的なネイバーの概念を紹介します。セクション3では、論理リンク内でNDメッセージを効率的に配信するためのMARSプロトコルの変更、および一時的なネイバーを検出するためのルールとメカニズムについて説明します。セクション4では、IPv6 / NBMAインターフェイスの初期化を制御する基本的なルール、パケットおよび制御メッセージのカプセル化、およびSVC管理のルールについて説明します。セクション5では、インターフェイストークン、リンク層アドレスオプション、およびリンクローカルアドレスを作成するための一般的なルールについて説明します。セクション6では、ドキュメントの標準セクションを終了します。付録Aは、Ipv6近隣探索の操作に関するいくつかの非規範的な説明文を提供します。付録Bでは、論理リンクの周囲の近隣探索メッセージのマルチキャストをエミュレートするためのいくつかの最適ではないソリューションについて説明します。付録Cでは、ショートカットの抑制について説明し、フロー検出と、サービス品質の異なるSVCへのフローのマッピングとの間の将来の関係を簡単に確認します。
2. Logical Links, and Transient Neighbors.
2. 論理リンク、および一時的なネイバー。
IPv6 contains a concept of on-link and off-link. Neighbors are those nodes that are considered on-link and whose link-layer addresses may therefore be located using Neighbor Discovery. Borrowing from the terminology definitions in the ND text:
IPv6には、オンリンクとオフリンクの概念が含まれています。ネイバーとは、リンク上と見なされるノードであり、そのため、リンク層アドレスはネイバー探索を使用して特定できます。 NDテキストの用語定義から借用：
on-link - an address that is assigned to a neighbor's interface on a shared link. A host considers an address to be on-link if: - it is covered by one of the link's prefixes, or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the target address, or - a Neighbor Discovery message is received from the address.
オンリンク-共有リンク上のネイバーのインターフェースに割り当てられるアドレス。次の場合、ホストはアドレスがリンク上にあると見なします。-リンクのプレフィックスの1つでカバーされている、または-近隣ルーターがリダイレクトメッセージのターゲットとしてアドレスを指定している、または-ターゲットの近隣アドバタイズメッセージを受信しているアドレス、または-近隣探索メッセージがアドレスから受信されます。
off-link - the opposite of "on-link"; an address that is not assigned to any interfaces attached to a shared link.
オフリンク-「オンリンク」の反対。共有リンクに接続されているインターフェースに割り当てられていないアドレス。
Off-link nodes are considered to only be accessible through one of the routers directly attached to the link.
オフリンクノードは、リンクに直接接続されているルーターの1つを介してのみアクセス可能と見なされます。
The NBMA environment complicates the sense of the word 'link' in much the same way as it complicated the sense of 'subnet' in the IPv4 case. For IPv4 this required the definition of the Logical IP Subnet (LIS) - an administratively constructed set of hosts that would share the same routing prefixes (network and subnetwork masks).
NBMA環境は、IPv4の場合の「サブネット」の意味を複雑にするのと同じように、「リンク」という単語の意味を複雑にします。 IPv4の場合、これには論理IPサブネット（LIS）の定義が必要でした。これは、同じルーティングプレフィックス（ネットワークおよびサブネットワークマスク）を共有する管理上構築されたホストのセットです。
This document considers the IPv6 analog to be a Logical Link (LL).
このドキュメントでは、IPv6アナログを論理リンク（LL）と見なしています。
An LL consists of nodes administratively configured to be 'on link' with respect to each other.
LLは、相互に「リンク」するように管理上構成されたノードで構成されます。
The members of an LL are an IPv6 interface's initial set of neighbors, and each interface's Link Local address only needs to be unique amongst this set.
LLのメンバーは、IPv6インターフェースの最初のネイバーのセットであり、各インターフェースのリンクローカルアドレスは、このセットの中で一意である必要があるだけです。
It should be noted that whilst members of an LL are IPv6 Neighbors, it is possible for Neighbors to exist that are not, administratively, members of the same LL.
LLのメンバーはIPv6ネイバーですが、管理上、同じLLのメンバーではないネイバーが存在する可能性があることに注意してください。
Neighbor Discovery events can result in the expansion of an IPv6 interface's set of Neighbors. However, this does not change the set of interfaces that make up its LL. This leads to three possible relationships between any two IPv6 interfaces:
近隣探索イベントにより、IPv6インターフェースの一連の近隣が拡張される可能性があります。ただし、これはそのLLを構成する一連のインターフェースを変更しません。これにより、任意の2つのIPv6インターフェース間に3つの可能な関係が生じます。
- On LL, Neighbor. - Off LL, Neighbor. - Off LL, not Neighbor.
- LLでは、ネイバー。 -オフLL、ネイバー。 -LLではなく、ネイバーではありません。
Off LL Neighbors represent the 'shortcut' connections, where it has been ascertained that direct connectivity at the NBMA level is possible to a target that is not a member of the source's LL.
オフLLネイバーは「ショートカット」接続を表し、NBMAレベルでの直接接続が、ソースのLLのメンバーではないターゲットに可能であることが確認されています。
Neighbors discovered through the operation of unsolicited messages, such as Redirects, are termed 'Transient Neighbors'.
リダイレクトなどの一方的なメッセージの操作を通じて発見されたネイバーは、「一時的なネイバー」と呼ばれます。
3. Intra-LL and Inter-LL Discovery.
3. LL内およびLL間ディスカバリー。
This document makes a distinction between the discovery of neighbors within a Logical Link (intra-LL) and neighbors beyond the LL (inter-LL). The goal is to allow both inter- and intra-LL neighbor discovery to involve no changes to the host-side IPv6 stack for NBMA interfaces.
このドキュメントでは、論理リンク（LL内）内のネイバーの発見とLL（インターLL）を超えたネイバーの発見を区別しています。目標は、LLMA内およびLL内の両方のネイバー探索で、NBMAインターフェイスのホスト側IPv6スタックに変更を加えないようにすることです。
Note that section 1.3.1 applies when the NBMA network is being used to provide only configured point to point (PVC) service.
セクション1.3.1は、NBMAネットワークが構成されたポイントツーポイント（PVC）サービスのみを提供するために使用されている場合に適用されることに注意してください。
3.1 Intra-LL - ND over emulated multicast.
3.1 Intra-LL-エミュレートされたマルチキャスト上のND。
The basic model of ND assumes that a link layer interface will do something meaningful with an ICMPv6 packet sent to a multicast IP destination address. (IPv6 assumes that multicasting is an integral part of the Internet service.) This document assumes multicast support will be provided using the RFC 2022 (MARS) [5] service (generalized for use over other NBMA technologies in addition to ATM). An IPv6 LL maps directly onto an IPv6 MARS Cluster in the same way an IPv4 LIS maps directly onto an IPv4 MARS Cluster.
NDの基本モデルでは、リンクレイヤーインターフェイスが、マルチキャストIP宛先アドレスに送信されるICMPv6パケットで意味のあることを行うと想定しています。 （IPv6は、マルチキャストがインターネットサービスの不可欠な部分であると想定しています。）このドキュメントでは、RFC 2022（MARS）[5]サービス（ATMに加えて他のNBMAテクノロジで使用するために一般化）を使用してマルチキャストサポートが提供されることを想定しています。 IPv6 LLは、IPv4 LISがIPv4 MARSクラスターに直接マップするのと同じ方法で、IPv6 MARSクラスターに直接マップします。
The goal of intra-LL operation is that the IPv6 layer must be able to simply pass multicast ICMPv6 packets down to the IPv6/NBMA driver without any special, NBMA specific processing. The underlying mechanism for distributing Neighbor Discovery and Router Discovery messages then works as expected.
LL内操作の目標は、IPv6層がマルチキャストICMPv6パケットをIPv6 / NBMAドライバーに渡すだけで、特別なNBMA固有の処理を行わないことです。近隣探索メッセージとルーター探索メッセージを配信するための基本的なメカニズムは、期待どおりに機能します。
Sections 3.1.1 describes the additional functionality that SHALL be required of any MARS used in conformance with this document. Background discussion of these additions is provided in Appendix B.
セクション3.1.1では、このドキュメントに準拠して使用されるMARSに必要となる追加機能について説明します。これらの追加の背景説明は、付録Bにあります。
3.1.1 Mandatory augmented MARS and MARS Client behavior.
3.1.1 必須の拡張されたMARSおよびMARSクライアントの動作。
IPv6/NBMA interfaces SHALL register as MARS Cluster members as described in section 4.1, and SHALL send certain classes of outgoing IPv6 packets directly to their local MARS as described in section 4.4.2.
IPv6 / NBMAインターフェイスは、セクション4.1で説明されているようにMARSクラスターメンバーとして登録する必要があり（SHALL）、セクション4.4.2で説明されているように、特定のクラスの発信IPv6パケットをローカルMARSに直接送信するものとします（SHALL）。
The MARS itself SHALL then re-transmit these packets according to the following rules:
次に、MARS自体は、次のルールに従ってこれらのパケットを再送信する必要があります。
- When the MARS receives an IPv6 packet, it scans the group membership database to find the NBMA addresses of the IPv6 destination group's members.
- MARSはIPv6パケットを受信すると、グループメンバーシップデータベースをスキャンして、IPv6宛先グループのメンバーのNBMAアドレスを見つけます。
- The MARS then checks to see if every group member currently has its pt-pt control VC open to the MARS. If so, the MARS sends a copy of the data packet directly to each group member over the existing pt-pt VCs.
- 次に、MARSは、すべてのグループメンバーが現在そのPT-PT制御VCをMARSに対して開いているかどうかを確認します。その場合、MARSはデータパケットのコピーを既存のpt-pt VCを介して各グループメンバーに直接送信します。
- If one or more of the discovered group members do not have an open pt-pt VC to the MARS, or if there are no group members listed, the packet is sent out ClusterControlVC instead. No copies of the packet are sent over the existing (if any) pt-pt VCs.
- 検出されたグループメンバーの1つ以上にMARSへのオープンpt-pt VCがない場合、またはグループメンバーがリストされていない場合は、代わりにパケットがClusterControlVCに送信されます。パケットのコピーは、既存の（存在する場合）pt-pt VCを介して送信されません。
3.2 Inter-LL - Redirects, and their generation.
3.2 Inter-LL-リダイレクトとその生成。
Shortcut connections are justified on the grounds that demanding flows of IP packets may exist between source/destination pairs that are separated by IP routing boundaries. Shortcuts are created between Transient Neighbors.
ショートカット接続は、IPルーティング境界によって分離された送信元/宛先ペアの間にIPパケットの要求の多いフローが存在する可能性があるという理由で正当化されます。ショートカットは一時的なネイバー間に作成されます。
The key to creating transient neighbors is the Redirect message (section 8 [7]). IPv6 allows a router to inform the members of an LL that there is a better 'first hop' to a given destination (section 8.2 [7]). The advertisement itself is achieved through a Router Redirect message, which may carry the link layer address of this better hop.
一時的なネイバーを作成するための鍵は、リダイレクトメッセージです（セクション8 [7]）。 IPv6を使用すると、ルーターはLLのメンバーに、特定の宛先へのより良い「最初のホップ」があることを通知できます（セクション8.2 [7]）。アドバタイズメント自体は、このより良いホップのリンク層アドレスを運ぶことができるルーターリダイレクトメッセージを介して行われます。
A transmitting host only listens to Router Redirects from the router that is currently acting as the default router for the IP destination that the Redirect refers to. If a Redirect arrives that indicates a better first hop for a given destination, and supplies a link layer (NBMA) address to use as the better first hop, the associated Neighbor Cache entry in the source host is updated and its reachability set to STALE. Updating the cache in this context involves building a new VC to the new NBMA address. If this is successful, the old VC is torn down only if it no longer required (since the old VC was to the router, it may still be required by other packets from the host that are heading to the router).
送信ホストは、リダイレクトが参照するIP宛先のデフォルトルーターとして現在機能しているルーターからのルーターリダイレクトのみをリッスンします。特定の宛先のより良い最初のホップを示すリダイレクトが到着し、より良い最初のホップとして使用するリンク層（NBMA）アドレスを提供する場合、ソースホストの関連する近隣キャッシュエントリが更新され、その到達可能性がSTALEに設定されます。このコンテキストでキャッシュを更新するには、新しいVCを新しいNBMAアドレスに構築する必要があります。これが成功した場合、古いVCは不要になった場合にのみ破棄されます（古いVCはルーター宛であったため、ルーターに向かうホストからの他のパケットで引き続き必要になる場合があります）。
Two mechanisms are provided for triggering the discovery of a better first hop:
より良い最初のホップの発見をトリガーするために、2つのメカニズムが提供されています。
Router-based flow identification/detection.
ルーターベースのフロー識別/検出。
Host-initiated shortcut request.
ホストが開始したショートカット要求。
Section 3.2.1 discusses flow-based triggers, section 3.2.2 discusses the host initiated trigger, and section 3.2.3 discusses the use of NHRP to discover mappings for IPv6 targets in remote LLs.
セクション3.2.1はフローベースのトリガーについて説明し、セクション3.2.2はホストが開始したトリガーについて説明し、セクション3.2.3はNHRPを使用してリモートLL内のIPv6ターゲットのマッピングを検出する方法について説明します。
3.2.1 Flow Triggered Redirection.
3.2.1 フローによってトリガーされるリダイレクト。
The modification of forwarding paths based on the dynamic detection of IP packet flows is at the core of models such as the Cell Switch Router [11] and the IP Switch [12]. Responsibility for detecting flows is placed into the routers, where packets cross the edges of IP routing boundaries.
IPパケットフローの動的検出に基づく転送パスの変更は、Cell Switch Router [11]やIP Switch [12]などのモデルの中核です。フローを検出する責任はルーターに置かれ、パケットはIPルーティング境界のエッジを通過します。
For the purpose of conformance with this document, a router MAY choose to initiate the discovery of a better first-hop when it determines that an identifiable flow of IP packets are passing through it.
このドキュメントに準拠するために、ルーターは、IPパケットの識別可能なフローが通過していると判断したときに、より良い最初のホップの発見を開始することを選択できます。
Such a router:
このようなルーター：
SHALL only track flows that originate from a directly attached host (a host that is within the LL-local scope of one of the router's interfaces).
直接接続されたホスト（ルーターのいずれかのインターフェイスのLLローカルスコープ内にあるホスト）から発生するフローのみを追跡する必要があります。
SHALL NOT use IP packets arriving from another router to trigger the generation of a Router Redirect.
別のルーターから到着するIPパケットを使用してルーターリダイレクトの生成をトリガーすることはできません。
SHALL only consider IPv6 packets with FlowID of zero for the purposes of flow detection as defined in this section.
このセクションで定義されているフロー検出の目的で、FlowIDがゼロのIPv6パケットのみを考慮する必要があります（SHALL）。
SHALL utilize NHRP as described in section 3.2.3 to ascertain a better first-hop when a suitable flow is detected, and advertise the information in a Router Redirect.
セクション3.2.3で説明されているように、NHRPを利用して、適切なフローが検出されたときに最初のホップが適切であることを確認し、ルーターリダイレクトで情報を通知する必要があります（SHALL）。
IPv6 routers that support the OPTIONAL flow detection behavior described above SHALL support administrative mechanisms to switch off flow-detection. They MAY provide mechanisms for adding additional constraints to the categories of IPv6 packets that constitute a 'flow'.
上記のオプションのフロー検出動作をサポートするIPv6ルーターは、フロー検出をオフにする管理メカニズムをサポートするものとします（SHALL）。それらは、「フロー」を構成するIPv6パケットのカテゴリに追加の制約を追加するためのメカニズムを提供する場合があります。
The actual algorithm(s) for determining what sequence of IPv6 packets constitute a 'flow' are outside the scope of this document. Appendix C discusses the rationale behind the use of non-zero FlowID to suppress flow detection.
IPv6パケットのどのシーケンスが「フロー」を構成するかを決定する実際のアルゴリズムは、このドキュメントの範囲外です。付録Cでは、ゼロ以外のFlowIDを使用してフロー検出を抑制する理由について説明します。
A source host MAY also trigger a redirection to a transient neighbor. To support host-triggered redirects, routers conforming to this document SHALL recognize specific Neighbor Solicitation messages sent by hosts as requests for the resolution of off-link addresses.
ソースホストは、一時的なネイバーへのリダイレクトもトリガーする場合があります。ホストトリガーリダイレクトをサポートするために、このドキュメントに準拠するルーターは、ホストから送信された特定の近隣要請メッセージを、オフリンクアドレスの解決要求として認識するものとします（SHALL）。
To perform a host-triggered redirect, a source host SHALL:
ホストトリガーのリダイレクトを実行するには、ソースホストは以下のことを行う必要があります。
Create a Neighbor Solicitation message referring to the off-LL destination (target) for which a shortcut is desired
ショートカットが必要なオフLL宛先（ターゲット）を参照する近隣要請メッセージを作成する
Address the NS message to the router that would be the next hop for traffic sent towards the off-LL target (rather than the target's solicited node multicast address).
（ターゲットの送信請求ノードマルチキャストアドレスではなく）オフLLターゲットに送信されるトラフィックのネクストホップとなるルーターにNSメッセージをアドレス指定します。
Use the standard ND hop limit of 255 to ensure the NS won't be discarded by the router.
標準のNDホップ制限255を使用して、NSがルーターによって破棄されないようにします。
Include the shortcut limit option defined in appendix D. The value of this option should be equal to the hop limit of the data flow for which this trigger is being sent. This ensures that the router is able to restrict the shortcut attempt to not exceed the reach of the data flow.
付録Dで定義されているショートカット制限オプションを含めます。このオプションの値は、このトリガーが送信されるデータフローのホップ制限と等しい必要があります。これにより、ルーターがショートカット試行を制限して、データフローの到達範囲を超えないようにすることができます。
Forward the NS packet to the router that would be the next hop for traffic sent towards the off-LL target.
NSパケットを、オフLLターゲットに送信されるトラフィックのネクストホップとなるルーターに転送します。
Routers SHALL consider a unicast NS with shortcut limit option as a request for a host-triggered redirect. However, actual shortcut discovery is OPTIONAL for IPv6 routers.
ルータは、ショートカット制限オプション付きのユニキャストNSを、ホストがトリガーするリダイレクトの要求と見なすものとします（SHALL）。ただし、実際のショートカット検出はIPv6ルーターではオプションです。
When shortcut discovery is not supported, the router SHALL construct a Redirect message identifying the router itself as the best 'shortcut', and return it to the soliciting host.
ショートカットディスカバリがサポートされていない場合、ルータはルータ自体を最適な「ショートカット」として識別するリダイレクトメッセージを作成し、それを要請ホストに返す必要があります。
If shortcut discovery is to be supported, the router's response SHALL be:
ショートカット検出がサポートされる場合、ルーターの応答は次のようになります。
A suitable NHRP Request is constructed and sent as described in section 3.2.3. The original NS message SHOULD be discarded.
セクション3.2.3で説明されているように、適切なNHRP要求が作成および送信されます。元のNSメッセージは破棄する必要があります。
Once the NHRP Reply is received by the originating router, the router SHALL construct a Redirect message containing the IPv6 address of the transient neighbor, and the NBMA link layer address returned by the NHRP resolution process.
元のルーターがNHRP応答を受信すると、ルーターは一時的なネイバーのIPv6アドレスと、NHRP解決プロセスによって返されたNBMAリンク層アドレスを含むリダイレクトメッセージを作成する必要があります（SHALL）。
The resulting Redirect message SHALL then be transmitted back to the source host. When the Redirect message is received, the source host SHALL update its Neighbor and Destination caches.
結果のリダイレクトメッセージは、送信元ホストに送信される必要があります（SHALL）。リダイレクトメッセージが受信されると、送信元ホストはその隣接キャッシュと宛先キャッシュを更新する必要があります（SHALL）。
The off-LL target is now considered a Transient Neighbor. The next packet sent to the Transient Neighbor will result in the creation of the direct, shortcut VC (to the off-LL target itself, or to the best egress router towards that neighbor as determined by NHRP).
オフLLターゲットは、一時的なネイバーと見なされます。 Transient Neighborに送信される次のパケットにより、直接のショートカットVCが作成されます（オフLLターゲット自体へ、またはNHRPによって決定されたそのネイバーへの最適な出力ルーターへ）。
If a NHRP NAK or error indication is received for a host-triggered shortcut attempt, the requesting router SHALL construct a Redirect message identifying the router itself as the best 'shortcut', and return it to the soliciting host.
ホストによってトリガーされるショートカットの試行に対してNHRP NAKまたはエラー通知が受信された場合、要求元ルーターは、ルーター自体を最適な「ショートカット」として識別するリダイレクトメッセージを作成し（SHALL）、それを要請ホストに返す必要があります。
3.2.3 Use of NHRP between routers.
3.2.3 ルーター間でのNHRPの使用。
Once flow detection has occurred, or a host trigger has been detected, routers SHALL use NHRP in an NHS to NHS mode to establish the IPv6 to link level address mapping of a better first hop.
フロー検出が発生した場合、またはホストトリガーが検出された場合、ルーターはNHSからNHSモードでNHRPを使用して、IPv6からリンクレベルのアドレスマッピングを確立し、より適切な最初のホップを確立する必要があります（SHALL）。
IPv6/NBMA routers supporting shortcut discovery will need to perform some or all of the following functions:
ショートカット検出をサポートするIPv6 / NBMAルーターは、次の機能の一部またはすべてを実行する必要があります。
- Construct NHRP Requests and Replies.
- NHRP要求と応答を作成します。
- Parse incoming NHRP Requests and Replies from other NHSes (routers).
- 他のNHS（ルーター）からの着信NHRP要求と応答を解析します。
- Forward NHRP Requests towards an NHS that is topologically closer to the IPv6 target.
- トポロジ的にIPv6ターゲットに近いNHSにNHRP要求を転送します。
- Forward NHRP Replies towards an NHS that is topologically closer to the requester.
- フォワードNHRP応答は、トポロジー上でリクエスターにより近いNHSに向けます。
- Perform syntax translation between Neighbor Solicitations and outbound NHRP Requests.
- 近傍要請と発信NHRP要求の間で構文変換を実行します。
- Perform syntax translation between inbound NHRP Replies and Redirects.
- インバウンドNHRP応答とリダイレクトの間で構文変換を実行します。
The destination of the flow that caused the trigger (or the target of the host initiated trigger) is used as the target for resolution in a NHRP Request. The router then forwards this NHRP Request to the next closest NHS. The process continues (as it would for normal NHRP) until the Request reaches an NHS that believes the IP target is within link-local scope of one of its interfaces. (This may potentially occur within a single router.)
トリガーを引き起こしたフローの宛先（またはホストが開始したトリガーのターゲット）は、NHRP要求の解決のターゲットとして使用されます。次に、ルーターはこのNHRP要求を次に近いNHSに転送します。プロセスは（通常のNHRPの場合と同様に）、要求が、IPターゲットがそのインターフェイスの1つのリンクローカルスコープ内にあると考えるNHSに到達するまで続きます。 （これは、単一のルーター内で発生する可能性があります。）
As NHRP resolution requests always follow the routed path for a given target protocol address, the scope of a shortcut request will be automatically bounded to the scope of the IPv6 target address. (e.g. resolution requests for site-local addresses will not be forwarded across site boundaries.)
NHRP解決要求は常に特定のターゲットプロトコルアドレスのルーティングされたパスをたどるので、ショートカット要求のスコープはIPv6ターゲットアドレスのスコープに自動的にバインドされます。 （たとえば、サイトローカルアドレスの解決要求は、サイト境界を越えて転送されません。）
The last hop router SHALL resolve the NHRP Request from mapping information contained in its neighbor cache for the interface on which the specified target is reachable. If there is no appropriate entry in the Neighbor cache, or the destination is currently considered unreachable, the last hop router SHALL perform Neighbor Discovery on the local interface, and build the NHRP Reply from the resulting answer. (Note, in the case where the NHRP Request originated due to flow detection, there must already be a hop-by-hop flow of packets going through the last hop router towards the target. In this typical case the Neighbor cache will already have the desired information.)
ラストホップルーターは、指定されたターゲットが到達可能なインターフェイスのネイバーキャッシュに含まれるマッピング情報からNHRP要求を解決するものとします（SHALL）。ネイバーキャッシュに適切なエントリがない場合、または宛先が現在到達不能と見なされている場合、ラストホップルータはローカルインターフェイスでネイバーディスカバリを実行して、結果の回答からNHRP応答を構築する必要があります（SHALL）。 （フロー検出が原因でNHRP要求が発生した場合、ターゲットに向かって最後のホップルーターを通過するパケットのホップバイホップフローが既に存在している必要があります。この一般的なケースでは、近隣キャッシュにはすでに必要な情報。）
The NHRP Reply is propagated back to the source of the NHRP Request, using a hop-by-hop path as it would for normal NHRP.
NHRP応答は、通常のNHRPの場合と同様にホップバイホップパスを使用して、NHRP要求の送信元に戻されます。
If the discovery process was triggered through flow detection at the originating router, the return of the NHRP Reply results in the following events:
元のルーターでのフロー検出によって検出プロセスがトリガーされた場合、NHRP応答が返されると、次のイベントが発生します。
A Redirect is constructed using the IPv6/NBMA mapping carried in the NHRP Reply.
リダイレクトは、NHRP応答で伝達されるIPv6 / NBMAマッピングを使用して構築されます。
The Redirect is unicast to the IP packet flow's source (using the VC on which the flow is arriving at the router, if it is a bi-directional pt-pt VC).
リダイレクトは、IPパケットフローのソースへのユニキャストです（双方向pt-pt VCの場合、フローがルーターに到達するVCを使用）。
Any Redirect message sent by a router MUST conform to all the rules described in [7] so that the packet is properly validated by the receiving host. Specifically, if the target of the resulting short-cut is the destination host then the ICMP Target Address MUST be the same as the ICMP Destination Address in the original message. If the target of the short-cut is an egress router then the ICMP Target Address MUST be a Link Local address of the egress router that is unique to the NBMA cloud to which the router's NBMA interface is attached.
ルーターが送信するすべてのリダイレクトメッセージは、パケットが受信ホストによって適切に検証されるように、[7]で説明されているすべてのルールに準拠する必要があります。特に、結果のショートカットのターゲットが宛先ホストである場合、ICMPターゲットアドレスは元のメッセージのICMP宛先アドレスと同じでなければなりません。ショートカットのターゲットが出力ルーターの場合、ICMPターゲットアドレスは、ルーターのNBMAインターフェイスが接続されているNBMAクラウドに固有の出力ルーターのリンクローカルアドレスである必要があります。
Also note that egress routers may subsequently redirect the source host. To do so, the Link Local ICMP Source Address of the Redirect message MUST be the same as the Link Local ICMP Target Address of the original Redirect message.
また、出力ルーターが送信元ホストをリダイレクトすることもあります。そのためには、リダイレクトメッセージのリンクローカルICMPソースアドレスは、元のリダイレクトメッセージのリンクローカルICMPターゲットアドレスと同じである必要があります。
Note that the router constructing the NHRP Reply does so using the NBMA address returned by the target host when the target host first accepted the flow of IP traffic. This retains a useful feature of Neighbor Discovery - destination interface load sharing.
NHRP応答を構築するルーターは、ターゲットホストが最初にIPトラフィックのフローを受け入れたときに、ターゲットホストから返されたNBMAアドレスを使用してこれを行うことに注意してください。これにより、近隣探索の便利な機能が維持されます-宛先インターフェイスのロードシェアリング。
Upon receipt of a NHRP NAK reply or error indication for a flow-triggered shortcut attempt, no indication is sent to the source of the flow.
NHRP NAK応答またはフローによってトリガーされるショートカット試行のエラー表示を受信すると、フローの送信元に表示は送信されません。
3.2.3.1 NHRP/ND packet translation rules.
3.2.3.1 NHRP / NDパケット変換ルール。
The following translation rules are meant to augment the packet format specification in section 5 of the NHRP specification [8], covering those packet fields specifically utilized by the IPv6/NBMA architecture.
次の変換規則は、NHRP仕様のセクション5のパケット形式仕様を強化することを目的としており、IPv6 / NBMAアーキテクチャで特に利用されるパケットフィールドをカバーしています。
NHRP messages are constructed and sent according to the rules in [8]. The value of the NBMA technology specific fields such as ar$afn, ar$pro.type, ar$pro.snap and link layer address format are defined in NBMA-specific companion documents. Source, destination or client protocol addresses in the common header or CIE of a NHRP message are always IPv6 addresses of length 16.
NHRPメッセージは、[8]のルールに従って作成および送信されます。 ar $ afn、ar $ pro.type、ar $ pro.snap、リンク層アドレス形式などのNBMAテクノロジ固有のフィールドの値は、NBMA固有の関連ドキュメントで定義されています。 NHRPメッセージの共通ヘッダーまたはCIEの送信元、宛先、またはクライアントプロトコルアドレスは、常に長さ16のIPv6アドレスです。
When constructing an host-triggered NHRP resolution request in response to a Neighbor Solicitation:
近隣要請に応じてホストトリガーNHRP解決要求を作成する場合：
The ar$hopcnt field MUST be smaller than the shortcut limit value specified in the shortcut limit option included in the triggering NS message. This ensures that hosts have control over the reach of their shortcut request. Note that the shortcut limit given in the option is relative to the requesting host, thus the requirement of ar$hopcnt being smaller than the given shortcut limit.
ar $ hopcntフィールドは、トリガーNSメッセージに含まれるショートカット制限オプションで指定されたショートカット制限値よりも小さくなければなりません。これにより、ホストはショートカット要求の到達範囲を確実に制御できます。オプションで指定されたショートカット制限は要求元のホストに関連しているため、ar $ hopcntの要件は指定されたショートカット制限よりも小さいことに注意してください。
The Flags field in the common header of the NHRP resolution request SHOULD have the Q and S bits set.
NHRP解決要求の共通ヘッダーのフラグフィールドには、QおよびSビットが設定されている必要があります（SHOULD）。
The U bit SHOULD be set. NBMA and protocol source addresses are those of the router constructing the request.
Uビットを設定する必要があります。 NBMAとプロトコルの送信元アドレスは、要求を構成するルーターのアドレスです。
The target address from the NS message is used as the NHRP destination protocol address. A CIE SHALL NOT be specified.
NSメッセージからのターゲットアドレスは、NHRP宛先プロトコルアドレスとして使用されます。 CIEは指定しないでください。
When constructing a NHRP resolution request as a result of flow detection, the choice of values is configuration dependent.
フロー検出の結果としてNHRP解決要求を作成する場合、値の選択は構成に依存します。
A NHRP resolution reply is build according to the rules in [8].
NHRP解決応答は、[8]のルールに従って作成されます。
For each CIE returned, the holding time is 10 minutes.
返されたCIEごとに、保持時間は10分です。
The MTU may be 0 or a value specified in the NBMA-specific companion document.
MTUは0またはNBMA固有の関連ドキュメントで指定されている値の場合があります。
A successful NHRP resolution reply for a host-triggered shortcut attempt is translated into an IPv6 Redirect message as follows:
ホストがトリガーしたショートカット試行に対するNHRP解決応答が成功すると、次のようにIPv6リダイレクトメッセージに変換されます。
IP Fields: Source Address The link-local address assigned to the router's interface from which this message is sent. Destination Address IPv6 Source Address of the triggering NS Hop Limit 255
IPフィールド：送信元アドレスこのメッセージの送信元であるルーターのインターフェースに割り当てられたリンクローカルアドレス。トリガーするNSホップ制限の宛先アドレスIPv6送信元アドレス255
ICMP Fields: Target Address NHRP Client Protocol Address Destination Address Target of triggering NS (this is equivalent to the NHRP Destination Protocol Address) Target link-layer address NHRP Client NBMA Address
ICMPフィールド：ターゲットアドレスNHRPクライアントプロトコルアドレス宛先アドレストリガーNSのターゲット（これはNHRP宛先プロトコルアドレスと同等です）ターゲットリンク層アドレスNHRPクライアントNBMAアドレス
All NHRP extensions currently defined in [8] have no effect on NHRP/ND translation and MAY be used in NHRP messages for IPv6.
[8]で現在定義されているすべてのNHRP拡張はNHRP / ND変換に影響を与えず、IPv6のNHRPメッセージで使用できます（MAY）。
3.2.3.2 NHRP Purge rules.
3.2.3.2 NHRPパージルール。
Purges are generated by NHRP when changes are detected that invalidate a previously issued NHRP Reply (this may include topology changes, or a target host going down or changing identity). Any IPv6 shortcut previously established on the basis of newly purged information SHOULD be torn down.
以前に発行されたNHRP応答を無効にする変更が検出されると、パージがNHRPによって生成されます（これには、トポロジの変更、またはターゲットホストの停止またはIDの変更が含まれる場合があります）。新たに削除された情報に基づいて以前に確立されたIPv6ショートカットは、破棄する必要があります。
Routers SHALL keep track of NHRP cache entries for which they have issued Neighbor Advertisements or Router Redirects. If a NHRP Purge is received that invalidates information previously issued to local host, the router SHALL issue a Router Redirect specifying the router itself as the new best next-hop for the affected IPv6 target.
ルーターは近隣アドバタイズまたはルーターリダイレクトを発行したNHRPキャッシュエントリを追跡する必要があります。以前にローカルホストに発行された情報を無効にするNHRPパージを受信した場合、ルーターはルーターリダイレクトを発行して、影響を受けるIPv6ターゲットの新しい最適なネクストホップとしてルーター自体を指定する必要があります（SHALL）。
Routers SHALL keep track of Neighbor cache entries that have previously been used to generate an NHRP Reply. The expiry of any such Neighbor cache entry SHALL result in a NHRP Purge being sent towards the router that originally requested the NHRP Reply.
ルータは、NHRP応答を生成するために以前に使用されたネイバーキャッシュエントリを追跡する必要があります。そのようなネイバーキャッシュエントリの有効期限が切れると、NHRPパージが、最初にNHRP応答を要求したルーターに送信されます
3.3. Neighbor Unreachability Detection.
3.3. ネイバー到達不能検出。
Neighbor Solicitations sent for the purposes of Neighbor Unreachability Detection (NUD) are unicast to the Neighbor in question, using the VC that is already open to that Neighbor. This suggests that as far as NUD is concerned, the Transient Neighbor is indistinguishable from an On-LL Neighbor.
Neighbor Unreachability Detection（NUD）の目的で送信されたNeighbor Solicitationは、そのNeighborに対してすでに開いているVCを使用して、問題のNeighborにユニキャストされます。これは、NUDに関する限り、一時的なネイバーはOn-LLネイバーと区別がつかないことを示唆しています。
3.4. Duplicate Address Detection.
3.4. 重複アドレス検出。
Duplicate Address Detection is only required within the link-local scope, which in this case is the LL-local scope. Transient Neighbors are outside the scope of the LL. No particular interaction is required between the mechanism for establishing shortcuts and the mechanism for detection of duplicate link local addresses.
重複アドレス検出は、リンクローカルスコープ内でのみ必要です。この場合はLLローカルスコープです。 Transient NeighborはLLの範囲外です。ショートカットを確立するためのメカニズムと、重複するリンクローカルアドレスを検出するためのメカニズムとの間で、特別な相互作用は必要ありません。
4 Node Operation Concepts.
4ノード操作の概念。
This section describes node operations for performing basic functions (such as sending and receiving data) on a Logical Link. The application of these basic functions to the operation of the various IPv6 protocols such as Neighbor Discovery is described in Appendix A.
このセクションでは、論理リンク上で基本的な機能（データの送受信など）を実行するためのノード操作について説明します。ネイバー探索などのさまざまなIPv6プロトコルの操作へのこれらの基本機能の適用については、付録Aで説明しています。
The majority of this section applies only to NBMA networks when used to provide point to point and point to multipoint SVCs. Section 7 discusses the case where the NBMA network is being used to supply only point to point PVCs.
このセクションの大部分は、ポイントツーポイントおよびポイントツーマルチポイントSVCを提供するために使用される場合、NBMAネットワークにのみ適用されます。セクション7では、NBMAネットワークを使用してポイントツーポイントPVCのみを供給する場合について説明します。
4.1.Connecting to a Logical Link.
4.1。論理リンクへの接続。
Before a node can send or receive IPv6 datagrams its underlying IPv6/NBMA interface(s) must first join a Logical Link.
ノードがIPv6データグラムを送受信できるようになる前に、その基礎となるIPv6 / NBMAインターフェースが最初に論理リンクに参加する必要があります。
An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS associated with its Logical Link, and register as a Cluster Member [5]. The node's IPv6/NBMA interface will then be a member of the LL, have a Cluster Member ID (CMI) assigned, and can begin supporting IPv6 and IPv6 ND operations.
IPv6 / NBMAドライバーは、その論理リンクに関連付けられたMARSへのpt-pt VCを確立し、クラスターメンバーとして登録する必要があります[5]。ノードのIPv6 / NBMAインターフェイスはLLのメンバーになり、クラスターメンバーID（CMI）が割り当てられ、IPv6およびIPv6 ND操作のサポートを開始できます。
If the node is a host or router starting up it SHALL issue a single group MARS_JOIN for the following groups:
ノードが起動中のホストまたはルーターである場合、次のグループに対して単一のグループMARS_JOINを発行する必要があります。
- Its derived Solicited-node address(es) with link-local scope. - The All-nodes address with link-local scope. - Other configured multicast groups with at least link-local scope.
- リンクローカルスコープを持つその導出要請ノードアドレス。 -リンクローカルスコープの全ノードアドレス。 -少なくともリンクローカルスコープを持つ他の構成済みマルチキャストグループ。
If the node is a router it SHALL additionally issue:
ノードがルーターの場合、さらに発行する必要があります：
- A single group MARS_JOIN for the All-routers address with link-local scope. - A block MARS_JOIN for the range(s) of IPv6 multicast addresses (with greater than link-local scope) for which promiscuous reception is required.
- リンクローカルスコープのAll-routerアドレスの単一グループMARS_JOIN。 -無差別受信が必要なIPv6マルチキャストアドレスの範囲（リンクローカルスコープを超える）のブロックMARS_JOIN。
The encapsulation mechanism for, and key field values of, MARS control messages SHALL be defined in companion documents specific to particular NBMA network technologies.
MARS制御メッセージのカプセル化メカニズムとキーフィールド値は、特定のNBMAネットワークテクノロジーに固有の関連ドキュメントで定義する必要があります。
4.2 Joining a Multicast Group.
4.2 マルチキャストグループへの参加。
This section describes the node's behavior when it gets a JoinLocalGroup request from the IPv6 Layer. The details of how this behavior is achieved are going to be implementation specific.
このセクションでは、IPv6レイヤーからJoinLocalGroupリクエストを受け取ったときのノードの動作について説明します。この動作を実現する方法の詳細は、実装によって異なります。
If a JoinLocalGroup for a node-local address is received, the IPv6/NBMA driver SHALL return success indication to the caller and take no additional action. (Packets sent to node-local addresses never reach the IPv6/NBMA driver.)
ノードローカルアドレスのJoinLocalGroupを受信した場合、IPv6 / NBMAドライバーは呼び出し元に成功の表示を返し、追加のアクションを実行しないものとします（SHALL）。 （ノードローカルアドレスに送信されたパケットは、IPv6 / NBMAドライバーに到達しません。）
If a JoinLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver SHALL send an appropriate single group MARS_JOIN request to register this address with the MARS.
ノードローカルスコープを超えるアドレスのJoinLocalGroupを受信した場合、IPv6 / NBMAドライバーは、このアドレスをMARSに登録するために適切な単一グループMARS_JOIN要求を送信する必要があります（SHALL）。
4.3. Leaving a Multicast Group.
4.3. マルチキャストグループを離れます。
This section describes the node's behavior when it gets a LeaveLocalGroup request from the IPv6 Layer. The details of how this behavior is achieved are going to be implementation specific.
このセクションでは、ノードがIPv6レイヤーからLeaveLocalGroupリクエストを受け取ったときのノードの動作について説明します。この動作を実現する方法の詳細は、実装によって異なります。
If a LeaveLocalGroup for a node-local address is received, the IPv6/NBMA driver SHALL return success indication to the caller and take no additional action. (Packets sent to node-local addresses never reach the IPv6/NBMA driver.)
ノードローカルアドレスのLeaveLocalGroupを受信した場合、IPv6 / NBMAドライバーは呼び出し元に成功の表示を返し、追加のアクションを実行しないものとします（SHALL）。 （ノードローカルアドレスに送信されたパケットは、IPv6 / NBMAドライバーに到達しません。）
If a LeaveLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver SHALL send an appropriate single group MARS_LEAVE request to deregister this address with the MARS.
ノードローカルスコープよりも大きいアドレスのLeaveLocalGroupを受信した場合、IPv6 / NBMAドライバーは、適切な単一グループMARS_LEAVE要求を送信して、このアドレスをMARSから登録解除する必要があります（SHALL）。
4.4. Sending Data.
4.4. データの送信。
Separate processing and encapsulation rules apply for outbound unicast and multicast packets.
アウトバウンドのユニキャストパケットとマルチキャストパケットには、個別の処理とカプセル化のルールが適用されます。
4.4.1. Sending Unicast Data.
4.4.1. ユニキャストデータの送信。
The IP level 'next hop' for each outbound unicast IPv6 packet is used to identify a pt-pt VC on which to forward the packet.
各発信ユニキャストIPv6パケットのIPレベル「ネクストホップ」は、パケットを転送するpt-pt VCを識別するために使用されます。
For NBMA networks where LLC/SNAP encapsulation is typically used (e.g. ATM or SMDS), the IPv6 packet SHALL be encapsulated with the following LLC/SNAP header and sent over the VC.
LLC / SNAPカプセル化が通常使用されるNBMAネットワーク（ATMまたはSMDSなど）の場合、IPv6パケットは次のLLC / SNAPヘッダーでカプセル化され、VC経由で送信される必要があります（SHALL）。
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] (LLC) (OUI) (PID)
[0xAA-AA-03] [0x00-00-00] [0x86-DD] [IPv6パケット]（LLC）（OUI）（PID）
For NBMA networks that do not use LLC/SNAP encapsulation, an alternative rule SHALL be specified in the NBMA-specific companion document.
LLC / SNAPカプセル化を使用しないNBMAネットワークの場合、NBMA固有の関連ドキュメントで代替ルールを指定する必要があります（SHALL）。
If no pt-pt VC exists for the next hop address for the packet, the node SHALL place a call to set up a VC to the next hop destination. Any time the IPv6/NBMA driver receives a unicast packet for transmission the IPv6 layer will already have determined the link-layer (NBMA) address of the next hop. Thus, the information needed to place the NBMA call to the next hop will be available.
パケットのネクストホップアドレスにpt-pt VCが存在しない場合、ノードは、ネクストホップの宛先へのVCを設定するためにコールを発信する必要があります。 IPv6 / NBMAドライバーが送信用のユニキャストパケットを受信するときは常に、IPv6レイヤーは次のホップのリンクレイヤー（NBMA）アドレスを既に決定しています。したがって、NBMAコールをネクストホップに発信するために必要な情報が利用可能になります。
The sending node SHOULD queue the packet that triggered the call request, and send it when the call is established.
送信ノードは、呼び出し要求をトリガーしたパケットをキューに入れ、呼び出しが確立されたときに送信する必要があります（SHOULD）。
If the call to the next hop destination node fails the sending node SHALL discard the packet that triggered the call setup. Persistent failure to create a VC to the next hop destination will be detected and handled at the IPv6 Network Layer through NUD.
ネクストホップの宛先ノードへのコールが失敗した場合、送信ノードは、コールセットアップをトリガーしたパケットを破棄する必要があります。ネクストホップ宛先へのVCを作成する永続的な障害は、NUDを介してIPv6ネットワークレイヤーで検出および処理されます。
At this time no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address.
現時点では、パケットの宛先アドレス以外のものを使用して、発信パケットをVCにマッピングするためのルールは指定されていません。
4.4.2. Sending Multicast Data.
4.4.2. マルチキャストデータの送信。
The IP level 'next hop' for each outbound multicast IPv6 packet is used to identify a pt-pt or pt-mpt VC on which to forward the packet.
各アウトバウンドマルチキャストIPv6パケットのIPレベル「ネクストホップ」は、パケットを転送するpt-ptまたはpt-mpt VCを識別するために使用されます。
For NBMA networks where LLC/SNAP encapsulation is typically used (e.g. ATM or SMDS), multicast packets SHALL be encapsulated in the following manner:
LLC / SNAPカプセル化が通常使用されるNBMAネットワーク（ATMまたはSMDSなど）では、マルチキャストパケットは次の方法でカプセル化される必要があります。
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet] (LLC) (OUI) (PID) (mars encaps)
[0xAA-AA-03] [0x00-00-5E] [0x00-01] [pkt $ cmi] [0x86DD] [IPv6パケット]（LLC）（OUI）（PID）（mars encaps）
The IPv6/NBMA driver's Cluster Member ID SHALL be copied into the 2 octet pkt$cmi field prior to transmission.
IPv6 / NBMAドライバーのクラスターメンバーIDは、送信前に2オクテットのpkt $ cmiフィールドにコピーする必要があります。
For NBMA networks that do not use LLC/SNAP encapsulation, an alternative rule SHALL be specified in the NBMA-specific companion document. Some mechanism for carrying the IPv6/NBMA driver's Cluster Member ID SHALL be provided.
LLC / SNAPカプセル化を使用しないNBMAネットワークの場合、NBMA固有の関連ドキュメントで代替ルールを指定する必要があります（SHALL）。 IPv6 / NBMAドライバーのクラスターメンバーIDを伝達するためのメカニズムを提供する必要があります。
If the packet's destination is one of the following multicast addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-pt VC to the MARS:
パケットの宛先が次のマルチキャストアドレスのいずれかである場合、IPv6 / NBMAドライバーの直接pt-pt VCを介してMARSに送信する必要があります。
- A Solicited-node address with link-local scope. - The All-nodes address with link-local scope. - The All-routers address with link-local scope. - A DHCP-v6 relay or server multicast address.
- リンクローカルスコープを持つ要請ノードアドレス。 -リンクローカルスコープの全ノードアドレス。 -リンクローカルスコープの全ルーターアドレス。 -DHCP-v6リレーまたはサーバーマルチキャストアドレス。
The MARS SHALL then redistribute the IPv6 packet as described in section 3.1.1. (If the VC to the MARS has been idle timed out for some reason, it MUST be re-established before forwarding the packet to the MARS.)
次に、MARSは、セクション3.1.1で説明されているようにIPv6パケットを再配布する必要があります。 （MARSへのVCが何らかの理由でアイドルタイムアウトになった場合は、パケットをMARSに転送する前に再確立する必要があります。）
If packet's destination is any other address, then the usual MARS client mechanisms are used by the IPv6/NBMA driver to select and/or establish a pt-mpt VC on which the packet is to be sent.
パケットの宛先がその他のアドレスの場合、通常のMARSクライアントメカニズムがIPv6 / NBMAドライバーによって使用され、パケットが送信されるpt-mpt VCを選択または確立します。
At this time no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address.
現時点では、パケットの宛先アドレス以外のものを使用して、発信パケットをVCにマッピングするためのルールは指定されていません。
4.5. Receiving Data.
4.5. データ受信中。
Packets received using the encapsulation shown in section 4.4.1 SHALL be de-encapsulated and passed up to the IPv6 layer. The IPv6 layer then determines how the incoming packet is to be handled.
セクション4.4.1に示されているカプセル化を使用して受信されたパケットは、カプセル化が解除され、IPv6レイヤーに渡される必要があります。次に、IPv6レイヤーは、着信パケットの処理方法を決定します。
Packets received using the encapsulation specified in section 4.4.2 SHALL have their pkt$cmi field compared to the local IPv6/NBMA driver's own CMI. If the pkt$cmi in the header matches the local CMI the packet SHALL be silently dropped. Otherwise, the packet SHALL be de-encapsulated and passed to the IPv6 layer. The IPv6 layer then determines how the incoming packet is to be handled.
セクション4.4.2で指定されたカプセル化を使用して受信されたパケットは、ローカルIPv6 / NBMAドライバー自体のCMIと比較して、pkt $ cmiフィールドを持っている必要があります（SHALL）。ヘッダーのpkt $ cmiがローカルCMIと一致する場合、パケットは黙って破棄される必要があります（SHALL）。それ以外の場合、パケットはカプセル化を解除され、IPv6層に渡される必要があります（SHALL）。次に、IPv6レイヤーは、着信パケットの処理方法を決定します。
For NBMA networks that do not use LLC/SNAP encapsulation, alternative rules SHALL be specified in the NBMA-specific companion document.
LLC / SNAPカプセル化を使用しないNBMAネットワークの場合、NBMA固有の関連ドキュメントで代替ルールを指定する必要があります（SHALL）。
The IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv6 packets arriving with encapsulation defined for unicast packets, nor attempt to filter out unicast IPv6 packets arriving with encapsulation defined for multicast packets.
IPv6 / NBMAドライバーは、ユニキャストパケットに対して定義されたカプセル化を使用して到着するマルチキャストIPv6パケットをフィルターで除外しようと試みたり、マルチキャストパケットに対して定義されたカプセル化を使用して到着するユニキャストIPv6パケットをフィルターで除外しようと試みたりしてはなりません。
4.6. VC Setup and release for unicast data.
4.6. ユニキャストデータのVCセットアップとリリース。
Unicast VCs are maintained separately from multicast VCs. The setup and maintenance of multicast VCs are handled by the MARS client in each IPv6/NBMA driver [5]. Only the setup and maintenance of pt-pt VCs for unicast IPv6 traffic will be described here. Only best effort unicast VCs are considered. The creation of VCs for other classes of service is outside the scope of this document.
ユニキャストVCは、マルチキャストVCとは別に維持されます。マルチキャストVCのセットアップとメンテナンスは、各IPv6 / NBMAドライバーのMARSクライアントによって処理されます[5]。ここでは、ユニキャストIPv6トラフィック用のpt-pt VCのセットアップとメンテナンスについてのみ説明します。ベストエフォートのユニキャストVCのみが考慮されます。他のサービスクラスのVCの作成は、このドキュメントの範囲外です。
Before sending a packet to a new destination within the same LL a node will first perform a Neighbor Discovery on the intra-LL target. This is done to resolve the IPv6 destination address into a link-layer address which the sender can then use to send unicast packets.
パケットを同じLL内の新しい宛先に送信する前に、ノードは最初にLL内ターゲットで近隣探索を実行します。これは、IPv6宛先アドレスをリンク層アドレスに解決して、送信者がユニキャストパケットの送信に使用できるようにするために行われます。
Appendix A.1.1 contains non-normative, descriptive text covering the Neighbor Solicitation/Advertisement exchange and eventual establishment of a new SVC.
付録A.1.1には、近隣要請/広告交換および最終的な新しいSVCの確立をカバーする非規範的で説明的なテキストが含まれています。
A Redirect message (either a redirect to a node on the same LL, or a shortcut redirect to a node outside the LL) results in the sending (redirected) node creating a new pt-pt VC to a new receiving node. the Redirect message SHALL contain the link layer (NBMA) address of the new receiving IPv6/NBMA interface. The redirected node does not concern itself where the new receiving node is located on the NBMA network. The redirected node will set up a pt-pt VC to the new node if one does not previously exist. The redirected node will then use the new VC to send data rather than whatever VC it had previously been using.
リダイレクトメッセージ（同じLL上のノードへのリダイレクト、またはLL外のノードへのショートカットリダイレクト）の結果、送信（リダイレクト）ノードは新しいpt-pt VCを新しい受信ノードに作成します。リダイレクトメッセージには、新しい受信IPv6 / NBMAインターフェイスのリンク層（NBMA）アドレスが含まれている必要があります（SHALL）。リダイレクトされたノードは、新しい受信ノードがNBMAネットワーク上のどこにあるかには関係ありません。リダイレクトされたノードが存在しない場合、新しいノードにpt-pt VCを設定します。リダイレクトされたノードは、以前使用していたVCではなく、新しいVCを使用してデータを送信します。
Redirects are unidirectional. Even after the source has reacted to a redirect, the destination will continue to send IPv6 packets back to the redirected node on the old path. This happens because the destination node has no way of determining the IPv6 address of the other end of a new VC in the absence of Neighbor Discovery. Thus, redirects will not result in both ends of a connection using the new VC. IPv6 redirects are not intended to provide symmetrical redirection. If the non-redirected node eventually receives a redirect it MAY discover the existing VC to the target node and use that rather than creating a new VC.
リダイレクトは単方向です。ソースがリダイレクトに反応した後でも、宛先は引き続きIPv6パケットを古いパス上のリダイレクトされたノードに送り返します。これは、近隣探索がない場合、宛先ノードが新しいVCのもう一方の端のIPv6アドレスを決定する方法がないために発生します。したがって、リダイレクトによって新しいVCを使用する接続の両端が発生することはありません。 IPv6リダイレクトは、対称的なリダイレクトを提供するためのものではありません。リダイレクトされていないノードが最終的にリダイレクトを受信した場合、ターゲットノードへの既存のVCを検出して、新しいVCを作成するのではなく、それを使用する場合があります。
It is desirable that VCs are released when no longer needed.
VCは、不要になったときに解放されることが望ましいです。
An IPv6/NBMA driver SHALL release any VC that has been idle for 20 minutes.
IPv6 / NBMAドライバーは、20分間アイドル状態であったVCを解放する必要があります（SHALL）。
This time limit MAY be reduced through configuration or as specified in companion documents for specific NBMA networks.
この時間制限は、構成を介して、または特定のNBMAネットワークの関連ドキュメントで指定されているように短縮される場合があります。
If a Neighbor or Destination cache entry is purged then any VCs associated with the purged entry SHOULD be released.
ネイバーまたは宛先キャッシュエントリがパージされた場合、パージされたエントリに関連付けられているすべてのVCを解放する必要があります（SHOULD）。
If the state of an entry in the Neighbor cache is set to STALE, then any VCs associated with the stale entry SHOULD be released.
ネイバーキャッシュ内のエントリの状態がSTALEに設定されている場合、古いエントリに関連付けられているすべてのVCを解放する必要があります（SHOULD）。
4.7 NBMA SVC Signaling Support and MTU issues.
4.7 NBMA SVCシグナリングサポートとMTUの問題。
Mechanisms for signaling the establishment and teardown of pt-pt and pt-mpt SVCs for different NBMA networks SHALL be specified in companion documents.
異なるNBMAネットワーク用のpt-ptおよびpt-mpt SVCの確立と破棄を通知するメカニズムは、関連ドキュメントで指定する必要があります。
Since any given IPv6/NBMA driver will not know if the remote end of a VC is in the same LL, drivers SHALL implement NBMA-specific mechanisms to negotiate acceptable MTUs at the VC level. These mechanisms SHALL be specified in companion documents.
特定のIPv6 / NBMAドライバーは、VCのリモートエンドが同じLLにあるかどうかを認識できないため、ドライバーはVCレベルで受け入れ可能なMTUをネゴシエートするNBMA固有のメカニズムを実装する必要があります（SHALL）。これらのメカニズムは、関連ドキュメントで指定する必要があります（SHALL）。
However, IPv6/NBMA drivers can assume that they will always be talking to another driver attached to the same type of NBMA network. (For example, an IPv6/NBMA driver does not need to consider the possibility of establishing a shortcut VC directly to an IPv6/FR driver.)
ただし、IPv6 / NBMAドライバーは、同じタイプのNBMAネットワークに接続されている別のドライバーと常に通信していると想定できます。 （たとえば、IPv6 / NBMAドライバーは、IPv6 / FRドライバーへのショートカットVCを直接確立する可能性を考慮する必要はありません。）
Each IPv6 interface must have an interface token from which to form IPv6 autoconfigured addresses. This interface token must be unique within a Logical Link to prevent the creation of duplicate addresses when stateless address configuration is used.
各IPv6インターフェースには、IPv6自動構成アドレスを形成するためのインターフェーストークンが必要です。このインターフェイストークンは、ステートレスアドレス構成が使用されているときに重複アドレスが作成されないように、論理リンク内で一意である必要があります。
In cases where two nodes on the same LL produce the same interface token then one interface MUST choose another host-token. All implementations MUST support manual configuration of interface tokens to allow operators to manually change a interface token on a per-LL basis. Operators may choose to manually set interface tokens for reasons other than eliminating duplicate addresses.
同じLL上の2つのノードが同じインターフェイストークンを生成する場合、1つのインターフェイスが別のホストトークンを選択する必要があります。すべての実装は、オペレーターが手動でLLごとにインターフェーストークンを変更できるように、インターフェーストークンの手動構成をサポートする必要があります。オペレーターは、重複アドレスを排除する以外の理由で、インターフェーストークンを手動で設定することを選択できます。
All interface tokens MUST be 64 bits in length and formatted as described in the following sections. The hosts tokens will be based on the format of an EUI-64 identifier [10]. Refer to [19 - Appendix A] for a description of creating IPv6 EUI-64 based interface identifiers.
すべてのインターフェイストークンの長さは64ビットで、次のセクションで説明するようにフォーマットする必要があります。ホストトークンは、EUI-64識別子[10]の形式に基づいています。 IPv6 EUI-64ベースのインターフェース識別子の作成については、[19-付録A]を参照してください。
Physical NBMA interfaces will generally have some local identifier that may be used to generate a unique IPv6/NBMA interface token. The exact mechanism for generating interface tokens SHALL be specified in companion documents specific to each NBMA network.
物理NBMAインターフェースには通常、固有のIPv6 / NBMAインターフェーストークンを生成するために使用できるローカル識別子があります。インターフェイストークンを生成するための正確なメカニズムは、各NBMAネットワークに固有の関連ドキュメントで指定する必要があります。
Physical NBMA interfaces MAY be used to provide multiple logical NBMA interfaces. Since each logical NBMA interface MAY support an independent IPv6 interface, two separate scenarios are possible:
物理NBMAインターフェイスは、複数の論理NBMAインターフェイスを提供するために使用される場合があります。各論理NBMAインターフェースは独立したIPv6インターフェースをサポートする可能性があるため（MAY）、2つの別々のシナリオが可能です。
- A single host with separate IPv6/NBMA interfaces onto a number of independent Logical Links.
- 複数の独立した論理リンクへの個別のIPv6 / NBMAインターフェイスを持つ単一のホスト。
- A set of 2 or more 'virtual hosts' (vhosts) sharing a common NBMA driver. Each vhost is free to establish IPv6/NBMA interfaces associated with different or common LLs. However, vhosts are bound by the same requirement as normal hosts - no two interfaces to the same LL can share the same interface token.
- 共通のNBMAドライバーを共有する2つ以上の「仮想ホスト」（vhosts）のセット。各仮想ホストは、異なるまたは一般的なLLに関連付けられたIPv6 / NBMAインターフェイスを自由に確立できます。ただし、vhostsは通常のホストと同じ要件によってバインドされます。同じLLへの2つのインターフェースが同じインターフェーストークンを共有することはできません。
In the first scenario, since each IPv6/NBMA interface is associated with a different LL, each interface's external identity can be differentiated by the LL's routing prefix. Thus, the host can re-use a single unique interface token across all its IPv6/NBMA interfaces. (Internally the host will tag received packets in some locally specific manner to identify what IPv6/NBMA interface they arrived on. However, this is an issue generic to IPv6, and does not required clarification in this document.)
最初のシナリオでは、各IPv6 / NBMAインターフェイスが異なるLLに関連付けられているため、各インターフェイスの外部IDは、LLのルーティングプレフィックスによって区別できます。したがって、ホストは、そのすべてのIPv6 / NBMAインターフェイスで単一の一意のインターフェイストークンを再利用できます。 （内部的にホストは受信したパケットにローカル固有の方法でタグを付けて、到着したIPv6 / NBMAインターフェイスを識別します。ただし、これはIPv6に一般的な問題であり、このドキュメントでの説明は不要です。）
The second scenario is more complex, but likely to be rarer.
2番目のシナリオはより複雑ですが、まれになる可能性があります。
When supporting multiple logical NBMA interfaces over a single physical NBMA interface, independent and unique identifiers SHALL be generated for each virtual NBMA interface to enable the construction of unique IPv6/NBMA interface tokens. The exact mechanism for generating interface tokens SHALL be specified in companion documents specific to each NBMA network.
単一の物理NBMAインターフェースで複数の論理NBMAインターフェースをサポートする場合、各仮想NBMAインターフェースに対して独立した一意の識別子を生成して、一意のIPv6 / NBMAインターフェーストークンを構築できるようにする必要があります。インターフェイストークンを生成するための正確なメカニズムは、各NBMAネットワークに固有の関連ドキュメントで指定する必要があります。
Neighbor Discovery defines two option fields for carrying link-layer specific source and target addresses.
近隣探索では、リンク層固有のソースアドレスとターゲットアドレスを伝送するための2つのオプションフィールドを定義します。
Between IPv6/NBMA interfaces, the format for these two options is adapted from the MARS [5] and NHRP [8] specs. It SHALL be:
IPv6 / NBMAインターフェイス間では、これら2つのオプションの形式は、MARS [5]およびNHRP [8]仕様から採用されています。それはする必要があります：
[Type][Length][NTL][STL][..NBMA Number..][..NBMA Subaddress..] | Fixed || Link layer address |
[タイプ] [長さ] [NTL] [STL] [.. NBMA番号..] [.. NBMAサブアドレス..] |修正済み||リンク層アドレス|
[Type] is a one octet field.
[タイプ]は1オクテットのフィールドです。
1 for Source link-layer address. 2 for Target link-layer address.
ソースリンク層アドレスの場合は1。ターゲットリンク層アドレスの場合は2。
[Length] is a one octet field.
[長さ]は1オクテットのフィールドです。
The total length of the option in multiples of 8 octets. Zeroed bytes are added to the end of the option to ensure its length is a multiple of 8 octets.
8オクテットの倍数で表したオプションの全長。長さが8オクテットの倍数になるように、ゼロ化されたバイトがオプションの最後に追加されます。
[NTL] is a one octet 'Number Type & Length' field.
[NTL]は1オクテットの「数値タイプと長さ」フィールドです。
[STL] is a one octet 'SubAddress Type & Length' field.
[STL]は、1オクテットの「SubAddress Type＆Length」フィールドです。
[NBMA Number] is a variable length field. It is always present. This contains the primary NBMA address.
[NBMA番号]は可変長フィールドです。それは常に存在しています。これには、プライマリNBMAアドレスが含まれています。
[NBMA Subaddress] is a variable length field. It may or may not be present. This contains any NBMA subaddress that may be required.
[NBMA Subaddress]は可変長フィールドです。存在する場合と存在しない場合があります。これには、必要になる可能性があるNBMAサブアドレスが含まれます。
If the [NBMA Subaddress] is not present, the option ends after the [NBMA Number] ( and any additional padding for 8 byte alignment).
[NBMAサブアドレス]が存在しない場合、オプションは[NBMA番号]（および8バイトアライメント用の追加のパディング）の後に終了します。
The contents and interpretation of the [NTL], [STL], [NBMA Number], and [NBMA Subaddress] fields are specific to each NBMA network, and SHALL be specified in companion documents.
[NTL]、[STL]、[NBMA番号]、および[NBMAサブアドレス]フィールドの内容と解釈は、各NBMAネットワークに固有であり、関連ドキュメントで指定する必要があります。
The IPv6 link-local address is formed by appending the interface token, as defined above, to the prefix FE80::/64.
IPv6リンクローカルアドレスは、上で定義したように、インターフェイストークンをプレフィックスFE80 :: / 64に追加することによって形成されます。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Token |
+----------+-----------------------+----------------------------+
This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that provide details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths (when dynamically signaled NBMA links are available).
このドキュメントでは、NBMAネットワーク上のIPv6の一般的なアーキテクチャについて説明します。これは、さまざまな特定のNBMAテクノロジ（ATMやフレームリレーなど）の詳細を提供する補助的な関連ドキュメントの基礎を形成します。 IPv6 over NBMAアーキテクチャーは、IPv6近隣探索プロトコルの従来のホスト側の操作を可能にすると同時に、「ショートカット」NBMA転送パスの確立をサポートします（動的にシグナリングされるNBMAリンクが利用可能な場合）。
The IPv6 "Link" is generalized to "Logical Link" in an analagous manner to the IPv4 "Logical IP Subnet". The MARS protocol is augmented and used to provide relatively efficient intra Logical Link multicasting of IPv6 packets, and distribution of Discovery messages. Shortcut NBMA level paths are supported either through router based flow detection, or host originated explicit requests. Neighbor Discovery is used without modification for all intra-LL control (including the initiation of NBMA shortcut discovery). Router to router NHRP is used to obtain the IPv6/NBMA address mappings for shortcut targets outside a source's Logical Link.
IPv6の「リンク」は、IPv4の「論理IPサブネット」と同様に「論理リンク」に一般化されています。 MARSプロトコルは拡張され、IPv6パケットの比較的効率的なイントラ論理リンクマルチキャスト、およびディスカバリメッセージの配信を提供するために使用されます。ショートカットNBMAレベルのパスは、ルーターベースのフロー検出、またはホストからの明示的な要求によってサポートされます。ネイバー探索は、すべてのLL制御（NBMAショートカット探索の開始を含む）に対して変更なしで使用されます。ルーター間NHRPは、ソースの論理リンク外のショートカットターゲットのIPv6 / NBMAアドレスマッピングを取得するために使用されます。
This architecture introduces no new protocols, but depends on existing protocols (NHRP, IPv6, ND, MARS) and is therefore subject to all the security threats inherent in these protocols. This architecture should not be used in a domain where any of the base protocols are considered unacceptably insecure. However, this protocol itself does not introduce additional security threats.
このアーキテクチャは新しいプロトコルを導入していませんが、既存のプロトコル（NHRP、IPv6、ND、MARS）に依存しているため、これらのプロトコルに固有のすべてのセキュリティ脅威の影響を受けます。このアーキテクチャは、基本プロトコルのいずれかが許容できないほど安全でないと見なされているドメインでは使用しないでください。ただし、このプロトコル自体は追加のセキュリティ脅威をもたらしません。
While this proposal does not introduce any new security mechanisms all current IPv6 security mechanisms will work without modification for NBMA. This includes both authentication and encryption for both Neighbor Discovery protocols as well as the exchange of IPv6 data packets. The MARS protocol is modified in a manner that does not affect or augment the security offered by RFC 2022.
この提案では新しいセキュリティメカニズムは導入されていませんが、現在のIPv6セキュリティメカニズムはすべて、NBMAを変更しなくても機能します。これには、両方の近隣探索プロトコルの認証と暗号化、およびIPv6データパケットの交換が含まれます。 MARSプロトコルは、RFC 2022によって提供されるセキュリティに影響を与えたり、セキュリティを強化したりしない方法で変更されます。
Acknowledgments
謝辞
Eric Nordmark confirmed the usefulness of ND Redirect messages in private email during the March 1996 IETF. The discussions with various ION WG members during the June and December 1996 IETF helped solidify the architecture described here. Grenville Armitage's original work on IPv6/NBMA occurred while employed at Bellcore. Elements of section 5 were borrowed from Matt Crawford's memo on IPv6 over Ethernet.
Eric Nordmarkは、1996年3月のIETF中に、プライベートメールでのND Redirectメッセージの有用性を確認しました。 1996年6月および12月のIETFでのさまざまなION WGメンバーとの議論は、ここで説明されているアーキテクチャを強化するのに役立ちました。グレンビルアーミテージのIPv6 / NBMAに関する最初の研究は、ベルコアでの勤務中に行われました。セクション5の要素は、Matt CrawfordのIPv6 over Ethernetに関するメモから借用したものです。
Authors' Addresses
著者のアドレス
Grenville Armitage Bell Laboratories, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA
Grenville Armitage Bell Laboratories、Lucent Technologies 101 Crawfords Corner Road Holmdel、NJ 07733 USA
EMail: gja@lucent.com
Peter Schulter Bright Tiger Technologies 125 Nagog Park Acton, MA 01720
Peter Schulter Bright Tiger Technologies 125 Nagga Park Octane、Ma 017
EMail: paschulter@acm.org
Markus Jork European Applied Research Center Digital Equipment GmbH CEC Karlsruhe Vincenz-Priessnitz-Str. 1 D-76131 Karlsruhe Germany
Markus Jork欧州応用研究センターDigital Equipment GmbH CECカールスルーエヴィンセンツプリエスニッツStr。 1 D-76131カールスルーエドイツ
EMail: jork@kar.dec.com
Geraldine Harter Digital UNIX Networking Compaq Computer Corporation 110 Spit Brook Road Nashua, NH 03062
Geraldine Harter Digital UNIX Networking Compaq Computer Corporation 110 Spit Brook Road Nashua、NH 03062
EMail: harter@zk3.dec.com
References
参考文献
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[1] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[2] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995.
[2] ATMフォーラム、「ATM User Network Interface（UNI）Specification Version 3.1」、ISBN 0-13-393828-X、Prentice Hall、Englewood Cliffs、NJ、1995年6月。
[3] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996.
[3] クロフォードM.、「イーサネットネットワーク上でのIPv6パケットの送信方法」、RFC 1972、1996年8月。
[4] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[4] Heinanen、J。、「ATMアダプテーションレイヤー5上のマルチプロトコルカプセル化」、RFC 1483、1993年7月。
[5] Armitage, G., "Support for Multicast over UNI 3.1 based ATM Networks", RFC 2022, November 1996.
[5] アーミテージ、G。、「UNI 3.1ベースのATMネットワーク上のマルチキャストのサポート」、RFC 2022、1996年11月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[6] Hinden、R. and S. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Narten、T.、Nordmark、E。およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[8] Luciani, J., Katz, D., Piscitello, D. Cole B and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[8] Luciani、J.、Katz、D.、Piscitello、D。Cole BおよびN. Doraswamy、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[9] Thomson、S.およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[10] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[10] 「64ビットグローバル識別子形式のチュートリアル」、http：//standards.ieee.org/db/oui/tutorials/EUI64.html。
[11] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's Router Architecture Extensions for ATM : Overview", RFC 2098, February 1997.
[11] 勝部順夫、永見和也、江崎博、「東芝のATM向けルーターアーキテクチャ拡張：概要」、RFC 2098、1997年2月。
[12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under IP", Proceedings of INFOCOM'96, San Francisco, March 1996, pp.1251-1260
[12] P.ニューマン、T。リヨン、G。ミンシャル、「Flow Labeled IP：ATM under IP」、Proceedings of INFOCOM'96、サンフランシスコ、1996年3月、pp.1251-1260
[13] Piscitello, D. and J. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, March 1991.
[13] Piscitello、D。およびJ. Lawrence、「The Transmission of IP Datagrams over the SMDS Service」、RFC 1209、1991年3月。
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[14] Plummer、D.、「イーサネットアドレス解決プロトコル-または-ネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[15] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[15] マッキャンJ.、ディアリングS.、J。モーグル、「IPバージョン6のパスMTUディスカバリー」、RFC 1981、1996年8月。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[16] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[17] アーミテージ、G。、シュルター、P。およびM.ジョーク、「ATMネットワーク上のIPv6」、RFC 2492、1999年1月。
[18] C. Perkins, J. Bound, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress.
[18] C.パーキンス、J。バウンド、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、作業中。
[19] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[19] Hinden、R. and S. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
The IPv6 over NBMA model described in this document maintains the complete semantics of the IPv6 protocols. No changes need to be made to the IPv6 Network Layer. Since the concept of the security association is not being changed for NBMA, this framework maintains complete IPv6 security semantics and features. This allows IPv6 nodes to choose their responses to solicitations based on security information as is done with other datalinks, thereby maintaining the semantics of Neighbor Discovery since it is always the solicited node that chooses what (and even if) to reply to the solicitation. Thus, NBMA will be transparent to the network layer except in cases where extra services (such as QoS VCs) are offered.
このドキュメントで説明されているIPv6 over NBMAモデルは、IPv6プロトコルの完全なセマンティクスを維持します。 IPv6ネットワーク層に変更を加える必要はありません。セキュリティアソシエーションの概念はNBMAで変更されていないため、このフレームワークは完全なIPv6セキュリティセマンティクスと機能を維持します。これにより、IPv6ノードは、他のデータリンクで行われるのと同じように、セキュリティ情報に基づいて要請に対する応答を選択できます。これにより、要請に応答する対象を（場合によっても）選択するのは常に要請ノードであるため、近隣探索のセマンティクスが維持されます。したがって、追加のサービス（QoS VCなど）が提供される場合を除いて、NBMAはネットワーク層に対して透過的です。
The remainder of this Appendix describes how the core IPv6 protocols will operate within the model described here.
この付録の残りの部分では、ここで説明するモデル内でコアIPv6プロトコルがどのように動作するかについて説明します。
Before performing any sort of Neighbor discover operation, each node must first join the all-node multicast group, and it's solicited node multicast address (the use of this address in relation to DAD is described in A.1.4). The IPv6 network layer will join these multicast groups as described in 4.2.
ネイバー探索操作を実行する前に、各ノードは最初に全ノードマルチキャストグループに参加する必要があり、要請ノードマルチキャストアドレスです（DADに関連したこのアドレスの使用については、A.1.4で説明しています）。 IPv6ネットワーク層は、4.2で説明されているように、これらのマルチキャストグループに参加します。
An IPv6 host performs address resolution by sending a Neighbor Solicitation to the solicited-node multicast address of the target host, as described in [7]. The Neighbor Solicitation message will contain a Source Link-Layer Address Option set to the soliciting node's NBMA address on the LL.
[7]で説明されているように、IPv6ホストは、近隣要請をターゲットホストの要請ノードマルチキャストアドレスに送信することにより、アドレス解決を実行します。近隣要請メッセージには、LL上の要請ノードのNBMAアドレスに設定されたソースリンク層アドレスオプションが含まれます。
When the local node's IPv6/NBMA driver is passed the Neighbor Solicitation message from the IPv6 network layer, it follows the steps described in section 4.4.2 Sending Multicast Data.
ローカルノードのIPv6 / NBMAドライバーにIPv6ネットワークレイヤーから近隣要請メッセージが渡されると、セクション4.4.2マルチキャストデータの送信で説明されている手順に従います。
One or more nodes will receive the Neighbor Solicitation message. The nodes will process the data as described in section 4.5 and pass the de-encapsulated packets to the IPv6 network layer.
1つ以上のノードが近隣要請メッセージを受信します。ノードは、セクション4.5で説明されているようにデータを処理し、カプセル化解除されたパケットをIPv6ネットワーク層に渡します。
If the receiving node is the target of the Neighbor Solicitation it will update its Neighbor cache with the soliciting node's NBMA address, contained in the Neighbor Solicitation message's Source Link-Layer Address Option as described in [7].
受信ノードが近隣要請のターゲットである場合、[7]で説明されているように、近隣要請メッセージの送信元リンク層アドレスオプションに含まれる要請ノードのNBMAアドレスで近隣キャッシュを更新します。
The solicited IPv6 host will respond to the Neighbor Solicitation with a Neighbor Advertisement message sent to the IPv6 unicast address of the soliciting node. The Neighbor Advertisement message will contain a Target Link-Layer Address Option set to the solicited node's NBMA address on the LL.
要請されたIPv6ホストは、要請ノードのIPv6ユニキャストアドレスに送信された近隣アドバタイズメッセージで近隣要請に応答します。ネイバーアドバタイズメッセージには、LL上の要請ノードのNBMAアドレスに設定されたターゲットリンクレイヤーアドレスオプションが含まれます。
The solicited node's IPv6/NBMA driver will be passed the Neighbor Advertisement and the soliciting node's link-layer address from the IPv6 network layer. It will then follow the steps described in section section 4.4.1 to send the NA message to the soliciting node. This will create a pt-pt VC between the solicited node and soliciting node if one did not already exist.
要請ノードのIPv6 / NBMAドライバーには、近隣アドバタイズと要請ノードのリンク層アドレスがIPv6ネットワーク層から渡されます。次に、セクション4.4.1で説明されている手順に従って、NAメッセージを送信請求ノードに送信します。これにより、要請ノードと要請ノードの間にpt-pt VCがまだ存在していなければ、作成されます。
The soliciting node will then receive the Neighbor Advertisement message over the new PtP VC, de-encapsulate the message, and pass it to the IPv6 Network layer for processing as described in section 4.5. The soliciting node will then make the appropriate entries in it's Neighbor cache, including caching the NBMA link-layer address of the solicited node as described in [7].
送信請求ノードは、新しいPtP VCを介して近隣アドバタイズメッセージを受信し、メッセージのカプセル化を解除して、セクション4.5で説明されているようにIPv6ネットワークレイヤーに渡して処理します。次に、要請ノードは、[7]で説明されているように、要請ノードのNBMAリンク層アドレスのキャッシュを含め、その近隣キャッシュに適切なエントリを作成します。
At this point each system has a complete Neighbor cache entry for the other system. They can exchange data over the pt-pt VC newly created by the solicited node when it returned the Neighbor Advertisement, or create a new VC.
この時点で、各システムには他のシステムの完全なネイバーキャッシュエントリがあります。要請されたノードがネイバーアドバタイズメントを返したときに新規に作成されたpt-pt VCを介してデータを交換したり、新しいVCを作成したりできます。
An IPv6 host can also send an Unsolicited Neighbor Advertisemnent to the all-nodes multicast address. When the local node IPv6/NBMA driver is passed the Neighbor Advertisement from the IPv6 network layer, it follows the steps described in section 4.4.2 to send the NA message to the all-nodes multicast address. Each node will process the incoming packet as described in section 4.5 and then pass the packet to the IPv6 network layer where it will be processed as described in [7].
IPv6ホストは、非送信請求ネイバーアドバタイズメントを全ノードマルチキャストアドレスに送信することもできます。ローカルノードのIPv6 / NBMAドライバーがIPv6ネットワーク層から近隣アドバタイズを渡されると、セクション4.4.2で説明されている手順に従って、NAメッセージを全ノードのマルチキャストアドレスに送信します。各ノードは、セクション4.5で説明されているように着信パケットを処理し、[7]で説明されているように処理されるIPv6ネットワーク層にパケットを渡します。
Router Discovery is described in [7]. To support Router Discovery an IPv6 router will join the IPv6 all-routers multicast group address. When the IPv6/NBMA driver gets the JoinLocalGroup request from the IPv6 Network Layer, it follows the process described in section 4.2.
ルーター発見は[7]で説明されています。ルーター検出をサポートするために、IPv6ルーターはIPv6全ルーターマルチキャストグループアドレスに参加します。 IPv6 / NBMAドライバーは、IPv6ネットワークレイヤーからJoinLocalGroup要求を取得すると、セクション4.2で説明されているプロセスに従います。
IPv6 routers periodically send unsolicited Router Advertisements announcing their availability on the LL. When an IPv6 router sends an unsolicited Router Advertisement, it sends a data packet addressed to the IPv6 all-nodes multicast address. When the local node IPv6/NBMA driver gets the Router Advertisement message from the IPv6 network layer, it transmits the message by following steps described in section 4.4.2. The MARS will transmit the packet on the LL's
IPv6ルーターは、要請されていないルーターアドバタイズメントを定期的に送信して、LLでの可用性を通知します。 IPv6ルーターが非送信請求ルーターアドバタイズを送信すると、IPv6全ノードマルチキャストアドレス宛てのデータパケットが送信されます。ローカルノードのIPv6 / NBMAドライバーは、IPv6ネットワークレイヤーからルーターアドバタイズメッセージを取得すると、セクション4.4.2で説明されている手順に従ってメッセージを送信します。 MARSはLLでパケットを送信します
ClusterControlVC, which sends the packets to all nodes on the LL. Each node on the LL will then process the incoming packet as described in section 4.5 and pass the received packet to the IPv6 Network layer for processing as appropriate.
ClusterControlVC。LL上のすべてのノードにパケットを送信します。 LLの各ノードは、セクション4.5で説明するように着信パケットを処理し、受信したパケットをIPv6ネットワーク層に渡して、適切に処理します。
To perform Router Discovery, an IPv6 host sends a Router Solicitation message to the all-routers multicast address. When the local node IPv6/NBMA driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps described in section 4.4.2. The RS message will be sent to either those nodes which have joined the all-routers multicast group or to all nodes. The nodes which receive the RA message will process the message as described in section 4.5 and pass the RA message up to the IPv6 layer for processing. Only those nodes which are routers will process the message and respond to it.
ルーター発見を実行するために、IPv6ホストはルーター要請メッセージを全ルーターマルチキャストアドレスに送信します。ローカルノードのIPv6 / NBMAドライバーは、IPv6ネットワークレイヤーからパケットを送信する要求を取得すると、セクション4.4.2で説明されている手順に従います。 RSメッセージは、全ルーターマルチキャストグループに参加したノードまたはすべてのノードに送信されます。 RAメッセージを受信するノードは、4.5節で説明されているようにメッセージを処理し、処理のためにRAメッセージをIPv6層に渡します。ルーターであるノードのみがメッセージを処理して応答します。
An IPv6 router responds to a Router Solicitation by sending a Router Advertisement addressed to the IPv6 all-nodes multicast address if the source address of the Router Solicitation was the unspecified address. If the source address in the Router Solicitation is not the unspecified address, the the router will unicast the Router Advertisement to the soliciting node. If the router sends the Router Advertisement to the all-nodes multicast address then it follows the steps described above for unsolicited Router Advertisements.
IPv6ルーターは、ルーター要請の送信元アドレスが指定されていないアドレスである場合、IPv6全ノードマルチキャストアドレスにアドレス指定されたルーターアドバタイズを送信することにより、ルーター要請に応答します。ルーター要請の送信元アドレスが指定されていないアドレスでない場合、ルーターはルーター通知を要請ノードにユニキャストします。ルーターがすべてのノードのマルチキャストアドレスにルーターアドバタイズを送信する場合、非送信請求ルーターアドバタイズについて上記の手順に従います。
If the Router Advertisement is to be unicast to the soliciting node, the IPv6 network layer will give the node's IPv6/NBMA driver the Router Advertisement and link-layer address of the soliciting node (obtained through Address Resolution if necessary) which will send the packet according to the steps described in section 4.4.1 This will result in a new pt-pt VC being created between the router and the soliciting node if one did not already exist.
ルーターアドバタイズを送信側ノードにユニキャストする場合、IPv6ネットワークレイヤーはノードのIPv6 / NBMAドライバーに、パケットを送信する送信側ノードのルーターアドバタイズとリンク層アドレス（必要に応じてアドレス解決を通じて取得）を提供します。セクション4.4.1で説明されている手順に従います。これにより、ルーターと要請ノードがまだ存在しない場合、ルーターと要請ノードの間に新しいpt-pt VCが作成されます。
The soliciting node will receive and process the Router Advertisement as described in section 4.5 and will pass the RA message to the IPv6 network layer. The IPv6 network layer may, depending on the state of the Neighbor cache entry, update the Neighbor cache with the router's NBMA address, contained in the Router Advertisement message's Source Link-Layer Address Option.
要請ノードは、セクション4.5で説明されているようにルーターアドバタイズを受信して処理し、RAメッセージをIPv6ネットワークレイヤーに渡します。 IPv6ネットワークレイヤーは、ネイバーキャッシュエントリの状態に応じて、ルーターアドバタイズメッセージのソースリンクレイヤーアドレスオプションに含まれているルーターのNBMAアドレスでネイバーキャッシュを更新します。
If a pt-pt VC is set up during Router Discovery, subsequent IPv6 best effort unicast data between the soliciting node and the router will be transmitted over the new PtP VC.
ルーター検出中にpt-pt VCが設定されている場合、送信請求ノードとルーター間の後続のIPv6ベストエフォートユニキャストデータは、新しいPtP VCを介して送信されます。
Neighbor Unreachability Detection (NUD) is the process by which an IPv6 host determines that a neighbor is no longer reachable, as described in [7]. Each Neighbor cache entry contains information used by the NUD algorithm to detect reachability failures. Confirmation of a neighbor's reachability comes either from upper-layer protocol indications that data recently sent to the neighbor was received, or from the receipt of a Neighbor Advertisement message in response to a Neighbor Solicitation probe.
[7]で説明されているように、ネイバー到達不能検出（NUD）は、IPv6ホストがネイバーに到達できなくなったと判断するプロセスです。各ネイバーキャッシュエントリには、NUDアルゴリズムが到達可能性の障害を検出するために使用する情報が含まれています。ネイバーの到達可能性の確認は、ネイバーに最近送信されたデータが受信されたという上位層プロトコルの指示、またはネイバー要請プローブへの応答としてのネイバーアドバタイズメントメッセージの受信から行われます。
Connectivity failures at the node's IPv6/NBMA driver, such as released VCs (see section 4.6) and the inability to create a VC to a neighbor (see section 4.4.1), are detected and handled at the IPv6 network layer, through Neighbor Unreachability Detection. The node's IPv6/NBMA driver does not attempt to detect or recover from these conditions.
ノードのIPv6 / NBMAドライバーでの接続障害（リリースされたVC（セクション4.6を参照）など）や、ネイバーへのVCを作成できない（セクション4.4.1を参照）などは、ネイバー到達不能性を通じてIPv6ネットワークレイヤーで検出および処理されます。検出。ノードのIPv6 / NBMAドライバーは、これらの状態の検出または回復を試みません。
A persistent failure to create a VC from the IPv6 host to one of its IPv6 neighbors will be detected and handled through NUD. On each attempt to send data from the IPv6 host to its neighbor, the node's IPv6/NBMA driver will attempt to set up a VC to the neighbor, and failing to do so, will drop the packet. IPv6 reachability confirmation timers will eventually expire, and the neighbor's Neighbor cache entry will enter the PROBE state. The PROBE state will cause the IPv6 host to unicast Neighbor Solicitations to the neighbor, which will be dropped by the local node's IPv6/NBMA driver after again failing to setup the VC. The IPv6 host will therefore never receive the solicited Neighbor Advertisements needed for reachability confirmation, causing the neighbor's entry to be deleted from the Neighbor cache. The next time the IPv6 host tries to send data to that neighbor, address resolution will be performed. Depending on the reason for the previous failure, connectivity to the neighbor could be re-established (for example, if the previous VC setup failure was caused by an obsolete link-layer address in the Neighbor cache).
IPv6ホストからそのIPv6ネイバーの1つへのVCを作成する永続的な障害は、NUDを通じて検出および処理されます。 IPv6ホストからネイバーにデータを送信しようとするたびに、ノードのIPv6 / NBMAドライバーはネイバーにVCを設定しようとしますが、失敗するとパケットがドロップされます。 IPv6到達可能性確認タイマーは最終的に期限切れになり、ネイバーのネイバーキャッシュエントリはPROBE状態になります。 PROBE状態により、IPv6ホストはネイバー要請をネイバーにユニキャストします。これは、VCのセットアップに再び失敗した後、ローカルノードのIPv6 / NBMAドライバーによってドロップされます。したがって、IPv6ホストは到達可能性の確認に必要な要請されたネイバーアドバタイズメントを受信しないため、ネイバーのエントリがネイバーキャッシュから削除されます。次にIPv6ホストがそのネイバーにデータを送信しようとしたときに、アドレス解決が実行されます。以前の障害の理由によっては、ネイバーへの接続が再確立される可能性があります（たとえば、以前のVCセットアップの障害がネイバーキャッシュ内の古いリンク層アドレスによって引き起こされた場合）。
In the event that a VC from an IPv6 neighbor is released, the next time a packet is sent from the IPv6 host to the neighbor, the node's IPv6/NBMA driver will recognize that it no longer has a VC to that neighbor and attempt to setup a new VC to the neighbor. If, on the first and on subsequent transmissions, the node is unable to create a VC to the neighbor, NUD will detect and handle the failure as described earlier (handling the persistent failure to create a VC from the IPv6 host to one of its IPv6 neighbors). Depending on the reason for the previous failure, connectivity to the neighbor may or may not be re-established.
IPv6ネイバーからのVCが解放された場合、次回IPv6ホストからネイバーにパケットが送信されると、ノードのIPv6 / NBMAドライバーは、そのネイバーへのVCがなくなったことを認識し、セットアップを試みます。ネイバーへの新しいVC。最初と後続の送信で、ノードがネイバーへのVCを作成できない場合、NUDは前述のように障害を検出して処理します（IPv6ホストからそのIPv6のいずれかにVCを作成する永続的な障害を処理します）隣人）。以前の障害の理由に応じて、ネイバーへの接続が再確立される場合とされない場合があります。
An IPv6 host performs Duplicate Address Detection (DAD) to determine that the address it wishes to use on the LL (i.e. a tentative address) is not already in use, as described in [9] and [7]. Duplicate Address Detection is performed on all addresses the host wishes to use, regardless of the configuration mechanism used to obtain the address.
[9]と[7]で説明されているように、IPv6ホストは重複アドレス検出（DAD）を実行して、LLで使用したいアドレス（仮アドレス）がまだ使用されていないことを確認します。重複アドレス検出は、アドレスの取得に使用される構成メカニズムに関係なく、ホストが使用するすべてのアドレスに対して実行されます。
Prior to performing Duplicate Address Detection, a host will join the all-nodes multicast address and the solicited-node multicast address corresponding to the host's tentative address (see 4.2. Joining a Multicast Group). The IPv6 host initiates Duplicate Address Detection by sending a Neighbor Solicitation to solicited-node multicast address corresponding to the host's tentative address, with the tentative address as the target. When the local node's IPv6/NBMA driver gets the Neighbor Solicitation message from the IPv6 network layer, it follows the steps outlined in section 4.4.2. The NS message will be sent to those nodes which joined the target solicited-node multicast group or to all nodes. The DAD NS message will be received by one or more nodes on the LL and processed by each as described in section 4.5. Note that the MARS client of the sending node will filter out the message so that the sending node's IPv6 network layer will not see the message. The IPv6 network layer of any node which is not a member of the target solicited-node multicast group will discard the Neighbor Solicitation message.
重複アドレス検出を実行する前に、ホストは、全ノードマルチキャストアドレスと、ホストの仮アドレスに対応する要請ノードマルチキャストアドレスに参加します（4.2。マルチキャストグループへの参加を参照）。 IPv6ホストは、ホストの仮アドレスに対応する要請ノードのマルチキャストアドレスに、仮アドレスをターゲットとして近傍要請を送信することにより、重複アドレス検出を開始します。ローカルノードのIPv6 / NBMAドライバーがIPv6ネットワークレイヤーから近隣要請メッセージを取得すると、セクション4.4.2で概説されている手順に従います。 NSメッセージは、ターゲット要請ノードマルチキャストグループに参加したノードまたはすべてのノードに送信されます。 DAD NSメッセージは、LL上の1つ以上のノードによって受信され、セクション4.5で説明されているように各ノードによって処理されます。送信ノードのMARSクライアントはメッセージをフィルターで除外するため、送信ノードのIPv6ネットワークレイヤーにはメッセージが表示されないことに注意してください。ターゲット要請ノードマルチキャストグループのメンバーではないノードのIPv6ネットワークレイヤーは、近隣要請メッセージを破棄します。
If no other hosts have joined the solicited-node multicast address corresponding to the tentative address, then the host will not receive a Neighbor Advertisement containing its tentative address as the target. The host will perform the retransmission logic described in [9], terminate Duplicate Address Detection, and assign the tentative address to the NBMA interface.
他のホストが仮アドレスに対応する送信請求ノードマルチキャストアドレスに参加していない場合、ホストは仮アドレスをターゲットとして含むネイバーアドバタイズを受信しません。ホストは、[9]で説明されている再送信ロジックを実行し、重複アドレス検出を終了し、暫定アドレスをNBMAインターフェイスに割り当てます。
Otherwise, other hosts on the LL that have joined the solicited-node multicast address corresponding to the tentative address will process the Neighbor Solicitation. The processing will depend on whether or not receiving IPv6 host considers the target address to be tentative.
それ以外の場合は、仮アドレスに対応する要請ノードマルチキャストアドレスに参加したLL上の他のホストが近隣要請を処理します。処理は、受信するIPv6ホストがターゲットアドレスを一時的なものと見なすかどうかによって異なります。
If the receiving IPv6 host's address is not tentative, the host will respond with a Neighbor Advertisement containing the target address. Because the source of the Neighbor Solicitation is the unspecified address, the host sends the Neighbor Advertisement to the all-nodes multicast address following the steps outlined in section 4.4.2. The DAD NA message will be received and processed by the MARS clients on all nodes in the LL as described in section 4.5. Note that the sending node will filter the incoming message since the CMI in the message header will match that of the receiving node. All other nodes will de-encapsulate the message and pass it to the IPv6 network layer. The host performing DAD will detect that its tentative address is the target of the Neighbor Advertisement, and determine that the tentative address is not unique and cannot be assigned to its NBMA interface.
受信するIPv6ホストのアドレスが暫定的でない場合、ホストはターゲットアドレスを含むネイバーアドバタイズメントで応答します。 Neighbor Solicitationのソースは未指定のアドレスであるため、ホストはセクション4.4.2で概説されている手順に従って、全ノードのマルチキャストアドレスにNeighbor Advertisementを送信します。 DAD NAメッセージは、セクション4.5で説明されているように、LLのすべてのノード上のMARSクライアントによって受信および処理されます。メッセージヘッダーのCMIは受信ノードのCMIと一致するため、送信ノードは受信メッセージをフィルター処理することに注意してください。他のすべてのノードはメッセージのカプセル化を解除し、IPv6ネットワーク層に渡します。 DADを実行するホストは、その暫定アドレスがネイバーアドバタイズのターゲットであることを検出し、暫定アドレスが一意ではなく、NBMAインターフェイスに割り当てることができないと判断します。
If the receiving IPv6 host's address is tentative, then both hosts are performing DAD using the same tentative address. The receiving host will determine that the tentative address is not unique and cannot be assigned to its NBMA interface.
受信IPv6ホストのアドレスが仮の場合、両方のホストが同じ仮アドレスを使用してDADを実行しています。受信ホストは、仮アドレスが一意ではなく、NBMAインターフェイスに割り当てることができないと判断します。
An IPv6 router uses a Redirect Message to inform an IPv6 host of a better first-hop for reaching a particular destination, as described in [7]. This can be used to direct hosts to a better first hop router, another host on the same LL, or to a transient neighbor on another LL. The IPv6 router will unicast the Redirect to the IPv6 source address that triggered the Redirect. The router's IPv6/NBMA driver will transmit the Redirect message using the procedure described in section 4.4.1. This will create a VC between the router and the redirected host if one did not previously exist.
[7]で説明されているように、IPv6ルーターはリダイレクトメッセージを使用して、特定の宛先に到達するためのより良い最初のホップをIPv6ホストに通知します。これを使用して、ホストをより適切なファーストホップルーター、同じLL上の別のホスト、または別のLL上の一時的なネイバーに転送できます。 IPv6ルーターは、リダイレクトをトリガーしたIPv6送信元アドレスにリダイレクトをユニキャストします。ルーターのIPv6 / NBMAドライバーは、セクション4.4.1で説明されている手順を使用してリダイレクトメッセージを送信します。これにより、以前に存在していなかった場合、ルーターとリダイレクトされたホストの間にVCが作成されます。
The IPv6/NBMA driver of the IPv6 host that triggered the Redirect will receive the encapsulated Redirect over one of it's pt-pt VCs. It will the de-encapsulate the packet, and pass the Redirect message to the IPv6 Network Layer, as described section 4.5.
リダイレクトをトリガーしたIPv6ホストのIPv6 / NBMAドライバーは、pt-pt VCの1つを介してカプセル化されたリダイレクトを受信します。セクション4.5で説明するように、パケットのカプセル化を解除し、リダイレクトメッセージをIPv6ネットワークレイヤーに渡します。
Subsequent data sent from the IPv6 host to the destination will be sent to the next-hop address specified in the Redirect Message. For NBMA networks, the Redirect Message should contain the link-layer address option as described in [7] and section 5.2, thus the redirected node will not have to perform a Neighbor Solicitation to learn the link-layer address of the node to which it has been redirected. Thus, the redirect can be to any node on the NBMA network, regardless of the LL membership of the new target node. This allows NBMA hosts to be redirected off their LL to achieve shortcut by using standard IPv6 protocols.
IPv6ホストから宛先に送信される後続のデータは、リダイレクトメッセージで指定されたネクストホップアドレスに送信されます。 NBMAネットワークの場合、[7]とセクション5.2で説明されているように、リダイレクトメッセージにはリンク層アドレスオプションが含まれている必要があります。したがって、リダイレクトされたノードは近隣要請を実行して、宛先ノードのリンク層アドレスを知る必要はありません。リダイレクトされました。したがって、リダイレクトは、新しいターゲットノードのLLメンバーシップに関係なく、NBMAネットワーク上の任意のノードに行うことができます。これにより、NBMAホストをLLからリダイレクトして、標準のIPv6プロトコルを使用してショートカットを実現できます。
Once redirected, the IPv6 network layer will give the node's IPv6/NBMA driver the IPv6 packet and the link-layer address of the next-hop node when it sends data to the redirected destination. The node's IPv6/NBMA driver will determine if a VC to the next-hop destination exists. If a pt-pt VC does not exist, then the IPv6/NBMA driver will queue the data packet and initiate a setup of a VC to the destination. When the VC is created, or if one already exists, then the node will encapsulate the outgoing data packet and send it on the VC.
リダイレクトされると、IPv6ネットワーク層は、ノードのIPv6 / NBMAドライバーに、リダイレクト先にデータを送信するときに、ネクストホップノードのIPv6パケットとリンク層アドレスを提供します。ノードのIPv6 / NBMAドライバーは、ネクストホップの宛先へのVCが存在するかどうかを判断します。 pt-pt VCが存在しない場合、IPv6 / NBMAドライバーはデータパケットをキューに入れ、宛先へのVCのセットアップを開始します。 VCが作成されるとき、またはすでに存在する場合、ノードは発信データパケットをカプセル化し、それをVCに送信します。
Note that Redirects are unidirectional. The redirected host will create a VC to the next-hop destination as specified in the Redirect message, but the next-hop will not be redirected to the source host. Because no Neighbor Discovery takes place, the next-hop destination has no way of determining the identity of the caller when it receives the new VC. Also, since ND does not take place on redirects, the next-hop receives no event that would cause it to update it's neighbor or destination caches. However, it will continue to transmit data back to the redirected host on the former path to the redirected host. The next-hop node should be able to use the new VC from the redirected destination if it too receives a redirect redirecting it to the redirected node. This behavior is consistent with [7].
リダイレクトは単方向であることに注意してください。リダイレクトされたホストは、リダイレクトメッセージで指定されたネクストホップの宛先にVCを作成しますが、ネクストホップはソースホストにリダイレクトされません。近隣探索は行われないため、ネクストホップ宛先は、新しいVCを受信したときに発信者のIDを判別する方法がありません。また、NDはリダイレクトでは発生しないため、ネクストホップは、ネイバーキャッシュまたは宛先キャッシュを更新するようなイベントを受信しません。ただし、リダイレクトされたホストへの以前のパスで、リダイレクトされたホストにデータを送信し続けます。ネクストホップノードは、リダイレクトされたノードにリダイレクトするリダイレクトも受信した場合、リダイレクトされた宛先から新しいVCを使用できる必要があります。この動作は[7]と一致しています。
IPv6 addresses are auto-configured using the stateless or stateful address auto-configuration mechanisms, as described in [9] and [18]. The IPv6 auto-configuration process involves creating and verifying the uniqueness of a link-local address on an LL, determining whether to use stateless and/or stateful configurationmechanisms to obtain addresses, and determining if other (non- address) information is to be autoconfigured. IPv6 addresses can also be manually configured, if for example, auto-configuration fails because the autoconfigured link-local address is not unique. An LL administrator specifies the type of autoconfiguration to use; the hosts on an LL receive this autoconfiguration information through Router Advertisement messages.
[9]と[18]で説明されているように、IPv6アドレスはステートレスまたはステートフルアドレス自動構成メカニズムを使用して自動構成されます。 IPv6自動構成プロセスには、LL上のリンクローカルアドレスの一意性の作成と検証、アドレスを取得するためにステートレスおよび/またはステートフル構成メカニズムを使用するかどうかの決定、および他の（非アドレス）情報を自動構成するかどうかの決定が含まれます。 。自動構成されたリンクローカルアドレスが一意でないために自動構成が失敗した場合など、IPv6アドレスを手動で構成することもできます。 LL管理者は、使用する自動構成のタイプを指定します。 LL上のホストは、ルーターアドバタイズメッセージを通じてこの自動構成情報を受信します。
The following sections describe how stateless, stateful and manual address configuration will work in an IPv6/NBMA environment.
次のセクションでは、IPv6 / NBMA環境でステートレス、ステートフル、および手動のアドレス構成がどのように機能するかについて説明します。
IPv6 stateless address configuration is the process by which an IPv6 host autoconfigures its interfaces, as described in [IPV6-ADDRCONF].
IPv6ステートレスアドレス構成は、[IPV6-ADDRCONF]で説明されているように、IPv6ホストがインターフェイスを自動構成するプロセスです。
When an IPv6 host first starts up, it generates a link-local address for the interface attached to the Logical Link. It then verifies the uniqueness of the link-local address using Duplicate Address Detection (DAD). If the IPv6 host detects that the link-local address is not unique, the autoconfiguration process terminates. The IPv6 host must then be manually configured.
IPv6ホストは、最初の起動時に、論理リンクに接続されているインターフェースのリンクローカルアドレスを生成します。次に、重複アドレス検出（DAD）を使用してリンクローカルアドレスの一意性を確認します。 IPv6ホストがリンクローカルアドレスが一意でないことを検出すると、自動構成プロセスは終了します。次に、IPv6ホストを手動で構成する必要があります。
After the IPv6 host determines that the link-local address is unique and has assigned it to the interface on the Logical Link, the IPv6 host will perform Router Discovery to obtain auto-configuration information. The IPv6 host will send out a Router Solicitation and will receive a Router Advertisement, or it will wait for an unsolicited Router Advertisement. The IPv6 host will process the M and O bits of the Router Advertisement, as described in [9] and as a result may invoke stateful address auto- configuration.
IPv6ホストがリンクローカルアドレスが一意であると判断し、論理リンク上のインターフェイスに割り当てた後、IPv6ホストはルーター検出を実行して自動構成情報を取得します。 IPv6ホストはルーター要請を送信してルーターアドバタイズメントを受信するか、または要請されていないルーターアドバタイズメントを待機します。 [9]で説明されているように、IPv6ホストはルーターアドバタイズのMビットとOビットを処理し、その結果、ステートフルアドレス自動構成を呼び出すことができます。
If there are no routers on the Logical Link, the IPv6 host will be able to communicate with other IPv6 hosts on the Logical Link using link-local addresses. The IPv6 host will obtain a neighbor's link-layer address using Address Resolution. The IPv6 host will also attempt to invoke stateful auto-configuration, unless it has been explicitly configured not to do so.
論理リンク上にルーターがない場合、IPv6ホストはリンクローカルアドレスを使用して、論理リンク上の他のIPv6ホストと通信できます。 IPv6ホストは、アドレス解決を使用してネイバーのリンク層アドレスを取得します。 IPv6ホストは、明示的に構成されていない限り、ステートフル自動構成を呼び出そうとします。
IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to perform stateful address auto-configuration, as described in [18].
[18]で説明されているように、IPv6ホストは動的ホスト構成プロトコル（DHCPv6）を使用して、ステートフルアドレス自動構成を実行します。
A DHCPv6 server or relay agent is present on a Logical Link that has been configured with manual or stateful auto-configuration. The DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay-Agent multicast group on the Logical Link. When the node's IPv6/NBMA driver gets the JoinLocalGroup request from the IPv6 network layer, it follows the process described in section 4.2.
DHCPv6サーバーまたはリレーエージェントが、手動またはステートフル自動構成で構成された論理リンクに存在します。 DHCPv6サーバーまたはリレーエージェントは、論理リンク上のIPv6 DHCPv6サーバー/リレーエージェントマルチキャストグループに参加します。ノードのIPv6 / NBMAドライバーがIPv6ネットワーク層からJoinLocalGroup要求を取得すると、セクション4.2で説明されているプロセスに従います。
An IPv6 host will invoke stateful auto-configuration if M and O bits of Router Advertisements indicate it should do so, and may invoke stateful auto-configuration if it detects that no routers are present on the Logical Link. An IPv6 host that is obtaining configuration information through the stateful mechanism will hereafter be referred to as a DHCPv6 client.
IPv6ホストは、ルーターアドバタイズのMビットとOビットがそうする必要があることを示している場合はステートフル自動構成を呼び出し、論理リンクにルーターが存在しないことを検出した場合はステートフル自動構成を呼び出す場合があります。ステートフルメカニズムを通じて構成情報を取得しているIPv6ホストは、以降、DHCPv6クライアントと呼ばれます。
A DHCPv6 client will send a DHCPv6 Solicit message to the DHCPv6 Server/Relay-Agent multicast address to locate a DHCPv6 Agent. When the soliciting node's IPv6/NBMA driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps described in section 4.4.2. This will result in one or more nodes on the LL receiving the message. Each node that receives the solicitation packet will process it as described in section section 4.5. Only the IPv6 network layer of the DHCPv6 server/relay-agent will accept the packet and process it.
DHCPv6クライアントは、DHCPv6サーバー/リレーエージェントマルチキャストアドレスにDHCPv6要請メッセージを送信して、DHCPv6エージェントを見つけます。送信請求ノードのIPv6 / NBMAドライバーがIPv6ネットワークレイヤーからパケットを送信する要求を取得すると、セクション4.4.2で説明されている手順に従います。これにより、LL上の1つ以上のノードがメッセージを受信します。要請パケットを受信する各ノードは、セクション4.5で説明されているようにそれを処理します。 DHCPv6サーバー/リレーエージェントのIPv6ネットワークレイヤーのみがパケットを受け入れて処理します。
A DHCPv6 Server or Relay Agent on the Logical Link will unicast a DHCPv6 Advertisement to the DHCPv6 client. The IPv6 network layer will give the node's IPv6/NBMA driver the packet and link-layer address of the DHCPv6 client (obtained through Neighbor Discovery if necessary). The node IPv6/NBMA driver will then transmit the packet as described in section 4.4.1. This will result in a new pt-pt VC being created between the server and the client if one did not previously exist.
論理リンク上のDHCPv6サーバーまたはリレーエージェントは、DHCPv6アドバタイズメントをDHCPv6クライアントにユニキャストします。 IPv6ネットワーク層は、ノードのIPv6 / NBMAドライバーにDHCPv6クライアントのパケットとリンク層アドレスを提供します（必要に応じて近隣探索を通じて取得）。ノードIPv6 / NBMAドライバーは、セクション4.4.1で説明されているようにパケットを送信します。これにより、以前に存在していなかった場合、サーバーとクライアントの間に新しいpt-pt VCが作成されます。
The DHCP client's IPv6/NBMA driver will receive the encapsulated packet from the DHCP Server or Relay Agent, as described in section 4.5. The node will de-encapsulate the multicast packet and then pass it up to the IPv6 Network Layer for processing. The IPv6 network layer will deliver the DHCPv6 Advertise message to the DHCPv6 client.
セクション4.5で説明されているように、DHCPクライアントのIPv6 / NBMAドライバーは、DHCPサーバーまたはリレーエージェントからカプセル化されたパケットを受信します。ノードはマルチキャストパケットのカプセル化を解除し、IPv6ネットワーク層に渡して処理します。 IPv6ネットワーク層は、DHCPv6アドバタイズメッセージをDHCPv6クライアントに配信します。
Other DHCPv6 messages (Request, Reply, Release and Reconfigure) are unicast between the DHCPv6 client and the DHCPv6 Server. Depending on the reachability of the DHCPv6 client's address, messages exchanged between a DHCPv6 client and a DHCPv6 Server on another LL are sent either via a router or DHCPv6 Relay-Agent. Prior to sending the DHCPv6 message, the IPv6 network layer will perform Neighbor Discovery (if necessary) to obtain the link-layer address corresponding to the packet's next-hop. A pt-pt VC will be set up between the sender and the next hop, and the encapsulated packet transmitted over it, as described in 4.4. Sending Data.
その他のDHCPv6メッセージ（要求、応答、解放、および再構成）は、DHCPv6クライアントとDHCPv6サーバーの間でユニキャストされます。 DHCPv6クライアントのアドレスの到達可能性に応じて、DHCPv6クライアントと別のLL上のDHCPv6サーバーの間で交換されるメッセージは、ルーターまたはDHCPv6リレーエージェントを介して送信されます。 DHCPv6メッセージを送信する前に、IPv6ネットワーク層は近隣探索（必要な場合）を実行して、パケットのネクストホップに対応するリンク層アドレスを取得します。 pt-pt VCは送信者とネクストホップの間に設定され、カプセル化されたパケットはそれを介して送信されます（4.4で説明）。データの送信。
An IPv6 host will be manually configured if it discovers through DAD that its link-local address is not unique. Once the IPv6 host is configured with a unique interface token, the auto-configuration mechanisms can then be invoked.
IPv6ホストは、DADを介して、リンクローカルアドレスが一意でないことを検出した場合、手動で構成されます。 IPv6ホストに一意のインターフェイストークンが構成されたら、自動構成メカニズムを呼び出すことができます。
IPv6 multicast routers will use the IGMPv6 protocol to periodically determine group memberships of local hosts. In the framework described here, the IGMPv6 protocols can be used without any special modifications for NBMA. While these protocols might not be the most efficient in this environment, they will still work as described below. However, IPv6 multicast routers connected to an NBMA LL could optionally optimize the IGMP functions by sending MARS_GROUPLIST_REQUEST messages to the MARS serving the LL and determining group memberships by the MARS_GROUPLIST_REPLY messages. Querying the MARS for multicast group membership is an optional enchancement and is not required for routers to determine IPv6 multicast group membership on a LL.
IPv6マルチキャストルーターは、IGMPv6プロトコルを使用して、ローカルホストのグループメンバーシップを定期的に決定します。ここで説明するフレームワークでは、NBMPを特別に変更することなく、IGMPv6プロトコルを使用できます。これらのプロトコルは、この環境では最も効率的ではないかもしれませんが、以下で説明するように機能します。ただし、NBMA LLに接続されたIPv6マルチキャストルーターは、LLSを提供するMARSにMARS_GROUPLIST_REQUESTメッセージを送信し、MARS_GROUPLIST_REPLYメッセージによってグループメンバーシップを決定することにより、オプションでIGMP機能を最適化できます。 MARSにマルチキャストグループメンバーシップを照会することはオプションの拡張であり、ルーターがLL上のIPv6マルチキャストグループメンバーシップを決定するために必要ではありません。
There are three ICMPv6 message types that carry multicast group membership information: the Group Membership Query, Group Membership Report and Group Membership Reduction messages. IGMPv6 will continue to work unmodified over the IPv6/NBMA architecture described in this document.
マルチキャストグループメンバーシップ情報を伝達するICMPv6メッセージタイプには、グループメンバーシップクエリ、グループメンバーシップレポート、グループメンバーシップ削減メッセージの3つがあります。 IGMPv6は、このドキュメントで説明されているIPv6 / NBMAアーキテクチャ上で変更されずに引き続き機能します。
An IPv6 multicast router receives all IPv6 multicast packets on the LL by joining all multicast groups in promiscuous mode [5]. The MARS server will then cause the multicast router to be added to all existing and future multicast VCs. The IPv6 multicast router will thereafter be the recipient of all IPv6 multicast packets sent within the Logical Link.
IPv6マルチキャストルーターは、混合モードですべてのマルチキャストグループに参加することにより、LLですべてのIPv6マルチキャストパケットを受信します[5]。次に、MARSサーバーは、マルチキャストルータを既存および将来のすべてのマルチキャストVCに追加します。その後、IPv6マルチキャストルーターは、論理リンク内で送信されるすべてのIPv6マルチキャストパケットの受信者になります。
An IPv6 multicast router discovers which multicast groups have members in the Logical Link by periodically sending Group Membership Query messages to the IPv6 all-nodes multicast address. When the local node's IPv6/NBMA driver gets the request from the IPv6 network layer to send the Group Membership Query packet, it follows the steps described in 4.4.2. The node determines that the destination address of the packet is the all-nodes multicast address and passes the packet to the node's MARS client where the packet is encapsulated and directly transmitted to the MARS. The MARS then relays the packet to all nodes in the LL. Each node's IPv6/NBMA drivers will receive the packet, de-encapsulate it, and passed it up to the IPv6 Network layer. If the originating node receives the encapsulated packet, the packet will be filtered out by the MARS client since the Cluster Member ID of the receiving node will match the CMI in the packet's MARS encapsulation header.
IPv6マルチキャストルーターは、グループメンバーシップクエリメッセージをIPv6全ノードマルチキャストアドレスに定期的に送信することにより、論理リンクにメンバーを持つマルチキャストグループを検出します。ローカルノードのIPv6 / NBMAドライバーがIPv6ネットワークレイヤーからグループメンバーシップクエリパケットを送信する要求を受け取ると、4.4.2で説明されている手順に従います。ノードは、パケットの宛先アドレスが全ノードマルチキャストアドレスであると判断し、パケットをノードのMARSクライアントに渡します。ここで、パケットはカプセル化され、MARSに直接送信されます。次に、MARSはパケットをLL内のすべてのノードにリレーします。各ノードのIPv6 / NBMAドライバーは、パケットを受信してカプセル化を解除し、IPv6ネットワークレイヤーに渡します。送信元ノードがカプセル化されたパケットを受信すると、受信ノードのクラスターメンバーIDがパケットのMARSカプセル化ヘッダーのCMIと一致するため、パケットはMARSクライアントによってフィルターで除外されます。
IPv6 hosts in the Logical Link will respond to a Group Membership Query with a Group Membership Report for each IPv6 multicast group joined by the host. IPv6 hosts can also transmit a Group Membership Report when the host joins a new IPv6 multicast group. The Group Membership Report is sent to the multicast group whose address is being reported. When the local node IPv6/NBMA driver gets the request from the IPv6 network layer to send the packet, it follows the steps described in 4.4.2. The node determines that the packet is being sent to a multicast address so forwards it to the node's MARS client for sending on the appropriate VC.
論理リンク内のIPv6ホストは、ホストが参加している各IPv6マルチキャストグループのグループメンバーシップレポートでグループメンバーシップクエリに応答します。 IPv6ホストは、ホストが新しいIPv6マルチキャストグループに参加したときに、グループメンバーシップレポートを送信することもできます。グループメンバーシップレポートは、アドレスが報告されているマルチキャストグループに送信されます。ローカルノードのIPv6 / NBMAドライバーは、IPv6ネットワークレイヤーからパケットを送信する要求を取得すると、4.4.2で説明されている手順に従います。ノードは、パケットがマルチキャストアドレスに送信されていると判断し、適切なVCで送信するためにパケットをノードのMARSクライアントに転送します。
The Group Membership Report packets will arrive at every node which is a member of the group being reported through one of the VC attached to each node's MARS client. The MARS client will de-encapsulate the incoming packet and the packet will be passed to the IPv6 network layer for processing. The MARS client of the sending node will filter out the packet when it receives it.
グループメンバーシップレポートパケットは、各ノードのMARSクライアントに接続されているVCの1つを介して報告されるグループのメンバーであるすべてのノードに到着します。 MARSクライアントは着信パケットのカプセル化を解除し、パケットはIPv6ネットワーク層に渡されて処理されます。送信ノードのMARSクライアントは、パケットを受信すると、パケットをフィルターで除外します。
An IPv6 host sends a Group Membership Reduction message when the host leaves an IPv6 multicast group. The Group Membership Reduction is sent to the multicast group the IPv6 host is leaving. The transmission and receipt of Group Membership Reduction messages are handled in the same manner as Group Membership Reports.
ホストがIPv6マルチキャストグループを離れると、IPv6ホストはグループメンバーシップ削減メッセージを送信します。グループメンバーシップの削減は、IPv6ホストが離脱するマルチキャストグループに送信されます。グループメンバーシップ削減メッセージの送受信は、グループメンバーシップレポートと同じ方法で処理されます。
B.1 Simplistic approach - Use MARS 'as is'.
B.1単純なアプローチ-MARSを「そのまま」使用します。
The IPv6/NBMA driver utilizes the standard MARS protocol to establish a VC forwarding path out of the interface on which it can transmit all multicast IPv6 packets, including ICMPv6 packets. The IPv6 packets are then transmitted, and received by the intended destination set, using separate pt-mpt VCs per destination group.
IPv6 / NBMAドライバーは、標準のMARSプロトコルを使用して、ICMPv6パケットを含むすべてのマルチキャストIPv6パケットを送信できるインターフェイスからVC転送パスを確立します。次に、IPv6パケットが送信され、宛先グループごとに個別のpt-mpt VCを使用して、目的の宛先セットによって受信されます。
In this approach all the protocol elements in [5] are used 'as is'. However, SVC resource consumption must be taken into consideration. Unfortunately, ND assumes that link level multicast resources are best conserved by generating a sparsely distributed set of Solicited Node multicast addresses (to which discovery queries are initially sent). The original goal was to minimize the number of innocent nodes that simultaneously received discovery messages really intended for someone else.
このアプローチでは、[5]のすべてのプロトコル要素が「そのまま」使用されます。ただし、SVCリソースの消費を考慮する必要があります。残念ながら、NDは、疎結合された要請ノードマルチキャストアドレスのセット（ディスカバリークエリが最初に送信される）を生成することにより、リンクレベルのマルチキャストリソースが最適に保存されると想定しています。本来の目的は、実際に他の人を対象としたディスカバリーメッセージを同時に受信する無害なノードの数を最小限にすることでした。
However, in connection oriented NBMA environments it becomes equally (or more) important to minimize the number of independent VCs that a given NBMA interface is required to originate or terminate. If we treat the MARS service as a 'black box' the sparse Solicited Node address space can lead to a large number of short-use, but longer lived, pt-mpt VCs (generated whenever the node is transmitting Neighbor Solicitations). Even more annoying, these VCs are only useful for additional packets being sent to their associated Solicited Node multicast address. A new pt-pt VC is required to actually carry the unicast IPv6 traffic that prompted the Neighbor Solicitation.
ただし、接続指向のNBMA環境では、特定のNBMAインターフェイスが開始または終了するために必要な独立VCの数を最小限に抑えることが同等（またはそれ以上）に重要になります。 MARSサービスを「ブラックボックス」として扱う場合、スパースな要請ノードアドレススペースは、多数の短期使用であるが、より長く存続するpt-mpt VC（ノードが近隣要請を送信するたびに生成される）につながる可能性があります。さらに厄介なことに、これらのVCは、関連する要請ノードのマルチキャストアドレスに送信される追加のパケットに対してのみ役立ちます。近隣要請を促したユニキャストIPv6トラフィックを実際に伝送するには、新しいpt-pt VCが必要です。
The axis of inefficiency brought about by the sparse Solicited Nodes address space is orthogonal to the VC mesh vs Multicast Server tradeoff. Typically a multicast server aggregates traffic flow to a common multicast group onto a single VC. To reduce the VC consumption for ND, we need to aggregate across the Solicited Node address space - performing aggregation on the basis of a packet's function rather than its explicit IPv6 destination. The trade-off here is that the aggregation removes the original value of scattering nodes sparsely across the Solicited Nodes space. This is a price of the mismatch between ND and connection oriented networks.
疎な要請ノードのアドレス空間によってもたらされる非効率性の軸は、VCメッシュとマルチキャストサーバーのトレードオフと直交しています。通常、マルチキャストサーバーは、共通のマルチキャストグループへのトラフィックフローを単一のVCに集約します。 NDのVC消費を削減するには、要請ノードアドレス空間全体で集約する必要があります。明示的なIPv6宛先ではなく、パケットの機能に基づいて集約を実行します。ここでのトレードオフは、集計により、要請ノードスペース全体の散在ノードの元の値がまばらに削除されることです。これは、NDとコネクション型ネットワーク間のミスマッチの代償です。
B.2 MARS as a Link (Multicast) Server.
B.2リンク（マルチキャスト）サーバーとしてのMARS。
One possible aggregation mechanism is for every node's IPv6/NBMA driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and logically remap their destinations to the All Nodes group (link local scope). By ensuring that the All Nodes group is supported by an MCS, the resultant VC load within the LL will be significantly reduced.
可能な集約メカニズムの1つは、すべてのノードのIPv6 / NBMAドライバーがマルチキャストNDまたはRDメッセージを運ぶマルチキャストICMPv6パケットをトラップし、それらの宛先をすべてのノードグループ（リンクローカルスコープ）に論理的に再マッピングすることです。 All NodesグループがMCSによってサポートされるようにすることで、LL内でのVC負荷が大幅に削減されます。
A further optimization is for every node's IPv6/NBMA driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and send them to the MARS itself for retransmission on ClusterControlVC (involving a trivial extension to the MARS itself.) This approach recognizes that in any LL where IPv6 multicasting is supported:
さらなる最適化は、すべてのノードのIPv6 / NBMAドライバーがマルチキャストNDまたはRDメッセージを運ぶマルチキャストICMPv6パケットをトラップし、それらをClusterControlVCで再送信するためにMARS自体に送信することです（MARS自体への些細な拡張を含みます）。このアプローチは、 IPv6マルチキャストがサポートされているLL：
- Nodes already have a pt-pt VC to their MARS.
- ノードには、MARSへのpt-pt VCがすでにあります。
- The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster members (LL members registered for multicast support).
- MARSには、すべてのクラスタメンバー（マルチキャストサポート用に登録されたLLメンバー）へのpt-mpt VC（ClusterControlVC）があります。
Because the VCs between a MARS and its MARS clients carry LLC/SNAP encapsulated packets, ICMP packets can be multiplexed along with normal MARS control messages. In essence the MARS behaves as a multicast server for non-MARS packets that it receives from around the LL.
MARSとそのMARSクライアント間のVCはLLC / SNAPカプセル化パケットを伝送するため、ICMPパケットは通常のMARS制御メッセージと共に多重化できます。本質的に、MARSは、LLの周囲から受信した非MARSパケットのマルチキャストサーバーとして動作します。
As there is no requirement that a MARS client accepts only MARS control messages on ClusterControlVC, ICMP packets received in this fashion may be passed to every node's IP layer without further comment. Within the IP layer, filtering will occur based on the packet's actual destination IP address, and only the targeted node will end up responding.
MARSクライアントがClusterControlVC上のMARS制御メッセージのみを受け入れる必要はないため、この方法で受信されたICMPパケットは、コメントを追加せずにすべてのノードのIP層に渡すことができます。 IPレイヤー内では、パケットの実際の宛先IPアドレスに基づいてフィルタリングが行われ、ターゲットノードのみが応答します。
Regrettably this approach does result in the entire Cluster's membership having to receive a variety of ICMPv6 messages that they will always throw away.
残念ながら、このアプローチでは、クラスターのメンバーシップ全体が、常に破棄するさまざまなICMPv6メッセージを受信する必要があります。
The relationship between IPv6 packet flows, Quality of Service guarantees, and optimal use of underlying IP and NBMA network resources are still subjects of ongoing research in the IETF (specifically the ISSLL, RSVP, IPNG, and ION working groups). This document currently only describes the use of flow detection as a means to optimize the use of NBMA network resources through the establishment of inter-LL shortcuts.
IPv6パケットフロー、Quality of Service保証、および基盤となるIPおよびNBMAネットワークリソースの最適な使用の関係は、IETF（特にISSLL、RSVP、IPNG、およびIONワーキンググループ）で現在も研究の対象となっています。このドキュメントでは現在、LL間ショートカットの確立を通じてNBMAネットワークリソースの使用を最適化する手段として、フロー検出の使用についてのみ説明しています。
For the purposes of this IPv6/NBMA architecture, a flow is:
このIPv6 / NBMAアーキテクチャの目的では、フローは次のとおりです。
A related sequence of IPv6 packets that the first hop router is allowed to perform flow-detection on for the purposes of triggering shortcut discovery.
ファーストホップルーターがショートカット検出をトリガーする目的でフロー検出を実行できるIPv6パケットの関連シーケンス。
How these packets are considered to be related to each other (e.g. through common header fields such as IPv6 destination addresses) is a local configuration issue.
これらのパケットが相互に関連していると見なされる方法（IPv6宛先アドレスなどの一般的なヘッダーフィールドを介して）は、ローカル構成の問題です。
The flow-detection rule specifies that only packets with a zero FlowID can be considered as flows for which shortcut discovery may be triggered. The rationale behind this decision is:
フロー検出ルールは、FlowIDがゼロのパケットのみが、ショートカット検出がトリガーされる可能性のあるフローと見なすことができることを指定します。この決定の根拠は次のとおりです。
NBMA shortcuts are for the benefit of 'the network' optimizing its forwarding of IPv6 packets in the absence of any other guidance from the host.
NBMAショートカットは、ホストからのその他のガイダンスがない場合に、IPv6パケットの転送を「ネットワーク」が最適化するためのものです。
It is desirable for an IPv6/NBMA host to have some mechanism for overriding attempts by 'the network' to optimize its internal forwarding path.
IPv6 / NBMAホストには、「ネットワーク」による内部転送パスを最適化するための試行を無効にするための何らかのメカニズムが必要です。
A zero FlowID has IPv6 semantics of "the source allows the network to utilize its own discretion in providing best-effort forwarding service for packets with zero FlowID"
ゼロFlowIDのIPv6セマンティクスは、「ソースは、ネットワークが独自の裁量を利用して、ゼロFlowIDのパケットにベストエフォートの転送サービスを提供できるようにする」
The IPv6 semantics of zero FlowID are consistent with the flow-detection rule in this document of "if the FlowID is zero, we are free to optimize the forwarding path using shortcuts"
ゼロFlowIDのIPv6セマンティクスは、このドキュメントの「FlowIDがゼロの場合、ショートカットを使用して転送パスを自由に最適化できる」というフロー検出ルールと一致しています。
A non-zero FlowID has IPv6 semantics of "the source has previously established some preferred, end to end hop by hop forwarding behaviour for packets with this FlowID" The IPv6 semantics of non-zero FlowID are consistent with the flow-detection rule in this document of "if the FlowID is non-zero, do not attempt to impose a shortcut".
ゼロ以外のFlowIDのIPv6セマンティクスは、「ソースは以前に、このFlowIDを持つパケットのホップツーホップフォワーディングホップバイフォワーディング動作をいくつか確立しています」ゼロ以外のFlowIDのIPv6セマンティクスは、このフロー検出ルールと一致しています。 「FlowIDがゼロ以外の場合は、ショートカットを強制しないでください」のドキュメント。
A non-zero FlowID might be assigned by the source host after negotiating a preferred forwarding mechanism with 'the network' (e.g. through dynamic means such as RSVP, or administrative means). Alternatively it can simply be assigned randomly by the source host, and the network will provide default best effort forwarding (an IPv6 router defaults to providing best-effort forwarding for packets whose FlowID/source-address pair is not recognized).
ゼロ以外のFlowIDは、「ネットワーク」との優先転送メカニズムのネゴシエーション後に（RSVPなどの動的な手段、または管理手段を介して）、送信元ホストによって割り当てられる可能性があります。または、送信元ホストによってランダムに割り当てられるだけで、ネットワークはデフォルトのベストエフォート転送を提供します（IPv6ルーターはデフォルトで、FlowID /送信元アドレスのペアが認識されないパケットにベストエフォート転送を提供します）。
Thus, the modes of operation supported by this document becomes:
したがって、このドキュメントでサポートされている操作モードは次のようになります。
Zero FlowID Best effort forwarding, with optional shortcut discovery triggered through flow-detection.
ゼロFlowIDベストエフォート転送。フロー検出によってトリガーされるオプションのショートカットディスカバリ。
Non-zero FlowID Best effort forwarding if the routers along the path have not been otherwise configured with alternative processing rules for this FlowID/source-address pair. Flow detection relating to shortcut discovery is suspended.
パスに沿ったルーターがこのFlowID /送信元アドレスペアの代替処理ルールで他の方法で構成されていない場合、ゼロ以外のFlowIDベストエフォート転送。ショートカット検出に関連するフロー検出は一時停止されます。
If the routers along the path have been configured with particular processing rules for this FlowID/source-address pair, the flow is handled according to those rules. Flow detection relating to shortcut discovery is suspended.
パスに沿ったルーターがこのFlowID /送信元アドレスペアの特定の処理ルールで構成されている場合、フローはそれらのルールに従って処理されます。ショートカット検出に関連するフロー検出は一時停止されます。
Mechanisms for establishing particular per-hop processing rules for packets with non-zero FlowID are neither constrained by, nor implied by, this document.
ゼロ以外のFlowIDを持つパケットに対して特定のホップごとの処理ルールを確立するためのメカニズムは、このドキュメントによる制約も暗黙的もありません。
In the future, accurate mapping of IPv6 flows onto NBMA VCs may require more information to be exchanged during the Neighbor Discovery process than is currently available in Neighbor Discovery packets. In these cases, the IPv6 Neighbor Discover protocols can be extended to include new TLV options (see section 4.6 of RFC 1970 [7]). However, if new options are required, the specification of these options must be co-ordinated with the IPNG working group. Since RFC 1970 specifies that nodes must silently ignore options they do not understand, new options can be added at any time without breaking backward compatibility with existing implementations.
将来、NBMA VCへのIPv6フローの正確なマッピングでは、近隣探索パケット中に現在利用可能な情報よりも多くの情報を近隣探索プロセス中に交換する必要が生じる可能性があります。このような場合、IPv6 Neighbor Discoverプロトコルを拡張して、新しいTLVオプションを含めることができます（RFC 1970 [7]のセクション4.6を参照）。ただし、新しいオプションが必要な場合は、これらのオプションの仕様をIPNGワーキンググループと調整する必要があります。 RFC 1970は、ノードが理解できないオプションを黙って無視する必要があると規定しているため、既存の実装との下位互換性を損なうことなく、いつでも新しいオプションを追加できます。
NHRP also provides mechanisms for adding optional TLVs to NHRP Requests and NHRP Replies. Future developments of this document's architecture will require consistent QoS extensions to both ND and NHRP in order to ensure they are semantically equivalent (syntactic differences are undesirable, but can be tolerated).
NHRPは、NHRP要求およびNHRP応答にオプションのTLVを追加するためのメカニズムも提供します。このドキュメントのアーキテクチャの今後の開発では、意味的に同等であることを保証するために、NDとNHRPの両方に一貫したQoS拡張が必要になります（構文の違いは望ましくありませんが、許容できます）。
Support for QoS on IPv6 unicast flows will not require further extensions to the existing MARS protocol. However, future support for QoS on IPv6 multicast flows may require extensions. MARS control messages share the same TLV extension mechanism as NHRP, allowing QoS extensions to be developed as needed.
IPv6ユニキャストフローでのQoSのサポートでは、既存のMARSプロトコルをさらに拡張する必要はありません。ただし、IPv6マルチキャストフローでのQoSの将来のサポートには、拡張が必要になる場合があります。 MARS制御メッセージはNHRPと同じTLV拡張メカニズムを共有するため、必要に応じてQoS拡張を開発できます。
For NS messages sent as a shortcut trigger, a new type of ND option is needed to pass on the information about the data flow hop limit from the host to the router. The use of this ND option is defined in section 3.2.2 of this specification. Its binary representation follows the rules of section 4.6 of RFC 1970:
ショートカットトリガーとして送信されるNSメッセージの場合、データフローホップ制限に関する情報をホストからルーターに渡すには、新しいタイプのNDオプションが必要です。このNDオプションの使用は、この仕様のセクション3.2.2で定義されています。そのバイナリ表現は、RFC 1970のセクション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 | Shortcut Limit| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type 6
タイプ6
Length 1
長さ1
Shortcut Limit 8-bit unsigned integer. Hop limit for shortcut attempt.
ショートカット制限8ビットの符号なし整数。ショートカット試行のホップ制限。
Reserved1 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約1このフィールドは未使用です。送信者はゼロに初期化する必要があり、受信者は無視する必要があります。
Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Reserved2このフィールドは未使用です。送信者はゼロに初期化する必要があり、受信者は無視する必要があります。
Description
説明
The shortcut limit option is used by a host in a Neighbor Solicitation message sent as a shortcut trigger to a default router. It restricts the router's shortcut query to targets reachable via the specified number of hops. The shortcut limit is given relative to the host requesting the shortcut. NS messages with shortcut limit values of 0 or 1 MUST be silently ignored.
ショートカット制限オプションは、デフォルトルーターへのショートカットトリガーとして送信される近隣要請メッセージでホストによって使用されます。ルーターのショートカットクエリを、指定したホップ数で到達可能なターゲットに制限します。ショートカットの制限は、ショートカットを要求しているホストに関連して与えられます。ショートカット制限値が0または1のNSメッセージは、黙って無視する必要があります。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。