[要約] RFC 5072は、PPPを介したIPv6の実装に関する標準化ドキュメントであり、IPv6パケットのPPPフレームへのエンカプセレーション方法を定義しています。このRFCの目的は、IPv6ネットワークへの接続を提供するためにPPPを使用する際の手順と要件を明確にすることです。
Network Working Group S. Varada, Ed.
Request for Comments: 5072 Transwitch
Obsoletes: 2472 D. Haskins
Category: Standards Track E. Allen
September 2007
IP Version 6 over PPP
PPP上のIPバージョン6
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The Point-to-Point Protocol (PPP) 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.
ポイントツーポイントプロトコル（PPP）は、ポイントツーポイントリンクを介したネットワーク層プロトコル情報をカプセル化する標準的な方法を提供します。PPPはまた、拡張可能なリンク制御プロトコルを定義し、さまざまなネットワーク層プロトコルを確立および構成するためのネットワーク制御プロトコルファミリー（NCPS）を提案します。
This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.
このドキュメントでは、PPPリンクを介してIPv6パケットを送信する方法、PPP上のIPv6を確立および構成するためのNCP、およびPPPリンクでIPv6リンクローカルアドレスを形成する方法を定義します。
It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.
また、PPPリンク用に構成されたIPv6グローバルユニキャストアドレスで、ステートフルまたはステートレスアドレスの自動構成を介して構成されたIPv6グローバルユニキャストアドレスで重複するアドレス検出を実行するための条件を指定します。
This document obsoletes RFC 2472.
このドキュメントは、RFC 2472を廃止します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. Sending IPv6 Datagrams ..........................................3
3. A PPP Network Control Protocol for IPv6 .........................3
4. IPV6CP Configuration Options ....................................4
4.1. Interface Identifier .......................................4
5. Stateless Autoconfiguration and Link-Local Addresses ............9
6. Security Considerations ........................................11
7. IANA Considerations ............................................11
8. Acknowledgments ................................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative references ....................................12
Appendix A: Global Scope Addresses................................14
Appendix B: Changes from RFC-2472.................................14
PPP has three main components:
PPPには3つの主要なコンポーネントがあります。
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) さまざまなネットワーク層プロトコルを確立および構成するためのネットワーク制御プロトコル（NCPS）のファミリー。
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.
ポイントツーポイントリンクで通信を確立するには、PPPリンクの各端が最初にLCPパケットを送信して、データリンクを構成およびテストする必要があります。リンクが確立され、LCPが必要に応じてオプションの施設が交渉された後、PPPは1つ以上のネットワーク層プロトコルを選択および構成するためにNCPパケットを送信する必要があります。選択した各ネットワーク層プロトコルが構成されると、各ネットワーク層プロトコルのデータグラムをリンク上に送信できます。
In this document, the NCP for establishing and configuring the IPv6 over PPP is referred to as the IPv6 Control Protocol (IPV6CP).
このドキュメントでは、PPPを介してIPv6を確立および構成するためのNCPは、IPv6コントロールプロトコル（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.).
リンクは、明示的なLCPまたはNCPパケットがリンクを閉じるか、外部イベントが発生するまで通信用に構成されたままになります（反対側の停電、キャリアドロップなど）。
This document obsoletes the earlier specification from RFC 2472 [7]. Changes from RFC 2472 are listed in Appendix B.
この文書は、RFC 2472 [7]からの以前の仕様を廃止します。RFC 2472からの変更は、付録Bにリストされています。
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 [6].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[6]で説明されているように解釈される。
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.
IPv6パケットが通信される前に、PPPはネットワーク層プロトコルフェーズに到達する必要があり、IPv6制御プロトコルは開かれた状態に到達する必要があります。
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).
PPPデータリンクレイヤーフレームの情報フィールドに1つのIPv6パケットがカプセル化されており、プロトコルフィールドがタイプHEX 0057（インターネットプロトコルバージョン6）を示しています。
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 to be at least as large as the minimum link MTU size required for IPv6 [2].
PPPリンクに送信されるIPv6パケットの最大長は、PPPデータリンクレイヤーフレームの情報フィールドの最大長と同じです。IPv6をサポートするPPPリンクは、IPv6に必要な最小リンクMTUサイズと少なくとも同じ大きさの情報フィールドにする必要があります[2]。
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 LCP. IPV6CP packets may not be exchanged until PPP has reached the network-layer protocol phase. IPV6CP packets that are received before this phase is reached should be silently discarded.
IPv6コントロールプロトコル（IPv6CP）は、ポイントツーポイントリンクの両端にIPv6プロトコルモジュールの構成、有効化、および無効化を担当します。IPv6CPは、LCPと同じパケット交換メカニズムを使用します。IPv6CPパケットは、PPPがネットワーク層プロトコルフェーズに達するまで交換されない場合があります。このフェーズに到達する前に受信されるIPv6CPパケットは、静かに破棄する必要があります。
The IPv6 Control Protocol is exactly the same as the LCP [1] with the following exceptions:
IPv6コントロールプロトコルは、次の例外を除いて、LCP [1]とまったく同じです。
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).
正確に1つのIPv6CPパケットが、PPPデータリンクレイヤーフレームの情報フィールドにカプセル化されています。ここでは、プロトコルフィールドがタイプHEX 8057（IPv6制御プロトコル）を示します。
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.
コード1〜7（configure-request、configure-ack、configure-nak、configure-reject、terminate-request、continate-cack、code-reject）のみが使用されます。他のコードは認識されていないものとして扱われるべきであり、コード抵抗をもたらす必要があります。
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パケットは、PPPがネットワーク層プロトコルフェーズに達するまで交換されない場合があります。認証を待つように実装を準備し、Configure-ackまたはその他の応答を待つタイミングを出す前に、品質決定をリンクする必要があります。実装は、ユーザーの介入または構成可能な時間の後にのみあきらめることが示唆されています。
Configuration Option Types
構成オプションタイプ
IPV6CP has a distinct set of Configuration Options.
IPv6CPには、構成オプションの明確なセットがあります。
IPV6CP Configuration Options allow negotiation of desirable IPv6 parameters. IPV6CP uses the same Configuration Option format defined for LCP [1] but 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構成オプションにより、望ましいIPv6パラメーターの交渉が可能になります。IPv6CPは、LCP [1]に対して定義された同じ構成オプション形式を使用しますが、オプションの個別のセットがあります。構成オプションがConfigure-Requestパケットに含まれていない場合、その構成オプションのデフォルト値が想定されます。
Up-to-date values of the IPV6CP Option Type field are specified in the online database of "Assigned Numbers" maintained at IANA [9]. The current value assignment is as follows:
IPv6CPオプションタイプフィールドの最新の値は、IANAで維持されている「割り当てられた数字」のオンラインデータベースで指定されています[9]。現在の値の割り当ては次のとおりです。
1 Interface-Identifier
1インターフェイス識別子
The only IPV6CP option defined in this document is the interface identifier. Any other IPV6CP configuration options that can be defined over time are to be defined in separate documents.
このドキュメントで定義されている唯一のIPv6CPオプションは、インターフェイス識別子です。時間の経過とともに定義できる他のIPv6CP構成オプションは、個別のドキュメントで定義されます。
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.
この構成オプションは、リンクのローカルエンドでのアドレスAutoconfiguration [3]に使用される一意の64ビットインターフェイス識別子をネゴシエートする方法を提供します（セクション5を参照）。configure-requestには、インターフェイス識別子オプションの1つのインスタンスが正確に1つ含まれている必要があります[1]。インターフェイス識別子は、PPPリンク内で一意でなければなりません。つまり、ネゴシエーションが完了すると、PPPリンクの終わりには異なるインターフェイス識別子値が選択されます。インターフェイス識別子は、より広い範囲にわたって一意である場合もあります。
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 unique to the link and, preferably, 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 (see Appendix A) that can be formed from the interface identifier.
この構成オプションが要求される前に、実装は暫定的なインターフェイス識別子を選択します。暫定インターフェイス識別子の非ゼロ値は、値がリンクに固有のものであり、できればIPv6CP有限状態マシンの初期化全体で一貫して再現できるように選択する必要があります（管理閉鎖と再起動、再起動など）。完全にランダムなインターフェイス識別子に一貫して再現可能な一意のインターフェイス識別子を好むための理論的根拠は、インターフェイス識別子から形成できるグローバルスコープアドレス（付録Aを参照）に安定性を提供することです。
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 [4] terminology), which indicates whether or not the interface identifier is based on a globally unique IEEE identifier (EUI-48 or EUI-64 [4])(see 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.
インターフェイス識別子ビットが標準的なビット順序で0から63に番号が付けられていると仮定すると、最も重要なビットはビット番号0です。ビット番号6は「u」ビットです（IEEE EUI-64のユニバーサル/ローカルビット[4]インターフェイス識別子がグローバルに一意のIEEE識別子（EUI-48またはEUI-64 [4]）に基づいているかどうかを示す用語）（以下のケース1を参照）。インターフェイス識別子を導出するためにグローバルに一意のIEEE識別子を使用している場合、1つに設定され、それ以外の場合はゼロ（0）に設定されます。
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 that the extracted identifier is presented in canonical ordering [14].
1) IEEEグローバル識別子（EUI-48またはEUI-64）がノード上のどこでも利用可能である場合、その独自性のために暫定インターフェイス識別子を構築するために使用する必要があります。ノード上の別のデバイスからIEEEグローバル識別子を抽出する場合、抽出された識別子が標準的な順序で提示されるように注意する必要があります[14]。
The only transformation from an EUI-64 identifier is to invert the "u" bit (universal/local bit in IEEE EUI-64 terminology).
EUI-64識別子からの唯一の変換は、「U」ビット（IEEE EUI-64用語でユニバーサル/ローカルビット）を反転することです。
For example, for a globally unique EUI-64 identifier of the form:
たとえば、フォームのグローバルに一意の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 the group/individual bit, and "e" are the bits of the extension identifier, the IPv6 interface identifier would be of the form:
ここで、「C」は割り当てられたcompany_idのビットであり、「0」はグローバルスコープを示すユニバーサル/ローカルビットの値であり、「g」はグループ/個人ビット、「e」は拡張識別子のビットです、IPv6インターフェイス識別子は次の形式です。
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 hexa-decimal 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識別子の場合、48ビットMACの中央（Company_idと拡張子の間にある0xffと0xfeの2つのバイトを挿入することにより、最初にEUI-64形式に変換されます。EUI-48値の識別子部分）。たとえば、フォームのグローバルに一意の48ビット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 the group/individual bit, and "e" are the bits of the extension identifier, the IPv6 interface identifier would be of the form:
ここで、「C」は割り当てられたcompany_idのビットであり、「0」はグローバルスコープを示すユニバーサル/ローカルビットの値であり、「g」はグループ/個人ビット、「e」は拡張識別子のビットです、IPv6インターフェイス識別子は次の形式です。
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」ビットをゼロ（0）に設定する必要があります。
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」ビットをゼロ（0）に設定する必要があります。
Good sources [1] of uniqueness or randomness are required for the interface identifier negotiation to succeed. If neither a unique number nor 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]が必要です。一意の数字も乱数も生成できない場合は、configure-requestで送信された界面識別子にゼロ値を使用することをお勧めします。この場合、PPPピアは、以下に説明するように、その応答に有効な非ゼロインターフェイス識別子を提供する場合があります。PPPピアの少なくとも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:
configure-requestがインターフェイスIdentifier構成オプションで受信され、受信ピアがこのオプションを実装すると、受信されたインターフェイス識別子は、ピアに送信された最後のconfigure-requestのインターフェイス識別子と比較されます。比較の結果に応じて、実装は次の方法のいずれかで応答する必要があります。
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.
2つのインターフェイス識別子が異なるが、受信されたインターフェイス識別子がゼロの場合、Configure-nakは、リモートピアが使用するために提案された非ゼロインターフェイス識別子値で送信されます。このような提案されたインターフェイス識別子は、ピアに送信された最後の構成リケストのインターフェイス識別子とは異なる必要があります。提案された値は、IPv6CP有限状態マシン（管理上の閉鎖と再起動など）の初期化全体で一貫して再現可能であることをお勧めします。提案された識別子の「U」（ユニバーサル/ローカル）ビットは、リモートピアが排他的に使用するためにグローバルに一意のEUI-48/EUI-64派生識別子が提供されない限り、そのソースに関係なくゼロ（0）に設定する必要があります。
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.
2つのインターフェイス識別子が異なり、受信されたインターフェイス識別子がゼロでない場合、インターフェイス識別子を確認する必要があります。つまり、要求されたインターフェイス識別子とともにconfigure-ackが送信されます。
If the two interface identifiers are equal and are not zero, 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.
2つのインターフェイス識別子が等しく、ゼロではない場合、リモートピアが使用するために提案されている異なる非ゼロインターフェイス識別子値を指定するようにconfigure-nakを送信する必要があります。提案された値は、IPv6CP有限状態マシン（管理上の閉鎖と再起動など）の初期化全体で一貫して再現可能であることをお勧めします。提案された識別子の「U」（ユニバーサル/ローカル）ビットは、リモートピアが排他的に使用するためにグローバルに一意のEUI-48/EUI-64派生識別子が提供されない限り、そのソースに関係なくゼロ（0）に設定する必要があります。
If the two interface identifiers are equal to zero, the interface identifier's negotiation MUST be terminated by transmitting the Configure-Reject with the interface-identifier value set to zero. In this case, a unique interface identifier cannot be negotiated.
2つのインターフェイス識別子がゼロに等しい場合、インターフェイス識別子の値をゼロに設定して設定されたrejectを送信することにより、インターフェイス識別子のネゴシエーションを終了する必要があります。この場合、一意のインターフェイス識別子を交渉することはできません。
If a Configure-Request is received with the Interface-Identifier Configuration Option and the receiving peer does not implement this option, Configure-Reject is sent.
configure-requestがインターフェイスIdentifier構成オプションで受信され、受信ピアがこのオプションを実装しない場合、configure-rejectが送信されます。
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 [1]).
新しいConfigure-Requestは、通常の処理が送信されるまでピアに送信しないでください（つまり、configure-nakが受信されるか、再起動タイマーが実行されるまで[1]）。
A new Configure-Request MUST NOT contain the interface-identifier option if a valid Interface-Identifier Configure-Reject is received.
新しいConfigure-Requestには、有効なインターフェイスIdentifier Configure-Rejectが受信された場合、インターフェイスIDENTIFIERオプションを含めてはなりません。
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.
PEERに送信された最後のconfigure-nakとは異なる提案されたインターフェイス識別子を使用したConfigure-nakの受信は、一意のインターフェイス識別子を示します。この場合、ピアの最後のconfigure-nakで提案された識別子値を使用して、新しいconfigure-requestを送信する必要があります。ただし、受信したインターフェイス識別子が最後のconfigure-nakで送信されたインターフェイス識別子と等しい場合、新しいインターフェイス識別子を選択する必要があります。この場合、新しい暫定的なインターフェイス識別子とともに新しいconfigure-requestを送信する必要があります。このシーケンス（configure-requestの送信、受信configure-request、送信configure-nak、受信configure-nak）は数回発生する可能性がありますが、繰り返し発生する可能性は非常に低いです。おそらく、両端で選択されたインターフェイス識別子が迅速に分岐し、シーケンスが終了します。
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.
インターフェイス識別子のネゴシエーションが必要であり、ピアがConfigure-Requestでオプションを提供しなかった場合、オプションはconfigure-nakに追加される必要があります。与えられたインターフェイス識別子の暫定値は、リモートインターフェイス識別子として受け入れられる必要があります。つまり、PPPリンクのローカルエンドで選択された識別子値とは異なるはずです。ピアからの次のConfigure-Requestには、このオプションが含まれる場合があります。次のconfigure-requestにこのオプションが含まれていない場合、ピアはこのオプションを含む別のconfigure-nakを送信してはなりません。ピアの実装がこのオプションをサポートしていないと仮定する必要があります。
By default, an implementation SHOULD attempt to negotiate the interface identifier for its end of the PPP connection.
デフォルトでは、実装は、PPP接続の終了のためにインターフェイス識別子をネゴシエートしようとする必要があります。
A summary of the Interface-Identifier Configuration Option format is shown below. The fields are transmitted from left to right.
インターフェイスIDENTIFIER構成オプション形式の概要を以下に示します。フィールドは左から右に送信されます。
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 cannot be found.
64ビットインターフェイス識別子は、リンクで一意になる可能性が非常に高い、またはユニークさの良いソースが見つからない場合はゼロです。
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.
有効なインターフェイス識別子を正常にネゴシエートできない場合、デフォルトのインターフェイス識別子値を想定する必要はありません。そのようなケースから回復する手順は特定されていません。1つのアプローチは、インターフェイスのインターフェイス識別子を手動で構成することです。
The interface identifier of IPv6 unicast addresses [5] 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.
PPPインターフェイスのIPv6ユニキャストアドレス[5]のインターフェイス識別子は、PPP接続セットアップのIPv6CPフェーズでネゴシエートする必要があります（セクション4.1を参照）。有効なインターフェイス識別子が正常に交渉されていない場合、そのような場合から回復する手順は不特定です。1つのアプローチは、インターフェイスのインターフェイス識別子を手動で構成することです。
The negotiated interface identifier is used by the local end of the PPP link to autoconfigure an IPv6 link-local unicast address for the PPP interface. However, it SHOULD NOT be assumed that the same interface identifier is used in configuring global unicast addresses for the PPP interface using IPv6 stateless address autoconfiguration [3]. The PPP peer MAY generate one or more interface identifiers, for instance, using a method described in [8], to autoconfigure one or more global unicast addresses.
ネゴシエートされたインターフェイス識別子は、PPPリンクのローカルエンドで使用され、PPPインターフェイスのIPv6リンクローカルユニキャストアドレスをAutoconfigureが使用します。ただし、IPv6ステートレスアドレスAutoconfiguration [3]を使用して、PPPインターフェイスのグローバルユニキャストアドレスの構成には同じインターフェイス識別子が使用されるとは想定してはなりません。PPPピアは、たとえば[8]で説明されている方法を使用して、1つ以上のグローバルユニキャストアドレスを自動構成するために、1つ以上のインターフェイス識別子を生成する場合があります。
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 (DAD) as a part of the IPv6 Stateless Address Autoconfiguration protocol [3] on the IPv6 link-local address generated by the PPP peer. It may also be redundant to perform DAD on any global unicast addresses configured (using an interface identifier that is either negotiated during IPV6CP or generated, for instance, as per [8]) for the interface as part of the IPv6 Stateless Address Autoconfiguration protocol [3] provided that the following two conditions are met:
インターフェイス識別子がPPP接続セットアップのIPv6CPフェーズでネゴシエートされている限り、IPv6 StatelessアドレスAutoconfiguration Protocol [3]の一部として、複製アドレス検出（DAD）を実行することは冗長です。PPPピアによって。また、IPv6 Stateless Autoconfiguration Protocolの一部としてインターフェイスのインターフェイスの一部として、構成されたグローバルユニキャストアドレスでDADを実行することが冗長になる場合があります（たとえば、[8]に従って[8]の間にIPv6CP中に交渉するか、生成される）3]次の2つの条件が満たされていることを条件とします。
1) The prefixes advertised through the Router Advertisement messages by the access router terminating the PPP link are exclusive to the PPP link.
1) PPPリンクを終了するアクセスルーターによってルーター広告メッセージを介して宣伝されている接頭辞は、PPPリンク専用です。
2) The access router terminating the PPP link does not autoconfigure any IPv6 global unicast addresses from the prefixes that it advertises.
2) PPPリンクを終了するアクセスルーターは、宣伝するプレフィックスからのIPv6グローバルユニキャストアドレスを自動構成しません。
Therefore, it is RECOMMENDED that for PPP links with the IPV6CP interface-identifier option enabled and satisfying the aforementioned two conditions, the default value of the DupAddrDetectTransmits autoconfiguration variable [3] is set to zero by the system management. 3GPP2 networks are an example of a technology that uses PPP to enable a host to obtain an IPv6 global unicast address and satisfies the aforementioned two conditions [10]. 3GPP networks are another example ([11] [13]).
したがって、前述の2つの条件を有効にし、満たすIPv6CPインターフェイス-IdentifierオプションとのPPPリンクの場合、dupaddrdEtecttransmits autoconfiguration変数[3]のデフォルト値は、システム管理によってゼロに設定されることをお勧めします。3GPP2ネットワークは、PPPを使用してホストがIPv6グローバルユニキャストアドレスを取得し、前述の2つの条件を満たすことができるテクノロジーの例です[10]。3GPPネットワークは別の例です（[11] [13]）。
Link-local addresses
Link-Localアドレス
Link-local addresses of PPP interfaces have the following format:
PPPインターフェイスのLink-Localアドレスには、次の形式があります。
| 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.
Lack of link security, such as authentication, trigger the security concerns raised in [3] when the stateless address autoconfiguration method is employed for the generation of global unicast IPv6 addresses out of interface identifiers that are either negotiated through the IPV6CP or generated, for instance, using a method described in [8]. Thus, the mechanisms that are appropriate for ensuring PPP link security are addressed below, together with the reference to a generic threat model.
認証などのリンクセキュリティの欠如は、[3]で提起されたセキュリティの懸念をトリガーします。、[8]で説明されている方法を使用します。したがって、PPPリンクのセキュリティを保証するのに適したメカニズムと、一般的な脅威モデルへの参照とともに、以下に説明します。
The mechanisms that are appropriate for ensuring PPP link Security are: 1) Access Control Lists that apply filters on traffic received over the link for enforcing admission policy, 2) an Authentication protocol that facilitates negotiations between peers [15] to select an authentication method (e.g., MD5 [16]) for validation of the peer, and 3) an Encryption protocol that facilitates negotiations between peers to select encryption algorithms (or crypto-suites) to ensure data confidentiality [17].
PPPリンクのセキュリティを確保するのに適したメカニズムは次のとおりです。1）入場ポリシーを施行するためにリンク上で受信したトラフィックにフィルターを適用するアクセス制御リスト、2）ピア間の交渉を促進する認証プロトコル[15]たとえば、MD5 [16]）ピアの検証のための、3）データの機密性を確保するために暗号化アルゴリズム（または暗号スイーツ）を選択するためにピア間の交渉を促進する暗号化プロトコル[17]。
There are certain threats associated with peer interactions on a PPP link even with one or more of the above security measures in place. For instance, using the MD5 authentication method [16] exposes one to replay attack, where an attacker could intercept and replay a station's identity and password hash to get access to a network. The user of this specification is advised to refer to [15], which presents a generic threat model, for an understanding of the threats posed to the security of a link. The reference [15] also gives a framework to specify requirements for the selection of an authentication method for a given application.
上記のセキュリティ対策の1つまたは複数が実施されている場合でも、PPPリンク上のピアインタラクションに関連する特定の脅威があります。たとえば、MD5認証法[16]を使用すると、攻撃を再生するために1つを公開します。攻撃者は、ネットワークにアクセスするためにステーションのIDとパスワードのハッシュを傍受して再生できます。この仕様のユーザーは、リンクのセキュリティにもたらされる脅威を理解するために、一般的な脅威モデルを提示する[15]を参照することをお勧めします。リファレンス[15]は、特定のアプリケーションの認証方法を選択するための要件を指定するフレームワークも提供します。
The IANA has assigned value 1 for the Type field of the IPv6 datagram interface-identifier option specified in this document. The current assignment is up-to-date at [9].
IANAは、このドキュメントで指定されたIPv6データグラムインターフェイスIDENTIFIERオプションのタイプフィールドに値1を割り当てました。現在の割り当ては[9]で最新のものです。
This document borrows from the Magic-Number LCP option and as such is partially based on previous work done by the PPP working group.
このドキュメントは、Magic-Number LCPオプションから借用しているため、PPPワーキンググループが行った以前の作業に部分的に基づいています。
The editor is grateful for the input provided by members of the IPv6 community in the spirit of updating RFC 2472. Thanks, in particular, go to Pete Barany and Karim El Malki for their technical contributions. Also, thanks to Alex Conta for a thorough review, Stephen Kent for helping with security aspects, and Spencer Dawkins and Pekka Savola for the nits. Finally, the author is grateful to Jari Arkko for his initiation to bring closure to this specification.
編集者は、RFC 2472を更新する精神でIPv6コミュニティのメンバーから提供された入力に感謝しています。特に、技術的な貢献についてPete BaranyとKarim El Malkiに感謝します。また、徹底的なレビューをしてくれたAlex Conta、セキュリティの側面を支援してくれたStephen Kent、およびNITSのSpencer DawkinsとPekka Savolaに感謝します。最後に、著者はJari Arkkoに、この仕様を閉鎖するために彼の開始について感謝しています。
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[3] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[3] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6ステートレスアドレスAutoconfiguration」、RFC 4862、2007年9月。
[4] IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
[4] IEEE、「64ビットグローバル識別子（EUI-64）のガイドライン」、http：//standards.ieee.org/regauth/oui/tutorials/eui64.html
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[5] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[7] Haskin、D.およびE. Allen、「PPP上のIPバージョン6」、RFC 2472、1998年12月。
[8] Narten T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[8] Narten T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[9] IANA, "Assigned Numbers," http://www.iana.org/numbers.html
[9] IANA、「割り当てられた番号」、http://www.iana.org/numbers.html
[10] 3GPP2 X.S0011-002-C v1.0, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services," September 2003.
[10] 3GPP2 X.S0011-002-C V1.0、「CDMA2000ワイヤレスIPネットワーク標準：シンプルIPおよびモバイルIPアクセスサービス」、2003年9月。
[11] 3GPP TS 29.061 V6.4.0, "Interworking between the Public Land Mobile Network (PLMN) Supporting packet based services and Packet Data Networks (PDN) (Release 6)," April 2005.
[11] 3GPP TS 29.061 V6.4.0、「パケットベースのサービスとパケットデータネットワーク（PDN）（リリース6）をサポートするパブリックランドモバイルネットワーク（PLMN）間のインターワーキング」、2005年4月。
[12] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[12] Droms、R.、Ed。、Bound。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[13] 3GPP TS 23.060 v6.8.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 6)," March 2005.
[13] 3GPP TS 23.060 V6.8.0、 "General Packet Radio Service（GPRS）;サービス説明;ステージ2（リリース6）、2005年3月。
[14] Narten, T. and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998.
[14] Narten、T。およびC. Burton、「リンク層アドレスの標準的な順序付けに関する注意」、RFC 2469、1998年12月。
[15] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[15] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、2004年6月。
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[16] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[17] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[17] Meyer、G。、「PPP暗号化制御プロトコル（ECP）」、RFC 1968、1996年6月。
Appendix A: Global Scope Addresses
付録A：グローバルスコープアドレス
A node on the PPP link creates global unicast addresses either through stateless or stateful address autoconfiguration mechanisms. In the stateless address autoconfiguration [3], the node relies on sub-net prefixes advertised by the router via the Router Advertisement messages to obtain global unicast addresses from an interface identifier. In the stateful address autoconfiguration, the host relies on a Stateful Server, like DHCPv6 [12], to obtain global unicast addresses.
PPPリンクのノードは、StatelessまたはStatefulアドレスの自動構成メカニズムを介してグローバルユニキャストアドレスを作成します。Stateless Address Autoconfiguration [3]では、ノードは、ルーター広告メッセージを介してルーターによって宣伝されているサブネットプレフィックスに依存して、インターフェイス識別子からグローバルユニキャストアドレスを取得します。Stateful Address Autoconfigurationでは、ホストはDHCPV6 [12]のようなステートフルサーバーに依存して、グローバルユニキャストアドレスを取得します。
Appendix B: Changes from RFC 2472
付録B：RFC 2472からの変更
The following changes were made from RFC 2472 "IPv6 over PPP":
以下の変更は、RFC 2472「PPP上のIPv6」から行われました。
- Minor updates to Sections 3 and 4
- セクション3および4のマイナーアップデート
- Updated the text in Section 4.1 to include the reference to Appendix A and minor text clarifications.
- セクション4.1のテキストを更新して、付録Aへの参照とマイナーテキストの説明を含めました。
- Removed Section 4.2 on IPv6-Compression-Protocol based on IESG recommendation, and created a new standards-track document to cover negotiation of the IPv6 datagram compression protocol using IPV6CP.
- IESG推奨に基づいてIPv6-Compression-Protocolのセクション4.2を削除し、IPv6CPを使用したIPv6データグラム圧縮プロトコルのネゴシエーションをカバーする新しい標準トラックドキュメントを作成しました。
- Updated the text in Section 5 to: (a) allow the use of one or more interface identifiers generated by a peer, in addition to the use of interface identifier negotiated between peers of the link, in the creation of global unicast addresses for the local PPP interface, and (b) identify cases against the DAD of created non-link-local addresses.
- セクション5のテキストを次のように更新しました（a）ピアによって生成された1つ以上のインターフェイス識別子の使用を許可します。PPPインターフェイス、および（b）作成された非リンクローカルアドレスのDADに対するケースを特定します。
- Added new and updated references.
- 新しいリファレンスと更新された参照を追加しました。
- Added Appendix A
- 付録Aが追加されました
Authors' Addresses
著者のアドレス
Dimitry Haskin Ed Allen
Dimitry Haskin Ed Allen
Srihari Varada (Editor) TranSwitch Corporation 3 Enterprise Dr. Shelton, CT 06484. US.
Srihari Varada（編集者）Transwitch Corporation 3 Enterprise Dr. Shelton、CT 06484. US。
Phone: +1 203 929 8810
EMail: varada@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。