Network Working Group S. Madanapalli Internet-Draft S. Kumar Expires: May 26, 2005 Samsung ISO S. Park Samsung Electronics November 25, 2004 Service-Oriented Address Assignment using DHCPv6 draft-ietf-dhc-soa-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 May 26, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document introduces a new option in DHCPv6 for Service-Oriented Address assignment for a particular type of service that DHCPv6 Clients provide. The Service-Oriented Address can be either Anycast/Shared Unicast or a Well-known Unicast Address. This address assignment is much similar to other address type assignments, Madanapalli, et al. Expires May 26, 2005 [Page 1] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 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. DHCPv6 specification dependency . . . . . . . . . . . . . . . 4 5. Identity Association for Service-Oriented Addresses . . . . . 4 5.1 IA_SA 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 May 26, 2005 [Page 2] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 1. Introduction IPv6 Addressing Architecture [RFC3513] defines a new addressing scheme called "anycast address" that 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. DHCPv6 base specification [RFC3315] provides a way for the DHCPv6 clients to get permanent/temporary unicast addresses from a DHCPv6 Server. This document provides a way for assigning an address to a Service provided by the DHCPv6 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 IA_SA option in DHCPv6 for Service-Oriented Address assignment for a particular type of service that DHCPv6 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 IPv6 Anycast has been adopted by IPv6 and has been defined in [RFC3513]. But its usage has been restricted to nodes which are routers. However, [I-D.ietf-ipngwg-ipv6-anycast-analysis] provides few guidelines to extend its usage to Hosts and also provides various other forms of anycasting usages that are in practice (e.g. Shared Anycast Addresses). 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 May 26, 2005 [Page 3] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 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. DHCPv6 specification dependency This document describes new DHCPv6 option for service-oriented address assignment. This document should be read in conjunction with the DHCPv6 specification [RFC3315]. Definitions for terms and acronyms not specifically defined in this document are defined in [RFC3315]. 5. Identity Association for Service-Oriented Addresses An IA_SA is a construct through which a server and a client can identify, group and manage a set of related IPv6 service-oriented addresses. Each IA_SA consists of an IAID and associated configuration information. An IA_SA for Service-Oriented Address is similar to IA_NA as described in [RFC3315] for unicast permanent addresses. The choosing of IA_SA IAID is similar to IA_NA IAID and IA_TA IAID. More details on choosing an IAID is given in [RFC3315]. The configuration information in an IA_SA consists of one or more IPv6 Service- Oriented Addresses for each Service Type along with the times T1 and T2 for the IA_AA. 5.1 IA_SA Option Format The Identity Association for Service-Oriented Addresses (IA_SA) option is used to carry an IA_SA, the parameters associated with the IA_SA, and the anycast/shared unicast addresses or well-known unicast addresses associated with the IA_SA. The format of the IA_SA option is: Madanapalli, et al. Expires May 26, 2005 [Page 4] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_SA | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service-Type |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA_SA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field description o option-code: OPTION_IA_SA (TBD). o option-len: 16 + length of IA_SA-options field. o IAID: The unique identifier for this IA_SA; the IAID must be unique among the identifiers for all of this client's IA_SAs. The number space for IA_SA IAIDs is separate from the number space for IA_NA IAIDs and IA_TA IAIDs. o Service-Type: The Service Type for which Anycast/Shared Unicast/ Well-Known Address to be assigned. A: 1-bit Flag, indicates if the address is an anycast address. o T1: The time at which the client contacts the server from which the addresses in the IA_SA were obtained to extend the lifetimes of the addresses assigned to the IA_SA; T1 is a time duration relative to the current time expressed in units of seconds. o T2: The time at which the client contacts any available server to extend the lifetimes of the addresses assigned to the IA_SA; T2 is a time duration relative to the current time expressed in units of seconds. o IA_SA-options: Options associated with this IA_SA. Madanapalli, et al. Expires May 26, 2005 [Page 5] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 The IA_SA-Options field encapsulates those options that are specific to this IA_SA. For example, all of the IA Address Options [RFC3315] carrying the addresses associated with this IA_SA are in the IA_SA-options field. An IA_SA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_SA options. The T1 and T2 parameters in IA_SA option are similar to T1 and T2 parameters in IA_NA option, refer [RFC3315] for more details. 6. Overview of Service-Oriented Address Assignment The DHCPv6 Client that wants to get Service-Oriented Address for a specific service Type includes IA_SA option in the Solicitation and/or Request that it sends to DHCPv6 Server with the Service-Type. If the client requires Service-Oriented addresses for multiple service types, it can include multiple IA_SA option fields in Solicitation and/or Request Messages. The DHCPv6 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 DHCPv6 Server to assign to the clients, then the server fills the Service-Oriented Address in IA Address Option which will be included in IA_SA Option that will be sent in Advertise/Reply Message to the DHCPv6 Client. If there are multiple Service-Oriented Address available for the same service type the server can typically includes multiple IA Address Options in IA_SA Option. 7. Security Considerations The DHCPv6 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 [RFC3315]. This option does not create any additional risk of such attacks. To guard against such "man in the middle" attacks, the DHCPv6 client SHOULD use authenticated DHCP as described in section 21, "Authentication of DHCP messages" of RFC 3315. 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 Madanapalli, et al. Expires May 26, 2005 [Page 6] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 OPTION_IA_AA TBD Section 5.1 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 o Defining similar option for DHCPv4. 10. References 10.1 Normative References [I-D.ietf-ipngwg-ipv6-anycast-analysis] Hagino, J. and K. Ettican, "An analysis of IPv6 anycast", draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in progress), June 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 10.2 Informative References [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. 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 May 26, 2005 [Page 7] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 Suraj Kumar Samsung India Software Operations J. P. Techno Park, 3/1 Millers Road, Bangalore 560052 INDIA Phone: +91 80 51197777 EMail: suraj.kumar@samsung.com 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 May 26, 2005 [Page 8] Internet-Draft Service-Oriented Address Assignment Using DHCPv6 November 2004 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 (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 Funding for the RFC Editor function is currently provided by the Internet Society. Madanapalli, et al. Expires May 26, 2005 [Page 9]