INTERNET-DRAFT J. Bound
IPv6 Work in Progress Digital Equipment Corp
P. Roque
Universidade de Lisboa
IPv6 Anycasting Service: Minimum requirements for end nodes
<draft-bound-anycast-00.txt>
Status of this memo
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 learn the current status of any Internet-Draft, please
check the ``1id-abstracts.txt'' listing contained in the
Internet- Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).
Abstract
This document proposes a minimum set of requirements for IPv6
hosts in order to achieve communication with nodes providing
services through IPv6 anycast addresses. We present a
mechanism that aims to allow TCP and UDP communication between
hosts where the packet exchange is initiated through the usage
of an anycast address, without requiring modifications to the
general definitions of the transport protocols.
Expires January 1997 [Page 1]
INTERNET-DRAFT June 1996
Table of Contents:
1. Introduction.................................................3
2. Terminology and Definitions..................................3
3. Anycast address usage........................................4
4. Source Identification Option.................................5
5. Receipt of Source Identification Option......................5
6. Issues for Further Consideration.............................7
Acknowledgements................................................7
References......................................................7
Authors' Address................................................8
Expires January 1997 [Page 2]
INTERNET-DRAFT June 1996
1. Introduction
IPv6 Anycast addresses [RFC-1883] allow a datagram to be
addressed to a group of hosts with delivery to one and
preferably only one semantic. This facility can be used to
facilitate traffic path selection when a group identifies the
set of routers of a particular traffic provider. Other
possible uses of anycast addresses are to provide a "Host
Anycasting Service" [RFC-1546], where a set of hosts can
represent a particular service. While the particular
mechanisms hosts can use to provide services via anycast
addresses are still to be defined, this document attempts to
define a minimum set of requirements that should be
implemented in all IPv6 hosts in order to use those services.
The authors view a "Host Anycasting Service" as complementary,
rather than orthogonal, to Service Discovery mechanisms
[SVRLOC] since they can be used to provide lightweight service
access without the need for previous configuration. For
instance, a well-known site-local address can be used to
communicate with a host that provides service discovery
services.
While it is expected that the particular specifications
regarding anycast address usage by application servers and
routing are defined as extensions to IPv6 and companion
protocols, the authors feel that mechanisms needed in every
host should be defined before the massive deployment of IPv6
hosts.
The problems pertaining to the usage of anycast addresses for
accessing application services can be clearly divided in three
distinct components: procedures for hosts providing services
via anycast addresses, routing, and procedures in hosts
accessing services via anycast. This document focuses solely
on the later problem, as the authors consider that it can be
solved independently of the previous two.
2. Terminology and Definitions
IP
Internet Protocol Version 6 (IPv6). The terms IPv4
and IPv6 are used only in contexts where necessary
to avoid ambiguity.
Anycast Address
An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to an
anycast address is delivered to one of the
interfaces identified by that address (the "nearest"
one, according to the routing protocols' measure of
distance).
Expires January 1997 [Page 3]
INTERNET-DRAFT June 1996
Communication
Any packet exchange between nodes that requires that
the address of each node used in the exchange remain
the same for the duration of the packet exchange.
Examples are a TCP connection or UDP
request/response.
3. Anycast address usage
Anycast addresses are restricted to be used as the destination
address of a datagram. This requirement is imposed by
necessity to determine the originating node of a datagram in
error conditions. Current transport protocols [RFC-768]
[RFC-793] rely, however, on the source address of the IP
datagram to demultiplex incoming packets.
Independently of how the network delivers datagrams addressed
to an anycast group, it's usage in normal communication
depends on the ability of a host to accept a datagram
originating from a distinct unicast address as a reply to a
packet sent to an anycast address.
Also, as anycast addresses are syntacticly indistinguishable
from unicast addresses, the client of a service provided via
anycast should not need explicit knowledge of whenever a
particular address is unicast or anycast, much less the
particular group membership for a particular anycast address.
To fulfill the above stated goals, the authors propose the
definition of a Destination Option, named Source
Identification Option, to dynamically inform client hosts that
a particular communication initiated through the use of an
anycast address should proceed with the use of a unicast
address of one of the anycast group members.
This option requires no processing from the network layer
other than encoding and decoding the respective extension
header and MUST be passed transparently from the network layer
to the transport layer. The transport layer MAY then take in
to account this information when demultiplexing datagrams.
Section 5 of this document discusses in more detail the
expected behavior of transport protocols when receiving a
datagram with this option.
Although this document does not pretend to specify the
mechanisms to be used by hosts providing a service through
anycast addresses, we note that a reply to a datagram received
for an anycast address will not be correctly interpreted if a
Source Identification Option is not present.
Expires January 1997 [Page 4]
INTERNET-DRAFT June 1996
4. Source Identification Option
The Source Identification Option provides a mechanism hosts
can use to inform it's communications peers that datagram
demultiplexing by transport protocols should be performed with
respect to the identifier present in this option. This option
is encoded in the Destination Options Extension Header of IP
datagrams as option type TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Identifier |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of option. The first three
bits of the option are 000, indicating first that a node
receiving the option may discard the option and still
process the rest of the packet, and second that the option
may not be modified enroute.
Option Length
8-bit unsigned integer. Length of the Option Data field of
this option, in octets.
Identifier
128-bit IP address. The anycast address known to the
receiver of the datagram as the destination address of a
particular communication.
5. Receipt of Source Identification Option
As previously stated in section 3 of this document, a
transport protocol MAY take in account the identifier received
in a Source Identification Option for purposes of datagram
demultiplexing.
TCP [RFC-793] communication depends on the knowledge of state
information by communicating peers, initialized on a
synchronization period referred to as the "three way
handshake". In terms of access to a service provided via the
use of anycast address, procedures must be provided to insure
correct synchronization between the client and a member of the
anycast group, and to maintain the same communication end-
points during the duration of the connection.
Expires January 1997 [Page 5]
INTERNET-DRAFT June 1996
An IP node performing a TCP active open sends a segment to the
network addressed to the destination address of the
connection. It then expects to receive a segment from this
address confirming or rejecting the connection establishment
request. When the destination address of the connection is an
anycast address this condition cannot be met since the
responding host may not send datagrams using an anycast
address as source address in datagrams. In this scenario, the
responding node should use the Source Identification Option,
with the destination address on the received syn segment as an
identifier, in order to inform the node performing the active
open that the segment is related to this communication.
A TCP performing an active open MAY then use the IP address
present on the Source Identification Option to demultiplex the
incoming segment. If the segment causes TCP to proceed to
SYN-RECEIVED or ESTABLISHED it MUST then consider that the
destination address of the connection is the source address
present on the received segment.
Note that for TCP, the receipt of a Source Identification
Option is meaningful only when the segment refers to a
connection on the SYN-SENT state. Otherwise, this option
should be ignored by TCP. This will cause the received segment
to be interpreted as a segment to a connection in the CLOSED
state, assuming that no communication is taking place between
the same address/port pairs.
Datagram exchanges using UDP [RFC-768] constitute a more
problematic case. While UDP is itself connectionless, many
applications using this transport protocol require state to be
maintained. This implies that while some applications desire
to communicate with any of the members of the anycast group,
others can only tolerate anycast initiated communication
requiring subsequent packets to be delivered to the same host.
Since the appropriate semantics of anycast address usage on
UDP communication are application dependent, a UDP
implementation should only take in to account the Source
Identification Option when this behavior has been explicitly
requested by the application. When such option is selected by
the application incoming datagrams containing a Source
Identification Option shall be demultiplexed and delivered to
the application using the identifier contained in the option
as the source address of the datagram. Otherwise, the Source
Identification Option should be ignored by a UDP
implementation.
As UDP already provides a means for determination of the
originating node of a received datagram by applications, no
further modifications are required to allow the use of this
service with the desired semantics.
Expires January 1997 [Page 6]
INTERNET-DRAFT June 1996
6. Issues for Further Consideration
Security considerations.
Receipt of a RST segment carried in a datagram containing a
Source Identification Option.
According to [RFC-793], a segment containing a valid
acknowledgement value and the RST bit on for a TCP
connection in SYN-SENT state, will cause the connection to
enter the CLOSED state. In the specific case of an active
open to an anycast address, this abortive termination could
be caused by a failure from one of the group members. The
appropriate action to take in this case is an issue for
further study.
Acknowledgements
We would like to thank Dan Harrington and Mike Shand who have
provided comments and review of an earlier version of this work.
References
[RFC-768]
J. Postel, "User Datagram Protocol", STD-6, August 1980.
[RFC-793]
J. Postel, "Transmission Control Protocol", STD-7, September
1981.
[RFC-1546]
C. Partridge, T. Mendez, W. Milliken, "Host Anycasting
Service", Informational Request for Comments, November 1993.
[RFC-1883]
S. Deering and R. Hinden, "Internet Protocol Version 6,
(IPv6) Specification" Proposed Standard, December 1995.
[SVRLOC]
J. Veizades, E. Guttman, C. Perkins and S. Kaplan, "Service
Location Protocol", Internet Draft, March 1996, <draft-ietf-
svrloc-protocol-12.txt>
Expires January 1997 [Page 7]
INTERNET-DRAFT June 1996
Authors' Address
Jim Bound
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Phone: (603) 881-0400
Email: bound@zk3.dec.com
Pedro Roque
Departamento de Inform'atica
Faculdade de Ciencias da Universidade de Lisboa
Campo Grande - Bloco C5
1700 Lisboa, Portugal
Email: roque@di.fc.ul.pt
Expires January 1997 [Page 8]