この文書はRFC2472の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group D. Haskin
Request for Comments: 2472 E. Allen
Obsoletes: 2023 Bay Networks, Inc.
Category: Standards Track December 1998
IP Version 6 over PPP
ＰＰＰ上のＩＰｖ６
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 (1998). All Rights Reserved.
Abstract
概要
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol, and
proposes a family of Network Control Protocols (NCPs) for
establishing and configuring different network-layer protocols.
Point-to-Pointプロトコル(PPP)[1]は、１対１リンクに関するネットワーク
レイヤプロトコル情報をカプセルする標準の方法を提供します。ＰＰＰは異
なったネットワーク層プロトコルの確立と構成のために拡張可能なリンク制
御ロトコルを定義し、ネットワーク制御プロトコル(NCP)群を提案します。
This document defines the method for transmission of IP Version 6 [2]
packets over PPP links as well as the Network Control Protocol (NCP)
for establishing and configuring the IPv6 over PPP. It also specifies
the method of forming IPv6 link-local addresses on PPP links.
この文書はＰＰＰリンク上でのＩＰバージョン６[2]パケットの転送方法と、
ＰＰＰ上でのＩＰｖ６の確立と構成のためのネットワーク制御プロトコル
(NCP)を定義します。また、ＩＰｖ６リンクローカルアドレスをＰＰＰリンク
上で生成する方法を規定します。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. Specification of Requirements
1.1. 仕様と条件
2. Sending IPv6 Datagrams
2. IPv6データグラムの送信
3. A PPP Network Control Protocol for IPv6
3. ＩＰｖ６のＰＰＰネットワーク制御プロトコル
4. IPV6CP Configuration Options
4. IPV6CP設定オプション
4.1. Interface-Identifier
4.1. インタフェース識別子
4.2. IPv6-Compression-Protocol
4.2. ＩＰｖ６圧縮プロトコル
5. Stateless Autoconfiguration and Link-Local Addresses
5. ステートレス自動設定とリンクローカルアドレス
6. Security Considerations
6. セキュリティに関する考察
7. Acknowledgments
7. 謝辞
8. Changes from RFC-2023
8. RFC2023からの変更点
9. References
9. 参考文献
10. Authors' Addresses
10. 著者のアドレス
11. Full Copyright Statement
11. 著作権表示全文
1. Introduction
1. はじめに
PPP has three main components:
ＰＰＰは主に３つの内容をもちます：
1) A method for encapsulating datagrams over serial links.
1) シリアルリンク上でのデータグラムのパケット化の方法
2) A Link Control Protocol (LCP) for establishing, configuring, and
testing the data-link connection.
2) データリンク接続の確立と設定と試験のためのリンク制御プロトコル(LCP)
3) A family of Network Control Protocols (NCPs) for establishing and
configuring different network-layer protocols.
3) 異なるネットワーク層プロトコルの確立と設定のためのネットワーク制
御プロトコル(NCP)群
In order to establish communications over a point-to-point link, each
end of the PPP link must first send LCP packets to configure and test
the data link. After the link has been established and optional
facilities have been negotiated as needed by the LCP, PPP must send
NCP packets to choose and configure one or more network-layer
protocols. Once each of the chosen network-layer protocols has been
configured, datagrams from each network-layer protocol can be sent
over the link.
１対１リンク上で通信を確立するために、各ＰＰＰの終点が最初にデータリ
ンクの構成と試験をするＬＣＰパケットを送ります。リンクが確立され、Ｌ
ＣＰで必要なオプション機能が交渉されたら、ＰＰＰは１つ以上のネットワー
ク層プロトコルを設定するためにＮＣＰパケットを送らなくてはなりません。
選択されたそれぞれがネットワーク層プロトコルの設定されると、それぞれ
のネットワーク層プロトコルのデータグラムをリンク上で送ることができま
す。
In this document, the NCP for establishing and configuring the IPv6
over PPP is referred as the IPv6 Control Protocol (IPV6CP).
この文書で、ＰＰＰ上でＩＰｖ６を設立し設定するＮＣＰを、ＩＰｖ６制御
プロトコルと言います。
The link will remain configured for communications until explicit LCP
or NCP packets close the link down, or until some external event
occurs (power failure at the other end, carrier drop, etc.).
リンクは、明示的にＬＣＰかＮＣＰパケットがリンクを閉じるか、いずれか
の外部のイベント（他点の電源断、キャリアがなくなる、など）が起こるま
で、通信のための設定が残ります。
1.1. Specification of Requirements
1.1. 仕様と条件
In this document, several words are used to signify the requirements
of the specification.
この文書で、いくつかの言葉が仕様書の条件を意味するために使われます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [7].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は[7]
で記述されるように翻訳されます。
2. Sending IPv6 Datagrams
2. IPv6データグラムの送信
Before any IPv6 packets may be communicated, PPP MUST reach the
Network-Layer Protocol phase, and the IPv6 Control Protocol MUST
reach the Opened state.
ＩＰｖ６パケットを転送する前に、ＰＰＰはネットワークレイヤプロトコル
フェーズに達しなければならなく(MUST)、ＩＰｖ６制御プロトコルはOpened
状態に達しなければなりません(MUST)。
Exactly one IPv6 packet is encapsulated in the Information field of
PPP Data Link Layer frames where the Protocol field indicates type
hex 0057 (Internet Protocol Version 6).
ＩＰｖ６パケットは、プロトコルフィールドが１６進数で0057(インターネッ
トプロトコルバー順６)を示すＰＰＰデータリンクレイヤフレームの情報
フィールドに正確にカプセル化されます。
The maximum length of an IPv6 packet transmitted over a PPP link is
the same as the maximum length of the Information field of a PPP data
link layer frame. PPP links supporting IPv6 MUST allow the
information field at least as large as the minimum link MTU size
required for IPv6 [2].
ＰＰＰリンク上に伝送されるＩＰｖ６パケットの最大長はＰＰＰデータリン
クレイヤフレームの情報フィールドの最大長と同じです。ＩＰｖ６をサポー
トするＰＰＰリンクの情報サイズは最低でもＩＰｖ６最小ＭＴＵ（１２８０）
と同じでなければなりません(MUST)。
3. A PPP Network Control Protocol for IPv6
3. ＩＰｖ６のＰＰＰネットワーク制御プロトコル
The IPv6 Control Protocol (IPV6CP) is responsible for configuring,
enabling, and disabling the IPv6 protocol modules on both ends of the
point-to-point link. IPV6CP uses the same packet exchange mechanism
as the Link Control Protocol (LCP). IPV6CP packets may not be
exchanged until PPP has reached the Network-Layer Protocol phase.
IPV6CP packets received before this phase is reached should be
silently discarded.
ＩＰｖ６制御プロトコル(IPV6CP)はポイントポイントリンクの両端における
ＩＰｖ６プロトコルモジュールの構成と動作と停止に責任があります。
IPV6CPはＬＣＰと同一のパケット交換メカニズムを使用しています。パケッ
トはＰＰＰがネットワーク層プロトコルフェーズに到達すつまで交換できま
せん。仮にこのフェーズの前にIPV6CPパケットを受信した場合は破棄しなけ
ればなりません。
The IPv6 Control Protocol is exactly the same as the Link Control
Protocol [1] with the following exceptions:
IPv6CPは次の例外を除いてほとんどＬＣＰと同じです。
Data Link Layer Protocol Field
データリンク層プロトコルフィールド
Exactly one IPV6CP packet is encapsulated in the Information
field of PPP Data Link Layer frames where the Protocol field
indicates type hex 8057 (IPv6 Control Protocol).
プロトコルフィールドタイプが１６進数で８０５７（ＩＰｖ６制御プ
ロトコル）のＰＰＰデータリンク層フレームの情報フィールドに、正
確に１つのIPV6CPパケットが、カプセル化されます。
Code field
コードフィールド
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request,
Terminate-Ack and Code-Reject) are used. Other Codes should
be treated as unrecognized and should result in Code-Rejects.
１から７までのコードだけが使われます（構成要求、構成確認、構成
否認、構成拒否、終了要求、終了応答、コード不良）。他のコードが
認識できないと扱われるべきで、コード不良をもたらすべきです。
Timeouts
タイムアウト
IPV6CP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation should be
prepared to wait for Authentication and Link Quality
Determination to finish before timing out waiting for a
Configure-Ack or other response. It is suggested that an
implementation give up only after user intervention or a
configurable amount of time.
IPV6CPパケットが、ＰＰＰがネットワーク層プロトコルフェーズに達
するまで、交換されないかもしれません。実装は、認証とリンク品質
決定が、構成確認や他の反応を待つタイムアウトより前に終わるよう
にすべきです。これは実装がユーザが干渉したか、設定可能な時間の
後にだけあきらめることを提案しています。
Configuration Option Types
設定オプションのタイプ
IPV6CP has a distinct set of Configuration Options.
IPV6CPは、異なる設定オプションを持ちます。
4. IPV6CP Configuration Options
4. IPV6CP設定オプション
IPV6CP Configuration Options allow negotiation of desirable IPv6
parameters. IPV6CP uses the same Configuration Option format defined
for LCP [1], with a separate set of Options. If a Configuration
Option is not included in a Configure-Request packet, the default
value for that Configuration Option is assumed.
IPV6CP 設定オプションが望ましいＩＰｖ６パラメータの交渉を許します。
IPV6CPがＬＣＰ[1]のために定義されたのと同じ設定オプションフォーマット
を使います。もし設定オプションが構成要求パケットに含められないなら、
その設定オプションのためのデフォルト値が想定されます。
Up-to-date values of the IPV6CP Option Type field are specified in
the most recent "Assigned Numbers" RFC [4]. Current values are
assigned as follows:
IPV6CPオプションタイプフィールドの最新の値は、最新の「番号割当て」
RFC[4]で指定されます。現在の値が次のように割り当てられます：
1 Interface-Identifier
インタフェース識別子
2 IPv6-Compression-Protocol
ＩＰｖ６圧縮プロトコル
The only IPV6CP options defined in this document are Interface-
Identifier and IPv6-Compression-Protocol. Any other IPV6CP
configuration options that can be defined over time are to be defined
in separate documents.
この文書で定義されたIPV6CPオプションはインタフェース識別子とＩＰｖ６
圧縮プロトコルです。将来定義される他のIPV6CP設定オプションは別の文書
で定義されるはずです。
4.1. Interface-Identifier
4.1. インタフェース識別子
Description
詳細
This Configuration Option provides a way to negotiate a unique 64-
bit interface identifier to be used for the address
autoconfiguration [3] at the local end of the link (see section 5).
A Configure-Request MUST contain exactly one instance of the
Interface-Identifier option [1]. The interface identifier MUST be
unique within the PPP link; i.e. upon completion of the
negotiation different Interface-Identifier values are to be
selected for the ends of the PPP link. The interface identifier
MAY also be unique over a broader scope.
この設定オプションはリンクのローカルな終端のアドレス自動設定[3]のた
めに使われるユニークな６４ビットのインタフェース識別子を交渉する方
法を供給します（５章参照）。構成要求がインタフェース識別子オプショ
ン[1]を正確に１つ含んでいなくてはなりません(MUST)。インタフェース識
別子はＰＰＰリンク内でユニークであるに違いありません；すなわち交渉
の結果異なるインタフェース識別子値がＰＰＰリンクの終端に選ばれるは
ずです(MUST)。インタフェース識別子はより広い範囲で同じくユニークで
あるかもしれません(MAY)。
Before this Configuration Option is requested, an implementation
chooses its tentative Interface-Identifier. The non-zero value of
the tentative Interface-Identifier SHOULD be chosen such that the
value is both unique to the link and, if possible, consistently
reproducible across initializations of the IPV6CP finite state
machine (administrative Close and reOpen, reboots, etc). The
rationale for preferring a consistently reproducible unique
interface identifier to a completely random interface identifier is
to provide stability to global scope addresses that can be formed
from the interface identifier.
この設定オプションが求められる前に、実装が仮のインタフェース識別子
を選択します。仮のインタフェース識別子の値は、ゼロ以外で値がリンク
でユニークになるように、もし可能なら、IPV6CP有限状態マシンを再開
（管理的停止、再開始、再起動など）した場合に同じ値が再現可能なよう
に選択すべきです(SHOILD)。同じ値が再現可能でユニークなインタフェー
ス識別子の方が完全にランダムなインタフェース識別子より好ましい原理
はインタフェース識別子から形成されるグローバルな範囲のアドレスの安
定性を供給するためです。
Assuming that interface identifier bits are numbered from 0 to 63
in canonical bit order where the most significant bit is the bit
number 0, the bit number 6 is the "u" bit (universal/local bit
in IEEE EUI-64 [5] terminology) which indicates whether or not the
interface identifier is based on a globally unique IEEE identifier
(EUI-48 or EUI-64 [5]) (see the case 1 below). It is set to
one (1) if a globally unique IEEE identifier is used to derive
the interface identifier, and it is set to zero (0) otherwise.
インタフェース識別子のビットを標準的なビット順序で０から６３の番号
を付けられていると仮定します、最上位ビットがビットナンバー０である
とすると、ビットナンバー６は"u"ビット（IEEE EUI-64 [5]技術のユニバー
サル／ローカルビット）で、これはインタフェース識別子が世界的規模で
ユニークなIEEE識別子(EUI-48かEUI-64 [5])に基づいているかどうかを示
します（以下の場合１を見てください）。"u"ビットは、もし世界的規模で
ユニークなIEEE識別子がインタフェース識別子を得るために使われるなら、
１に設定され、さもなければゼロ（０）に設定されます。
The following are methods for choosing the tentative Interface
Identifier in the preference order:
次は仮のインタフェース識別子を選択する方法の優先順位です：
1) If an IEEE global identifier (EUI-48 or EUI-64) is
available anywhere on the node, it should be used to construct
the tentative Interface-Identifier due to its uniqueness
properties. When extracting an IEEE global identifier from
another device on the node, care should be taken to that the
extracted identifier is presented in canonical ordering [8].
1) もしIEEEグローバルな識別子(EUI-48かEUI-64)がノード上のどこかにあ
るならば、これをユニークな特性のために仮のインタフェース識別子を
組み立てるために使うべきです。ノード内のほかのデバイスからグロー
バルなIEEE識別子を抜き出す際に、ぬき出した識別子が標準的な順序
[8]であるかどうか注意するべきです。
The only transformation from an EUI-64 identifier is to invert
the "u" bit (universal/local bit in IEEE EUI-64 terminology).
For example, for a globally unique EUI-64 identifier of the
form:
EUI-64識別子から唯一の翻訳は"u"ビット（IEEE EUI-64技術のユニバー
サル／ローカルビット）を反転させる事です。例えば、次のグローバル
でユニークなEUI-64識別子について：
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g"
is group/individual bit, and "e" are the bits of the extension
identifier, the IPv6 interface identifier would be of the form:
"c"は会社識別子に割り当てられたビットで、"0"はユニバーサル／ロー
カルビットの、世界的な範囲を示す値で、"g"はグループ／個別ビットで、
"e"が拡張識別子ビットの場合、ＩＰｖ６インタフェース識別子の形式は
以下でしょう：
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
The only change is inverting the value of the universal/local
bit.
唯一の変更はユニバーサル／ローカルビットの値の反転です。
In the case of a EUI-48 identifier, it is first converted to the
EUI-64 format by inserting two bytes, with hexadecimal values of
0xFF and 0xFE, in the middle of the 48 bit MAC (between the
company_id and extension-identifier portions of the EUI-48
value). For example, for a globally unique 48 bit EUI-48
identifier of the form:
EUI-48識別子の場合、４８ビットのMACの真ん中（EUI-48値の会社識別
子と拡張識別子の間）に、１６進数で0xFFと0xFEの２バイトを差し込む
ことで最初にEUI-64フォーマットに変換します。例えば、次の世界的規
模でユニークな４８ビットEUI-48識別子について：
most-significant least-significant
bit bit
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g"
is group/individual bit, and "e" are the bits of the extension
identifier, the IPv6 interface identifier would be of the form:
"c"は会社識別子に割り当てられたビットで、"0"はユニバーサル／ロー
カルビットの、世界的な範囲を示す値で、"g"はグループ／個別ビットで、
"e"が拡張識別子ビットの場合、ＩＰｖ６インタフェース識別子の形式は
以下でしょう：
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
2) If an IEEE global identifier is not available a different source
of uniqueness should be used. Suggested sources of uniqueness
include link-layer addresses, machine serial numbers, et cetera.
2) もしIEEEグローバル識別子が使えなければ、他のユニークな情報が使わ
れるべきです。提案できるユニークな情報はリンク層アドレス、機械の
シリアル番号などを含みます。
In this case the "u" bit of the interface identifier MUST be set
to zero (0).
この場合インタフェース識別子の"u"ビットはゼロ（０）に設定されな
くてはなりません(MUST)。
3) If a good source of uniqueness cannot be found, it is
recommended that a random number be generated. In this case the
"u" bit of the interface identifier MUST be set to zero (0).
3) もしユニークな情報が見つけだせないなら、乱数で生成することが勧め
られます。この場合インタフェース識別子の"u"ビットはゼロ（０）に
設定されなくてはなりません(MUST)。
Good sources [1] of uniqueness or randomness are required for the
Interface-Identifier negotiation to succeed. If neither a unique
number or a random number can be generated it is recommended that a
zero value be used for the Interface-Identifier transmitted in the
Configure-Request. In this case the PPP peer may provide a valid
non-zero Interface-Identifier in its response as described below.
Note that if at least one of the PPP peers is able to generate
separate non-zero numbers for itself and its peer, the identifier
negotiation will succeed.
ユニークあるいは乱雑な良い情報[1]はインターフェース識別子の交渉の成
功に必要です。もしユニークな数もランダムな数も得られないなら、構成
要求で送るインターフェース識別子に０の値を使うことが勧められます。
この場合ＰＰＰピアは、下に記述されるように、その回答でゼロ以外の正
当なインタフェース識別子を供給するかもしれません。もし少なくともＰ
ＰＰピアのどちらかが自分自身とピアのゼロ以外の数を生成可能なら、識
別子交渉が成功するであろうことに注意を払ってください。
When a Configure-Request is received with the Interface-Identifier
Configuration Option and the receiving peer implements this option,
the received Interface-Identifier is compared with the Interface-
Identifier of the last Configure-Request sent to the peer.
Depending on the result of the comparison an implementation MUST
respond in one of the following ways:
インタフェース識別子設定オプションを持つ構成要求を受信し、受信した
ピアがこのオプションを実装している場合、受信したインタフェース識別
子と、ピアが最後に送った設定要求のインタフェース識別子と比較します。
比較の結果によって、実装が次の方法の１つで返答しなくてはなりません
(MUST)：
If the two Interface-Identifiers are different but the received
Interface-Identifier is zero, a Configure-Nak is sent with a non-
zero Interface-Identifier value suggested for use by the remote
peer. Such a suggested Interface-Identifier MUST be different from
the Interface-Identifier of the last Configure-Request sent to the
peer. It is recommended that the value suggested be consistently
reproducible across initializations of the IPV6CP finite state
machine (administrative Close and reOpen, reboots, etc). The "u"
universal/local) bit of the suggested identifier MUST be set to
zero (0) regardless of its source unless the globally unique EUI-
48/EUI-64 derived identifier is provided for the exclusive use by
the remote peer.
もし２つのインタフェース識別子が異なっているが、受信したインタフェー
ス識別子がゼロであるなら、遠隔ピアに使用を勧める非ゼロのインタフェー
ス識別子を設定した構成否認を送ります。提案されたインタフェース識別
子はピアに送られた最後の構成要求のインタフェース識別子と異なってい
るに違いありません(MUST)。提案された値がIPV6CP有限状態マシンの再開
後も同じ値が再現可能であることが勧められます（管理的停止、再開始、
リブート）。提案された識別子の"u"（ユニバーサル／ローカル）ビットが、
世界的規模でユニークなEUI- 48/EUI-64によって得られた識別子が遠隔の
ピアによって排他的に使用されないなら、その情報源にかかわらずゼロ
（０）にセットされなくてはなりません(MUST)。
If the two Interface-Identifiers are different and the received
Interface-Identifier is not zero, the Interface-Identifier MUST be
acknowledged, i.e. a Configure-Ack is sent with the requested
Interface-Identifier, meaning that the responding peer agrees with
the Interface-Identifier requested.
もし２つのインタフェース識別子が異なり、受信したインタフェース識別
子がゼロでないなら、インタフェース識別子を認めなければなりません
(MUST)、すなわち要求したインターフェース識別子を設定した構成確認を
送り、これはインタフェース識別子について合意した事をピアに返答する
ことを意味します。
If the two Interface-Identifiers are equal and are not zero, a
Configure-Nak MUST be sent specifying a different non-zero
Interface-Identifier value suggested for use by the remote peer.
It is recommended that the value suggested be consistently
reproducible across initializations of the IPV6CP finite state
machine (administrative Close and reOpen, reboots, etc). The "u"
universal/local) bit of the suggested identifier MUST be set to
zero (0) regardless of its source unless the globally unique EUI-
48/EUI-64 derived identifier is provided for the exclusive use by
the remote peer.
もし２つのインタフェース識別子が同じで、ゼロないなら、他の、使用を
薦める、ゼロでないインターフェース識別子を指定した構成否認を送りま
す(MUST)。提案された値がIPV6CP有限状態マシンの再開後も同じ値が再現
可能であることが勧められます（管理的停止、再開始、リブート）。提案
された識別子の"u"（ユニバーサル／ローカル）ビットが、世界的規模でユ
ニークなEUI- 48/EUI-64によって得られた識別子が遠隔のピアによって排
他的に使用されないなら、その情報源にかかわらずゼロ（０）にセットさ
れなくてはなりません(MUST)。
If the two Interface-Identifiers are equal to zero, the Interface-
Identifiers negotiation MUST be terminated by transmitting the
Configure-Reject with the Interface-Identifier value set to zero.
In this case a unique Interface-Identifier can not be negotiated.
もし２つのインタフェース識別子がゼロなら、インタフェース識別子交渉
はゼロを設定したインタフェース識別子値の構成拒否を送ることで終了し
ます(MUST)。この場合ユニークなインタフェース識別子が交渉ができませ
ん。
If a Configure-Request is received with the Interface-Identifier
Configuration Option and the receiving peer does not implement this
option, Configure-Rej is sent.
もしインタフェース識別子設定オプションを持つ構成要求を受信したピア
がこのオプションを実装しないなら、構成拒否が送られます。
A new Configure-Request SHOULD NOT be sent to the peer until normal
processing would cause it to be sent (that is, until a Configure-
Nak is received or the Restart timer runs out).
通常の処理により送る事になる（構成否認受信や再送タイマーがタイム
アウトする）まで新しい構成要求を送るべきではありません(SHOULD NOT)。
A new Configure-Request MUST NOT contain the Interface-Identifier
option if a valid Interface-Identifier Configure-Reject is
received.
もし正しいインタフェース識別子の構成拒否を受信したら、インタフェース
識別子オプションを含む新しい構成要求を送ってはなりません(MUST NOT)。
Reception of a Configure-Nak with a suggested Interface-Identifier
different from that of the last Configure-Nak sent to the peer
indicates a unique Interface-Identifier. In this case a new
Configure-Request MUST be sent with the identifier value suggested
in the last Configure-Nak from the peer. But if the received
Interface-Identifier is equal to the one sent in the last
Configure-Nak, a new Interface-Identifier MUST be chosen. In this
case, a new Configure-Request SHOULD be sent with the new tentative
Interface-Identifier. This sequence (transmit Configure-Request,
receive Configure-Request, transmit Configure-Nak, receive
Configure-Nak) might occur a few times, but it is extremely
unlikely to occur repeatedly. More likely, the Interface-
Identifiers chosen at either end will quickly diverge, terminating
the sequence.
ピアに送った最後の構成否認のインターフェース識別子と異なったインター
フェース識別子を提案した構成否認の受信がユニークなインターフェース
識別子を示します。この場合、ピアからの最後の構成否認で提案された識
別子の値で、新しい構成要求が送られなくてはなりません(MUST)。けれど
ももし受け取ったインターフェース識別子が最後の構成否認で送ったもの
と等しいなら、新しいインターフェース識別子を選択しなくてはなりませ
ん(MUST)。この場合、新しい構成要求が新しい仮インターフェース識別子
と一緒に送られるべきです(SHOULD)。シーケンス（構成要求を送る、構成
要求を受取る、構成否認を送り、構成否認を受け取る）は数回繰り返され
るかもしれませんが、繰り返される可能性は非常にまれです。多分、イン
ターフェース識別子がそれぞれで選ばれて、異なった値で、シーケンスが
終わるでしょう。
If negotiation of the Interface-Identifier is required, and the
peer did not provide the option in its Configure-Request, the
option SHOULD be appended to a Configure-Nak. The tentative value
of the Interface-Identifier given must be acceptable as the remote
Interface-Identifier; i.e. it should be different from the
identifier value selected for the local end of the PPP link. The
next Configure-Request from the peer may include this option. If
the next Configure-Request does not include this option the peer
MUST NOT send another Configure-Nak with this option included. It
should assume that the peer's implementation does not support this
option.
もしインターフェース識別子の交渉が必要で、ピアがその構成要求でオプ
ションを供給しなかったら、オプションは構成否認に添えられるべきです
(SHOULD)。与えられたインターフェース識別子の仮値は遠隔インターフェー
ス識別子として受容できなくてはなりません；すなわちその値がＰＰＰリ
ンクのローカルエンドのために選んだ識別子と異なるべきです。ピアから
の次の構成要求はこのオプションを含むかもしれません。もし次の構成要
求がこのオプションを含まないなら、ピアはオプションを含む構成否認を
送ってはなりません(MUST NOT)。これはピアの実装がこのオプションをサ
ポートしないと想定するべきです。
By default, an implementation SHOULD attempt to negotiate the
Interface-Identifier for its end of the PPP connection.
デフォルトで、実装はＰＰＰ接続の終わりのインターフェース識別子の交
渉しようと試みるべきです(SHOULD)。
A summary of the Interface-Identifier Configuration Option format is
shown below. The fields are transmitted from left to right.
インターフェース識別子設定オプションフォーマットの要約を下に示します。
フィールドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Interface-Identifier (MS Bytes)
| タイプ | 長さ | インターフェース識別子(上位)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Identifier (cont)
インターフェース識別子(続き)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Identifier (LS Bytes) |
インターフェース識別子(下位) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
10
10
Interface-Identifier
インターフェース識別子
The 64-bit Interface-Identifier which is very likely to be unique on
the link or zero if a good source of uniqueness can not be found.
リンク上でユニークで可能性が非常に高い６４ビットインターフェース
識別子か、もしユニークさの良い情報が見つからないならゼロ。
Default
デフォルト
If no valid interface identifier can be successfully negotiated, no
default Interface-Identifier value should be assumed. The procedures
for recovering from such a case are unspecified. One approach is to
manually configure the interface identifier of the interface.
もし正しいインタフェース識別子の交渉が成功しないなら、デフォルト
インターフェース識別子値が想定されるべきではありません。このよう
なケースから回復する手順は指定されません。１つの方法は手作業でイ
ンタフェースのインタフェース識別子を設定することです。
4.2. IPv6-Compression-Protocol
4.2. ＩＰｖ６圧縮プロトコル
Description
詳細
This Configuration Option provides a way to negotiate the use of a
specific IPv6 packet compression protocol. The
IPv6-Compression-Protocol Configuration Option is used to indicate the
ability to receive compressed packets. Each end of the link must
separately request this option if bi-directional compression is
desired. By default, compression is not enabled.
この設定オプションは特定のＩＰｖ６パケット圧縮プロトコルの使用を交
渉する方法を供給します。ＩＰｖ６圧縮プロトコル設定オプションは圧縮
されたパケットを受け取る能力を示すために使われます。各リンクの終端
は、もし双方向性の圧縮が希望されるなら、別々にこのオプションを使わ
なければなりません。デフォルトで、圧縮は使用可能でありません。
IPv6 compression negotiated with this option is specific to IPv6
datagrams and is not to be confused with compression resulting from
negotiations via Compression Control Protocol (CCP), which potentially
effect all datagrams.
このオプションで交渉されたＩＰｖ６圧縮はＩＰｖ６データグラムに特有
で、潜在的に全てのデータグラムに影響を与える圧縮コントロールプロト
コル（CCP）の交渉の結果の圧縮と混乱しないはずです。
A summary of the IPv6-Compression-Protocol Configuration Option format
is shown below. The fields are transmitted from left to right.
ＩＰｖ６圧縮プロトコル設定オプションフォーマットの概要を下に記述しま
す。フィールドは左から右に送られます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6-Compression-Protocol |
| タイプ | 長さ | ＩＰｖ６圧縮プロトコル |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
| データ ...
+-+-+-+-+
Type
タイプ
2
2
Length
長さ
>= 4
>= 4
IPv6-Compression-Protocol
ＩＰｖ６圧縮プロトコル
The IPv6-Compression-Protocol field is two octets and indicates
the compression protocol desired. Values for this field are
always the same as the PPP Data Link Layer Protocol field values
for that same compression protocol.
ＩＰｖ６圧縮プロトコルフィールドは２オクテットで、希望する圧縮プ
ロトコルを示します。このフィールドの値は、同じ圧縮プロトコルのＰ
ＰＰデータリンク層プロトコルフィールド値と常に同じです。
No IPv6-Compression-Protocol field values are currently assigned.
Specific assignments will be made in documents that define
specific compression algorithms.
ＩＰｖ６圧縮プロトコルフィールド値が現在割り当てられてません。特
定の圧縮アルゴリズムを定義する文書で特定の割当がされるでしょう。
Data
データ
The Data field is zero or more octets and contains additional
data as determined by the particular compression protocol.
データフィールドはゼロ以上のオクテットで、特定の圧縮プロトコルに
依存する追加のデータを含んでいます。
Default
デフォルト
No IPv6 compression protocol enabled.
ＩＰｖ６圧縮プロトコルが使用されません。
5. Stateless Autoconfiguration and Link-Local Addresses
5. ステートレス自動設定とリンクローカルアドレス
The Interface Identifier of IPv6 unicast addresses [6] of a PPP
interface, SHOULD be negotiated in the IPV6CP phase of the PPP
connection setup (see section 4.1). If no valid Interface Identifier
has been successfully negotiated, procedures for recovering from such
a case are unspecified. One approach is to manually configure the
Interface Identifier of the interface.
ＰＰＰインターフェースのＩＰｖ６ユニキャストアドレス[6]のインタフェー
ス識別子は、ＰＰＰ接続セットアップのIPV6CPフェーズで交渉されるべきで
す(SHOULD)（４.１章参照）。もし正しいインタフェース識別子交渉が成功し
なかった場合、回復する手順は指定されません。１つの方法が手作業でイン
タフェースのインタフェース識別子を設定することです。
As long as the Interface Identifier is negotiated in the IPV6CP phase
of the PPP connection setup, it is redundant to perform duplicate
address detection as a part of the IPv6 Stateless Autoconfiguration
protocol [3]. Therefore it is recommended that for PPP links with
the IPV6CP Interface-Identifier option enabled the default value of
the DupAddrDetectTransmits autoconfiguration variable [3] be zero.
インタフェース識別子がＰＰＰ接続セットアップのIPV6CPフェーズで交渉さ
れる限り、ＩＰｖ６ステートレス自動設定プロトコル[3]の一部として重複ア
ドレス検出を行うことは重複します。それ故IPV6CPインターフェース識別子
オプションを使用可能にしたＰＰＰリンクでDupAddrDetectTransmits自動設
定変数[3]のデフォルト値がゼロであることが勧められます。
Link-local addresses of PPP interfaces have the following format:
ＰＰＰインタフェースのリンクローカルアドレスが次のフォーマットを持ち
ます：
| 10 bits | 54 bits | 64 bits |
+----------+------------------------+-----------------------------+
|1111111010| 0 | Interface Identifier |
| | | インターフェース識別子 |
+----------+------------------------+-----------------------------+
The most significant 10 bits of the address is the Link-Local prefix
FE80::. 54 zero bits pad out the address between the Link-Local
prefix and the Interface Identifier fields.
上位１０ビットアドレスの仮数部はリンクローカルプレフィックスFE80::で
す。リンクローカルプレフィックスとインタフェース識別子フィールドの間
は５４ビットのゼロが穴埋めします。
6. Security Considerations
6. セキュリティに関する考察
The IPv6 Control Protocol extension to PPP can be used with all
defined PPP authentication and encryption mechanisms.
ＰＰＰのＩＰｖ６コントロールプロトコル拡張はすべての定義されたＰＰＰ
認証と暗号化メカニズムで使うことができます。
7. Acknowledgments
7. 謝辞
This document borrows from the Magic-Number LCP option and as such is
partially based on previous work done by the PPP working group.
この書類はマジック番号ＬＣＰオプションから部分的にＰＰＰワークグルー
プによってされた前の仕事に基づくものを借用します。
8. Changes from RFC-2023
8. RFC2023からの変更点
The following changes were made from RFC-2023 "IP Version 6 over
PPP":
RFC-2023「ＩＰバージョン６上のＰＰＰ」から次の変更がされました：
- Changed to use "Interface Identifier" instead of the "Interface
Token" term according to the terminology adopted in [6].
- [6]の専門用語にあわせて、用語「インターフェーストークン」の代わりに
用語「インタフェース識別子」っを使います。
- Increased the size of Interface Identifier to 64 bits according to
the newly adopted IPv6 addressing architecture [6].
- 新しいＩＰｖ６アドレス構造[6]にあわせてインターフェース識別子の大き
さを６４ビットに増やしました。
- Added methods for selection of an interface identifier that is
consistently reproducible across initializations of the IPV6CP
finite state machine.
- IPV6CP有限状態マシンの初期化後も同じ値が再現可能なインタフェース識
別子の選択の方法を追加します。
- Added the interface identifier selection methods for generating
globally unique interface identifier from an unique an IEEE global
identifier when it is available anywhere on the node.
- ノードで得ることが出来れば、ユニークなＩＥＥＥグローバル識別子から、
グローバルにユニークなインターフェース識別子を生成するインタフェー
ス識別子選択方法を追加しました。
- Changed to send a Configure-Nak instead a Configure-Ack in response
to receiving a Configure-Request with a zero Interface-Identifier
value.
- ゼロのインターフェース識別子値の構成要求を受信した場合の応答につい
て、構成確認でなく構成否認を送るように変更しました。
- Replaced the value assignment of the IPv6-Compression-Protocol
field of the IPv6-Compression-Protocol Configuration option with
the text stating that no IPv6-Compression-Protocol field values are
currently assigned and that specific assignments will be made in
documents that define specific compression algorithms.
- ＩＰｖ６圧縮プロトコル設定オプションのＩＰｖ６圧縮プロトコルフィー
ルドの値の割当ての文書を、ＩＰｖ６圧縮プロトコルフィールド値が現在
割り当てらてませんから、特定の圧縮アルゴリズムを定義する文書で特定
の割当がされるでしょう、に置き換えました。
- Added new and updated references.
- 新しいのと更新された参考文献を加えました。
- Minor text clarifications and improvements.
- マイナーなテキストの明確化と改良。
9. References
9. 参考文献
[1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC
1661, July 1994.
[2] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[3] Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also: http://www.iana.org/numbers.html
[5] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html, March
1997.
[6] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14, RFC 2119, March 1997.
[8] Narten T., and C. Burton, "A Caution On The Canonical Ordering
Of Link-Layer Addresses", RFC 2469, December 1998.
10. Authors' Addresses
10. 著者のアドレス
Dimitry Haskin
Bay Networks, Inc.
600 Technology Park
Billerica, MA 01821
EMail: dhaskin@baynetworks.com
Ed Allen
Bay Networks, Inc.
600 Technology Park
Billerica, MA 01821
EMail: eallen@baynetworks.com
11. Full Copyright Statement
11. 著作権表示全文
Copyright (C) The Internet Society (1998). 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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。