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]