Network Working Group P. Arberg
Request for Comments: 4638 D. Kourkouzelis
Category: Informational Redback Networks
M. Duckett
T. Anschutz
BellSouth
J. Moisand
Juniper Networks
September 2006
Network Working Group P. Arberg
Request for Comments: 4638 D. Kourkouzelis
Category: Informational Redback Networks
M. Duckett
T. Anschutz
BellSouth
J. Moisand
Juniper Networks
September 2006
Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)
在以太网点对点协议（PPPoE）中容纳大于1492的最大传输单元/最大接收单元（MTU/MRU）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
As of this writing, no current IEEE standard supports the use of "jumbo frames" (MTU greater than 1500). Although this document contains recommended mechanisms to detect problems in the path, interoperability and reliability of non-standard extensions cannot be assured. Both implementors and users of the protocol described here should exercise caution in its use.
在撰写本文时，没有现行的IEEE标准支持使用“巨型帧”（MTU大于1500）。尽管本文档包含用于检测路径中问题的推荐机制，但无法确保非标准扩展的互操作性和可靠性。这里描述的协议的实现者和用户在使用时都应该谨慎。
Abstract
摘要
The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks.
如RFC 2516所述，以太网点对点协议（PPPoE）要求最大协商最大接收单元（MRU）为1492。本文档概述了一种解决方案，该解决方案放宽了这一限制，允许最大协商MRU大于1492，以最小化下一代宽带网络中的碎片。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Proposed Solution ...............................................4
4. PPPoE Discovery Stage ...........................................5
5. LCP Considerations ..............................................5
5.1. MRU Negotiations ...........................................5
5.2. MRU Test and Troubleshooting ...............................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................7
8. Acknowledgements ................................................7
9. Normative References ............................................7
10. Informative References .........................................8
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Proposed Solution ...............................................4
4. PPPoE Discovery Stage ...........................................5
5. LCP Considerations ..............................................5
5.1. MRU Negotiations ...........................................5
5.2. MRU Test and Troubleshooting ...............................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................7
8. Acknowledgements ................................................7
9. Normative References ............................................7
10. Informative References .........................................8
As broadband network designs are changing from PC-initiated PPPoE [1] sessions in a combined Ethernet/Asynchronous Transfer Mode (ATM) setup, as shown in Figure 1, to more intelligent PPPoE-capable Residential Gateway (RG) and Gigabit Ethernet/ATM broadband network designs, as shown in Figures 2 and 3, the need to increase the maximum transmit and receive unit in the PPPoE protocol is becoming more important in order to reduce fragmentation in the network.
随着宽带网络设计从以太/异步传输模式（ATM）组合设置中的PC启动PPPoE[1]会话（如图1所示）转变为更智能的支持PPPoE的住宅网关（RG）和千兆以太网/ATM宽带网络设计（如图2和3所示），为了减少网络中的碎片，增加PPPoE协议中最大发送和接收单元的需求变得越来越重要。
<------------------ PPPoE session ------------------>
<------------------ PPPoE session ------------------>
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------|CPE|-----------|DSLAM|-----------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <ATM> | |
+-----+ +-----+
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------|CPE|-----------|DSLAM|-----------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <ATM> | |
+-----+ +-----+
Figure 1. Initial broadband network designs with PPPoE
图1。PPPoE宽带网络的初步设计
In the network design shown in Figure 1, fragmentation is typically not a problem, since the subscriber session is PPPoE end to end from the PC to the BRAS. Therefore, a PPP-negotiated MRU of 1492 octets is fully acceptable, as it makes the largest PPPoE frame adhere to the standard Ethernet MTU of 1500 octets.
在图1所示的网络设计中，碎片通常不是问题，因为用户会话是从PC到BRAS的PPPoE端到端。因此，1492个八位字节的PPP协商MRU是完全可以接受的，因为它使最大的PPPoE帧符合1500个八位字节的标准以太网MTU。
<----- IPoE -----> <--------- PPPoE session --------->
<----- IPoE -----> <--------- PPPoE session --------->
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|-----------|DSLAM|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|-----------|DSLAM|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
Figure 2. Next-generation broadband network designs with PPPoE
图2。基于PPPoE的下一代宽带网络设计
In the network design shown in Figure 2, fragmentation becomes a major problem, since the subscriber session is a combination of IPoE and PPPoE. The IPoE typically uses a Maximum Transit Unit (MTU) of 1500 octets. However, when the Residential Gateway and the Broadband Remote Access Server (BRAS) are the PPPoE session endpoints and therefore negotiate an MTU/MRU of 1492 octets, the result is a large number of fragmented packets in the network.
在图2所示的网络设计中，碎片成为一个主要问题，因为用户会话是IPoE和PPPoE的组合。IPoE通常使用1500个八位字节的最大传输单元（MTU）。然而，当住宅网关和宽带远程访问服务器（BRA）是PPPoE会话端点，因此协商1492个八位字节的MTU/MRU时，结果是网络中存在大量碎片数据包。
<----- IPoE -----> <---- PPPoA ----> <- PPPoE session ->
<----- IPoE -----> <---- PPPoA ----> <- PPPoE session ->
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|------------|DSLAM|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------| RG|------------|DSLAM|------------| BRAS|
+--+ <Ethernet> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
<-------------- PPPoA -------------> <- PPPoE session ->
<-------------- PPPoA -------------> <- PPPoE session ->
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------|CPE|------------|DSLAM|------------| BRAS|
+--+ <ATM> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
+-----+ +-----+
+--+ +---+ | | | |
|PC|--------------|CPE|------------|DSLAM|------------| BRAS|
+--+ <ATM> +---+ <ATM> | | <GigE> | |
+-----+ +-----+
Figure 3. Broadband network designs with PPPoA-to-PPPoE conversion
图3。PPPoA到PPPoE转换的宽带网络设计
In the network design shown in Figure 3, which is studied by the DSL-Forum in the context of the migration to Ethernet for broadband aggregation networks, fragmentation is not the only problem when MRU differences exist in Point-to-Point Protocol over AAL5 (PPPoA) and PPPoE sessions.
在图3所示的网络设计中，DSL论坛在宽带聚合网络向以太网迁移的背景下对其进行了研究，当AAL5（PPPoA）和PPPoE会话上的点对点协议存在MRU差异时，碎片不是唯一的问题。
The subscriber session is a PPP session running over a combination of PPPoA and PPPoE. The PPP/PPPoA host typically negotiates a 1500- octet MRU. Widely deployed PPP/PPPoA hosts in Customer Premises Equipment (CPE) do not support a 1492-octet MRU, which creates an issue in turn for the BRAS (PPPoE server) if strict compliance to RFC
订户会话是通过PPPoA和PPPoE的组合运行的PPP会话。PPP/PPPoA主机通常协商一个1500字节的MRU。在客户场所设备（CPE）中广泛部署的PPP/PPPoA主机不支持1492八位组MRU，如果严格遵守RFC，这反过来会给BRA（PPPoE服务器）带来问题
2516 [1] is mandated. For PPP/PPPoA hosts capable of negotiating a 1492-octet MRU size, then we are back to a fragmentation issue.
2516[1]是强制性的。对于能够协商1492个八位组MRU大小的PPP/PPPoA主机，我们又回到了碎片问题。
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 RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
ATM - Asynchronous Transfer Mode PPP - Point-to-Point Protocol PPPoA - PPP over AAL5 PPPoE - PPP over Ethernet MTU - Maximum Transmit Unit MRU - Maximum Receive Unit PC - Personal Computer CPE - Customer Premises Equipment RG - Residential Gateway BRAS - Broadband Remote Access Server DSLAM - Digital Subscriber Line Access Multiplexer PPPoE - client PC, RG, or CPE that initiates a PPPoE session PPPoE - server BRAS terminating PPPoE sessions initiated by client PADI - PPPoE Active Discovery Initiation PADO - PPPoE Active Discovery Offer PADR - PPPoE Active Discovery Request PADS - PPPoE Active Discovery Session-confirmation
ATM-异步传输模式PPP-点对点协议PPPoA-AAL5 PPPPOE上的PPP-以太网MTU上的PPP-最大传输单元MRU-最大接收单元PC-个人计算机CPE-客户场所设备RG-住宅网关BRAS-宽带远程访问服务器DSLAM-数字用户线路访问多路复用器PPPPOE-启动PPPoE会话的客户端PC、RG或CPE PPPoE-服务器BRA终止客户端PADI启动的PPPoE会话-PPPoE主动发现启动PADO-PPPoE主动发现提供PADR-PPPoE主动发现请求PADS-PPPoE主动发现会话确认
The procedure described in this document does not strictly conform to IEEE standards for Ethernet packet size but relies on a widely deployed behavior of supporting frames with Ethernet packet format, but exceeding the maximum packet lengths defined by [4].
本文件中描述的程序不严格符合IEEE以太网数据包大小标准，但依赖于广泛部署的以太网数据包格式支持帧的行为，但超过了[4]定义的最大数据包长度。
Since next-generation broadband networks are built around Ethernet systems supporting baby-giants and jumbo frames with payload sizes larger than the normal Ethernet MTU of 1500 octets, a BRAS acting as a PPPoE server MUST support PPPoE MRU negotiations larger than 1492 octets in order to limit the amount of fragmented packets in networks similar to those described in Section 1.
由于下一代宽带网络是围绕支持巨型婴儿和巨型帧的以太网系统构建的，其有效负载大小大于1500个八位字节的普通以太网MTU，充当PPPoE服务器的BRA必须支持大于1492个八位字节的PPPoE MRU协商，以限制网络中的碎片数据包数量，类似于第1节所述。
By default, the Maximum-Receive-Unit (MRU) option MUST follow the rules set forward in RFC 1661 [2] but MUST NOT be negotiated to a size larger than 1492 to guarantee compatibility with Ethernet network segments limited to 1500-octet frames. In such a case, as the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MRU MUST NOT be greater than 1492.
默认情况下，最大接收单元（MRU）选项必须遵循RFC 1661[2]中提出的规则，但不得协商为大于1492的大小，以保证与限制为1500个八位字节帧的以太网网段的兼容性。在这种情况下，由于PPPoE报头为6个八位字节，PPP协议ID为2个八位字节，PPP MRU不得大于1492。
An optional PPPoE tag, "PPP-Max-Payload", allows a PPPoE client to override this default behavior by providing a maximum size for the PPP payload it can support in both the sending and receiving directions. When such a tag is received by the PPPoE server, the server MAY allow the negotiation of an MRU larger than 1492 and the use of an MTU larger than 1492, subject to limitations of its local configuration and according to the rules set forward in RFC 1661 [2], within the limits of the maximum payload size indicated by the PPPoE client.
可选的PPPoE标记“PPP最大有效负载”允许PPPoE客户端通过提供其在发送和接收方向上都能支持的PPP有效负载的最大大小来覆盖此默认行为。当PPPoE服务器接收到这样的标签时，服务器可允许在PPPoE客户端指示的最大有效负载大小的限制内，根据其本地配置的限制并根据RFC 1661[2]中提出的规则，协商大于1492的MRU并使用大于1492的MTU。
If a PPPoE client wants to use an MTU/MRU higher than 1492 octets, then it MUST include an optional PPP-Max-Payload Tag in the PADI and PADR packets. If the PPPoE server can support an MTU/MRU higher than 1492 octets, it MUST respond with an echo of the clients tag in the PADO and PADS packets when the PPP-Max-Payload tag is received from the client.
如果PPPoE客户端希望使用高于1492个八位字节的MTU/MRU，则必须在PADI和PADR数据包中包含可选的PPP最大有效负载标签。如果PPPoE服务器可以支持高于1492个八位字节的MTU/MRU，则当从客户端接收到PPP最大有效负载标记时，它必须在PADO和PADS数据包中以客户端标记的回声进行响应。
Tag-name: PPP-Max-Payload Tag-value: 0x0120 Tag-length: 2 octets Tag-value: binary encoded value (max PPP payload in octets)
标记名称：PPP最大有效负载标记值：0x0120标记长度：2个八位字节标记值：二进制编码值（最大PPP有效负载以八位字节为单位）
Tag-description: This TAG indicates that the client and server are capable of supporting a given maximum PPP payload greater than 1492 octets for both the sending and receiving directions. Note that this value represents the PPP payload; therefore it is directly comparable with the value used in the PPP MRU negotiation.
标记说明：此标记表示客户端和服务器能够支持发送和接收方向上大于1492个八位字节的给定最大PPP负载。注意，该值表示PPP有效载荷；因此，它与PPP MRU谈判中使用的价值直接可比。
Since Ethernet (without jumbo frames) has a maximum payload size of 1500 octets, the PPPoE header is 6 octets, and the PPP Protocol ID is 2 octets, the Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a size larger than 1492, unless both the PPPoE client and server have indicated the ability to support a larger MRU in the PPPoE Discovery Stage.
由于以太网（无巨型帧）的最大有效负载大小为1500个八位字节，PPPoE报头为6个八位字节，PPP协议ID为2个八位字节，因此最大接收单元（MRU）选项的协商大小不得大于1492，除非PPPoE客户端和服务器都表明能够在PPPoE发现阶段支持更大的MRU。
The initial MRU negotiation for the PPP/PPPoE server MUST follow a flow as shown below:
PPP/PPPoE服务器的初始MRU协商必须遵循如下所示的流程：
If PPPoE {
PPP_MRU_Max = 1492
If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492)
Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)
}
"Normal" PPP_MRU_Negotiation (PPP_MRU_Max)
If PPPoE {
PPP_MRU_Max = 1492
If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492)
Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)
}
"Normal" PPP_MRU_Negotiation (PPP_MRU_Max)
If the PPP-Max-Payload tag is present and greater than 1492, it MUST be considered along with the server's interface MTU settings when the maximum value is selected for the normal RFC 1661 [2] MRU negotiation which decides the actual MRU to use.
如果PPP最大有效载荷标签存在且大于1492，则在为正常RFC 1661[2]MRU协商选择最大值时，必须将其与服务器的接口MTU设置一起考虑，该协商决定实际使用的MRU。
If the PPP-Max-Payload tag isn't present or is present but below 1492, then the existing MRU constraint of 1492 octets MUST stay applicable, thus preserving backward compatibility.
如果PPP最大有效负载标签不存在或存在，但低于1492，则1492个八位字节的现有MRU约束必须保持适用，从而保持向后兼容性。
This, in summary, indicates the following behavior:
总之，这表明以下行为：
1. When a "PPP-Max-Payload" tag is received,
1. 当收到“PPP最大有效载荷”标签时，
a. the value in this tag will indicate the maximum MRU allowed to be accepted or suggested in an MRU negotiation; and
a. 此标签中的值将指示MRU谈判中允许接受或建议的最大MRU；和
b. if MRU is not negotiated, then RFC 1661 [2] will set the default MRU at 1500. This will say that the "PPP-Max-Payload" tag can have a value greater than 1500, but in this case RFC 1661 [2] sets the default MRU to 1500, and only if MRU is negotiated higher (up to maximum payload) will the "PPP-Max-Payload" tag value be used.
b. 如果MRU未协商，则RFC 1661[2]将默认MRU设置为1500。这意味着“PPP最大有效载荷”标签的值可以大于1500，但在这种情况下，RFC 1661[2]将默认MRU设置为1500，并且只有当MRU协商得更高（最大有效载荷）时，才会使用“PPP最大有效载荷”标签值。
2. When a "PPP-Max-Payload" tag is not received by either end, then RFC 2516 [1] sets the rule.
2. 当任何一端都没有收到“PPP最大有效负载”标记时，RFC 2516[1]设置规则。
If the MRU is negotiated to a value larger than 1492 octets, the sending side SHOULD have the option of sending one or more MRU-sized Echo-Request packets once the session is opened. This allows it to test that the receiving side and any intermediate Ethernet segments and equipment can handle such a packet size.
如果MRU协商的值大于1492个八位字节，则发送端应具有在会话打开后发送一个或多个MRU大小的回显请求数据包的选项。这允许它测试接收端和任何中间以太网段和设备是否能够处理这样的数据包大小。
If no Echo-Replies are received, the sending side MAY choose to repeat the test with 1492 octets Echo-Request packets. If these packets receive replies, the sending side MUST not send packets bigger than 1492 octets for this session.
如果未收到回音回复，发送端可选择使用1492个八位字节回音请求数据包重复测试。如果这些数据包收到回复，发送端不得为此会话发送大于1492个八位字节的数据包。
This capability SHOULD be enabled by default. It SHOULD be configurable and MAY be disabled on networks where there is some prior knowledge indicating that the test is not necessary.
默认情况下应启用此功能。它应该是可配置的，并且可以在网络上禁用，其中有一些先验知识表明测试是不必要的。
This document does not introduce new security issues. The security considerations pertaining to the original PPPoE protocol [1] remain relevant.
本文档不会引入新的安全问题。与原始PPPoE协议[1]相关的安全注意事项仍然相关。
This document defines a new value in a space that currently has no IANA registry. There is work in progress to define a registry [5] and that document already contains the value assigned here. No IANA action is required for this document.
本文档在当前没有IANA注册表的空间中定义了一个新值。正在进行定义注册表[5]的工作，并且该文档已包含此处指定的值。本文件无需IANA操作。
The authors would like to thank Prakash Jayaraman, Amit Cohen, Jim Ellis, David Thorne, John Reid, Oliver Thorp, Wojciech Dec, Jim Wilks, Mark Townsley, Bart Salaets, Tom Mistretta, Paul Howard, Dave Bernard, and Darren Nobel for their contributions and comments to this document.
作者感谢Prakash Jayaraman、Amit Cohen、Jim Ellis、David Thorne、John Reid、Oliver Thorp、Wojciech Dec、Jim Wilks、Mark Townsley、Bart Salaets、Tom Remetta、Paul Howard、Dave Bernard和Darren Nobel对本文件的贡献和评论。
[1] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[1] Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.，和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[2] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[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] Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2005, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Draft amendment to - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters", December 2005.
[4] 电气和电子工程师协会，IEEE标准802.3-2005，“带冲突检测的载波侦听多址接入IEEE标准（CSMA/CD）存取方法和物理层规范.信息技术.系统间远程通信和信息交换.局域网和城域网.特殊要求.第3部分：带冲突检测的载波侦听多路存取（CSMA/CD）访问方法和物理层规范-媒体访问控制参数、物理层和管理参数”，2005年12月。
[5] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over Ethernet (PPPoE), Work in Progress, June 2006.
[5] Arberg，P.和V.Mammoliti，“IANA对以太网PPP（PPPoE）的考虑”，正在进行的工作，2006年6月。
Authors' Addresses
作者地址
Peter Arberg Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Peter Arberg Redback Networks，Inc.加利福尼亚州圣何塞霍尔格大道300号，邮编95134
EMail: parberg@redback.com
EMail: parberg@redback.com
Diamantis Kourkouzelis Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Diamantis Kourkouzelis Redback Networks，Inc.加利福尼亚州圣何塞霍尔格大道300号，邮编95134
EMail: diamondk@redback.com
EMail: diamondk@redback.com
Mike Duckett BellSouth Telecommunications, Inc. 575 Morosgo Drive Atlanta, GA 30324
Mike Duckett BellsSouth Telecommunications，Inc.位于佐治亚州亚特兰大莫洛斯哥大道575号，邮编30324
EMail: mike.duckett@bellsouth.com
EMail: mike.duckett@bellsouth.com
Tom Anschutz BellSouth Science and Technology 725 W. Peachtree St. Atlanta, GA 30308
Tom Anschutz BellSouth科技公司乔治亚州亚特兰大桃树街西725号，邮编30308
EMail: tom.anschutz@bellsouth.com
EMail: tom.anschutz@bellsouth.com
Jerome Moisand Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886
Jerome Moisand Juniper Networks，Inc.马萨诸塞州韦斯特福德科技园大道10号，邮编01886
EMail: jmoisand@juniper.net
EMail: jmoisand@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。