Network Working Group S. Varada, Ed.
Request for Comments: 5172 Transwitch
Obsoletes: 2472 March 2008
Category: Standards Track
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.
IPv6控制协议（IPV6CP）是PPP链路的NCP，允许通过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
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:
PPP[1]有三个主要组成部分：
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链路的每一端必须首先发送LCP数据包以配置和测试数据链路。链路建立并根据LCP的需要协商可选设施后，PPP必须发送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.
在IPv6 over PPP规范[2]中，定义了用于建立和配置IPv6 over PPP的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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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参数。IPV6CP使用与LCP[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选项的类型字段如下所示：
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压缩协议配置选项格式的摘要如下所示。字段从左向右传输。
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 ...
+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Type
类型
2
2.
Length
长
>= 4
>= 4
IPv6-Compression-Protocol
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压缩协议字段是两个八位字节，表示所需的压缩协议。此字段的值始终与同一压缩协议的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.
[4,5]中为IP报头压缩（0061）分配了IPv6压缩协议字段值，[6]中为健壮报头压缩（ROHC）（0003）分配了IPv6压缩协议字段值。可以在定义特定压缩算法的文档中进行其他分配。
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
即使有一个或多个以上的安全措施，PPP链路上的对等交互也存在一定的威胁。例如，使用MD5身份验证方法[9]会使人遭受重播攻击，在这种攻击中，攻击者可以截获并重播站点的身份和密码散列以访问网络。建议本规范的用户参考[8]，其中提供了一个通用威胁模型，以了解对其构成的威胁
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.
链接的安全性。参考文献[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数据报压缩选项的类型字段赋值不需要执行任何特定操作。[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压缩协议值，因此无需采取任何措施来分配IPV6压缩协议值。此字段的值始终与同一压缩协议的PPP数据链路层协议字段值相同。因此，这些值的未来分配受RFC 3818[11]的约束，该约束要求IETF达成一致意见。当前值位于注册表“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.
编辑感谢Jari Arkko在本文件中提供的指导，以及James Carlson提供的有用建议。感谢D.Haskin和E.Allen在RFC 2023和RFC 2472中完成的规范工作。
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Varada, S., Ed., Haskin, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[2] Varada，S.，Ed.，Haskin，D.，和E.Allen，“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] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[4] Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[5] Koren, T., Casner, S., and C. Bormann, "IP Header Compression over PPP", RFC 3544, July 2003.
[5] Koren，T.，Casner，S.，和C.Bormann，“PPP上的IP报头压缩”，RFC 3544，2003年7月。
[6] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[6] Bormann，C.，“PPP上的鲁棒头压缩（ROHC）”，RFC 32412002年4月。
[7] IANA, http://www.iana.org.
[7] 伊安娜，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.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[10] Meyer，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.
[11] Schryver，V.，“点到点协议（PPP）的IANA考虑因素”，BCP 88，RFC 3818，2004年6月。
[12] Rand, D., "The PPP Compression Control Protocol(CCP)", RFC 1962, June 1996.
[12] Rand，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.Allen，“PPP上的IP版本6”，RFC 24721998年12月。
Editor's Address
编辑地址
Srihari Varada TranSwitch Corporation 3 Enterprise Dr. Shelton, CT 06484 US
Srihari Varada TranSwitch Corporation 3 Enterprise Shelton博士，美国CT 06484
Phone: +1 203 929 8810
EMail: varada@ieee.org
Phone: +1 203 929 8810
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.