Internet DRAFT - draft-ipv6-ata-anycast-resolving
draft-ipv6-ata-anycast-resolving
INTERNET-DRAFT S. Ata
<draft-ata-ipv6-anycast-resolving-01.txt> Osaka City University
H. Kitamura
NEC Corporation
M. Murata
Osaka University
Expires in six months 16 February 2004
A Protocol for Anycast Address Resolving
<draft-ata-ipv6-anycast-resolving-01.txt>
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," <draft-ietf-ipngwg-ipv6-anycast-
analysis-02.txt>,
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]
