INTERNET-DRAFT S. Ata Osaka City University H. Kitamura NEC Corporation M. Murata Osaka University Expires in six months 24 June 2002 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 This document describes a mechanism to realize anycast communication without any modifications of applications and/or underlying protocols. The mechanism, using a DLL (Dynamic Linkable Library) based approach, is called AARP (Anycast Address Resolving Protocol), which resolves the anycast address into the corresponding unicast address prior to establishing the communication. AARP smoothly supports anycasting without change of existing applications. S. Ata [Page 1] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 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 design a new architecture called AARP (Anycast Address Resolving Protocol) for anycast resolving so that every application can support anycast communications without modifications of both its program codes and underlying protocol layers. The mechanism uses the same approach described in [SOCKSv5], which overwrites original (i.e., provided by the operating system) APIs in order to add special functions. We have implemented our designed architecture on the FreeBSD operating system, and verified that our proposed mechanism smoothly supports anycasting without change of existing applications. 2. Protocol Overview The task of AARP is to translate the anycast address specified by the application into the matched unicast address. 2.1 Requirements for AARP For smoothly supporting anycast, AARP is required to enable anycast communications without any modifications of both applications and protocols. For this purpose, AARP is implemented as a kind of dynamic linkable library overwrites original APIs. We call this library as AARP Library in this document. Fig. 1 shows a protocol stack in anycast communication with AARP. S. Ata [Page 2] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 Host C Host S (anycast:AA, unicast:UA) +---------------+ +---------------+ | Application | | | +^=============v+(AA) +---------+ | | || +----->+ anycast | | Application | || *AARP Lib* | | address | | | || +-<----+ resolve | | | +|=============|+(UA) +---------+ +^-------------v+ || Socket APIs || || Socket APIs || +|-------------|+ +|-------------|+ || IPv6 || || IPv6 || +|-------------|+ +|-------------|+ || Network I/F || || Network I/F || +|-------------|+ +|-------------|+ | +------------>>>-------------+ | +-----<<<------------------<<<------------------<<<------+ ->, <- : Traffic Direction Fig. 1 Protocol Stack of AARP AARP Library (*AARP Lib* in Fig.1) provides the same set of APIs as the original socket 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 AARP library layer. Lower layers below the AARP Library do not aware the anycast address, but only treat the translated unicast address. 2.2 Address Resolution Process in AARP 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, AARP Library's API is first called instead of the socket layer's API. 2. In the callee function, the AARP Library converts the anycast address the unicast address. 3. After the conversion, the AARP Library 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 S. Ata [Page 3] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 thier destination addresses. 3. 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. 4. Implementation Issues This section describes the outline for the current implementation of AARP. 4.1 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 [RFC2373], 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 [KAME] has been implemented this feature. The merit of using ICMPv6 ECHO packets is that the anycast membership 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. 4.2 Implementation for AARP Library S. Ata [Page 4] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 To implement the AARP Library, the SOCKS-based approach [SOCKSv5] is used. The task of address conversion is implemented as a single process independent of the AARP Library (running as out-process). There are major two reasons why the AARP agent is out-processed. 1. Most current operating systems require the administrative privilege to receive ICMP packets. So the AARP agent should be run as a daemon (or a background service) process. If the AARP agent cannot run as a daemon process, AARP Library can also resolve the anycast address by using the ping6 program. However, the cost of process creation overhead is expensive. 2. Because the AARP is performed for every socket API call, the overhead of anycast resolving is not negligible. To reduce the overhead, the AARP agent has a caching mechanism to hold the latest resolved addresses. By running the AARP agent as out- process, multiple applications can share the resolved address and reduce the query overhead. 4.3 AARP Agent The main task of the AARP agent is to translate the anycast address queried by the AARP Library into the matched unicast address (See Fig. 2). +==========+ AA +-------+ Req. (AA) +---------------+ | +---->+ AARP |===========>|Host H | |*AARP Lib*| | | | (Unicast : UA)| | +<----+ agent |<===========| (Anycast : AA)| +==========+ UA +-------+ Rply. [UA] +---------------+ ===>, <=== ICMP ECHO Packet Direction (AA): Destination address is AA, [UA]: Source address is UA. Fig.2 AARP agent More specifically, the AARP agent first sends an ICMPv6 ECHO REQUEST packet including the anycast address AA as its destination address. The host S, one of the anycast memberships of AA, receives the ICMP ECHO REQUEST packet, and then returns an ICMP ECHO REPLY packet to the host C. The AARP agent retrieves the unicast address UA for the anycast address AA by receiving the ICMP ECHO REPLY packet from the host S. S. Ata [Page 5] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 5. Applicability Statement 5.1 Technical Features AARP mechanism has following features. 1. No application modification is needed AARP 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 AARP Library. Neither source code modification nor re-compile is necessary. 2. No protocol extension is needed In the underlying layers below the AARP Library, all APIs are called by the use of the resolved unicast address. If AARP uses ICMPv6 ECHO REQUEST/REPLY packets to resolve the anycast address, anycast membership host is only required to (1) response the ICMPv6 ECHO REQUEST packet, and (2) set the unicast address of the host into the source address of the ICMP reply packet. No other protocol extension or responsibilities are needed. 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). 5.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. S. Ata [Page 6] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 6. Security Considerations If the AARP uses ICMPv6 packets for address resolving, security issues discussed in Section 5 of [ICMPv6] should be considered. Other security descriptions about anycast are shown in [ANALYSIS]. S. Ata [Page 7] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 References [KAME] KAME Project. http://www.kame.net/ [ANALYSIS] Hagino, J., and Ettikan, T., "An Analysis of IPv6 Anycast," , February 2001 "work in progress." [SOCKSv5] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., and Jones, L., "SOCKS Protocol V5," RFC1928, April 1996. [TRANS] H. Kitamura, "A SOCKS-based IPv6/IPv4 Gateway Mechanism," RFC3089, April 2001. [ICMPv6] Conta, A., and Deering, S., "Internet Control Message Protocol (ICMPv6) for the Internete Protocol Version 6 (IPv6) Specification," RFC2463, December 1998. [IPv6] Hinden, R., and Deering, S., "IP Version 6 Addressing Architecture," RFC2373, July 1998. APPENDIX A. Location for Current Implementation Current implementation of AARP is available at http://www.anarg.jp/ipv6/ (Not available yet) 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 S. Ata [Page 8] INTERNET-DRAFT Anycast Address Resolving Protocol June 2002 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 S. Ata [Page 9]