この文書はRFC2590の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
概要
This memo describes mechanisms for the transmission of IPv6 packets
over Frame Relay networks.
この文書はＩＰｖ６パケットをフレームリレーネットワークで運ぶメカニ
ズムを記述します
Table of Contents
目次
1. Introduction
1. はじめに
2. Maximum Transmission Unit
2. 最大転送単位
3. IPv6 Frame Format
3. ＩＰｖ６フレームフォーマット
4. Stateless Autoconfiguration
4. ステートレス自動設定
4.1 Generating the "Mid" field.
4.1 「中間」フィールドの生成
5. Link-Local Addresses
5. リンクローカルアドレス
6. Address Mapping -- Unicast, Multicast
6. アドレスマッピング−ユニキャストとマルチキャスト
7. Sending Neighbor Discovery Messages
7. 近隣探索メッセージ送信
8. Receiving Neighbor Discovery Messages
8. 近隣探索メッセージ受信
9. Security Considerations
9. セキュリティの考慮
10. Acknowledgments
10. 謝辞
11. References
11. 参考文献
12. Authors' Addresses
12. 著者のアドレス
13. Full Copyright Statement
13. 著作権表示全文
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...
この文書はフレームリレーネットワーク上でのＩＰｖ６パケット転送のフレー
ムフォーマットと、フレームリレーリンク上のＩＰｖ６リンクローカルアド
レスの生成方法と、ＩＰｖ６アドレスとフレームリレーアドレスの対応方法
を指定します。これは近隣探索[ND]と逆近隣探索[IND]メッセージがフレーム
リレーリンクの上を伝達される時に、メッセージで使われるソース／目標リ
ンクレイヤアドレスオプションの内容を指定します。これは非ブロードキャ
スト多重アクセス（ＮＢＭＡ）メディアでのＩＰｖ６メカニズム[IPv6-NBMA]
[IPv6-ATM]や特定のリンクレイヤのこのようなメカニズムの定義などを仕様
書群[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.
この文書の情報は（例えば公共キャリアやＰＴＴの提供する）公共か私的フ
レームリレーネットワークの終端局のデバイスに適用されます。フレームリ
レー終端局はＩＰｖ６ホストかルーターです。この文書でそれらはノードと
述べられます。
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.
フレームリレーネットワークで、多くの仮想回路がステーション（ノード）
の間の接続を形成します。相互に結び付いた装置の結果として生じている集
合体はプライベートフレームリレーグループを形成し、完全「メッシュ」の
仮想回路で完全に相互接続されるか、部分的に相互に結び付けるだけかもし
れません。どちらの場合でも、各フレームリレーインタフェース（カード）
は各仮想回路をユニークなデータリンク接続識別子（ＤＬＣＩ）で識別しま
す。たいていの状況で、ＤＬＣＩは各フレームリレーインタフェースの厳密
に局部的な意味を持っています。
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.
デフォルトでＤＬＣＩ長は１０ビットです。フレームリレー仕様書が１６や
１７や２３ビットＤＬＣＩを定義します。前者は使わず、後２者はＳＶＣと
共に使用するのが勧められます。
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.
フレームリレー仮想回路が永久仮想回路−ＰＶＣ−として、あるいは動的に
切り替える仮想回路−ＳＶＣ−として管理的に作ることができます。この文
書で定義されたメカニズムは永久仮想回路でも動的仮想回路でも当てはまり、
それらがポイントポイントでもポイントマルチポイントでも当てはまります。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
in [RFC 2119].
キーワードMUSTとMUST NOTとMAYとOPTIONALとREQUIREDとRECOMMENDEDとSHALL
とSHALL NOTとSHOULDとSHOULD NOTは[RFC 2119]で定義されるように翻訳され
ます。
2. Maximum Transmission Unit
2. 最大転送単位
The IPv6 minimum MTU is defined in [IPv6].
ＩＰｖ６の最大ＭＴＵは[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.
一般に、フレームリレー装置が少なくとも１６００オクテットの最大のフレー
ムサイズを持つように設定されます。それ故に、フレームリレーインタフェー
スのデフォルトＩＰｖ６ＭＴＵサイズは１５９２であると考えられます。
A smaller than default frame size can be configured but of course not
smaller than the minimum 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.
デフォルトＩＰｖ６ＭＴＵより大きい適切なフレームリレーフレームサイズ
が分割を避けるように設定できます。最大のフレームサイズはＨＤＬＣレベ
ルで使われるＣＲＣ生成メカニズムによって決まります。ＣＲＣ１６が４０
９６バイトまでのフレームを守り、実効的な最大のフレームサイズはおよそ
４０８８バイトです。（ＦＤＤＩやトークンリングで使うような）より大き
いフレームサイズを望むなら、フレームリレーフォーラムとＩＴＵ−Ｔ標準
に従うフレームリレーシステムでまだ広く使われてなく義務的でないＣＲＣ
３２機構を必要とします。
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.
一般に、もし上位レイヤが適切なエラー保護／検出メカニズムを供給するな
ら、実装がリンクレイヤで４０８０オクテットサイズ以上のフレームサイズ
設定を許すかもしれませんが、リンクレイヤのエラー保護／検出メカニズム
は弱くなります。しかしながら、ＩＰｖ６が上層と下層のエラー発見に依存
するので、４０８０より大きい値にＩＰｖ６ＭＴＵを設定することは強く反
対します。
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.
フレームリレー回路が入力と出力で別の最大のフレームサイズの定義を許す
が、簡略化の目的のために、この仕様書は入力と出力の両方で対称、すなわ
ち同じＭＴＵを想定します。
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.
さらに、実装がフレームリレー最大フレームサイズ設定をインタフェース
（リンクやカード）レベルで制限するかもしれなくて、それは（リンクやカー
ド上の）インタフェース上の全てのＰＶＣやＳＶＣに強制されます。ＳＶＣ
で、回路設定時に交渉された最大フレームサイズパラメータは設定された最
大フレームサイズを超えないでしょう。
3. IPv6 Frame Format
3. ＩＰｖ６フレームフォーマット
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:
（ＰＶＣとＳＶＣ両方で）フレームリレーでのＩＰｖ６フレームカプセル化
は[ENCAPS]の通りで、これはＶＣに他のプロトコルパケットとともにＩＰｖ
６パケットを運ぶことを許します。ＮＬＰＩＤフレームフォーマットが使わ
れ、ＩＰｖ６のＮＬＰＩＤは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.
「ｎ」はQ.９２２アドレス長で２オクテットか４オクテットです。
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:
ＤＬＣＩのQ.９２２表現は以下です（正規順で−最初のビットは最下位、
すなわちメモリのバイトの最も右です）[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
１０ビットＤＬＣＩ
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
１７ビットＤＬＣＩ
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
２３ビットＤＬＣＩ
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].
（それら自身のＰＩＤで）ＳＮＡＰカプセル化を使う種々のプロトコルによっ
て交換されるデータや制御装置メッセージのカプセル化には影響がありませ
ん。このようなメッセージでのＩＰｖ６プロトコル識別子のコーディングは
それらのプロトコルの仕様書と[ASSNUM]に従ってされなくてはなりません
(MUST)。
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.
ＩＰｖ６フレームリレーインタフェースのためのインタフェース識別子
[AARCH]がフレームリレーリンク[AARCH]上でユニークであり、インタフェー
ス上で終端したＶＣによって表される仮想のリンクのそれぞれの上でもユニー
クであるに違いありません。
The interface identifier for the Frame Relay interface is locally
generated by the IPv6 module.
フレームリレーインタフェースのインタフェース識別子はローカルにＩＰｖ
６モジュールによって生成されます。
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.
各フレームリレーネットワークでの仮想回路がフレームリレーインタフェー
ス上でＤＬＣＩによってユニークに識別されます。さらに、ＤＬＣＩがフレー
ムリレーインタフェース上の仮想回路の終端の識別子と見ることができます。
各フレームリレーＶＣが個別に設定されるか確立し、ネットワーク上か、リ
ンクやワイヤかファイバのインターフェース上で、他のＶＣかだ独立な仮想
リンクとして動作し、フレームリレーインタフェース上の各ＶＣの終端ポイ
ントを「疑似インタフェース」あるいはフレームリレーインタフェースに重
なった「論理名インタフェース」だと見なすことは有益に思われます。さら
に、各「疑似インタフェース」、すなわちＶＣの終端、すなわちフレームリ
レーインタフェース上の各ＤＬＣＩを、（ＩＰｖ６リンクローカルアドレス
を含めて）ＩＰｖ６自動設定アドレスの生成と関連づけが可能であることは
有益に思われます。
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):
上に記述された利益を達成するために、この文書で指定されたメカニズムは
３つの別のフィールド（図１）からフレームリレーインタフェース識別子を
作ることを提案します：
(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) 「ＥＵＩビット」フィールド。最初のオクテットのビット６と７、それ
ぞれＩＰｖ６で使うＥＵＩ−６４の「ユニバーサル／ローカル」と「個
人／グループ」を表わすビットです。前者は６４ビットのインタフェー
ス識別子値がローカルに意味を持つことを示すためにゼロにセットされ
ます[AARCH]。後者はユニキャストアドレスを反映するために０にセッ
トされます[AARCH]。
(b) The "Mid" field. A 38 bit field which is generated with the
purpose of adding uniqueness to the interface identifier.
(b) 「中間」フィールド。インタフェース識別子にユニークさを加える目的
で生成される３８ビットのフィールド。
(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) 「ＤＬＣＩ」フィールド。２４ビットフィールドには、０を付けて２４
ビットに拡張した(MUST)１０か１７か２３ビットＤＬＣＩ値を設定しま
す(MAY)。（正当なＤＬＣＩを含んでいる）ＤＬＣＩベースのインター
フェース識別子は、ＶＣ（ ＰＶＣあるいはＳＶＣ ）の生成が成功した
結果として生成されるべきです(SHOULD)。
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.
もしＤＬＣＩが既知ではないなら、フィールドは２４ビットの１から成
る「特定されていないＤＬＣＩ」値を設定しなければなりません(MUST)。
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.
ＤＬＣＩがフレームリレーノードにローカルに決まっているので、フレーム
リレーネットワークの中の別の仮想回路が同じＤＬＣＩ値を持つことは可能
です。
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
図１ フレームリレー疑似インタフェース識別子
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:
「中間」は多数の方法で生成できます。この仕様書は２つのメカニズムを
示唆します：
(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) 長さ６ビットの乱数（図２）
(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) フレームリレーノード識別子−１６ビット− はローカルにフレー
ムリレーノードを識別するために使うユーザ管理値（図２）
(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) フレームリレーリンク識別子−１６ビット−はフレームリレーイン
タフェースあるいはリンクの数値表現です。
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
図２ フレームリレー疑似インタフェース識別子
or,
または、
(b.2) "Use of The Frame Relay address - E.164 [E164], X.121
[X25] numbers, or NSAP [NSAP] address"
(b.2) 「フレームリレーアドレス−Ｅ.１６４[E164]やＸ.１２１番号[X25]
やＮＳＡＰアドレス[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.
もしフレームリレーインタフェースがＥ.１６４かＸ.１２１番号を持つ
なら、「中間」フィールドを以下の様にその数で埋めます(MUST)：３８
ビットに切り詰めた、ＢＣＤコーディングで表現されたＥ.１６４や
Ｘ.１２１番号や、ＮＳＡＰアドレスの２進表現（図３）。フレームリレー
インタフェース識別子が「ローカル」に意味を持つので、リンク上でイ
ンタフェース識別子のユニークさを加える以外、この値に真の実用的な
目的はありません。それ故に切詰めはに上位ビットで行う事も下位ビッ
トで行う事もできます。もし、ＶＣが例えばＥ.１６４の国内か国際宛先
部を示して、上位ビットの切り取りがリンク上でユニークさを供給しな
いなら−多分ＤＬＣＩ値がユニークではないので−次に下位ビットの切
り取りをするべきで、これはユニークさを供給する見込みが高いでしょう。
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
図３ フレームリレー（疑似）インタフェース識別子
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].
ＩＰｖ６フレームリレーインタフェースのＩＰｖ６リンクローカルアドレス
[AARCH]は上で生成したインタフェース識別子にプレフィックスFE80::/64
[AARCH]を付加して生成します。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) |Frame Relay Interface 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-ND]で記
述されます。さらに、リンクレイヤアドレスをＩＰｖ６アドレスにマッピン
グする近隣探索（ＮＤ）への拡張が[IND]で逆近隣探索（ＩＮＤ）と定義され
ます。この文書はＮＤとＩＮＤで使われたリンクレイヤアドレスフィールド
のフォーマットを定義します。この仕様書はＩＰｖ６マルチキャストアドレ
スをフレームリレーリンクレイヤアドレスにマッピングするアルゴリズムを
定義しません。
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]で定義された一般的な規則
に従います。ＩＰｖ６アドレスがリンクレイヤアドレスと等しい識別子の２
つのタイプをマップすることができます：
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:
ＤＬＣＩとフレームリレーアドレス。それ故に、フレームリレーのために、
この文書はＮＤとＩＮＤメッセージのリンクレイヤアドレスフィールドのた
めに２つの異なるフォーマットを定義します：
(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) ＤＬＣＩフォーマット−ＮＤやＩＮＤメッセージ交換前に既に確立して
いるＶＣ−たいていＰＶＣ−上でのＮＤやＩＮＤメッセージでの使用。
ＳＶＣの上の使用は、もしＳＶＣが成立した後に遠隔ノードのそのＳＶ
Ｃに割り当てられた他のＩＰｖ６アドレスの情報を集めるためにＩＮＤ
で使用するなら、逆近隣探索[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) フレームリレーアドレスフォーマット−フレームリレー遠隔のノード識
別子（リンクレイヤアドレス）をあるＩＰｖ６アドレスにマップするた
めに、新しいＳＶＣを作る前での使用。
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.
この様な実装でのメカニズムは、ＩＰｖ６アドレスから「フレームリレー
アドレスフォーマット」と「ＤＬＣＩフォーマット」リンクレイヤアド
レスへのマッピングをする近隣探索キャッシュを分離するか、「ＤＬＣ
Ｉフォーマット」アドレスへの様々なマッピングがあるだろうが、これ
らはこの仕様書の範囲外です。
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.
上記のリンクレイヤアドレスフォーマットを含んでいる広告メッセージ
での上書き「Ｏ」ビットの使用は、[ND]仕様書に従うべきです(SHOULD)。
さらに、リンクレイヤアドレスフォーマットタイプに一貫性があるべき
です：実装が近隣探索キャッシュ１つのアドレスフォーマットを上書き
する時には同じタイプのアドレスフォーマットを上書きするべきです。
The "DLCI Format" is defined as follows:
「ＤＬＣＩフォーマット」は次のように定義されます：
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+
with a DLCI (Q.922 address) encoded as option value:
オプション値でコード化されたＤＬＣＩ（Q.９２２アドレス）で：
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
１０ビットＤＬＣＩ
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
１７ビットＤＬＣＩ
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
２３ビットＤＬＣＩ
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.
長さ （タイプと長さフィールドを含めて）８オクテット
単位でのオプションの長さ。値は１です。
Link-Layer Address The DLCI encoded as a Q.922 address.
リンクレイヤアドレス Ｑ.９２２としてＤＬＣＩコード化。
Description
詳細
The "DLCI Format" option value field has two components:
「ＤＬＣＩフォーマット」オプションフィールドは２つの要素を持ちます。
(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) アドレスタイプ−最初の２オクテットの最初の２ビットでコード
化。ＤＬＣＩフォーマットを示唆するため両方のビットが１です。
最初の２オクテットの残りのビットは使われません−これらは送
信時に０を設定し(MUST)、受信時に無視します(MUST)。
(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) ＤＬＣＩ − Q.９２２アドレスでコード化し、このフォーマット
の全部のリンクレイヤアドレスフィールドで利用可能ように、最
後の６オクテットはゼロを埋めます。
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:
オプション価値としてコード化されたＥ.１６４やＸ.１２１番号やＮＳＡＰ
アドレスで：
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:
長さ （タイプと長さフィールドを含めて）８オクテット
単位でのオプションの長さ。値は以下です。
2 -- for E.164, or X.121 numbers or NSAP
addresses not longer than 11 octets
[E164], [X25], [NSAP].
2 -- １１オクテットを超えないＥ.１６４やＸ.１２１番
号やＮＳＡＰアドレス[E164], [X25], [NSAP]。
3 -- for NSAP addresses longer than 11 but
not longer than 19 octets.
3 -- １１オクテットを超え１９オクテットを超えない
ＮＳＡＰアドレス。
4 -- for NSAP addresses longer than 19 octets
(not longer than the maximum NSAP address
length) [NSAP].
4 -- １９オクテットを超え（ＮＳＡＰアドレスの最大長
を超えない）ＮＳＡＰアドレス[NSAP]。
Link-Layer Address The E.164, X.121, number encoded in
Binary Coded Decimal (BCD), or the NSAP
address.
リンクレイヤアドレス ２進化１０進（ＢＣＤ）でコード化された
Ｅ.１６４かＸ.１２１番号、またはＮＳＡ
Ｐアドレス。
Description
詳細
The "Frame Relay Address" option value has three components:
「フレームリレーアドレス」オプション値は３つの要素を持っています：
(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) アドレスタイプ−最初の２オクテットの最初の２ビットでコード化。
最初のビットは０で、次のビットは１です。
(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) 大きさ−最初のオクテットの後ろ（上位）６ビットにコード化しま
す。フィールドの最大の値はＥ.１６４やＸ.１２１やＮＳＡＰアド
レスの最大サイズです。
(c) Address Family Number -- the number assigned for the E.164,
X.121, or NSAP address family [ASSNUM].
(c) アドレスファミリー番号−Ｅ.１６４やＸ.１２１やＮＳＡＰに割り当
てたアドレスファミリー[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) Ｅ.１６４、Ｘ.１２１番号−ＢＣＤ（オクテット毎に２桁）でコード
化します。もしＥ.１６４やＸ.１２１が偶数桁なら、コーディングは
桁数の半分のオクテット数で、すべてのオクテットを満たすでしょう。
もしＥ.１６４やＸ.１２１が奇数桁なら、最下位桁はオクテットの半
分だけを埋め、Ｅ.１６４やＸ.１２１エンコーディングの最終オクテッ
トの最初の４ビットに置かれます。最後の１１オクテット目までの利
用可能フィールドの残りはゼロを埋めます。
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.
ＮＳＡＰアドレス−ＮＳＡＰアドレス。それは、もしＮＳＡＰアドレ
スは、オプション長を８オクテットの倍数にするようにゼロを追加し
ます。
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.
フレームリレーネットワークがリンクレイヤネイティブのマルチキャストメ
カニズムを供給しません。近隣探索メカニズムが正しく作用するために、リ
ンクレイヤマルチキャストがエミュレートされなくてはなりません。
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.
近隣探索（ＮＤ）のためにマルチキャストをエミュレートするためには、ノー
ドはフレームリレーインタフェース上のすべてのＶＣにＮＤマルチキャスト
パケットを運んでいるフレームを送らなくてはなりません(MUST)。これは全
ノードマルチキャストと要請ノードマルチキャストの両方に当てはまります。
この方法はＰＶＣでうまくいきます。メッシュのＰＶＣがマルチキャストト
ラフィックのみ設定されるかもしれません(MAY)。メッシュのＰＶＣの代案は
ポイントからマルチポイントへのＰＶＣです。
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.
もしノードが受信した近隣探索懇願メッセージにＤＬＣＩを設定したソース
リンクレイヤアドレスオプションを含んでいるなら、メッセージは、ＮＤプ
ロトコルエンジン処理がフィールドの正しい解釈に必要な、フレームリレー
特有の前処理をしなくてはなりません(MUST)。この処理は、近隣探索メッセー
ジが近隣探索（ＮＤ）プロトコルエンジンによって処理される前にします。
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.
この処理の動機は近隣探索メッセージのＤＬＣＩフィールドがローカルに意
味を持つことです：送信者ノードでのＤＬＣＩの意味は受信ノードのＤＬＣ
Ｉの意味と異なっています。換言すれば、送信者がフレームリレー仮想回路
を識別するＤＬＣＩは受信ノードが仮想回路を識別するＤＬＣＩと異なって
いるかもしれません。さらに、送信者ノードは受話者のＤＬＣＩ値を知らな
いかもしれません。それ故に、フレームリレー特有の前処理は、ソースリン
クレイヤアドレスオプションにそのフレームを受信した仮想回路の、受信ノー
ドが知ってる、ＤＬＣＩ値を設定する事で、受信した近隣探索懇願メッセー
ジを修正することです。保管されるＤＬＣＩ値は適切なフォーマットでコー
ド化されます（前章参照）。フレームリレーモジュールから近隣探索前処理
モジュールへのＤＬＣＩ値の渡し方は実装依存です。
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-ND]や逆近隣探索[IND]メッセージに適用した、ＩＰ
ｖ６セキュリティ機構[IPSEC], [IPSEC-Auth], [IPSEC-ESP] によって供給
されます。
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.
ＩＰＳｅｃ認証証明故障を避けるために、ＤＬＣＩフォーマットソースリン
クレイヤアドレスオプションを含む近隣探索懇願メッセージのフレームリレー
特有の前処理は、受信ノードがＩＰセキュリティ処理を完了した後にされな
くてはなりません(MUST)。
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. Harringtonと
M. Merharに感謝します。同じくレビューと提案に対してG.Armitageに感謝し
ます。同じく文書の提案と改善に対してThomas Nartenに本当に感謝します。
11. References
11. 参考文献
[AARCH] Hinden, R. and S. Deering, "IPv6 Addressing
Architecture", RFC 2373, July 1998.
[ASSNUM] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC 2462, December 1998.
[CANON] Narten, T. and C. Burton, "A Caution on the Canonical
Ordering of Link-Layer Addresses", RFC 2469, December
1998.
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over
Frame Relay", STD 55, RFC 2427, November 1998.
[IND] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery", Work in Progress, December 1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[IPv6-ATM] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.
[IPv6-ETH] Crawford, M., "Transmission of IPv6 packets over
Ethernet Networks", RFC 2464, December 1998.
[IPv6-FDDI] Crawford, M., "Transmission of IPv6 packets over FDDI
Networks", RFC 2467, December 1998.
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter,
"IPv6 over Non-Broadcast Multiple Access (NBMA)
networks", RFC 2491, January 1999.
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[IPv6-PPP] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
2472, December 1998.
[IPv6-TR] Narten, T., Crawford, M. and M. Thomas, "Transmission
of IPv6 packets over Token Ring Networks", RFC 2470,
December 1998.
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header",
RFC 2402, December 1998.
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[E164] International Telecommunication Union - "Telephone
Network and ISDN Operation, Numbering, Routing, amd
Mobile 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.
[X25] "Information Technology -- Data Communications -- X.25
Packet Layer Protocol for Data Terminal Equipment",
International Standard 8208, March 1988.
12. Authors' Addresses
12. 著者のアドレス
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
Phone: +1-978-952-7414
EMail: malis@ascend.com
Martin Mueller
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
PHone: +1-978-287-2833
EMail: memueller@lucent.com
13. Full Copyright Statement
13. 著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。