draft-ietf-dhc-rapid-commit-opt-05.txt   rfc4039.txt 
Network Working Group S. Park Network Working Group S. Park
Internet-Draft P. Kim Request for Comments: 4039 P. Kim
June 25, 2004 Samsung Electronics Category: Standards Track SAMSUNG Electronics
B. Volz B. Volz
Cisco Systems Cisco Systems
March 2005
Rapid Commit Option for DHCPv4 Rapid Commit Option for the
draft-ietf-dhc-rapid-commit-opt-05.txt Dynamic Host Configuration Protocol version 4 (DHCPv4)
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 24, 2004. 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a new DHCPv4 option, modeled on the DHCPv6 This document defines a new Dynamic Host Configuration Protocol
Rapid Commit option, for obtaining IP address and configuration version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option,
information using a 2-message exchange rather than the usual 4- for obtaining IP address and configuration information using a
message exchange, expediting client configuration. 2-message exchange rather than the usual 4-message exchange,
expediting client configuration.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction................................................... 2
2. Requirements..................................................3 2. Requirements................................................... 2
3. Client/Server Operations......................................3 3. Client/Server Operations....................................... 2
3.1 Detailed Flow................................................4 3.1. Detailed Flow............................................ 3
3.2 Administrative Considerations................................7 3.2. Administrative Considerations............................ 6
4. Rapid Commit Option Format....................................8 4. Rapid Commit Option Format..................................... 7
5. IANA Considerations...........................................8 5. IANA Considerations............................................ 7
6. Security Considerations.......................................8 6. Security Considerations........................................ 7
7. References....................................................9 7. References..................................................... 7
7.1 Normative References.........................................9 7.1. Normative References..................................... 7
7.2 Informative References.......................................9 7.2. Informative References................................... 8
8. Authors' Addresses...........................................10 8. Acknowledgements............................................... 8
9. Acknowledgements.............................................10 Authors' Addresses................................................ 9
Full Copyright Statement.......................................... 10
1. Introduction 1. Introduction
In some environments, such as those in which high mobility occurs In some environments, such as those in which high mobility occurs and
and the network attachment point changes frequently, it is benefical the network attachment point changes frequently, it is beneficial to
to rapidly configure clients. And, in these environments it is rapidly configure clients. And, in these environments it is possible
possible to more quickly configure clients because the protections to more quickly configure clients because the protections offered by
offered by the normal (and longer) 4-message exchange may not be the normal (and longer) 4-message exchange may not be needed. The
needed. The 4-message exchange allows for redundancy (multiple DHCP 4-message exchange allows for redundancy (multiple DHCP servers)
servers) without wasting addresses, as addresses are only without wasting addresses, as addresses are only provisionally
provisionally assigned to a client until the client chooses and assigned to a client until the client chooses and requests one of the
requests one of the provisionally assigned addresses. The 2-message provisionally assigned addresses. The 2-message exchange may
exchange may therefore be used when only one server is present or therefore be used when only one server is present or when addresses
when addresses are plentiful and having multiple servers commit are plentiful and having multiple servers commit addresses for a
addresses for a client is not a problem. client is not a problem.
This document defines a new Rapid Commit option for DHCPv4, modeled This document defines a new Rapid Commit option for DHCPv4, modeled
on the DHCPv6 Rapid Commit option [RFC3315], which can be used to on the DHCPv6 Rapid Commit option [RFC3315], which can be used to
initiate a 2-message exchange to expedite client configuration in initiate a 2-message exchange to expedite client configuration in
some environments. A client advertises its support of this option some environments. A client advertises its support of this option by
by sending it in DHCPDISCOVER messages. A server then determines sending it in DHCPDISCOVER messages. A server then determines
whether to allow the 2-message exchange based on its configuration whether to allow the 2-message exchange based on its configuration
information and can either handle the DHCPDISCOVER as defined in information and can either handle the DHCPDISCOVER as defined in
[RFC2131] or commit the client's configuration information and [RFC2131] or commit the client's configuration information and
advance to sending a DHCPACK message with the Rapid Commit option advance to sending a DHCPACK message with the Rapid Commit option as
as defined herein. defined herein.
2. Requirements 2. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC 2119] document, are to be interpreted as described in [RFC2119].
3. Client/Server Operations 3. Client/Server Operations
If a client that supports the Rapid Commit option intends to use If a client that supports the Rapid Commit option intends to use the
the rapid commit capability, it includes a Rapid Commit option in rapid commit capability, it includes a Rapid Commit option in
DHCPDISCOVER messages that it sends. The client MUST NOT include DHCPDISCOVER messages that it sends. The client MUST NOT include it
it in any other messages. A client and server only use this option in any other messages. A client and server only use this option when
when configured to do so. configured to do so.
A client that sent a DHCPDISCOVER with Rapid Commit option processes A client that sent a DHCPDISCOVER with Rapid Commit option processes
responses as described in [RFC 2131]. However, if the client responses as described in [RFC2131]. However, if the client receives
receives a DHCPACK message with a Rapid Commit option, it SHOULD a DHCPACK message with a Rapid Commit option, it SHOULD process the
process the DHCPACK immediately (without waiting for additional DHCPACK immediately (without waiting for additional DHCPOFFER or
DHCPOFFER or DHCPACK messages) and use the address and DHCPACK messages) and use the address and configuration information
configuration information contained therein. contained therein.
A server that supports the Rapid Commit option MAY respond to a A server that supports the Rapid Commit option MAY respond to a
DHCPDISCOVER message that included the Rapid Commit option with a DHCPDISCOVER message that included the Rapid Commit option with a
DHCPACK that includes the Rapid Commit option and fully committed DHCPACK that includes the Rapid Commit option and fully committed
address and configuration information. A server MUST NOT include address and configuration information. A server MUST NOT include the
the Rapid Commit option in any other messages. Rapid Commit option in any other messages.
The Rapid Commit option MUST NOT appear in a Parameter Request The Rapid Commit option MUST NOT appear in a Parameter Request List
List option [RFC 2132]. option [RFC2132].
All other DHCP operations are as documented in [RFC 2131]. All other DHCP operations are as documented in [RFC 2131].
3.1 Detailed Flow 3.1. Detailed Flow
The following is a revised Section 3.1 of [RFC 2131] that includes The following is revised from Section 3.1 of [RFC2131], which
handling of the Rapid Commit option. includes handling of the Rapid Commit option.
1. The client broadcasts a DHCPDISCOVER message on its local 1. The client broadcasts a DHCPDISCOVER message on its local
physical subnet. If the client supports the Rapid Commit physical subnet. If the client supports the Rapid Commit
option and intends to use the rapid commit capability, it option and intends to use the rapid commit capability, it
includes a Rapid Commit option in the DHCPDISCOVER message. includes a Rapid Commit option in the DHCPDISCOVER message.
The DHCPDISCOVER message MAY include options that suggest The DHCPDISCOVER message MAY include options that suggest
values for the network address and lease duration. BOOTP values for the network address and lease duration. BOOTP relay
relay agents may pass the message on to DHCP servers not on agents may pass the message on to DHCP servers not on the same
the same physical subnet. physical subnet.
2. Each server may respond with either a DHCPOFFER message or a 2. Each server may respond with either a DHCPOFFER message or a
DHCPACK message with Rapid Commit option (the latter only if DHCPACK message with the Rapid Commit option (the latter only
the DHCPDISCOVER contained a Rapid Commit option and the if the DHCPDISCOVER contained a Rapid Commit option and the
server's configuration policies allow use of Rapid Commit) server's configuration policies allow use of Rapid Commit).
that includes an available network address in the 'yiaddr' These would include an available network address in the
field (and other configuration parameters in DHCP options). 'yiaddr' field (and other configuration parameters in DHCP
Servers sending a DHCPOFFER need not reserve the offered options). Servers sending a DHCPOFFER need not reserve the
network address, although the protocol will work more offered network address, although the protocol will work more
efficiently if the server avoids allocating the offered efficiently if the server avoids allocating the offered network
network address to another client. Servers sending the address to another client. Servers sending the DHCPACK message
DHCPACK message commit the binding for the client to commit the binding for the client to persistent storage before
persistent storage before sending the DHCPACK. The sending the DHCPACK. The combination of 'client identifier' or
combination of 'client identifier' or 'chaddr' and assigned 'chaddr' and assigned network address constitute a unique
network address constitute a unique identifier for the identifier for the client's lease and are used by both the
client's lease and are used by both the client and server client and server to identify a lease referred to in any DHCP
to identify a lease referred to in any DHCP messages. The messages. The server transmits the DHCPOFFER or DHCPACK
server transmits the DHCPOFFER or DHCPACK message to the message to the client, if necessary by using the BOOTP relay
client, using the BOOTP relay agent if necessary. agent.
When allocating a new address, servers SHOULD check that the When allocating a new address, servers SHOULD check that the
offered network address is not already in use; e.g., the offered network address is not already in use; e.g., the server
server may probe the offered address with an ICMP Echo Request. may probe the offered address with an ICMP Echo Request.
Servers SHOULD be implemented so that network administrators Servers SHOULD be implemented so that network administrators
MAY choose to disable probes of newly allocated addresses. MAY choose to disable probes of newly allocated addresses.
Figure 3 in [RFC 2131] shows the flow for the normal 4-message Figure 3 in [RFC 2131] shows the flow for the normal 4-message
exchange. Figure 1 below shows the 2-message exchange. exchange. Figure 1 below shows the 2-message exchange.
Server Client Server Server Client Server
(not selected) (selected) (not selected) (selected)
v v v v v v
skipping to change at page 5, line 31 skipping to change at page 4, line 37
| \________ | / DHCPACK | | \________ | / DHCPACK |
| DHCPOFFER\ |/w/Rapid Commit| | DHCPOFFER\ |/w/Rapid Commit|
| (discarded) | | | (discarded) | |
| Initialization complete | | Initialization complete |
| | | | | |
. . . . . .
. . . . . .
| | | | | |
| Graceful shutdown | | Graceful shutdown |
| | | | | |
| |\ ____________ | | |\_____________ |
| | DHCPRELEASE \| | | DHCPRELEASE \|
| | | | | |
| | Discards lease | | Discards lease
| | | | | |
v v v v v v
Figure 1: Timeline diagram when Rapid Commit used Figure 1 Timeline diagram when Rapid Commit is used
3. The client receives one or more DHCPOFFER or DHCPACK (if Rapid 3. The client receives one or more DHCPOFFER or DHCPACK (if the
Commit option sent in DHCPDISCOVER) messages from one or more Rapid Commit option is sent in DHCPDISCOVER) messages from one
servers. If a DHCPACK (with Rapid Commit option) is received, or more servers. If a DHCPACK (with the Rapid Commit option)
the client may immediately advance to step 5 below if the is received, the client may immediately advance to step 5 below
offered configuration parameters are acceptable. The client may if the offered configuration parameters are acceptable. The
choose to wait for multiple responses. The client chooses one client may choose to wait for multiple responses. The client
server from which to request or accept configuration parameters, chooses one server from which to request or accept
based on the configuration parameters offered in the DHCPOFFER configuration parameters, based on the configuration parameters
and DHCPACK messages. If the client chooses a DHCPACK, it offered in the DHCPOFFER and DHCPACK messages. If the client
advances to step 5. Otherwise, the client broadcasts a chooses a DHCPACK, it advances to step 5. Otherwise, the
DHCPREQUEST message that MUST include the 'server identifier' client broadcasts a DHCPREQUEST message that MUST include the
option to indicate which server it has selected, and that MAY 'server identifier' option to indicate which server it has
include other options specifying desired configuration values. selected, the message MAY include other options specifying
The 'requested IP address' option MUST be set to the value of desired configuration values. The 'requested IP address'
'yiaddr' in the DHCPOFFER message from the server. This option MUST be set to the value of 'yiaddr' in the DHCPOFFER
DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP message from the server. This DHCPREQUEST message is broadcast
relay agents. To help ensure that any BOOTP relay agents and relayed through DHCP/BOOTP relay agents. To help ensure
forward the DHCPREQUEST message to the same set of DHCP servers that any BOOTP relay agents forward the DHCPREQUEST message to
that received the original DHCPDISCOVER message, the the same set of DHCP servers that received the original
DHCPREQUEST message MUST use the same value in the DHCP message DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
header's 'secs' field and be sent to the same IP broadcast value in the DHCP message header's 'secs' field and be sent to
address as the original DHCPDISCOVER message. The client times the same IP broadcast address as was the original DHCPDISCOVER
out and retransmits the DHCPDISCOVER message if the client message. The client times out and retransmits the DHCPDISCOVER
receives no DHCPOFFER messages. message if the client receives no DHCPOFFER messages.
4. The servers receive the DHCPREQUEST broadcast from the client. 4. The servers receive the DHCPREQUEST broadcast from the client.
Those servers not selected by the DHCPREQUEST message use the Servers not selected by the DHCPREQUEST message use the message
message as notification that the client has declined that as notification that the client has declined those servers'
server's offer. The server selected in the DHCPREQUEST message offers. The server selected in the DHCPREQUEST message commits
commits the binding for the client to persistent storage and the binding for the client to persistent storage and responds
responds with a DHCPACK message containing the configuration with a DHCPACK message containing the configuration parameters
parameters for the requesting client. The combination of for the requesting client. The combination of 'client
'client identifier' or 'chaddr' and assigned network address identifier' or 'chaddr' and assigned network address constitute
constitute a unique identifier for the client's lease and are a unique identifier for the client's lease and are used by both
used by both the client and server to identify a lease referred the client and server to identify a lease referred to in any
to in any DHCP messages. Any configuration parameters in the DHCP messages. Any configuration parameters in the DHCPACK
DHCPACK message SHOULD NOT conflict with those in the earlier message SHOULD NOT conflict with those in the earlier DHCPOFFER
DHCPOFFER message to which the client is responding. The message to which the client is responding. The server SHOULD
server SHOULD NOT check the offered network address at this NOT check the offered network address at this point. The
point. The 'yiaddr' field in the DHCPACK messages is filled in 'yiaddr' field in the DHCPACK messages is filled in with the
with the selected network address. selected network address.
If the selected server is unable to satisfy the DHCPREQUEST If the selected server is unable to satisfy the DHCPREQUEST
message (e.g., the requested network address has been message (e.g., the requested network address has been
allocated), the server SHOULD respond with a DHCPNAK message. allocated), the server SHOULD respond with a DHCPNAK message.
A server MAY choose to mark addresses offered to clients in A server MAY choose to mark addresses offered to clients in
DHCPOFFER messages as unavailable. The server SHOULD mark an DHCPOFFER messages as unavailable. The server SHOULD mark an
address offered to a client in a DHCPOFFER message as available address offered to a client in a DHCPOFFER message as available
if the server receives no DHCPREQUEST message from that client. if the server receives no DHCPREQUEST message from that client.
5. The client receives the DHCPACK message with configuration 5. The client receives the DHCPACK message with configuration
parameters. The client SHOULD perform a final check on the parameters. The client SHOULD perform a final check on the
parameters (e.g., ARP for allocated network address), and notes parameters (e.g., ARP for allocated network address), and it
the duration of the lease specified in the DHCPACK message. At notes the duration of the lease specified in the DHCPACK
this point, the client is configured. If the client detects message. At this point, the client is configured. If the
that the address is already in use (e.g., through the use of client detects that the address is already in use (e.g.,
ARP), the client MUST send a DHCPDECLINE message to the server through the use of ARP), the client MUST send a DHCPDECLINE
and restarts the configuration process. The client SHOULD wait message to the server, and it restarts the configuration
a minimum of ten seconds before restarting the configuration process. The client SHOULD wait a minimum of ten seconds
process to avoid excessive network traffic in case of looping. before restarting the configuration process to avoid excessive
network traffic in case of looping.
If the client receives a DHCPNAK message, the client restarts If the client receives a DHCPNAK message, the client restarts
the configuration process. the configuration process.
The client times out and retransmits the DHCPREQUEST message if The client times out and retransmits the DHCPREQUEST message if
the client receives neither a DHCPACK nor a DHCPNAK message. the client receives neither a DHCPACK nor a DHCPNAK message.
The client retransmits the DHCPREQUEST according to the The client retransmits the DHCPREQUEST according to the
retransmission algorithm in section 4.1 of [RFC 2131]. The retransmission algorithm in section 4.1 of [RFC 2131]. The
client should choose to retransmit the DHCPREQUEST enough times client should choose to retransmit the DHCPREQUEST enough times
to give adequate probability of contacting the server without to give an adequate probability of contacting the server
causing the client (and the user of that client) to wait overly without causing the client (and the user of that client) to
long before giving up; e.g., a client retransmitting as wait too long before giving up; e.g., a client retransmitting
described in section 4.1 of [RFC 2131] might retransmit the as described in section 4.1 of [RFC2131] might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds, DHCPREQUEST message four times, for a total delay of 60
before restarting the initialization procedure. If the client seconds, before restarting the initialization procedure. If
receives neither a DHCPACK nor a DHCPNAK message after the client receives neither a DHCPACK nor a DHCPNAK message
employing the retransmission algorithm, the client reverts to after employing the retransmission algorithm, the client
INIT state and restarts the initialization process. The client reverts to INIT state and restarts the initialization process.
SHOULD notify the user that the initialization process has The client SHOULD notify the user that the initialization
failed and is restarting. process has failed and is restarting.
6. The client may choose to relinquish its lease on a network 6. The client may choose to relinquish its lease on a network
address by sending a DHCPRELEASE message to the server. The address by sending a DHCPRELEASE message to the server. The
client identifies the lease to be released with its 'client client identifies the lease to be released with its 'client
identifier', or 'chaddr' and network address in the DHCPRELEASE identifier' or 'chaddr' and network address in the DHCPRELEASE
message. If the client used a 'client identifier' when it message. If the client used a 'client identifier' when it
obtained the lease, it MUST use the same 'client identifier' in obtained the lease, it MUST use the same 'client identifier' in
the DHCPRELEASE message. the DHCPRELEASE message.
3.2 Administrative Considerations 3.2. Administrative Considerations
Network administrators MUST only enable the use of Rapid Commit on a Network administrators MUST only enable the use of Rapid Commit on a
DHCP server if one of the following conditions is met: DHCP server if one of the following conditions is met:
1. The server is the only server for the subnet. 1. The server is the only server for the subnet.
2. When multiple servers are present, they may each commit a 2. When multiple servers are present, they may each commit a
binding for all clients and therefore each server must have binding for all clients, and therefore each server must have
sufficient addresses available. sufficient addresses available.
A server MAY allow configuration for a different (likely A server MAY allow configuration for a different (likely shorter)
shorter) initial lease time for addresses assigned when Rapid initial lease time for addresses assigned when Rapid Commit is used
Commit is used to expedite reclaiming addresses not used by to expedite reclaiming addresses not used by clients.
clients.
4. Rapid Commit Option Format 4. Rapid Commit Option Format
The Rapid Commit option is used to signal the use of the two message The Rapid Commit option is used to indicate the use of the two-
exchange for address assignment. The code for the Rapid Commit message exchange for address assignment. The code for the Rapid
Option has to be defined (TBD). The format of the option is: Commit option is 80. The format of the option is:
Code Len Code Len
+-----+-----+ +-----+-----+
| TBD | 0 | | 80 | 0 |
+-----+-----+ +-----+-----+
A client MUST include this option in a DHCPDISCOVER message if A client MUST include this option in a DHCPDISCOVER message if the
the client is prepared to perform the DHCPDISCOVER-DHCPACK client is prepared to perform the DHCPDISCOVER-DHCPACK message
message exchange described earlier. exchange described earlier.
A server MUST include this option in a DHCPACK message sent in A server MUST include this option in a DHCPACK message sent in a
a response to a DHCPDISCOVER message when completing the response to a DHCPDISCOVER message when completing the DHCPDISCOVER-
DHCPDISCOVER-DHCPACK message exchange. DHCPACK message exchange.
5. IANA Considerations 5. IANA Considerations
IANA is requested to assign a value for the Rapid Commit option code IANA has assigned value 80 for the Rapid Commit option code in
in accordance with [RFC 2939]. accordance with [RFC2939].
6. Security Considerations 6. Security Considerations
The concepts in this document do not significantly alter the The concepts in this document do not significantly alter the security
security considerations for DHCP (see [RFC 2131] and [RFC 3118]). considerations for DHCP (see [RFC2131] and [RFC3118]). However, use
However, use of this option could expedite denial of service attacks of this option could expedite denial of service attacks by allowing a
by allowing a mischievous client to more rapidly consume all mischievous client to consume all available addresses more rapidly or
available addresses or to do so without requiring two-way to do so without requiring two-way communication (as injecting
communication (as injecting DHCPDISCOVER messages with the Rapid DHCPDISCOVER messages with the Rapid Commit option is sufficient to
Commit option is sufficient to cause a server to allocate an cause a server to allocate an address).
address).
7. References 7. References
7.1 Normative References 7.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2131] R. Droms, Dynamic Host Configuration Protocol, RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
March 1997. 2131, March 1997.
7.2 Informative References 7.2. Informative References
[RFC 2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Vendor Extensions," RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC 2939] R. Droms, Procedures and IANA Guidelines for Definition [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types, RFC 2939, of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000. September 2000.
[RFC 3118] R. Droms and W. Arbaugh, Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages, RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC 3315] R. Droms, et. al., Dynamic Host Configuration Protocol [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
for IPv6, RFC 3315, July 2003. and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
8. Authors' Addresses 8. Acknowledgements
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.
Particularly, the authors would like to acknowledge the
implementation contributions by Minho Lee of SAMSUNG Electronics.
Authors' Addresses
Soohong Daniel Park Soohong Daniel Park
Mobile Platform Laboratory Mobile Platform Laboratory
Samsung Electronics SAMSUNG Electronics
416, Maetan-3dong, Yeongtong-Gu 416, Maetan-3dong, Yeongtong-Gu
Suwon, Korea Suwon, Korea
Phone: +82-31-200-4508 Phone: +82-31-200-4508
EMail: soohong.park@samsung.com EMail: soohong.park@samsung.com
Pyungsoo Kim Pyungsoo Kim
Mobile Platform Laboratory Mobile Platform Laboratory
Samsung Electronics SAMSUNG Electronics
416, Maetan-3dong, Yeongtong-Gu 416, Maetan-3dong, Yeongtong-Gu
Suwon, Korea Suwon, Korea
Phone: +82-31-200-4635 Phone: +82-31-200-4635
Email: kimps@samsung.com EMail: kimps@samsung.com
Bernie Volz Bernie Volz
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusette Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1-978-936-0382 Phone: +1-978-936-0382
EMail: volz@cisco.com EMail: volz@cisco.com
9. Acknowledgements Full Copyright Statement
Special thanks to Ted Lemon and Andre Kostur for their many Copyright (C) The Internet Society (2005).
valuable comments. Thanks to Ralph Droms for his review comments
during WGLC. Thanks to Youngkeun Kim for his support on this work.
Particularly, authors would like to acknowledge the implementation This document is subject to the rights, licenses and restrictions
contributions by Minho Lee of Samsung Electronics. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the IETF's procedures with respect to rights in IETF on the procedures with respect to rights in RFC documents can be
Documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
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.
Copyright Statement
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.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/