Wable R. U. Network Working Group S. Madanapalli Internet-Draft Samsung ISO Expires: August 4, 2005 S. Park Samsung Electronics February 3, 2005 Service-Oriented Address Assignment using DHCPv4 draft-syam-dhc-soav4-option-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 4, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document introduces a new option in DHCPv4 for Service-Oriented Address assignment for a particular type of service that DHCPv4 Clients provide. The Service-Oriented Address can be either Anycast/Shared Unicast or a Well-known Unicast Addresses. This address assignment is much similar to other address type assignments, Madanapalli, et al. Expires August 4, 2005 [Page 1] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 except that Service-Oriented Address assignment requires the specification of Service Type of the node that is requesting the address. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statements . . . . . . . . . . . . . . . . . . . 3 4. DHCPv4 specification dependency . . . . . . . . . . . . . . . 4 5. Service-Oriented Address Option . . . . . . . . . . . . . . . 4 5.1 Service-Oriented Address Option Format . . . . . . . . . . 4 6. Overview of Service-Oriented Address Assignment . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 10.2 Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 9 Madanapalli, et al. Expires August 4, 2005 [Page 2] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 1. Introduction "Anycast address" is an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is routed to the "nearest" interface having that address, depending on the distance of the routing path. Anycast addresses can be used as unique service identifiers for many services such as Domain Name System (DNS) Servers, Web-Servers etc. Also usage of Well-known Unicast Addresses is being increasing for acheiving Zero-configuration. DHCPv4 base specification [RFC2131] provides a way for the DHCPv4 clients to get permanent/temporary unicast addresses from a DHCPv4 Server. This document provides a way for assigning an address to a Service provided by the DHCPv4 Clients. An address that is assigned to a service is called Service-Oriented Address (SOA). The Service-Oriented Address can be Anycast/Shared Unicast or a Well-known Unicast Address. This document introduces a new Service Address option in DHCPv4 for Service-Oriented Address assignment for a particular type of service that DHCPv4 Client provides. This address assignment is much similar to other address types assignments, except that the Service-Oriented Address assignment requires the specification of Service Type while requesting this address assignement. 2. Requirements 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]. 3. Applicability Statements With successful adoption of the Anycast Addresses in IPv6 the efforts are going on towards the usage of the similar concept in IPv4([RFC 3068]). But its usage has been restricted to nodes which are routers. However, the work is in progress to implement the anycast address support in IPv4 Hosts. Anycast addresses can be used as unique service identifiers. Many services such as Domain Name System (DNS) and HTTP proxy are operated on the Internet. It is troublesome that users have to know IP addresses of servers for accessing these services at each site. If each service had its own unique anycast address as its service identifier and its servers used the address for their network Madanapalli, et al. Expires August 4, 2005 [Page 3] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 interfaces, users could access the service only with the anycast address. This mechanism can ease users into using services. Currently no mechanism exists to automatically configure the hosts with a specific (anycast) address for a particular service. Also usage of Well-Known Addresses is increasing for achieving zero-configuration. Currently these addresses are being preloaded into the devices before shipping them to the end-users. This draft is applicable to the Nodes that provide well-known services (e.g. DNS Servers) and administrator defined servers using Anycast/Shared Unicast Addressing (e.g. Web Servers) for dynamically assigning the addresses corresponding the services they provide using DHCPv6. 4. DHCPv4 specification dependency This document describes new DHCPv4 option for service-oriented address assignment. This document should be read in conjunction with the DHCPv4 specification [RFC2131]. Definitions for terms and acronyms not specifically defined in this document are defined in [RFC2131]. 5. Service-Oriented Address Option Service-Oriented Address Request is an option through which a client can request a server a spcefic service-oriented address. Server identify, group and manage a set of related IPv4 service-oriented addresses. Server maintains associated configuration information for each client for Service-Oriented Address is similar to other adresses as described in [RFC2131] for unicast addresses. The client can request IPv4 addresses for one or more services in same message with multiple option for different service type . Configuration options will be sent by the Server can be sent to client with one or more replies with separate parameter list for each of the address list. 5.1 Service-Oriented Address Option Format The Service-Oriented Address option carries the information about the requested/offered address. The format of the Service Oriented Address option is: Madanapalli, et al. Expires August 4, 2005 [Page 4] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 1 1 2 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len | Service Type |Anycast| a1 | a2 | a3 | a4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Oriented Address Field description o Code : Service Oriented Address Option (TBD). o Len: 7 (Bytes). o Service-Type: The Service Type for which Anycast/Shared Unicast/ Well-Known Address to be assigned. o Anycast: 1 : If the address is an Anycast 0 : Otherwise o Service Oriented Address: Address allocated by DHCPv4 Server for Service Type requested by DHCPv4 Client. Anycast sub-option specifies that the address is an Anycast address or not. Client can request specifically anycast address using this sub-option and the Server can set the field to 1 if the address allocated for a requested service type is a Anycast address. Server SHOULD allocate any available address for selected service, if the Anycast sub-option is set to zero. Server SHOULD ignore the request for Anycast address if the Anycast address address is not present for selected service. Server MUST set the Anycast sub-option to 1 if the address for the selected service is Anycast address. Service-Oriented address field in the option will be field by the DHCPv4 Server. This field in the option will be set to zero by the client while sending the request message and will be ignored by the server while processing it. Madanapalli, et al. Expires August 4, 2005 [Page 5] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 An Service-Oriented Address option may only appear in the options area of a DHCP message. A DHCP message may contain multiple Service Orieneted Address options.All other paramter list will remain same as per any other address. 6. Overview of Service-Oriented Address Assignment The DHCPv4 Client that wants to get Service-Oriented Address for a specific service Type includes Service Oriented Address option in the Solicitation and/or Request that it sends to DHCPv4 Server with the Service-Type. If the client requires Service-Oriented addresses for multiple service types, it can include multiple Service-Oriented Address option fields in Solicitation and/or Request Messages. The DHCPv4 server then checks the availability of the Service-Oriented Address for the requested service type. If the Service-Oriented Address pertinent to the Service Type is configured in the DHCPv4 Server to assign to the clients, then the server fills the Service-Oriented Address in Service-Oriented Address field of Service Oriented option with the service type details. The presence of this option conveys the DHCPv4 client that the address allocated is for the service specified in the Service-Oriented Address Option and address is present in the same option. If there are multiple Service-Oriented Address available for the same service type the server can typically send one or multiple responses to the client with same service type included. Address assignment and the other operation of the basic DHCP remains same excpet the request for the Service-Oriented Address option in Request and Reply Message. 7. Security Considerations The DHCPv4 Option defined here allows a malicious server providing incorrect address information to the client, causing users with valid service-oriented address unable to use services. This is a well known property of the DCHP protocol [RFC2131]. This option does not create any additional risk of such attacks. 8. IANA Considerations This document defines the following new DHCPv6 option that IANA needs assign a code from DHCPv6 Option codes name space: Option Name Value Described in Service-Oriented Address Option TBD Section 5.1 Madanapalli, et al. Expires August 4, 2005 [Page 6] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 This document introduces a new name space for Service-Type. The DHC WG needs to identify the relevant Service Types for which IANA will later need to assign the codes. 9. Future Work o Identifying & Defining of Service Types 10. References 10.1 Normative References [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC 2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2 Informative References [RFC 3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", RFC 3068,June 2001 [RFC 3330] IANA, "Special-Use IPv4 Addresses" RFC 3330 September 2002 Authors' Addresses Syam Madanapalli Samsung India Software Operations J. P. Techno Park, 3/1 Millers Road, Bangalore 560052 INDIA Phone: +91 80 51197777 EMail: syam@samsung.com Madanapalli, et al. Expires August 4, 2005 [Page 7] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 Soohong Daniel Park Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4508 EMail: soohong.park@samsung.com Madanapalli, et al. Expires August 4, 2005 [Page 8] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 February 2005 Intellectual Property Statement 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. 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. 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. 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Madanapalli, et al. Expires August 4, 2005 [Page 9]