IP Version 6 Working Group S. Ata Internet-Draft Osaka City University Expires: June 6, 2005 H. Kitamura NEC Corporation M. Murata Osaka University December 7, 2004 Applications of IPv6 Anycasting draft-ata-ipv6-anycast-app-00 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 April 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Today, the use of IPv6 anycast is limited. One of the main reasons is because the usage (in other words, application) of IPv6 anycasting still unclear. This document tries to describe some applications to Ata, et al. Expires April 18, 2005 [Page 1] Internet-Draft Applications of IPv6 Anycasting October 2004 which IPv6 anycasting intends to resolve. We also discuss functionalities on anycast nodes needed to realize such applications. Ata, et al. Expires April 18, 2005 [Page 2] Internet-Draft Applications of IPv6 Anycasting October 2004 1. Introduction Anycast is defined as one of new IPv6 features, which supports service-oriented address assignments in IPv6 networks. Anycast address is not determined by the location of node, but by the type of service presented at the node. In anycast communication, the client can automatically locate the appropriate node corresponding to a specific service without knowledge of the location of the server. This appropriateness is determined by routing protocols' measure of distance. However, anycast is hardly used (except for MIPv6 HA address) now. This is because there are several technical problems, which were described in [ANALYSIS]. Another reason is that the usage of anycast is still unclear. In this document, we clarify the usage of anycast with some examples. Then, we show the applications suitable for anycast and analyze the functionalities of anycast. Scope of this Document The notion of anycast is not only limited to the network (i.e., IP) layer, but can also be achieved in other (e.g., application) layers. In this document, we focus on network-layer anycast, which is defined in IPv6 specification [ADDR-ARCH]. 2. Characteristics/Observations of Anycast The motivation for anycast, described in [ANYCASTING], is that it simplifies the task of finding an appropriate server. One of the questions we try to answer is "What is the merit of using anycast?" In the following sections, we first present several scenarios where anycast is suitable to use. Next, we show some advantages of using anycast. After that, we list what kinds of functionalities are required to realize these scenarios. 2.1 Application Scenarios As already discussed in [ANYCASTING], one of the major applications of anycasting is to establish a server/service discovery. Mirrored FTP sites can share a single anycast address, and users would simply perform an FTP to the anycast address to reach the nearest server. By controlling routing mechanism appropriately, the anycast initiator can communicate with an optimal (e.g., minimum delay or high throughput) anycast receiver chosen from multiple anycast members by specifying the anycast address. Additional examples listed below clearly demonstrate characteristics of anycasting. Ata, et al. Expires April 18, 2005 [Page 3] Internet-Draft Applications of IPv6 Anycasting October 2004 o Load Distribution If we utilize some appropriate routing mechanism for anycasting, anycast packets are evenly distributed to the anycast initiators. o Improving System Reliability By increasing the number of anycast receivers, system reliability can be improved because it still works even if some of these fail. o Host Auto-configuration By defining and assigning a well-known anycast address to widely used applications (e.g., DNS and proxy services), an anycast initiator can use these services without setting the address of the server. o Gate to Overlay Network A distributed application like a P2P (Peer-to-Peer) service constructs a logical network topology among nodes participating in the service. By defining and assigning a well-known anycast address to all peers, each peer only specifies the anycast address in order to participate in the logical network. o Local Information Service We can consider other new services and those for local information such as "Emergency Calls (e.g., call for an ambulance)" can be introduced by defining a common anycast address to assign that certain service. This means an anycast initiator can reach a nearby service offered by the anycast receiver by using that address. 2.2 Advantages of Anycasting Auto configuration through anycasting is quite effective during the primitive setup phase (e.g., DNS server cannot be used). When a host is plugged in, its IPv6 address is configured automatically. However, to achieve true plug&play, various settings are necessary (e.g., configuring unicast addresses of DNS server). If a well-known anycast address is installed in the hardware beforehand, end users can utilize DNS service without complicated configuration. It would be sufficient to send a query to a well known DNS anycast address. Moreover, in the current P2P application, the peer needs to know the IP address (i.e., unicast address of a peer) to connect the logical network prior to participating in the service. However, with Ata, et al. Expires April 18, 2005 [Page 4] Internet-Draft Applications of IPv6 Anycasting October 2004 anycasting, each peer only specifies the anycast address to participate in the logical network. The advantage of this model is that all processes are completed within its own protocol. Like above examples, only anycasting has the following advantages that existing application-layer technologies cannot realize. o Transparency Anycast addresses are allocated from the unicast address space. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. So, the clients do not need to know whether the destination address is unicast or anycast. Only anycast receivers are explicitly configured to know that it is an anycast address. This obviates the need to change of client and server applications. Moreover, in application-layer anycasting, to realize the access to appropriate server providing specific service, service location tools (i.e., directory server) are necessary. However, even if the server works correctly, trouble of the directory server can cause unreachable to the server. On the other hand, network-layer anycasting can help realize appropriate server selection by only specifying an IP address. The directory server is no longer necessary to discover services. o Separation of application and routing policy Each application has different appropriateness. In application-layer anycasting, this application-dependent information managed for each application is required to realize appropriate server selection. So, different routing architecture is required for each application to support different appropriateness. On the other hand, network-layer anycasting reduces this troublesome task and can be used for all applications. Each appropriateness can be mapped to one criterion, and the routing architecture of network-layer anycasting works based on the criterion. Then, each application can use the routing architecture to support different appropriateness. Anycasting relaxes the routing architecture from the application-dependent information. 2.3 Functionalities for Anycast Applications 2.3.1 Basic Functionality Ata, et al. Expires April 18, 2005 [Page 5] Internet-Draft Applications of IPv6 Anycasting October 2004 Before considering each application, we show the basic (i.e., minimum) functionalities to realize anycast communications. o Supporting unicast forwarding Anycast addresses are syntactically indistinguishable from unicast address. Then, - if the receiving packet is not an anycast packet, each anycast router MUST forward the packet as a unicast packet. Moreover, this functionality is necessary to retain backward compatibility. So, - if we replace existing routers with anycast routers, they MUST do all tasks of existing routers. o Reachability to the server To ensure reachability to the server, it is necessary for routers to forward the packet destined to the anycast address. To forward packets, - anycast routers SHOULD have routing entry of receiving anycast packet. If the router does not have the routing entry for the receiving packet in the routing table, it simply discards the packet. Moreover, only anycast receivers can identify the anycast address, because it is not identified by address itself. So, anycast routers cannot identify anycast address unless the anycast receivers notify them. Then, - each anycast receiver MUST notify a neighbor router of its membership information. Above two functionalities are not necessary only when the anycast address is subnet anycast. 2.3.2 Functionalities to Realize Advantages of Anycasting In this section, we show what kinds of functionalities are required to realize the advantages of anycasting. o Transparency Following functionalities are required to realize the Ata, et al. Expires April 18, 2005 [Page 6] Internet-Draft Applications of IPv6 Anycasting October 2004 transparency. - If an anycast router receives an anycast packet, the router MUST forward it to one anycast receiver. If multiple packets are sent to an anycast address, multiple reply packets may be delivered to the anycast initiator. This does not give much transparency to the initiator because the client application cannot decide the appropriate server. Of course, if the anycast router keeps only one routing entry for receiving packet, the router simply forwards the anycast packet according to the entry. However, if there are multiple candidate entries for receiving anycast packet, following functionalities are necessary. * Anycast routers SHOULD have anycast selection criteria. * Anycast routers SHOULD have the knowledge to select one entry. * Anycast receivers MAY notify a neighbor router of its preference value (e.g., metric). These are unique functionalities for anycast communication. - Well-known anycast address MAY be defined. To discover specific servers without directory servers, defining well-known anycast address is needed for each service. It can be done by IANA. o Separation of application and routing policy Following functionalities are required to realize this advantage. - Anycast Receivers MAY notify a neighbor router of its preference value (e.g., metric). 2.3.3 Other Functionalities Moreover, following functionality is required to realize anycast communication. o Introducing Scope As described in [ANALYSIS], the use of anycast addresses may lack scalability. To improve scalability of routing protocol, it is necessary to limit the range of sending route information to an Ata, et al. Expires April 18, 2005 [Page 7] Internet-Draft Applications of IPv6 Anycasting October 2004 anycast address. Then, - anycast routers MAY handle scope to limit the range of sending routing information. 3. Security Considerations This draft does not include any security issues of anycast. Other security descriptions about anycast are shown in [ANALYSIS]. Ata, et al. Expires April 18, 2005 [Page 8] Internet-Draft Applications of IPv6 Anycasting October 2004 4. References 4.1 Normative References [ANYCASTING] Partridge, C., and Mendez, T., and Milliken, T., "Host Anycasting Service," RFC1546, November 1993 [ADDR-ARCH] Hinden, R., and Deering, S., "IP Version 6 Addressing Architecture," RFC3513, April 2003. [ANALYSIS] Hagino, J., and Ettikan, K., "An Analysis of IPv6 Anycast," , June 2003 "work in progress." [SUBNET] Johnson, D., and Deering, S., "Researved IPv6 Subnet Anycast Addresses," RFC2526, March 1999. [ND] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. [AARP] ATA, S., Kitamura, H., and Murata, M., "A Protocol for Anycast Address Resolving," , June 2002. 4.2 Informative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ADDR-AUTO] Thomson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration," RFC2462, December 1998. Authors' Addresses Shingo Ata Osaka City University 3-3-138, Sugimoto, Sumiyoshi-ku Osaka, 558-8585 Japan Phone: +81-6-6605-2191 Fax: +81-6-6690-5382 EMail: ata@info.eng.osaka-cu.ac.jp Ata, et al. Expires April 18, 2005 [Page 9] Internet-Draft Applications of IPv6 Anycasting October 2004 Hiroshi Kitamura NEC Corporation (Igarashi Building 4F) 11-5, Shibaura 2-Chome Minato-ku, Tokyo 108-8557 Japan Phone: +81-3-5476-1071 Fax: +81-3-5476-1005 EMail: kitamura@da.jp.nec.com Masayuki Murata Osaka University 1-5 Yamadaoka, Suita Suita-shi, Osaka 565-0871 Japan Phone: +81-6-6879-4543 Fax: +81-6-6879-4544 EMail: murata@ist.osaka-u.ac.jp Ata, et al. Expires April 18, 2005 [Page 10] Internet-Draft Applications of IPv6 Anycasting 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. Ata, et al. Expires April 18, 2005 [Page 11]