Network Working Group S. Varada, Ed.
Request for Comments: 5172 Transwitch
Obsoletes: 2472 March 2008
Category: Standards Track
Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol
IPv6の制御プロトコルを使用したIPv6データグラムの圧縮のためのネゴシエーション
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）のファミリーを提案しています。
The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.
PPPリンクのNCPでのIPv6制御プロトコル（IPV6CP）は、PPP上のIPv6インタフェースのための望ましいパラメータのネゴシエーションを可能にします。
This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP.
この文書では、IPV6CPを通じて、リンク上のノードによって交渉することができたIPv6データグラムの圧縮オプションを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. IPV6CP Configuration Options ....................................3
2.1. IPv6-Compression-Protocol ..................................3
3. Security Considerations .........................................4
4. IANA Considerations .............................................5
5. Management Considerations .......................................5
6. Acknowledgments .................................................5
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................6
PPP [1] has three main components:
[1] 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. 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.).
ポイントツーポイントリンクを介して通信を確立するために、PPPリンクの各端部は、第1のデータリンクを設定し、テストするためにLCPパケットを送信しなければなりません。リンクが確立され、LCPの必要に応じてオプションの施設が交渉された後、PPPは、1つ以上のネットワーク層プロトコルを選択し、設定するためにNCPパケットを送信する必要があります。選択されたネットワーク層プロトコルの各々が構成されたら、各ネットワーク層プロトコルからのデータグラムは、リンクを介して送信することができます。リンクは、明示的なLCPまたはNCPパケットがダウンリンクを閉じるまで、または何らかの外部イベントが（等他端に電源障害、キャリア降下）が発生するまでの通信のために構成残ります。
In the IPv6 over PPP specification [2], the NCP, or IPV6CP, for establishing and configuring IPv6 over PPP is defined. The same specification defines the Interface Identifier parameter, which can be used to generate link-local and globally unique IPv6 addresses, for negotiation.
PPPの仕様上のIPv6 [2]、PPP上のIPv6を確立し、構成するためのNCP、またはIPV6CPは、定義されています。同じ仕様では交渉のため、リンクローカルおよびグローバルに一意のIPv6アドレスを生成するために使用することができるインタフェース識別子パラメータを定義します。
In this specification, the compression parameter for use in IPv6 datagram compression is defined. Together with RFC 5072 [2], this document obsoletes RFC 2472 [13]. However, no protocol changes have been introduced over RFC 2472.
本明細書では、IPv6データグラムの圧縮に使用するための圧縮パラメータが定義されています。一緒にRFC 5072と、[2]、この文書は、RFC 2472 [13]を廃止します。しかし、プロトコルの変更は、RFC 2472を介して導入されていません。
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 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[3]で説明されるように解釈されます。
IPV6CP Configuration Options allow negotiation of desirable IPv6 parameters. IPV6CP uses the same Configuration Option format as 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パラメータのネゴシエーションを可能にします。 LCPのために定義されるようIPV6CP [1]が、オプションの別のセットと同じ構成オプションのフォーマットを使用します。設定オプションが設定要求パケットに含まれていない場合は、その設定オプションのデフォルト値が仮定されます。
The only IPV6CP option defined in this document is the IPv6- Compression-Protocol. The Type field for this IPV6CP Option is as follows:
この文書で定義された唯一のIPV6CPオプションはIPv6-圧縮・プロトコルです。次のようにこのIPV6CPオプションのためのTypeフィールドは次のとおりです。
2 IPv6-Compression-Protocol
2 IPv6の圧縮、プロトコル
Note that the up-to-date values of the IPV6CP Option Type field are specified in the on-line database of "Assigned Numbers" maintained by IANA [7].
IPV6CPオプションタイプフィールドの最新の値はIANAによって維持される「割り当て番号」のオンラインデータベースに指定されていることに注意してください[7]。
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 bidirectional compression is desired. By default, compression is not enabled.
この設定オプションは、特定のIPv6パケット圧縮プロトコルの使用を交渉する方法を提供します。 IPv6の圧縮・プロトコル設定オプションは、圧縮されたパケットを受信する能力を示すために使用されます。双方向の圧縮が望まれる場合には、リンクの各端部は、個別に、このオプションを要求しなければなりません。デフォルトでは、圧縮が有効になっていません。
IPv6 compression negotiated with this option is specific to IPv6 datagrams and is not to be confused with compression resulting from a compression method negotiated via the PPP Compression Control Protocol (CCP) [12], which potentially affects all datagrams.
このオプションと交渉のIPv6圧縮は、IPv6データグラムに特異的であり、潜在的にすべてのデータグラムに影響PPP圧縮制御プロトコル（CCP）[12]を介してネゴシエート圧縮方法から得られる圧縮と混同されるべきではありません。
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
タイプ
2
２
Length
長さ
>= 4
＞＝ ４
IPv6-Compression-Protocol
IPv6の圧縮、プロトコル
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の圧縮プロトコルフィールドは、2つのオクテットであり、所望の圧縮プロトコルを示します。このフィールドの値は常にその同じ圧縮プロトコルのPPPデータリンク層プロトコルフィールドの値と同じです。
IPv6-Compression-Protocol field values have been assigned in [4, 5] for IP Header Compression (0061), and in [6] for Robust Header Compression (ROHC) (0003). Other assignments can be made in documents that define specific compression algorithms.
IPv6の圧縮プロトコルフィールドの値は、IPヘッダー圧縮（0061）[4]、[5]に割り当てられ、[6]ロバストヘッダ圧縮（ROHC）用（0003）にされています。その他の割り当ては、特定の圧縮アルゴリズムを定義する文書で行うことができます。
Data
データ
The Data field is zero or more octets and contains additional data as determined by the particular compression protocol.
データフィールドはゼロ以上のオクテットであり、特定の圧縮プロトコルによって決定されるような追加のデータを含みます。
The default (in the absence of negotiation of this option) is to have no IPv6 compression protocol enabled.
（このオプションの交渉がない場合）デフォルトではIPv6の圧縮プロトコルが有効になっていないことです。
Lack of proper link security, such as authentication, prior to data transfers may enable man-in-the middle attacks resulting in the loss of data integrity and confidentiality. The mechanisms that are appropriate for ensuring PPP link security are addressed below together with the reference to a generic threat model.
認証などの適切なリンクセキュリティの欠如は、データ転送に先立っては、男・イン・データの整合性と機密性が失われ、中央の攻撃を可能にします。 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 [8] to select an authentication method (e.g., MD5 [9]) for validation of the peer, and 3) an encryption control protocol that facilitates negotiations between peers to select encryption algorithms (or crypto-suites) to ensure data confidentiality [10]).
PPPリンクのセキュリティを確保するのに適しているメカニズムは、次のとおり承認ポリシーを実施するためのリンクを介して受信されたトラフィックにフィルタを適用1）アクセス制御リスト、ピア間の交渉を容易にする2）認証プロトコル[8]の認証方法を選択します（例えば、ピアの検証のためのMD5 [9]）、および暗号化アルゴリズム（または暗号スイートを選択するためにピア間の交渉を容易3）暗号化制御プロトコル）データの機密性を確保するために[10]）。
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 [9] exposes one to replay attacks, in which 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 [8], which presents a generic threat model, for an understanding of the threats posed to the security of a link. The reference [8] also gives a framework to specify requirements for the selection of an authentication method for a given application.
でも、代わりに上記のセキュリティ対策の1つ以上とPPPリンク上のピア間の相互作用に関連した特定の脅威があります。例えば、MD5認証方式を使用して、[9]攻撃者が傍受し、ネットワークへのアクセスを得るために駅のIDとパスワードハッシュを再生することがあった攻撃を、再生するために1を公開します。この仕様書の利用者は、リンクの安全保障に脅威を理解するために、一般的な脅威モデルを提示する、[8]を参照することをお勧めします。 [8]参照はまた、所与のアプリケーションのための認証方法を選択するための要件を指定するためのフレームワークを与えます。
No specific action is needed for the assignment of a value for the Type field of IPv6 datagram compression option specified in this specification. The current assignment is up-to-date in the registry "PPP IPV6CP CONFIGURATION OPTIONS" for item IPv6-Compression-Protocol (2) at [7]. However, the RFC reference for that item has been changed to 5172.
具体的なアクションは、この仕様書で指定されたIPv6データグラムの圧縮オプションのTypeフィールドの値の割り当てのために必要ありません。現在の割り当ては、[7]にある項目のIPv6圧縮・プロトコル（2）は、「PPP IPV6CP構成オプション」レジストリに最新です。しかし、その項目のRFC参照が5172に変更されました。
No action is needed either for the assignment of the IPV6- Compression-Protocol values, as such values have already been defined by other documents listed in Section 2.1. Values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. As a result, future allocation of these values is governed by RFC 3818 [11] that requires IETF Consensus. Current values are in the registry "IPv6-Compression-Protocol Types". However, the RFC reference for that registry has been changed to 5172.
このような値がすでに2.1節に記載されている他のドキュメントで定義されているとして何の行動は、どちらかIPV6-圧縮・プロトコル値の割り当てのために必要ありません。このフィールドの値は常にその同じ圧縮プロトコルのPPPデータリンク層プロトコルフィールドの値と同じです。結果として、これらの値の将来の割り当ては、IETFコンセンサスを必要とするRFC 3818 [11]によって支配されます。現在の値は、レジストリの「IPv6-圧縮・プロトコルタイプ」です。しかし、そのレジストリのためのRFC参照が5172に変更されました。
From an operational point of view, the status of the negotiation and the compression algorithm on the link should be observable by an operator managing a network. There is no standard management interface that covers this at the time of the writing of this specification.
動作の観点からは、リンク上の交渉の状況と圧縮アルゴリズムは、ネットワークを管理するオペレータによって観察する必要があります。この仕様書の執筆時点でこれをカバー標準的な管理インターフェイスはありません。
The editor is grateful to Jari Arkko for the direction provided on this document and James Carlson for helpful suggestions. Acknowledgments are also due to D. Haskin and E. Allen for the specification work done in RFC 2023 and RFC 2472.
エディタは、有用な提案については、このドキュメントとジェームズ・カールソンに提供する方向のためのヤリArkkoに感謝です。謝辞は、RFC 2023およびRFC 2472で行われる仕様の作業にもD. HaskinとE.アレンによるものです。
[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] Varada, S., Ed., Haskin, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[2] Varada、S.、エド。、Haskin、D.、およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 5072、2007年9月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[4] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[5] Koren, T., Casner, S., and C. Bormann, "IP Header Compression over PPP", RFC 3544, July 2003.
[5]コレン、T.、Casner、S.、およびC.ボルマン、 "PPP上のIPヘッダー圧縮"、RFC 3544、2003年7月。
[6] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[6]ボルマン、C.、 "PPPオーバーロバストヘッダ圧縮（ROHC）"、RFC 3241、2002年4月。
[7] IANA, http://www.iana.org.
[7] IANA、http://www.iana.org。
[8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[8] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[10]マイヤー、G.、 "PPP暗号化制御プロトコル（ECP）"、RFC 1968、1996年6月。
[11] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004.
、BCP 88、RFC 3818、2004年6月[11] Schryver、V.、 "ポイントツーポイントプロトコル（PPP）のためのIANAの考慮事項"。
[12] Rand, D., "The PPP Compression Control Protocol(CCP)", RFC 1962, June 1996.
[12]ランド、D.、 "PPP圧縮制御プロトコル（CCP）"、RFC 1962、1996年6月。
[13] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[13] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。
Editor's Address
編集者の住所
Srihari Varada TranSwitch Corporation 3 Enterprise Dr. Shelton, CT 06484 US
スリアリVarada TranSwitch社株式会社3エンタープライズ博士シェルトン、コネチカット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 (2008).
著作権（C）IETFトラスト（2008）。
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に情報を記述してください。