RFC 2472 - IP Version 6 over PPP 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2472
タイトル : RFC 2472 - PPP上のIPバージョン6
翻訳編集 : 自動生成

[要約] RFC 2472は、PPPを介したIPv6の実装に関する標準仕様です。このRFCの目的は、PPPを使用してIPv6を効果的に伝送するための手順と要件を定義することです。

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

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) [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.

ポイントツーポイントプロトコル（PPP）[1]は、ポイントツーポイントリンクを介してネットワーク層プロトコル情報をカプセル化する標準的な方法を提供します。 PPPは拡張可能なリンク制御プロトコルも定義し、さまざまなネットワーク層プロトコルを確立および構成するためのネットワーク制御プロトコル（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.

このドキュメントでは、PPPリンクを介したIPバージョン6 [2]パケットの送信方法と、IPv6 over PPPを確立および構成するためのネットワーク制御プロトコル（NCP）を定義します。また、PPPリンクでIPv6リンクローカルアドレスを形成する方法も指定します。

Table of Contents

   1.     Introduction ..........................................    2
        1.1.  Specification of Requirements .....................    2
   2.     Sending IPv6 Datagrams ................................    2
   3.     A PPP Network Control Protocol for IPv6 ...............    3
   4.     IPV6CP Configuration Options ..........................    4
        4.1.  Interface-Identifier ..............................    4
        4.2.  IPv6-Compression-Protocol..........................    9
   5.     Stateless Autoconfiguration and Link-Local Addresses ..   10
   6      Security Considerations ...............................   11
   7      Acknowledgments .......................................   11
   8      Changes from RFC-2023 .................................   11
   9      References ............................................   12
   10     Authors' Addresses ....................................   13

   11     Full Copyright Statement ..............................   14

1. Introduction

1. はじめに

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）異なるネットワーク層プロトコルを確立および構成するためのネットワーク制御プロトコル（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.

ポイントツーポイントリンクを介して通信を確立するには、PPPリンクの両端が最初にLCPパケットを送信して、データリンクを構成およびテストする必要があります。リンクが確立され、オプションの機能がLCPによって必要に応じてネゴシエートされた後、PPPはNCPパケットを送信して、1つ以上のネットワーク層プロトコルを選択および構成する必要があります。選択した各ネットワーク層プロトコルが構成されたら、各ネットワーク層プロトコルからのデータグラムをリンク経由で送信できます。

In this document, the NCP for establishing and configuring the IPv6 over PPP is referred as the IPv6 Control Protocol (IPV6CP).

このドキュメントでは、IPv6 over PPPを確立および構成するための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パケットがリンクを閉じるまで、または何らかの外部イベント（もう一方の端での電源障害、キャリアドロップなど）が発生するまで、リンクは通信用に構成されたままになります。

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.

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).

ちょうど1つのIPv6パケットがPPPデータリンク層フレームの情報フィールドにカプセル化され、プロトコルフィールドはタイプ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 at least as large as the minimum link MTU size required for IPv6 [2].

PPPリンクを介して送信されるIPv6パケットの最大長は、PPPデータリンク層フレームの情報フィールドの最大長と同じです。 IPv6をサポートするPPPリンクでは、少なくともIPv6に必要な最小リンクMTUサイズと同じ大きさの情報フィールドを許可する必要があります[2]。

3. A PPP Network Control Protocol for IPv6

3. IPv6のPPPネットワーク制御プロトコル

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.

IPv6制御プロトコル（IPV6CP）は、ポイントツーポイントリンクの両端でIPv6プロトコルモジュールを構成、有効化、および無効化します。 IPV6CPは、リンク制御プロトコル（LCP）と同じパケット交換メカニズムを使用します。 PPPがネットワーク層プロトコルフェーズに到達するまで、IPV6CPパケットは交換されません。このフェーズに到達する前に受信したIPV6CPパケットは、通知なく破棄されます。

The IPv6 Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:

IPv6制御プロトコルは、リンク制御プロトコル[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データリンク層フレームの情報フィールドにカプセル化され、プロトコルフィールドは16進数の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、Terminate-Ack、および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.

PPPがネットワーク層プロトコルフェーズに到達するまで、IPV6CPパケットは交換されません。実装は、認証とリンク品質の決定が完了するのを待ってから、Configure-Ackまたはその他の応答を待つタイムアウトになるように準備する必要があります。実装は、ユーザーの介入または構成可能な時間の後にのみあきらめることをお勧めします。

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構成オプションにより、望ましいIPv6パラメータのネゴシエーションが可能になります。 IPV6CPは、LCP [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

1インターフェース識別子2 IPv6-圧縮プロトコル

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オプションは、Interface-IdentifierとIPv6-Compression-Protocolです。長期にわたって定義できるその他の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]に使用される一意の64ビットインターフェイス識別子をネゴシエートする方法を提供します（セクション5を参照）。 Configure-Requestには、Interface-Identifierオプションのインスタンスを1つだけ含める必要があります[1]。インターフェイス識別子はPPPリンク内で一意でなければなりません。つまり、ネゴシエーションが完了すると、PPPリンクの両端に異なるInterface-Identifier値が選択されます。インターフェース識別子はまた、より広い範囲にわたって一意であるかもしれません。

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.

この構成オプションが要求される前に、実装は暫定的なInterface-Identifierを選択します。暫定的なInterface-Identifierのゼロ以外の値は、値がリンクに対して一意であり、可能であれば、IPV6CP有限状態マシンの初期化（管理上のCloseおよびReOpen、再起動など）を通じて一貫して再現できるように選択する必要があります（SHOULD）。完全にランダムなインターフェイス識別子よりも一貫して再現可能な一意のインターフェイス識別子を優先する根拠は、インターフェイス識別子から形成できるグローバルスコープアドレスに安定性を提供することです。

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.

インターフェイス識別子ビットが0から63までの正規のビット順序で番号付けされ、最上位ビットがビット番号0であると仮定すると、ビット番号6は「u」ビット（IEEE EUI-64のユニバーサル/ローカルビット[5]用語））これは、インターフェース識別子がグローバルに一意のIEEE識別子（EUI-48またはEUI-64 [5]）に基づいているかどうかを示します（以下のケース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 to that the extracted identifier is presented in canonical ordering [8].

1）IEEEグローバル識別子（EUI-48またはEUI-64）がノードのどこでも使用できる場合は、その一意性プロパティにより、暫定的なInterface-Identifierを構築するために使用する必要があります。ノード上の別のデバイスから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,

ここで、 "c"は割り当てられたcompany_idのビット、 "0"はグローバルスコープを示すユニバーサル/ローカルビットの値、 "g"はグループ/個別ビット、 "e"は拡張識別子のビットです。

the IPv6 interface identifier would be of the form:

IPv6インターフェースIDは次の形式になります。

   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識別子の場合、48ビットMACの中央（company_idとextension-identifierの部分の間）に16進値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 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インターフェースIDは次の形式になります。

   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 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.

Interface-Identifierネゴシエーションが成功するには、一意性またはランダム性の適切なソース[1]が必要です。一意の番号も乱数も生成できない場合は、Configure-Requestで送信されるInterface-Identifierにゼロ値を使用することをお勧めします。この場合、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:

Interface-Identifier Configuration OptionでConfigure-Requestを受信し、受信ピアがこのオプションを実装すると、受信したInterface-Identifierが、ピアに送信された最後のConfigure-RequestのInterface-Identifierと比較されます。比較の結果に応じて、実装は次のいずれかの方法で応答する必要があります。

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つのInterface-Identifierは異なるが、受信したInterface-Identifierが0の場合、リモートピアによる使用が提案されている0以外のInterface-Identifier値とともにConfigure-Nakが送信されます。このような提案されたInterface-Identifierは、ピアに送信された最後のConfigure-RequestのInterface-Identifierとは異なる必要があります。提案された値は、IPV6CP有限状態マシンの初期化（管理上のクローズと再オープン、再起動など）を通じて一貫して再現可能であることをお勧めします。リモートピアによる排他的使用のためにグローバルに一意のEUI-48 / EUI-64派生識別子が提供されない限り、提案された識別子の「u」ユニバーサル/ローカル）ビットは、そのソースに関係なくゼロ（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つのInterface-Identifierが異なり、受信したInterface-Identifierがゼロでない場合は、Interface-Identifierを確認する必要があります。つまり、Configure-Ackが要求されたInterface-Identifierとともに送信されます。つまり、応答するピアがInterface-Identifierに同意します。識別子が要求されました。

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.

2つのInterface-Identifierが等しく、0でない場合、リモートピアによる使用が提案された、0以外の異なるInterface-Identifier値を指定して、Configure-Nakを送信する必要があります。提案された値は、IPV6CP有限状態マシンの初期化（管理上のクローズと再オープン、再起動など）を通じて一貫して再現可能であることをお勧めします。リモートピアによる排他的使用のためにグローバルに一意のEUI-48 / EUI-64派生識別子が提供されない限り、提案された識別子の「u」ユニバーサル/ローカル）ビットは、そのソースに関係なくゼロ（0）に設定する必要があります。

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.

2つのインターフェイス識別子がゼロに等しい場合、インターフェイス識別子の値をゼロに設定してConfigure-Rejectを送信することにより、インターフェイス識別子のネゴシエーションを終了する必要があります。この場合、一意のインターフェイス識別子はネゴシエートできません。

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.

Configure-RequestがInterface-Identifier Configuration Optionで受信され、受信ピアがこのオプションを実装していない場合、Configure-Rejが送信されます。

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).

新しいConfigure-Requestは、通常の処理によって送信されるまで（つまり、Configure-Nakが受信されるか、再起動タイマーがなくなるまで）ピアに送信すべきではありません（SHOULD NOT）。

A new Configure-Request MUST NOT contain the Interface-Identifier option if a valid Interface-Identifier Configure-Reject is received.

有効なInterface-Identifier Configure-Rejectを受信した場合、新しいConfigure-RequestにInterface-Identifierオプションを含めてはなりません（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.

ピアに送信された最後のConfigure-Nakとは異なる提案されたInterface-Identifierを持つConfigure-Nakの受信は、一意のInterface-Identifierを示します。この場合、新しいConfigure-Requestは、ピアからの最後のConfigure-Nakで提案された識別子の値とともに送信されなければなりません（MUST）。ただし、受信したInterface-Identifierが最後のConfigure-Nakで送信されたものと等しい場合は、新しいInterface-Identifierを選択する必要があります。この場合、新しいConfigure-Requestは新しい暫定的なInterface-Identifierとともに送信されるべきです（SHOULD）。このシーケンス（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.

Interface-Identifierのネゴシエーションが必要で、ピアがそのConfigure-Requestでオプションを提供しなかった場合、オプションをConfigure-Nakに追加する必要があります（SHOULD）。指定されたInterface-Identifierの暫定値は、リモートInterface-Identifierとして受け入れられる必要があります。つまり、PPPリンクのローカルエンド用に選択された識別子の値とは異なる必要があります。ピアからの次のConfigure-Requestには、このオプションが含まれる場合があります。次のConfigure-Requestにこのオプションが含まれていない場合、ピアは、このオプションを含む別のConfigure-Nakを送信してはなりません（MUST NOT）。ピアの実装がこのオプションをサポートしていないと想定する必要があります。

By default, an implementation SHOULD attempt to negotiate the Interface-Identifier for its end of the PPP connection.

デフォルトでは、実装は、PPP接続の終了のためにインターフェース識別子のネゴシエーションを試みる必要があります（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

タイプ

１

Length

長さ

１０

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.

リンク上で一意である可能性が非常に高い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.

有効なインターフェイス識別子を正常にネゴシエートできない場合、デフォルトのInterface-Identifier値は想定されません。このような場合からの回復手順は不定です。 1つのアプローチは、インターフェースのインターフェースIDを手動で構成することです。

4.2. IPv6-Compression-Protocol

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パケット圧縮プロトコルの使用をネゴシエートする方法を提供します。 IPv6-Compression-Protocol構成オプションは、圧縮されたパケットを受信する機能を示すために使用されます。双方向圧縮が必要な場合は、リンクの両端でこのオプションを個別に要求する必要があります。デフォルトでは、圧縮は有効になっていません。

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.

このオプションでネゴシエートされたIPv6圧縮はIPv6データグラムに固有であり、すべてのデータグラムに影響を与える可能性のある圧縮制御プロトコル（CCP）によるネゴシエーションから生じる圧縮と混同しないでください。

A summary of the IPv6-Compression-Protocol Configuration Option format is shown below. The fields are transmitted from left to right.

IPv6-Compression-Protocol構成オプションの形式の概要を以下に示します。フィールドは左から右に送信されます。

   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

タイプ

２

Length

長さ

>= 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.

IPv6-Compression-Protocolフィールドは2オクテットであり、必要な圧縮プロトコルを示します。このフィールドの値は、同じ圧縮プロトコルのPPPデータリンク層プロトコルフィールドの値と常に同じです。

No IPv6-Compression-Protocol field values are currently assigned. Specific assignments will be made in documents that define specific compression algorithms.

IPv6-Compression-Protocolフィールド値は現在割り当てられていません。特定の割り当ては、特定の圧縮アルゴリズムを定義するドキュメントで行われます。

Data

データ

The Data field is zero or more octets and contains additional data as determined by the particular compression protocol.

データフィールドは0オクテット以上であり、特定の圧縮プロトコルによって決定される追加データが含まれます。

Default

デフォルト

No IPv6 compression protocol enabled.

IPv6圧縮プロトコルが有効になっていません。

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.

PPPインターフェースのIPv6ユニキャストアドレスのインターフェース識別子[6]。PPP接続セットアップのIPV6CPフェーズでネゴシエートする必要があります（セクション4.1を参照）。有効なインターフェイス識別子が正常にネゴシエートされなかった場合、そのような場合から回復するための手順は規定されていません。 1つのアプローチは、インターフェースのインターフェースIDを手動で構成することです。

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.

PPP接続セットアップのIPV6CPフェーズでインターフェイス識別子がネゴシエートされる限り、IPv6ステートレス自動構成プロトコル[3]の一部として重複アドレス検出を実行することは冗長です。したがって、IPV6CP Interface-Identifierオプションが有効になっているPPPリンクでは、DupAddrDetectTransmits自動構成変数[3]のデフォルト値をゼロにすることをお勧めします。

Link-local addresses of PPP interfaces have the following format:

PPPインターフェイスのリンクローカルアドレスの形式は次のとおりです。

   | 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.

アドレスの最上位10ビットは、リンクローカルプレフィックスFE80 ::です。 54個のゼロビットは、リンクローカルプレフィックスとインターフェイス識別子フィールドの間のアドレスを埋めます。

6. Security Considerations

6. セキュリティに関する考慮事項

The IPv6 Control Protocol extension to PPP can be used with all defined PPP authentication and encryption mechanisms.

PPPのIPv6制御プロトコル拡張は、定義されたすべてのPPP認証および暗号化メカニズムで使用できます。

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.

このドキュメントは、マジックナンバーLCPオプションを借用したものであり、PPPワーキンググループによる以前の作業に部分的に基づいています。

8. Changes from RFC-2023

8. RFC-2023からの変更点

The following changes were made from RFC-2023 "IP Version 6 over PPP":

RFC-2023「IPバージョン6 over PPP」から次の変更が行われました。

- 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].

- 新しく採用されたIPv6アドレス指定アーキテクチャ[6]に従って、インターフェイス識別子のサイズを64ビットに拡大しました。

- 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.

- ノード上の任意の場所で使用可能な場合に、一意のIEEEグローバル識別子からグローバルに一意のインターフェース識別子を生成するためのインターフェース識別子選択メソッドが追加されました。

- Changed to send a Configure-Nak instead a Configure-Ack in response to receiving a Configure-Request with a zero Interface-Identifier value.

- ゼロのInterface-Identifier値を持つConfigure-Requestの受信に応答して、Configure-Ackの代わりにConfigure-Nakを送信するように変更されました。

- 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.

- IPv6-Compression-Protocol ConfigurationオプションのIPv6-Compression-Protocolフィールドの値の割り当てを、IPv6-Compression-Protocolフィールドの値が現在割り当てられておらず、特定の割り当てが特定の圧縮を定義するドキュメントで行われることを示すテキストで置き換えましたアルゴリズム。

- 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.

[1] Simpson、W。、「The Point-to-Point Protocol」、STD 51、RFC 1661、1994年7月。

[2] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[2] Deering、S。、およびR. Hinden、編集者、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。

[3] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.

[3] Thomson、S。、およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。

   [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.

[5] IEEE、「64ビットグローバル識別子（EUI-64）登録機関のガイドライン」、http：//standards.ieee.org/db/oui/tutorials/EUI64.html、1997年3月。

[6] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

[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.

[7] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。

[8] Narten T., and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998.

[8] Narten T.、およびC. Burton、「リンク層アドレスの標準的な順序付けに関する注意」、RFC 2469、1998年12月。

10. Authors' Addresses

10. 著者のアドレス

Dimitry Haskin Bay Networks, Inc. 600 Technology Park Billerica, MA 01821

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

Ed Allen Bay Networks、Inc. 600 Technology Park Billerica、MA 01821

   EMail: eallen@baynetworks.com

11. Full Copyright Statement

11. 完全な著作権表示

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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。