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
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.
著作権（C）インターネット協会（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のマッピングは、リレーアドレスをフレームに対処します。また、これらのメッセージは、フレームリレーリンクを介して送信されたときに近隣探索[ND]と逆近隣探索[IND]メッセージで使用されるソース/ターゲットリンク層アドレスオプションの内容を指定します。それは、非ブロードキャストマルチアクセス（NBMA）メディア〔のIPv6-NBMA]、[IPv6の-ATM]、及び特定のリンク層のためのそのようなメカニズムを定義より大きいセット[たIPv6-ETHこのようなIPv6のメカニズムを定義する仕様のセットの一部であります]、[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.
この文書の情報は、パブリックまたはプライベートフレームリレーネットワーク上のエンドステーション（のDTE）として機能する中継装置のフレームに適用される（一般的な担体またはPTTによって提供たとえば、。）、フレームリレーエンドステーションは、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を定義します。後者の二つは、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].
キーワードは、MAY、OPTIONAL、必須、推奨、、、、で定義されるように解釈されるべきではないべきでないものとSHALL NOT MUST MUST [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は、約4088バイトに有効な最大フレームサイズを減少させる長さ4096バイトまでのフレームを保護します。 （例えば、FDDIまたはトークンリングで使用されるような）より大きな所望のフレームサイズは、まだ広く使用されていないとリレーフォーラムとITU-T規格のフレームに適合フレーム・リレー・システムのために必須ではない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は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.
フレームリレー回路は、入力および出力のための明確な最大フレームサイズの定義を可能にするが、簡略化のために、この仕様は、入力と出力の両方のための対称性、すなわち、同じ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:
（PVCおよびSVCの両方について）、フレームリレーのIPv6フレームのカプセル化は、他のプロトコルパケットと共にIPv6パケットを運ぶためにVCを可能にする、[ENCAPS]以下。 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 +
| |
+-----------------------+-----------------------+
"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のQ.922表現（標準的な順序に - 最初のビットは、最下位に格納されている、すなわち、メモリ内のバイトの右端のビット）[CANON]は以下の通りです。
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].
（独自のPIDを有する）SNAPカプセル化を使用する様々なプロトコルによって交換されるデータまたは制御メッセージのカプセル化は影響されません。このようなメッセージに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]上で一意である必要があり、インターフェイスで終端するVCによって表される仮想リンクの各々に一意でなければなりません。
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の終端点を表示するために有益と思われます「擬似インターフェース」または「論理インタフェース」などのインターフェイスは、フレームリレーインターフェイス上に重ねます。また、生成することができるし、フレームリレーインターフェース上の各DLCIに、すなわち、各「擬似インターフェース」、VCのすなわちエンドポイントにIPv6は（ローカルアドレスの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つの異なるフィールド（図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ビット" フィールド。 EUI-64のIPv6用に変換「ユニバーサル/ローカル」とそれぞれ「個人/グループ」ビットを表すビット6と第1のオクテットの7。前者は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" フィールド。 10、17、または24ビットに0で拡張されなければならない23ビットDLCI値を保持することができる24ビットのフィールド。 DLCIベースのインタフェース識別子 - 有効DLCIを含ん - PVCまたはSVC - 正常VCを確立した結果として生成されるべきです。
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.
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.
VC - - 一意で生成された識別子と、その結果リンク上のリンクローカルアドレスまで【AUTOCONF]で指定された重複アドレス検出は、インタフェース識別子とローカルリンクアドレス生成プロセス中に繰り返し使用されます。
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）の長さ（図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）フレームリレーノード識別子 - 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.
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].
【AARCH]のIPv6フレームリレーインタフェースのIPv6リンクローカルアドレスは、プレフィックスFE80 :: / 64 [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:
フレームリレーリンクのために近隣探索と逆近隣探索メッセージで使用されるソース/ターゲットリンク層アドレスオプションは、[IPv6の-ND]で定義された一般的な規則に従います。 IPv6アドレスは、リンク層アドレスに相当識別子の2種類をマップすることができます。
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:
DLCI、およびフレームリレーアドレス。そのため、フレームリレーのために、この文書は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フォーマット - ほとんどのPVC - 前ND又はINDメッセージ交換に確立されたVCでND及び/又はINDメッセージで使用されます。 INDがリモートノードとそのSVCに割り当てられた他のIPv6アドレスについての情報を収集するためにSVCの成功確立した後に使用される場合のSVCに使用することは、逆近隣探索[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）は、フレームリレーアドレスフォーマット - フレームは、特定の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.
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.
このような実装では、「フレームリレーのアドレス形式」と「DLCIフォーマット」リンク層アドレスにIPv6アドレスの近隣探索キャッシュのマッピングを区別するだろうメカニズム、または「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.
リンク層アドレスDLCIは、Q.922アドレスとしてエンコードされました。
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に設定されています。二つの第一のオクテット内のビットの残りは使用されない - それらは、送信時にゼロに設定しなければならなくて、受信機で無視しなければなりません。
(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アドレスとしてコード化は、この形式の全体のリンク層アドレスフィールドに利用可能な6つのオクテットの最後のオクテットにゼロで埋め。
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].
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ため[NSAP]（最大NSAPアドレスの長さよりも長くない）長い19オクテットよりも対処します。
Link-Layer Address The E.164, X.121, number encoded in Binary Coded Decimal (BCD), or the NSAP address.
リンク層は、2進化10進数（BCD）で符号化されたE.164、X.121、数、または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、またはXの最後のオクテットの最初の4ビットに配置されます0.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.
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.
近隣探索（ND）のためにマルチキャストをエミュレートするノードは、フレームリレーインタフェース上のすべてのVCにNDマルチキャストパケットを運ぶフレームを送信しなければなりません。これは、メッセージは、すべてのノードと要請ノードマルチキャストアドレスの両方に宛て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.
ノードによって受信された近隣探索要請メッセージは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の値が適切な形式で符号化されなければならない（前のセクションを参照）。近隣探索前処理モジュールへのフレームリレーモジュールからの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ステートレス自動設定重複アドレス検出メカニズムにより達成されます。セキュリティここで説明するメカニズムのレベルでの偽造や事故に対する保護がIPv6のセキュリティ・メカニズムによって提供され、[IPSEC]、[IPSEC-AUTH]、[IPSEC-ESP]は、近隣探索[IPv6の-ND]または逆近隣探索に適用されます[ 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.
それはIP Securityの処理を完了した後、IPsecの認証検証の失敗を避けるために、DLCIフォーマットソースリンク層アドレスオプションが含まれている近隣探索要請メッセージのフレームリレーの特定の前処理は、受信ノードによって行われなければなりません。
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氏にも感謝します。
[AARCH] Hinden, R. and S. Deering, "IPv6 Addressing Architecture", RFC 2373, July 1998.
[AARCH] HindenとR.とS.デアリング、 "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]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、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]トムソン、S.とT. Narten氏、 "IPv6のステートレス自動設定"、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.バートン、「リンク層アドレスの正規順序に注意」、RFC 2469、1998年12月。
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", STD 55, RFC 2427, November 1998.
[ENCAPS]ブラウン、C.とA. Malis、 "フレームリレー上のマルチインターコネクト"、STD 55、RFC 2427、1998年11月。
[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の仕様"、RFC 2460、1998年12月。
[IPv6-ATM] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[IPv6の-ATM]アーミテージ、G.、Schulter、P.とM. Jorkの、 "ATMネットワーク上のIPv6"、RFC 2492、1999年1月。
[IPv6-ETH] Crawford, M., "Transmission of IPv6 packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6の-ETH]クロフォード、M.、 "イーサネットネットワーク上のIPv6パケットの送信"、RFC 2464、1998年12月。
[IPv6-FDDI] Crawford, M., "Transmission of IPv6 packets over FDDI Networks", RFC 2467, December 1998.
[IPv6の-FDDI]クロフォード、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]アーミテージ、G.、Schulter、P.、Jorkの、M.およびG.ハーター、 "非ブロードキャスト多重アクセス（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.シンプソン、 "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.アレン、 "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.、クロフォード、M.とM.トーマス、 "トークンリングネットワーク上のIPv6パケットの送信"、RFC 2470、1998年12月。
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]アトキンソン、R.とS.ケント、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402, December 1998.
[IPSEC-AUTH]アトキンソン、R.とS.ケント、 "IP認証ヘッダー"、RFC 2402、1998年12月。
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[IPSEC-ESP]アトキンソン、R.とS.ケント、 "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]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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：ネットワーク層アドレッシング」。国際標準8348 /補遺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
アレックス・コンタルーセント・テクノロジーズ・インク300ベーカーアベニュー、スイート100コンコード、MA 01742
Phone: +1-978-287-2842 EMail: aconta@lucent.com
電話：+ 1-978-287-2842 Eメール：aconta@lucent.com
Andrew Malis Ascend Communications 1 Robbins Rd Westford, MA 01886
アンドリューMalisアセンドコミュニケーションズ1ロビンスRdのウェストフォード、MA 01886
Phone: +1-978-952-7414 EMail: malis@ascend.com
電話：+ 1-978-952-7414 Eメール：malis@ascend.com
Martin Mueller Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742
マーティン・ミューラールーセント・テクノロジーズ・インク300ベーカーアベニュー、スイート100コンコード、MA 01742
PHone: +1-978-287-2833 EMail: memueller@lucent.com
電話：+ 1-978-287-2833 Eメール：memueller@lucent.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。