INTERNET-DRAFT S. Ata Osaka City University I. Kalil Osaka Univeristy H. Kitamura NEC Corporation M. Murata Osaka University Expires in six months 9 February 2004 Possible Deployment Scenarios for IPv6 Anycasting 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 anycasting is quite limited. In this document we list possible deployment scenarios in IPv6 anycasting. We consider three conditions based on the region of anycasting, and list possible scenarios. For each scenario we also clarify example applications as well as technical issues to be resolved. 1. Introduction Anycast is service-based addressing architecture, which is promising for providing new services. However, currently the use of anycasting is quite limited. One of a main reasons is because the use of the S. Ata [Page 1] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 anycast is not so clear. Another reason is because there are many technical issues to be resolved in the current definitions of IPv6 anycast. Most of problems are stated in [ANALYSIS]. In this document we list possible deployment scenarios in IPv6 anycasting. We classify them into three groups according to the applicable region of anycasting (intra-segment, intra-domain, inter- domain). We also focus on the necessity of current protocol changes and/or introducing new protocols/definitions. For each scenario, we clarify (1) examples of possible applications, (2) addressing, (3) reachability of packets, (4) required functionalities, and (5) requirements of existing protocol changes. The objective of this document is to list all considerable cases of anycast deployment, but concluding what scenario is best is out of scope of this document. Terminology 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]. Other terms in this document are defined in [ANYTERM]. 2. Background Technologies 2.1 Limitation of IPv6 Anycast As noted in [ANALYSIS], the main limitations of IPv6 anycast are 1. Only the router node can notify the routing information, thus the anycast address cannot be assigned to the host node. 2. The anycast address is assigned from the unicast addressing space, so the anycast address is syntactically indistinguishable from the unicast address. 3. From the second limitation, the anycast address cannot be set as the source address of the packet because the anycast initiator cannot identify packets from different anycast receivers if they send packets by setting the anycast address as the source. 2.2 Shared Unicast Shared unicast is similar to anycast, in which multiple nodes can have the same unicast address. The packet destinied to the shared unicast address is delivered to one of those nodes based on the distance from the source node. But there are several differences between anycast and shared unicast [ANALYSIS]. We only focus on IPv6 S. Ata [Page 2] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 anycasting and the deployment scenarios on shared unicast are not within scope of this document. However, some scenarios in this document can be applied to shared unicast, and some shared unicast practices are also useful while considering the deployment scenarios of anycasting. 2.3 Discovery of Anycast Members IPv6 addressing architecture [RFC 2731] prohibits from assigning the anycast address to the host node until the use of anycast address becomes safe (in terms of security) and some avoiding mechanism against illegal use of anycasting arise. The problem of secure group management are stated in some research groups (e.g., IRTF Group Security (GSEC) Research Group). But they are still in discussion. Current possible techniques are: 1. use the extension of MLD (multicast listener discovery) 2. establish a virtual p-to-p tunnel from the anycast receiver to the router with authorization 3. configure (authorize) the router to receive the anycast routing information from anycast receivers 2.4 Virtual Path In most cases it is not directly connected between the anycast receiver and the anycast router (and between two anycast routers). In this case a virtual path should be established between two anycast nodes. 2.5 Scope If we consider global use of anycasting, the scalability problem of routing table will be arisen. The router must have "host route" for the anycast address when multiple anycast receivers are on different segments which have different unicast prefixes. According to the increase of the number of anycast address, the explosion of the size of routing table will lead to a serious performance degradation of routers. Furthermore, even if there are many anycast receivers, it is rare that all of receivers will be "appropriate" for each anycast initiator, i.e., for each initiator some of the receivers may be appropriate, but others are not needed. Many of routing entries for the anycast address are thus not frequently utilized. In both scalability and usability, most of the anycast entries must be restricted for advertising arbitrary routers. Introducing "scope" S. Ata [Page 3] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 will be preferable to limit the range of propagation of anycast routing entries. 3. Intra-Segment Anycasting 3.1 Local Served Anycast Receivers In this scenario the anycast receiver is on the same segment of the anycast initiator. Fig. 1 shows an example. +----+ +--| AI | | +----+ +--------+ | (WAN)--| Router |--+ +--------+ | | +----+ +--| AR | +----+ Fig. 1 Local served anycast receiver The anycast receiver AR only configures the anycast address AA in addition to the unicast address. No route information is notified to Router. The anycast initiator AI discovers the anycast receiver AR by performing lower layer's address resolving protocols (e.g., Neighbor Discovery). * Possible applications: primitive service discovery (DNS, proxy, SMTP, etc.) * Addressing: The anycast receiver MUST assign the ancyast address from: 1. unused space of the subnet prefix to which the corresponding unicast address belongs. 2. predefined well-known link-local anycast address. * Packet reachability: The anycast packet is always delivered when the anycast receiver exists on the same segment. * Requirements: 1. Nodes SHOULD NOT use the anycast address outside the segment. 2. No special routing protocols for the anycast address is S. Ata [Page 4] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 required. * Requirements of protocol changes: none 3.2 Multiple Anycast Receivers within the Same Segment This is one of the simplest scenarios. All anycast receivers are on the segment. The prefix address of the anycast address is the same as one of the corresponding unicast address. Fig. 2 shows an example of this scenario. In this figure there are three anycast receivers (AR1, AR2, AR3). All anycast receivers have the same anycast address AA. AA is assigned from the available space of the subnet belonging to anycast receivers. +-----+ +--| AR1 | | +-----+ +----+ +--------+ | +-----+ | AI |----- (WAN) -----| Router |--+--| AR2 | +----+ +--------+ | +-----+ | +-----+ +--| AR3 | +-----+ Fig. 2 All anycast receivers are on the same segment The packet destinied to the anycast address AA is forwarded to the last hop router based on the unicast routing by the subnet prefix of AA. After arriving at the last hop router, the destination receiver is determined by the last hop router. The selection of the final destination is performed by e.g., Neighbor Discovery [RFC 2461]. * Possible applications: clustering servers, load balancing, replicated servers to improve reliabilitiy * Addressing: The anycast receiver MUST assign the ancyast address from unused space of the subnet prefix which the corresponding unicast address belongs to. * Packet reachability: The anycast packet can be delivered when the anycast receiver exists on the segment. However, when the selected anycast receiver S. Ata [Page 5] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 becomes unavailable, packets will not be delivered until the last hop router updates its learned information (e.g., Neighbor Cache). * Requirements: 1. Set the same anycast address only to anycast receivers on the same segment. Anycast receivers on the different segments MUST be set the different anycast addresses. 2. No special routing protocols for the anycast address is required. 3. Configuring the learning time (aging time) on the last hop router could improve the adaptability of load balancing. * Requirements of protocol changes: none 4. Scoped Anycasting The use of inter-segment anycasting has a scaling problem, in which the routing of anycast packet requires routers to add a host entry (e.g., /128 prefix entry) for each anycast membership. To overcome the scale problem, the advertisement of anycast routing information is highly restricted. There are some approaches to limit the advertisement. First is to allow the exchange of anycast routing information only within the controlled domain (e.g., AS). Second is to tell the routing information only the neighbor domains. We consider above both cases separately. 4.1 Inter-Domain Anycasting In the controlled area (e.g., domain) the influence of adding host entry for the anycast is limited within the controlled region. Thus the administrative operator can use anycasting to receive benefits of anycasting. The simple way to support anycasting to add a host entry of anycast receiver manually (i.e., the selection of anycast receivers is performed by the statical configures) by using exting unicast intra-domain routing protocols (e.g., OSPF). However, in such a static approach, the blackout time of switching to an alternative receiver would be long if the active receiver fails. To improve the service reliability, the selection of anycast receivers would be performed dynamically. The current IPv6 definition [RFC 2373], however, prohibits host nodes from advertising their route information to routers. Fig. 3 shows the example of intra-domain anycasting. +----------------------Intra-domain region--+ | | S. Ata [Page 6] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 | <===== +----+ | | +------------| AR | | | | +----+ | | | | | +---+----+ +----+ | (WAN) --------------| Router |-------------| AR | | No anycast route | +---+----+ <===== +----+ | will be notified | | Advertise anycast route | outside of domain | | +----+ by unicast IGP | | +------------| AR | | | <===== +----+ | +-------------------------------------------+ Fig. 3 Intra-domain Anycasting * Possible applications: load balancing, alternative servers for reliabilitiy, service discovery * Addressing: The anycast receiver SHOULD assign the anycast address from any arbitrary of unused space. However, assigning from the segment- independent subnet space would be better. * Packet reachability: The anycast packet can be delivered when the anycast receiver exists in the domain. However, when the selected anycast receiver falls down, packets will not be delivered until the router update related routing entries. * Requirements: 1. Routers MUST NOT advertise entries of anycast receivers to outside of the domain. 2. Routing entry of anycast receivers should be added manually or dynamically. 3. If manually, the administrative operator configures all of routing entries of anycast receivers. 4. If dynamically, the anycast receiver MUST advertise its host- based routing entry by running routing daemons. However, this item requires a modification of current IPv6 definition. 5. Unicast-based routing protocols (IGPs) can be utilized for exchanging anycast entries. * Requirements of protocol changes: S. Ata [Page 7] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 To update the routing entry of anycast receiver dymanically, we MUST change the definition of IPv6 anycast to enable anycast host nodes to advertise the routing information. 4.2 Regional Anycasting The second way to limit the propagation of anycast routing information is to set the scope (e.g., hoplimit) to routing messages. For example, when we set the hop limit of anycast routing messages to one, anycast routing information is advertised only the neighbor domains directly connected to the domain which the anycast receiver belong to. Fig. 4 shows the example to limit the region of anycasting. In this figure, we set the hop limit of anycst routing messages as the scope of the corresponding anycast address. Anycast receiver AR1 is on the domain AS1, and notify the route for the anycast address to the edge router of AS1. The edge router of AS1 then sends the routing entry for the anycast address to neighbor domains AS2, AS3, and AS4. However, because the hop limit of the routing message is one, the message is not delivered to domains AS5 and AS6, which are out of scope of the anycast address. +-Anycast Routing Region Limited by Scope---+ | | | EGP (hop limit 1) | | ===> +-----+ | | +------------| AS2 | | | | +-----+ | Not delivered | | EGP (hop limit 1) | outside scope | +-- AS 1 ---+---+ ===> +-----+ | +-----+ | | +-------------| AS3 |-------X----| AS5 | | | Intra-domain | +-----+ | +-----+ | | +----+ | | | | | AR | | ===> +-----+ | +-----+ | | +----+ +------| AS4 |-------------X--| AS6 | | +---------------+ +-----+ | +-----+ +-------------------------------------------+ Fig. 4 Regional Anycasting Most characteristics on the regional anycasting are the same as ones on intra-domain anycasting. * Possible applications: S. Ata [Page 8] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 providing regional services (e.g., proxy), location dependent mirror servers (e.g., based on countries) * Addressing: The anycast receiver SHOULD assign the anycast address from any arbitrary of unused space. * Packet reachability: The anycast packet can be delivered when the anycast receiver exists in the domain. However, when the selected anycast receiver falls down, packets will not be delivered until the router update related routing entries. * Requirements: 1. Routing messages for the anycast address MUST include the scope of the anycast address. 2. Routers MUST NOT advertise entries of anycast receivers to outside the scope. 3. Routing entry of anycast receivers should be added manually or dynamically. 4. If manually, the administrative operator configures all of routing entries of anycast receivers. 5. If dynamically, the anycast receiver MUST advertise its host- based routing entry by running routing daemons. However, this item requires a modification of current IPv6 definition. 6. Unicast-based routing protocols (IGPs) can be utilized for exchanging anycast entries. * Requirements of protocol changes: Same as intra-domain anycasting. To update the routing entry of anycast receiver dymanically, we MUST change the definition of IPv6 anycast to enable anycast host nodes to advertise the routing information. 5. Inter-domain Anycasting Due to the scalability problem, the existing unicast routers are not suitable for forwarding anycast packets in case of inter-domain anycast routing. It is preferable to deploy a special node which handles anycast packets based on anycast routing. For deploying anycast routers, we consider three cases based on the number of anycast routers. Note that this section is also an example of transition scenario for supporting anycast. S. Ata [Page 9] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 5.1 Single Anycast Router Anycast seed [ANYTERM] is one of the solutions for supporting global anycasting without modification of existing network framework. Anycast seed is a primary node of the anycast membership. Anycast members have the anycast address, which is also the unicast address of the anycast seed. Without any settings, all packets destinied to the anycast address are forwarded to the anycast seed by the unicast routing. After that, the anycast seed then redirect the "appropriate" anycast receiver via the virtual path between anycast seed and anycast receiver. As a result, the anycast seed acts as the anycast router for the anycast address. Fig. 5 shows the example of anycast seed. +-----+ Anycast Unicast ........| AR1 | Address = AA Addres = AA : +-----+ +----+ +------+ +-----+ Anycast | AI |----- (WAN) -----| Seed |............| AR2 | Address = AA +----+ +------+ +-----+ : +-----+ Anycast :.......| AR3 | Address = AA +-----+ Fig. 5 Anycast Seed (... : virtual path) In this figure, there are four member nodes for the anycast address AA. AA is also the unicast address of Seed. Seed and other members (AR1, AR2, AR3) are connected virtually (e.g., tunnels). All packets to the anycast address AA are sent to Seed node. After receiving the anycast packet, Seed then decides the appropriate node for the anycast packet and sends it through the virtual path. * Possible applications: mirroring service, load distribution * Addressing: The anycast receiver MUST assign the unicast address of anycast seed as the anycast address. * Packet reachability: Whenever the anycast seed is alive, the anycast packet is always delivered at least to the anycast seed. Otherwise (i.e., the anycast seed is not available), no packet is delivered even if other receivers are alive. S. Ata [Page 10] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 * Requirements: 1. Anycast seed MUST be capable of forwarding the anycast packet. 2. Anycast seed SHOULD have knowledge about the condition of anycast receivers, and SHOULD have a procedure to select the appropriate receiver for the anycast packet. 3. Other anycast receiver MUST accept establishing the virtual path from the anycast seed. * Requirements of protocol changes: none 5.2 Multiple Seeds Anycast seed is a kind of anycast router. When the number of anycast packets increases, the ancyast seed will become a bottleneck. To reduce the load of the anycast seed, it is effective to deploy multiple seeds in the network. +-----+ ........| AR1 | : +-----+ +-----+ +----+ +-----+ | AI1 |-- (WAN) --| S1 |............| AR2 | +-----+ +----+ +-----+ +-----+ :: | AI2 | ::::: +-----+ :: | +----+ +-----+ +- (WAN) -| S2 |............| AR3 | +----+ +-----+ Fig. 6 Multiple Seeds (... : virtual path) Fig. 6 shows the example of multiple seeds. There are two anycast seeds and three anycast receivers. All the anycast nodes have the same address AA. The deployment of seeds S1 and S2 is the same as regional anycasting (See 4.2 for details). All the seeds and anycast receivers are virtually connected eath other. In this figure, S1 (S2) is a nearest receiver for AI1 (AI2). When S1 and S2 receive anycast packets, they forward to an approprite receiver selected from all the avaiable receivers. By increasing the number of seeds, the load on the seed nodes can be reduced. S. Ata [Page 11] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 * Possible applications: Same as single seed case. * Addressing: Same as regional anycasting case. * Packet reachability: Same as regional anycasting case. However, if the anycast seed is not available, no packet is delivered even if other receivers are alive. * Requirements: Requirements of both regional anycasting and single seed cases are needed. * Requirements of protocol changes: Same as regional anycasting case. 5.3 Generalized Anycast Routers Anycast seed is a specialized anycast router for the single anycast address. By assigning multiple anycast address into a single anycast seed node, the anycast seed can support multiple anycast addresses. As a result, the anycast seed would become a generic anycast router. The architecture of this scenario is the same as the multiple seeds case except supporting the multiple anycast addresses. Howver, the criteria of appropriate node selection may differ. A generic anycast- based routing protocol is needed to handle multiple node selection criterias. 6. Security Considerations Anycasting potentially has some technical statements about security shown in [ANALYSIS]. References: [ANYTERM] Doi, S., Kalil, I., Ata, S., Kitamura, H., Murata, M., "Anycast Terminology/Functionality Definition," Internet draft, draft-doi-ipv6-anycast-func-term-01.txt, February 2004, work in progress. S. Ata [Page 12] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 [ANALYSIS] Hagino, J., and Ettikan, T., "An Analysis of IPv6 Anycast," Internet draft, draft-ietf-ipv6-anycast- analysis-02.txt, November 2003, work in progress. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. [RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing Architecture," RFC2373, July 1998. Author's Address: 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 Ibrahim Kalil 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 Hiroshi Kitamura Development Labratories, 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 Cybermedia Center, Osaka University 1-30 Machikaneyama, Toyonaka, Osaka 560-0043, JAPAN Phone: +81 6 6850 6615 Fax: +81 6 6850 6589 Email: murata@cmc.osaka-u.ac.jp Full Copyright Statement S. Ata [Page 13] INTERNET-DRAFT Deployment Scenarios for Anycasting February 2004 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this doc- ument itself may not be modified in any way, such as by removing the copyright notice ore references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. S. Ata [Page 14]