Network Working Group S. Madanapalli Internet-Draft O. Rao Expires: April 16, 2005 Samsung ISO S. Daniel Park Samsung Electronics October 16, 2004 Anycast Address Assignment using DHCPv6 draft-madanapalli-dhcpv6-anycast-00.txt 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 http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document introduces a new option in DHCPv6 for Anycast/Shared Unicast 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 Anycast Address assignment requires the specification of Service Type of the Anycast or Shared Unicast Address. Madanapalli, et al. Expires April 16, 2005 [Page 1] Internet-Draft Anycast Address Assignment Using DHCPv6 October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statements . . . . . . . . . . . . . . . . . . . 3 4. DHCPv6 specification dependency . . . . . . . . . . . . . . . 4 5. Identity Association for Anycast Addresses . . . . . . . . . . 4 5.1 IA_AA Option Format . . . . . . . . . . . . . . . . . . . 4 6. Overview of Anycast Address Assignment . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Future Works . . . . . . . . . . . . . . . . . . . . . . . . . 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 April 16, 2005 [Page 2] Internet-Draft Anycast Address Assignment Using DHCPv6 October 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. DHCPv6 base specification [RFC3315] provides a way for the DHCPv6 clients to get permanent/temporary unicast addresses from a DHCPv6 Server. This document introduces a new IA_AA option in DHCPv6 for Anycast/Shared Unicast 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 Anycast Address assignment requires the specification of Service Type of the Anycast or Shared Unicast Address. 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 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 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. Madanapalli, et al. Expires April 16, 2005 [Page 3] Internet-Draft Anycast Address Assignment Using DHCPv6 October 2004 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 options for IPv6 anycast 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 Anycast Addresses An IA_AA is a construct through which a server and a client can identify, group and manage a set of related IPv6 anycast addresses. Each IA_AA consists of an IAID and associated configuration information. An IA_AA for anycast address is similar to IA_NA as described in [RFC3315] for unicast permanent addresses. The choosing of IA_AA 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_AA consists of one or more IPv6 anycast addresses for each Service Type along with the times T1 and T2 for the IA_AA. 5.1 IA_AA Option Format The Identity Association for Anycast Addresses option (IA_AA option) is used to carry an IA_AA, the parameters associated with the IA_AA, and the anycast addresses associated with the IA_AA. The format of the IA_AA option is: Madanapalli, et al. Expires April 16, 2005 [Page 4] Internet-Draft Anycast Address Assignment Using DHCPv6 October 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_AA | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA_AA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field description o option-code: OPTION_IA_NA (TBD). o option-len: 16 + length of IA_AA-options field. o IAID: The unique identifier for this IA_AA; the IAID must be unique among the identifiers for all of this client's IA_AAs. The number space for IA_AA 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 is required. o T1: The time at which the client contacts the server from which the addresses in the IA_AA were obtained to extend the lifetimes of the addresses assigned to the IA_AA; 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_AA; T2 is a time duration relative to the current time expressed in units of seconds. o IA_AA-options: Options associated with this IA_AA. The IA_AA-Options field encapsulates those options that are specific to this IA_AA. For example, all of the IA Address Options [RFC3315] Madanapalli, et al. Expires April 16, 2005 [Page 5] Internet-Draft Anycast Address Assignment Using DHCPv6 October 2004 carrying the addresses associated with this IA_AA are in the IA_AA-options field. An IA_AA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_AA options. The T1 and T2 parameters in IA_AA option are similar to T1 and T2 parameters in IA_NA option, refer [RFC3315] for more details. 6. Overview of Anycast Address Assignment The DHCPv6 Client that wants to get anycast/shared unicast/well-known address for a specific service Type includes IA_AA option in the Solicitation and/or Request that it sends to DHCPv6 Server with the Service-Type. If the client requires anycast addresses for multiple service types, it can include multiple IA_AA option fields in Solicitation and/or Request Messages. The DHCPv6 server then checks the availability of the anycast/shared unicast/well-known addresses for the requested service type. If there is an anycast/shared unicast/well-known address configured in the DHCPv6 Server to assign to the clients, then the server fills the anycast/shared unicast/well-known address in IA Address Option which will be included in IA_AA Option that will be sent in Advertise/Reply Message to the DHCPv6 Client. If there are multiple anycast addresses available for the same service type the server can typically includes multiple IA Address Options in IA_AA Option. 7. Security Considerations The DHCPv6 Option defined here allows a malicious server providing incorrect address information to the client, causing users with valid anycast 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 OPTION_IA_AA TBD Section 5.1 Madanapalli, et al. Expires April 16, 2005 [Page 6] Internet-Draft Anycast Address Assignment Using DHCPv6 October 2004 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 Works 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 April 16, 2005 [Page 7] Internet-Draft Anycast Address Assignment Using DHCPv6 October 2004 OLN Rao Samsung India Software Operations J. P. Techno Park, 3/1 Millers Road, Bangalore 560052 INDIA Phone: +91 80 51197777 EMail: olnrao@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 April 16, 2005 [Page 8] Internet-Draft Anycast Address Assignment Using DHCPv6 October 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 April 16, 2005 [Page 9]