idnits 2.17.1 draft-haberman-ipv6-anycast-rr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MOBILEIP], [RFC2119], [ANALYSIS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2373' is defined on line 175, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'ANALYSIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MOBILEIP' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission B. Haberman 3 draft-haberman-ipv6-anycast-rr-00.txt Caspian Networks 4 October 2002 E. Nordmark 5 Expires April 2003 Sun Microsystems 7 IPv6 Anycast Binding using Return Routability 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 Today, the use of IPv6 anycast is limited. This document proposes a 31 mechanism by which TCP/SCTP and stateful protocols using UDP can 32 securely discover the mapping from an anycast address to a unicast 33 address that can be used until a failure is detected. The mechanism 34 reuses the Mobile IPv6 Return Routability and Binding Update 35 mechanism. 37 Introduction 39 Several limitations in IPv6 anycast have been identified[ANALYSIS]. 40 This document proposes a solution for securely discovering the 41 mapping from an anycast address to a unicast address so that 42 protocols which require a sequence of packets to go to the same 43 anycast receiver can take advantage of anycast for the initial 44 discovery of the unicast address of an anycast member. 46 This document proposes an approach to IPv6 anycast communication 47 utilizing the Return Routability Procedure defined in [MOBILEIP]. 49 This approach will allow client nodes to use IPv6 anycast for initial 50 packet exchanges and determine the unicast address of the anycast 51 member. After which, the anycast member will provide sufficient 52 information for the client node to "bind" a unicast address assigned 53 to the member. 55 Terminology 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC 2119]. 61 Other terms in this document are defined in [MOBILEIP]. 63 Overview 65 The conceptual model of anycast communication contains many 66 similarities to the Mobile IPv6 model. One similarity is that the 67 node listening on an anycast address is reachable at two addresses 68 (the anycast address and a unicast address) much like a MIP Mobile 69 Node is reachable at a Home Address and a Care-of Address. As with 70 MIPv6, there has to be a secure mechanism to establish a binding 71 between the anycast and unicast address. The node originating the 72 communication takes on the role of Mobile IPv6 correspondent node. 73 The correspondent node can utilize the binding information to make 74 communication efficient. 76 The primary difference between the anycast model and the Mobile IPv6 77 model is that once a binding is known, it is permanent for the 78 duration of the communication session between the nodes or until a 79 failure is detected. That is point, the originating node will want 80 to establish a new binding. 82 What this memo defines is a mechanism for applying the return 83 routability procedure from Mobile IPv6 to anycast communication. 85 Anycast Return Routability Procedure 87 The return routability signaling for anycast proceeds as follows: 89 Client Server 90 (Addr = A) (Anycast Addr = B, 91 | Unicast Addr = C) 92 | | 93 | -------------- TCP SYN --------------> | 94 | IP src=A, IP dst=B | 95 | | 96 | <---------- Home Test Init ----------- | 97 | IP src=B, IP dst=A | 98 | <--------- Care-of Test Init --------- | 99 | IP src=C, IP dst=A | 100 | | 101 | ------------- Home Test -------------> | 102 | IP src=A, IP dst=B | 103 | ------------ Care-of Test -----------> | 104 | IP src=A, IP dst=C | 105 | | 106 | <---------- Binding Update+ ---------- | 107 | IP src=B, IP dst=A | 108 | | 109 | -------------- TCP SYN --------------> | 110 | IP src=A, IP dst=C | 111 | | 113 The Home Test Init (HoTI) and the Care-of Test Init (CoTI) are 114 transmitted at the same time by the server. The client responds with 115 the Home Test (HoT) and the Care-of Test (CoT) messages as quickly as 116 possible. 118 The contents of each message, their formats, and the basic processing 119 rules are defined in [MOBILEIP]. 121 Binding Update+ 123 The Binding Update message returned by the server requires an 124 additional indication that the binding is for an anycast address. 125 This allows the client stack to drop any connection state associated 126 with the anycast address and recreate it using the server's unicast 127 address. 129 This indication can be accomplished by reserving an additional flag 130 within the Mobile IPv6 Binding Update message. The new Binding 131 Update message format would be as follows: 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Sequence # | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 |A|H|S|D|L|E| Reserved | Lifetime | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 . . 140 . Mobility Options . 141 . . 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 The E (for equivalent) bit indicates a switchover from an anycast 145 address to a unicast address. It MUST be set when sending a Binding 146 Update for an anycast address. It should be noted that a Binding 147 Update with E=1 indicates that a Mobile IPv6 RHtype2 extension header 148 is not included in the packet and that transport protocols should be 149 made aware of the change in the destination address. 151 The Lifetime field of the Binding Update MUST be set to a value of 152 one (16 seconds). This allows the binding to be used for immediate 153 communication. Longer lifetimes will cause the anycast receivers to 154 exert control over which member of the anycast group receives packets 155 addressed to it. By having a short lifetime, the control over 156 delivery of packets to the anycast group is maintained by the routing 157 system. 159 Open Issues 161 - This mechanism requires the use of an anycast address as a source 162 address for the CoTI message. The issues with this needs to be 163 carefully understood with respect to [ANALYSIS]. 164 - Additional text needed on Mobile IPv6 message exchange? 165 - Additional security threats? 166 - Should an RHtype2 be used to deliver the packets for better 167 consistency with MIPv6? 169 Security Considerations 171 Security considerations are discussed in [MOBILEIP]. 173 References 175 [RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing 176 Architecture", RFC 2373, July 1998. 178 [ANALYSIS] Hagino, J., and Ettikan, K., "An Analysis of IPv6 179 Anycast", work in progress. 181 [MOBILEIP] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support 182 in IPv6", work in progress. 184 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", RFC 2119, March 1997. 187 Authors' Address 189 Brian Haberman 190 Caspian Networks 191 One Park Drive 192 Suite 400 193 Research Triangle Park, NC 27709 194 Tel: +1-919-949-4828 195 EMail: bkhabs@nc.rr.com 197 Erik Nordmark 198 Sun Microsystems Laboratories 199 180, avenue de l'Europe 200 38334 SAINT ISMIER Cedex, France 201 Tel: +33 (0)4 76 18 88 03 202 Fax: +33 (0)4 76 18 88 88 203 EMail: erik.nordmark@sun.com 205 Full Copyright Statement 207 Copyright (C) The Internet Society (2002). All Rights Reserved. 209 This document and translations of it may be copied and furnished to 210 others, and derivative works that comment on or otherwise explain it 211 or assist in its implementation may be prepared, copied, published 212 and distributed, in whole or in part, without restriction of any 213 kind, provided that the above copyright notice and this paragraph are 214 included on all such copies and derivative works. However, this doc- 215 ument itself may not be modified in any way, such as by removing the 216 copyright notice ore references to the Internet Society or other 217 Internet organizations, except as needed for the purpose of develop- 218 ing Internet standards in which case the procedures for copyrights 219 defined in the Internet Standards process must be followed, or as 220 required to translate it into languages other than English. 222 The limited permissions granted above are perpetual and will not be 223 revoked by the Internet Society or its successors or assigns. 225 This document and the information contained herein is provided on an 226 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 227 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 228 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 229 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 230 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.