IP Version 6 Working Group S. Ata Internet-Draft Osaka City University Expires: April 25, 2005 H. Kitamura NEC Corporation M. Murata Osaka University October 25, 2004 Possible Deployment Scenarios for IPv6 Anycasting draft-ata-anycast-deploy-scenario-01 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 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 Ata, et al. Expires April 25, 2005 [Page 1] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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 reason is because the use only of the 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 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) example 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. 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. Ata, et al. Expires April 25, 2005 [Page 2] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 2.2 Shared Unicast Shared unicast is a similar practice to anycast, in which multiple nodes can have the same unicast address. The packet destinied to the shared unicast address is delivered 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 anycasting and the deployment scenarios on shared unicast are not scope of this document. However, some scenarios in this document can be applied to shared unicast, and some shared unicast practices are also useful to consider the deployment scenario on 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) [MLDEXT] 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 a global use of anycasting, the scaling 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 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 Ata, et al. Expires April 25, 2005 [Page 3] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 initiator, i.e., for each initiator some of 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 anycast entries must be restricted for advertising arbitrary routers. Introducing "scope" 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 which the corresponding unicast address belongs to. 2. predefined well-known link-local anycast address. * Packet reachability: The anycast packet is always delivered when the anycast receiver Ata, et al. Expires April 25, 2005 [Page 4] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 exists in the same segment. * Requirements: 1. Nodes SHOULD NOT use the anycast address outside of the segment. 2. No special routing protocols for the anycast address is NOT required. * Requirements of protocol changes: none 3.2 Multiple Anycast Receivers within the Same Segment This is one of the simplest scenario. All anycast receivers are on the segment. The prefix address of the anycast address is the same as the 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 which anycast receivers are belonging to. +-----+ +--| 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 Ata, et al. Expires April 25, 2005 [Page 5] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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 in the segment. However, when the selected anycast receiver falls down, 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 NOT 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 Ata, et al. Expires April 25, 2005 [Page 6] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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--+ | | | <===== +----+ | | +------------| 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. Ata, et al. Expires April 25, 2005 [Page 7] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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: 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 | | +---------------+ +-----+ | +-----+ +-------------------------------------------+ Ata, et al. Expires April 25, 2005 [Page 8] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 Fig. 4 Regional Anycasting Most characteristics on the regional anycasting are the same as ones on intra-domain anycasting. * Possible applications: 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 scale problem, the existing unicast routers are not Ata, et al. Expires April 25, 2005 [Page 9] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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. 5.1 Single Anycast Router Anycast seed [ANYTERM] is one of solution 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 once 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 once sent to Seed node. After receiving the anycast packet, Seed then decides the appropriate node for the anycast packet and sent to 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. Ata, et al. Expires April 25, 2005 [Page 10] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 * 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. * Requirements: 1. Anycast seed MUST have a capability to forward the anycast packet. 2. Anycast seed SHOULD have a 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 to establish 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 on 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 of 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 seeds and anycast receivers are Ata, et al. Expires April 25, 2005 [Page 11] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 connected virtually eath other. In this figure, S1, S2 is a nearest receiver for AI1, AI2, respectively. When S1 and S2 receive anycast packets, they forward an approprite receiver selected from all receivers. By increasing the number of seeds, the load of seed nodes become degraded. * 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 between different anycast addresses. 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]. Ata, et al. Expires April 25, 2005 [Page 12] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 7. References 7.1 Normative References [ANYTERM] Doi, S., Kahlil, 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. [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. 7.2 Informative References [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. 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 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 Ata, et al. Expires April 25, 2005 [Page 13] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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 25, 2005 [Page 14] Internet-Draft Deployment Scenario 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 25, 2005 [Page 15]