Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT IIJ Research Laboratory
Expires: March 4, 2001 K. Ettikan
Multimedia University
September 4, 2000
An analysis of IPv6 anycast
draft-itojun-ipv6-anycast-analysis-00.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.''
Distribution of this memo is unlimited.
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
The memo tries to identify the problems and issues in the use of IPv6
anycast [Hinden, 1998] . The goals of the draft are (1) to understand
IPv6 anycast better, (2) to provide guidelines for people trying to
deploy anycast services, and (3) to suggest updates to IPv6 anycast
protocol specification.
The document was made possible by input from ipngwg DNS discovery design
team.
1. IPv6 anycast
"Anycast" is a communication model for IP, just like unicast and
multicast are. RFC1546 [Partridge, 1993] documents IPv4 anycast, and it
defines the term "anycast".
HAGINO, ETTIKAN Expires: March 4, 2001 [Page 1]
DRAFT Analysis of IPv6 anycast September 2000
Anycast can be understood best by comparing with unicast and multicast.
IP unicast allows a source device to transmit IP datagrams to a single
destination device. The destination device is identified by an unicast
address. IP multicast allows a source device to transmit IP datagrams
to a group of destination devices. The destination devices are
identfied by a multicast group, and we use a multicast address to
identify the multicast group.
IP anycast allows a source device to transmit IP datagrams to a single
destination device, out of a group of destination devices. IP datagram
will reach the topologically-closest destination device in the set of
destination devices. The source device does not need to care about how
to pick the closest destination device, as the routing system will
figure it out (in other words, the source device has no control over the
selection). The set of destionation devices is identified by an anycast
address.
Anycast was adopted by IPv6 specification suite. RFC2373 [Hinden, 1998]
defines the IPv6 anycast address, and its constraints in the usage. To
give an outline, RFC2373 defines IPv6 anycast like below:
o IPv6 anycast address is curved out of IPv6 unicast address space.
IPv6 anycast address is basically not distinguishable from IPv6
unicast addresses. This is different from experimental IPv4 anycast
[Partridge, 1993] , where anycast address is distinguishable from
unicast addresses.
o IPv6 anycast address can be assigned to IPv6 routers only. This is to
avoid injecting host routes for IPv6 anycast destination, into IPv6
cloud.
o IPv6 anycast address can not be put into IPv6 source address. This is
basically because an IPv6 anycast address does not identify single
source node.
The following sections try to follow RFC2373 restrictions.
2. Terminology
Throughout the document, we will use the following terminology:
Anycast server
A server which is assigned an anycast address (or addresses). A
service is provided by a set of IPv6 TCP/UDP servers, where the
server's address is identified by using a single anycast address.
There can be multiple anycast servers, with the same anycast
address. Clients will reach one of the servers based on IPv6
anycast routing.
HAGINO, ETTIKAN Expires: March 4, 2001 [Page 2]
DRAFT Analysis of IPv6 anycast September 2000
3. IP layer constraints
We should not fragment packets, if the packet has anycast address in the
IPv6 destination address field. This is because the fragments may reach
multiple different destinations.
In general, we cannot use IPsec with packets with anycast address.
We can use no more than 1 packet with anycast destination address, in a
set of protocol exchange, If we use more than 2 packets, 1st and 2nd
packet may reach different anycast server and may cause unexpected
results. For example, consider the following packet exchange. The
following exchange can easily lead us to failure, as we are not sure if
the 1st and 2nd anycast packet have reached the same server. If the
protocol is completely stateless, and we can consider the first
roundtrip and second roundtrip separate, it is okay.
query: client unicast (Cu) -> server anycast (Sa)
reply: server unicast (Su) -> client unicast (Cu)
query: client unicast (Cu) -> server anycast (Sa)
It may reach a different server!
reply: server unicast (Su) -> client unicast (Cu)
For stateful protocols, it is suggested to use anycast for the first
packet in the exchange, to discover unicast address of the (nearest)
server. After we have discovered the unicast address of the server, we
should use the server's unicast address for the protocol exchange.
As IPv6 anycast addresses are not distinguishable from IPv6 unicast
addresses, in general, it is not easy for a sender to determine if the
destination address is anycast address or not. We may need to have an
explicit configuration to help the determination.
4. UDP constraints
Many of the UDP-based protocols use source and destination address pair
to identify the traffic. One example would be DNS over UDP; most of the
DNS client implementation checks if the source address of the reply is
the same as the destination address of the query, in the fear of the
fabricated reply from bad guy.
query: client unicast (Cu) -> server unicast (Su*)
reply: server unicast (Su*) -> client unicast (Cu)
addresses marked with (*) must be equal.
If we use server's anycast address as the destination of the query, we
cannot meet the requirement due to RFC2373 restriction (anycast address
cannot be used as the source address of packets). Effectively, client
will consider the reply is fabricated (hijack attempt), and drops the
packet.
HAGINO, ETTIKAN Expires: March 4, 2001 [Page 3]
DRAFT Analysis of IPv6 anycast September 2000
query: client unicast (Cu) -> server anycast (Sa)
reply: server unicast (Su) -> client unicast (Cu)
One way to circumvent this issue is to use home address option on the
reply. In this way, UDP layer would consider that the packet is from
server's anycast address, and the exchange will success. The exchange
will be friendly with codebase which checks the source address of the
reply.
query: client unicast (Cu) -> server anycast (Sa)
reply: server unicast (Su) -> client unicast (Cu)
with server anycast (Sa) in home address option
Note that, however, bad guys can still inject fabricated results to the
client. It does not make a perfect protection, even if we check source
address of the reply. It is suggested to verify the authenticity of the
reply, by using upper-layer security mechanisms like DNSSEC (note that
we cannot use IPsec here).
5. TCP constraints
We cannot simply use anycast for TCP exchanges, as we identify a TCP
connection by using address/port pair for the source/destination node.
It is desired to implement some of the following, to enable the use of
IPv6 anycast in TCP. Note, however, security requirement is rather
complicated for the following protocol modifications.
o Define a TCP option which lets us to switch peer's address from IPv6
anycast address, to IPv6 unicast address. There are couple of
proposals in the past.
o Define an additional connection setup protocol that resolves IPv6
unicast address from IPv6 anycast address. We first resolve IPv6
unicast address using the new protocol, and then, make a TCP
connection using the IPv6 unicast address. IPv6 node information
query/reply [Crawford, 2000] could be used for this.
6. Service content restrictions
If we are to assign an IPv6 anycast address to servers, those servers
must provide uniform services. For example, if server A and server B
provides different quality of service, and people wants to differentiate
between A and B, we cannot use single IPv6 anycast address to identify
both A and B.
7. Routing constraints
RFC2373 suggests to assign anycast addresses to a node, only when the
node is a router. This is to avoid injecting host routes for anycast
HAGINO, ETTIKAN Expires: March 4, 2001 [Page 4]
DRAFT Analysis of IPv6 anycast September 2000
address, into the IPv6 routing system. If no hosts have anycast address
on them, it is easier for us to route an IP datagram to anycast
destination. We just need to follow existing routing entries, and we
will eventually hit a router that has the anycast address. If we follow
RFC2373 restriction strictly, we could only place anycast servers onto
routers.
If we try to ease the restriction and assign anycast addresses to IPv6
hosts (non-routers), we would need to inject host routes for the anycast
addresses, with prefix length set to /128, into the IPv6 routing system.
We will inject host routes from each of the anycast servers, to make
packets routed to a topologically-closest anycast server.
The impact of host routes depends on the scope of the anycast address
usage. For example, if we use site-local anycast address to identify a
set of servers, the propagation of host route is limited inside the
site. If the site administration policy permits it, and the site
routers can handle the additional routing entries, the additional host
routes are okay. So, we can safely assign anycast address to non-router
nodes (hosts), and inject host route for the anycast address, into the
site IPv6 routing system. It is still questionable to inject host
routes into worldwide IPv6 routing system, as it has problems in terms
of scalability. Also, because of IPv6 route aggregation rules [Rockell,
2000] it is normally impossible to propagate IPv6 host routes worldwide.
8. Summary
To deploy anycast servers, the following items should be satisfied:
o For an anycast address, anycast servers must provide the identical
service.
o If we are to deploy worldwide uniform services, we should use well-
known scoped (site-local or link-local) anycast address.
o If we are to use TCP or UDP, interaction of anycast with TCP and UDP
must carefully diagnosed.
9. Security consideration
The document should introduce no new security issues.
References
Hinden, 1998.
R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt.
HAGINO, ETTIKAN Expires: March 4, 2001 [Page 5]
DRAFT Analysis of IPv6 anycast September 2000
Partridge, 1993.
C. Partridge, T. Mendez, and W. Milliken, ""Host Anycasting Service"" in
RFC1546 (November 1993). ftp://ftp.isi.edu/in-notes/rfc1546.txt.
Crawford, 2000.
Matt Crawford, ""IPv6 Node Information Queries"," internet draft (August
2000). work in progress material.
Rockell, 2000.
Rob Rockell and Bob Fink, ""6Bone Backbone Routing Guidelines"" in
RFC2772 (February 2000). ftp://ftp.isi.edu/in-notes/rfc2772.txt.
Change history
None.
Author's address
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN
Tel: +81-3-5259-6350
Fax: +81-3-5259-6351
Email: itojun@iijlab.net
K. Ettikan
Faculty of Information Technology, Multimedia University (MMU)
Jalan Multimedia
63100 Cyberjaya Selangor, Malaysia
Tel: +60-3-8312-5403
Fax: +60-3-8312-5264
Email: ettikan@mmu.edu.my
HAGINO, ETTIKAN Expires: March 4, 2001 [Page 6]