RFC3122 日本語訳
3122 Extensions to IPv6 Neighbor Discovery for Inverse DiscoverySpecification. A. Conta. June 2001. (Format: TXT=40416 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Conta Request for Comments: 3122 Transwitch Corporation Category: Standards Track June 2001
コメントを求めるワーキンググループA.コンタの要求をネットワークでつないでください: 3122年のTranswitch社のカテゴリ: 標準化過程2001年6月
Extensions to IPv6 Neighbor Discovery for Inverse Discovery
Specification
逆さの発見仕様のための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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.
このメモはノードが与えられたリンクレイヤアドレスに対応するIPv6アドレスを決定して、広告を出す拡大を、IPv6 Neighborディスカバリーに説明します。 これらの拡大はInverse Neighborディスカバリーと呼ばれます。 Inverse Neighborディスカバリー(IND)は、元々Frame Relayネットワークのために開発されましたが、また、同様の振舞いで他のネットワークに適用されるかもしれません。
Conta Standards Track [Page 1] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[1ページ]。
Table of Contents
目次
1. Introduction.................................................... 3
2. Inverse Neighbor Discovery Messages............................. 3
2.1 Inverse Neighbor Discovery Solicitation Message............. 3
2.2 Inverse Neighbor Discovery Advertisement Message............ 5
3. Inverse Neighbor Discovery Options Format....................... 6
3.1 Target Address List......................................... 6
4. Inverse Neighbor Discovery Protocol............................. 9
4.1 Sender Node Processing...................................... 9
4.2 Receiver Node Processing.................................... 9
4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
4.3 Message Validation......................................... 10
4.3.1 Validation of Inverse Neighbor Discovery Solicitations. 10
4.3.2 Validation of Inverse Neighbor Discovery Advertisements 11
5. Security Considerations........................................ 12
6. IANA Considerations............................................ 13
7. Acknowledgments................................................ 13
8. References..................................................... 13
9. Authors' Addresses............................................. 14
Appendix A........................................................ 15
Full Copyright Statement.......................................... 20
1. 序論… 3 2. 逆さの隣人発見メッセージ… 3 2.1の逆さの隣人発見懇願メッセージ… 3 2.2の逆さの隣人発見広告メッセージ… 5 3. 逆さの隣人発見オプション形式… 6 3.1 住所録を狙ってください… 6 4. 逆さの隣人ディスカバリーは議定書を作ります… 9 4.1 送付者ノード処理… 9 4.2 受信機ノード処理… 9 4.2 .1 処理の逆さの隣人発見懇願… 9 4.2 .2 処理の逆さの隣人発見広告… 10 4.3 メッセージ合法化… 10 4.3 .1 逆さの隣人発見懇願の合法化。 10 4.3 .2 逆さの隣人発見広告11 5の合法化。 セキュリティ問題… 12 6. IANA問題… 13 7. 承認… 13 8. 参照… 13 9. 作者のアドレス… 14 付録A.… 15 完全な著作権宣言文… 20
Conta Standards Track [Page 2] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[2ページ]。
1. Introduction
1. 序論
This document defines extensions to the IPv6 Neighbor Discovery (ND)[IPv6-IND]. The extensions are called IPv6 Inverse Neighbor Discovery (IND). The IPv6 Inverse Neighbor Discovery (IND) allows a node that knows the link-layer address of a directly connected remote node to learn the IPv6 addresses of that node. A node using IND sends solicitations and receives advertisements for one or more IPv6 addresses corresponding to a known link-layer address.
このドキュメントはIPv6 Neighborディスカバリー(ノースダコタ)[IPv6-IND]と拡大を定義します。 拡大はIPv6 Inverse Neighborディスカバリー(IND)と呼ばれます。 IPv6 Inverse Neighborディスカバリー(IND)はそれが、直接接続された遠隔ノードのリンクレイヤアドレスが学ぶのを知っているノードにそのノードのIPv6アドレスを許容します。 INDを使用するノードは、知られているリンクレイヤアドレスに対応する1つ以上のIPv6アドレスのために懇願を送って、広告を受け取ります。
The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.
Inverse Neighborディスカバリー(IND)は、元々Frame Relayネットワークのために開発されましたが、また、同様の振舞いで他のネットワークに適用されるかもしれません。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [KEYWORDS].
キーワードが解釈しなければならない、[KEYWORDS]で定義されるようにNOT、5月、OPTIONAL、REQUIRED、RECOMMENDED、SHALL、SHALL NOT、SHOULD、SHOULD NOTを解釈することになっていなければなりませんか?
There are a number of similarities and differences between the mechanisms described here and those defined for Inverse ARP for IPv4 in [INV-ARP] or its replacement documents.
ここで説明されたメカニズムとIPv4のためのInverse ARPのために定義されたものの間には、[INV-ARP]かその差し替え書類に多くの類似性と違いがあります。
2. Inverse Neighbor Discovery Messages
2. 逆さの隣人発見メッセージ
The following messages are defined:
以下のメッセージは定義されます:
2.1. Inverse Neighbor Discovery Solicitation Message
2.1. 逆さの隣人発見懇願メッセージ
A node sends an Inverse Neighbor Discovery Solicitation message to request an IPv6 address corresponding to a link-layer address of the target node while also providing its own link-layer address to the target. Since the remote node IPv6 addresses are not known, Inverse Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level, an IND Solicitation is sent directly to the target node, identified by the known link-layer address.
ノードはまた、それ自身のリンクレイヤアドレスを目標に供給している間に目標ノードのリンクレイヤアドレスに対応するIPv6アドレスを要求するInverse NeighborディスカバリーSolicitationメッセージを送ります。 遠隔ノードIPv6アドレスが知られていないので、IPv6オールノードマルチキャスト[IPv6]としてInverse Neighborディスカバリー(IND)懇願を送ります、[IPv6-フラン]、[ENCAPS。] しかしながら、リンクレイヤレベルでは、直接知られているリンクレイヤアドレスによって特定された目標ノードにIND Solicitationを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Conta Standards Track [Page 3] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[3ページ]。
Source Address
An IPv6 address assigned to the interface from which this message
is sent.
このメッセージが送られるインタフェースに割り当てられたソースAddress An IPv6アドレス。
Destination Address
The IPv6 all-node multicast address. This address is specified in
its link-scope format, which is FF02::1.
IPv6オールノードマルチキャストが扱う目的地Address。 このアドレスはFF02であるリンク範囲形式で指定されます:、:1.
Hop Limit 255
ホップ限界255
Authentication Header
If a Security Association for the IP Authentication Header exists
between the sender and the destination, then the sender SHOULD
include this header.
IP Authentication Headerのための認証Header If a Security Associationは送付者と目的地の間に存在していて、次に、送付者SHOULDはこのヘッダーを含んでいます。
ICMP Fields:
ICMP分野:
Type 141
141をタイプしてください。
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
チェックサム、ICMPチェックサム。 [ICMPv6]を見てください。
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
予約されたThis分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Required options:
必要なオプション:
The sender node MUST send the following options in the Solicitation message:
送付者ノードはSolicitationメッセージにおける以下のオプションを送らなければなりません:
Source Link-Layer Address
The link-layer address of the sender.
リンクレイヤが扱う送付者のソースLink-層のAddress。
Target Link-Layer Address
The link-layer address of the target node.
リンクレイヤが扱う目標ノードのLink-層のAddressを狙ってください。
Other valid options:
他の妥当な選択肢:
The sender node MAY choose to add the following options in the Solicitation message:
送付者ノードは、Solicitationメッセージにおける以下のオプションを加えるのを選ぶかもしれません:
Source Address List
The list of one or more IPv6 addresses of the interface identified
by the Source Link-Layer Address. This option is defined in
section 3.
1IPv6のリストが扱うAddress Source Link-層によって特定されたインタフェースのソースAddress List。 このオプションはセクション3で定義されます。
Conta Standards Track [Page 4] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[4ページ]。
MTU
The MTU configured for this link [IPv6-ND].
MTU MTUは[IPv6-ノースダコタ]をこのリンクに構成しました。
Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは別の選択肢タイプを加えるかもしれません。 受信機は、静かに彼らが認識しない少しのオプションも無視して、メッセージを処理し続けなければなりません。
2.2 Inverse Neighbor Discovery Advertisement Message
2.2 逆さの隣人発見広告メッセージ
A node sends Inverse Neighbor Discovery Advertisements in response to Inverse Neighbor Discovery Solicitations.
ノードはInverse NeighborディスカバリーSolicitationsに対応してInverse NeighborディスカバリーAdvertisementsを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IP分野:
Source Address
An address assigned to the interface from which the advertisement
is sent.
広告が送られるインタフェースに割り当てられたソースAddress Anアドレス。
Destination Address
The Source Address of an invoking Inverse Discovery Neighbor
Solicitation.
呼び出しInverseディスカバリーNeighbor Solicitationの目的地Address Source Address。
Hop Limit 255
ホップ限界255
Authentication Header
If a Security Association for the IP Authentication Header exists
between the sender and the destination address, then the sender
SHOULD include this header.
IP Authentication Headerのための認証Header If a Security Associationは送付者と送付先アドレスの間に存在していて、次に、送付者SHOULDはこのヘッダーを含んでいます。
ICMP Fields:
ICMP分野:
Type 142
142をタイプしてください。
Code 0
コード0
Checksum The ICMP checksum. See [ICMPv6].
チェックサム、ICMPチェックサム。 [ICMPv6]を見てください。
Conta Standards Track [Page 5] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[5ページ]。
Reserved 32-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
予約された32ビットの未使用の分野。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Required options:
必要なオプション:
The sender node MUST send the following options in the Advertisement message:
送付者ノードはAdvertisementメッセージにおける以下のオプションを送らなければなりません:
Source Link-Layer Address The link-layer address of the sender.
リンクレイヤが扱う送付者のソースLink-層のAddress。
Target Link-Layer Address
The link-layer address of the target, that is, the sender of
the advertisement.
すなわち、目標のリンクレイヤアドレス、広告の送付者の目標Link-層のAddress。
Target Address List
The list of one or more IPv6 addresses of the interface
identified by the Target Link-Layer Address in the Inverse
Neighbor Discovery Solicitation message that prompted this
advertisement. This option is defined in Section 3.
1IPv6のリストが扱うこの広告をうながしたInverse NeighborディスカバリーSolicitationメッセージのAddress Target Link-層によって特定されたインタフェースのAddress Listを狙ってください。 このオプションはセクション3で定義されます。
Other valid options:
他の妥当な選択肢:
The sender node MAY choose to add the following option in the Advertisement message:
送付者ノードは、Advertisementメッセージにおける以下のオプションを加えるのを選ぶかもしれません:
MTU
The MTU configured for this link [IPv6-ND].
MTU MTUは[IPv6-ノースダコタ]をこのリンクに構成しました。
Future versions of this protocol may add other option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは別の選択肢タイプを加えるかもしれません。 受信機は、静かに彼らが認識しない少しのオプションも無視して、メッセージを処理し続けなければなりません。
3. Inverse Neighbor Discovery Options Formats
3. 逆さの隣人発見オプション形式
Inverse Neighbor Discovery messages include Neighbor Discovery options [IPv6-ND] as well as an Inverse Neighbor Discovery specific options: the Source Address List and the Target Address List.
逆さのNeighborディスカバリーメッセージはNeighborディスカバリーオプションInverse Neighborと同様に[IPv6-ノースダコタ]ディスカバリー特有のオプションを含んでいます: ソース住所録とあて先アドレスはリストアップされています。
3.1 Source/Target Address List
3.1 ソース/目標住所録
The Source Address List and the Target Address List option are TLV options (type, length, variable size field) (see Section 4.6 of [IPv6-ND] with the following fields:
Source Address ListとTarget Address ListオプションはTLVオプション(タイプ、長さ、可変サイズ分野)です。(以下の分野がある[IPv6-ノースダコタ]のセクション4.6を見てください:
Conta Standards Track [Page 6] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[6ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~
|
+-+-+-+-+...
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - + | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | IPv6が+であると扱う+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | IPv6が+であると扱う+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ | +-+-+-+-+...
Fields:
分野:
Type 9 for Source Address List
10 for Target Address List
目標住所録のためのソースアドレスリスト10のために9をタイプしてください。
Note: These Option Type values should be assigned from the IPv6
Neighbor Discovery family of values.
以下に注意してください。 これらのOption Type値は値のIPv6 Neighborディスカバリーファミリーから割り当てられるべきです。
Length The length of the option (including the Type,
Length, and the Reserved fields) in units of 8
octets. The minimum value for Length is 3, for one
IPv6 address.
長さ、8つの八重奏のユニットのオプション(Type、Length、およびReserved分野を含んでいる)の長さ。 Lengthのための最小値は1つのIPv6アドレスのための3です。
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
予約されたThis分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
IPv6 Addresses One or more IPv6 addresses of the interface.
インタフェースのIPv6 Addresses Oneか、より多くのIPv6アドレス。
Conta Standards Track [Page 7] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[7ページ]。
Description:
記述:
The Source Address List contains a list of IPv6 addresses of the interface identified by the Source Link-Layer Address.
Source Address ListはAddress Source Link-層によって特定されたインタフェースのIPv6アドレスのリストを含んでいます。
The Target Address List contains a list of IPv6 addresses of the interface identified by the Target Link-Layer Address.
Target Address ListはAddress Target Link-層によって特定されたインタフェースのIPv6アドレスのリストを含んでいます。
The number of addresses "n" in the list is calculated based on the length of the option:
リストのアドレス「n」の数はオプションの長さに基づいて計算されます:
n = (Length - 1)/2 (Length is the number of groups of 8 octets)
nは/2と等しいです(長さ--1)。(長さは8つの八重奏のグループの数です)
The Source Address List MUST fit in one IND Solicitation message. Therefore in case all IPv6 addresses of an interface do not fit in one messages, the option does not contain a complete list. For a complete list of IPv6 addresses, a node should rely on the IND Advertisement message.
Source Address Listは1つのIND Solicitationメッセージをうまくはめ込まなければなりません。 したがって、インタフェースのすべてのIPv6アドレスが1つのメッセージをうまくはめ込まないといけないので、オプションは全リストを含んでいません。 IPv6アドレスの全リストに関しては、ノードはIND Advertisementメッセージを当てにするはずです。
The Target Address List SHOULD be the complete list of addresses of the interface identified by the Target Link-Layer Address. If the list of IPv6 addresses of an interface does not fit in one IND Advertisement message, one or more IND Advertisement messages, with the same fields as the first message, SHOULD follow. The Target Address List option(s) of the second, and subsequent message(s) SHOULD contain the rest of the IPv6 addresses of the interface identified by the Target Link-Layer Address, which did not fit in the first message.
Target Address List SHOULD、Address Target Link-層によって特定されたインタフェースのアドレスに関する全リストになってください。 インタフェースのIPv6アドレスのリストが1つのIND Advertisementメッセージをうまくはめ込まないなら、1つ以上のIND Advertisementメッセージであり、最初のメッセージと同じ分野と共に、SHOULDは続きます。 2番目のTarget Address Listオプション、およびSHOULDが最初のメッセージをうまくはめ込まなかったAddress Target Link-層によって特定されたインタフェースのIPv6アドレスの残りを含んでいるというその後のメッセージ。
Note 1: The scope of the Inverse Neighbor Discovery mechanism is limited to IPv6 address discovery, that is, providing address mapping information. Therefore, it does not make any provisions or rules regarding how a node uses the addresses that were returned in an Inverse Discovery message. Furthermore, it does not exclude any particular type of IPv6 address from the Source or Target Address
注意1: Inverse Neighborディスカバリーメカニズムの範囲はIPv6アドレス発見に制限されて、すなわち、提供はアドレスマッピング情報です。 したがって、それはノードがどうInverseディスカバリーメッセージで返されたアドレスを使用するかに関するどんな条項や規則も作りません。 その上、それはどんな特定のタイプのIPv6アドレスもSourceかTarget Addressに入れないようにしません。
List. For example, if an interface has manually configured, and autoconfigured addresses, including temporary ones, unicast, multicast, etc..., the list should not exclude any.
記載してください。 例えば、インタフェースが手動でアドレスを構成して、自動構成したなら、一時的なもの、ユニキャスト、マルチキャストなどを含んでいます。, リストはいずれも除くはずがありません。
Note 2: An implementation MUST NOT send duplicates in the IPv6 address list.
注意2: 実装はIPv6住所録の写しを送ってはいけません。
Conta Standards Track [Page 8] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[8ページ]。
4. Inverse Neighbor Discovery Protocol
4. 逆さの隣人発見プロトコル
IND operates essentially the same as ND [IPv6-ND]: the solicitor of a target IP address sends on an interface a solicitation message, the target node responds with an advertisement message containing the information requested. The information learned MAY be stored in the Neighbor Discovery cache [IPv6-ND], as well as IPv6 address structures which may be associated with the interface.
INDはノースダコタ[IPv6-ノースダコタ]として本質的には同じように作動します: 目標IPアドレスの事務弁護士はインタフェースで懇願メッセージを送って、広告メッセージが要求された情報を含んでいて、目標ノードは応じます。 学習された情報はNeighborディスカバリーキャッシュ[IPv6-ノースダコタ]で保存されるかもしれません、インタフェースに関連するかもしれないIPv6アドレス構造と同様に。
4.1 Sender Node Processing
4.1 送付者ノード処理
A soliciting node formats an IND Solicitation message as defined in a previous section, encapsulates the packet for the specific link-layer and sends it directly to the target node. Although the destination IP address is the all-node multicast address, the message is sent only to the target node. The significant fields for the IND protocol are the Source IP address, the Source link-layer address, the Target link-layer address, and the MTU. The latter can be used in setting the optimum value of the MTU for the link.
請求ノードは、前項で定義されるようにIND Solicitationメッセージをフォーマットして、特定のリンクレイヤのためにパケットをカプセルに入れって、直接目標ノードにそれを送ります。 送付先IPアドレスはオールノードマルチキャストアドレスですが、目標ノードだけにメッセージを送ります。 INDプロトコルのための重要な分野は、Source IPアドレスと、Sourceリンクレイヤアドレスと、Targetリンクレイヤアドレスと、MTUです。 MTUの最適値をリンクに設定する際に後者を使用できます。
While awaiting a response, the sender SHOULD retransmit IND Solicitation messages approximately every RetransTimer (expiration)[IPv6-ND], even in the absence of additional traffic to the neighbor. Retransmissions MUST be rate-limited to at most one solicitation per neighbor every RetransTimer.
応答を待っている間、送付者SHOULDはおよそあらゆるRetransTimer(満了)[IPv6-ノースダコタ]の、そして、隣人への追加トラフィックがないとき同等のIND Solicitationメッセージを再送します。 Retransmissionsはレートで1隣人ほとんどの1つの懇願のあらゆるRetransTimerに限らなければなりません。
If no IND Advertisement is received after MAX_MULTICAST_SOLICIT [IPv6-ND] solicitations, inverse address resolution has failed. If the sending of the Solicitation was required by an upper-layer, the sender module MUST notify the error to the upper-layer through an appropriate mechanism (e.g., return value from a procedure call).
マックス_MULTICAST_SOLICIT[IPv6-ノースダコタ]懇願の後にIND Advertisementを全く受け取らないなら、逆さのアドレス解決は失敗しました。 Solicitationの発信が上側の層によって必要とされたなら、送付者モジュールは適切な手段を通して上側の層に誤りに通知しなければなりません(例えば、手順呼び出しから値を返してください)。
4.2 Receiver Node Processing
4.2 受信機ノード処理
4.2.1 Processing Inverse Neighbor Solicitation Messages
4.2.1 処理の逆さの隣人懇願メッセージ
For every IND Solicitation, the receiving node SHOULD format in response a proper IND Advertisement using the link-layer source and target address pair as well as the IPv6 source address from the IND Solicitation message.
あらゆるIND Solicitationに関しては、受信ノードSHOULDは、応答でIND SolicitationメッセージからのIPv6ソースアドレスと同様にリンクレイヤソースとあて先アドレス組を使用することで適切なIND Advertisementをフォーマットします。
If a node updates the Neighbor Discovery Cache with information learned from IND messages, the receiver node of the IND Solicitation SHOULD put the sender's IPv6 address/link-layer address mapping - i.e., the source IP address and the Source link-layer address from the solicitation message - into its ND cache [IPv6-ND] as it would for a ND solicitation.
情報がINDメッセージから学習されている状態でノードがNeighborディスカバリーCacheをアップデートするなら、IND Solicitation SHOULDの受信機ノードは送付者のIPv6リンクレイヤアドレス/アドレス・マッピングを置きました--すなわち、アドレスとSourceリンクレイヤがノースダコタの懇願のために演説するように懇願メッセージからノースダコタキャッシュ[IPv6-ノースダコタ]に演説するソースIP。
Conta Standards Track [Page 9] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[9ページ]。
Because IPv6 nodes may have multiple IPv6 addresses per interface, a node responding to an IND Solicitation SHOULD return in the Target Address List option a list containing one or more IPv6 addresses corresponding to the interface identified by the Target Link-Layer Address field in the solicitation message. The list MUST not contain duplicates.
IPv6ノードには複数の1インタフェースあたりのIPv6アドレスがあるかもしれないので、Target Address Listオプションで1IPv6を入れてあるリストをIND Solicitation SHOULDリターンに反応させるノードは懇願メッセージでTarget Link-層のAddress分野によって特定されたインタフェースとの対応を扱います。 リストは写しを含んではいけません。
4.2.2 Processing Inverse Neighbor Advertisement Messages
4.2.2 処理の逆さの隣人広告メッセージ
If a node updates The Neighbor Discovery Cache with information learned from IND messages, the receiver node of the IND advertisement SHOULD put the sender's IPv6 address/link-layer address mapping - i.e., the IP addresses from Target addresses list and the Source link-layer address from the IND advertisement message - into its ND cache [IPv6-ND] as it would for a ND advertisement.
ノースダコタ広告のために置いたでしょう、したがって、情報がINDメッセージから学習されている状態でノードがNeighborディスカバリーCacheをアップデートするなら、IND広告SHOULDの受信機ノードはすなわち、IPが、TargetアドレスからリストとSourceがIND広告メッセージからのリンクレイヤアドレスであると扱うという送付者のIPv6リンクレイヤアドレス/アドレス・マッピングをノースダコタキャッシュ[IPv6-ノースダコタ]に置きました。
4.3 Message Validation
4.3 メッセージ合法化
Inverse Neighbor Discovery messages are validated as follows:
逆さのNeighborディスカバリーメッセージは以下の通り有効にされます:
4.3.1 Validation of Inverse Neighbor Discovery Solicitations
4.3.1 逆さの隣人発見懇願の合法化
A node MUST silently discard any received Inverse Neighbor Solicitation messages that do not satisfy all of the following validity checks:
ノードは静かに以下のバリディティチェックのすべてを満たさないどんな受信されたInverse Neighbor Solicitationメッセージも捨てなければなりません:
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- IP Hop Limit分野には、255の値があります、すなわち、ルータはパケットを進めることができませんでした。
- If the message includes an IP Authentication Header, the
message authenticates correctly.
- メッセージはIP Authentication Header、メッセージを含んでいます。正しく、認証します。
- ICMP Checksum is valid.
- ICMP Checksumは有効です。
- ICMP Code is 0.
- ICMP Codeは0歳です。
- ICMP length (derived from the IP length) is 24 or more
octets.
- ICMPの長さ(IPの長さから、派生する)は24以上の八重奏です。
- The Target Link-Layer Address is a required option and MUST
be present.
- Address Target Link-層は、必要なオプションであり、存在していなければなりません。
- The Source Link-Layer Address is a required option and MUST
be present.
- Address Source Link-層は、必要なオプションであり、存在していなければなりません。
- All included options have a length that is greater than
zero.
- すべての含まれているオプションには、ゼロ以上である長さがあります。
Conta Standards Track [Page 10] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[10ページ]。
The content of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
Reserved分野、およびどんな認識されていないオプションの内容も無視しなければなりません。 プロトコルへの将来的で、後方コンパチブル変化は、Reserved分野のコンテンツを指定するか、または新しいオプションを加えるかもしれません。 後方の非互換な変化は異なったCode値を使用するかもしれません。
The contents of any Neighbor Discovery [IPv6-ND] options that are not specified to be used with Inverse Neighbor Discovery Solicitation messages MUST be ignored and the packet processed as normal. The only defined option that may appear besides the required options is the MTU option.
Inverse NeighborディスカバリーSolicitationメッセージと共に使用されるために指定されない少しのNeighborディスカバリー[IPv6-ノースダコタ]オプションのコンテンツも無視しなければなりませんでした、そして、パケットは標準として処理されました。 必要なオプション以外に現れるかもしれない唯一の定義されたオプションがMTUオプションです。
An Inverse Neighbor Solicitation that passes the validity checks is called a "valid solicitation".
バリディティチェックを通過するInverse Neighbor Solicitationは「有効な懇願」と呼ばれます。
4.3.2 Validation of Inverse Neighbor Discovery Advertisements
4.3.2 逆さの隣人発見広告の合法化
A node MUST silently discard any received Inverse Neighbor Discovery Advertisement messages that do not satisfy all of the following validity checks:
ノードは静かに以下のバリディティチェックのすべてを満たさないどんな受信されたInverse NeighborディスカバリーAdvertisementメッセージも捨てなければなりません:
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- IP Hop Limit分野には、255の値があります、すなわち、ルータはパケットを進めることができませんでした。
- If the message includes an IP Authentication Header, the
message authenticates correctly.
- メッセージはIP Authentication Header、メッセージを含んでいます。正しく、認証します。
- ICMP Checksum is valid.
- ICMP Checksumは有効です。
- ICMP Code is 0.
- ICMP Codeは0歳です。
- ICMP length (derived from the IP length) is 48 or more
octets.
- ICMPの長さ(IPの長さから、派生する)は48以上の八重奏です。
- Source Link-Layer Address option is present.
- ソースLink-層のAddressオプションは存在しています。
- Target Link-Layer Address option is present.
- 目標Link-層のAddressオプションは存在しています。
- The Target Address List option is present.
- Target Address Listオプションは存在しています。
- The length of the Target Address List option is at least 3.
- Target Address Listオプションの長さは少なくとも3です。
- All other included options have a length that is greater
than zero.
- 他のすべての含まれているオプションには、ゼロ以上である長さがあります。
The contents of the Reserved fields, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved fields or add new options; backward-incompatible changes may use different Code values.
Reserved分野、およびどんな認識されていないオプションのコンテンツも無視しなければなりません。 プロトコルへの将来的で、後方コンパチブル変化は、Reserved分野のコンテンツを指定するか、または新しいオプションを加えるかもしれません。 後方の非互換な変化は異なったCode値を使用するかもしれません。
Conta Standards Track [Page 11] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[11ページ]。
The contents of any defined options [IPv6-ND] that are not specified to be used with Inverse Neighbor Advertisement messages MUST be ignored and the packet processed as normal. The only defined option that may appear besides the required options is the MTU option.
Inverse Neighbor Advertisementメッセージと共に使用されるために指定されない少しの定義されたオプション[IPv6-ノースダコタ]のコンテンツも無視しなければなりませんでした、そして、パケットは標準として処理されました。 必要なオプション以外に現れるかもしれない唯一の定義されたオプションがMTUオプションです。
An Inverse Neighbor Advertisement that passes the validity checks is called a "valid advertisement".
バリディティチェックを通過するInverse Neighbor Advertisementは「有効な広告」と呼ばれます。
5. Security Considerations
5. セキュリティ問題
When being employed on point to point virtual circuits, as it is the case with Frame Relay networks, Inverse Neighbor Discovery messages are less sensitive to impersonation attacks from on-link nodes, as it would be the case with broadcast links.
仮想の回路を指すのにそれがFrame Relayネットワークがあるケースであるようにポイントの上で使われる場合、Inverse Neighborディスカバリーメッセージはそれほどリンクの上のノードからのものまね攻撃に機密ではありません、それが放送リンクがあるケースであるだろうというように。
Like Neighbor Discovery, the protocol reduces the exposure to threats from off-link nodes in the absence of authentication by ignoring IND packets received from off-link senders. The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor.
Neighborディスカバリーのように、プロトコルはオフリンク送付者から受け取られたINDパケットを無視するのによる認証がないときオフリンクノードから暴露を脅威に減少させます。 すべての容認されたパケットのHop Limit分野は、255、最大の正当な値を含むように確かめられます。 ルータがそれらが進めるすべてのパケットでHop Limitを減少させるので、255のHop Limitを含む容認されたパケットは隣人から発したに違いありません。
Inverse Neighbor Discovery protocol packet exchanges can be authenticated using the IP Authentication Header [IPSEC-Auth]. A node SHOULD include an Authentication Header when sending Inverse Neighbor Discovery packets if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol.
IP Authentication Header[IPSEC-Auth]を使用することで逆さのNeighborディスカバリープロトコルパケット交換を認証できます。 IP Authentication Headerとの使用のためのセキュリティ協会が送付先アドレスのために存在するならディスカバリーパケットをInverse Neighborに送るとき、ノードSHOULDはAuthentication Headerを含んでいます。 セキュリティ協会は手動の構成を通して、または、何らかのかぎ管理プロトコルの操作を通して創設されたかもしれません。
Received Authentication Headers in Inverse Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored.
正当性のためにInverse Neighborディスカバリーパケットの容認されたAuthentication Headersについて確かめなければなりません、そして、不正確な認証があるパケットを無視しなければなりません。
In case of use with Frame Relay, to avoid an IP Security Authentication verification failure, the Frame Relay specific preprocessing of a Neighbor Discovery Solicitation message that contains a DLCI format Source link-layer address option, MUST be done by the receiver node after it completed IP Security processing.
Frame Relayとの使用の場合には、IP Security処理を終了した後にIPを避けるために、受信機ノードはSecurity Authentication検証の故障(DLCI形式Sourceリンクレイヤアドレスオプションを含むNeighborディスカバリーSolicitationメッセージのFrame Relayの特定の前処理)をしなければなりません。
It SHOULD be possible for the system administrator to configure a node to ignore any Inverse Neighbor Discovery messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages.
それ、SHOULD、システム管理者がAuthentication HeaderかEncapsulating Security有効搭載量を使用することで認証されないどんなInverse Neighborディスカバリーメッセージも無視するためにノードを構成するのにおいて、可能であってください。 許容へのそのようなスイッチSHOULDデフォルトはメッセージを非認証しました。
Conta Standards Track [Page 12] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[12ページ]。
Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC- ESP].
秘密性問題はIP Security ArchitectureとIP Encapsulating Security有効搭載量ドキュメント[IPSEC]、[IPSEC超能力]によって扱われます。
6. IANA Considerations
6. IANA問題
IANA was requested to assign two new ICMPv6 type values, as described in Section 2.1 and 2.2. They were assigned from the Informational range of messages, as defined in Section 2.1 of RFC 2463. There were no ICMPv6 code values defined for these types (other than 0); future assignments are to be made under Standards Action as defined in RFC 2434.
セクション2.1と2.2で説明されるようにIANAが2つの新しいICMPv6タイプ値を割り当てるよう要求されました。 それらはRFC2463のセクション2.1で定義されるようにメッセージのInformational範囲から割り当てられました。 これらのタイプ(0を除いた)のために定義されたICMPv6コード値が全くありませんでした。 将来の課題はRFC2434で定義されるようにStandards Actionの下で作られていることです。
IANA was also requested to assign two new ICMPv6 Neighbor Discovery Option types as defined in Section 3.1. No outside reviewing was necessary.
また、IANAがセクション3.1で定義されるように2つの新しいICMPv6 NeighborディスカバリーOptionタイプを選任するよう要求されました。 外の論評は必要ではありませんでした。
7. Acknowledgments
7. 承認
Thanks to Steve Deering, Thomas Narten and Erik Nordmark for discussing the idea of Inverse Neighbor Discovery. Thanks to Thomas Narten, and Erik Nordmark, and also to Dan Harrington, Milan Merhar, Barbara Fox, Martin Mueller, and Peter Tam for a thorough reviewing.
スティーブ・デアリング、トーマスNarten、およびエリックNordmarkとInverse Neighborディスカバリーの考えについて議論してくださってありがとうございます。 徹底的な論評をトーマスNarten、およびエリックNordmarkと、そして、ダン・ハリントン、ミラノMerharと、バーバラフォックスと、マーチン・ミューラーと、ピーター・タムをもありがとうございます。
Also it should be acknowledged that parts of the text in this specification derived from the IPv6 Neighbor Discovery text [IPv6- ND].
また、この仕様によるテキストの部分がIPv6 Neighborからディスカバリーテキスト[IPv6ノースダコタ]を引き出したと認められるべきです。
8. References
8. 参照
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[IPv6] デアリングとS.とR.Hinden、「インターネットプロトコルバージョン6仕様」、RFC2460、1998年12月。
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[IPv6-ノースダコタ]のNarten、T.、Nordmark、E.、およびW.シンプソンを「IPバージョン6(IPv6)のために発見を近所付き合いさせる」、RFC2461、12月1998日
[ICMPv6] Conta, A., and S. Deering "Internet Control Message
Protocol for the Internet Protocol Version 6", RFC
2463, December 1998.
「インターネットコントロールメッセージはインターネットプロトコルバージョン6インチ、RFC2463、1998年12月に議定書の中で述べる」[ICMPv6]コンタ、A.、およびS.デアリング。
[IPv6-FR] Conta, A., Malis, A. and M. Mueller, "Transmission of
IPv6 Packets over Frame Relay Networks", RFC 2590, May
1999. December 1997.
[IPv6-FR] コンタ、A.、Malis、A.、およびM.ミューラー(「フレームリレーネットワークの上のIPv6パケットのトランスミッション」、RFC2590)は1999がそうするかもしれません。 1997年12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[IPSEC] アトキンソンとR.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
Conta Standards Track [Page 13] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[13ページ]。
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header",
RFC 2402, December 1998.
[IPSEC-Auth] アトキンソンとR.とS.ケント、「IP認証ヘッダー」、RFC2402、1998年12月。
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[IPSEC-超能力] アトキンソンとR.とS.ケント、「セキュリティがプロトコル(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[ASSIGN] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, March 1994.
[割り当てます] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年3月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect
over Frame Relay", RFC 2427, November 1998.
[ENCAPS] ブラウンとC.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC2427、1998年11月。
[INV-ARP] Bradley, T., Brown, C. and A. Malis "Inverse Address
Resolution Protocol", RFC 2390, August 1998.
[INV-ARP] ブラッドリーとT.とブラウンとC.とA.Malis「逆さのアドレス解決プロトコル」、RFC2390、1998年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9. Authors' Addresses
9. 作者のアドレス
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484
ct06484のアレックスコンタTranswitch社3のエンタープライズDriveシェルトン
Phone: +1-203-929-8810 EMail: aconta@txc.com
以下に電話をしてください。 +1-203-929-8810 メールしてください: aconta@txc.com
Conta Standards Track [Page 14] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[14ページ]。
Appendix A
付録A
A. Inverse Neighbor Discovery with Frame Relay Networks
A。 フレームリレーネットワークとの逆さの隣人発見
This appendix documents the details of using the Inverse Neighbor Discovery on Frame Relay Networks, which were too specific to be part of the more general content of the previous sections.
この付録は前項の、より一般的な内容の一部であるように思えないほど特定であったFrame Relay NetworksでInverse Neighborディスカバリーを使用する詳細を記録します。
A.1 Introduction
A.1序論
The Inverse Neighbor Discovery (IND) specifically applies to Frame Relay nodes. Frame Relay permanent virtual circuits (PVCs) and switched virtual circuits (SVCs) are identified in a Frame Relay network by a Data Link Connection Identifier (DLCI). Each DLCI defines for a Frame Relay node a single virtual connection through the wide area network (WAN). A DLCI has in general a local significance.
Inverse Neighborディスカバリー(IND)は明確にFrame Relayノードに適用されます。 フレームRelay相手固定接続(PVCs)と交換仮想回路(SVCs)はFrame RelayネットワークでData Link Connection Identifier(DLCI)によって特定されます。 各DLCIはFrame Relayノードのために広域ネットワーク(WAN)を通した単独の仮想接続を定義します。 一般に、DLCIには、ローカルの意味があります。
By way of specific signaling messages, a Frame Relay network may announce to a node a new virtual circuit with its corresponding DLCI. The DLCI identifies to a node a virtual circuit, and can be used as the equivalent of a remote node link-layer address, allowing a node to identify at link layer level the node at the other end of the virtual circuit. For instance in Figure 1., node A (local node) identifies the virtual circuit to node B (remote node) by way of DLCI = 30. However, the signaling message does not contain information about the DLCI used by a remote node to identify the virtual circuit to the local node, which could be used as the equivalent of the local link-layer address. For instance in Figure 1., node B (remote node) may identify the virtual circuit to node A by way of DLCI = 62.
特定のシグナリングメッセージを通して、Frame Relayネットワークは対応するDLCIと共に新しい仮想の回路をノードに発表するかもしれません。 DLCIは仮想の回路をノードに特定して、遠隔ノードリンクレイヤアドレスの同等物として使用できます、ノードが仮想の回路のもう一方の端でリンクレイヤレベルでノードを特定するのを許容して。 例えば、図1.では、ノードA(ローカルのノード)はDLCI=30を通してノードB(遠隔ノード)に仮想の回路を特定します。 しかしながら、シグナリングメッセージは遠隔ノードによって使用される、ローカルのリンクレイヤアドレスの同等物として使用できたローカルのノードに仮想の回路を特定するDLCIの情報を含んでいません。 例えば、図1.では、ノードB(遠隔ノード)はDLCI=62を通してノードAに仮想の回路を特定するかもしれません。
Furthermore, the message being transmitted at link-layer level and completely independent of the IPv6 protocol does not include any IPv6 addressing information. The Inverse Neighbor Discovery is a protocol that allows a Frame Relay node to discover the equivalent of a local link layer address, that is, the identifier by way of which remote nodes identify the node, and more importantly discover the IPv6 addresses of the interface at the other end of the virtual circuit, identified by the remote link-layer address.
その上、リンクレイヤレベルにおいて完全にIPv6プロトコルの如何にかかわらず送られるメッセージは少しのIPv6アドレス指定情報も含んでいません。 Inverse NeighborディスカバリーはFrame Relayノードがアドレス(すなわち、識別子を通って遠隔ノードがノードを特定して、仮想の回路のもう一方の端で、より重要にインタフェースのIPv6アドレスを発見する)がリモートリンクレイヤアドレスで特定した地方のリンクレイヤの同等物を発見できるプロトコルです。
Conta Standards Track [Page 15] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[15ページ]。
~~~~~~~~~~~ Remote
{ } Node
+-----+ DLCI { } DLCI+-----+
| A |-30------{--+----+----+--}---------62-| B |
+-----+ { } +-----+
Local { } Frame Relay
Node ~~~~~~~~~~~ Network Cloud
Figure 1.
~~~~~~~~~~~ リモートである、ノード+-----+ DLCI、DLCI+-----+ | A|-30------{--+----+----+--}---------62-| B| +-----+ { } +-----+ ローカル、フレームリレーノード~~~~~~~~~~~ 雲の図1をネットワークでつないでください。
The IPv6 Inverse Neighbor Discovery (IND) protocol allows a Frame Relay node to discover dynamically the DLCI by which a remote node identifies the virtual circuit. It also allows a node to learn the IPv6 addresses of a node at the remote end of a virtual circuit.
IPv6 Inverse Neighborディスカバリー(IND)プロトコルで、Frame Relayノードはダイナミックに、遠隔ノードが仮想の回路を特定するDLCIを発見できます。 また、それで、ノードは仮想の回路のリモートエンドでノードのIPv6アドレスを学ぶことができます。
A.2. Inverse Neighbor Discovery Messages
A.2。 逆さの隣人発見メッセージ
Frame Relay nodes generate Inverse Neighbor Discovery messages as follows:
フレームRelayノードは、Inverse Neighborディスカバリーが以下のメッセージであると生成します:
A.2.1. Inverse Neighbor Discovery Solicitation Message
A.2.1。 逆さの隣人発見懇願メッセージ
The sender of an Inverse Neighbor Discovery Solicitation does not know the remote node's IPv6 addresses, but knows the equivalent of a remote node link-layer address. Inverse Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level, an IND Solicitation is sent directly to the target node, identified by the known link-layer address (DLCI).
Inverse NeighborディスカバリーSolicitationの送付者は、遠隔ノードのIPv6が遠隔ノードリンクレイヤアドレスの同等物を扱いますが、知っているのを知りません。 IPv6オールノードマルチキャスト[IPv6]、[IPv6-フラン][ENCAPS]として逆さのNeighborディスカバリー(IND)懇願を送ります。 しかしながら、リンクレイヤレベルでは、直接アドレス(DLCI)知られているリンクレイヤによって特定された目標ノードにIND Solicitationを送ります。
The fields of the message, which are filled following considerations specific to Frame Relay are:
メッセージの分野(Frame Relayに特定のいっぱいにされた次の問題である)は以下の通りです。
Source Link-Layer Address
For the sender Frame Relay node, the Source Link-Layer Address is
the equivalent of the link-layer address by which the remote node
identifies the source of this message. The sender may have no
knowledge of this information. If the sender knows the
information, it SHOULD include it in the field, otherwise it
SHOULD live it zero (empty). This information, if present, can be
used for network debugging purposes. Regardless of the sender's
action on this field, prior to any Inverse Neighbor Discovery
processing, the receiver of this message replaces this field,
whether filled in or not by the sender, with information carried
by the Frame Relay header in the DLCI field. The field is encoded
in DLCI format as defined by [IPv6-FR].
送付者Frame Relayノード、ソースLink-層のAddress For Address Source Link-層は遠隔ノードがこのメッセージの源を特定するリンクレイヤアドレスの同等物です。 送付者には、この情報に関する知識が全くないかもしれません。 SHOULDはそうでなければ、分野、それにSHOULDライブな状態でそれを含んでいます。送付者が情報を知っているならそれ、それはゼロに合わせます(空にします)。 存在しているなら、ネットワークデバッグ目的にこの情報を使用できます。 このフィールドへの送付者の動作にかかわらず、どんなInverse Neighborディスカバリー処理の前にもこのメッセージの受信機はこの野原を取り替えます、送付者によって記入されるか否かに関係なく、情報がDLCI分野のFrame Relayヘッダーによって運ばれている状態で。 [IPv6-FR]によって定義されるように分野はDLCI形式でコード化されます。
Conta Standards Track [Page 16] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[16ページ]。
Target Link-Layer Address
For sender Frame Relay node, the Target Link-Layer Address field
is filled with the value known as the equivalent of the target
node link-layer address. This value is the DLCI of the VC to the
target node. It is encoded in DLCI format [IPv6-FR].
目標Link-層のAddress For送付者Frame Relayノード、Target Link-層のAddress分野は目標ノードリンクレイヤアドレスの同等物として知られている値で満たされます。 この値は目標ノードへのVCのDLCIです。 それはDLCI形式[IPv6-FR]でコード化されます。
To illustrate the generating of a IND Solicitation message by a
Frame Relay node, let's consider as an example Node A (Figure 1.)
which sends an IND solicitation to Node B. The Solicitation
message fields will have the following values:
Frame RelayノードでIND Solicitationメッセージを生成することを例証するために、SolicitationメッセージがさばくNode B.にIND懇願を送る例のNode A(図1)が以下の値を持つとき、考えましょう:
At Node A (sender of the IND solicitation message).
Node A(IND懇願メッセージの送付者)で。
Source Link-Layer Address
DLCI=unknown (overwritten by the receiver).
ソースLink-層のAddress DLCIは未知(受信機で、上書きされる)と等しいです。
Target Link-Layer Address
DLCI=30.
リンクレイヤアドレスDLCI=30を狙ってください。
At Node B (receiver of the IND solicitation message).
Node B(IND懇願メッセージの受信機)で。
Source Link-Layer Address
DLCI=62 (filled in by the receiver).
ソースLink-層のAddress DLCI=62(受信機で、記入されます)。
Target Link-Layer Address
DLCI=30.
リンクレイヤアドレスDLCI=30を狙ってください。
Note: For Frame Relay, both the above addresses are in Q.922 format (DLCI), which can have 10 (default), or 23 significant addressing bits [IPv6-FR]. The option length (link-layer address) is expressed in 8 octet units, therefore, the DLCI will have to be extracted from the 8 bytes based on the EA field (bit 0) of the second, third, or forth octet (EA = 1). The C/R, FECN, BECN, DE fields in the Q.922 address have no significance for IND and are set to 0 [IPv6-FR].
以下に注意してください。 Frame Relayに関しては、両方の上のアドレスがQ.922形式(DLCI)か重要な23アドレシングビット[IPv6-FR]にあります。(形式は10(デフォルト)を持つことができます)。 オプションの長さ(リンクレイヤアドレス)は8八重奏ユニットで表されました、したがって、8バイトから抽出されるために意志にはあるDLCIが2番目のEAフィールド(ビット0)の上3番目、または先へ八重奏(EA=1)の拠点を置きました。 C/R、FECN、Q.922住所のBECN、DE分野は、INDのために意味を全く持たないで、0[IPv6-FR]に設定されます。
MTU
The value filled in the MTU option is the MTU for the virtual
circuit identified by the known DLCI [IPv6-FR].
値がMTUオプションでいっぱいにしたMTUは知られているDLCI[IPv6-FR]によって特定された仮想の回路へのMTUです。
A.2.2 Inverse Neighbor Discovery Advertisement Message
A.2.2の逆さの隣人発見広告メッセージ
A Frame Relay node sends Inverse Neighbor Discovery Advertisements in response to Inverse Neighbor Discovery Solicitations.
Frame RelayノードはInverse NeighborディスカバリーSolicitationsに対応してInverse NeighborディスカバリーAdvertisementsを送ります。
The fields of the message, which are filled following considerations specific to Frame Relay are:
メッセージの分野(Frame Relayに特定のいっぱいにされた次の問題である)は以下の通りです。
Conta Standards Track [Page 17] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[17ページ]。
Source Link-Layer Address
For Frame Relay, this field is copied from the Target link-layer
address field of the Inverse Neighbor Discovery Solicitation. It
is encoded in DLCI format [IPv6-FR].
ソースLink-層のAddress For Frame Relay、この分野はInverse NeighborディスカバリーSolicitationのTargetリンクレイヤアドレス・フィールドからコピーされます。 それはDLCI形式[IPv6-FR]でコード化されます。
Target Link-Layer Address
For Frame Relay, this field is copied from the Source link-layer
address field of the Inverse Neighbor Discovery Solicitation. It
is encoded in DLCI format [IPv6-FR].
目標Link-層のAddress For Frame Relay、この分野はInverse NeighborディスカバリーSolicitationのSourceリンクレイヤアドレス・フィールドからコピーされます。 それはDLCI形式[IPv6-FR]でコード化されます。
For example if Node B (Figure 1.) responds to an IND solicitation sent by Node A. with an IND advertisement, these fields will have the following values:
例えば、Node B(図1)がIND広告と共にNode A.によって送られたIND懇願に応じると、これらの分野には、以下の値があるでしょう:
At Node B (sender of the advertisement message):
Node B(広告メッセージの送付者)で:
Source Link-Layer Address
DLCI=30 (was Target in Solicitation Message).
ソースリンクレイヤアドレスDLCI=30(懇願メッセージでは、目標でした)。
Target Link-Layer Address
DLCI=62 (was Source in Solicitation Message).
リンクレイヤアドレスDLCI=62(懇願メッセージでは、ソースであった)を狙ってください。
At Node A (receiver of the advertisement message from B).
Node A(Bからの広告メッセージの受信機)で。
Source Link-Layer Address
DLCI=30 (was Target in Solicitation Message).
ソースリンクレイヤアドレスDLCI=30(懇願メッセージでは、目標でした)。
Target Link-Layer Address
DLCI=62 (was Source in Solicitation Message).
リンクレイヤアドレスDLCI=62(懇願メッセージでは、ソースであった)を狙ってください。
Target Address List
The list of one or more IPv6 addresses of the interface identified
by the Target Link-Layer Address in the Inverse Neighbor Discovery
Solicitation message that prompted this advertisement.
1IPv6のリストが扱うこの広告をうながしたInverse NeighborディスカバリーSolicitationメッセージのAddress Target Link-層によって特定されたインタフェースのAddress Listを狙ってください。
MTU The MTU configured for this link (virtual circuit) [IPv6-ND].
MTU MTUはこのリンク(仮想の回路)に[IPv6-ノースダコタ]を構成しました。
Note: In case of Frame Relay networks, the IND messages are sent
on a virtual circuit, which acts like a virtual-link. If the
virtual circuit breaks, all participants to the circuit receive
appropriate link layer signaling messages, which can be propagated
to the upper layers, including IPv6.
以下に注意してください。 Frame Relayネットワークの場合には、INDメッセージを仮想の回路に送ります。(それは、仮想のリンクのように作動します)。 仮想の回路が壊れるなら、回路へのすべての関係者が適切なリンクレイヤシグナリングメッセージを受け取ります、IPv6を含んでいて。(上側の層にメッセージを伝播できます)。
A.3. Inverse Neighbor Discovery Protocol
A.3。 逆さの隣人発見プロトコル
This section of the appendix documents only the specific aspects of Inverse Neighbor Discovery with Frame Relay Networks.
付録のこのセクションはFrame Relay Networksと共にInverse Neighborディスカバリーの特定の局面だけを記録します。
Conta Standards Track [Page 18] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[18ページ]。
A.3.1 Sender Node Processing
A.3.1送付者ノード処理
A soliciting Frame Relay node formats an IND solicitation message as defined in a previous section, encapsulates the packet for the Frame Relay link-layer [IPv6-FR] and sends it to the target Frame Relay node. Although the destination IP address is the IPv6 all-node multicast address, the message is sent only to the target Frame Relay node. The target node is the known remote node on the link represented by the virtual circuit.
請求しているFrame Relayノードは、前項で定義されるようにIND懇願メッセージをフォーマットして、Frame Relay[IPv6-FR]リンクレイヤのためにパケットをカプセルに入れって、目標Frame Relayノードにそれを送ります。 送付先IPアドレスはIPv6オールノードマルチキャストアドレスですが、目標Frame Relayノードだけにメッセージを送ります。 目標ノードは仮想の回路によって表されたリンクの上の知られている遠隔ノードです。
A.3.2 Receiver Node Processing
A.3.2受信機ノード処理
A.3.2.1 Processing Inverse Neighbor Solicitation Messages
A.3.2.1の処理の逆さの隣人懇願メッセージ
A Frame Relay node, before further processing, is replacing in the Source link-layer address the existent DLCI value with the DLCI value from the Frame Relay header of the frame containing the message. The DLCI value has to be formatted appropriately in the Source link-layer address field [IPv6-FR]. This operation is required to allow a correct interpretation of the fields in the further processing of the IND solicitation message.
メッセージを含んでいて、Frame Relayノードはさらに処理する前に、Sourceリンクレイヤアドレスで目下のDLCI値をフレームのFrame RelayヘッダーからDLCI値に取り替える予定です。 DLCI値はSourceリンクレイヤアドレス・フィールド[IPv6-FR]で適切にフォーマットされなければなりません。 この操作が、IND懇願メッセージのさらなる処理における、分野の正しい解釈を許容するのに必要です。
For a Frame Relay node, the MTU value from the solicitation message MAY be used to set the receiver's MTU to a value that is more optimal, in case that was not already done at the interface configuration time.
Frame Relayノードに関しては、懇願メッセージからのMTU値は、より最適の値に受信機のMTUを設定するのに使用されるかもしれません、インタフェース構成時間に既にそれをしないといけなかったので。
A.3.2.2 Processing Inverse Neighbor Advertisement Messages
A.3.2.2の処理の逆さの隣人広告メッセージ
The receiver Frame Relay node of the IND Advertisement MAY put the sender's IPv6 address/link-layer address mapping - i.e., the Target IP addresses and the Source link-layer address from the IND advertisement message - into its ND cache [IPv6-ND] as it would for a ND Advertisement.
IND Advertisementの受信機Frame RelayノードはノースダコタAdvertisementのために置くように送付者のIPv6リンクレイヤアドレス/アドレス・マッピング(IND広告メッセージからのすなわち、Target IPアドレスとSourceリンクレイヤアドレス)をノースダコタキャッシュ[IPv6-ノースダコタ]に置くかもしれません。
Further, the receiver Frame Relay node of the IND Advertisement MAY store the Target link-layer address from the message as the DLCI value at the remote end of the VC. This DLCI value is the equivalent of the link-layer address by which the remote node identifies the receiver.
さらに、DLCIがVCのリモートエンドで評価するようにIND Advertisementの受信機Frame RelayノードはメッセージからのTargetリンクレイヤアドレスを保存するかもしれません。 このDLCI値は遠隔ノードが受信機を特定するリンクレイヤアドレスの同等物です。
If the receiver node of the IND Advertisement has a pool of IPv6 addresses, and if the implementation allows, it may take decisions to pairing specific local IPv6 addresses to specific IPv6 addresses from the target list in further communications on the VC. More specifically, such a pairing may be based on IPv6 addresses being on the same subnet, that is having the same prefix.
IND Advertisementの受信機ノードではIPv6アドレスのプールがあって、実装である、許容、それは特定の地方のIPv6が目標リストからのさらなるコミュニケーションのVCに関する特定のIPv6アドレスに扱う組み合わせように決定を取るかもしれません。 それには、より明確に、そのような組み合わせが同じサブネットにあるIPv6アドレスに基づくかもしれなくて、同じ接頭語があります。
Conta Standards Track [Page 19] RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
コンタStandardsは隣人発見2001年6月にRFC3122拡張子をIPv6に追跡します[19ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネット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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Conta Standards Track [Page 20]
コンタ標準化過程[20ページ]
一覧
スポンサーリンク
