Network Working Group S. Hollenbeck
Request for Comments: 3734 VeriSign, Inc.
Category: Standards Track March 2004
Network Working Group S. Hollenbeck
Request for Comments: 3734 VeriSign, Inc.
Category: Standards Track March 2004
Extensible Provisioning Protocol (EPP) Transport Over TCP
TCP上的可扩展资源调配协议（EPP）传输
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server.
本文档描述如何将可扩展资源调配协议（EPP）会话映射到单个传输控制协议（TCP）连接。此映射需要使用传输层安全性（TLS）协议来保护EPP客户端和EPP服务器之间交换的信息。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document. . . . . . . . . . . . 2
2. Session Management . . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Considerations . . . . . . . . . . . . . . . . . . . 5
6. Internationalization Considerations. . . . . . . . . . . . . . 6
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References. . . . . . . . . . . . . . . . . . 7
10.2. Informative References. . . . . . . . . . . . . . . . . 8
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document. . . . . . . . . . . . 2
2. Session Management . . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Considerations . . . . . . . . . . . . . . . . . . . 5
6. Internationalization Considerations. . . . . . . . . . . . . . 6
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References. . . . . . . . . . . . . . . . . . 7
10.2. Informative References. . . . . . . . . . . . . . . . . 8
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
This document describes how the Extensible Provisioning Protocol (EPP) is mapped onto a single client-server TCP connection. Security services beyond those defined in EPP are provided by the Transport Layer Security (TLS) Protocol [RFC2246]. EPP is described in [RFC3730]. TCP is described in [RFC793].
本文档描述如何将可扩展资源调配协议（EPP）映射到单个客户机-服务器TCP连接。EPP中定义的安全服务以外的安全服务由传输层安全（TLS）协议[RFC2246]提供。[RFC3730]中描述了EPP。[RFC793]中描述了TCP。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Mapping EPP session management facilities onto the TCP service is straight forward. An EPP session first requires creation of a TCP connection between two peers, one that initiates the connection request and one that responds to the connection request. The initiating peer is called the "client", and the responding peer is called the "server". An EPP server MUST listen for TCP connection requests on a standard TCP port assigned by IANA.
将EPP会话管理设施映射到TCP服务是很简单的。EPP会话首先需要在两个对等方之间创建TCP连接，一个启动连接请求，另一个响应连接请求。发起方称为“客户机”，响应方称为“服务器”。EPP服务器必须在IANA分配的标准TCP端口上侦听TCP连接请求。
The client MUST issue an active OPEN call, specifying the TCP port number on which the server is listening for EPP connection attempts. The server MUST respond with a passive OPEN call, which the client MUST acknowledge to establish the connection. The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established.
客户端必须发出活动的OPEN调用，指定服务器正在侦听EPP连接尝试的TCP端口号。服务器必须响应被动打开调用，客户端必须确认该调用才能建立连接。TCP会话建立后，EPP服务器必须向客户端返回EPP<greeting>。
An EPP session is normally ended by the client issuing an EPP <logout> command. A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection through an active CLOSE call. The client MUST respond with a passive CLOSE call.
EPP会话通常由客户端发出EPP<logout>命令来结束。接收EPP<logout>命令的服务器必须结束EPP会话，并通过活动的close调用关闭TCP连接。客户端必须以被动关闭呼叫进行响应。
A client MAY end an EPP session by issuing an active CLOSE call. A server SHOULD respond with a passive CLOSE call.
客户端可以通过发出活动的关闭调用来结束EPP会话。服务器应以被动关闭调用进行响应。
A server MAY limit the life span of an established TCP connection. EPP sessions that are inactive for more than a server-defined period MAY be ended by a server issuing an active CLOSE call. A server MAY also close TCP connections that have been open and active for longer than a server-defined period.
服务器可能会限制已建立TCP连接的寿命。超过服务器定义的时间段处于非活动状态的EPP会话可能会由服务器发出活动关闭调用而结束。服务器还可以关闭已打开并处于活动状态超过服务器定义时间的TCP连接。
Peers SHOULD respond to an active CLOSE call with a passive CLOSE call. The closing peer MAY issue an ABORT call if the responding peer does not respond to the active CLOSE call.
对等方应以被动关闭呼叫响应主动关闭呼叫。如果响应的对等方没有响应活动的关闭调用，关闭的对等方可以发出中止调用。
With the exception of the EPP server greeting, EPP messages are initiated by the EPP client in the form of EPP commands. An EPP server MUST return an EPP response to an EPP command on the same TCP connection that carried the command. If the TCP connection is closed after a server receives and successfully processes a command but before the response can be returned to the client, the server MAY attempt to undo the effects of the command to ensure a consistent state between the client and the server. EPP commands are idempotent, so processing a command more than once produces the same net effect on the repository as successfully processing the command once.
除EPP服务器问候语外，EPP消息由EPP客户端以EPP命令的形式启动。EPP服务器必须在承载该命令的同一TCP连接上返回对EPP命令的EPP响应。如果TCP连接在服务器接收并成功处理命令后，但在响应返回到客户端之前关闭，则服务器可能会尝试撤消命令的效果，以确保客户端和服务器之间的状态一致。EPP命令是幂等的，因此多次处理命令会在存储库中产生与成功处理命令一次相同的净效果。
An EPP client streams EPP commands to an EPP server on an established TCP connection. A client MAY but SHOULD NOT establish multiple TCP connections to create multiple command exchange channels. A server SHOULD limit a client to a maximum number of TCP connections based on server capabilities and operational load.
EPP客户端通过已建立的TCP连接将EPP命令流式传输到EPP服务器。客户端可以但不应该建立多个TCP连接来创建多个命令交换通道。服务器应根据服务器功能和操作负载将客户端限制为最大TCP连接数。
EPP describes client-server interaction as a command-response exchange where the client sends one command to the server and the server returns one response to the client. A client might be able to realize a slight performance gain by pipelining (sending more than one command before a response for the first command is received) commands with TCP transport, but this feature does not change the basic single command, single response operating mode of the core protocol. The amount of data that can be outstanding is limited to the current TCP window size.
EPP将客户机-服务器交互描述为命令-响应交换，其中客户机向服务器发送一个命令，服务器向客户机返回一个响应。客户机可能能够通过TCP传输管道化（在接收到第一个命令的响应之前发送多个命令）命令来实现轻微的性能提升，但此功能不会改变核心协议的基本单命令、单响应操作模式。未完成的数据量仅限于当前TCP窗口大小。
Each EPP data unit MUST contain a single EPP message. Commands MUST be processed independently and in the same order as sent from the client.
每个EPP数据单元必须包含一条EPP消息。命令必须独立处理，处理顺序与从客户端发送的顺序相同。
A server SHOULD impose a limit on the amount of time required for a client to issue a well-formed EPP command. A server SHOULD end an EPP session and close an open TCP connection if a well-formed command is not received within the time limit.
服务器应限制客户端发出格式良好的EPP命令所需的时间。如果在时间限制内未收到格式良好的命令，服务器应结束EPP会话并关闭打开的TCP连接。
A general state machine for an EPP server is described in section 2 of [RFC3730]. General client-server message exchange using TCP transport is illustrated in Figure 1.
[RFC3730]第2节描述了EPP服务器的通用状态机。使用TCP传输的通用客户机-服务器消息交换如图1所示。
Client Server
| |
| Connect |
| >>------------------------------->> |
| |
| Send Greeting |
| <<-------------------------------<< |
| |
| Send <login> |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command X |
| >>------------------------------->> |
| |
| Send Command Y |
| >>---------------+ |
| | |
| | |
| Send Response X |
| <<---------------(---------------<< |
| | |
| | |
| +--------------->> |
| |
| Send Response Y |
| <<-------------------------------<< |
| |
| Send <logout> |
| >>------------------------------->> |
| |
| Send Response & Disconnect |
| <<-------------------------------<< |
| |
Client Server
| |
| Connect |
| >>------------------------------->> |
| |
| Send Greeting |
| <<-------------------------------<< |
| |
| Send <login> |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command X |
| >>------------------------------->> |
| |
| Send Command Y |
| >>---------------+ |
| | |
| | |
| Send Response X |
| <<---------------(---------------<< |
| | |
| | |
| +--------------->> |
| |
| Send Response Y |
| <<-------------------------------<< |
| |
| Send <logout> |
| >>------------------------------->> |
| |
| Send Response & Disconnect |
| <<-------------------------------<< |
| |
Figure 1: TCP Client-Server Message Exchange
图1:TCP客户机-服务器消息交换
The data field of the TCP header MUST contain an EPP data unit. The EPP data unit contains two fields: a 32-bit header that describes the total length of the data unit, and the EPP XML instance.
TCP标头的数据字段必须包含EPP数据单元。EPP数据单元包含两个字段：描述数据单元总长度的32位标头和EPP XML实例。
EPP Data Unit Format (one tick mark represents one bit position):
EPP数据单元格式（一个记号表示一位位置）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EPP XML Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EPP XML Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Total Length (32 bits): The total length of the EPP data unit measured in octets in network (big endian) byte order. The octets contained in this field MUST be included in the total length calculation.
总长度（32位）：EPP数据单元的总长度，以网络（大端）字节顺序的八位字节为单位。此字段中包含的八位字节必须包含在总长度计算中。
EPP XML Instance (variable length): The EPP XML instance carried in the data unit.
EPP XML实例（可变长度）：数据单元中携带的EPP XML实例。
Section 2.1 of the EPP core protocol specification [RFC3730] describes considerations to be addressed by protocol transport mappings. This mapping addresses each of the considerations using a combination of features described in this document and features provided by TCP as follows:
EPP核心协议规范[RFC3730]第2.1节描述了协议传输映射需要考虑的事项。此映射使用本文档中描述的功能和TCP提供的功能的组合来解决每个注意事项，如下所示：
- TCP includes features to provide reliability, flow control, ordered delivery, and congestion control. Section 1.5 of RFC 793 [RFC793] describes these features in detail; congestion control principles are described further in RFC 2581 [RFC2581] and RFC 2914 [RFC2914]. TCP is a connection-oriented protocol, and Section 2 of this mapping describes how EPP sessions are mapped to TCP connections.
- TCP包括提供可靠性、流量控制、有序交付和拥塞控制的功能。RFC 793[RFC793]第1.5节详细描述了这些特性；RFC 2581[RFC2581]和RFC 2914[RFC2914]中进一步描述了拥塞控制原理。TCP是一种面向连接的协议，本映射的第2节描述了如何将EPP会话映射到TCP连接。
- Sections 2 and 3 of this mapping describe how the stateful nature of EPP is preserved through managed sessions and controlled message exchanges.
- 该映射的第2节和第3节描述了如何通过托管会话和受控消息交换来保持EPP的状态性质。
- Section 3 of this mapping notes that command pipelining is possible with TCP, though batch-oriented processing (combining multiple EPP commands in a single data unit) is not permitted.
- 此映射的第3节指出，命令管道可以通过TCP实现，但不允许面向批处理的处理（在单个数据单元中组合多个EPP命令）。
- Section 4 of this mapping describes features to frame data units by explicitly specifying the number of octets used to represent a data unit.
- 此映射的第4节通过明确指定用于表示数据单元的八位字节数来描述帧数据单元的功能。
This mapping does not introduce or present any internationalization or localization issues.
此映射不会引入或呈现任何国际化或本地化问题。
System port number 700 has been assigned by the IANA for mapping EPP onto TCP.
IANA已分配系统端口号700，用于将EPP映射到TCP。
User port number 3121 (which was used for development and test purposes) has been reclaimed by the IANA.
IANA已回收用户端口号3121（用于开发和测试目的）。
EPP as-is provides only simple client authentication services using identifiers and plain text passwords. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial command forgery. Protection against most other common attacks MUST be provided by other layered protocols.
EPP原样仅提供使用标识符和纯文本密码的简单客户端身份验证服务。被动攻击足以恢复客户端标识符和密码，从而允许少量命令伪造。针对大多数其他常见攻击的保护必须由其他分层协议提供。
EPP provides protection against replay attacks through command idempotency. A replayed or repeated command will not change the state of any object in any way, though denial of service through consumption of connection resources is a possibility.
EPP通过命令幂等性提供防止重播攻击的保护。重播或重复的命令不会以任何方式改变任何对象的状态，但也可能通过消耗连接资源来拒绝服务。
When layered over TCP, the Transport Layer Security (TLS) Protocol described in [RFC2246] MUST be used to prevent eavesdropping, tampering, and command forgery attacks. Implementations of TLS often contain a US-exportable cryptographic mode that SHOULD NOT be used to protect EPP. Clients and servers desiring high security SHOULD instead use TLS with cryptographic algorithms that are less susceptible to compromise.
在TCP上分层时，必须使用[RFC2246]中描述的传输层安全（TLS）协议来防止窃听、篡改和命令伪造攻击。TLS的实现通常包含不应用于保护EPP的美国可导出加密模式。需要高安全性的客户机和服务器应改为使用TLS和不易被破坏的加密算法。
Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED. Signatures on the complete certificate chain for both client machine and server machine MUST be validated as part of the TLS handshake. Information included in the client and server certificates, such as validity periods and machine names, MUST also be validated. EPP service MUST NOT be granted until successful
需要使用TLS握手协议进行客户端和服务器的相互身份验证。客户端计算机和服务器计算机的完整证书链上的签名必须作为TLS握手的一部分进行验证。还必须验证客户端和服务器证书中包含的信息，如有效期和计算机名称。在成功之前不得授予EPP服务
completion of a TLS handshake and certificate validation, ensuring that both the client machine and the server machine have been authenticated and cryptographic protections are in place.
完成TLS握手和证书验证，确保客户端计算机和服务器计算机都已通过身份验证，并且密码保护已到位。
Authentication using the TLS Handshake Protocol confirms the identity of the client and server machines. EPP uses an additional client identifier and password to identify and authenticate the client's user identity to the server, supplementing the machine authentication provided by TLS. The identity described in the client certificate and the identity described in the EPP client identifier can differ, as a server can assign multiple user identities for use from any particular client machine.
使用TLS握手协议的身份验证确认客户端和服务器机器的身份。EPP使用一个附加的客户端标识符和密码来向服务器标识和验证客户端的用户身份，以补充TLS提供的机器身份验证。客户端证书中描述的标识和EPP客户端标识符中描述的标识可能不同，因为服务器可以分配多个用户标识，以便从任何特定的客户端计算机使用。
EPP TCP servers are vulnerable to common TCP denial of service attacks including TCP SYN flooding. Servers SHOULD take steps to minimize the impact of a denial of service attack using combinations of easily implemented solutions, such as deployment of firewall technology and border router filters to restrict inbound server access to known, trusted clients.
EPP TCP服务器容易受到常见的TCP拒绝服务攻击，包括TCP SYN洪泛攻击。服务器应采取措施，结合使用易于实施的解决方案（如部署防火墙技术和边界路由器过滤器）将拒绝服务攻击的影响降至最低，以限制对已知可信客户端的入站服务器访问。
This document was originally written as an individual submission Internet-Draft. The provreg working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
本文件最初是作为个人提交的互联网草案编写的。provreg工作组后来将其作为工作组文件通过，并提出了许多宝贵的意见和改进建议。作者希望感谢工作组主席Edward Lewis和Jaap Akkerhuis的工作过程和编辑贡献。
Specific suggestions that have been incorporated into this document were provided by Chris Bason, Randy Bush, Patrik Faltstrom, Ned Freed, James Gould, Dan Manley, and John Immordino.
Chris Bason、Randy Bush、Patrik Faltstrom、Ned Freed、James Gould、Dan Manley和John Immordino提供了纳入本文件的具体建议。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[RFC3730]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，RFC3730，2004年3月。
None
没有一个
Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Scott Hollenbeck VeriSign全球注册服务21345 Ridgetop Circle Dulles，弗吉尼亚州20166-6503美国
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。