INTERNET-DRAFT S. Doi Osaka University I. Khalil Osaka University S. Ata Osaka City University H. Kitamura NEC Corporation M. Murata Osaka University Expires in six months 9 February 2003 IPv6 Anycast Functionality/Terminology Definition Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Today, the use of IPv6 anycast is limited. This is because the usage of IPv6 anycast is still unclear. This document first defines the terminology of anycast not only for the rest of this document, but also for future discussion. Then we describe the usage of IPv6 anycast with several examples. Moreover, we describe the functionalities of anycast. S. Doi [Page 1] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 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 first define the terminology for anycast, which will be useful not only for the rest of this document, but also for future discussions. Then, we clarify the usage of anycast with some examples. We show the applications suitable for anycast and analyze the functionalities of anycast. 1.1 Requirement Language 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 RFC 2119 [RFC-2119]. 1.2 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. Terminology Definition We first define some basic terms related to anycast. These definitions will assist in describing the following terminology definitions. o Anycast Packet Anycast packet means the packet whose destination address is set to an anycast address. o Anycast Communication S. Doi [Page 2] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 Anycast communication is the communication using anycast packets. o Anycast Routing Anycast routing means the routing method to transfer anycast packets. The first subsection describes some basic functionalities of anycast to define the terminology of architectural components; the second describes the address assignment issues of anycast to define the terminology concerning address assignment; the last subsection introduces other terminology related to anycast. 2.1 Architectural Components As described in [ADDR-ARCH], a packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to some appropriately defined metric of anycast routing). Figure 1 shows a simple anycast communication. There are three nodes which have the same anycast address "AA". When node "AI" sends a packet to anycast address "AA", the packet is transferred to the node "AR2", which is chosen by the anycast routing. +-- Anycast Membership --+ | +-----+ | | | AR1 | (Anycast: AA) | | +-----+ (Unicast: UA1) | | | +----+ Anycast Routing | +-----+ | | AI |------------------------>| AR2 | (Anycast: AA) | +----+ to appropriate node | +-----+ (Unicast: UA2) | | | | +-----+ | | | AR3 | (Anycast: AA) | | +-----+ (Unicast: UA3) | +------------------------+ Fig. 1 anycast communication (simple model) o Anycast Initiator Anycast initiator means the node that initiates anycast communication. In Fig. 1, AI shows anycast initiator. S. Doi [Page 3] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 o Anycast Receiver Anycast receiver means the node which is configured with an anycast address. In Fig. 1, AR1, AR2, and AR3 correspond to anycast receiver. o Anycast Router Anycast router means the router that can deal with anycast routing. o Anycast Membership Anycast membership means the set of anycast receivers which share the same anycast address. o Anycast Member Anycast member means the anycast receiver which belongs to the anycast membership. When an anycast initiator sends an anycast packet, only one of anycast members can receive the anycast packet at any time. We define this receiver as Selected Anycast Receiver. o Selected (Corresponding) Anycast Receiver Selected anycast receiver means the node which actually communicates with the anycast initiator. In Fig. 1, AR2 corresponds to selected anycast receiver. o Anycast Communication Path Anycast communication path means the path that an anycast packet traverses in anycast communication. o Corresponding (Resolved) Unicast Address Corresponding unicast address means the unicast address of a specific anycast receiver. In Fig. 1, UA2 is the corresponding unicast address for the anycast receiver AR2. S. Doi [Page 4] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 2.2 Addressing Anycast addresses belong to the unicast address spaces [ADDR-ARCH], but, unlike unicast, assignment of anycast addresses is not determined by the node location. Henceforth, we need to consider what kind of addresses should be assigned to the anycast address. First, we define the following two types of anycast address. The assignment of anycast address depends on whether all anycast receivers are on the same segment or on different segments. It is also true for the anycast address assignment policy. If all anycast receivers are connected to the same segment, the anycast address can be assigned with its segment's prefix. On the other hand, if anycast receivers are on different segments, we describe later as Global Anycast. o Subnet Anycast Subnet Anycast means an anycast address whose address prefix is determined based on the node's unicast address prefix. Its interface-ID is determined arbitrarily. All anycast receivers that share the same anycast address are connected to the same segment. In unicast routing, routers forward packets by prefix routing. Therefore, packets having a unicast address as a destination address can reach the last hop router by unicast routing. When the last hop router receives the anycast packets, selected anycast receiver is determined by the Neighbor Cache [ND] of the last hop router. S. Doi [Page 5] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 +----+ | AI | +-+--+ | +--+-----------------------+ | | | Internet | | | +---------------------+----+ | +--+-+ | R | Anycast Router +--+-+ | ---+----+---+---------+---- | | | +--+--+ +--+--+ +--+--+ | AR1 | | AR2 | | AR3 | +-----+ +-----+ +-----+ same anycast address: AA Anycast Address AA: | n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix (= segments' prefix) | arbitrarily | +------------------------------------------------+----------------+ Fig. 2 Subnet Anycast o Global Anycast Global anycast means an anycast address whose address prefix and interface-ID are determined arbitrarily. Generally, nodes having that address are located on different segments. S. Doi [Page 6] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 +----+ | AI | +-+--+ | +--+-----------------------+ | | | Internet | | | +----+-----------------+---+ | | +-+--+ Anycast +--+-+ | R1 | Router | R2 | +-+--+ +--+-+ | | --+---+-- ----+---+---- | | +--+--+ +--+--+ | AR1 | Anycast | AR2 | +-----+ Receiver +-----+ same anycast address: AA Anycast Address AA: | 128 bits | +-----------------------------------------------------------------+ | Anycast Address | +-----------------------------------------------------------------+ Fig. 3 Global Anycast Moreover, by introducing a "Unicast Seed", the anycast routing based anycast address can be divided into the following two types of addresses. "Unicast Seed" is a representative node of the anycast receivers. o Anycast Address with Unicast Seed Anycast address with unicast seed means an anycast address whose address prefix is determined from one (called "Seed") of its anycast membership. All other nodes belonging to the same anycast membership have an address prefix of the seed node. Packets sent to this type of anycast address are reachable at least to the Seed Node without anycast routing. S. Doi [Page 7] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 +----+ | AI | +-+--+ | +--+-----------------------+ | | | Internet | | | +----+-----------------+---+ | | +-+--+ Anycast +--+-+ | R1 | Router | R2 | +-+--+ +--+-+ | | --+---+-- ----+---+---- | | +--+--+ +--+--+ | AR1 | Anycast | AR2 |<---Seed Node +-----+ Receiver +-----+ Unicast address: UA2 same anycast address: AA Anycast Address AA: | n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix (= prefix of UA2) | arbitrarily | +------------------------------------------------+----------------+ Fig. 4 Anycast Address with Unicast Seed o Anycast Address without Unicast Seed Anycast address without unicast seed means an anycast address whose address prefix's segment doesn't exist in the actual network. Without anycast routing, the packet towards its address might not reach anywhere. 2.3 Other Issue In addition to the above-mentioned terminology, the following issues should be considered. o Anycast Selection Criteria Anycast selection criteria mean the criteria of selecting a selected anycast receiver from an anycast membership. S. Doi [Page 8] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 o Anycast Address Resolving Anycast address resolving treats resolution from the anycast address to the corresponding unicast address. We consider anycast as a service discovery mechanism [AARP]. Once an anycast receiver is discovered, the anycast initiator uses the server's unicast address for continuous communication. 3. 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. 3.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. 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. S. Doi [Page 9] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 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 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. S. Doi [Page 10] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 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 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. S. Doi [Page 11] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 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 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. S. Doi [Page 12] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 * 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 anycast address. Then, - anycast routers MAY handle scope to limit the range of sending routing information. 2.3.4 Summary After all, following functionalities are required for each network component. Functionalities (requirements) of anycast receivers o Anycast receivers MUST notify a neighbor router of the membership information. o Anycast receivers MAY notify a neighbor router of the preference value (e.g., metric) S. Doi [Page 13] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 Functionalities (requirements) of anycast routers o Anycast routers MUST support unicast forwarding. o Anycast routers SHOULD have the routing entry for the receiving anycast packet. o Anycast routers SHOULD have anycast selection criteria. o Anycast routers SHOULD have the knowledge to select one entry. o Anycast routers MAY handle scope. 4. Security Considerations This draft does not include any security issues of anycast. Other security descriptions about anycast are shown in [ANALYSIS]. S. Doi [Page 14] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 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. [ADDR-AUTO] Thomson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration," RFC2462, December 1998. [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. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Address: Satoshi Doi Graduate School of Information Science and Technology, Osaka University 1-3 Machikaneyama, Toyonaka, Osaka 560-8531, Japan Phone: +81 (6) 6850-6588 Fax: +81 (6) 6850-6589 Email: s-doi@ist.osaka-u.ac.jp Ibrahim Khalil Advanced Network Architecture Laboratory Cybermedia Center, Osaka University 1-30 Machikaneyama, Toyonaka, Osaka 560-0043, JAPAN Phone: +81 (6) 6850-6863 Fax: +81 (6) 6850-6589 Email: ibrahim@anarg.jp S. Doi [Page 15] INTERNET-DRAFT Anycast Functionality/Terminology December 2003 Shingo Ata Graduate School of Engineering, Osaka City University 3-3-138, Sugimoto, Sumiyoshi-Ku, Osaka 558-8585, JAPAN Phone: +81 (6) 6605-2191 Fax: +81 (6) 6605-2191 Email: ata@info.eng.osaka-cu.ac.jp Hiroshi Kitamura NEC Corporation Central Research Laboratories System Platforms Research Laboratories (Igarashi Building 4F) 11-5, Shibaura 2-Chome, Minato-Ku, Tokyo 108-8557, JAPAN Phone: +81 (3) 5476-1107 Fax: +81 (3) 5476-1005 Email: kitamura@da.jp.nec.com Masayuki Murata Cybermedia Center, Osaka University 1-30 Machikaneyama, Toyonaka, Osaka 560-0043, JAPAN Phone: +81 (6) 6850-6860 Fax: +81 (6) 6850-6860 Email: murata@cmc.osaka-u.ac.jp S. Doi [Page 16]