Individual Submission B. Haberman
draft-haberman-ipv6-anycast-rr-00.txt Caspian Networks
October 2002 E. Nordmark
Expires April 2003 Sun Microsystems
IPv6 Anycast Binding using Return Routability
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."
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
Today, the use of IPv6 anycast is limited. This document proposes a
mechanism by which TCP/SCTP and stateful protocols using UDP can
securely discover the mapping from an anycast address to a unicast
address that can be used until a failure is detected. The mechanism
reuses the Mobile IPv6 Return Routability and Binding Update
mechanism.
Introduction
Several limitations in IPv6 anycast have been identified[ANALYSIS].
This document proposes a solution for securely discovering the
mapping from an anycast address to a unicast address so that
protocols which require a sequence of packets to go to the same
anycast receiver can take advantage of anycast for the initial
discovery of the unicast address of an anycast member.
This document proposes an approach to IPv6 anycast communication
utilizing the Return Routability Procedure defined in [MOBILEIP].
Haberman/Nordmark [Page 1]
INTERNET DRAFT October 2002
This approach will allow client nodes to use IPv6 anycast for initial
packet exchanges and determine the unicast address of the anycast
member. After which, the anycast member will provide sufficient
information for the client node to "bind" a unicast address assigned
to the member.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
Other terms in this document are defined in [MOBILEIP].
Overview
The conceptual model of anycast communication contains many
similarities to the Mobile IPv6 model. One similarity is that the
node listening on an anycast address is reachable at two addresses
(the anycast address and a unicast address) much like a MIP Mobile
Node is reachable at a Home Address and a Care-of Address. As with
MIPv6, there has to be a secure mechanism to establish a binding
between the anycast and unicast address. The node originating the
communication takes on the role of Mobile IPv6 correspondent node.
The correspondent node can utilize the binding information to make
communication efficient.
The primary difference between the anycast model and the Mobile IPv6
model is that once a binding is known, it is permanent for the
duration of the communication session between the nodes or until a
failure is detected. That is point, the originating node will want
to establish a new binding.
What this memo defines is a mechanism for applying the return
routability procedure from Mobile IPv6 to anycast communication.
Anycast Return Routability Procedure
The return routability signaling for anycast proceeds as follows:
Client Server
(Addr = A) (Anycast Addr = B,
| Unicast Addr = C)
| |
| -------------- TCP SYN --------------> |
| IP src=A, IP dst=B |
| |
| <---------- Home Test Init ----------- |
Haberman/Nordmark [Page 2]
INTERNET DRAFT October 2002
| IP src=B, IP dst=A |
| <--------- Care-of Test Init --------- |
| IP src=C, IP dst=A |
| |
| ------------- Home Test -------------> |
| IP src=A, IP dst=B |
| ------------ Care-of Test -----------> |
| IP src=A, IP dst=C |
| |
| <---------- Binding Update+ ---------- |
| IP src=B, IP dst=A |
| |
| -------------- TCP SYN --------------> |
| IP src=A, IP dst=C |
| |
The Home Test Init (HoTI) and the Care-of Test Init (CoTI) are
transmitted at the same time by the server. The client responds with
the Home Test (HoT) and the Care-of Test (CoT) messages as quickly as
possible.
The contents of each message, their formats, and the basic processing
rules are defined in [MOBILEIP].
Binding Update+
The Binding Update message returned by the server requires an
additional indication that the binding is for an anycast address.
This allows the client stack to drop any connection state associated
with the anycast address and recreate it using the server's unicast
address.
This indication can be accomplished by reserving an additional flag
within the Mobile IPv6 Binding Update message. The new Binding
Update message format would be as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D|L|E| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The E (for equivalent) bit indicates a switchover from an anycast
Haberman/Nordmark [Page 3]
INTERNET DRAFT October 2002
address to a unicast address. It MUST be set when sending a Binding
Update for an anycast address. It should be noted that a Binding
Update with E=1 indicates that a Mobile IPv6 RHtype2 extension header
is not included in the packet and that transport protocols should be
made aware of the change in the destination address.
The Lifetime field of the Binding Update MUST be set to a value of
one (16 seconds). This allows the binding to be used for immediate
communication. Longer lifetimes will cause the anycast receivers to
exert control over which member of the anycast group receives packets
addressed to it. By having a short lifetime, the control over
delivery of packets to the anycast group is maintained by the routing
system.
Open Issues
- This mechanism requires the use of an anycast address as a source
address for the CoTI message. The issues with this needs to be
carefully understood with respect to [ANALYSIS].
- Additional text needed on Mobile IPv6 message exchange?
- Additional security threats?
- Should an RHtype2 be used to deliver the packets for better
consistency with MIPv6?
Security Considerations
Security considerations are discussed in [MOBILEIP].
References
[RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ANALYSIS] Hagino, J., and Ettikan, K., "An Analysis of IPv6
Anycast", work in progress.
[MOBILEIP] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support
in IPv6", work in progress.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
Haberman/Nordmark [Page 4]
INTERNET DRAFT October 2002
Authors' Address
Brian Haberman
Caspian Networks
One Park Drive
Suite 400
Research Triangle Park, NC 27709
Tel: +1-919-949-4828
EMail: bkhabs@nc.rr.com
Erik Nordmark
Sun Microsystems Laboratories
180, avenue de l'Europe
38334 SAINT ISMIER Cedex, France
Tel: +33 (0)4 76 18 88 03
Fax: +33 (0)4 76 18 88 88
EMail: erik.nordmark@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, such as by removing the
copyright notice ore references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Haberman/Nordmark [Page 5]