RFC2590 日本語訳
2590 Transmission of IPv6 Packets over Frame Relay NetworksSpecification. A. Conta, A. Malis, M. Mueller. May 1999. (Format: TXT=41817 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Conta
Request for Comments: 2590 Lucent
Category: Standards Track A. Malis
Ascend
M. Mueller
Lucent
May 1999
コメントを求めるワーキンググループA.コンタの要求をネットワークでつないでください: 2590年の透明なカテゴリ: 標準化過程A.Malisは1999年5月に透明なM.ミューラーを昇ります。
Transmission of IPv6 Packets over Frame Relay Networks
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
このメモはIPv6パケットのトランスミッションのためにFrame Relayネットワークの上でメカニズムについて説明します。
Table of Contents
目次
1. Introduction.................................................2
2. Maximum Transmission Unit....................................3
3. Frame Format.................................................4
4. Stateless Autoconfiguration..................................5
4.1 Generating the MID field.................................7
5. Link-Local Address...........................................9
6. Address Mapping -- Unicast, Multicast........................9
7. Sending Neighbor Discovery Messages.........................14
8. Receiving Neighbor Discovery Messages.......................15
9. Security Considerations.....................................15
10. Acknowledgments............................................16
11. References.................................................16
12. Authors' Addresses.........................................18
13. Full Copyright Statement...................................19
1. 序論…2 2. 最大のトランスミッション単位…3 3. 形式を縁どってください…4 4. 状態がない自動構成…5 4.1 MID分野を生成します…7 5. リンクローカルアドレス…9 6. マッピングを扱ってください--ユニキャスト、マルチキャスト9 7. 隣人発見にメッセージを送ります…14 8. 隣人発見メッセージを受け取ります…15 9. セキュリティ問題…15 10. 承認…16 11. 参照…16 12. 作者のアドレス…18 13. 完全な著作権宣言文…19
Conta, et al. Standards Track [Page 1] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[1ページ]。
1. Introduction
1. 序論
This document specifies the frame format for transmission of IPv6 packets over Frame Relay networks, the method of forming IPv6 link- local addresses on Frame Relay links, and the mapping of the IPv6 addresses to Frame Relay addresses. It also specifies the content of the Source/Target link-layer address option used in Neighbor Discovery [ND] and Inverse Neighbor Discovery [IND] messages when those messages are transmitted over a Frame Relay link. It is part of a set of specifications that define such IPv6 mechanisms for Non Broadcast Multi Access (NBMA) media [IPv6-NBMA], [IPv6-ATM], and a larger set that defines such mechanisms for specific link layers [IPv6-ETH], [IPv6-FDDI], [IPv6-PPP], [IPv6-ATM], etc...
このドキュメントはFrame Relayネットワークの上のIPv6パケットのトランスミッション、IPv6リンクローカルのアドレスをFrame Relayリンクに形成するメソッド、およびFrame RelayアドレスへのIPv6アドレスに関するマッピングにフレーム形式を指定します。 また、それはそれらのメッセージがFrame Relayリンクの上に送られるときNeighborディスカバリー[ノースダコタ]とInverse Neighborディスカバリー[IND]メッセージで使用される目標Source/リンクレイヤアドレスオプションの内容を指定します。 それはNon Broadcast Multi Access(NBMA)メディアのためにそのようなIPv6メカニズムを定義する仕様[IPv6-NBMA]、[IPv6-ATM]、および特定のリンクレイヤのためにそのようなメカニズムを定義するより大きいセット[IPv6-ETH]の1セットの一部、[IPv6-FDDI]、[IPv6-PPP]、[IPv6-ATM]ですなど。
The information in this document applies to Frame Relay devices which serve as end stations (DTEs) on a public or private Frame Relay network (for example, provided by a common carrier or PTT.) Frame Relay end stations can be IPv6 hosts or routers. In this document they are referred to as nodes.
情報が終わりのステーション(DTEs)として公共の、または、私設のFrame Relayネットワークで本書ではFrame Relayデバイスにどのサーブを当てはまるか、(例えば、運輸業者かPTTによって提供されている、) フレームRelay端のステーションは、IPv6ホストかルータであるかもしれません。 本書ではそれらはノードと呼ばれます。
In a Frame Relay network, a number of virtual circuits form the connections between the attached stations (nodes). The resulting set of interconnected devices forms a private Frame Relay group which may be either fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected. In either case, each virtual circuit is uniquely identified at each Frame Relay interface (card) by a Data Link Connection Identifier (DLCI). In most circumstances, DLCIs have strictly local significance at each Frame Relay interface.
Frame Relayネットワークでは、多くの仮想の回路が付属ステーション(ノード)の間の接続を形成します。 結果として起こるセットのインタコネクトされたデバイスは仮想の回路の完全な「メッシュ」で完全にインタコネクトされたか、または部分的にインタコネクトされるだけであるかもしれない民間のFrame Relayグループを結成します。 どちらの場合ではも、それぞれの仮想の回路はそれぞれのFrame Relayインタフェース(カード)でData Link Connection Identifier(DLCI)によって唯一特定されます。 ほとんどの事情では、DLCIsはそれぞれのFrame Relayインタフェースに厳密にローカルの意味を持っています。
A Frame Relay virtual circuit acts like a virtual-link (also referred to as logical-link), with its own link parameters, distinct from the parameters of other virtual circuits established on the same wire or fiber. Such parameters are the input/output maximum frame size, incoming/outgoing requested/agreed throughput, incoming/outgoing acceptable throughput, incoming/outgoing burst size, incoming/outgoing frame rate.
Frame Relayの仮想の回路は仮想のリンク(また、論理的なリンクと呼ばれる)のように作動します、それ自身のリンクパラメータで、同じワイヤかファイバーの上で確立された他の仮想の回路のパラメタと、異なります。 そのようなパラメタは入力/出力の最大のフレーム・サイズ、入って来るか送信する要求されたか同意されたスループット、入って来るか送信する許容できるスループット、入って来るか外向的な放出量、入って来るか外向的なフレームレートです。
By default a DLCI is 10 bits in length. Frame Relay specifications define also 16, 17, or 23 bit DLCIs. The former is not used, while the latter two are suggested for use with SVCs.
デフォルトで、DLCIは長さが10ビットです。 また、フレームRelay仕様は16ビットか17ビットか23ビットのDLCIsを定義します。 前者は使用されていませんが、後者の2はSVCsとの使用のために示されます。
Frame Relay virtual circuits can be created administratively as Permanent Virtual Circuits -- PVCs -- or dynamically as Switched Virtual Circuits -- SVCs. The mechanisms defined in this document are intended to apply to both permanent and switched Frame Relay virtual circuits, whether they are point to point or point to multi- point.
Permanent Virtual Circuits(PVCs)として行政上ダイナミックにフレームRelay仮想の回路を作成できる、Switched Virtual Circuits--SVCs。 本書では定義されたメカニズムが永久的なものと同様に切り換えられたFrame Relay仮想の回路に適用することを意図します、それらがポイントからポイント・ツー・ポイントかマルチポイントであることにかかわらず。
Conta, et al. Standards Track [Page 2] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[2ページ]。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [RFC 2119].
キーワードが解釈しなければならない、[RFC2119]で定義されるようにNOT、5月、OPTIONAL、REQUIRED、RECOMMENDED、SHALL、SHALL NOT、SHOULD、SHOULD NOTを解釈することになっていなければなりませんか?
2. Maximum Transmission Unit
2. マキシマム・トランスミッション・ユニット
The IPv6 minimum MTU is defined in [IPv6].
IPv6の最小のMTUは[IPv6]で定義されます。
In general, Frame Relay devices are configured to have a maximum frame size of at least 1600 octets. Therefore, the default IPv6 MTU size for a Frame Relay interface is considered to be 1592.
一般に、Frame Relayデバイスは、少なくとも1600の八重奏の最大のフレーム・サイズを持つために構成されます。 したがって、Frame RelayインタフェースへのデフォルトIPv6 MTUサイズは1592であると考えられます。
A smaller than default frame size can be configured but of course not smaller than the minimum IPv6 MTU.
デフォルトよりわずかなフレーム・サイズは、構成されていますが、もちろん最小のIPv6 MTUよりわずかであるはずがありません。
An adequate larger than default IPv6 MTU and Frame Relay frame size can be configured to avoid fragmentation. The maximum frame size is controlled by the CRC generation mechanisms employed at the HDLC level. CRC16 will protect frames up to 4096 bytes in length, which reduces the effective maximum frame size to approximately 4088 bytes. A larger desired frame size (such as that used by FDDI or Token Ring), would require the CRC32 mechanism, which is not yet widely used and is not mandatory for frame relay systems conforming to Frame Relay Forum and ITU-T standards.
断片化を避けるために適切なデフォルトIPv6 MTUとFrame Relayより大きいフレーム・サイズを構成できます。 最大のフレーム・サイズはHDLCで採用しているメカニズムが平らにするCRC世代によって制御されます。 CRC16はフレームを長さ4096バイトまで保護するでしょう。(長さは有効な最大のフレーム・サイズをおよそ4088バイトまで減少させます)。 より大きい必要なフレーム・サイズ(FDDIかToken Ringによって使用されたそれなどの)、CRC32メカニズムを必要とするでしょう。(それは、まだ広く使用されていなくて、またFrame Relay Forumに一致しているフレームリレーシステムとITU-T規格に義務的ではありません)。
In general, if upper layers provide adequate error protection/detection mechanisms, implementations may allow configuring a Frame Relay link with a larger than 4080 octets frame size but with a lesser error protection/detection mechanism at link layer. However, because IPv6 relies on the upper and lower layer error detection, configuring the IPv6 MTU to a value larger than 4080 is strongly discouraged.
一般に、上側の層が適切な誤り保護/検出メカニズムを提供するなら、実装で、4080の八重奏より大きいフレーム・サイズにもかかわらず、リンクレイヤの、より少ない誤り保護/検出メカニズムとのFrame Relayリンクを構成するかもしれません。 しかしながら、IPv6が上下の層の誤り検出に依存するので、4080年より大きい値にIPv6 MTUを構成するのは強くお勧めできないです。
Although a Frame Relay circuit allows the definition of distinct maximum frame sizes for input and output, for simplification purposes, this specification assumes symmetry, i.e. the same MTU for both input and output.
Frame Relay回路は入出力のための異なった最大のフレーム・サイズの定義を許しますが、簡素化目的のために、この仕様は対称を仮定します、すなわち、両方のための同じMTUが入出力します。
Furthermore, implementations may limit the setting of the Frame Relay maximum frame size to the interface (link, or card) level, which then is enforced on all of the PVCs or SVCs on that interface (on that link, or card). For an SVC, the maximum frame size parameter negotiated during circuit setup will not exceed the configured maximum frame size.
その上、実装はFrame Relayの最大のフレーム・サイズの設定を次にそのインタフェース(そのリンク、またはカードの)のPVCsかSVCsのすべてで励行されるインタフェース(リンク、またはカード)レベルに制限するかもしれません。 SVCに関しては、回路セットアップの間に交渉された最大のフレームサイズ・パラメータは構成された最大のフレーム・サイズを超えないでしょう。
Conta, et al. Standards Track [Page 3] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[3ページ]。
3. IPv6 Frame Format
3. IPv6フレーム形式
The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs) follows [ENCAPS], which allows a VC to carry IPv6 packets along with other protocol packets. The NLPID frame format is used, in which the IPv6 NLPID has a value of 0x8E:
Frame Relay(PVCsとSVCsの両方のための)のためのIPv6フレームカプセル化は[ENCAPS]に続きます。(VCはそれで他のプロトコルパケットに伴うIPv6パケットを運ぶことができます)。 NLPIDは使用される形式を縁どっています:(そこでは、IPv6 NLPIDが0x8Eの値を持っています)。
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | Control (UI) 0x03 | NLPID 0x8E | NLPID
+-----------------------+-----------------------+ indicating
n+2 | . | IPv6
/ . /
/ IPv6 packet /
| . |
+-----------------------+-----------------------+
| |
+ FCS +
| |
+-----------------------+-----------------------+
0 1(八重奏)+-----------------------+-----------------------+ (八重奏)0| | /'Q.922アドレス//('長さと同輩2か4)/| | +-----------------------+-----------------------+ n| コントロール(UI)0x03| NLPID 0x8E| NLPID+-----------------------+-----------------------+ n+2を示すこと。| . | IPv6///IPv6パケット/| . | +-----------------------+-----------------------+ | | + FCS+| | +-----------------------+-----------------------+
"n" is the length of the Q.922 address which can be 2 or 4 octets.
「n」は2か4つの八重奏であるかもしれないQ.922アドレスの長さです。
The Q.922 representation of a DLCI (in canonical order - the first
bit is stored in the least significant, i.e., the right-most bit
of a byte in memory) [CANON] is the following:
DLCI(正準なオーダーで--最初のビットは最も重要でないところに保存されます、すなわち、メモリの1バイトの最も権利ビット)[キヤノン]のQ.922表現は以下です:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ (八重奏)0| DLCI(高位)| 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 1 | DLCI(下位)| 0 | 0 | 0 | 1 | +-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
10ビットのDLCI
Conta, et al. Standards Track [Page 4] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[4ページ]。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ (八重奏)0| DLCI(高位)| 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 1 | DLCI| 0 | 0 | 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 2 | DLCI(下位)| 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 3 | 未使用です(0に設定されます)。| 1 | 1 | +-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
17ビットのDLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ (八重奏)0| DLCI(高位)| 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+----- 1 | DLCI| 0 | 0 | 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 2 | DLCI| 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 3 | DLCI(下位)| 0 | 1 | +-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
23ビットのDLCI
The encapsulation of data or control messages exchanged by various protocols that use SNAP encapsulation (with their own PIDs) is not affected. The encoding of the IPv6 protocol identifier in such messages MUST be done according to the specifications of those protocols, and [ASSNUM].
SNAPカプセル化(それら自身のPIDsと)を使用する様々なプロトコルによって交換されたデータかコントロールメッセージのカプセル化は影響を受けません。 それらのプロトコルの仕様、および[ASSNUM]に従って、そのようなメッセージにおける、IPv6プロトコル識別子のコード化をしなければなりません。
4. Stateless Autoconfiguration
4. 状態がない自動構成
An interface identifier [AARCH] for an IPv6 Frame Relay interface must be unique on a Frame Relay link [AARCH], and must be unique on each of the virtual links represented by the VCs terminated on the interface.
IPv6 Frame Relayインタフェースのためのインタフェース識別子[AARCH]は、Frame Relayリンク[AARCH]でユニークでなければならなく、インタフェースで終えられたVCsによって表されたそれぞれの仮想のリンクでユニークであるに違いありません。
The interface identifier for the Frame Relay interface is locally generated by the IPv6 module.
Frame Relayインタフェースのためのインタフェース識別子はIPv6モジュールで局所的に生成されます。
Each virtual circuit in a Frame Relay network is uniquely identified on a Frame Relay interface by a DLCI. Furthermore, a DLCI can be seen as an identification of the end point of a virtual circuit on a Frame Relay interface. Since each Frame Relay VC is configured or established separately, and acts like an independent virtual-link from other VCs in the network, or on the interface, link, wire or
Frame Relayネットワークにおけるそれぞれの仮想の回路はFrame RelayインタフェースでDLCIによって唯一特定されます。 その上、DLCIをFrame Relayインタフェースにおける仮想の回路のエンドポイントの識別と考えることができます。 または以来、各Frame Relay VCは別々に構成されるか、または設立されます、そして、ネットワークか、インタフェースの上の他のVCsからの独立している仮想のリンクのような行為はリンクされます、ワイヤ。
Conta, et al. Standards Track [Page 5] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[5ページ]。
fiber, it seems beneficial to view each VC's termination point on the Frame Relay interface as a "pseudo-interface" or "logical-interface" overlaid on the Frame Relay interface. Furthermore, it seems beneficial to be able to generate and associate an IPv6 autoconfigured address (including an IPv6 link local address) to each "pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a Frame Relay interface.
ファイバー、Frame Relayインタフェースでかぶせられた「疑似インタフェース」か「論理的なインタフェース」としてFrame Relayインタフェースの各VCの終了ポイントを見なすのは有益に思えます。 その上、生成することができるように有益に見えます、そして、IPv6が自動構成した仲間はすなわち、各「疑似インタフェース」、すなわち、各DLCIにオンなVCのエンドポイントにFrame Relayインタフェースを扱います(IPv6リンクローカルアドレスを含んでいます)。
In order to achieve the benefits described above, the mechanisms specified in this document suggest constructing the Frame Relay interface identifier from 3 distinct fields (Fig.1):
上で説明された利益を達成するために、本書では指定されたメカニズムは、3つの異なった分野(Fig.1)からFrame Relayインタフェース識別子を構成するのを示します:
(a) The "EUI bits" field. Bits 6 and 7 of the first octet,
representing the EUI-64 "universal/local" and respectively
"individual/group" bits converted to IPv6 use. The former is set
to zero to reflect that the 64 bit interface identifier value
has local significance [AARCH]. The latter is set to 0 to
reflect the unicast address [AARCH].
(a) 「EUIビット」分野。 最初の八重奏、「普遍的であるか地方」でEUI-64を表して、およびそれぞれ「個々の/グループ」ビットのビット6と7はIPv6使用に変えました。 ゼロに前者が、64ビットのインタフェース識別子価値にはローカルの意味[AARCH]があるのを反映するように設定されます。 0に後者がユニキャストアドレス[AARCH]を反映するように設定されます。
(b) The "Mid" field. A 38 bit field which is generated with the
purpose of adding uniqueness to the interface identifier.
(b) 「中間」の分野。 インタフェース識別子にユニークさを追加する目的で生成される38ビットの分野。
(c) The "DLCI" field. A 24 bit field that MAY hold a 10, 17, or 23
bit DLCI value which MUST be extended with 0's to 24 bits. A
DLCI based interface identifier -- which contains a valid DLCI
-- SHOULD be generated as a result of successfully establishing
a VC -- PVC or SVC.
(c) "DLCI"分野。 24ビットには0で広げなければならない10を保持するかもしれない24ビットの分野、17、または23ビットのDLCI値があります。 DLCIはインタフェース識別子--有効なDLCIを含むもの--SHOULDを基礎づけました。首尾よくVCを設立することの結果、生成されてください--PVCかSVC。
If a DLCI is not known, the field MUST be set to the
"unspecified DLCI" value which consists of setting each of the
24 bits to 1.
DLCIが知られていないなら、それぞれの24ビットを1に設定するのから成る「不特定のDLCI」値に分野を設定しなければなりません。
Since DLCIs are local to a Frame Relay node, it is possible to have Frame Relay distinct virtual circuits within a Frame Relay network identified with the same DLCI values.
DLCIsがFrame Relayノードに地方であるので、同じDLCI値と同一視されたFrame Relayネットワークの中にFrame Relayの異なった仮想の回路を持っているのは可能です。
Conta, et al. Standards Track [Page 6] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[6ページ]。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | |"EUI bits" |
+ +-----+-----+
1 | |
+ +
2 | "Mid" |
+ +
3 | |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ (八重奏)0| |「EUIビット」| + +-----+-----+ 1 | | + + 2 | 「中間です」。| + + 3 | | + + 4 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | | + + 6 | "DLCI"| + + 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+
Fig.1 Frame Relay Pseudo-Interface Identifier
Fig.1フレームリレー疑似インタフェース識別子
The Duplicate Address Detection specified in [AUTOCONF] is used repeatedly during the interface identifier and local-link address generation process, until the generated identifier and consequently the link-local address on the link -- VC -- are unique.
[AUTOCONF]で指定されたDuplicate Address Detectionはインタフェース識別子とローカルのリンクアドレス発生経過の間、繰り返して使用されます、発生している識別子とその結果リンクの上のリンクローカルアドレス(VC)がユニークになるまで。
4.1 Generating the "Mid" field.
4.1 「中間」の分野を生成します。
The "Mid" can be generated in multiple ways. This specification suggests two mechanisms:
複数の方法で「中間」を生成することができます。 この仕様は2つのメカニズムを示します:
(b.1) "Use of Local Administrative Numbers"
(b.1) 「地方の管理数の使用」
The "Mid" is filled with the result of merging:
「中間」は合併するという結果で満たされます:
(b.1.1) A random number of 6 bits in length (Fig.2).
(b.1.1) 長さ(Fig.2)6ビットの乱数。
(b.1.2) The Frame Relay Node Identifier -- 16 bits -- is a user
administered value used to locally identify a Frame Relay
node (Fig.2).
(b.1.2) Frame Relay Node Identifier(16ビット)は局所的に、Frame Relayノード(Fig.2)を特定するのに使用されるユーザの管理された値です。
(b.1.3) The Frame Relay Link Identifier -- 16 bits -- is a numerical
representation of the Frame Relay interface or link (Fig.2).
(b.1.3) Frame Relay Link Identifier(16ビット)はFrame Relayインタフェースかリンク(Fig.2)の数字の表現です。
Conta, et al. Standards Track [Page 7] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[7ページ]。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | Random Number | MBZ |
+-----------------------------------+-----+-----+
1 | |
+ Frame Relay Node Identifier +
2 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | |
+ Frame Relay Link Identifier +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ (八重奏)0| 乱数| MBZ| +-----------------------------------+-----+-----+ 1 | | + フレームリレーノード識別子+2| | +-----+-----+-----+-----+-----+-----+-----+-----+ 3 | | + フレームリレーリンク識別子+4| | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | | + + 6 | "DLCI"| + + 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+
Fig.2 Frame Relay Pseudo-Interface Identifier
Fig.2フレームリレー疑似インタフェース識別子
or,
または
(b.2) "Use of The Frame Relay address - E.164 [E164], X.121
[X25] numbers, or NSAP [NSAP] address"
(b.2)、「Frame Relayアドレスの使用--、E.164[164E]、X.121[X25]番号、またはNSAP[NSAP]が扱う、」
If a Frame Relay interface has an E.164 or a X.121 number, or an
NSAP address, the "Mid" field MUST be filled in with a number
resulted from it as follows: the number represented by the BCD
encoding of the E.164 or X.121 number, or the binary encoding of
the NSAP address is truncated to 38 bits (Fig.3). Since the Frame
Relay interface identifier has a "local" significance, the use of
such a value has no real practical purposes other than adding to
the uniqueness of the interface identifier on the link. Therefore
the truncation can be performed on the high order or low order
bits. If the high order bits truncation does not provide
uniqueness on the link -- perhaps the DLCI value is not unique --
this most likely means that the VC spans more for instance than a
national and/or international destination area for an E.164
number, and therefore the truncation of the low order bits should
be performed next, which most likely will provide the desired
uniqueness.
Frame RelayインタフェースにE.164、X.121番号、またはNSAPアドレスがあるなら、数が以下の通りそれから結果として生じて、「中間」の分野に記入しなければなりません: 数がBCDでE.164かX.121番号のコード化を表したか、またはNSAPアドレスの2進のコード化は38ビット(Fig.3)に先端を切られます。 Frame Relayインタフェース識別子には「地方」の意味があるので、そのような値の使用では、リンクに関するインタフェース識別子のユニークさに加える以外のどんな本当の実用的な目的もありません。 したがって、高位か下位のビットにトランケーションを実行できます。 高位のビットトランケーションはリンクの上にユニークさを提供しません--恐らく、DLCI値はユニークではありません--これが、たぶんE.164番号のための国家的である、そして/または、国際的な目的地の地域より例えば、VCがわたることを意味して、したがって、下位のビットのトランケーションが次に実行されるなら(たぶん必要なユニークさを提供するでしょう)。
Conta, et al. Standards Track [Page 8] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[8ページ]。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | | MBZ |
+ +-----+-----+
1 | |
+ E.164, X.121 (BCD encoding) +
2 | or NSAP Address |
+ +
3 | (truncated to 38 bits) |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ (八重奏)0| | MBZ| + +-----+-----+ 1 | | + E.164、X.121(BCDコード化)+2| または、NSAPアドレス| + + 3 | (38ビットに先端を切られます) | + + 4 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | | + + 6 | "DLCI"| + + 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+
Fig.3 Frame Relay (Pseudo) Interface Identifier
Fig.3フレームリレー(疑似な)インタフェース識別子
5. Link-Local Addresses
5. リンクローカルのアドレス
The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface is formed by appending the interface identifier, formed as defined above, to the prefix FE80::/64 [AARCH].
IPv6 Frame RelayインタフェースへのIPv6リンクローカルアドレス[AARCH]は上で定義されるように形成されたインタフェース識別子を接頭語FE80に追加することによって、形成されます:、:/64[AARCH]。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) |Frame Relay Interface Ident.|
+----------+-----------------------+----------------------------+
10ビット54ビット64ビット+----------+-----------------------+----------------------------+ |1111111010| (ゼロ) |フレームリレーはIdent| +を連結します。----------+-----------------------+----------------------------+
6. Address Mapping -- Unicast, Multicast
6. アドレス・マッピング--ユニキャスト、マルチキャスト
The procedure for mapping IPv6 addresses to link-layer addresses is described in [IPv6-ND]. Additionally, extensions to Neighbor Discovery (ND) that allow the mapping of link-layer addresses to IPv6 addresses are defined as Inverse Neighbor Discovery (IND) in [IND]. This document defines the formats of the link-layer address fields used by ND and IND. This specification does not define an algorithmic mapping of IPv6 multicast addresses to Frame Relay link-layer addresses.
IPv6アドレスをリンクレイヤアドレスに写像するための手順は[IPv6-ノースダコタ]で説明されます。 さらに、Neighborディスカバリー(ノースダコタ)へのリンクレイヤアドレスに関するマッピングをIPv6アドレスに許容する拡大が[IND]でInverse Neighborディスカバリー(IND)と定義されます。 このドキュメントはノースダコタとINDによって使用されたリンクレイヤアドレス・フィールドの書式を定義します。 この仕様はIPv6マルチキャストアドレスのアルゴリズムのマッピングをFrame Relayリンクレイヤアドレスと定義しません。
The Source/Target Link-layer Address option used in Neighbor Discovery and Inverse Neighbor Discovery messages for a Frame Relay link follows the general rules defined by [IPv6-ND]. IPv6 addresses can map two type of identifiers equivalent to link-layer addresses:
オプションがFrame RelayリンクにNeighborディスカバリーとInverse Neighborディスカバリーメッセージで使用したSource/目標Address Link-層は[IPv6-ノースダコタ]によって定義された総則に従います。 IPv6アドレスはリンクレイヤアドレスに同等な識別子の2タイプを写像できます:
Conta, et al. Standards Track [Page 9] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[9ページ]。
DLCIs, and Frame Relay Addresses. Therefore, for Frame Relay, this document defines two distinct formats for the ND and IND messages Link-Layer Address field:
DLCIs、およびフレームリレーアドレス。 したがって、Frame Relayに関して、このドキュメントはメッセージLink-層のAddressがさばくノースダコタとINDのための2つの異なった書式を定義します:
(a) DLCI Format -- used in ND and/or IND messages on VCs that were
established prior to the ND or IND message exchange -- mostly
PVCs. The use on SVCs makes sense with Inverse Neighbor
Discovery [IND] messages if IND is employed after the successful
establishing of an SVC to gather information about other IPv6
addresses assigned to the remote node and that SVC.
(a) DLCI Format--VCsに関するノースダコタ、そして/または、INDメッセージで使用されて、それはノースダコタかIND交換処理の前に設立されました--ほとんどPVCs。 INDがSVCのうまくいっている設立の後に遠隔ノードとそのSVCに割り当てられた他のIPv6アドレスに関して情報を収集するのに使われるなら、SVCsにおける使用はInverse Neighborディスカバリー[IND]メッセージで理解できます。
(b) Frame Relay Address Format -- used mostly prior to establishing
a new SVC, to get the Frame Relay remote node identifier
(link-layer address) mapping to a certain IPv6 address.
(b) Relay Address Formatを縁どってください--Frame Relay遠隔ノード識別子(リンクレイヤアドレス)マッピングをあるIPv6アドレスに得るためにほとんど新しいSVCを設立する前に、使用されています。
Note: An implementation may hold both types of link layer
identifiers in the Neighbor Discovery cache. Additionally, in
case of multiple VCs between two nodes, one node's Neighbor
Discovery cache may hold a mapping of one of the remote node's
IPv6 addresses to each and every DLCI identifying the VCs.
以下に注意してください。 実装はNeighborディスカバリーキャッシュにおける、両方のタイプに関するリンクレイヤ識別子を保持するかもしれません。 さらに、2つのノードの間の複数のVCsの場合に、1つのノードのNeighborディスカバリーキャッシュは遠隔ノードのIPv6アドレスの1つに関するマッピングをVCsを特定するありとあらゆるDLCIとして保持するかもしれません。
The mechanisms which in such an implementation would make the
distinction between the Neighbor Discovery Cache mapping of an
IPv6 address to a "Frame Relay Address Format" and a "DLCI
Format" link-layer address, or among several mappings to a "DLCI
Format" addresses are beyond the scope of this specification.
そのような実装には、「フレームリレーアドレス形式」へのIPv6アドレスに関するNeighborディスカバリーCacheマッピングと「DLCI形式」というリンクレイヤアドレスの間で区別をするだろうか、またはこの仕様の範囲に「DLCI形式」アドレスへのいくつかのマッピングの中にあるメカニズム。
The use of the override "O" bit in the advertisement messages
that contain the above Link-Layer Address formats SHOULD be
consistent with the [ND] specifications. Additionally, there
should be consistency related to the type of Link-Layer Address
format: an implementation should override one address format in
its Neighbor Discovery cache with the same type of address
format.
上のリンクレイヤアドレス形式を含む広告メッセージにおけるオーバーライド「O」ビットの使用は[ノースダコタ]仕様と一致しているべきです。 さらに、Link-層のAddress形式のタイプに関連する一貫性があるべきです: 実装は同じタイプのアドレス形式でNeighborディスカバリーキャッシュにおける1つのアドレス形式をくつがえすべきです。
The "DLCI Format" is defined as follows:
「DLCI形式」は以下の通り定義されます:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ 0 | タイプ| +-----+-----+-----+-----+-----+-----+-----+-----+ 1 | 長さ| +-----+-----+-----+-----+-----+-----+-----+-----+
Conta, et al. Standards Track [Page 10] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[10ページ]。
with a DLCI (Q.922 address) encoded as option value:
DLCI(Q.922アドレス)がオプションとしてコード化されている状態で、以下を評価してください。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | |
+ Padding +
7 | (zeros) |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ 2 | | 1 | 1 | + 未使用の+-----+-----+ 3 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 4 | DLCI(高位)| 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | DLCI(下位)| 0 | 0 | 0 | 1 | +-----+-----+-----+-----+-----+-----+-----+-----+ 6 | | + 詰め物+7| (ゼロ) | +-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
10ビットのDLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ 2 | | 1 | 1 | + 未使用の+-----+-----+ 3 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 4 | DLCI(高位)| 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | DLCI| 0 | 0 | 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 6 | DLCI(下位)| 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 7 | 未使用です(0に設定されます)。| 1 | 1 | +-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
17ビットのDLCI
Conta, et al. Standards Track [Page 11] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[11ページ]。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ 2 | | 1 | 1 | + 未使用の+-----+-----+ 3 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 4 | DLCI(高位)| 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+----- 5 | DLCI| 0 | 0 | 0 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 6 | DLCI| 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 7 | DLCI(下位)| 0 | 1 | +-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
23ビットのDLCI
Option fields:
オプション・フィールド:
Type 1 for Source Link-layer address.
2 for Target Link-layer address.
Source Link-層のアドレスのために1をタイプしてください。 2 Target Link-層のアドレスのために。
Length The Length of the Option (including the Type
and Length fields) in units of 8 octets.
It has the value 1.
長さ、8つの八重奏のユニットのOption(TypeとLength分野を含んでいる)のLength。 それには、値1があります。
Link-Layer Address The DLCI encoded as a Q.922 address.
DLCIがQ.922アドレスとしてコード化したリンク層のAddress。
Description
記述
The "DLCI Format" option value field has two components:
「DLCI形式」オプション価値分野には、2つのコンポーネントがあります:
(a) Address Type -- encoded in the first two bits of the first
two octets. Both bits are set to 1 to indicate the DLCI
format. The rest of the bits in the two first octets are
not used -- they MUST be set to zero on transmit and MUST
be ignored by the receiver.
(a) Typeを扱ってください--最初の2つの八重奏の最初の2ビットでは、コード化されています。 1に両方のビットがDLCI書式を示すように設定されます。 使用されない2/1の八重奏における、ビットの残り--それらをゼロにオンなセットが伝わるということでなければならなく、受信機で無視しなければなりません。
(b) DLCI -- encoded as a Q.922 address padded with zeros to the
last octet of the 6 octets available for the entire Link-
Layer Address field of this format.
(b) DLCI--Q.922アドレスとしてコード化されるのはゼロでこの形式の全体のLink層のAddress分野に利用可能な6つの八重奏の最後の八重奏にそっと歩きました。
Conta, et al. Standards Track [Page 12] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[12ページ]。
The "Frame Relay Address Format" is defined as follows:
「フレームリレーアドレス形式」は以下の通り定義されます:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ 0 | タイプ| +-----+-----+-----+-----+-----+-----+-----+-----+ 1 | 長さ| +-----+-----+-----+-----+-----+-----+-----+-----+
with an E.164, X.121, number or NSAP address encoded as option value:
E.164と共に、オプションとしてコード化されたX.121、数またはNSAPアドレスが以下を評価します。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | size | 1 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | E.164 or X.121, or NSAP |
+--- Address Family Number ---+
4 | (Assigned Number) |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
/ E.164, or X.121 number (BCD encoded) /
/ or NSAP address /
4+size | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5+size | |
/ Padding /
/ (zeros) /
8*Length-1| |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0(オーダーに噛み付く)+-----+-----+-----+-----+-----+-----+-----+-----+ 2 | サイズ| 1 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 3 | E.164、X.121、またはNSAP| +--- アドレスファミリー番号---+ 4 | (規定番号) | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | | /E.164、X.121番号(コード化されたBCD)//またはNSAPアドレス/4+サイズ| | +-----+-----+-----+-----+-----+-----+-----+-----+ 5+サイズ| | /詰め物//(ゼロ)/8*長さ-1| | +-----+-----+-----+-----+-----+-----+-----+-----+
Option fields:
オプション・フィールド:
Type 1 for Source Link-layer address.
2 for Target Link-layer address.
Source Link-層のアドレスのために1をタイプしてください。 2 Target Link-層のアドレスのために。
Length The length of the Option (including the
Type and Length fields) in units of 8 octet.
It may have the value:
長さ、ユニットの8八重奏における、Option(TypeとLength分野を含んでいる)の長さ。 それには、値があるかもしれません:
2 -- for E.164, or X.121 numbers or NSAP
addresses not longer than 11 octets
[E164], [X25], [NSAP].
11の八重奏[164E]、[X25][NSAP]ほど長くないE.164、X.121番号またはNSAPアドレスのための2。
3 -- for NSAP addresses longer than 11 but
not longer than 19 octets.
19の八重奏より長いのではなく11より長いNSAPアドレスのための3。
Conta, et al. Standards Track [Page 13] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[13ページ]。
4 -- for NSAP addresses longer than 19 octets
(not longer than the maximum NSAP address
length) [NSAP].
19の八重奏(最大のNSAPアドレスの長さほど長くない)[NSAP]より長いNSAPアドレスのための4。
Link-Layer Address The E.164, X.121, number encoded in
Binary Coded Decimal (BCD), or the NSAP
address.
リンク層のAddress E.164、X.121、2進化10進法(BCD)でコード化された数、またはNSAPアドレス。
Description
記述
The "Frame Relay Address" option value has three components:
「フレームリレーアドレス」オプション価値には、3つのコンポーネントがあります:
(a) Address Type -- encoded in the first two bits of the first
octet. The first bit is set to 0, the second bit is set to 1.
(a) Typeを扱ってください--最初の八重奏の最初の2ビットでは、コード化されています。 最初のビットは0に設定されて、2番目のビットは1に設定されます。
(b) Size -- encoded in the last (high order) 6 bits of the first
octet. The maximum value of the field is the maximum size of
the E.164, X.121, or NSAP addresses.
(b)サイズ--最後の(高位)では、最初の八重奏の6ビットをコード化しました。 分野の最大値はE.164、X.121、またはNSAPアドレスの最大サイズです。
(c) Address Family Number -- the number assigned for the E.164,
X.121, or NSAP address family [ASSNUM].
(c)アドレスFamily Number--E.164、X.121、またはNSAPのために割り当てられた数はファミリー[ASSNUM]を扱います。
(d) E.164, X.121, number -- encoded in BCD (two digits per octet).
If the E.164, or X.121 has an even number of digits the
encoding will fill all encoding octets -- half the number of
digits. If the E.164, or X.121 number has an odd number of
digits, the lowest order digit fills only half of an octet --
it is placed in the first 4 bits of the last octet of the
E.164, or X.121 BCD encoding. The rest of the field up to the
last octet of the 11 octets available is padded with zeros.
(d)E.164、X.121、数--BCD(1八重奏あたり2ケタ)では、コード化されます。 E.164、またはX.121がそうしたなら、コード化がそうするケタの偶数の数は八重奏をすべてコード化しながら、いっぱいになります--ケタの半数。 E.164、またはX.121番号がそうしたなら、ケタの奇数に、最も低いオーダーケタは八重奏について半分だけをいっぱいにしています--それはE.164、またはX.121 BCDコード化の最後の八重奏の最初の4ビットに置かれます。 利用可能な11の八重奏の最後の八重奏までの分野の残りはゼロで水増しされます。
NSAP address -- the NSAP address. It is padded with zeros if
the NSAP address does not fit in a number of octets that makes
the length of the option an even number of 8 octets.
NSAPアドレス--NSAPアドレス。 NSAPアドレスがオプションの長さを8つの八重奏の偶数にする多くの八重奏をうまくはめ込まないなら、それはゼロで水増しされます。
7. Sending Neighbor Discovery Messages
7. 送付隣人発見メッセージ
Frame Relay networks do not provide link-layer native multicasting mechanisms. For the correct functioning of the Neighbor Discovery mechanisms, link-layer multicasting must be emulated.
フレームRelayネットワークはリンクレイヤの固有のマルチキャスティングメカニズムを提供しません。Neighborディスカバリーメカニズムの正しい機能において、リンクレイヤマルチキャスティングを見習わなければなりません。
To emulate multicasting for Neighbor Discovery (ND) the node MUST send frames carrying ND multicast packets to all VCs on a Frame Relay interface. This applies to ND messages addressed to both all-node and solicited-node multicast addresses. This method works well with PVCs. A mesh of PVCs MAY be configured and dedicated to multicast traffic only. An alternative to a mesh of PVCs is a set of point-to- multipoint PVCs.
Neighborディスカバリー(ノースダコタ)のためにマルチキャスティングを見習うために、Frame RelayインタフェースでノースダコタマルチキャストパケットをすべてのVCsまで運んで、ノードはフレームを送信しなければなりません。 これは両方のオールノードと請求されたノードマルチキャストアドレスに扱われたノースダコタメッセージに適用されます。 このメソッドはPVCsと共にうまくいきます。 PVCsのメッシュは、マルチキャストトラフィックだけに構成されて、捧げられるかもしれません。 PVCsのメッシュへの代替手段はポイントから多点へのPVCsの1セットです。
Conta, et al. Standards Track [Page 14] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[14ページ]。
8. Receiving Neighbor Discovery Messages
8. 隣人発見メッセージを受け取ります。
If a Neighbor Discovery Solicitation message received by a node contains the Source link-layer address option with a DLCI, the message MUST undergo Frame Relay specific preprocessing required for the correct interpretation of the field during the ND protocol engine processing. This processing is done before the Neighbor Discovery message is processed by the Neighbor Discovery (ND) protocol engine.
ノードによって受け取られたNeighborディスカバリーSolicitationメッセージがDLCIとのSourceリンクレイヤアドレスオプションを含んでいるなら、メッセージは分野の正しい解釈にノースダコタのプロトコルエンジン処理の間必要であるFrame Relayの特定の前処理を受けなければなりません。 Neighborディスカバリー(ノースダコタ)プロトコルエンジンでNeighborディスカバリーメッセージを処理する前にこの処理をします。
The motivation for this processing is the local significance of the DLCI fields in the Neighbor Discovery message: the DLCI significance at the sender node is different than the DLCI significance at the receiver node. In other words, the DLCI that identifies the Frame Relay virtual circuit at the sender may be different than the DLCI that identifies the virtual circuit at the receiver node. Furthermore, the sender node may not be aware of the DLCI value at the receiver. Therefore, the Frame Relay specific preprocessing consists in modifying the Neighbor Discovery Solicitation message received, by storing into the Source link-layer address option the DLCI value of the virtual circuit on which the frame was received, as known to the receiver node. The DLCI value being stored must be encoded in the appropriate format (see previous sections). The passing of the DLCI value from the Frame Relay module to the Neighbor Discovery preprocessing module is an implementation choice.
この処理に関する動機はNeighborディスカバリーメッセージのDLCI分野のローカルの意味です: 送付者ノードのDLCI意味は受信機ノードでDLCI意味と異なっています。 言い換えれば、送付者でFrame Relayの仮想の回路を特定するDLCIは受信機ノードで仮想の回路を特定するDLCIと異なっているかもしれません。 その上、送付者ノードは受信機でDLCI価値を意識していないかもしれません。したがって、Frame Relayの特定の前処理はフレームが受け取られた仮想の回路のDLCI値をSourceリンクレイヤアドレスオプションとして保存することによって受け取られたNeighborディスカバリーSolicitationメッセージを変更しながら、存します、受信機ノードに知られているように。 適切な形式で保存されるDLCI値をコード化しなければなりません(前項を見てください)。 DLCI価値のFrame RelayモジュールからNeighborディスカバリー前処理モジュールまでの通過は実装選択です。
9. Security Considerations
9. セキュリティ問題
The mechanisms defined in this document for generating an IPv6 Frame Relay interface identifier are intended to provide uniqueness at link level -- virtual circuit. The protection against duplication is achieved by way of IPv6 Stateless Autoconfiguration Duplicate Address Detection mechanisms. Security protection against forgery or accident at the level of the mechanisms described here is provided by the IPv6 security mechanisms [IPSEC], [IPSEC-Auth], [IPSEC-ESP] applied to Neighbor Discovery [IPv6-ND] or Inverse Neighbor Discovery [IND] messages.
本書ではIPv6 Frame Relayインタフェース識別子を生成するために定義されたメカニズムがリンク・レベルにおけるユニークさを提供することを意図します--仮想の回路。 複製に対する保護はIPv6 Stateless Autoconfiguration Duplicate Address Detectionメカニズムを通して達成されます。IPv6セキュリティー対策[IPSEC]から偽造に対する機密保持かここで説明されたメカニズムのレベルにおける事故を供給します、[IPSEC-Auth]、Neighborディスカバリー[IPv6-ノースダコタ]かInverse Neighborディスカバリー[IND]メッセージに適用された[IPSEC-超能力。]
To avoid an IPsec 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.
IPsec Authentication検証の故障、DLCI形式Sourceリンクレイヤアドレスオプションを含むNeighborディスカバリーSolicitationメッセージのFrame Relayの特定の前処理を避けるために、IP Security処理を終了した後に受信機ノードはしなければなりません。
Conta, et al. Standards Track [Page 15] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[15ページ]。
10. Acknowledgments
10. 承認
Thanks to D. Harrington, and M. Merhar for reviewing this document and providing useful suggestions. Also thanks to G. Armitage for his reviewing and suggestions. Many thanks also to Thomas Narten for suggestions on improving the document.
このドキュメントを再検討して、D.ハリントン、およびM.Merharに役に立つ提案を提供してくださってありがとうございます。 また、彼の論評と提案のためにG.アーミテージをありがとうございます。 また、ドキュメントを改良するときの提案のためにトーマスNartenをありがとうございます。
11. References
11. 参照
[AARCH] Hinden, R. and S. Deering, "IPv6 Addressing
Architecture", RFC 2373, July 1998.
[AARCH] HindenとR.とS.デアリング、「IPv6アドレッシング体系」、RFC2373、1998年7月。
[ASSNUM] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[ASSNUM] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC 2462, December 1998.
[AUTOCONF] トムソンとS.とT.Narten、「IPv6の状態がない自動構成」、RFC2462、1998年12月。
[CANON] Narten, T. and C. Burton, "A Caution on the Canonical
Ordering of Link-Layer Addresses", RFC 2469, December
1998.
[キヤノン]NartenとT.とC.バートン、「リンクレイヤアドレスの正準な注文での警告」、RFC2469、1998年12月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over
Frame Relay", STD 55, RFC 2427, November 1998.
[ENCAPS]ブラウン、C.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」STD55、1998年11月のRFC2427。
[IND] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery", Work in Progress, December 1998.
[IND] コンタ、A.、「逆さの発見のためのIPv6隣人発見への拡大」が進歩、1998年12月に働いています。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[IPv6] デアリングとS.とR.Hinden、「インターネットプロトコルバージョン6仕様」、RFC2460、1998年12月。
[IPv6-ATM] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.
1999年1月の[IPv6-気圧]のアーミテージとG.、SchulterとP.とM.Jork、「気圧ネットワークの上のIPv6」RFC2492。
[IPv6-ETH] Crawford, M., "Transmission of IPv6 packets over
Ethernet Networks", RFC 2464, December 1998.
[IPv6-ETH] クロフォード、M.、「イーサネットNetworksの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[IPv6-FDDI] Crawford, M., "Transmission of IPv6 packets over FDDI
Networks", RFC 2467, December 1998.
[IPv6-FDDI] クロフォード、M.、「FDDI Networksの上のIPv6パケットのトランスミッション」、RFC2467、1998年12月。
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter,
"IPv6 over Non-Broadcast Multiple Access (NBMA)
networks", RFC 2491, January 1999.
[IPv6-NBMA]アーミテージとG.とSchulterとP.とJorkとM.とG.Harter、「Non-放送Multiple Access(NBMA)ネットワークの上のIPv6」、RFC2491、1999年1月。
[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、1998年12月。
Conta, et al. Standards Track [Page 16] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[16ページ]。
[IPv6-PPP] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
2472, December 1998.
[IPv6-ppp] ハスキンとD.とE.アレン、「pppの上のIPバージョン6」、RFC2472、1998年12月。
[IPv6-TR] Narten, T., Crawford, M. and M. Thomas, "Transmission
of IPv6 packets over Token Ring Networks", RFC 2470,
December 1998.
[IPv6-TR] NartenとT.とクロフォードとM.とM.トーマス、「Token Ring Networksの上のIPv6パケットのトランスミッション」、RFC2470、1998年12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPSEC] アトキンソンとR.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のためのRequirement Levelsを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[E164] International Telecommunication Union - "Telephone
Network and ISDN Operation, Numbering, Routing, amd
Mobile Service", ITU-T Recommendation E.164, 1991.
[164E]の国際電気通信連合--「NetworkとISDN Operation、Numbering、ルート設定、amdのモバイルServiceに電話をする」ITU-T Recommendation E.164、1991。
[NSAP] ISO/IEC, "Information Processing Systems -- Data
Communications -- Network Service Definition Addendum 2:
Network Layer Addressing". International Standard
8348/Addendum 2, ISO/IEC JTC 1, Switzerland 1988.
[NSAP]ISO/IEC、「情報処理システム(データ通信)はサービス定義付加物2をネットワークでつなぎます」。 「ネットワーク層アドレシング。」 国際規格8348/付加物2、ISO/IEC JTC1、スイス1988。
[X25] "Information Technology -- Data Communications -- X.25
Packet Layer Protocol for Data Terminal Equipment",
International Standard 8208, March 1988.
[X25] 「情報技術--データ通信--データ端末装置のためのX.25パケット層のプロトコル」、国際規格8208、1988年3月。
Conta, et al. Standards Track [Page 17] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[17ページ]。
12. Authors' Addresses
12. 作者のアドレス
Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742
スイート100一致、MA アレックスコンタルーセントテクノロジーズ株式会社300ベイカーAve、01742
Phone: +1-978-287-2842 EMail: aconta@lucent.com
以下に電話をしてください。 +1-978-287-2842 メールしてください: aconta@lucent.com
Andrew Malis Ascend Communications 1 Robbins Rd Westford, MA 01886
アンドリューMalisはコミュニケーション1ロビンス・第ウェストフォード、MA 01886を昇ります。
Phone: +1-978-952-7414 EMail: malis@ascend.com
以下に電話をしてください。 +1-978-952-7414 メールしてください: malis@ascend.com
Martin Mueller Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742
スイート100一致、MA マーチンミューラールーセントテクノロジーズ株式会社300ベイカーAve、01742
PHone: +1-978-287-2833 EMail: memueller@lucent.com
電話: +1-978-287-2833 メールしてください: memueller@lucent.com
Conta, et al. Standards Track [Page 18] RFC 2590 IPv6 over Frame Relay Networks May 1999
コンタ、他 規格は1999年5月にフレームリレーネットワークの上でRFC2590IPv6を追跡します[18ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Conta, et al. Standards Track [Page 19]
コンタ、他 標準化過程[19ページ]
一覧
スポンサーリンク
