Internet DRAFT - draft-ata-ipv6-anycast-app
draft-ata-ipv6-anycast-app
IP Version 6 Working Group S. Matsunaga
Internet-Draft Osaka University
Expires: August 21, 2005 S. Ata
Osaka City University
H. Kitamura
NEC Corporation
M. Murata
Osaka University
February 14, 2005
Applications of IPv6 Anycasting
draft-ata-ipv6-anycast-app-01.txt
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 August 21, 2005.
Copyright
Copyright (C) The Internet Society (2005).
Abstract
This document describes the applications and characteristics of
S. Matsunaga, et al. Expires August 2005 [Page 1]
INTERNET-DRAFT Applications of IPv6 Anycasting February
Anycast, which is network addressing and routing scheme that routes
data through the best destination. The primary purpose of this
document is to describe the many advantages and applications of
Anycast and hopefully, to motivate you to consider new applications
of Anycast.
1. Introduction
Although [RFC2460] defines anycast, it is currently not being widely
used. One reason is that it was only defined briefly, and the
numerous practical applications and flexibility of the scheme have
not yet been clearly described. Therefore, we will describe anycast
applications and characteristics, and how they can be applied to
enhance your current networking systems. By increasing public
awareness about the flexibility, advantages, and potential
applications for the scheme, the documents ivolves to popularize
anycast and motivate people to use it to expand their current
networking capabilities.
One of the reasons that anycast is not widely used is that [RFC3513]
only addressed and defined the architecture without defining the
other specifications and terms. For clarity, we will use the term as
defined by [ANY-TERM].
Scope of this Document
Anycast is not only limited to network (i.e., IP) layers, but can
also be implemented/used in other (e.g., application) layers. In this
document, we focus on network-layer anycast, which is defined in IPv6
specification [RFC3513].
2. Anycast Characteristics and Applications
In this section, we will describe anycast characteristics and
applications as they apply to [RFC3513], which describes the
specifications of anycast addresses. First, we will describe the
actual and potential anycast characteristics, based on these
specifications. Then, we will describe the anycast applications that
correspond to each anycast characteristic.
The anycast characteristics will appear in either the IP layer,
transport layer or application layer because IPv6 anycast is the
technique in the IP layer. At this point, we can categorize anycast
characteristics into three categories: the IP, the transport, and the
application layers, in addition to ones in other layers that are not
S. Matsunaga, et al. Expires August 2005 [Page 2]
INTERNET-DRAFT Applications of IPv6 Anycasting February
described in this draft.
The characteristics of the IP layer are described in 2.1; the
characteristic of the transport layer are described in 2.2; and the
characteristics of the application layer are described in 2.3.
2.1. Characteristics of IP layer and Applications
In this section, we will describe the anycast IP layer
characteristics, as they relate to all anycast characteristics and
applications that each characteristic applies to. In the IP layer,
anycast characteristics are categorized into three types, the
initiator, the responder, and the intermediate node views, according
to each aspect of the node that sends, receives, and forwards the
packets.
2.1.1. Anycast Initiator View
In this section, we will describe the characteristics for the anycast
initiator and anycast applications that each characteristic applies
to.
o Characteristic: Source Specific Anycast
Application : Local Information Service
In unicast, nodes usually communicate with the same node if the
same unicast address is the destination. On the other hand, in
anycast each Anycast initiator (AI) can communicate with different
Anycast Responders (ARs) depending on the appropriateness of them,
even if the same anycast address is the destination. Although
various way can be considered to switch AR, the source specific
anycast is one of those way. The source specific anycast which is
the way that AR is selected by AI's information as same as the
source specific multicast matches the model of anycast very well.
Therefore, anycast communication can be used for applications that
change the AR depending on the AI's information.
Local information service is given to applications that make the
best use of this characteristic. Local information services
communicate with the appropriate server for the client as the way
you call the telephone to the appropriate emergency facilities for
the caller's place. The local information service in the IP layer
are achieved by getting each AI to communicate with the
appropriate server to the AI's location.
S. Matsunaga, et al. Expires August 2005 [Page 3]
INTERNET-DRAFT Applications of IPv6 Anycasting February
One situation where this application is very useful is when the
mobile node uses the services. Different servers are often used by
the mobile node after it moves from one subnet to another, even if
it continues to use the same service. Then, if the same anycast
address is assigned to the servers and can be used from both
subnets, we can establish a network environment in which the
mobile node can automatically use the most appropriate server when
moving. This model is similar model of mobile IP which a
corresponding node can communicate with the mobile node by using
the same address which is called home address.
o Characteristic: Communication with Scope
Application : Service Discovery
One or more ARs belong to an anycast group with the same anycast
address. If each AI has a scope, AI can limit those ARs which can
communicate with AI. The scope of multicast limits the
communication between a node in the scope and a node outside the
scope and a sender communicates with all nodes in the scope.But AI
communicates with one of all ARs in the scope although the scope
of anycast limits the communication such as multicast. In other
words, anycast with scope is useful for applications that choose
candidates from all ARs for each AI.
Service discovery is given to the application that makes the best
use of this characteristic. In this application, a packet is
automatically forwarded to an appropriate AI server, so that AI
only specifies the anycast address as a server address, allowing
each AI to automatically use the service. At this time, AI
communicates with the AR that exists in the constant range
specified by the AI's scope.
Further, DHCPv6 and SLP are proposed as service discovery
techniques. However, in these techniques a client or a server must
advertise a message that broadcasts over the subnet, and service
discovery is provided only within the range where the message is
advertised. On the other hand, in anycast service discovery, each
client can specify the range of the discovery service based on its
scope. Therefore, the client can use service discovery without
depending on other nodes. This application is well suited to the
IPv6 plug and play model.
2.1.2. Anycast Responder View
In this section, we will describe the anycast characteristics of the
anycast responder and the applications for each characteristic it
S. Matsunaga, et al. Expires August 2005 [Page 4]
INTERNET-DRAFT Applications of IPv6 Anycasting February
applies to.
o Characteristic: Independent Address Assignment
from/based on the Unicast Address
Application : Plug and Play of Server
In IPv6, one or more IP addresses can be assigned to an interface.
However, packets are generally delivered to the subnet with the
same prefix as the destination address of the packet. Therefore,
if the address which doesn't have the prefix of the subnet is
assigned to the interface, there are many troubles for the
receiver. However, in global anycast, AR can receive packets whose
destination does not contain a subnet prefix because anycast has
another space from the unicast as same as the multicast has. In
addition, AR can continue to receive packets from AI while the AR
anycast address remains unchanged, even if the AR unicast address
changes, as long as AI uses the service with the anycast address.
Therefore, communications that do not depend on AR unicast
addresses are possible using anycast, because AI uses only one
(or, is constant numerical) anycast address, even if there is an
increase or decrease in the number of ARs.
Using these characteristics, plug and play of server is given as
an application.IP address of the server commonly doesn't get
decided until you configure the server. If the address is
configured automatically, clients are not able to know the address
of the server. Therefore, you need configure the fixed (unicast)
address to the server manually when the server provides a service
in the global network. But, in this way, the management of the
server saves you a lot of effort for as follow reasons:
- the address need have the prefix of the subnet
- the address need be advertised to the global network
- the address need be changed when the server moves to
the other subnet.
In other words, you hope to be able to provide services by only
auto configuration. But, in networks with global anycast, plug and
play of server is achieved as you can decide the address for
services by the above characteristic before you configure the
server. In addition, if you modify the application which listens
by an anycast address instead of "in_addr any", you can decide the
address of the service when you make the application. As a result,
you don't need manual assignment of the address when you configure
the server.
S. Matsunaga, et al. Expires August 2005 [Page 5]
INTERNET-DRAFT Applications of IPv6 Anycasting February
o Characteristic: Communication Zone
Application : Load Balancing
One AR does not need to communicate with all the AIs when two or
more ARs belong to a specific anycast group, and the AI of each AR
can be allotted/allocated?. This means that each AR can limit the
communication range by specifying a zone. This characteristic,
allows anycast to be used even with applications that limit the
range of the provider's service.
The use of load balancing is an application that uses this
characteristic. When the service range is selected by specifying a
zone, the server only provides service to the AI that exists in
that zone. The number of zones increases when the service provider
increases the AR according to the service requirements/demands,
allowing it to divide zones serviced by only one server into zones
with two or more servers. As a result, anycast can more
effectively balance loads because each AI can communicate with the
corresponding AR.
o Characteristic: Automatic Switching to Alternate Routes
Application : Service Redundancy
In unicast, there is only one receiver corresponding to each
unicast address, so unicast routing forwards the packet to that
receiver. The packet is unreachable and routing ends when the
packet can no longer be forwarded, because the destination of the
packet is uniquely selected by unicast. Therefore, to communicate
with another node when we cannot communicate with the receiver,
the necessity for specifying a new destination address falls upon
the sender.
Anycast, strives to deliver the packet to the best AR, because it
is unacceptable to forward the packet to an AR that cannot
receive. The same anycast address is assigned to interfaces as for
ARs belonging to the anycast group. In this case, the packet's
destination node can be changed into another AR because all ARs
can receive packets with an anycast destination address. The
packet is forwarded to AR for AI as usual. Then if the node
detects that the packet is unable to forward it to the specified
AR, then it tries to deliver it to another available AR. Then, if
it is possible to switch automatically, the intermediate node and
AI are both accepted as nodes that detect unreachable destinations
and the packet is forwarded to another AR. This characteristic
allows anycast to be used for applications that need to maintain a
state in which each AI can communicate with any AR.
S. Matsunaga, et al. Expires August 2005 [Page 6]
INTERNET-DRAFT Applications of IPv6 Anycasting February
Service redundancy is an application that uses this
characteristic. This application maintains the state in which
service can be used in the same address by one or more ARs and can
improve service redundancy. Clients need to search for the address
of another server and then restart/reestablish communication to it
when they cannot use the communicating server. On the other hand,
using anycast, the clients do not need to worry because anycast
automatically establishes communication with another server using
the same address.
2.1.3. Intermediate Node View
In this section, we will describe the anycast characteristics for
nodes other than AI/AR and the anycast applications that each
characteristic applies to.
o Characteristic: Traffic Distribution
Application : Avoid DoS Attack
Traffic can be distributed when the intermediate node (or, AI)
retains information from multiple routes to AR in the routing
table that can be an anycast packet or switching destination, and
so on. Anycast can manage the band when required.
Avoiding a DoS attacks is an application that uses this
characteristic. Even if a DoS attack is undetectable and increases
traffic to a a single node abnormally, we can prevent it from
accumulating on a single route by distributing the traffic to two
or more routes. In addition, after the DoS attack has been
detected, we can avoid future attacks by forwarding the packet to
a camouflage server, such as a honey pot rather than rejecting the
packet altogether.
2.2. Characteristics in Transport Layer and Applications
In this section, we will describe the anycast characteristics in the
transport layer for all the applicable anycast characteristics and
applications.
o Characteristic: AR Selection based Connection
Application : Multiple Server Access
As described in 2, data passed from the application is divided in
the sender's transport layer, and restored in the receiver's
S. Matsunaga, et al. Expires August 2005 [Page 7]
INTERNET-DRAFT Applications of IPv6 Anycasting February
transport layer. To properly transmit the divided data to the same
node, a connection is established between both nodes in the
transport layer. At this time, AI can use AR according to each
connection by sending a packet to the anycast address that
establishes a connection. Therefore, using this characteristic, we
can achieve applications that communicate with different ARs
according to the connection.
Multiple server access is an application that uses this
characteristic. When anycast is used with an application that
establishes multiple connections to the same unicast address, each
connection is automatically established with different servers
that specify the same anycast address. As a concrete illustration,
when a client browses a web page, they download the html file and
each picture file from separate mirror servers. As a result, the
client can use the entire bandwidth, and can download the whole
web page more quickly than with unicast.
2.3. Characteristics in Application Layer and Applications
In this section, we will describe the anycast characteristics in
the application layers for all applicable anycast characteristics
and applications.
o Characteristic: Cross-Platform API with Unicast
Application : Easy Installation of Anycast
Because IPv6 anycast is performed in the IP layer, the application
layer can communicate with anycast characteristics only when using
an anycast address instead of a unicast address. The difference
between anycast and unicast in the application layer is whether
the destination of the communication is an anycast or a unicast
address. However, because both addresses have the same format,
there is no difference in the applications can use these addresses
with same API to communicate between a single sender and single
receiver. This means anycast characteristics can be added to the
existing services being provided by unicast without changing the
application operation in the application layer.
Anycast's easy installation feature is an application that uses
this characteristic. Anycast characteristics can be added to
services without changing the protocol and operations for the
various services provided in the application layer. When high
reliability service is provided for special distribution devices,
we need to enable the devices and servers to work together.
However, anycast applications are added to services only if the
S. Matsunaga, et al. Expires August 2005 [Page 8]
INTERNET-DRAFT Applications of IPv6 Anycasting February
servers use an anycast address to receive packets, while
performing same operations as the unicast address. Therefore, we
can complete anycast installation simply by assigning an anycast
address to the interface of each server. Then, the various
functions described in this draft can be added to the
applications.
3. Security Considerations
This draft does not include any security issues of anycast. Other
security descriptions about anycast are shown in [ANALYSIS].
S. Matsunaga, et al. Expires August 2005 [Page 9]
INTERNET-DRAFT Applications of IPv6 Anycasting February
4. References
[RFC2460] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification," RFC 2460, December 1998.
[RFC3513] R. Hinden, and S. Deering, "IP Version 6 Addressing
Architecture," RFC3513, April 2003.
[ANY-TERM] Hashimoto, M., Ata, S., Kitamura, H., Murata, M., "IPv6
Anycast Terminology Definition,"
<draft-doi-ipv6-anycast-func-term-03.txt>,
February 2005 "work in progress."
[ANALYSIS] Hagino, J., and Ettikan, K., "An Analysis of IPv6
Anycast,"
<draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt>,
June 2003 "work in progress."
S. Matsunaga, et al. Expires August 2005 [Page 10]
INTERNET-DRAFT Applications of IPv6 Anycasting February
Authors' Addresses
Satoshi Matsunaga
Osaka University
1-5, Yamadaoka, Suita
Osaka, 565-0871,
Japan
Phone: +81-6-6850-6863
FAX: +81-6-6850-6868
EMail: s-matung@ist.osaka-u.ac.jp
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
(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
S. Matsunaga, et al. Expires August 2005 [Page 11]
INTERNET-DRAFT Applications of IPv6 Anycasting February
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 (2005). 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.
S. Matsunaga, et al. Expires August 2005 [Page 12]
