2010 International Conference on Networking and Digital Society
A Secure Communication Model of Solving Anycast Scalability in IPv6
Wang Xiaonan
Changshu Institute of Technology
School of Computer Science and Engineering
Changshu, China
e-mail: wxn_2001@163.com
Abstract-The existing designs for providing anycast services
are either to confine each anycast group to a preconfigured
topological region or to globally distribute routes to individual
anycast group ,both of which are all confronted with two
problems: scalability and security. A new kind of Anycast
communication model is proposed in this paper, which not
only solves Anycast existing scalability and security problem
but also allows Anycast members to freely leave and join
Anycast group. In addition, this model accomplishes the
distributed maintenance and transaction of the information on
Anycast members so in some sense it fulfills the load balance.
This paper deeply analyzes and discusses the feasibility and
performance of this communication model , and argues that it
is able to support the large-scale Anycast group .
Keywords-IPv6, Anycast, Anycast Controller, Scalability,
Security
I. INTRODUCTION
The original definition of Anycast in RFC1546 is: "A
host transmits a datagram to an Anycast address and the
internet is responsible for providing best effort delivery of
the datagram to at least one, and preferably only one, of the
servers that accept datagrams for the Anycast address." In
practice, Anycast is a point-to-point flow of packets
between a single client and the nearest destination server
identified by an Anycast address. The idea behind Anycast
is that a client would like to send packets to a server
offering a particular service or application, but it is not
important which server is chosen. To accomplish this, a
single Anycast address is assigned to one or more servers
within a so-called Anycast group and a client sends packets
to an anycast server by placing the Anycast address in the
packet header with being unaware that Anycast is used. And
then the network of routers will attempt to deliver the
packets to the nearest server with the destination Anycast
address, just as is shown in figure 1.
�up A mem � ar�up A mem�
ra
11 � measures must be taken to avoid this kind of attack, namely,
��
Figure1 Anycast Service
978-1-4244-5161-61101$26.00 ©2010 IEEE
171
Anycast can support various web services. For example,
DNS resolvers would no longer have to be configured with
the IP addresses of their servers, but rather could send a
request to a well-known DNS anycast address, which makes
it easy for DNS resolvers to move to any new networks by
its pleasure.
II. ANYCAST SCALABILITY
IPv6 allocates anycast addresses from unicast addresses,
so Anycast address is not distinguishable from Unicast
address, which, to some extent, mitigates routing table
expanding explosion caused by Anycast service and makes
full use of the existing routing resources. Traditional
Unicast routing can aggregate routes to destinations that
share the same prefix into one routing entry, which make it
possible for Unicast to scale. However, unfortunately
Anycast defies this kind of hierarchical aggregation.
An anycast address represents a node group which share
the same characteristics and can be distributed to every
internet region. Therefore, if unicast routing protocol is used
to route anycast packets each member of global anycast
group will be advertised as a separate entry in all the
relevant routing tables, which makes the routing tables
expand proportionally to the number of the global anycast
groups in the entire Internet , thereby resulting in anycast
scalability.
Ill. ANYCAST SECURITY
Anycast address is assigned to a group of servers which
offers the same service so it can not be used as the source
address of a response packet. Therefore, anycast member
will use its unicast address as the source address of the
response packet when it responds to anycast service requests
from clients. But clients can not judge if that source address
is a valid one of a legitimate anycast member, hence, if that
source address is fake all the messages sent from the clients
will be intercepted and incorrectly transacted by this false
anycast member.
In addition, a fake anycast member may repeatedly
send some outdated messages to the clients but clients can
not judge if these messages are valid or not so some
replay attack.
To sum up, a secure anycast communication model
must possess the following characteristics:
1 )an authentication mechanism to control the join and
leave of anycast members;
 2) an authentication mechanism to check if the
identification of the anycast member, who responds to the
anycast service requests from the clients, is valid and
legitimate;
3)a method to check if the response message from the
anycast member is outdated.
According to the above discussion and analysis a new
kind of anycast communication model is proposed in this
paper. This model has many advantages, the first one is that
it effectively solve the anycast's scalability; the second one
is that it accomplishes the secure mechanism of
authenticating anycast members' identifications; the last one
is that it achieves the distributed management of anycast
members.
The following sections give a detailed analysis and
discusses of this model.
C_region by the management organization of its local
network.
C. Anycast Address
In general an anycast address is assigned to a group of
servers which offer the same service and a data packet with
that anycast address as its destination address can be routed
to the nearest anycast member. In this model an anycast
controller is added into each local network which manages
the join and leave of anycast members located in the local
network and maintains a database to record the relevant
parameters of anycast members located in the local network,
including unicast address and the number of current sessions,
etc, just as is shown in figure 2.
anycast controller

IV. ANYCAST COMMUNICATION MODEL

A. Anycast Address
Anycast address model adopted by IPv6 is totally
different from the one recommended by RFC1546. The Figure2 Anycast Architecture
former suggests that anycast addresses should be allocated
from unicast addresses so that anycast address structure is
In this model all the anycast controllers are the
not distinguishable from unicast one, but the latter
members of a multicast group and the information exchange
recommends that anycast address should adopt an
between anycast controllers may be achieved in the
independent model. This model chooses the latter
multicast way. The process of a client's requesting anycast
recommendation.
service is described as follows:
It can be inferred from the above discussion that IPv6
I)a client requests DNS to parse the domain name and
address has a layered structure, therefore this model adopts
DNS returns the corresponding Anycast address;
the followin anycast address format:
2) according to the definition of anycast address in 4.1
the client can learn that the address returned by DNS is an
The first 3 bits are an anycast prefix whose value may anycast one so it sends to anycast controller a message
be set to any values except 001 and in this model this value which includes the received anycast address and requests
is set to 000. From the above figure, it can be inferred that anycast controller to parse that anycast address into the
anycast address in this model is still global and can be corresponding unicast address;
assigned to any hosts located in the global regions. 3) after anycast controller authenticates the client's
In general, a legitimate and valid anycast address must be identification it first searches the local database for the
assigned and authenticated by lANA. received anycast address and locates the anycast member
B. Maintaining the Integrity of the Specifications with the least sessions and the best performance, and then
signs its unicast address and returns it to the client, or if no
In this model, the legitimacy and validity of an anycast
corresponding entry is found in the database the anycast
member can be estimated by three factors:
controller sends to its neighbor anycast controller a query
1 )the anycast address of an anycast member must be
message for the information on that anycast address and sets
valid and legitimate, namely, it must be assigned and
a timer whose functions are to control the routing time of
authenticated by lANA;
query messages and to avoid the replay attack from fake
2)the owner of the anycast group must acknowledge and
anycast members;
authenticate the identification of that anycast member;
4) after receiving the query message the neighbor
3)the physical location of the anycast member must be
anycast controller first authenticates its legitimacy and
valid and legitimate, namely, that anycast member must have
validity and then searches its local database for that anycast
the valid membership in its physical network.
address. If there exist some corresponding entries in it the
In this model, the legitimacy and validity of the above
neighbor anycast controller will select the anycast member
three factors are authenticated by C_addr, C_membership
with the least sessions and the best performance and
and C_region respectively. C3ddr is released by lANA,
transmit that query message to that optimal member; or the
C_membership by the owner of the anycast group and

172
neighbor anycast controller will transmit that query message
to its neighbor anycast controllers;
5) after the optimal anycast member acquired in step 4)
receives that query message it first signs its own unicast
address and other relevant parameters with C_Addr and
C_Membership and encapsulates these data into the
response message, and then send it to the source anycast
controller;
6) when the timer expires the anycast controller will
deal with all the received response messages, it first
decrypts the digital signatures in the messages and after
authenticating their identifications then selects an anycast
member with the least sessions and best performance, and at
last signs its unicast address and send it to the client; if no
response messages are returned during the time timer
restricts the anycast controller will send an error message to
the client and notify that the anycast server is not available;
7) after the client receives the response message from
the local anycast controller it first decrypts the digital
signature in it and after authenticating its identification it
extracts the unicast address of the optimal anycast member
from that received message and then can establish a direct
connection with that member in the unicast secure
communication way.
D. Join and Leave ofAnycast Group
In this model if a host wants to join an anycast group it
must meet three requirements:
I)the address of that anycast group must be legitimate
and valid, namely, that address must be assigned and
authenticated by lANA;
2) the owner of that anycast group allows that host to
join;
3) that host must be a legitimate and valid member in
its physical network, namely, it must own a valid
membership in that region authenticated by the management
organization of that local network.
If a host satisfies that above conditions it may send a
join request to its local anycast controller. In this model
each local anycast controller needs to maintain a database to
record the information on anycast members located in the
local network, such as unicast address, the number of
current sessions and performance parameters, etc. The
following words give a detailed description of a host's
requesting to join an anycast group:
I) a host sends to its local anycast controller a Jom
request message which includes the anycast address, its own
unicast address, three digital signatures signed by private
keys in C_addr, C_membership and C_region respectively,
and the current time of the local anycast controller;
2) after the local anycast controller receives the join
message it first check if the message is outdated according
to the current time field encapsulated in the message, and
then decrypts three digital signatures in it with the public
keys of C_addr, C_membership and C_region respectively.
If that message is fresh and is authenticated successfully it
173
sends an accept message to the host and notifies all the other
anycast controllers of the join of that new member in
multicast way, and in the meanwhile it appends that new
member into its local database; or the local anycast
controller sends a refuse message to the host. Here, either an
accept message or a refuse message must be signed by the
local anycast controller and then be sent to the host;
3) after receiving the response message from the local
anycast controller the host first decrypts the digital signature
in it to authenticate the source of that message, and if that
message is accept message that host owns the identification
of that anycast member.
Until now a host joins successfully an anycast group.
But how an anycast member requests to leave the anycast
group it belongs to? The following words will discuss on the
process of an anycast member's leaving the anycast group:
1) a host sends to its local anycast controller a leave
request message which includes the anycast address of the
anycast group it belongs to, its own unicast address, three
digital signatures signed by private keys in C_addr,
C_membership and C_region respectively, and the current
time of the local anycast controller;
2) after the local anycast controller receives the leave
message it first check if the message is outdated according
to the current time field encapsulated in the message, and
then decrypts three digital signatures in it with the public
keys of C3ddr, C_membership and CJegion respectively.
If that message is fresh and is authenticated successfully it
sends an agree message to the host and deletes that member
from its local database, and in the meanwhile notifies all the
other anycast controllers of the leave of that member in
multicast way. Also, an agree message must be signed by
the local anycast controller and then be sent to the host;
3)after receiving the response message from the local
anycast controller the host first decrypts the digital signature
in it to authenticate the source of that message, and if that
message is an agree message that host successfully leaves
that anycast group it belonged to.
The above process can be achieved by creating new
types of BGP and IGMP messages.
E. Routing Analysis
To effectively obtain an optimal anycast member in this
model a query message contains two fields: one is path
attribute which records all the networks a query message
crosses in order to prevent the query message from looping,
and the other is TTL which is used to control the routing
scope of a quest message. The value of TTL is initialized to
the maximum number of network hops a query message can
traverse and gets decreased by I with each hop. The entire
process of anycast controller's querying for the information
on an anycast address is described as follows:
I) anycast controller encapsulates the anycast address
into a query message and sends it to its neighbor anycast
controller in a multicast way, and then start up a timer;

2) after a neighbor anycast controller receives a query
message it first searches its local database for the entries on
that anycast address. If some relevant entries are found out
the neighbor anycast controller will select an optimal
anycast member in terms of the relevant parameters, such as
the number of current sessions and the current performance,
and then transmit the received query message to it, or
anycast controller decreases TTL by I and appends its
unicast address into path attribute, and then checks if the
value of TTL is equal to zero and routing path forms loop. If
neither, the anycast controller again transmits that query
message to its neighbor controllers in a multicast way;
3) after the optimal anycast member receives that query
message, it encapsulates its own unicast address, its relevant
parameters and the values of the path attribute in the query
message into a response message and then the message is
signed by C_Addr and C_Membership, and at last the
optimal anycast member sends the response message with
digital signature to the source anycast controller.
After sending a query message, the source anycast
controller starts up a timer and waits for the response
messages. When the timer expires the anycast controller
decrypts the digital signatures of all the received response
messages to authenticate their sources and selects one
anycast member with the least sessions and the best
performance, and then after signing its unicast address sends
it to the client. After the client receives that unicast address
returned by the local anycast controller it can establish a
direct connection with that optimal anycast member. In
some extreme situations if no response messages are
returned the anycast controller can return an error message
to the client.
F. Performance Analysis
The performance analysis refers to the comparison
between anycast service performed in this model and the
one fulfilled on IP layer and application layer. From the
client's perspective the shorter the time interval between
client's sending service request and receiving service
response, which is called TRT, is, the better the service
quality is, so the performance analysis is obtained by
comparing the values of TRT(total response time) of
transmitting the same bytes in the above three ways, as is
shown in the following formula and figures.
Rl=TRTApplictlliollLayel TRT;R2=TRTlPLtlyel TRT
1.3 �Jr.1-----
1.29
1. 28
1.2
1. 25 TTL=2
1.25
1. 22
1.2 I h-::--"""":',...."":--....,.....,..,...---,,.....,.,,........,,,..
0.04 0.08 0.12 0 . 15
Percentage of domain that
have Anycast members
2
13 &,p. __________---,
1. 29
1. 28
1. 2S
1. 24
1. 23
1. 22
1. 21h.-....,....�_,.."';':<"__,...,...-"""""._,!
._
O. 04 O. 08 O. 12 O . 16 0. 20 0.24
Percentage of domain that
have Anycast members
Here, R I represents the ratio of the TRT value of
performing the anycast service on application layer to the
one of performing the same service in this model;
TRTApplicationLayer is the TRT value of performing anycast
service on application layer; TRT is the TRT value of
performing anycast service in this model; R2 represents the
ratio of the TRT value of performing one anycast service on
IP layer to the one of performing the same service in this
model; TRT'PLayer is the TRT value of performing anycast
service on IP layer. From the above figures, it can be
inferred that the value of R1 trends to 1.225 and the value of
R2 1.245. This experimental result indicates the
performance of anycast service fulfilled in this model IS
better than the ones on application layer and IP layer.
V. PREPARE YOUR PAPER BEFORE STYLING
Anycast is a new characteristic of IPv6 and supports
various kinds of services. In IPv6 simulation, a new
communication model is proposed to accomplish anycast
service's scalability and security. In this paper this model's
validity and feasibility are analyzed and discussed in detail.
As a new kind of communication model, Anycast is
promising, but since it is only on the primary stage there still
exists many problems which need further study and analysis.
ACKNOWLDMENT
The work is supported by Jiangsu Natural Science
Foundation (BK2009133)
REFERENCES
[I] Partridge C, Mendez T, Milliken W. Host Anycasting Service, RFC
1546 [EB/OL]. [2005-03-01]. http://www. ietf. org/rfc/rfc1546.txt.
[2] Deering S, Hinden R. Internet Protocol. Version 6 (IPv6)
Specification, RFC 2460 [EB/OL]. [2005-03-18]. http://www. ietf.
org/rfc/rfc2460.txt.
[3] Zhang Li, Yan Wei, Li Xiaoming. Anycast�-another
communication model for IP[J]. Journal of computer research and
development, 2003, 40(6): 784-790(Ch).
[4] Greg 0, Michael R. Child-proof Authentication for MIPv6
(CAM)[C]// ACM Computer Communications Review.New York:
ACM Press, 200I.
[5] Johnson D, Deering S. Reserved lPv6 Subnet Anycast Addresses,
RFC 2526 [EB/OL]. [2005-9-01]. http://www. ietf. org/rfc/rfc2526.txt.
[6] Ballani H, Francis P. Towards a global IP anycast service[C]//
Proceeding of S1GCOMM. New York: ACM Press,2005.
[7] Kent S, Seo K. Security Architecture for the Internet Protocol, RFC
4301 [EB/OL]. [2005-12-12]. http://www. ietf. org/rfc/rfc430 l .txt.
[8] Pethia R, Crocker S, Fraser B. Guidelines for the Secure Operation of
the Internet, RFC 1281 [EB/OL]. [2006-02-04]. http://www. ietf.
...,
..,,,_
,) org/rfc/rfc128 l .txt.
0.20 0.24
174