Internet DRAFT - draft-ata-ipv6-anycast-resolving
draft-ata-ipv6-anycast-resolving
Individual Submission S. Ata
Internet-Draft Osaka City University
Expires: July 19, 2006 H. Kitamura
NEC Corporation
M. Murata
Osaka University
January 20, 2006
A Protocol for Anycast Address Resolving
draft-ata-ipv6-anycast-resolving-04
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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.
Ata, et al. Expires July 19, 2006 [Page 1]
Internet-Draft Protocol of Anycast Address Resolving January 2006
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 July 19, 2006 [Page 2]
Internet-Draft Protocol of Anycast Address Resolving January 2006
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 July 19, 2006 [Page 3]
Internet-Draft Protocol of Anycast Address Resolving January 2006
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 July 19, 2006 [Page 4]
Internet-Draft Protocol of Anycast Address Resolving January 2006
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 July 19, 2006 [Page 5]
Internet-Draft Protocol of Anycast Address Resolving January 2006
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," <draft-ietf-ipngwg-ipv6-anycast-
analysis-02.txt>,
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 July 19, 2006 [Page 6]
Internet-Draft Protocol of Anycast Address Resolving January 2006
(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"
01->02:
* Revise some editorial mistakes
02->03:
* Revise security consideration section
03->04:
* Revise some editorial mistakes
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
Ata, et al. Expires July 19, 2006 [Page 7]
Internet-Draft Protocol of Anycast Address Resolving January 2006
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
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 July 19, 2006 [Page 8]
Internet-Draft Protocol of Anycast Address Resolving January 2006
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 (2006). 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 July 19, 2006 [Page 9]
