INTERNET-DRAFT S. Ata Osaka City University H. Kitamura NEC Corporation M. Murata Osaka University Expires in six months 16 February 2004 A Protocol for Anycast Address Resolving 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 Since the route of packets to the same anycast adddress may change according to the network/node condition, it is not suitable to use anycast addresses directry for stateful communications (such as TCP). The more preferable use of the anycast addresses is to discover (the unicast address of) service node. The approach intended to describe in this document is to resolve (i.e., obtain) the corresponding unicast address for the anycast address prior to establishing the communication. We call this process as Anycast Address Resolving (AARP). The objevtive of the AARP is to enable the use of anycast addresses to all existing applications without any modifications. S. Ata [Page 1] INTERNET-DRAFT Anycast Address Resolving Protocol February 2004 1. Introduction Anycast is defined as one of new IPv6 features, which supports service-oriented address assignments in IPv6 networks. Anycast address is not determined by the location of node, but by the type of service presented at the node. In anycast communication, the client can automatically obtain the appropriate node corresponding to a specific service without knowledge of the location of the server. However, there are some technical issues to be solved in the current anycast definitions. In the anycast communication, there is no guarantee that multiple packets to the same anycast address will reach the same destination. That is why anycast address cannot be used directly to establish a TCP connection [ANALYSIS]. For this problem, it is desirable to resolve the anycast address into the unicast address prior to beginning the communication. We call it as "Anycast Address Resolving" in this document. In this case the anycast address is used only to determine the appropriate host out of anycast membership hosts. In this document we describe a protocol for anycast address resolving so that every application can support anycast communications without modifications of both its program codes and underlying protocol layers. We introduce a new sub-layer above the transport (TCP/UDP) layer. The mechanism is similar dscribed in [SOCKSv5], which overwrites original (i.e., provided by the operating system) APIs in order to add special functions. 2. The Use of Anycast Address As described before, the anycast address is not suitable for the stateful commmunications such as TCP, because there is no guarantee that multiple packets with the same anycast address are delivered to the same destination node. Thus we use the anycast address for only the discovery of the destination node associated with the anycast address. Since the resolving of anycast address should be completed before the initialize phase of the session, it is preferable to be resolved upper the network layer. 3. Anycast Resolving Layer 3.1 Architecture Overview We introduce a new sub-layer above the transport layer. We call this sub-layer as Anycast Resolving Layer (ARL) in this document. Fig. 1 shows a protocol stack in anycast communication with AARP. S. Ata [Page 2] INTERNET-DRAFT Anycast Address Resolving Protocol February 2004 Host C Host S (anycast:AA, unicast:UA) +---------------+ +---------------+ | Application | | | +^=============v+(AA) +---------+ | | || +----->+ anycast | | Application | || ARL | | address | | | || +-<----+ resolve | | | +|=============|+(UA) +---------+ +^-------------v+ || Socket APIs || || Socket APIs || +|-------------|+ +|-------------|+ || IPv6 || || IPv6 || +|-------------|+ +|-------------|+ || Network I/F || || Network I/F || +|-------------|+ +|-------------|+ | +------------>>>-------------+ | +-----<<<------------------<<<------------------<<<------+ ->, <- : Traffic Direction Fig. 1 Protocol Stack of AARP ARL provides the same set of APIs as the original socket (transport layer) APIs, and hooks them in order to resolve anycast addresses. It operates to convert an anycast address into its corresponding unicast address prior to calling the original APIs. The anycast address is used in only the application layer and the ARL. Lower layers below the ARL do not aware the anycast address, but only treat the translated unicast address. 3.2 Address Resolution Process in ARL When the host C would like to establish an anycast communication to the host whose anycast address is AA, the process of anycast address resolving is as follows; 1. The host C calls socket API (e.g., connect() in TCP) with AA of its parameter. In the mechanism, ARL's API is first called instead of the socket layer's API. 2. In the callee function, the ARL converts the anycast address the unicast address. 3. After the conversion, the ARL calls the original socket API by the use of the unicast address UA and continues establishing communication. 4. After the hosts C and S estiablishing the communication, all packets from the host C are set the unicast address UA in thier S. Ata [Page 3] INTERNET-DRAFT Anycast Address Resolving Protocol February 2004 destination addresses. 4. Applicability Statement 4.1 Technical Features AARP mechanism has following features. 1. No application modification is needed ARL provides the same set of APIs as provided by the operating system to establish the communication. The anycast address is resolved under the application layer. The application is not necessary to notice whether the destination address is anycast or unicast. In the application layer, no special operation is processed. The anycast address is automatically resolved in the ARL. Neither source code modification nor re-compile is necessary. 2. No protocol extension is needed In the underlying layers below the ARL, all APIs are called by the use of the resolved unicast address. 3. Easy setup If the host wants to support anycast communication, the operator is simply requested to copy AARP Library files to the specified directory, and append the copied directory to the head of the environment variable (e.g., LD_LIBRARY_PATH). 4.2 Protocol Overhead Since the host cannot identify the destination address as the anycast or unicast address [IPv6], AARP requires to query all destination addresses whatever the address is already known as the unicast address or not. As a result, unnegligible overhead will arise when the number of applications using anycast is increased. Address caching in AARP agent may reduce such overhead. 5. Security Considerations Anycast addresses potentially have some security issues discussed in [ANALYSIS]. Especially, since the ARL does not provide any security functionalities, either following two solutions must be achieved for secure communications. 1. To establish a secure resolving of anycast address S. Ata [Page 4] INTERNET-DRAFT Anycast Address Resolving Protocol February 2004 In the ARL, the anycast address is resolved to the unicast address. The process for address resolving should verify that the resolved unicast address represents really a proper destination for the anycast address. Otherwise the client host would try to connect to a spoofed address when a malicious node sends an illigal reply for address resolving. It leads a kind of denial of service traffic. 2. To use the secure transport protocol A malicious node also captures the session by replying its unicast address on the address resolving. To make a secure communication, a secure mechanism on the upper layer (e.g., SSL) is required. References [ANALYSIS] Hagino, J., and Ettikan, T., "An Analysis of IPv6 Anycast," , June 2003 "work in progress." [SOCKSv5] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., and Jones, L., "SOCKS Protocol V5," RFC1928, April 1996. [IPv6] Hinden, R., and Deering, S., "IP Version 6 Addressing Architecture," RFC3513, April 2003. 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 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 S. Ata [Page 5] INTERNET-DRAFT Anycast Address Resolving Protocol February 2004 Phone: +81 6 6850 6615 Fax: +81 6 6850 6589 Email: murata@cmc.osaka-u.ac.jp History of revision 00->01: * Remove implementation sections * Add some security guidelines * Change the word "AARP Library" to "ARL" APPENDIX A: Implementation Issues A.1 Method for Address Conversion To convert the anycast address into the unicast address, AARP uses the packet probing technique described as follows. 1. The host C first sends a probe packet included the anycast address AA in its destination address. 2. The probe packet is routed and sent to the host S, one of the memberships of the anycast address AA. 3. The host S then returns a packet to the host C. The source address of the returned packet is set to the unicast address UA of the host S. 4. The host C waits for the response of the probe packet. After receiving the packet, the host C gets the unicast address UA from the source address of the received packet. A.2 Implementation for Address Conversion The current implementation of AARP uses ICMPv6 ECHO REQUEST/REPLY packets to resolve the anycast address. Since the anycast address should not be set in the source address of the packet header [IPV6], the host S sets the corresponding unicast address UA to the source address field of ICMP packet instead of the anycast address. It assumes that the host sets its unicast address into the source address of ICMP packet even if the host receives the ICMP request packet destined for the anycast address. Note that the current KAME protocol stack has been implemented this feature. The merit of using ICMPv6 ECHO packets is that the anycast membership S. Ata [Page 6] INTERNET-DRAFT Anycast Address Resolving Protocol February 2004 host can reply its unicast address by the protocol specification. If the AARP cannot use the ICMPv6 mechanism, special software is required to answer the probe packet from the caller host. Full Copyright Statement 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 7]