RFC2491 日本語訳
2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks. G.Armitage, P. Schulter, M. Jork, G. Harter. January 1999. (Format: TXT=100782 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループG.アーミテージ要求をネットワークでつないでください: 2491年のルーセントテクノロジーズカテゴリ: 明るい標準化過程のデジタル機器GmbH G.HarterコンパックP.Schulterタイガー技術M.Jork1999年1月
IPv6 over Non-Broadcast Multiple Access (NBMA) networks
Non-放送Multiple Access(NBMA)ネットワークの上のIPv6
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
このドキュメントはIPv6のためにNBMAネットワークの上で一般的なアーキテクチャについて説明します。 それは様々な特定のNBMA技術(ATMかFrame Relayなどの)のための詳細について説明する補助の仲間ドキュメントの基礎を形成します。 NBMAアーキテクチャの上のIPv6はまた、ダイナミックに合図されたNBMAリンクが利用可能であるときに'近道'NBMA推進経路の設立をサポートしている間、IPv6 Neighborディスカバリープロトコルの従来のホストサイド手術を許します。 また、Point NBMAリンクへの行政上構成されたPointの上の操作は説明されます。
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近道はオフLink NBMAの目的地の発見のためにLogicalリンクス、および相互ルータNHRPの中でIPv6 Neighborディスカバリープロトコル操作の使用で達成されます。 引き起こされた流れと明らかにソースによって引き起こされた近道の両方がサポートされます。
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
非Broadcast Multiple Access(NBMA)ネットワークはさまざまな方法で利用されるかもしれません。 1つの極端では、単に行政上構成可能なポイント・ツー・ポイントサービスを提供するのにそれらを使用できます、IPv6ルータとインタコネクトできるくらいの(あるIPv6ホストさえ
Armitage, et. al. Standards Track [Page 1] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[1ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
状況) それとは正反対に、Virtual Circuits(または、機能的な同等物)のダイナミックな設立と分解をサポートする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).
このドキュメントはIPv6のためにNBMAネットワークの上で一般的なアーキテクチャについて説明します。 それは様々なNBMA技術(例えば、ATM[17]かFrame Relay)に特定の詳細を明らかにする仲間ドキュメントの基礎を形成します。 NBMAアーキテクチャの上のIPv6はまた、'近道'NBMA推進経路の設立をサポートしている間(ダイナミックに合図されたNBMAリンクが利用可能であるときに)、IPv6 Neighborディスカバリープロトコルの従来のホストサイド手術を許します。
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ネットワークでインタフェースの間の多点呼び出しへのダイナミックに管理されたポイント・ツー・ポイントとポイントの使用に焦点を合わせます。 これらはドキュメントの残りで一般的に「SVCs」と呼ばれるでしょう。 また、呼び出しを指す行政上構成されたポイントの使用について議論するでしょう。 そのような呼び出しは一般的に「PVCs」と呼ばれるでしょう。 文脈によって、どちらかが"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.
NBMAプロトコルの上のこのアーキテクチャと前のIPの主要な違いは、IPv6 Neighborがディスカバリーであるとサポートするためのそのメカニズムです。
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.
イーサネットARPから始まって、IPv4世界は'リンクレイヤ'で補助のプロトコル操作の操作によった解決を扱うアプローチを発展しました。(RFC826[14])。 ARPがSMDSの上でNBMA(非Broadcast、Multiple Access)ネットワークの世界では、IPv4に適用された、(ATMの上のRFC1209[13])とIPv4、(RFC1577[3])。 より最近、IONワーキンググループはNHRPを開発しました。(次のHop Resolutionプロトコル[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
Neighborディスカバリー[7]として知られているプロトコルに多くのタスクを結合するためにchosingして、遠くでリンクレイヤの特定のアプローチからわたるように選ばれたIPv6開発者は、多くのリンクレイヤ技術の向こう側に特定されないことを意図しました。 主要な仮定、Neighborディスカバリーの実際のプロトコルによって作られて、それはaの基礎となるリンク技術です。
Armitage, et. al. Standards Track [Page 2] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[2ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
与えられたIPインタフェースはネイティブのマルチキャスティングができます。 これは、ほとんどのNBMAネットワーク・サービスに関して特に本当でなく、通常、必要なサービスを見習うために集合プロトコルを必要とします。 (火星プロトコル(RFC2022[5])はそのような集合プロトコルに関する例です。) このドキュメントは、使用のためにIPv6 Neighborディスカバリーを支持して火星プロトコルを増大して、最適化します、ATMネットワークを超えてRFC2022の適用性を一般化して。
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近道は、NBMA雲(例えば、ルータホップとNBMA VCs)の上でIPの中でリソースの消費を最小にするためのメカニズムです。
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.
IPが要求(SVCsか機能的な同等物)のダイナミックな設立をサポートすることができるNBMAネットワークの向こう側に配布されるときはいつも、NBMA近道がサポートされるのは、重要です。 NBMAの上のIPv6に関しては、近道の発見と管理はNeighborディスカバリーとNHRPの混合物を通して達成されます。
1.3 Key components of the IPv6 over NBMA architecture.
1.3 NBMAアーキテクチャの上のIPv6の主要な部品。
1.3.1 NBMA networks providing PVC support.
1.3.1 NBMAはPVCがサポートする提供をネットワークでつなぎます。
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つのノードを接続するでしょう、そして、Neighborディスカバリーと他のIPv6の特徴の使用は限られています。 IPv6/NBMAインタフェースには、1人の隣人しか各Linkにいません。 火星とNHRPプロトコルは必要ではありません、マルチキャストと放送操作がNBMAの平らなユニキャスト操作まで崩れるので。 ダイナミックに発見された近道はサポートされません。
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:
実際は、トークン世代SHALLについてカプセル化について詳述して、リンクします。仲間ドキュメントで、特定のNBMA技術をカバーしながら、カバーされています。 それら、SHALLは以下のガイドラインに従います:
Both unicast and multicast IPv6 packets SHALL be transmitted over
PVC links using the encapsulation described in section 4.4.1.
ユニキャストとマルチキャストIPv6パケットSHALLの両方、セクション4.4で.1に説明されたカプセル化を使用することでPVCリンクの上に伝えられてください。
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リンクSHALLのためにトークンを連結してください。説明されるとして、セクション5で構成されてください。 インタフェーストークンはPVCリンクの上の2つのノードの間でユニークであるだけでよいです。
Armitage, et. al. Standards Track [Page 3] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[3ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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接続(例えば、Inverse Neighborディスカバリー)における使用のために一般的使用のために開発されるかもしれないものについて議定書の中で述べるNeighborに拡張子の使用を禁止しないのを強制しません。
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を示すためにOPTIONALアプローチとしてNBMAメカニズムの上でPPPとPPPの上でさらに、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 NBMAはSVCがサポートする提供をネットワークでつなぎます。
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 Neighbor(隣人はIPv6インタフェースの地方のIPv6 Linkのメンバーにとってメッセージマルチキャストの使用で発見される)はモデル化します。 - 基本的なNBMAネットワークによって提供された多点呼び出しを使用することで一般的なマルチキャストのエミュレーションを許容する火星モデル。 - NHRPは、NBMAを捜し出すためにIPの位相的な意味で論理的に遠方でそうするIPインタフェースのアイデンティティを修理します。 - '流れ'としての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環境(Logical IP SubnetへのIPv4IP Subnetの一般化にRFC1209と次にRFC1577で類似の)で「論理的なリンク」(LL)に一般化されます。
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インタフェースは一般的なイントラ論理的なLinkマルチキャスティングにRFC2022(火星)を利用します。 火星自体は、Logical Linkの中で発見メッセージを最適に分配するのに使用されます。
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.
適切に構成されると、Logical Linkからの出口ルータはそれを通した近道の接続の利益を得るかもしれない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質問を開始します。
Armitage, et. al. Standards Track [Page 4] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[4ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
そして、流れの目的地が一時的なNeighborであると認識して、元々質問しているルータはIPソースにRedirectを発行します。
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.
また、パケット流動の存在にかかわらず、近道の発見についてホストによって開始された引き金となることは送信元ホストのデフォルトルータに送られた特定のNeighbor Solicitationsを通してサポートされます。
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スタックは、それぞれのリンクレイヤ技術のために別々のノースダコタがプロトコルであると実装しません。
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の目的地がそれら自身のダイナミックなインタフェース負荷分割法を実行する能力であるとサポートします。
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アドレス」と呼ばれるでしょう。 (このアーキテクチャをSMDSネットワークに適用するとき、ATMネットワーク、またはE.164番号へのこのアーキテクチャを適用するとき、例はATM End System Address、AESAでしょう。)
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.
いったん設立されると1つの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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[16]で説明されるように本書では解釈されることであるべきですか?
Armitage, et. al. Standards Track [Page 5] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[5ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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 Linkの一般化について説明して、Transient Neighborの概念を紹介します。 セクション3は、Transientネイバーズを発見するためにLogical Link、規則、およびメカニズムの中にノースダコタメッセージの効率的な分配のための火星プロトコルに変更を説明します。 セクション4はIPv6/NBMAインタフェース初期化、パケット、コントロールメッセージカプセル化、およびSVC管理のための規則を支配する基本的なルールをカバーします。 セクション5は、Interface Tokens、Link Layer Address Option、およびLink Localアドレスを構成するために総則について説明します。 セクション6はドキュメントの標準のセクションを結論づけます。 付録AはIpv6 Neighborディスカバリーの操作に関する何らかの非標準の説明文を提供します。 付録BはLogical Linkの周りでNeighborディスカバリーメッセージのマルチキャスティングを見習ういくつかのサブ最適解について説明します。 付録Cは、近道の抑圧について議論して、簡潔に流れに関する流れ検出とマッピングとの今後の関係について異なったサービスの品質のSVCsに調査します。
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はオンリンクとオフリンクの概念を含んでいます。 ネイバーズはリンクであると考えられて、したがってリンクレイヤアドレスがNeighborディスカバリーを使用することで見つけられるかもしれないそれらのノードです。 ノースダコタテキストとの用語定義からの借入れ:
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つでカバーされている、--隣接しているルータがRedirectメッセージの目標としてアドレスを指定する、--あて先アドレスのためにNeighbor Advertisementメッセージを受け取る、--アドレスからNeighborディスカバリーメッセージを受け取ります。
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つを通してアクセスしやすいだけであると考えられます。
Armitage, et. al. Standards Track [Page 6] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[6ページ]RFC2491IPv6は1999年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).
大体同じようなやり方でIPv4場合における'サブネット'の感覚を複雑にしたようにNBMA環境は単語('リンクする')の意味を複雑にします。 IPv4に関しては、これはLogical IP Subnet(LIS)の定義を必要としました--同じルーティング接頭語(ネットワークとサブネットワークマスク)を共有する行政上組み立てられたセットのホスト。
This document considers the IPv6 analog to be a Logical Link (LL).
このドキュメントは、IPv6アナログがLogical Link(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インタフェースの始発の隣人です、そして、各インタフェースのLink Localアドレスはこのセットの中で特有である必要があるだけです。
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'.
Redirectsなどのように、お節介なメッセージの操作で発見されたネイバーズは'一時的なネイバーズ'と呼ばれます。
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.
このドキュメントはLogical Link(イントラ-LL)の中の隣人とLLを超えた隣人発見の区別を(相互LL)にします。 そして、目標が両方を許容することである、相互、NBMAのためにホストサイドIPv6スタックへの変化に全くかかわらないイントラ-LL隣人発見は連結します。
Note that section 1.3.1 applies when the NBMA network is being used to provide only configured point to point (PVC) service.
NBMAネットワークが構成されたポイント・ツー・ポイント(PVC)サービスだけを提供するのに使用されているとき、セクション1.3.1が適用されることに注意してください。
Armitage, et. al. Standards Track [Page 7] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[7ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
3.1 Intra-LL - ND over emulated multicast.
3.1 イントラ-LL--見習われたマルチキャストの上のノースダコタ。
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.
ノースダコタの基本型は、リンクレイヤインタフェースがマルチキャストIP送付先アドレスにICMPv6パケットを送って何か有意義なことをやると仮定します。 (IPv6は、マルチキャスティングがインターネットのサービスの不可欠の部分であると仮定します。) このドキュメントは、マルチキャストサポートがRFC2022(火星)[5]サービス(ATMに加えた他のNBMA技術の上の使用のために、一般化される)を利用することで提供されると仮定します。 IPv6 LLはIPv4 LISが火星Clusterを直接IPv4に写像する同じように火星Clusterを直接IPv6に写像します。
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パケットを少しも特別番組(NBMAの特定の処理)のないIPv6/NBMAドライバーまで通過できなければならないということです。 そして、NeighborディスカバリーとRouterディスカバリーメッセージを分配するための発症機序は予想されるように動作します。
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 このドキュメントによる順応に使用されるどんな火星でも必要な状態でSHALLがある追加機能性について説明します。 これらの追加のバックグラウンド議論をAppendix Bに提供します。
3.1.1 Mandatory augmented MARS and MARS Client behavior.
3.1.1 義務的な増大している火星と火星Clientの振舞い。
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.
セクション4.1、およびSHALLで説明される火星Clusterメンバーがセクション4.4.2で説明されるようにあるクラスの出発しているIPv6パケットを直接地元の火星に送るとき、IPv6/NBMAはSHALLレジスタを連結します。
The MARS itself SHALL then re-transmit these packets according to the following rules:
次に、以下の規則に従って、火星SHALL自身はこれらのパケットを再送します:
- 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.
- 火星が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.
- そして、火星は、すべてのグループのメンバーが現在火星に開かれているPt PtコントロールVCを持っているかどうか確認するためにチェックします。 そうだとすれば、火星は直接既存のPt Pt VCsの上のそれぞれのグループのメンバーにデータ・パケットのコピーを送ります。
- 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か発見されたグループのメンバーの以上が開いているPt Pt VCを火星に持っていないか、またはメンバーが記載したグループが全くなければ、代わりに出ているClusterControlVCをパケットに送ります。 既存(もしあれば)のPt Pt VCsの上にパケットのコピーを全く送りません。
Armitage, et. al. Standards Track [Page 8] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[8ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
3.2 Inter-LL - Redirects, and their generation.
3.2相互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ルーティング限界で切り離されるソース/目的地組の間に存在するかもしれないので、近道の接続は正当です。 近道はTransientネイバーズの間で作成されます。
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.
作成一時的な隣人のキーはRedirectメッセージです。(セクション8[7])。 IPv6は与えられた目的地への、より良い'最初のホップ'があることをLLのメンバーにルータを知らせさせます。(セクション8.2[7])。 広告自体はRouter Redirectメッセージを通して達成されます。メッセージはこのより良いホップのリンクレイヤアドレスを運ぶかもしれません。
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).
伝わっているホストは現在Redirectが言及するIPの目的地へのデフォルトルータとして機能しているルータからRouter Redirectsを聞くだけです。 Redirectが到着するなら、それは、より良い最初のホップを与えられた目的地に示して、より良い最初のホップ、送信元ホストの関連Neighbor Cacheエントリーをアップデートして、可到達性がSTALEにセットしたので、使用するリンクレイヤ(NBMA)アドレスを供給します。 キャッシュをアップデートするのは、新しい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はリモートLLsのIPv6目標のためのマッピングを発見するためにNHRPの使用について議論します。
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ルーティング限界の縁を越えます。
Armitage, et. al. Standards Track [Page 9] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[9ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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).
SHALLは直接付属しているホスト(ルータのインタフェースの1つのLL地方の範囲の中にいるホスト)から発する流れを追跡するだけです。
SHALL NOT use IP packets arriving from another router to
trigger the generation of a Router Redirect.
SHALL NOTはRouter Redirectの世代の引き金となるように別のルータから到着するIPパケットを使用します。
SHALL only consider IPv6 packets with FlowID of zero for the
purposes of flow detection as defined in this section.
SHALLは流れ検出の目的のためにこのセクションで定義されるようにゼロのFlowIDがあるIPv6パケットを考えるだけです。
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.
SHALLは適当な流れが検出されるとき、最初に、より良いホップを確かめるためにセクション3.2.3で説明されるようにNHRPを利用して、Router Redirectの情報の広告を出します。
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'.
OPTIONAL流動が検出の振舞いであるとサポートする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の使用の後ろで原理について議論します。
3.2.2 Host Triggered Redirection
3.2.2 ホストの引き起こされたリダイレクション
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が、特定のNeighbor Solicitationメッセージがオフリンクアドレスの解決を求める要求としてホストで送ったと認めるこのドキュメントに従って、向け直します。
To perform a host-triggered redirect, a source host SHALL:
再直接のホストによって引き起こされたaソースを実行するには、SHALLを接待してください:
Create a Neighbor Solicitation message referring to the off-LL
destination (target) for which a shortcut is desired
近道が望まれているオフLLの目的地(目標)について言及するNeighbor Solicitationメッセージを作成してください。
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メッセージを扱ってください。
Armitage, et. al. Standards Track [Page 10] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[10ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
Use the standard ND hop limit of 255 to ensure the NS won't be
discarded by the router.
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.
ルータSHALLは、aとしての近道の限界オプションがあるNSがaのために要求するユニキャストがホストによって引き起こされると再直接で考えます。 しかしながら、実際の近道の発見はIPv6ルータのためのOPTIONALです。
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.
近道の発見がサポートされないとき、ルータSHALLはルータ自体が最も良い'近道'であると認識しながらRedirectメッセージを構成して、請求しているホストにそれを返します。
If shortcut discovery is to be supported, the router's response SHALL be:
発見は近道であるならサポートされることであり、ルータの応答はSHALLです。いてください:
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 Requestを組み立てて、送ります。 捨てられて、オリジナルのNSはSHOULDを通信させます。
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 Replyを受け取ると、ルータSHALLは一時的な隣人のIPv6アドレスを含むRedirectメッセージを構成します、そして、NBMAリンクレイヤアドレスはNHRP解決プロセスで戻りました。
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.
結果として起こるRedirectはSHALLを通信させて、次に、送信元ホストに伝わって戻ってください。 Redirectメッセージが受信されているとき、ソースホストSHALLはNeighborとDestinationキャッシュをアップデートします。
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であると考えられます。 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はルータ自体が最も良い'近道'であると認識しながらRedirectメッセージを構成して、請求しているホストにそれを返します。
Armitage, et. al. Standards Track [Page 11] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[11ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
いったん流れ検出が起こったか、またはホスト引き金が検出されると、ルータSHALLは、より良い最初のホップの平らなアドレス・マッピングをリンクするためにIPv6を証明するのにNHSでNHSモードにNHRPを使用します。
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).
- 他のNHSes(ルータ)から入って来るNHRP RequestsとRepliesを分析してください。
- Forward NHRP Requests towards an NHS that is topologically
closer to the IPv6 target.
- NHSに向かったNHRP RequestsをIPv6目標の、より近くに位相的に送ってください。
- Forward NHRP Replies towards an NHS that is topologically closer
to the requester.
- NHSに向かったNHRP Repliesをリクエスタの、より近くに位相的に送ってください。
- Perform syntax translation between Neighbor Solicitations and
outbound NHRP Requests.
- Neighbor Solicitationsと外国行きのNHRP Requestsの間の構文翻訳を実行してください。
- Perform syntax translation between inbound NHRP Replies and
Redirects.
- 本国行きのNHRP RepliesとRedirectsの間の構文翻訳を実行してください。
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 Requestでの解決のための目標として使用されます。 そして、ルータは次の最も近いNHSにこのNHRP Requestを送ります。 Requestがそれがインタフェースの1つのリンク地方の範囲の中にあるとIP目標に信じているNHSに達するまで、プロセスは持続します(正常なNHRPのためにそうするように)。 (これはただ一つのルータの中に潜在的に起こるかもしれません。)
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
最後のホップルータSHALLは指定された目標が届いているインタフェースへの隣人キャッシュに含まれたマッピング情報からNHRP Requestを決議します。 Neighborキャッシュにはどんな適切なエントリーもないか、または目的地が現在手が届かないと考えられるなら、最後のホップルータSHALLは局所界面にNeighborディスカバリーを実行して、結果として起こる答えからNHRP Replyを造ります。 (NHRP Requestが流れ検出のため起因した場合では、ホップごとに既にあるに違いないことに注意してください。
Armitage, et. al. Standards Track [Page 12] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[12ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.)
最後のホップルータに目標に向かって直面しているパケットの流れ。 この典型的な場合では、Neighborキャッシュは既に必要な情報を持つでしょう。)
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 ReplyはNHRP Requestの源に伝播して戻されます、正常な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 Replyの復帰は以下のイベントをもたらします:
A Redirect is constructed using the IPv6/NBMA mapping carried in
the NHRP Reply.
Redirectは、NHRP Replyで運ばれた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).
Redirectは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.
ルータによって送られたどんなRedirectメッセージも[7]で説明されたすべての規則に従わなければならないので、パケットは受信ホストによって適切に有効にされます。 明確に、ICMP Target Addressは結果として起こるショートカットの目標があて先ホストであるならオリジナルのメッセージでICMP Destination Addressと同じでなければなりません。 ショートカットの目標が出口ルータであるなら、ICMP Target AddressはルータのNBMAインタフェースが付けているNBMA雲にユニークな出口ルータのLink Localアドレスであるに違いありません。
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.
また、出口ルータが次に送信元ホストを向け直すかもしれないことに注意してください。 そうするために、RedirectメッセージのLink Local ICMP Source AddressはオリジナルのRedirectメッセージのLink Local ICMP Target Addressと同じでなければなりません。
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.
目標ホストが最初にIPトラフィックの流れを受け入れたとき、NHRP Replyを組み立てるルータがそうするというNBMAアドレスを使用するメモが目標ホストで戻りました。 これはNeighborディスカバリーの役に立つ特徴を保有します--目的地インタフェース負荷分割法。
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/ノースダコタのパケット翻訳は統治されます。
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仕様[8]のセクション5でパケット書式仕様を増大させることになっています、IPv6/NBMAアーキテクチャによって明確に利用されたそれらのパケット分野をカバーしていて。
Armitage, et. al. Standards Track [Page 13] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[13ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
[8]の規則に従って、NHRPメッセージを構成して、送ります。 ar$afnなどのNBMAの技術の特定の分野の値、ar$pro.type、ar$pro.snap、およびリンクレイヤアドレス形式はNBMA特有の仲間ドキュメントで定義されます。 ソース、いつもNHRPメッセージの一般的ヘッダーかCIEの目的地かクライアントプロトコルアドレスは長さ16のIPv6アドレスです。
When constructing an host-triggered NHRP resolution request in response to a Neighbor Solicitation:
ホストによって引き起こされたNHRP解決を構成するときにはNeighbor Solicitationに対応して以下を要求してください。
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.
要求SHOULDにはQとSビットがあるというNHRP解決の一般的なヘッダーのFlags分野はセットしました。
The U bit SHOULD be set. NBMA and protocol source addresses are
those of the router constructing the request.
UはSHOULDに噛み付きました。用意ができています。 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 SHALL NOT、指定されてください。
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はNBMA特有の仲間ドキュメントで指定された0か値であるかもしれません。
A successful NHRP resolution reply for a host-triggered shortcut attempt is translated into an IPv6 Redirect message as follows:
ホストによって引き起こされた近道の試みのためのうまくいっているNHRP解決回答は以下のIPv6 Redirectメッセージに翻訳されます:
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分野: リンクローカルアドレスがルータのものに割り当てたこのメッセージが送られるソースAddressは連結します。 引き金となるNS Hop Limit255のものの目的地Address IPv6 Source Address
Armitage, et. al. Standards Track [Page 14] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[14ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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分野: NS(これはNHRP DestinationプロトコルAddressに同等である)目標リンクレイヤアドレスNHRP Client NBMA Addressの引き金となる目標Address NHRP ClientプロトコルAddress Destination Address Target
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/ノースダコタの翻訳のときに効き目がなくて、IPv6にNHRPメッセージで使用されるかもしれません。
3.2.3.2 NHRP Purge rules.
3.2.3.2 NHRP Purgeは統治します。
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 Replyを無効にする変化が検出されるとき(これはトポロジー変化、または落ちるか、またはアイデンティティを変える目標ホストを含むかもしれません)、パージはNHRPによって生成されます。 新たに掃除されていることに基づいてどんなIPv6近道も以前に、情報SHOULDを設立しました。取りこわします。
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.
ルータSHALLはそれらがNeighbor AdvertisementsかRouter Redirectsを発行したNHRPキャッシュエントリーの動向をおさえます。 NHRP Purgeが受け取られているなら、それは以前にローカル・ホストに発行された情報を無効にします、とルータSHALLが影響を受けるIPv6目標のための新しい最も良い次のホップとしてルータ自体を指定するRouter Redirectを発行します。
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.
ルータSHALLは以前にNHRP Replyを生成するのに使用されたNeighborキャッシュエントリーの動向をおさえます。 そんなに元々ルータに向かって送られるNHRP PurgeのどんなそのようなNeighborキャッシュエントリーSHALL結果の満期もNHRP Replyを要求しました。
3.3. Neighbor Unreachability Detection.
3.3. 隣人Unreachability検出。
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)の目的のために送られた隣人Solicitationsは問題のNeighborへのユニキャストです、既にそのNeighborに開かれているVCを使用して。 これは、NUDに関する限り、Transient NeighborがOn-LL Neighborから区別がつかないと示唆します。
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.
写しAddress Detectionがリンク地方の範囲の中で必要であるだけです。この場合、範囲はLL地方の範囲です。 LLの範囲の外に一時的なネイバーズがあります。 どんな特定の相互作用も近道を確立するためのメカニズムと写しリンクローカルのアドレスの検出のためのメカニズムの間で必要ではありません。
Armitage, et. al. Standards Track [Page 15] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[15ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
このセクションはLogical Linkで実行基本機能(送受信データなどの)のためのノード手術について説明します。 Neighborディスカバリーなどの様々なIPv6プロトコルの操作へのこれらの基本機能の適用はAppendix 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.
ポイント・ツー・ポイントとポイントを多点SVCsに供給するのに使用されると、このセクションの大部分がNBMAネットワークだけに当てはまります。 セクション7はNBMAネットワークがポイント・ツー・ポイントだけPVCsを供給するのに使用されているケースについて論じます。
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インタフェースは最初に、Logical Linkを接合しなければなりません。
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ドライバーSHALLはLogical Linkに関連している火星にPt Pt VCを設立して、Clusterメンバー[5]として登録します。 ノードのIPv6/NBMAインタフェースは、そしてLLのメンバーであり、ClusterメンバーID(CMI)を割り当てさせて、IPv6とIPv6がノースダコタの操作であるとサポートし始めることができます。
If the node is a host or router starting up it SHALL issue a single group MARS_JOIN for the following groups:
ノードがそれを立ち上げるホストかルータであるなら、SHALLは以下のグループのために_の単一のグループ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.
- リンク地方の範囲がある派生しているSolicited-ノードアドレス(es)。 - リンク地方の範囲があるAll-ノードアドレス。 - 他の構成されたマルチキャストは少なくともリンク地方の範囲で分類されます。
If the node is a router it SHALL additionally issue:
ノードであるなら、ルータはそれです。SHALLはさらに、以下を発行します。
- 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-ルータアドレスのための_の単一のグループJOIN火星。 - IPv6マルチキャストアドレス(リンク地方であるより大きい範囲がある)の範囲への無差別なレセプションがそうであるブロック_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.
カプセル化メカニズム、キーフィールド値、火星コントロールは定義されたコネが特定のNBMAネットワーク技術に特定の仲間ドキュメントであったならSHALLを通信させます。
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 LayerからJoinLocalGroup要求を得るとき、このセクションはノードの振舞いについて説明します。 この振舞いがどう達成されるかに関する詳細は実装特有になるでしょう。
Armitage, et. al. Standards Track [Page 16] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[16ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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ドライバーSHALLはJOINがこのアドレスを火星に登録するよう要求する_の適切な単一のグループ火星を送ります。
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 Layerから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ドライバーSHALLはLEAVEが「反-レジスタ」に要求する_の適切な単一のグループ火星に火星があるこのアドレスを送ります。
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パケットSHALLは以下のLLC/SNAPヘッダーと共にカプセル化されて、VCを移動しました。
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
(LLC) (OUI) (PID)
[0xAA-AA-03][0×00 00-00][0×86DD][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ネットワークのために、カプセル化、代替手段は、SHALLがNBMA特有の仲間ドキュメントで指定されると裁決します。
Armitage, et. al. Standards Track [Page 17] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[17ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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もパケットのための次のホップアドレスのために存在していないなら、SHALLが電話するノードは次のホップの目的地に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.
次のホップ目的地ノードへの呼び出しが送付ノードに失敗するなら、SHALLは呼び出しセットアップの引き金となったパケットを捨てます。 次のホップの目的地にVCを作成しないと、NUDを通してIPv6 Network Layerで検出されて、扱われるでしょう。
At this time no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address.
このとき、規則は全くパケットの送付先アドレスより多いものは何も使用することで外国行きのパケットをVCsに写像するのに指定されません。
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カプセル化が通常使用された(例えば、ATMかSMDS)マルチキャストパケットSHALLであるNBMAネットワークのために:
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
packet]
(LLC) (OUI) (PID) (mars encaps)
[0xAA-AA-03][0×00 00-5E][0×00-01][pkt$cmi][0x86DD][IPv6パケット](LLC)(OUI)(PID)(encapsを損ないます)
The IPv6/NBMA driver's Cluster Member ID SHALL be copied into
the 2 octet pkt$cmi field prior to transmission.
IPv6/NBMAドライバーのClusterメンバーID SHALL、トランスミッションの前に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ネットワークのために、カプセル化、代替手段は、SHALLがNBMA特有の仲間ドキュメントで指定されると裁決します。 何らかのメカニズム、IPv6/NBMAドライバーのClusterメンバーID SHALLを運ぶのに、提供してください。
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:
パケットの目的地は以下のマルチキャストアドレスの1つであり、それはSHALLです。火星へのIPv6/NBMAドライバーのダイレクトPt Pt VCの上に送ってください:
- 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.
- リンク地方の範囲があるSolicited-ノードアドレス。 - リンク地方の範囲があるAll-ノードアドレス。 - リンク地方の範囲があるAll-ルータアドレス。 - DHCP-v6リレーかサーバマルチキャストアドレス。
Armitage, et. al. Standards Track [Page 18] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[18ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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 SHALLはセクション3.1.1で説明されるようにIPv6パケットを再配付します。 (火星へのVCが何らかの理由で調節されていた状態で使用されていないなら、パケットを火星に送る前に、それを復職させなければなりません。)
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.
パケットの目的地がアドレスであるなら、いかなる他のも普通の火星クライアントメカニズムは、パケットが送られることになっているPt-mpt VCを選択する、そして/または、証明するのにIPv6/NBMAドライバーによって使用されます。
At this time no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address.
このとき、規則は全くパケットの送付先アドレスより多いものは何も使用することで外国行きのパケットをVCsに写像するのに指定されません。
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.1SHALLに反-カプセル化されるように示して、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.
パケットは、地元のIPv6/NBMAドライバーの自己のCMIと比べて、SHALLがそれらのpkt$cmiにさばかせるセクション4.4.2で指定されたカプセル化を使用することで受信されました。 ヘッダーのpkt$cmiがローカルのCMIに合っているなら、下げられて、パケットSHALLは静かにそうです。 さもなければ、パケットSHALLは反-カプセル化されて、IPv6層に通りました。 そして、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ネットワークのために、代替手段は、SHALLがNBMA特有の仲間ドキュメントで指定されると裁決します。
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ドライバーSHALL NOTは、カプセル化がユニキャストパケットのために定義されている状態で到着するマルチキャストIPv6パケットを無視するのを試みて、カプセル化がマルチキャストパケットのために定義されている状態で到着するユニキャストIPv6パケットを無視するのを試みます。
4.6. VC Setup and release for unicast data.
4.6. ユニキャストデータのためのVC Setupとリリース。
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.
ユニキャストVCsは別々にマルチキャストVCsから維持されます。 マルチキャストVCsのセットアップとメインテナンスはそれぞれのIPv6/NBMAドライバー[5]という火星クライアントによって扱われます。 ユニキャストIPv6トラフィックのためのPt Pt VCsのセットアップとメインテナンスだけがここで説明されるでしょう。 ベストエフォート型ユニキャストだけVCsは考えられます。 このドキュメントの範囲の外に他のクラスのサービスのためのVCsの作成があります。
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目標にNeighborディスカバリーを実行するでしょう。 次に送付者がユニキャストパケットを送るのに使用できるリンク層のアドレスにIPv6送付先アドレスに変えるためにこれをします。
Armitage, et. al. Standards Track [Page 19] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[19ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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のNeighbor Solicitation/広告交換と最後の設立を含んでいる非規範的で、描写的であるテキストを含んでいます。
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.
Redirectメッセージ(同じLLの上のノードへの再直接のaかLLの外のノードへの再直接の近道のどちらか)は新しいPt Pt VCを新しい受信ノードに作成する発信(向け直される)ノードをもたらします。RedirectメッセージSHALLは新しい受信IPv6/NBMAインタフェースのリンクレイヤ(NBMA)アドレスを含んでいます。 新しい受信ノードがNBMAネットワークに位置しているところで向け直されたノードはタッチしません。 1つが以前に存在しないなら、向け直されたノードは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.
向け直す、単方向はそうです。 ソースがaに再直接で反応した後にさえ、目的地は、古い経路の向け直されたノードにIPv6パケットを送り返し続けるでしょう。 目的地ノードにはNeighborディスカバリーがないとき新しいVCのもう一方の端のIPv6アドレスを決定する方法が全くないので、これは起こります。 その結果、接続の両端で新しいVCを使用することで結果ではなく、意志を向け直します。 IPv6が向け直す、対称のリダイレクションを提供することを意図しません。 非向け直されたノードが結局再直接でaを受けるなら、それは、既存のVCを目標ノードに発見して、新しいVCを作成するよりむしろそれを使用するかもしれません。
It is desirable that VCs are released when no longer needed.
もう必要でないとVCsがリリースされるのは、望ましいです。
An IPv6/NBMA driver SHALL release any VC that has been idle for 20
minutes.
20分間のSHALLがどんな使用されていないVCもリリースするIPv6/NBMAドライバー。
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.
NeighborかDestinationキャッシュエントリーが掃除されるなら、どんなVCsもリリースされる掃除されたエントリー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.
Neighborキャッシュにおけるエントリーの状態がSTALEに設定されるなら、どんなVCsもリリースされる聞き古したエントリーSHOULDと交際しました。
4.7 NBMA SVC Signaling Support and MTU issues.
4.7 NBMA SVC Signaling Supportと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.
指定されていて、仲間ドキュメントでPt Ptと異なったNBMAネットワークのためのPt-mpt SVCs SHALLの設立と分解に合図するためのメカニズム。
Armitage, et. al. Standards Track [Page 20] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[20ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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にあるかを知らないので、ドライバーSHALLはVCレベルで許容できるMTUsを交渉するためにNBMA特有のメカニズムを実装します。 これらのメカニズム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を設立する可能性を考える必要はありません。)
5. Interface Tokens, Link Layer Address Options, Link-Local Addresses
5. インタフェーストークン、リンクレイヤアドレスオプション、リンクローカルのアドレス
5.1 Interface Tokens
5.1 インタフェーストークン
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にアドレスを自動構成したかからのインタフェーストークンがなければなりません。 このインタフェーストークンは、状態がないアドレス構成が使用されているとき、写しアドレスの作成を防ぐためにLogical Linkの中でユニークでなければなりません。
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つのインタフェースが別のホストトークンを選ばなければなりません。 すべての実装が、オペレータが1LLあたり1個のベースで手動でインタフェーストークンを変えるのを許容するためにインタフェーストークンの手動の構成をサポートしなければなりません。 オペレータは、手動で写しアドレスを排除するのを除いた理由にインタフェーストークンを設定するのを選ぶかもしれません。
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]。
5.1.1 Single Logical Links on a Single NBMA Interface
5.1.1 単一のNBMAインタフェースの単一の論理的なリンク
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ネットワークに特定の状態で指定されていて、インタフェーストークンがSHALLであると生成するための正確なメカニズム。
5.1.2 Multiple Logical Links on a Single NBMA Interface
5.1.2 単一の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インタフェースをサポートするかもしれないので、2つの別々のシナリオが可能です:
- A single host with separate IPv6/NBMA interfaces onto a number
of independent Logical Links.
- 別々のIPv6/NBMAの独身のホストは多くの独立しているLogicalリンクスに連結します。
Armitage, et. al. Standards Track [Page 21] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[21ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
- 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.
- 異なったか一般的なLLsに関連している. 各vhostが自由に設立できる一般的なNBMAドライバーを共有している2'事実上のホスト'(vhosts)IPv6/NBMAインタフェースのセット。 しかしながら、vhostsは普通のホストと同じ要件によって縛られます--同じLLへのいいえtwo、インタフェースは同じインタフェーストークンを共有できます。
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に関連しているので、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インタフェース、独立していてユニークな識別子SHALLの上のインタフェースであるとサポートするときには生成されて、それぞれの仮想のNBMAインタフェースはユニークなIPv6/NBMAインタフェーストークンの工事を可能にしてください。 仲間ドキュメントでそれぞれのNBMAネットワークに特定の状態で指定されていて、インタフェーストークンがSHALLであると生成するための正確なメカニズム。
5.2 Link Layer Address Options
5.2 リンクレイヤアドレスオプション
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つのオプションのための形式は火星[5]とNHRP[8]眼鏡から適合させられます。 それ、SHALL、あります:
[Type][Length][NTL][STL][..NBMA Number..][..NBMA
Subaddress..]
| Fixed || Link layer address
|
[タイプします] [長さ] [NTL] [STL] [..NBMA番号] [..NBMA Subaddress。] | 修理されています。|| リンクレイヤアドレス|
[Type] is a one octet field.
[タイプ]は1つの八重奏分野です。
1 for Source link-layer address.
2 for Target link-layer address.
1 Sourceリンクレイヤアドレスのために。 2 Targetリンクレイヤアドレスのために。
[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つの八重奏の倍数であることを保証するためにオプションの終わりに加えられます。
Armitage, et. al. Standards Track [Page 22] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[22ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
[NTL] is a one octet 'Number Type & Length' field.
[NTL]は1つの八重奏'数のType&Length'分野です。
[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 Number]は可変長フィールドです。 それはいつも存在しています。 これはプライマリ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 subaddressを含んでいます。
If the [NBMA Subaddress] is not present, the option ends after the [NBMA Number] ( and any additional padding for 8 byte alignment).
[NBMA Subaddress]が存在していないなら、オプションは[NBMA Number](そして、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 Number]、および[NBMA Subaddress]分野のコンテンツと解釈は各NBMAネットワーク、およびSHALLに特定です。仲間ドキュメントでは、指定されます。
5.3 Link-Local Addresses
5.3 リンクローカルのアドレス
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 |
+----------+-----------------------+----------------------------+
10ビット54ビット64ビット+----------+-----------------------+----------------------------+ |1111111010| (ゼロ) | インタフェーストークン| +----------+-----------------------+----------------------------+
6. Conclusion and Open Issues
6. 結論と未解決の問題
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).
このドキュメントはIPv6のためにNBMAネットワークの上で一般的なアーキテクチャについて説明します。 それは様々な特定のNBMA技術(ATMかFrame Relayなどの)のための詳細を明らかにする補助の仲間ドキュメントの基礎を形成します。 NBMAアーキテクチャの上のIPv6はまた、'近道'NBMA推進経路の設立をサポートしている間(ダイナミックに合図されたNBMAリンクが利用可能であるときに)、IPv6 Neighborディスカバリープロトコルの従来のホストサイド手術を許します。
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サブネット」へのanalagous方法で「論理的なリンク」に一般化されます。 火星プロトコルは、IPv6パケットのLogical Linkマルチキャスティング、およびディスカバリーメッセージの分配を比較的効率的なイントラに提供するのに増大して、使用されます。 平らな経路がルータを通してサポートされる近道のNBMAが流れ検出を基礎づけたか、またはホストは明白な要求を溯源しました。 隣人ディスカバリーはすべてのイントラ-LLコントロールに変更なしで使用されます(NBMA近道の発見の開始を含んでいて)。 ルータNHRPへのルータは、ソースのLogical Linkの外の近道の目標のためのIPv6/NBMAアドレス・マッピングを得るのに使用されます。
Armitage, et. al. Standards Track [Page 23] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[23ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
7. Security Considerations
7. セキュリティ問題
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、ノースダコタ火星)によって、したがって、これらのプロトコルに固有のすべての軍事的脅威を受けることがあります。 ベースプロトコルのいずれも容認できないほど不安定であると考えられるドメインでこのアーキテクチャを使用するべきではありません。 しかしながら、このプロトコル自体は追加担保の脅威を導入しません。
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のために変更なしで動作するでしょう。 これはNeighborディスカバリープロトコルとIPv6データ・パケットの交換の両方のための認証と暗号化の両方を含んでいます。 火星プロトコルはRFC2022によって提供されたセキュリティを影響しないか、または増大させない方法で変更されます。
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.
エリックNordmarkは1996年3月のIETFの間、個人的なメールによるノースダコタRedirectメッセージの有用性を確認しました。 6月、1996年12月のIETFの間の様々なION WGメンバーとの議論は、ここで説明されたアーキテクチャを固めるのを助けました。 IPv6/NBMAへのグレンビルアーミテージのオリジナルの作業はBellcoreで使われている間、起こりました。 イーサネットの上のIPv6の上のマット・クロフォードのメモからセクション5のElementsを借りました。
Armitage, et. al. Standards Track [Page 24] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[24ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
Authors' Addresses
作者のアドレス
Grenville Armitage Bell Laboratories, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA
グレンビルアーミテージベル研究所、ルーセントテクノロジーズ101Crawfordsコーナー道路Holmdel、ニュージャージー07733米国
EMail: gja@lucent.com
メール: gja@lucent.com
Peter Schulter Bright Tiger Technologies 125 Nagog Park Acton, MA 01720
ピーター・Schulterのうまいタイガー技術125Nagog Parkアクトン、MA 01720
EMail: paschulter@acm.org
メール: paschulter@acm.org
Markus Jork European Applied Research Center Digital Equipment GmbH CEC Karlsruhe Vincenz-Priessnitz-Str. 1 D-76131 Karlsruhe Germany
マーカスJork European応用研究センターデジタル機器GmbH CECカールスルーエVincenzプリースニッツStr。 1 D-76131カールスルーエドイツ
EMail: jork@kar.dec.com
メール: jork@kar.dec.com
Geraldine Harter Digital UNIX Networking Compaq Computer Corporation 110 Spit Brook Road Nashua, NH 03062
ジェラルディン・HarterのデジタルUNIXネットワークコンパックコンピュータ社110のつばのブルック・Roadナッシュア、ニューハンプシャー 03062
EMail: harter@zk3.dec.com
メール: harter@zk3.dec.com
Armitage, et. al. Standards Track [Page 25] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[25ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
References
参照
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[1] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[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] 気圧フォーラム、「気圧ユーザネットワーク・インターフェース(UNI)仕様バージョン3.1インチ、ISBN0-13-393828X、新米のホール、イングルウッドがけ、ニュージャージー、1995年6月。」
[3] Crawford, M., "A Method for the Transmission of IPv6 Packets over
Ethernet Networks", RFC 1972, August 1996.
[3] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッションのためのメソッド」、RFC1972、1996年8月。
[4] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993.
[4] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[5] Armitage, G., "Support for Multicast over UNI 3.1 based ATM
Networks", RFC 2022, November 1996.
[5] アーミテージ、G.、「UNI3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[6]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、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.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、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.、キャッツ、D.、Piscitello、D.コールB、およびN.Doraswamy、「次のNBMAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[9] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、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]KatsubeとY.とNagamiとK.とH.江崎、気圧のための「の東芝ルータアーキテクチャ拡大:、」 「概要」、RFC2098、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.Minshall、「流れはIPをラベルしました」。 「IPの下のATM」、INFOCOM96年、サンフランシスコ、1996年3月、pp.1251-1260のProceedings
[13] Piscitello, D. and J. Lawrence, "The Transmission of IP
Datagrams over the SMDS Service", RFC 1209, March 1991.
[13]PiscitelloとD.とJ.ローレンス、「SMDSサービスの上のIPデータグラムの送信」、RFC1209、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] プラマー、D.、「イーサネットは解決プロトコルを扱います--、イーサネットハードウェアの上でトランスミッションのための48.bitイーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、STD37、RFC826(1982年11月)
Armitage, et. al. Standards Track [Page 26] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[26ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
[15] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
version 6", RFC 1981, August 1996.
[15] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[16] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.
[17] アーミテージとG.とSchulterとP.とM.Jork、「気圧ネットワークの上のIPv6」、RFC2492、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.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
Armitage, et. al. Standards Track [Page 27] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[27ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
Appendix A. IPv6 Protocol Operation Description
付録A.IPv6プロトコル操作記述
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.
本書では説明されたNBMAモデルの上のIPv6はIPv6プロトコルの完全な意味論を維持します。 どんな変化も、IPv6 Network Layerに作られている必要がありません。 セキュリティ協会の概念がNBMAのために変えられていないので、このフレームワークは完全なIPv6セキュリティ意味論と特徴を維持します。 これで、IPv6ノードはいつもそれが懇願に関してどんな(and even if)について返答したらよいかを選ぶ請求されたノードであるので他のデータリンクでして、その結果、Neighborディスカバリーの意味論を維持しながらそのままでセキュリティ情報に基づく懇願への彼らの応答を選ぶことができます。 したがって、ケースを除いて、中追加サービス(QoS VCsなどの)が提供されるNBMAはネットワーク層に透明になるでしょう。
The remainder of this Appendix describes how the core IPv6 protocols will operate within the model described here.
このAppendixの残りはコアIPv6プロトコルがここで説明されたモデルの中でどう作動するかを説明します。
A.1 Neighbor Discovery Operations
A.1隣人発見操作
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.
各ノードは最初にオールノードマルチキャストグループに加わらなければなりません、そして、Neighborのどんな種類も実行する前に、操作を発見してください、そして、それはノードマルチキャストアドレスに請求しました(DADと関連したこのアドレスの使用はA.1.4で説明されます)。 IPv6ネットワーク層は4.2で説明されるようにこれらのマルチキャストグループに加わるでしょう。
A.1.1 Performing Address Resolution
アドレス解決を実行するA.1.1
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.
IPv6ホストは目標ホストの請求されたノードマルチキャストアドレスにNeighbor Solicitationを送ることによって、アドレス解決を実行します、[7]で説明されるように。 Neighbor SolicitationメッセージはLLに関する請求ノードのNBMAアドレスに設定されたAddress Option Source Link-層を含むでしょう。
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.
Neighbor SolicitationメッセージがIPv6ネットワーク層よりローカルのノードのIPv6/NBMAドライバーに移られるとき、ステップがセクション4.4で.2Sending Multicast Dataについて説明したということになります。
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つ以上のノードがNeighbor Solicitationメッセージを受け取るでしょう。 ノードは、セクション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].
受信ノードがNeighbor Solicitationの目標であるなら、それは[7]で説明されるようにNeighbor SolicitationメッセージのSource Link-層のAddress Optionに含まれた請求ノードのNBMAアドレスでNeighborキャッシュをアップデートするでしょう。
Armitage, et. al. Standards Track [Page 28] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[28ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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ホストはNeighbor Solicitationに請求ノードのIPv6ユニキャストアドレスにNeighbor Advertisementメッセージを送って応じるでしょう。 Neighbor AdvertisementメッセージはLLに関する請求されたノードのNBMAアドレスに設定されたAddress Option Target Link-層を含むでしょう。
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.
Neighbor Advertisementと請求ノードのリンクレイヤアドレスはIPv6ネットワーク層より請求されたノードのIPv6/NBMAドライバーに移られるでしょう。 そして、NAメッセージを請求ノードに送ると、セクション部分4.4.1で説明された方法は従われるでしょう。 1つが既に存在しなかったなら、これは請求されたノードと請求しているノードの間で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].
請求ノードは、セクション4.5で説明されるように次に、新しいPtP VCの上にNeighbor Advertisementメッセージを受け取って、反-メッセージをカプセル化して、処理のためにIPv6 Network層にそれを通過するでしょう。 請求ノードは次に、それのNeighborキャッシュにおける適切なエントリーをするでしょう、[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.
ここに、各システムには、もう片方のシステムのための完全なNeighborキャッシュエントリーがあります。 彼らは、Neighbor Advertisementを返したとき請求されたノードによって新たに作成された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ホストはオールノードマルチキャストアドレスにUnsolicited Neighbor Advertisemnentを送ることができます。 Neighbor AdvertisementがIPv6ネットワーク層より地元のノードIPv6/NBMAドライバーに移られるとき、オールノードマルチキャストアドレスにNAメッセージを送ると、セクション4.4.2で説明された方法は従われます。 各ノードは、[7]で説明されるようにセクション4.5で説明されるように入って来るパケットを処理して、次に、それが処理されるところにIPv6ネットワーク層へのパケットを向かわせるでしょう。
A.1.2 Performing Router Discovery
ルータ発見を実行するA.1.2
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]で説明されます。 RouterディスカバリーがIPv6ルータであるとサポートするのがIPv6オールルータマルチキャストグループアドレスを接合するでしょう。 IPv6/NBMAドライバーがIPv6 Network Layerから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ルータで、求められていないRouter Advertisementsは定期的に彼らの有用性をLLに発表します。 IPv6ルータが求められていないRouter Advertisementを送るとき、それはIPv6オールノードマルチキャストアドレスに扱われたデータ・パケットを送ります。 地元のノードIPv6/NBMAドライバーがIPv6ネットワーク層からRouter Advertisementメッセージを得るとき、それは、セクション4.4.2で説明された方法に従うことでメッセージを送ります。 火星はLLのところでパケットを伝えるでしょう。
Armitage, et. al. Standards Track [Page 29] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[29ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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。(そのClusterControlVCはLLですべてのノードにパケットを送ります)。 LLの上の各ノードは、次に、セクション4.5で説明されるように入って来るパケットを処理して、処理のために適宜容認されたパケットをIPv6 Network層に通過するでしょう。
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.
Routerディスカバリーを実行するために、IPv6ホストはオールルータマルチキャストアドレスにRouter Solicitationメッセージを送ります。 地元のノードIPv6/NBMAドライバーがパケットを送るためにIPv6 Network Layerから要求を得るとき、それはセクション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ルータは、Router Solicitationのソースアドレスが不特定のアドレスであったならIPv6オールノードマルチキャストアドレスに扱われたRouter Advertisementを送ることによって、Router Solicitationに応じます。 Router Solicitationのソースアドレスがそうでないなら、不特定のアドレス、ルータは請求ノードへのRouter Advertisementをユニキャストに望んでいます。 ルータがオールノードマルチキャストアドレスにRouter Advertisementを送るなら、それは求められていないRouter Advertisementsのために上で説明された方法に従います。
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.
Router Advertisementによる請求ノードへのユニキャストであるつもりであるなら、IPv6ネットワーク層はノードのIPv6/NBMAドライバーにRouter Advertisementを与えるでしょう、そして、セクション4.4.1Thisで説明されたステップに応じてパケットを送る請求ノード(必要なら、Address Resolutionを通して得る)のリンクレイヤアドレスは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で説明されるようにRouter Advertisementを処理して、RAメッセージをIPv6ネットワーク層に通過するでしょう。 Neighborキャッシュエントリーの状態によって、IPv6ネットワーク層はRouter AdvertisementメッセージのSource Link-層のAddress Optionに含まれたルータのNBMAアドレスでNeighborキャッシュをアップデートするかもしれません。
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がRouterディスカバリーの間、セットアップされると、請求ノードとルータの間のその後のIPv6ベストエフォート型ユニキャストデータは新しいPtP VCの上に送られるでしょう。
Armitage, et. al. Standards Track [Page 30] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[30ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
A.1.3 Performing Neighbor Unreachability Detection (NUD)
隣人Unreachability検出を実行するA.1.3(NUD)
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.
隣人Unreachability Detection(NUD)はIPv6ホストが隣人がもう届いていないと決心しているプロセスです、[7]で説明されるように。 それぞれのNeighborキャッシュエントリーは可到達性失敗を検出するのにNUDアルゴリズムで使用される情報を含んでいます。 隣人の可到達性の確認は最近隣人に送られたデータを受け取ったという上側の層のプロトコル指摘か、Neighbor Solicitation徹底的調査に対応したNeighbor Advertisementメッセージの受領から来ます。
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.
リリースされたVCsなどのノードのIPv6/NBMAドライバーでの接続性失敗(セクション4.6を見る)とVCを隣人に作成できないこと(セクション4.4.1を見る)は、IPv6ネットワーク層で検出されて、扱われます、Neighbor Unreachability Detectionを通して。 ノードの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ホストからVCをIPv6隣人のひとりに作成しないと、NUDを通して検出されて、扱われるでしょう。 IPv6ホストから隣人にデータを送る各試みのときに、ノードのIPv6/NBMAドライバーは、隣人にVCをセットアップするのを試みるでしょう、そして、そうしないと、パケットを下げるでしょう。 IPv6可到達性確認タイマは結局期限が切れるでしょう、そして、隣人のNeighborキャッシュエントリーはPROBE状態に入れるでしょう。 PROBE州は隣人へのユニキャストNeighbor SolicitationsにIPv6ホストを引き起こすでしょう。(その隣人は、再び後にVCをセットアップしないことでローカルのノードのIPv6/NBMAドライバーによって下げられるでしょう)。 したがって、IPv6ホストは可到達性確認に必要である請求されたNeighbor Advertisementsを決して受け取らないでしょう、隣人のエントリーがNeighborキャッシュから削除されることを引き起こして。 IPv6ホストがその隣人にデータを送ろうとする次の時に、アドレス解決は実行されるでしょう。 前の失敗の理由によって、隣人への接続性は復職できました(前のVCセットアップの故障が例えばNeighborキャッシュにおける時代遅れのリンクレイヤアドレスで引き起こされたなら)。
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/NBMAドライバーは、IPv6ホストから隣人にパケットを送る次の時にもうその隣人にVCを持っていないと認めて、新しいVCを隣人にセットアップするのを試みるでしょう。 ノードが1日とその後のトランスミッションのときにVCを隣人に作成できないと、NUDはより多くの早さに(IPv6ホストからVCをIPv6隣人のひとりに作成しない永続的なことを扱う)説明されるように失敗を検出して、扱うでしょう。 前の失敗の理由によって、隣人への接続性は復職するかもしれません。
Armitage, et. al. Standards Track [Page 31] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[31ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
A.1.4 Performing Duplicate Address Detection (DAD)
写しアドレス検出を実行するA.1.4(おとうさん)
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.
IPv6ホストはそれがLL(すなわち、一時的なアドレス)で使用したがっているアドレスが既に使用中でないことを決定するために、Duplicate Address Detection(DAD)を実行します、[9]と[7]で説明されるように。 写しAddress Detectionはホストが使用したがっているすべてのアドレスに実行されます、アドレスを得るのに使用される構成メカニズムにかかわらず。
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.
Duplicate Address Detectionを実行する前に、ホストはオールノードマルチキャストアドレスとホストの一時的なアドレスに対応する請求されたノードマルチキャストアドレスに加わるでしょう(4.2 Multicast Groupを接合しながら、見てください)。 IPv6ホストはホストの一時的なアドレスに対応する請求されたノードマルチキャストアドレスにNeighbor Solicitationを送ることによって、Duplicate Address Detectionを開始します、目標としての一時的なアドレスで。 ローカルのノードのIPv6/NBMAドライバーがIPv6ネットワーク層からNeighbor Solicitationメッセージを得るとき、それはセクション4.4.2に概説された方法に従います。 目標請求されたノードマルチキャストグループに加わったそれらのノード、または、すべてのノードにNSメッセージを送るでしょう。 DAD NSメッセージは、セクション4.5で説明されるようにLLの上の1つ以上のノードによって受け取られて、それぞれによって処理されるでしょう。 送付ノードのIPv6ネットワーク層がメッセージを見ないように送付ノードの火星クライアントがメッセージを無視することに注意してください。 目標請求されたノードマルチキャストグループのメンバーでないどんなノードのIPv6ネットワーク層もNeighbor Solicitationメッセージを捨てるでしょう。
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.
他のどんなホストも一時的なアドレスに対応する請求されたノードマルチキャストアドレスに加わっていないと、ホストは目標として一時的なアドレスを含むNeighbor Advertisementを受け取らないでしょう。 ホストは、NBMAインタフェースに[9]で説明された「再-トランスミッション」論理を実行して、Duplicate Address Detectionを終えて、一時的なアドレスを割り当てるでしょう。
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の上の他のホストはNeighbor Solicitationを処理するでしょう。 処理は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
受信IPv6ホストのアドレスが一時的でないなら、Neighbor Advertisementがあて先アドレスを含んでいて、ホストは応じるでしょう。 Neighbor Solicitationの源が不特定のアドレスであるので、ホストはセクション4.4.2に概説された方法に従うオールノードマルチキャストアドレスにNeighbor Advertisementを送ります。 DAD NAメッセージは、セクション4.5で説明されるようにLLのすべてのノードで火星クライアントによって受け取られて、処理されるでしょう。 メッセージヘッダーのCMIが受信ノードのものに合うので送付ノードが入力メッセージをフィルターにかけることに注意してください。 すべて他です。
Armitage, et. al. Standards Track [Page 32] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[32ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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ネットワーク層にそれを通過するでしょう。 ホスト実行DADは検出するでしょう。一時的なアドレスがNeighbor Advertisementの目標であり、一時的なアドレスがユニークでないことを決定して、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インタフェースに選任できません。
A.1.5 Processing Redirects
A.1.5処理は向け直します。
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.
IPv6ルータは特定の目的地に達するように最初に、より良いホップについてIPv6ホストに知らせるのにRedirect Messageを使用します、[7]で説明されるように。 別のLLで、より良い最初のホップルータ、同じLLの上の別のホストか一時的な隣人のホストを指示するのにこれを使用できます。 IPv6ルータはRedirectの引き金となったIPv6ソースへのRedirectが扱うユニキャストがそうするでしょう。 ルータのIPv6/NBMAドライバーは、セクション4.4.1で説明された手順を用いることでRedirectメッセージを送るでしょう。 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.
Redirectの引き金となったIPv6ホストのIPv6/NBMAドライバーはカプセル化されたそれのPt Pt VCsの1つ以上のRedirectを受け取るでしょう。 それは、反-要約しているのにパケットを望んでいて、説明されたセクション4.5としてRedirectメッセージをIPv6 Network Layerに通過します。
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ホストから目的地に送られた順次データをRedirect Messageで指定された次のホップアドレスに送るでしょう。 NBMAネットワークのために、Redirect Messageは[7]とセクション5.2で説明されるリンクレイヤアドレスオプションを含むはずです、その結果、向け直されたノードはそれが向け直されたノードのリンクレイヤアドレスを学ぶためにNeighbor Solicitationを実行する必要はないでしょう。 したがって、NBMAネットワークのどんなノードにはも再直接があることができます、新しい目標ノードのLL会員資格にかかわらず。 これは、NBMAホストが標準のIPv6プロトコルを使用することによって近道を達成するために彼らのLLで向け直されるのを許容します。
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パケットと次のホップノードのリンクレイヤアドレスをノードのIPv6/NBMAドライバーに与えるでしょう。 ノードのIPv6/NBMAドライバーは、次のホップの目的地へのVCが存在するかどうかと決心するでしょう。 Pt Pt VCが存在していないと、IPv6/NBMAドライバーは、目的地にデータ・パケットを列に並ばせて、VCのセットアップに着手するでしょう。 VCが作成されるか、1つが既に存在しているなら、ノードが発信データパケットをカプセルに入れって、それをVCに送るとき。
Armitage, et. al. Standards Track [Page 33] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[33ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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].
Redirectsが単方向であることに注意してください。 向け直されたホストはRedirectメッセージの指定されるとしての次のホップの目的地にVCを作成するでしょうが、次のホップは送信元ホストに向け直されないでしょう。 Neighborディスカバリーが全く行われないので、次のホップの目的地には、新しいVCを受けるとき訪問者のアイデンティティを決定する方法が全くありません。 また、ノースダコタが取らないので入賞してください、オンである、向け直す、次のホップはそれがそれの隣人か目的地キャッシュをアップデートするイベントを全く受けません。 しかしながら、それは、向け直されたホストへの前の経路の向け直されたホストにデータを送って戻し続けるでしょう。 向け直されたノードにそれを向け直しながら再直接でaを受けるなら、次のホップノードは向け直された目的地から新しいVCを使用するはずであることができます。 この振舞いは[7]と一致しています。
A.2 Address Configuration
A.2アドレス構成
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.
IPv6アドレスは、[9]と[18]で説明されるように状態がないかstatefulなアドレス自動構成メカニズムを使用することで自動構成されます。 IPv6自動構成プロセスは、アドレスを得るためにLL、使用に状態がないか否かに関係なく、決定する、そして/または、stateful configurationmechanismsでリンクローカルアドレスのユニークさを作成して、確かめて、他の(非アドレス)の情報が自動構成されるかどうかことであることを決定することを伴います。 また、例えば、自動構成されたリンクローカルアドレスがユニークでないので自動構成が失敗するなら、手動でIPv6アドレスを構成できます。 LL管理者は使用する自動構成のタイプを指定します。 LLの上のホストはRouter Advertisementメッセージを通してこの自動構成情報を受け取ります。
The following sections describe how stateless, stateful and manual address configuration will work in an IPv6/NBMA environment.
以下のセクションは状態がなくて、statefulであって手動のアドレス構成がIPv6/NBMA環境でどう働くかを説明します。
A.2.1 Stateless Address Configuration
A.2.1の状態がないアドレス構成
IPv6 stateless address configuration is the process by which an IPv6 host autoconfigures its interfaces, as described in [IPV6-ADDRCONF].
IPv6の状態がないアドレス構成はIPv6ホストが[IPV6-ADDRCONF]で説明されるようにインタフェースを自動構成するプロセスです。
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ホストが最初に始動すると、それはLogical Linkに付けられたインタフェースにリンクローカルアドレスを生成します。 そして、それは、Duplicate Address Detection(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
IPv6ホストがリンクローカルアドレスがユニークであると決心して、Logical Linkの上のインタフェースにそれを割り当てた後に、IPv6ホストは、自動構成情報を得るためにRouterディスカバリーを実行するでしょう。 IPv6ホストが、Router Solicitationを出して、Router Advertisementを受け取るだろうか、またはそれは待っています。
Armitage, et. al. Standards Track [Page 34] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[34ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
求められていないRouter Advertisement。 IPv6ホストは、[9]で説明されるようにRouter AdvertisementのMとOビットを処理して、その結果statefulアドレス自動構成を呼び出すかもしれません。
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.
ルータが全くLogical Linkにないと、IPv6ホストは、Logical Linkでリンクローカルのアドレスを使用することで他のIPv6ホストとコミュニケートできるでしょう。 IPv6ホストは、Address Resolutionを使用することで隣人リンクの層のアドレスを得るでしょう。 また、それがそうしないように明らかに構成されていないと、IPv6ホストは、stateful自動構成を呼び出すのを試みるでしょう。
A.2.2 Stateful Address Configuration (DHCP)
A.2.2 Statefulアドレス構成(DHCP)
IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to perform stateful address auto-configuration, as described in [18].
IPv6ホストは、statefulアドレス自動構成を実行するのに、[18]で説明されるようにDynamic Host Configuration Protocol(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サーバか中継エージェントが手動の、または、statefulな自動構成によって構成されたLogical Linkに出席しています。 DHCPv6サーバか中継エージェントがLogical Linkに関するIPv6 DHCPv6 Server/リレーエージェントマルチキャストグループに加わるでしょう。 ノードの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ビットのRouter Advertisementsが、それがそうするべきであるのを示すとstateful自動構成を呼び出して、それを検出するなら、stateful自動構成を呼び出すかもしれません。どんなルータもLogical Linkに存在していません。 statefulメカニズムを通して設定情報を得ている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 Server/エージェントマルチキャストアドレスにDHCPv6 Solicitメッセージを送るでしょう。 請求ノードのIPv6/NBMAドライバーがパケットを送るためにIPv6 Network Layerから要求を得るとき、それはセクション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.
Logical Linkの上のDHCPv6 ServerかRelayエージェントはDHCPv6クライアントへのユニキャストa DHCPv6 Advertisementがそうするでしょう。 IPv6ネットワーク層はDHCPv6クライアント(必要なら、Neighborディスカバリーを通して得る)のパケットとリンクレイヤアドレスをノードのIPv6/NBMAドライバーに与えるでしょう。 そして、ノードIPv6/NBMAドライバーはセクション4.4.1で説明されるようにパケットを伝えるでしょう。 これは1つが以前に存在しなかったならサーバとクライアントの間で作成される新しいPt Pt VCをもたらすでしょう。
Armitage, et. al. Standards Track [Page 35] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[35ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
DHCPクライアントのIPv6/NBMAドライバーはDHCP ServerかRelayエージェントからカプセル化されたパケットを受けるでしょう、セクション4.5で説明されるように。 ノードは、反-マルチキャストパケットをカプセルに入れって、次に、処理のためにそれをIPv6 Network Layerまで通過するでしょう。 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メッセージ(要求、Reply、Release、およびReconfigure)はDHCPv6クライアントとDHCPv6 Serverの間のユニキャストです。DHCPv6クライアントのアドレスの可到達性によって、ルータかDHCPv6 Relay-エージェントを通してDHCPv6クライアントと別のLLの上のDHCPv6 Serverの間で交換されたメッセージを送ります。 DHCPv6メッセージを送る前に、IPv6ネットワーク層は、(必要なら、)パケットの次のホップに対応するリンクレイヤアドレスを得るためにNeighborディスカバリーを実行するでしょう。 Pt Pt VCは送付者と、次のホップと、それの上に伝えられたカプセル化されたパケットの間でセットアップされるでしょう、4.4で説明されるように。 データを送ります。
A.2.3 Manual Address Configuration
A.2.3の手動のアドレス構成
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.
DADを通してリンクローカルアドレスがユニークでないと発見すると、IPv6ホストは手動で構成されるでしょう。 一度、ユニークなインタフェーストークンでIPv6ホストを構成して、次に、自動構成メカニズムを呼び出すことができます。
A.3 Internet Group Management Protocol (IGMP)
A.3インターネットグループ管理プロトコル(IGMP)
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プロトコルを使用するでしょう。 ここで説明されたフレームワークでは、NBMAに少しも特別な変更なしでIGMPv6プロトコルを使用できます。 この環境でこれらのプロトコルは最も効率的でないかもしれませんが、それでも、それらは以下で説明されるように働くでしょう。 しかしながら、NBMA LLに接続されたIPv6マルチキャストルータは、火星_GROUPLIST_REQUESTメッセージをLLに役立つ火星に送って、火星_GROUPLIST_REPLYメッセージでグループ会員資格を決定することによって、IGMP機能を任意に最適化するかもしれません。 マルチキャストグループ会員資格のために火星について質問するのは、任意のenchancementであり、ルータが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.
マルチキャストグループ会員資格情報を運ぶ3つのICMPv6メッセージタイプがあります: Group Membership Query、Group Membership Report、およびGroup Membership Reductionメッセージ。 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
IPv6マルチキャストルータは、LLですべてのマルチキャストグループに無差別なモード[5]で加わることによって、すべてのIPv6マルチキャストパケットを受けます。 そして、火星サーバで、マルチキャストルータをすべてに加えるでしょう。
Armitage, et. al. Standards Track [Page 36] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[36ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
existing and future multicast VCs. The IPv6 multicast router will thereafter be the recipient of all IPv6 multicast packets sent within the Logical Link.
存在と将来のマルチキャストVCs。 IPv6マルチキャストルータはその後、Logical Linkの中で送られたすべての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マルチキャストルータは、どのマルチキャストグループにメンバーがメッセージをGroup Membership Queryに送りながらLogical Linkに定期的でいるかをIPv6オールノードマルチキャストアドレスに発見します。 いつローカルのノードのIPv6/NBMAドライバーがGroup Membership Queryパケットを送るためにIPv6ネットワーク層から要求を得て、説明された方法に従うか、4.4、.2 ノードは、パケットの送付先アドレスがオールノードマルチキャストアドレスであることを決定して、パケットがカプセルに入れられて、直接火星に伝えられるところにノードの火星クライアントへのパケットを向かわせます。 そして、火星はLLのすべてのノードにパケットをリレーします。 各ノードのIPv6/NBMAドライバーは反-それをカプセル化して、それがIPv6 Network層まで通過されたパケットを受けるでしょう。 起因するノードがカプセル化されたパケットを受けると、受信ノードのClusterメンバーIDがパケットの火星カプセル化ヘッダーでCMIに合うので、パケットは火星クライアントによって無視されるでしょう。
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.
Logical LinkのIPv6ホストはホストによって加わられたそれぞれのIPv6マルチキャストグループのためにGroup Membership Reportと共にGroup Membership Queryに応じるでしょう。 また、ホストが新しいIPv6マルチキャストグループに加わるとき、IPv6ホストはGroup Membership Reportを伝えることができます。 アドレスが報告されているマルチキャストグループにGroup Membership Reportを送ります。 いつ地元のノードIPv6/NBMAドライバーがパケットを送るためにIPv6ネットワーク層から要求を得て、説明された方法に従うか、4.4、.2 ノードは、パケットがしたがってアドレスがそれを送るマルチキャストに送られることを適切なVCを転送するためのノードの火星クライアントに決定します。
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.
Group Membership Reportパケットは各ノードの火星クライアントに愛着しているVCの1つを通して報告されるグループのメンバーであるあらゆるノードに到着するでしょう。 火星クライアントは反-入って来るパケットをカプセルに入れるでしょう、そして、パケットは処理のためにIPv6ネットワーク層に通過されるでしょう。 それを受けるとき、送付ノードの火星クライアントはパケットを無視するでしょう。
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ホストはGroup Membership Reductionメッセージを送ります。 IPv6ホストが残しているマルチキャストグループにGroup Membership Reductionを送ります。 Group Membership Reductionメッセージのトランスミッションと受領はGroup Membership Reportsと同じ方法で扱われます。
Armitage, et. al. Standards Track [Page 37] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[37ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
Appendix B. Alternative models of MARS support for Intra-LL ND
Intra-LLノースダコタの火星サポートの付録B.Alternativeモデル
B.1 Simplistic approach - Use MARS 'as is'.
B.1の安易なアプローチ--'そのままで'火星を使用してください。
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ドライバーはそれがすべてのマルチキャストIPv6パケットを伝えることができるインタフェースからVC推進経路を証明するのに標準の火星プロトコルを利用します、ICMPv6パケットを含んでいて。 目的地グループあたりの別々のPt-mpt VCsを使用して、IPv6パケットは、意図している目的地セットによって次に、送信されて、受け取られます。
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リソース消費を考慮に入れなければなりません。 残念ながら、ノースダコタは、まばらに分散しているセットのSolicited Nodeマルチキャストアドレス(発見質問が初めは送られる)を作ることによってリンク・レベルマルチキャスト資源を節約するのが最も良いと仮定します。 元の目標は同時に他の誰かのために本当に意図する発見メッセージを受け取った潔白なノードの数を最小にすることでした。
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インタフェースが溯源するか、または終えるのに必要である独立しているVCsの数を最小にするために重要な状態でなります。 私たちが'ブラックボックス'として火星サービスを扱うなら、まばらなSolicited Nodeアドレス空間は多くの短い使用ですが、より長い間送られたPt-mpt VCs(ノードがNeighbor Solicitationsを伝えているときはいつも、生成される)に通じることができます。 よりいらいらさせさえして、これらのVCsは単にそれらの関連Solicited Nodeマルチキャストアドレスに送られる追加パケットの役に立ちます。 新しいPt Pt VCが、実際にNeighbor SolicitationをうながしたユニキャストIPv6トラフィックを運ぶのに必要です。
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.
まばらなSolicited Nodesアドレス空間によって引き起こされた非能率の軸はVCメッシュ対Multicast Server見返りと直交しています。 通常、マルチキャストサーバは独身のVCへの一般的なマルチキャストグループへの交通の流れに集められます。 VC消費をノースダコタに抑えるために、明白なIPv6の目的地よりむしろパケットの機能に基づいて集合を実行して、私たちは、Solicited Nodeアドレス空間の向こう側に集める必要があります。 ここでのトレードオフは集合が散るノードの元の値をSolicited Nodesスペースの向こう側にまばらに移すということです。 これはノースダコタと接続指向のネットワークの間のミスマッチの価格です。
B.2 MARS as a Link (Multicast) Server.
B.2はリンク(マルチキャスト)としてサーバを損ないます。
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
ある可能な凝集機構はあらゆるノードのIPv6/NBMAドライバーが捕らえるように、ノースダコタかRDが通信させるマルチキャストを論理的に運ぶマルチキャストICMPv6パケットがそれらの目的地をAll Nodesにremapするということです。
Armitage, et. al. Standards Track [Page 38] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[38ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
分類してください(地方の範囲をリンクしてください)。 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:
さらなる最適化はマルチキャストノースダコタかRDメッセージを伝える罠マルチキャストICMPv6パケットへのあらゆるノードのIPv6/NBMAドライバーのためのものです、そして、ClusterControlVCの上の「再-トランスミッション」のためにそれらを火星自体に送ってください(些細な拡大に火星自体にかかわります。)。 このアプローチはIPv6マルチキャスティングがサポートされるどんなLLでもそれを認識します:
- Nodes already have a pt-pt VC to their MARS.
- ノードは既にPt Pt VCをそれらの火星に持ちます。
- The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster
members (LL members registered for multicast support).
- 火星はすべてのClusterメンバーへの外にPt-mpt VC(ClusterControlVC)を持っています(LLメンバーはマルチキャストサポートに登録しました)。
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.
火星とその火星クライアントの間のVCsがパケットであるとカプセル化されたLLC/SNAPを運ぶので、正常な火星コントロールメッセージと共にICMPパケットを多重送信できます。 本質では、火星はそれがLLから受ける非火星パケットのためのマルチキャストサーバとして振る舞います。
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.
火星クライアントがClusterControlVCに関する火星コントロールメッセージだけを受け入れるという要件が全くなくて、こんなやり方で受け取られた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メッセージを受け取らなければならない全体のClusterの会員資格をもたらします。
Armitage, et. al. Standards Track [Page 39] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[39ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
Appendix C. Flow detection
付録C.Flow検出
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パケット流れの間の関係、Service保証のQuality、および基本的なIPとNBMAネットワーク資源の最適の使用はIETF(明確にISSLL、RSVP、IPNG、およびIONワーキンググループ)の継続中の研究の対象です。 このドキュメントは現在、NBMAネットワーク資源の相互LL近道の設立による使用を最適化する手段として流れ検出の使用を記述するだけです。
C.1. The use of non-zero FlowID to suppress flow detection
C.1。 流れ検出を抑圧する非ゼロFlowIDの使用
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.
ホストからのいかなる他の指導がないときIPv6パケットの推進を最適化しながら、NBMA近道は'ネットワーク'の利益のためのものです。
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にも、「ソースはネットワークにパケットのためのベストエフォート型推進サービスにFlowIDを全く提供しない際に一存を利用させる」IPv6意味論がありません。
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"
非ゼロFlowIDには、「ソースは以前に好まれたいくつかを設立しました、このFlowIDと共にパケットのためのホップ推進のふるまいでホップを終わらせる終わり」のIPv6意味論があります。
Armitage, et. al. Standards Track [Page 40] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[40ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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が非ゼロであるなら、近道を課すどんな試みもしないでください」のこのドキュメントの流れ検出規則と一致しています。
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).
'ネットワーク'(例えば、RSVP、または管理手段などのダイナミックな手段による)と都合のよい推進メカニズムを交渉した後に、非ゼロFlowIDは送信元ホストによって割り当てられるかもしれません。 送信元ホストは単に手当たりしだいにあるいはまたそれを割り当てることができます、そして、ネットワークはベストエフォート型推進をデフォルトに提供するでしょう(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 Best取り組み推進のゼロを合わせてください。
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 Best取り組み推進はこの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.
1ホップあたりの特定の処理を確立するためのメカニズムはパケットのために非ゼロでFlowIDが強制的でなくて、また暗示していない統治されます、このドキュメント。
C.2. Future directions for Flow Detection
C.2。 Flow Detectionのための将来の方向
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.
IPv6の将来的で、正確なマッピングでは、NBMA VCsへの流れは、現在Neighborディスカバリーパケットで利用可能であるというよりも情報がNeighborディスカバリープロセスの間、交換されるのを必要とするかもしれません。 これらの場合では、IPv6 Neighbor Discoverプロトコルは、新しいTLVオプションを含むように拡張できます。(セクション4.6のRFC1970[7])を見てください。 しかしながら、新しいオプションが必要であるなら、IPNGワーキンググループと共にこれらのオプションの仕様を調整しなければなりません。 RFC1970が、ノードが静かにオプションを無視しなければならないと指定するので、彼らは分からないで、いつでも、既存の実装との壊れている後方の互換性なしで新しいオプションは加えることができます。
Armitage, et. al. Standards Track [Page 41] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[41ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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 RequestsとNHRP Repliesに任意のTLVsを加えるのにメカニズムを提供します。 このドキュメントのアーキテクチャの未来の発展は、確実に意味的に同等に(構文の違いを望ましくないのですが、許容できます)なるようにするためにノースダコタと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のサポートは既存の火星プロトコルにさらなる拡大を必要としないでしょう。 しかしながら、IPv6マルチキャスト流れのQoSの今後のサポートは拡大を必要とするかもしれません。 QoS拡張子が必要に応じて開発されるのを許容して、火星コントロールメッセージはNHRPと同じTLV拡張機能を共有します。
Appendix D. Shortcut Limit Option
付録D.近道の限界オプション
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メッセージにおいて、新しいタイプのノースダコタのオプションが、ホストからルータまでのデータフローホップ限界の情報を伝えるのに必要です。 このノースダコタのオプションの使用はこの.2のセクション3.2仕様に基づき定義されます。 2進法表示はRFC1970のセクション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 近道の限界| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
分野:
Type 6
6をタイプしてください。
Length 1
長さ1
Shortcut Limit 8-bit unsigned integer. Hop limit for shortcut
attempt.
近道のLimit、8ビットの符号のない整数。 近道の試みのための限界を飛び越してください。
Reserved1 This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Reserved1 This分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Reserved2 This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Reserved2 This分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Armitage, et. al. Standards Track [Page 42] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[42ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
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.
近道の限界オプションは近道の引き金としてデフォルトルータに送られたNeighbor Solicitationメッセージでホストによって使用されます。 それはルータの近道の質問をホップの指定された数を通して届いている目標に制限します。 近道を要求するホストに比例して近道の限界を与えます。 静かに0か1の近道の制限値があるNSメッセージを無視しなければなりません。
Armitage, et. al. Standards Track [Page 43] RFC 2491 IPv6 over NBMA networks January 1999
etアーミテージ、アル。 NBMAの上の規格Track[43ページ]RFC2491IPv6は1999年1月をネットワークでつなぎます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Armitage, et. al. Standards Track [Page 44]
etアーミテージ、アル。 標準化過程[44ページ]
一覧
スポンサーリンク
