Network Working Group S. Park
Request for Comments: 4039 P. Kim
Category: Standards Track SAMSUNG Electronics
B. Volz
Cisco Systems
March 2005
Network Working Group S. Park
Request for Comments: 4039 P. Kim
Category: Standards Track SAMSUNG Electronics
B. Volz
Cisco Systems
March 2005
Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)
动态主机配置协议版本4（DHCPv4）的快速提交选项
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration.
本文档定义了一个新的动态主机配置协议版本4（DHCPv4）选项，该选项以DHCPv6快速提交选项为模型，用于使用2消息交换而不是通常的4消息交换来获取IP地址和配置信息，从而加快客户端配置。
Table of Contents
目录
1. Introduction................................................... 2
2. Requirements................................................... 2
3. Client/Server Operations....................................... 2
3.1. Detailed Flow............................................ 3
3.2. Administrative Considerations............................ 6
4. Rapid Commit Option Format..................................... 7
5. IANA Considerations............................................ 7
6. Security Considerations........................................ 7
7. References..................................................... 7
7.1. Normative References..................................... 7
7.2. Informative References................................... 8
8. Acknowledgements............................................... 8
Authors' Addresses................................................ 9
Full Copyright Statement.......................................... 10
1. Introduction................................................... 2
2. Requirements................................................... 2
3. Client/Server Operations....................................... 2
3.1. Detailed Flow............................................ 3
3.2. Administrative Considerations............................ 6
4. Rapid Commit Option Format..................................... 7
5. IANA Considerations............................................ 7
6. Security Considerations........................................ 7
7. References..................................................... 7
7.1. Normative References..................................... 7
7.2. Informative References................................... 8
8. Acknowledgements............................................... 8
Authors' Addresses................................................ 9
Full Copyright Statement.......................................... 10
In some environments, such as those in which high mobility occurs and the network attachment point changes frequently, it is beneficial to rapidly configure clients. And, in these environments it is possible to more quickly configure clients because the protections offered by the normal (and longer) 4-message exchange may not be needed. The 4-message exchange allows for redundancy (multiple DHCP servers) without wasting addresses, as addresses are only provisionally assigned to a client until the client chooses and requests one of the provisionally assigned addresses. The 2-message exchange may therefore be used when only one server is present or when addresses are plentiful and having multiple servers commit addresses for a client is not a problem.
在某些环境中，例如发生高移动性和网络连接点频繁变化的环境中，快速配置客户端是有益的。而且，在这些环境中，可以更快地配置客户端，因为可能不需要正常（或更长）4消息交换提供的保护。4消息交换允许冗余（多个DHCP服务器），而不会浪费地址，因为在客户端选择并请求其中一个临时分配的地址之前，地址仅临时分配给客户端。因此，当只有一台服务器存在，或者当地址充足且一个客户端有多个服务器提交地址不是问题时，可以使用双消息交换。
This document defines a new Rapid Commit option for DHCPv4, modeled on the DHCPv6 Rapid Commit option [RFC3315], which can be used to initiate a 2-message exchange to expedite client configuration in some environments. A client advertises its support of this option by sending it in DHCPDISCOVER messages. A server then determines whether to allow the 2-message exchange based on its configuration information and can either handle the DHCPDISCOVER as defined in [RFC2131] or commit the client's configuration information and advance to sending a DHCPACK message with the Rapid Commit option as defined herein.
本文档为DHCPv4定义了一个新的快速提交选项，该选项以DHCPv6快速提交选项[RFC3315]为模型，可用于启动2消息交换，以加快某些环境中的客户端配置。客户端通过在DHCPDISCOVER消息中发送此选项来宣传其对该选项的支持。然后，服务器根据其配置信息确定是否允许2-消息交换，并且可以处理[RFC2131]中定义的DHCPDISCOVER，或者提交客户端的配置信息，并使用本文定义的快速提交选项发送DHCPACK消息。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释。
If a client that supports the Rapid Commit option intends to use the rapid commit capability, it includes a Rapid Commit option in DHCPDISCOVER messages that it sends. The client MUST NOT include it in any other messages. A client and server only use this option when configured to do so.
如果支持快速提交选项的客户机打算使用快速提交功能，则在其发送的DHCPDISCOVER消息中包含快速提交选项。客户端不得将其包含在任何其他消息中。客户端和服务器仅在配置为使用此选项时才使用此选项。
A client that sent a DHCPDISCOVER with Rapid Commit option processes responses as described in [RFC2131]. However, if the client receives a DHCPACK message with a Rapid Commit option, it SHOULD process the DHCPACK immediately (without waiting for additional DHCPOFFER or DHCPACK messages) and use the address and configuration information contained therein.
发送带有快速提交选项的DHCPDISCOVER的客户端处理响应，如[RFC2131]中所述。但是，如果客户机接收到带有快速提交选项的DHCPACK消息，则应立即处理DHCPACK（无需等待其他DHCPOFFER或DHCPACK消息），并使用其中包含的地址和配置信息。
A server that supports the Rapid Commit option MAY respond to a DHCPDISCOVER message that included the Rapid Commit option with a DHCPACK that includes the Rapid Commit option and fully committed address and configuration information. A server MUST NOT include the Rapid Commit option in any other messages.
支持快速提交选项的服务器可以使用包含快速提交选项和完全提交的地址和配置信息的DHCPACK来响应包含快速提交选项的DHCPDISCOVER消息。服务器不得在任何其他消息中包含快速提交选项。
The Rapid Commit option MUST NOT appear in a Parameter Request List option [RFC2132].
快速提交选项不得出现在参数请求列表选项[RFC2132]中。
All other DHCP operations are as documented in [RFC2131].
所有其他DHCP操作如[RFC2131]中所述。
The following is revised from Section 3.1 of [RFC2131], which includes handling of the Rapid Commit option.
以下是对[RFC2131]第3.1节的修订，其中包括快速提交选项的处理。
1. The client broadcasts a DHCPDISCOVER message on its local physical subnet. If the client supports the Rapid Commit option and intends to use the rapid commit capability, it includes a Rapid Commit option in the DHCPDISCOVER message. The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet.
1. 客户端在其本地物理子网上广播DHCPDISCOVER消息。如果客户端支持快速提交选项并打算使用快速提交功能，则它会在DHCPDISCOVER消息中包含一个快速提交选项。DHCPDISCOVER消息可能包括建议网络地址和租赁期限值的选项。BOOTP中继代理可以将消息传递到不在同一物理子网上的DHCP服务器。
2. Each server may respond with either a DHCPOFFER message or a DHCPACK message with the Rapid Commit option (the latter only if the DHCPDISCOVER contained a Rapid Commit option and the server's configuration policies allow use of Rapid Commit). These would include an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers sending a DHCPOFFER need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. Servers sending the DHCPACK message commit the binding for the client to persistent storage before sending the DHCPACK. The combination of 'client identifier' or 'chaddr' and assigned network address constitute a unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP messages. The server transmits the DHCPOFFER or DHCPACK message to the client, if necessary by using the BOOTP relay agent.
2. 每个服务器都可以使用DHCPOFFER消息或带有快速提交选项的DHCPACK消息进行响应（后者仅在DHCPDISCOVER包含快速提交选项且服务器的配置策略允许使用快速提交的情况下）。这些将包括“yiaddr”字段中的可用网络地址（以及DHCP选项中的其他配置参数）。发送DHCPOFFER的服务器不需要保留提供的网络地址，但如果服务器避免将提供的网络地址分配给另一个客户端，则协议将更有效地工作。发送DHCPACK消息的服务器在发送DHCPACK之前将客户端的绑定提交到持久性存储。“客户端标识符”或“chaddr”与分配的网络地址的组合构成客户端租约的唯一标识符，客户端和服务器都使用它来标识任何DHCP消息中引用的租约。如果需要，服务器使用BOOTP中继代理将DHCPOFFERE或DHCPACK消息传输到客户端。
When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request.
分配新地址时，服务器应检查提供的网络地址是否尚未使用；e、 例如，服务器可以使用ICMP回显请求探测提供的地址。
Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses.
应该实现服务器，以便网络管理员可以选择禁用对新分配地址的探测。
Figure 3 in [RFC2131] shows the flow for the normal 4-message exchange. Figure 1 below shows the 2-message exchange.
[RFC2131]中的图3显示了正常4消息交换的流程。下面的图1显示了双向消息交换。
Server Client Server (not selected) (selected)
服务器客户端服务器（未选择）（已选择）
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| w/Rapid Commit| w/Rapid Commit|
| | |
Determines | Determines
configuration | configuration
| | Commits configuration
| Collects replies |
|\ | ____________/|
| \________ | / DHCPACK |
| DHCPOFFER\ |/w/Rapid Commit|
| (discarded) | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\_____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| w/Rapid Commit| w/Rapid Commit|
| | |
Determines | Determines
configuration | configuration
| | Commits configuration
| Collects replies |
|\ | ____________/|
| \________ | / DHCPACK |
| DHCPOFFER\ |/w/Rapid Commit|
| (discarded) | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\_____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 1 Timeline diagram when Rapid Commit is used
图1使用快速提交时的时间线图
3. The client receives one or more DHCPOFFER or DHCPACK (if the Rapid Commit option is sent in DHCPDISCOVER) messages from one or more servers. If a DHCPACK (with the Rapid Commit option) is received, the client may immediately advance to step 5 below if the offered configuration parameters are acceptable. The client may choose to wait for multiple responses. The client chooses one server from which to request or accept
3. 客户端从一个或多个服务器接收一个或多个DHCPOFFER或DHCPACK（如果在DHCPDISCOVER中发送了快速提交选项）消息。如果接收到DHCPACK（带有快速提交选项），则如果提供的配置参数是可接受的，则客户端可以立即进入下面的步骤5。客户端可以选择等待多个响应。客户机选择一台服务器，从中请求或接受
configuration parameters, based on the configuration parameters offered in the DHCPOFFER and DHCPACK messages. If the client chooses a DHCPACK, it advances to step 5. Otherwise, the client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, the message MAY include other options specifying desired configuration values. The 'requested IP address' option MUST be set to the value of 'yiaddr' in the DHCPOFFER message from the server. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as was the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages.
配置参数，基于DHCPOFFER和DHCPACK消息中提供的配置参数。如果客户机选择DHCPACK，则进入步骤5。否则，客户端广播DHCPREQUEST消息，该消息必须包括“服务器标识符”选项，以指示其选择的服务器，该消息可能包括指定所需配置值的其他选项。在来自服务器的DHCPOFFER消息中，“请求的IP地址”选项必须设置为“yiaddr”值。此DHCPREQUEST消息通过DHCP/BOOTP中继代理进行广播和中继。为了帮助确保任何BOOTP中继代理将DHCPREQUEST消息转发到接收原始DHCPDISCOVER消息的同一组DHCP服务器，DHCPREQUEST消息必须使用DHCP消息头的“secs”字段中的相同值，并发送到与原始DHCPDISCOVER消息相同的IP广播地址。如果客户端未收到DHCPOFFER消息，则客户端将超时并重新传输DHCPDISCOVER消息。
4. The servers receive the DHCPREQUEST broadcast from the client. Servers not selected by the DHCPREQUEST message use the message as notification that the client has declined those servers' offers. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of 'client identifier' or 'chaddr' and assigned network address constitute a unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP messages. Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The server SHOULD NOT check the offered network address at this point. The 'yiaddr' field in the DHCPACK messages is filled in with the selected network address.
4. 服务器从客户端接收DHCPREQUEST广播。DHCPREQUEST消息未选择的服务器使用该消息作为通知，表明客户端已拒绝这些服务器的报价。在DHCPREQUEST消息中选择的服务器将客户端的绑定提交到持久存储，并使用包含请求客户端的配置参数的DHCPACK消息进行响应。“客户端标识符”或“chaddr”与分配的网络地址的组合构成客户端租约的唯一标识符，客户端和服务器都使用它来标识任何DHCP消息中引用的租约。DHCPACK消息中的任何配置参数都不应与客户端响应的较早的DHCPOFFER消息中的配置参数冲突。服务器此时不应检查提供的网络地址。DHCPACK消息中的“yiaddr”字段用所选网络地址填充。
If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message.
如果所选服务器无法满足DHCPREQUEST消息（例如，已分配请求的网络地址），则服务器应使用DHCPNAK消息进行响应。
A server MAY choose to mark addresses offered to clients in DHCPOFFER messages as unavailable. The server SHOULD mark an address offered to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client.
服务器可以选择将DHCPOFFER消息中提供给客户端的地址标记为不可用。如果服务器未收到来自客户机的DHCPREQUEST消息，则服务器应将DHCPOFFER消息中提供给该客户机的地址标记为可用。
5. The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and it notes the duration of the lease specified in the DHCPACK
5. 客户端接收带有配置参数的DHCPACK消息。客户端应对参数（例如，分配网络地址的ARP）进行最终检查，并记录DHCPACK中指定的租约期限
message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server, and it restarts the configuration process. The client SHOULD wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping.
消息此时，将配置客户端。如果客户端检测到该地址已在使用中（例如，通过使用ARP），则客户端必须向服务器发送DHCPDecend消息，并重新启动配置过程。在重新启动配置过程之前，客户端应至少等待10秒钟，以避免在循环情况下出现过多的网络流量。
If the client receives a DHCPNAK message, the client restarts the configuration process.
如果客户端收到DHCPNAK消息，则客户端将重新启动配置过程。
The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK nor a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1 of [RFC2131]. The client should choose to retransmit the DHCPREQUEST enough times to give an adequate probability of contacting the server without causing the client (and the user of that client) to wait too long before giving up; e.g., a client retransmitting as described in section 4.1 of [RFC2131] might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK nor a DHCPNAK message after employing the retransmission algorithm, the client reverts to INIT state and restarts the initialization process. The client SHOULD notify the user that the initialization process has failed and is restarting.
如果客户端既没有收到DHCPACK消息，也没有收到DHCPNAK消息，则客户端将超时并重新传输DHCPREQUEST消息。客户机根据[RFC2131]第4.1节中的重传算法重传DHCPREQUEST。客户机应选择重新传输DHCPREQUEST足够的时间，以提供足够的联系服务器的可能性，而不会导致客户机（以及该客户机的用户）在放弃之前等待太久；e、 例如，[RFC2131]第4.1节所述的客户端重新传输可能会在重新启动初始化过程之前重新传输DHCPREQUEST消息四次，总延迟为60秒。如果客户端在采用重传算法后既没有收到DHCPACK消息，也没有收到DHCPNAK消息，则客户端将恢复到初始状态并重新启动初始化过程。客户端应通知用户初始化过程已失败，正在重新启动。
6. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released with its 'client identifier' or 'chaddr' and network address in the DHCPRELEASE message. If the client used a 'client identifier' when it obtained the lease, it MUST use the same 'client identifier' in the DHCPRELEASE message.
6. 客户端可以通过向服务器发送DHCPRELEASE消息来选择放弃对网络地址的租用。客户端在DHCPRELEASE消息中使用其“客户端标识符”或“chaddr”以及网络地址标识要释放的租约。如果客户端在获得租约时使用了“客户端标识符”，则必须在DHCPRELEASE消息中使用相同的“客户端标识符”。
Network administrators MUST only enable the use of Rapid Commit on a DHCP server if one of the following conditions is met:
只有满足以下条件之一时，网络管理员才能在DHCP服务器上启用快速提交：
1. The server is the only server for the subnet.
1. 服务器是子网的唯一服务器。
2. When multiple servers are present, they may each commit a binding for all clients, and therefore each server must have sufficient addresses available.
2. 当存在多个服务器时，每个服务器都可能为所有客户端提交一个绑定，因此每个服务器必须有足够的可用地址。
A server MAY allow configuration for a different (likely shorter) initial lease time for addresses assigned when Rapid Commit is used to expedite reclaiming addresses not used by clients.
当使用快速提交加快回收客户端未使用的地址时，服务器可能允许为分配的地址配置不同（可能更短）的初始租用时间。
The Rapid Commit option is used to indicate the use of the two-message exchange for address assignment. The code for the Rapid Commit option is 80. The format of the option is:
快速提交选项用于指示使用两个消息交换进行地址分配。快速提交选项的代码是80。该选项的格式为：
Code Len
+-----+-----+
| 80 | 0 |
+-----+-----+
Code Len
+-----+-----+
| 80 | 0 |
+-----+-----+
A client MUST include this option in a DHCPDISCOVER message if the client is prepared to perform the DHCPDISCOVER-DHCPACK message exchange described earlier.
如果客户端准备执行前面描述的DHCPDISCOVER-DHCPACK消息交换，则客户端必须在DHCPDISCOVER消息中包含此选项。
A server MUST include this option in a DHCPACK message sent in a response to a DHCPDISCOVER message when completing the DHCPDISCOVER-DHCPACK message exchange.
完成DHCPDISCOVER-DHCPACK消息交换时，服务器必须在响应DHCPDISCOVER消息时发送的DHCPACK消息中包含此选项。
IANA has assigned value 80 for the Rapid Commit option code in accordance with [RFC2939].
IANA已根据[RFC2939]为快速提交选项代码分配了值80。
The concepts in this document do not significantly alter the security considerations for DHCP (see [RFC2131] and [RFC3118]). However, use of this option could expedite denial of service attacks by allowing a mischievous client to consume all available addresses more rapidly or to do so without requiring two-way communication (as injecting DHCPDISCOVER messages with the Rapid Commit option is sufficient to cause a server to allocate an address).
本文档中的概念不会显著改变DHCP的安全注意事项（请参阅[RFC2131]和[RFC3118]）。但是，使用此选项可以通过允许恶意客户端更快地使用所有可用地址或在不需要双向通信的情况下使用所有可用地址来加速拒绝服务攻击（因为使用快速提交选项注入DHCPDISCOVER消息足以导致服务器分配地址）。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[RFC2939]Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
Special thanks to Ted Lemon and Andre Kostur for their many valuable comments. Thanks to Ralph Droms for his review comments during WGLC. Thanks to Noh-Byung Park and Youngkeun Kim for their supports on this work.
特别感谢Ted Lemon和Andre Kostur的宝贵评论。感谢Ralph Droms在WGLC期间的评论。感谢朴能彬和金永根对这项工作的支持。
Particularly, the authors would like to acknowledge the implementation contributions by Minho Lee of SAMSUNG Electronics.
特别是，作者要感谢三星电子（SAMSUNG Electronics）的李明浩（Minho Lee）的实施贡献。
Authors' Addresses
作者地址
Soohong Daniel Park Mobile Platform Laboratory SAMSUNG Electronics 416, Maetan-3dong, Yeongtong-Gu Suwon, Korea
Soohong Daniel Park移动平台实验室三星电子416，韩国永通谷水原Maetan-3dong
Phone: +82-31-200-4508
EMail: soohong.park@samsung.com
Phone: +82-31-200-4508
EMail: soohong.park@samsung.com
Pyungsoo Kim Mobile Platform Laboratory SAMSUNG Electronics 416, Maetan-3dong, Yeongtong-Gu Suwon, Korea
平洙金移动平台实验室三星电子416，韩国永通谷水原前滩3洞
Phone: +82-31-200-4635
EMail: kimps@samsung.com
Phone: +82-31-200-4635
EMail: kimps@samsung.com
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
伯尼·沃兹思科系统公司，美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
Phone: +1-978-936-0382
EMail: volz@cisco.com
Phone: +1-978-936-0382
EMail: volz@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。