IETF IPng Working Group David B. Johnson
INTERNET-DRAFT Carnegie Mellon University
Stephen E. Deering
Cisco Systems, Inc.
7 August 1998
Reserved IPv6 Subnet Anycast Addresses
<draft-ietf-ipngwg-resv-anycast-00.txt>
Status of This Memo
This document is a submission by the IPng Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the Working Group mailing list at "ipng@sunroof.Eng.Sun.COM".
Distribution of this memo is unlimited.
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
The IP Version 6 addressing architecture defines an "anycast"
address as an IPv6 address that is assigned to more than one network
interface (typically belonging to different nodes), with the property
that a packet sent to an anycast address is routed to the "nearest"
interface having that address, according to the routing protocols'
measure of distance. This document defines a set of reserved anycast
addresses within each subnet prefix, and lists the initial allocation
of these reserved subnet anycast addresses.
Johnson and Deering Expires 7 February 1999 [Page i]
INTERNET-DRAFT Reserved IPv6 Subnet Anycast Addresses 7 August 1998
1. Introduction
IP Version 6 (IPv6) defines a new type of address, known as an
"anycast" address, that allows a packet to be routed to one of a
number of different nodes all responding to the same address [1, 2].
The anycast address may be assigned to one or more network interfaces
(typically on different nodes), with the network delivering packets
addressed to this address to the "nearest" interface based on the
notion of "distance" determined by the routing protocols in use.
The uses of anycast addresses are still evolving, but such addresses
offer the potential for a number of important services [4, 5]. For
example, an anycast address may be used to allow nodes to access
one of a collection of servers providing a well-known service,
without manual configuration in each node of the list of servers; or
an anycast address may be used in a source route to force routing
through a specific internet service provider, without limiting
routing to a single specific router providing access to that ISP.
IPv6 defines a required Subnet-Router anycast address [2] for
all routers within a subnet prefix, and allows additional anycast
addresses to be taken from the unicast address space. This document
defines an additional set of reserved anycast addresses within each
subnet prefix, and lists the initial allocation of these reserved
subnet anycast addresses.
2. Format of Reserved Subnet Anycast Addresses
Within each subnet, the highest 128 interface ID values are reserved
for assignment as subnet anycast addresses. Specifically, these
reserved subnet anycast addresses have the format:
| n bits | 121-n bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+
| interface ID field |
The n-bit "subnet prefix" consists of all fields of the IPv6 address
except the interface ID field. The interface ID field here is formed
from a 7-bit "anycast ID", with the remaining (highest order) 121-n
bits filled with all one's. The "anycast ID" identifies a particular
reserved anycast address within the subnet prefix, from the set of
reserved subnet anycast addresses.
The motivation for reserving the highest addresses from each subnet
rather than the lowest addresses, is to avoid conflicting with some
existing official and unofficial uses of the low-numbered addresses
in a prefix. For example, these low-numbered addresses are often
Johnson and Deering Expires 7 February 1999 [Page 1]
INTERNET-DRAFT Reserved IPv6 Subnet Anycast Addresses 7 August 1998
used for the ends of a point-to-point link, for tunnel endpoints, for
manually configured unicast addresses when a hardware token is not
available for the network interface, and even for manually configured
static addresses for the routers on a link. Reserving only 128
values for anycast IDs (rather than perhaps 256) means that the
minimum possible size of interface IDs in an IPv6 address is 8 bits,
allowing the division between subnet prefix and interface ID in this
case to be byte-aligned.
As with all IPv6 anycast addresses [2], these reserved subnet anycast
addresses are allocated from the IPv6 unicast address space. All
reserved subnet anycast addresses as defined in this document are
reserved on all links, with all subnet prefixes. They MUST NOT be
used for unicast addresses assigned to any interface.
3. List of Reserved Anycast Addresses
Currently, the following anycast IDs for these reserved subnet
anycast addresses are defined:
Decimal Hexadecimal Description
------- ----------- -----------
127 7F Reserved
126 7E Mobile IPv6 Home-Agents anycast [3]
0-125 00-7D Reserved
Additional anycast IDs are expected to be defined in the future.
4. IANA Considerations
This document defines a set of reserved anycast addresses, based
on a set of anycast IDs within each subnet prefix in the IPv6
unicast address space. As future needs arise, new anycast IDs may
be defined. Such anycast IDs MUST be reserved within all subnet
prefixes, and so the assignment of these anycast IDs requires
centralized administration. New values SHOULD be assigned in
descending numerical order and are expected to be assigned only with
IESG approval.
5. Security Considerations
The use of any type of reserved anycast addresses poses a security
concern only in allowing potential attackers a well-known address to
attack. By designating certain services to be located at specific
reserved anycast addresses, an attacker may more profitably focus an
attack against such a specific service. Any such attack, however, is
best dealt with in each service that uses a reserved anycast address.
Johnson and Deering Expires 7 February 1999 [Page 2]
INTERNET-DRAFT Reserved IPv6 Subnet Anycast Addresses 7 August 1998
RFC 1546, which originally proposed the idea of anycasting in IP,
also points out a number of security considerations with the use of
anycasting in general [5].
References
[1] Stephen E. Deering and Robert M. Hinden. Internet
Protocol version 6 (IPv6) specification. Internet-Draft,
draft-ietf-ipngwg-ipv6-spec-v2-02.txt, August 1998. Work in
progress.
[2] Robert M. Hinden and Stephen E. Deering. IP Version 6 addressing
architecture. RFC 2373, July 1998.
[3] David B. Johnson and Charles Perkins. Mobility support in IPv6.
Internet-Draft, draft-ietf-mobileip-ipv6-06.txt, August 1998.
Work in progress.
[4] Steve King et al. The case for IPv6. Internet-Draft,
draft-ietf-iab-case-for-ipv6-01.txt, March 1998. Work in
progress.
[5] Craig Partridge, Trevor Mendez, and Walter Milliken. Host
anycasting service. RFC 1546, November 1993.
Authors' Addresses
David B. Johnson Stephen E. Deering
Carnegie Mellon University Cisco Systems, Inc.
Computer Science Department 170 West Tasman Drive
5000 Forbes Avenue San Jose, CA 95134-1706
Pittsburgh, PA 15213-3891 USA
USA
Phone: +1 412 268-7399 Phone: +1 408 527-8213
Fax: +1 412 268-5576 Fax: +1 408 527-8254
Email: dbj@cs.cmu.edu Email: deering@cisco.com
Johnson and Deering Expires 7 February 1999 [Page 3]
