IP Version 6 Working Group S. Matsunaga Internet-Draft Osaka University Expires: August 21, 2005 S. Ata Osaka City University H. Kitamura NEC Corporation M. Murata Osaka University February 14, 2005 Applications of IPv6 Anycasting draft-ata-ipv6-anycast-app-01.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 21, 2005. Copyright Copyright (C) The Internet Society (2005). Abstract This document describes the applications and characteristics of S. Matsunaga, et al. Expires August 2005 [Page 1] INTERNET-DRAFT Applications of IPv6 Anycasting February Anycast, which is network addressing and routing scheme that routes data through the best destination. The primary purpose of this document is to describe the many advantages and applications of Anycast and hopefully, to motivate you to consider new applications of Anycast. 1. Introduction Although [RFC2460] defines anycast, it is currently not being widely used. One reason is that it was only defined briefly, and the numerous practical applications and flexibility of the scheme have not yet been clearly described. Therefore, we will describe anycast applications and characteristics, and how they can be applied to enhance your current networking systems. By increasing public awareness about the flexibility, advantages, and potential applications for the scheme, the documents ivolves to popularize anycast and motivate people to use it to expand their current networking capabilities. One of the reasons that anycast is not widely used is that [RFC3513] only addressed and defined the architecture without defining the other specifications and terms. For clarity, we will use the term as defined by [ANY-TERM]. Scope of this Document Anycast is not only limited to network (i.e., IP) layers, but can also be implemented/used in other (e.g., application) layers. In this document, we focus on network-layer anycast, which is defined in IPv6 specification [RFC3513]. 2. Anycast Characteristics and Applications In this section, we will describe anycast characteristics and applications as they apply to [RFC3513], which describes the specifications of anycast addresses. First, we will describe the actual and potential anycast characteristics, based on these specifications. Then, we will describe the anycast applications that correspond to each anycast characteristic. The anycast characteristics will appear in either the IP layer, transport layer or application layer because IPv6 anycast is the technique in the IP layer. At this point, we can categorize anycast characteristics into three categories: the IP, the transport, and the application layers, in addition to ones in other layers that are not S. Matsunaga, et al. Expires August 2005 [Page 2] INTERNET-DRAFT Applications of IPv6 Anycasting February described in this draft. The characteristics of the IP layer are described in 2.1; the characteristic of the transport layer are described in 2.2; and the characteristics of the application layer are described in 2.3. 2.1. Characteristics of IP layer and Applications In this section, we will describe the anycast IP layer characteristics, as they relate to all anycast characteristics and applications that each characteristic applies to. In the IP layer, anycast characteristics are categorized into three types, the initiator, the responder, and the intermediate node views, according to each aspect of the node that sends, receives, and forwards the packets. 2.1.1. Anycast Initiator View In this section, we will describe the characteristics for the anycast initiator and anycast applications that each characteristic applies to. o Characteristic: Source Specific Anycast Application : Local Information Service In unicast, nodes usually communicate with the same node if the same unicast address is the destination. On the other hand, in anycast each Anycast initiator (AI) can communicate with different Anycast Responders (ARs) depending on the appropriateness of them, even if the same anycast address is the destination. Although various way can be considered to switch AR, the source specific anycast is one of those way. The source specific anycast which is the way that AR is selected by AI's information as same as the source specific multicast matches the model of anycast very well. Therefore, anycast communication can be used for applications that change the AR depending on the AI's information. Local information service is given to applications that make the best use of this characteristic. Local information services communicate with the appropriate server for the client as the way you call the telephone to the appropriate emergency facilities for the caller's place. The local information service in the IP layer are achieved by getting each AI to communicate with the appropriate server to the AI's location. S. Matsunaga, et al. Expires August 2005 [Page 3] INTERNET-DRAFT Applications of IPv6 Anycasting February One situation where this application is very useful is when the mobile node uses the services. Different servers are often used by the mobile node after it moves from one subnet to another, even if it continues to use the same service. Then, if the same anycast address is assigned to the servers and can be used from both subnets, we can establish a network environment in which the mobile node can automatically use the most appropriate server when moving. This model is similar model of mobile IP which a corresponding node can communicate with the mobile node by using the same address which is called home address. o Characteristic: Communication with Scope Application : Service Discovery One or more ARs belong to an anycast group with the same anycast address. If each AI has a scope, AI can limit those ARs which can communicate with AI. The scope of multicast limits the communication between a node in the scope and a node outside the scope and a sender communicates with all nodes in the scope.But AI communicates with one of all ARs in the scope although the scope of anycast limits the communication such as multicast. In other words, anycast with scope is useful for applications that choose candidates from all ARs for each AI. Service discovery is given to the application that makes the best use of this characteristic. In this application, a packet is automatically forwarded to an appropriate AI server, so that AI only specifies the anycast address as a server address, allowing each AI to automatically use the service. At this time, AI communicates with the AR that exists in the constant range specified by the AI's scope. Further, DHCPv6 and SLP are proposed as service discovery techniques. However, in these techniques a client or a server must advertise a message that broadcasts over the subnet, and service discovery is provided only within the range where the message is advertised. On the other hand, in anycast service discovery, each client can specify the range of the discovery service based on its scope. Therefore, the client can use service discovery without depending on other nodes. This application is well suited to the IPv6 plug and play model. 2.1.2. Anycast Responder View In this section, we will describe the anycast characteristics of the anycast responder and the applications for each characteristic it S. Matsunaga, et al. Expires August 2005 [Page 4] INTERNET-DRAFT Applications of IPv6 Anycasting February applies to. o Characteristic: Independent Address Assignment from/based on the Unicast Address Application : Plug and Play of Server In IPv6, one or more IP addresses can be assigned to an interface. However, packets are generally delivered to the subnet with the same prefix as the destination address of the packet. Therefore, if the address which doesn't have the prefix of the subnet is assigned to the interface, there are many troubles for the receiver. However, in global anycast, AR can receive packets whose destination does not contain a subnet prefix because anycast has another space from the unicast as same as the multicast has. In addition, AR can continue to receive packets from AI while the AR anycast address remains unchanged, even if the AR unicast address changes, as long as AI uses the service with the anycast address. Therefore, communications that do not depend on AR unicast addresses are possible using anycast, because AI uses only one (or, is constant numerical) anycast address, even if there is an increase or decrease in the number of ARs. Using these characteristics, plug and play of server is given as an application.IP address of the server commonly doesn't get decided until you configure the server. If the address is configured automatically, clients are not able to know the address of the server. Therefore, you need configure the fixed (unicast) address to the server manually when the server provides a service in the global network. But, in this way, the management of the server saves you a lot of effort for as follow reasons: - the address need have the prefix of the subnet - the address need be advertised to the global network - the address need be changed when the server moves to the other subnet. In other words, you hope to be able to provide services by only auto configuration. But, in networks with global anycast, plug and play of server is achieved as you can decide the address for services by the above characteristic before you configure the server. In addition, if you modify the application which listens by an anycast address instead of "in_addr any", you can decide the address of the service when you make the application. As a result, you don't need manual assignment of the address when you configure the server. S. Matsunaga, et al. Expires August 2005 [Page 5] INTERNET-DRAFT Applications of IPv6 Anycasting February o Characteristic: Communication Zone Application : Load Balancing One AR does not need to communicate with all the AIs when two or more ARs belong to a specific anycast group, and the AI of each AR can be allotted/allocated?. This means that each AR can limit the communication range by specifying a zone. This characteristic, allows anycast to be used even with applications that limit the range of the provider's service. The use of load balancing is an application that uses this characteristic. When the service range is selected by specifying a zone, the server only provides service to the AI that exists in that zone. The number of zones increases when the service provider increases the AR according to the service requirements/demands, allowing it to divide zones serviced by only one server into zones with two or more servers. As a result, anycast can more effectively balance loads because each AI can communicate with the corresponding AR. o Characteristic: Automatic Switching to Alternate Routes Application : Service Redundancy In unicast, there is only one receiver corresponding to each unicast address, so unicast routing forwards the packet to that receiver. The packet is unreachable and routing ends when the packet can no longer be forwarded, because the destination of the packet is uniquely selected by unicast. Therefore, to communicate with another node when we cannot communicate with the receiver, the necessity for specifying a new destination address falls upon the sender. Anycast, strives to deliver the packet to the best AR, because it is unacceptable to forward the packet to an AR that cannot receive. The same anycast address is assigned to interfaces as for ARs belonging to the anycast group. In this case, the packet's destination node can be changed into another AR because all ARs can receive packets with an anycast destination address. The packet is forwarded to AR for AI as usual. Then if the node detects that the packet is unable to forward it to the specified AR, then it tries to deliver it to another available AR. Then, if it is possible to switch automatically, the intermediate node and AI are both accepted as nodes that detect unreachable destinations and the packet is forwarded to another AR. This characteristic allows anycast to be used for applications that need to maintain a state in which each AI can communicate with any AR. S. Matsunaga, et al. Expires August 2005 [Page 6] INTERNET-DRAFT Applications of IPv6 Anycasting February Service redundancy is an application that uses this characteristic. This application maintains the state in which service can be used in the same address by one or more ARs and can improve service redundancy. Clients need to search for the address of another server and then restart/reestablish communication to it when they cannot use the communicating server. On the other hand, using anycast, the clients do not need to worry because anycast automatically establishes communication with another server using the same address. 2.1.3. Intermediate Node View In this section, we will describe the anycast characteristics for nodes other than AI/AR and the anycast applications that each characteristic applies to. o Characteristic: Traffic Distribution Application : Avoid DoS Attack Traffic can be distributed when the intermediate node (or, AI) retains information from multiple routes to AR in the routing table that can be an anycast packet or switching destination, and so on. Anycast can manage the band when required. Avoiding a DoS attacks is an application that uses this characteristic. Even if a DoS attack is undetectable and increases traffic to a a single node abnormally, we can prevent it from accumulating on a single route by distributing the traffic to two or more routes. In addition, after the DoS attack has been detected, we can avoid future attacks by forwarding the packet to a camouflage server, such as a honey pot rather than rejecting the packet altogether. 2.2. Characteristics in Transport Layer and Applications In this section, we will describe the anycast characteristics in the transport layer for all the applicable anycast characteristics and applications. o Characteristic: AR Selection based Connection Application : Multiple Server Access As described in 2, data passed from the application is divided in the sender's transport layer, and restored in the receiver's S. Matsunaga, et al. Expires August 2005 [Page 7] INTERNET-DRAFT Applications of IPv6 Anycasting February transport layer. To properly transmit the divided data to the same node, a connection is established between both nodes in the transport layer. At this time, AI can use AR according to each connection by sending a packet to the anycast address that establishes a connection. Therefore, using this characteristic, we can achieve applications that communicate with different ARs according to the connection. Multiple server access is an application that uses this characteristic. When anycast is used with an application that establishes multiple connections to the same unicast address, each connection is automatically established with different servers that specify the same anycast address. As a concrete illustration, when a client browses a web page, they download the html file and each picture file from separate mirror servers. As a result, the client can use the entire bandwidth, and can download the whole web page more quickly than with unicast. 2.3. Characteristics in Application Layer and Applications In this section, we will describe the anycast characteristics in the application layers for all applicable anycast characteristics and applications. o Characteristic: Cross-Platform API with Unicast Application : Easy Installation of Anycast Because IPv6 anycast is performed in the IP layer, the application layer can communicate with anycast characteristics only when using an anycast address instead of a unicast address. The difference between anycast and unicast in the application layer is whether the destination of the communication is an anycast or a unicast address. However, because both addresses have the same format, there is no difference in the applications can use these addresses with same API to communicate between a single sender and single receiver. This means anycast characteristics can be added to the existing services being provided by unicast without changing the application operation in the application layer. Anycast's easy installation feature is an application that uses this characteristic. Anycast characteristics can be added to services without changing the protocol and operations for the various services provided in the application layer. When high reliability service is provided for special distribution devices, we need to enable the devices and servers to work together. However, anycast applications are added to services only if the S. Matsunaga, et al. Expires August 2005 [Page 8] INTERNET-DRAFT Applications of IPv6 Anycasting February servers use an anycast address to receive packets, while performing same operations as the unicast address. Therefore, we can complete anycast installation simply by assigning an anycast address to the interface of each server. Then, the various functions described in this draft can be added to the applications. 3. Security Considerations This draft does not include any security issues of anycast. Other security descriptions about anycast are shown in [ANALYSIS]. S. Matsunaga, et al. Expires August 2005 [Page 9] INTERNET-DRAFT Applications of IPv6 Anycasting February 4. References [RFC2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998. [RFC3513] R. Hinden, and S. Deering, "IP Version 6 Addressing Architecture," RFC3513, April 2003. [ANY-TERM] Hashimoto, M., Ata, S., Kitamura, H., Murata, M., "IPv6 Anycast Terminology Definition," , February 2005 "work in progress." [ANALYSIS] Hagino, J., and Ettikan, K., "An Analysis of IPv6 Anycast," , June 2003 "work in progress." S. Matsunaga, et al. Expires August 2005 [Page 10] INTERNET-DRAFT Applications of IPv6 Anycasting February Authors' Addresses Satoshi Matsunaga Osaka University 1-5, Yamadaoka, Suita Osaka, 565-0871, Japan Phone: +81-6-6850-6863 FAX: +81-6-6850-6868 EMail: s-matung@ist.osaka-u.ac.jp 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 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 S. Matsunaga, et al. Expires August 2005 [Page 11] INTERNET-DRAFT Applications of IPv6 Anycasting February 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. S. Matsunaga, et al. Expires August 2005 [Page 12]