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 A Protocol for Anycast Address Resolving draft-ata-ipv6-anycast-resolving-02 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 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). Ata, et al. Expires April 25, 2005 [Page 1] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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. Ata, et al. Expires April 25, 2005 [Page 2] Internet-Draft Deployment Scenario of IPv6 Anycasting October 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. Ata, et al. Expires April 25, 2005 [Page 3] Internet-Draft Deployment Scenario of IPv6 Anycasting October 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 Ata, et al. Expires April 25, 2005 [Page 4] Internet-Draft Deployment Scenario of IPv6 Anycasting October 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 Ata, et al. Expires April 25, 2005 [Page 5] Internet-Draft Deployment Scenario of IPv6 Anycasting October 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. 6. References 6.1 Normative References [ANALYSIS] Hagino, J., and Ettikan, T., "An Analysis of IPv6 Anycast," , June 2003 "work in progress." 6.2 Informative References [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. 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 Ata, et al. Expires April 25, 2005 [Page 6] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 (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 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 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 Ata, et al. Expires April 25, 2005 [Page 7] Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004 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 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. Ata, et al. Expires April 25, 2005 [Page 8] 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 9]