[要約] RFC 2590は、IPv6パケットをフレームリレーネットワーク上で転送するための仕様書です。その目的は、IPv6ネットワークとフレームリレーネットワークの間での効率的な通信を実現することです。
Network Working Group A. Conta
Request for Comments: 2590 Lucent
Category: Standards Track A. Malis
Ascend
M. Mueller
Lucent
May 1999
Transmission of IPv6 Packets over Frame Relay Networks Specification
フレームリレーネットワーク仕様上のIPv6パケットの送信
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
このメモは、フレームリレーネットワーク上のIPv6パケットの送信のメカニズムについて説明しています。
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
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...
このドキュメントは、フレームリレーネットワーク上のIPv6パケットを送信するためのフレーム形式、フレームリレーリンクにIPv6リンクローカルアドレスを形成する方法、およびフレームリレーアドレスにIPv6アドレスをマッピングする方法を指定します。また、それらのメッセージがフレームリレーリンクを介して送信されたときに、Neighbor Discovery [ND]および逆近隣発見[IND]メッセージで使用されるソース/ターゲットリンクレイヤーアドレスオプションのコンテンツを指定します。これは、非ブロードキャストマルチアクセス（NBMA）メディア[IPv6-NBMA]、[IPv6-ATM]のこのようなIPv6メカニズムを定義する一連の仕様の一部であり、特定のリンクレイヤーのそのようなメカニズムを定義するより大きなセット[IPv6-Eth]、[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.
このドキュメントの情報は、パブリックまたはプライベートフレームリレーネットワーク（たとえば、一般的なキャリアやPTTによって提供される）でエンドステーション（DTE）として機能するフレームリレーデバイスに適用されます。フレームリレーエンドステーションは、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.
フレームリレーネットワークでは、多くの仮想回路が接続されたステーション（ノード）間の接続を形成します。結果の相互接続されたデバイスのセットは、仮想回路の完全な「メッシュ」と完全に相互接続されているか、部分的に相互接続されたプライベートフレームリレーグループを形成します。どちらの場合でも、各仮想回路は、データリンク接続識別子（DLCI）によって各フレームリレーインターフェイス（カード）で一意に識別されます。ほとんどの場合、DLCIは各フレームリレーインターフェイスで厳密に局所的に重要です。
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.
フレームリレー仮想回路は、同じワイヤまたはファイバーに確立された他の仮想回路のパラメーターとは異なる独自のリンクパラメーターを備えた仮想リンク（論理リンクとも呼ばれる）のように機能します。このようなパラメーターは、入出力/出力の最大フレームサイズ、受信/発信要求/合意されたスループット、受信/発信許容スループット、着信/発信バーストサイズ、着信/発信フレームレートです。
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ビットです。フレームリレー仕様は、16、17、または23ビットDLCIも定義します。前者は使用されませんが、後者の2つはSVCで使用することをお勧めします。
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.
フレームリレー仮想回路は、永久的な仮想回路（PVC）として、またはスイッチされた仮想回路として動的にSVCとして管理的に作成できます。このドキュメントで定義されているメカニズムは、ポイントツーポイントであろうとマルチポイントのポイントであろうと、永続的および切り替えられたフレームリレー仮想回路の両方に適用することを目的としています。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [RFC 2119].
キーワードは、[RFC 2119]で定義されているように解釈されるべきではない、、オプション、必要、要求、推奨、推奨されることはしないでください。
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.
一般に、フレームリレーデバイスは、少なくとも1600オクテットの最大フレームサイズを持つように構成されています。したがって、フレームリレーインターフェイスのデフォルトの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およびフレームリレーフレームサイズよりも大きいものを構成できます。最大フレームサイズは、HDLCレベルで使用されるCRC生成メカニズムによって制御されます。CRC16は、長さが最大4096バイトまでのフレームを保護し、有効な最大フレームサイズを約4088バイトに減らします。より大きな希望のフレームサイズ（FDDIまたはトークンリングが使用するなど）には、まだ広く使用されていないCRC32メカニズムが必要になります。
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オクテットのフレームサイズが大きいが、リンク層でのエラー保護/検出メカニズムが少ないフレームリレーリンクを構成することができます。ただし、IPv6は上層および下層エラーの検出に依存しているため、IPv6 MTUを4080を超える値に構成することは強く推奨されていません。
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.
フレームリレー回路は、入力と出力の明確な最大フレームサイズの定義を可能にしますが、単純化の目的では、この仕様は対称性、つまり入力と出力の両方で同じ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.
さらに、実装により、フレームリレーの最大フレームサイズの設定がインターフェイス（リンク、またはカード）レベルに制限される場合があります。これは、そのインターフェイスのすべてのPVCまたはSVC（そのリンク、またはカード）で施行されます。SVCの場合、回路のセットアップ中にネゴシエートされた最大フレームサイズパラメーターは、構成された最大フレームサイズを超えません。
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:
フレームリレーのIPv6フレームカプセル化（PVCとSVCの両方）は[cankaps]に続きます。これにより、VCは他のプロトコルパケットとともにIPv6パケットを運ぶことができます。NLPIDフレーム形式が使用され、IPv6NLPIDの値は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 +
| |
+-----------------------+-----------------------+
"n" is the length of the Q.922 address which can be 2 or 4 octets.
「n」は、q.922アドレスの長さであり、2〜4オクテットです。
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の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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
10ビット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(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | unused (set to 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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
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カプセル化（独自のPIDを使用）を使用するさまざまなプロトコルによって交換されるデータまたはコントロールメッセージのカプセル化は影響を受けません。このようなメッセージにおけるIPv6プロトコル識別子のエンコードは、これらのプロトコルの仕様と[assnum]に従って行う必要があります。
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フレームリレーインターフェイスのインターフェイス識別子[AARCH]は、フレームリレーリンク[AARCH]で一意でなければならず、インターフェイスで終了したVCSで表される仮想リンクのそれぞれで一意でなければなりません。
The interface identifier for the Frame Relay interface is locally generated by the IPv6 module.
フレームリレーインターフェイスのインターフェイス識別子は、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 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.
フレームリレーネットワーク内の各仮想回路は、DLCIによってフレームリレーインターフェイスで一意に識別されます。さらに、DLCIは、フレームリレーインターフェイス上の仮想回路のエンドポイントの識別と見なすことができます。各フレームリレーVCは個別に構成または設定され、ネットワーク内の他のVCからの独立した仮想リンクのように機能するため、またはインターフェイス、リンク、ワイヤー、またはファイバーでは、フレームリレー上の各VCの終端ポイントを表示することは有益であると思われます。フレームリレーインターフェイスでオーバーレイされた「擬似インターフェイス」または「論理インターフェイス」としてのインターフェイス。さらに、IPv6 Autoconfiguredアドレス（IPv6リンクローカルアドレスを含む）を各「擬似インターフェイス」、つまりVCのエンドポイント、つまりフレームリレーインターフェイス上の各DLCIに関連付けることができて、有益であると思われます。
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つの異なるフィールドからフレームリレーインターフェイス識別子を構築することを示唆しています（図1）：
(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ビット」フィールド。最初のオクテットのビット6と7は、それぞれIPv6使用に変換されたEUI-64「ユニバーサル/ローカル」を表し、「個人/グループ」ビットをそれぞれ表しています。前者はゼロに設定されており、64ビットインターフェイス識別子値が局所的に重要であることを反映しています[AARCH]。後者は、ユニキャストアドレス[AARCH]を反映するために0に設定されています。
(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」フィールド。0〜24ビットで拡張する必要がある10、17、または23ビットのDLCI値を保持できる24ビットフィールド。有効なDLCIを含むDLCIベースのインターフェイス識別子 - は、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.
DLCIはフレームリレーノードからローカルであるため、同じDLCI値で識別されたフレームリレーネットワーク内にフレームリレーの個別の仮想回路を持つことができます。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | |"EUI bits" |
+ +-----+-----+
1 | |
+ +
2 | "Mid" |
+ +
3 | |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.1 Frame Relay Pseudo-Interface Identifier
図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]で指定された重複アドレス検出は、生成された識別子と結果としてリンクのリンクローカルアドレス（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）長さが6ビットの乱数（図2）。
(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）フレームリレーノード識別子-16ビット - は、フレームリレーノードをローカルに識別するために使用されるユーザー管理値です（図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）フレームリレーリンク識別子 - 16ビット - は、フレームリレーインターフェイスまたはリンクの数値表現です（図2）。
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 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.2 Frame Relay Pseudo-Interface Identifier
図2フレームリレー疑似インターフェイス識別子
or,
または、
(b.2) "Use of The Frame Relay address - E.164 [E164], X.121 [X25] numbers, or NSAP [NSAP] address"
（B.2）「フレームリレーアドレスの使用-E.164 [E164]、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.
フレームリレーインターフェイスにe.164またはx.121番号、またはNSAPアドレスがある場合、「ミッド」フィールドに次のように生じる数字で入力する必要があります。EのBCDエンコーディングで表される数値.164またはx.121番号、またはNSAPアドレスのバイナリエンコーディングは38ビットに切り捨てられます（図3）。フレームリレーインターフェイス識別子には「ローカル」の重要性があるため、このような値の使用には、リンク上のインターフェイス識別子の一意性を追加する以外に実際の実用的な目的はありません。したがって、切り捨ては高次または低次ビットで実行できます。高次ビットの切り捨てがリンクに独自性を提供しない場合 - おそらくDLCI値は一意ではない - これは、たとえばE.164番号の国内および/または国際的な目的地エリアよりもVCが範囲に広がる可能性が高いことを意味します。、したがって、低次ビットの切り捨てを次に実行する必要があります。
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 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Fig.3 Frame Relay (Pseudo) Interface Identifier
図3フレームリレー（擬似）インターフェイス識別子
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フレームリレーインターフェイスのIPv6 Link-Localアドレス[AARCH]は、上記のように形成されたインターフェイス識別子を接続することにより形成されます。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) |Frame Relay Interface Ident.|
+----------+-----------------------+----------------------------+
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-ND]で説明されています。さらに、IPv6アドレスへのリンク層アドレスのマッピングを可能にする隣接発見（ND）への拡張は、[Ind]の逆隣接発見（Ind）として定義されます。このドキュメントでは、NDおよびIndが使用するリンク層アドレスフィールドの形式を定義します。この仕様では、IPv6マルチキャストアドレスのアルゴリズムマッピングを定義して、リンクリンク層アドレスをフレーム化することはできません。
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: 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:
近隣発見で使用されるソース/ターゲットリンクレイヤーアドレスオプションおよびフレームリレーリンクの逆近隣ディスカバリーメッセージは、[IPv6-ND]で定義された一般的なルールに従います。IPv6アドレスは、リンク層アドレスと同等の2つのタイプの識別子をマッピングできます：DLCIS、およびフレームリレーアドレス。したがって、フレームリレーの場合、このドキュメントは、NDおよび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形式 - NDまたはINDメッセージ交換の前に確立されたVCのNDおよび/またはINDメッセージで使用されます - 主にPVC。SVCでの使用は、SVCの確立に成功した後にINDが採用された場合、逆近隣発見[Ind]メッセージで理にかなっています。リモートノードおよびそのSVCに割り当てられた他のIPv6アドレスに関する情報を収集します。
(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) フレームリレーアドレスフォーマット - 主に新しいSVCを確立する前に使用され、フレームリレーリモートノード識別子（リンクレイヤーアドレス）を特定のIPv6アドレスにマッピングします。
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.
注：実装は、近隣発見キャッシュに両方のタイプのリンクレイヤー識別子を保持する場合があります。さらに、2つのノード間の複数のVCの場合、1つのノードのNeightre Discovery Cacheは、VCを識別するすべてのDLCIにリモートノードのIPv6アドレスの1つのマッピングを保持する場合があります。
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アドレスの「フレームリレーアドレス形式」への近隣発見キャッシュマッピングと「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」ビットを使用することは、[nd]仕様と一致する必要があります。さらに、リンク層アドレス形式のタイプに関連する一貫性があるはずです。実装は、同じタイプのアドレス形式で近隣ディスカバリーキャッシュの1つのアドレス形式をオーバーライドする必要があります。
The "DLCI Format" is defined as follows:
「DLCI形式」は次のように定義されています。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
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) |
+-----+-----+-----+-----+-----+-----+-----+-----+
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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
17ビット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 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
23ビットDLCI
Option fields:
オプションフィールド：
Type 1 for Source Link-layer address. 2 for Target Link-layer address.
ソースリンク層アドレスのタイプ1。2ターゲットリンク層アドレスの場合。
Length The Length of the Option (including the Type and Length fields) in units of 8 octets. It has the value 1.
長さ8オクテットの単位のオプションの長さ（タイプおよび長さフィールドを含む）。値1があります。
Link-Layer Address The DLCI encoded as a Q.922 address.
リンク層アドレスQ.922アドレスとしてエンコードされたDLCI。
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) アドレスタイプ - 最初の2オクテットの最初の2ビットでエンコードされています。両方のビットは、DLCI形式を示すために1に設定されています。2つの最初のオクテットの残りのビットは使用されません - 送信時にゼロに設定する必要があり、受信機によって無視する必要があります。
(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-この形式のリンク層アドレスフィールド全体で利用可能な6オクテットの最後のオクテットにゼロでパディングされたQ.922アドレスとしてエンコードされています。
The "Frame Relay Address Format" is defined as follows:
「フレームリレーアドレスフォーマット」は、次のように定義されています。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
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| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Option fields:
オプションフィールド：
Type 1 for Source Link-layer address. 2 for Target Link-layer address.
ソースリンク層アドレスのタイプ1。2ターゲットリンク層アドレスの場合。
Length The length of the Option (including the Type and Length fields) in units of 8 octet. It may have the value:
長さ8オクテットの単位のオプションの長さ（タイプおよび長さフィールドを含む）。値があるかもしれません：
2 -- for E.164, or X.121 numbers or NSAP addresses not longer than 11 octets [E164], [X25], [NSAP].
2 -E.164またはX.121の場合、またはNSAPアドレスは11オクテット[E164]、[X25]、[NSAP]を超えていません。
3 -- for NSAP addresses longer than 11 but not longer than 19 octets.
3-NSAPアドレスは11を超えていますが、19オクテット以下です。
4 -- for NSAP addresses longer than 19 octets (not longer than the maximum NSAP address length) [NSAP].
4 -NSAPアドレスの場合、19オクテットより長い（最大NSAPアドレス長以下）[NSAP]。
Link-Layer Address The E.164, X.121, number encoded in Binary Coded Decimal (BCD), or the NSAP address.
リンク層アドレスE.164、X.121、バイナリコード付き小数（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) アドレスタイプ - 最初のオクテットの最初の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) アドレスファミリ番号-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でエンコードされています（オクテットあたり2桁）。e.164またはX.121に偶数数の数字がある場合、エンコードはすべてのエンコードオクテットを埋めます - 桁数の半分。E.164またはX.121数が奇数の数字の場合、最低の数字はオクテットの半分しか埋めません - それはE.164の最後のオクテットの最初の4ビット、またはXに配置されます。.121 BCDエンコーディング。利用可能な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オクテットにする多くのオクテットに収まらない場合、ゼロが詰め込まれています。
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.
フレームリレーネットワークは、リンク層ネイティブマルチキャストメカニズムを提供しません。隣接する発見メカニズムの正しい機能のためには、リンク層マルチキャストをエミュレートする必要があります。
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 Discovery（ND）のマルチキャストをエミュレートするには、ノードは、フレームリレーインターフェイス上のすべてのVCSにNDマルチキャストパケットを運ぶフレームを送信する必要があります。これは、All-NodeおよびSolicited Nodeマルチキャストアドレスの両方にアドレス指定されたNDメッセージに適用されます。この方法は、PVCでうまく機能します。PVCのメッシュを構成し、マルチキャストトラフィックのみに専念することができます。PVCのメッシュに代わるものは、ポイントツーマルチポイントPVCのセットです。
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.
NODEで受信したNeighbor Discovery Solicitationメッセージに、DLCIを使用したソースリンク層アドレスオプションが含まれている場合、NDプロトコルエンジン処理中にフィールドの正しい解釈に必要なフレームリレー固有の前処理を受ける必要があります。この処理は、近隣発見メッセージが近隣発見（ND）プロトコルエンジンによって処理される前に行われます。
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.
この処理の動機は、近隣発見メッセージのDLCIフィールドの局所的な重要性です。送信者ノードでのDLCIの重要性は、レシーバーノードでのDLCIの重要性とは異なります。言い換えれば、送信者のフレームリレー仮想回路を識別するDLCIは、受信機ノードの仮想回路を識別するDLCIとは異なる場合があります。さらに、送信者ノードは、受信機のDLCI値を認識していない場合があります。したがって、フレームリレー固有の前処理は、受信したソースリンク層アドレスオプションに格納され、受信者ノードに既知のフレームが受信された仮想回路のDLCI値を保存することにより、隣接発見勧誘メッセージの変更に構成されます。保存されるDLCI値は、適切な形式でエンコードする必要があります（前のセクションを参照）。フレームリレーモジュールからNeighbor Discovery PreprocessingモジュールへのDLCI値を渡すことは、実装の選択肢です。
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フレームインターフェイス識別子を生成するために、リンクレベルである仮想回路で一意性を提供することを目的としています。重複に対する保護は、IPv6 Stateless Autoconfigurationの重複したアドレス検出メカニズムによって達成されます。ここで説明するメカニズムのレベルでの偽造または事故に対するセキュリティ保護は、IPv6セキュリティメカニズム[IPSEC]、[IPSEC-AUTH]、[IPSEC-ESP]によって提供されます。Ind]メッセージ。
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認証検証の障害を回避するには、DLCI形式のソースリンクレイヤーアドレスオプションを含むNeighbor Discovery Solicitationメッセージのフレームリレー特異的前処理は、IPセキュリティ処理を完了した後、受信機ノードで実行する必要があります。
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.メルハーに、このドキュメントをレビューし、有用な提案を提供してくれたことに感謝します。また、G。Armitageのレビューと提案に感謝します。ドキュメントの改善に関する提案をしてくれたThomas Nartenにも感謝します。
[AARCH] Hinden, R. and S. Deering, "IPv6 Addressing Architecture", RFC 2373, July 1998.
[Aarch] Hinden、R。and S. Deering、「IPv6アドレス指定アーキテクチャ」、RFC 2373、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] Reynolds、J。and J. Postel、「Assigned Numbers」、Std 2、RFC 1700、1994年10月。http：//www.iana.org/numbers.htmlも参照してください。
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Autoconfiguration", RFC 2462, December 1998.
[Autoconf] Thomson、S。およびT. Narten、「IPv6 Stateless Autoconfiguration」、RFC 2462、1998年12月。
[CANON] Narten, T. and C. Burton, "A Caution on the Canonical Ordering of Link-Layer Addresses", RFC 2469, December 1998.
[Canon] Narten、T。およびC. Burton、「リンク層アドレスの標準的な順序付けに関する注意」、RFC 2469、1998年12月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", STD 55, RFC 2427, November 1998.
[Encaps] Brown、C。and A. Malis、「Multiprotocol Interconnect Over Frame Relay」、Std 55、RFC 2427、1998年11月。
[IND] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery", Work in Progress, December 1998.
[Ind] Conta、A。、「逆発見のためのIPv6近隣発見への拡張」、1998年12月、進行中の作業。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998.
[IPv6] Deering、S。およびR. Hinden、「インターネットプロトコルバージョン6仕様」、RFC 2460、1998年12月。
[IPv6-ATM] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[IPv6-ATM] Armitage、G.、Schulter、P。and M. Jork、「IPv6 Over ATM Networks」、RFC 2492、1999年1月。
[IPv6-ETH] Crawford, M., "Transmission of IPv6 packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6-Eth] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[IPv6-FDDI] Crawford, M., "Transmission of IPv6 packets over FDDI Networks", RFC 2467, December 1998.
[IPv6-Fddi] Crawford、M。、「FDDIネットワーク上のIPv6パケットの送信」、RFC 2467、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] Armitage、G.、Schulter、P.、Jork、M.、G。Harter、「非ブロードキャストマルチアクセス（NBMA）ネットワークを介したIPv6」、RFC 2491、1999年1月。
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPv6-ND] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[IPv6-PPP] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[IPv6-PPP] Haskin、D。およびE. Allen、「PPP上のIPバージョン6」、RFC 2472、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.、Crawford、M。、およびM. Thomas、「トークンリングネットワーク上のIPv6パケットの送信」、RFC 2470、1998年12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Atkinson、R。およびS. Kent、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402, December 1998.
[Ipsec-auth] Atkinson、R。and S. Kent、「IP認証ヘッダー」、RFC 2402、1998年12月。
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[Ipsec-esp] Atkinson、R。and S. Kent、「IPがセキュリティプロトコル（ESP）をカプセル化する」、RFC 2406、1998年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[E164] International Telecommunication Union - "Telephone Network and ISDN Operation, Numbering, Routing, amd Mobile Service", ITU-T Recommendation E.164, 1991.
[E164]国際通信組合 - 「電話ネットワークおよびISDN運用、番号付け、ルーティング、AMDモバイルサービス」、ITU -Tの推奨事項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：ネットワークレイヤーアドレス指定」。International Standard 8348/Addendum 2、ISO/IEC JTC 1、スイス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月。
Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742
Alex Conta Lucent Technologies Inc. 300 Baker Ave、Suite 100 Concord、MA 01742
Phone: +1-978-287-2842
EMail: aconta@lucent.com
Andrew Malis Ascend Communications 1 Robbins Rd Westford, MA 01886
アンドリュー・マリスアセンドコミュニケーション1ロビンズRDウェストフォード、マサチューセッツ州01886
Phone: +1-978-952-7414
EMail: malis@ascend.com
Martin Mueller Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742
Martin Mueller Lucent Technologies Inc. 300 Baker Ave、Suite 100 Concord、MA 01742
PHone: +1-978-287-2833
EMail: memueller@lucent.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。