DHC S. Daniel Park Internet-Draft SAMSUNG Electronics Expires : 16 April 2004 Bernie Volz Ericsson 17 October 2003 Rapid Reply Option for DHCPv4 draft-volz-dhc-rapidreply-opt-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 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 http://www.ietf.org/shadow.html. Abstract This document defines a new option, modeled on the IPv6 option for getting IP address and configuration information rapidly which can be used for detecting network attachment when client moves to a new link. Park, Volz [Expires: 16 April 2004] [Page 1] Internet-Draft Rapid Reply Option for DHCPv4 17 October 2003 Table of Contents 1. Introduction.................................................2 2. Requirements.................................................3 3. Operations...................................................3 4. Rapid Reply Option...........................................3 5. Applicability Statement......................................4 6. IANA Considerations..........................................5 7. Security Considerations......................................5 8. References...................................................5 9. Author Addresses.............................................6 10. Acknowledgements.............................................6 1. Introduction In some environments (are described in section 3), we care more about the device getting configured rapidly than we do about wasting addresses, or we may know that there is only one DHCP server, so the client is not going to have to make a choice. In such an environment, we might want to do a two-packet handshake to assign the IP address just to get the device up and running a little bit faster. Contrary to the DHCPv6, current DHCPv4 do not provide valuable option for obtaining IP address and configuration information rapidly, so we has to waste some duration in order to obtain IP addresses from DHCP server. This document defines a new option as Rapid Reply option, modeled on the IPv6 options DHCPv6 [RFC 3315] which can be used for detecting network attachment when client moves to a new link. This extension is targeted to the detecting network attachment as well as wireless mobile environment. This option is only shown in DHCPDISCOVER / DHCPACK message. Park, Volz [Expires: 16 April 2004] [Page 2] Internet-Draft Rapid Reply Option for DHCPv4 17 October 2003 2. Requirements 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 [RFC 2119] 3. Operations A client that supports the Rapid Reply option MAY include it in DHCPDISCOVER messages that it sends. The client MUST NOT include it in any other messages. A server that supports the Rapid Reply option MAY respond to a DHCPDISCOVER message that included the Rapid Reply option with a DHCPACK that includes the Rapid Reply option and fully a committed address and configuration information. A server MUST NOT include the Rapid Reply option in any other messages. A client that sent a DHCPDISCOVER with Rapid Reply option processes responses as described in DHCP [DHCP]. However, if the client receives a DHCPACK with a Rapid Reply option, it may process the DHCPACK immediately and use the address and configuration information contained therein. All other DHCP operations are as documented in [DHCP]. 4. Rapid Reply Option The Rapid Reply option is used to signal the use of the two message exchange for address assignment. The code for the Rapid Reply Option has to be defined (TBD), and its length is 1 octet. Code Len +-----+-----+ | TBD | 0 | +-----+-----+ Park, Volz [Expires: 16 April 2004] [Page 3] Internet-Draft Rapid Reply Option for DHCPv4 17 October 2003 A client MAY include this option in a DHCPDISCOVER message if the client is prepared to perform the DHCPDISCOVER-DHCPACK message exchange described in section 3.1 DHCP [RFC 2131]. 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. 5. Applicability Statement DHCP client (e.g. mobile node) has to obtain a valid IP address from DHCP server when attaching a new link. In particular, mobile node wants to obtain its address as soon as it moves to a new link. Anything which meets above requirement can make use of a new Rapid Reply option as well. The new option defined in this document can also be applied to wireless lan and mobile environment in order to detecting network attachment with latency optimization. [AR] [AR] [AR] | | | | | | +------------+ | | | | | | | | | | [AP1] [AP2] [AP3] [AP4] / / /\/ /\/ / / MN-----> MN-----> Figure 1: Wireless Lan Topology supporting Rapid Reply option Park, Volz [Expires: 16 April 2004] [Page 4] Internet-Draft Rapid Reply Option for DHCPv4 17 October 2003 As depicted figure 1, MN has to request its IP address to the nearest AP in a new link as soon as layer 2 association is established. In particular, current AP can perform DHCP server configured by operator and allocate IP address either private or public IP address. A server MUST include Rapid Reply option in DHCPACK sent in response to a DHCPDISCOVER when performing DHCP message exchange. As described in DHCPv6, if more that one server responds to a DHCPDISCOVER that includes a Rapid Reply option, some server will commit addresses that are not actually used by the client. This consideration is able to be minimized by the same behavior in DHCPv6, for example, by designing the DHCP service so that only one server responds to this option or by using relatively short lifetimes for assigned address. Generally, private addresses are used for allocating IP address via NAT in wireless area, so above problem will not be severe. 6. IANA Considerations The value Rapid Reply option code must be assigned from a numbering space defined for public DHCP options in [RFC 2939]. 7. Security Considerations This document do not occur any security consideration, nor does it impact existing security. DHCP provides an authentication and message integrity mechanism, as described in [RFC 3118], which may be used if authenticity is required for data carried by the option defined in this document. 8. References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2131] R. Droms, Dynamic Host Configuration Protocol, RFC 2131, March 1997. Park, Volz [Expires: 16 April 2004] [Page 5] Internet-Draft Rapid Reply Option for DHCPv4 17 October 2003 [RFC 3315] R. Droms, et. al., Dynamic Host Configuration Protocol for IPv6, RFC 3315, July 2003. [RFC 2939] R. Droms, Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types, RFC 2939, September 2000. [RFC 3118] R. Droms and W. Arbaugh, Authentication for DHCP Messages, RFC 3118, June 2001. 9. Author Addresses Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics 416, Maetan-3Dong, Paldal-Gu, Suwon Gyeonggi-Do, Korea Phone: +82-31-200-4508 EMail: soohong.park@samsung.com Bernie Volz 116 Hawkins Pond Road Center Harbor, NH 03226-3103 USA Phone: +1-508-259-3734 EMail: volz@metrocast.net 10. Acknowledgements Specially thank is Ted Lemon for his many valuable comments. Notice Regarding Intellectual Property Rights See http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt Park, Volz [Expires: 16 April 2004] [Page 6] Internet-Draft Rapid Reply Option for DHCPv4 17 October 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Funding for the RFC editor function is currently provided by the internet Society. Park, Volz [Expires: 16 April 2004] [Page 7]