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
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はまた、拡張可能なリンク制御プロトコルを定義し、確立し、異なるネットワーク層プロトコルを設定するためのネットワーク制御プロトコル（NCP）のファミリーを提案しています。
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リンク確立およびPPP上でIPv6を設定するためのNCP経由でIPv6パケットを送信するための方法、および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グローバルユニキャストアドレスに重複アドレス検出を実行するための条件を指定します。
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）を確立し、異なるネットワーク層プロトコルを設定するためのネットワーク制御プロトコル（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リンクの各端部は、第1のデータリンクを設定し、テストするために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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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制御プロトコルはOpened状態に達しなければなりません。
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パケットは、プロトコルフィールドがタイプ六角0057（インターネットプロトコルバージョン6）を示すPPP Data Link Layerフレームの情報フィールドにカプセル化されています。
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として同じパケット交換メカニズムを使用しています。 PPPは、ネットワーク層プロトコルフェーズに達するまでIPV6CPパケットは交換されないかもしれません。この段階に到達する前に受信されているIPV6CPパケットは静かに捨てられるべきです。
The IPv6 Control Protocol is exactly the same as the LCP [1] with the following exceptions:
IPv6の制御プロトコル[1]は、以下の例外を除いてLCPと全く同じです。
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パケットは、プロトコルフィールドがタイプ六角8057（IPv6の制御プロトコル）を示すPPP Data Link Layerフレームの情報フィールドにカプセル化されています。
Code field
Codeフィールド
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（設定要求、設定肯定応答、通信設定否定応答、構成拒否、終了要求、終了-ACKおよびコード拒否）が使用されます。他のコードは認識されていないとして扱われるべきとコード・リジェクツを生じるはずです。
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パケットは交換されないかもしれません。実装は、通信設定肯定応答または他の応答を待ってタイムアウトする前に終了する認証とリンク品質の決意を待つために準備する必要があります。実装がユーザ介入や時間の設定可能な量の後にあきらめることが示唆されます。
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 [1] LCPのためではなく、オプションの別個のセットで定義された同一の構成オプションのフォーマットを使用します。設定オプションが設定要求パケットに含まれていない場合は、その設定オプションのデフォルト値が仮定されます。
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
この構成オプションは、リンクのローカル・エンドのアドレス自動設定[3]のために使用される一意の64ビットのインタフェース識別子を交渉する方法を提供する（セクション5を参照）。設定要求は、インターフェース識別子オプション[1]のうちの正確に1つのインスタンスを含まなければなりません。インタフェース識別子は、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.
リンク;すなわち、ネゴシエーションが完了すると、異なるインタフェース識別子値は、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の正規ビット順に0から63まで番号が付けられていると仮定すると、ビット数6 IEEE EUI-64に「U」ビット（ユニバーサル/ローカルビットである[4]インターフェース識別子はグローバルにユニークなIEEE識別子に基づいているかどうかを示す用語）、（EUI-48またはEUI-64 [4]）（）下ケース1を参照されたいです。グローバルにユニークなIEEE識別子がインターフェース識別子を導出するために使用され、そしてそれはそうでなければゼロ（0）に設定されている場合には、1（1）に設定されています。
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].
IEEEグローバル識別子（EUI-48またはEUI-64）の任意の場所ノードで利用可能である場合1）、その一意の特性に仮のインタフェース識別子を構築するために使用されるべきです。ノード上の他のデバイスから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識別子の場合には、第一のcompany_idおよび拡張の間（48ビットMACの途中で、は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.
IEEEグローバル識別子を使用できない場合は2）、一意性の異なるソースを使用すべきです。一意の提案ソースがリンク層アドレス、マシンのシリアル番号、エトセトラを含みます。
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]ユニークさやランダム性の良い情報源は、成功するためのインタフェース識別子のネゴシエーションのために必要とされます。固有番号や乱数のいずれも生成することができる場合、ゼロの値が設定要求で送信インタフェース識別子のために使用することが推奨されます。以下に説明するように、この場合に、PPPピアは、その応答に有効な非ゼロインタフェース識別子を提供することができます。 PPPピアの少なくとも一つは、それ自体とそのピアの別の非ゼロ数字を生成することができる場合、識別子交渉が成功することに注意してください。
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:
設定要求を受信した場合、インタフェース識別子設定オプション及び受信ピアがこのオプションを実装して、受信されたインタフェース識別子は、ピアに送信された最後の設定要求のインタフェース識別子と比較されます。比較の結果に応じて、実装は、次のいずれかの方法で応答しなければなりません：
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種類のインタフェース識別子が異なっているが、受信インタフェース識別子がゼロであれば、設定否定応答がリモートピアで使用するために提案非ゼロインタフェース識別子値と送られます。そのような提案インタフェース識別子は、ピアに送信された最後の設定要求のインタフェース識別子と異なっていなければなりません。 （など、行政を閉じて再度開いた、再起動します）推奨値がIPV6CP有限状態マシンの初期化全体で一貫して再現することをお勧めします。提案識別子の「U」（ユニバーサル/ローカル）ビットがゼロ（0）にかかわらず、そのソースのグローバルにユニークなEUI-48 / EUI-64由来の識別子がリモートピアによる排他的使用のために提供されない限り、に設定しなければなりません。
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種類のインタフェース識別子が異なっており、受信したインタフェース識別子がゼロでない場合、インタフェース識別子は、認めなければならない、すなわち、設定肯定応答は、応答ピアが要求されたインタフェース識別子と一致することを意味し、要求されたインタフェース識別子と送信されます。
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種類のインタフェース識別子が等しく、ゼロでない場合は、設定否定応答は、異なる非ゼロインタフェース識別子値は、リモートピアで使用するために提案指定送らなければなりません。 （など、行政を閉じて再度開いた、再起動します）推奨値がIPV6CP有限状態マシンの初期化全体で一貫して再現することをお勧めします。提案識別子の「U」（ユニバーサル/ローカル）ビットがゼロ（0）にかかわらず、そのソースのグローバルにユニークなEUI-48 / EUI-64由来の識別子がリモートピアによる排他的使用のために提供されない限り、に設定しなければなりません。
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種類のインタフェース識別子がゼロに等しい場合、インタフェース識別子のネゴシエーションがゼロに設定さインターフェイス識別子の値と設定が拒否送信することによって終了しなければなりません。この場合には、ユニークなインタフェース識別子を交渉することはできません。
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.
設定要求がインターフェイス識別子設定オプションと受信ピアで受信された場合は、このオプションを実装していない、通信設定拒否送信されます。
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]).
新しい設定要求は、通常の処理は、それが送信される原因となるまで（設定否定応答が受信されるまで、つまりまたは再起動タイマーが切れる[1]）ピアに送るべきではありません。
A new Configure-Request MUST NOT contain the interface-identifier option if a valid Interface-Identifier Configure-Reject is received.
有効なインターフェイスには、識別子が設定拒否受信された場合は、新しい設定要求は、インタフェース識別子オプションを含めることはできません。
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.
ピアに送信された最後の設定否定応答とは異なる示唆したインタフェース識別子を持つ通信設定否定応答の受信は、ユニークなインタフェース識別子を示します。この場合、新たに設定要求は、ピアからの最後の通信設定否定応答で提案されている識別子の値を送らなければなりません。受信したインターフェイス識別子が最後の通信設定否定応答で送信されたものに等しい場合でも、新しいインタフェース識別子を選ばなければなりません。この場合、新しい設定要求は、新たな仮のインタフェース識別子と共に送信されるべきです。このシーケンスは、（設定否定応答を送信し、設定要求を受け、設定要求を送信し、通信設定否定応答を受信）数回発生する場合がありますが、繰り返し発生する極めてまれです。それどころか、両端に選ばれたインターフェイス識別子は、すぐにシーケンスを終了、発散します。
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.
インタフェース識別子の交渉が必要とされ、ピアがその設定要求でオプションを提供しなかった場合は、オプションが設定否定応答に付加されるべきです。所定のインタフェース識別子の暫定値は、リモートインタフェース識別子として許容されなければなりません。すなわち、それは、PPPリンクのローカルエンドのために選択された識別子の値と異なるなければなりません。ピアからの次の設定要求は、このオプションを含めることができます。次の設定要求は、このオプションが含まれていない場合は、このオプションを使用して別の設定否定応答を送ってはいけませんピアが含まれています。これは、ピアの実装では、このオプションをサポートしていないことを前提とすべきです。
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.
インターフェイス識別子設定オプションフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
１
Length
長さ
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.
有効なインタフェース識別子が正常にネゴシエートできない場合は、デフォルトのインターフェイス識別子の値が想定されるべきではありません。そのような場合から回復するための手順は不定です。一つのアプローチは、手動インタフェースのインタフェース識別子を設定することです。
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節を参照）。有効なインタフェース識別子が正常に交渉されていない場合、そのような場合から回復するための手順は、指定されていません。一つのアプローチは、手動インタフェースのインタフェース識別子を設定することです。
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インターフェイスのIPv6リンクローカルユニキャストアドレスを自動設定するためにPPPリンクのローカルエンドで使用されます。しかしながら、同一のインタフェース識別子は、IPv6ステートレスアドレス自動設定を使用して、PPPインターフェイスのグローバルユニキャストアドレスを構成する際に使用されることが想定されるべきではない[3]。 PPPピアは、一つ以上のグローバルユニキャストアドレスを自動設定する、[8]に記載の方法を用いて、例えば、一つ以上のインタフェース識別子を生成することができます。
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ステートレスアドレス自動設定プロトコルの一部として重複アドレス検出（DAD）を実行するために冗長である[3]が生成IPv6リンクローカルアドレスでPPPピアによって。また、構成された任意のグローバルユニキャストアドレスでDADを実行するために冗長であってもよい（あたりとして、例えば、IPV6CP中にネゴシエートまたは生成されるか、インタフェース識別子を使用して、[8]）のIPv6ステートレスアドレス自動設定プロトコルの一部としてインタフェースのための[ 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]).
したがって、IPV6CPインタフェース識別子とのPPPリンクにオプションを有効にし、上記2つの条件を満たし、DupAddrDetectTransmits自動変数のデフォルト値を[3]システム管理によってゼロに設定することが推奨されます。 3GPP2ネットワークは、[10] IPv6グローバルユニキャストアドレスを取得するためにホストを可能にするために、PPPを使用し、前述の二つの条件を満足する技術の一例です。 3GPPネットワークは、別の例である（[11] [13]）。
Link-local addresses
リンクローカルアドレス
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ゼロビットパッド。
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.
認証などのリンクのセキュリティの欠如、ステートレスアドレス自動設定方法は、いずれかのIPV6CPを通してネゴシエートまたは生成、例えばれるインターフェイス識別子からグローバルユニキャストIPv6アドレスを生成するために使用された場合[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リンク上のピア間の相互作用に関連した特定の脅威があります。たとえば、[16] MD5認証方式を使用して、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データグラムインターフェース識別子オプションのTypeフィールドの値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.
この文書では、マジック・ナンバーの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,
エディタは、具体的には、RFC 2472.感謝の更新の精神でのIPv6コミュニティのメンバーによって提供された入力に感謝です
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.
彼らの技術的な貢献のためのピートBaranyとカリム・エルMalkiに行きます。また、ニットのためのセキュリティの側面を支援するための徹底的な見直しのためのアレックス・コンタ、スティーブン・ケント、およびスペンサードーキンスとペッカSavolaに感謝。最後に、著者はこの仕様に閉鎖をもたらすために彼の開始のためのヤリArkkoに感謝です。
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1]シンプソン、W.、エド。、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2]デアリング、S.と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]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、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.デアリング、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[7] Haskin、D.およびE.アレン、 "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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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、2005年4月 "公衆陸上モバイルネットワーク（PLMN）のサポート、パケットベースのサービスおよびパケットデータネットワーク（PDN）（6）リリース、間のインターワーキング"。
[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.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "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、 "汎用パケット無線サービス（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.バートン、「リンク層アドレスの正規の順序に注意」、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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[16]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[17] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[17]マイヤー、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リンク上のノードは、いずれかのステートレスまたはステートフルアドレス自動設定機構を介してグローバルユニキャストアドレスを作成します。ステートレスアドレス自動設定に[3]、ノードは、インターフェース識別子からグローバルユニキャストアドレスを取得するためにルータ広告メッセージを介してルータによってアドバタイズサブネットプレフィックスに依存しています。ステートフルアドレス自動設定では、ホストは、グローバルユニキャストアドレスを取得するために、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.
- 付録Aとマイナーテキスト明確化への参照が含まれるように、セクション4.1のテキストを更新しました。
- 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の圧縮・プロトコル上のセクション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.
グローバルユニキャストアドレスの作成に、リンクのピア間でネゴシエートインタフェース識別子の使用に加えて、（a）は、ピアによって生成された一つ以上のインタフェース識別子の使用を許可する： - に第5節のテキストを更新ローカルPPPインタフェース、および（b）作成の非リンクローカルアドレスのDADに対してケースを識別する。
- Added new and updated references.
- 新規および更新の参照を追加しました。
- Added Appendix A
- 追加付録A
Authors' Addresses
著者のアドレス
Dimitry Haskin Ed Allen
Dimitry Haskinエド・アレン
Srihari Varada (Editor) TranSwitch Corporation 3 Enterprise Dr. Shelton, CT 06484. US.
スリアリVarada（編集）トランスイッチ社3エンタープライズ博士シェルトン、CT 06484.米国。
Phone: +1 203 929 8810 EMail: varada@ieee.org
電話：+1 203 929 8810 Eメール：varada@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。