idnits 2.17.1 draft-ietf-ngtrans-6to4anycast-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 30 instances of lines with control characters in the document. ** The abstract seems to contain references ([TBDIANA], [Bradner,1996], [6TO4], [6to4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (January 2, 2001) is 8508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '6to4' on line 314 looks like a reference -- Missing reference section? 'TBD IANA' on line 115 looks like a reference -- Missing reference section? 'Bradner' on line 366 looks like a reference -- Missing reference section? '1996' on line 366 looks like a reference -- Missing reference section? '6TO4' on line 402 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 4 Expires July 2, 2001 January 2, 2001 6 An anycast prefix for 6to4 relay routers 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The operation of 6to4 routers require either that participation in 32 IPv6 inter-domain routing, or that the routers be provisioned with a 33 default route. This memo proposes a standard method to define the 34 default route. It requires that IANA assign a "6to4 Relay anycast 35 prefix" from which 6to4 routers can derive the static "6to4 anycast 36 address". In order to enable efficient management of the "6to4 Relay 37 anycast prefix" in IPv4 inter-domain routing, this memo also 38 requests the reservation by IANA of a "6to4 Autonomous System ID." 39 With this definition, the proposed scheme guarantees that 6to4 40 packets will be automatically routed to the nearest available 41 router. It allows the managers of the 6to4 relay routers to control 42 the sources authorized to use their resource. It makes it easy to 43 set up a large number of 6to4 relay routers, thus enabling 44 scalability. 46 1 Introduction 48 According to [6to4], there are two deployment options for a 6to4 49 routing domain, depending of whether or not the domain is using an 50 IPv6 exterior routing protocol. If a routing protocol is used, then 51 the 6to4 routers acquire routes to all existing IPv6 networks 52 through the combination of EGP and IGP. If no IPv6 exterior routing 53 protocol is used, the 6to4 routers using a given relay router each 54 have a default IPv6 route pointing to the relay router. This second 55 case is typically used by small networks; for these networks, 56 finding and configuring the default route is in practice a 57 significant hurdle. In addition, even when the managers of these 58 networks find an available route, this route often points to a 59 router on the other side of the Internet, leading to very poor 60 performances. 62 This memo proposes to reserve a "6to4 anycast address" in order to 63 simplify the configuration of 6to4 routers. It also defines how this 64 address will be used by 6to4 relay routers, how the corresponding 65 "6to4 anycast prefix" will be advertised in the IGP and in the EGP. 66 The memo requests the reservation by IANA of the "6to4 relay anycast 67 prefix" and of a "6to4 Autonomous System ID." 69 2 Definitions 71 This memo uses the definitions introduced in [6to4], in particular 72 the definition of a 6to4 router and a 6to4 Relay Router. It adds the 73 definition of the 6to4 Relay anycast prefix, 75 2.1 6to4 router (or 6to4 border router) 77 An IPv6 router supporting a 6to4 pseudo-interface. It is normally 78 the border router between an IPv6 site and a wide-area IPv4 network. 80 2.2 6to4 Relay Router 82 A 6to4 router configured to support transit routing between 6to4 83 addresses and native IPv6 addresses. 85 2.3 6to4 Relay anycast prefix 87 An IPv4 address prefix used to advertise an IPv4 route to an 88 available 6to4 Relay Router, as defined in this memo. 90 The value of this prefix is x.x.x.0/nn [Length and value TBD IANA] 92 2.4 6to4 Relay anycast address 94 An IPv4 address used to reach the nearest 6to4 Relay Router, as 95 defined in this memo. 97 The address corresponds to host number 1 in the 6to4 Relay anycast 98 prefix, x.x.x.1. [Derived from the 6to4 Relay anycast prefix, TBD 99 IANA] 101 2.5 6to4 IPv6 relay anycast address 103 The IPv6 address derived from the 6to4 Relay anycast address 104 according to the rules defined in 6to4, using a null prefix and a 105 null host identifier. 107 The value of the address is "2002:XXXX:XX01::". [Derived from the 108 6to4 Relay anycast address, TBD IANA] 110 2.6 6to4 Autonomous System ID 112 A 16-bit Autonomous system ID, for use in BGP in accordance to this 113 memo. 115 The value of the 6to4 Autonomous System ID is YYYY. [TBD IANA] 117 3 Model, requirements 119 Operation of 6to4 routers in domains that don't run an IPv6 EGP 120 requires that these routers be configured with a default route to 121 the IPv6 Internet. This route will be expressed as a 6to4 address. 122 The packets bound to this route will be encapsulated in IPv4 whose 123 source will be an IPv4 address associated to the 6to4 router, and 124 whose destination will be the IPv4 address that is extracted from 125 the default route. We want to arrive at a model of operation in 126 which the configuration is automatic. 128 It should also be easy to set up a large number of 6to4 relay 129 routers, in order to cope with the demand. The discovery of the 130 nearest relay router should be automatic; if a router fails, the 131 traffic should be automatically redirected to the nearest available 132 router. The managers of the 6to4 relay routers should be able to 133 control the sources authorized to use their resource. 135 4 Description of the solution 137 4.1 Default route in the 6to4 routers 139 The 6to4 routers are configured with the default IPv6 route (::/0) 140 pointing to the 6to4 IPv6 anycast address. 142 4.2 Behavior of 6to4 relay routers 144 The 6to4 relay routers that follow the specification of this memo 145 shall advertise the 6to4 anycast prefix, using the IGP of their IPv4 146 autonomous system, as if it where a connection to an external 147 network. 149 The 6to4 relay routers that advertise the 6to4 anycast prefix will 150 receive packets bound to the 6to4 anycast address. They will relay 151 these packets to the IPv6 Internet, as specified in [6to4]. 153 4.3 Interaction with the EGP 155 If the managers of an IPv4 autonomous domain that includes 6to4 156 relay routers want to make these routers available to neighbor ASes, 157 they will advertise reachability of the 6to4 anycast prefix. When 158 this advertisement is done using BGP, the AS path leading to the 159 6to4 anycast prefix shall include the identifier of the local AS and 160 the 6to4 Autonomous System ID. 162 The path to the 6to4 anycast prefix may be propagated using standard 163 EGP procedures. The whole v6 network will appear to v4 as a single 164 AS, with multiple peering points scattered over the whole Internet. 166 5 Discussion of the solution 168 The initial surfacing of the proposal in the NGTRANS working group 169 helped is surface a number of issues, such as scaling concerns, the 170 size of the address prefix, the need for an AS number, and concerns 171 about risking to stay too long in a transition state. 173 5.1 Does it scale ? 175 With the proposed scheme, it is easy to first deploy a small number 176 of relay routers, which will carry the limited 6to4 traffic during 177 the initial phases of IPv6 deployment. The routes to these routers 178 will be propagated according to standard peering agreements. 180 As the demand for IPv6 increases, we expect that more ISPs will 181 deploy 6to4 relay routers. Standard IPv4 routing procedures will 182 direct the traffic to the nearest relay router, assuring good 183 performance. 185 5.2 Discovery and failover 187 The 6to4 routers send packets bound to the v6 Internet by tunneling 188 them to the 6to4 anycast address. These packets will reach the 189 closest 6to4 relay router provided by their ISP, or by the closest 190 ISP according to inter-domain routing. 192 The routes to the relay routers will be propagated according to 193 standard IPv4 routing rules. This ensures automatic discovery. 195 If a 6to4 relay router somehow breaks, or loose connectivity to the 196 v6 Internet, it will cease to advertise reachability of the 6to4 197 anycast prefix. At that point, the local IGP will automatically 198 compute a route towards the "next best" 6to4 relay router. 200 5.3 Access control 202 Only those ASes that run 6to4 relay routers and are willing to 203 provide access to the v6 network announce a path to the 6to4 anycast 204 prefix. They can use the existing structure of peering and transit 205 agreements to control to whom they are willing to provide service, 206 and possibly to charge for the service. 208 5.4 Why do we need a large prefix? 210 In theory, a single IP address, a.k.a. a /32 prefix, would be 211 sufficient: all IGP, and even BGP, can carry routes that are 212 arbitrarily specific. In practice, however, such routes are almost 213 guaranteed not to work. 215 The size of the routing table is of great concern for the managers 216 of Internet "default free" networks: they don't want to waste a 217 routing entry, which is an important resource, for the sole benefit 218 of a small number of Internet nodes. Many have put in place filters 219 that automatically drop the routes that are too specific; most of 220 these filters are expressed as a function of the length of the 221 address prefix, such as "my network will not accept advertisements 222 for a network that is smaller than a /19." The actual limit may vary 223 from network to network, and also over time. We consider that a /16, 224 from the old class B, would be very safe. 226 It could indeed be argued that using a large network is a waste of 227 the precious addressing resource. However, this is a waste for the 228 good cause of actually moving to IPv6, i.e. providing a real relief 229 to the address exhaustion problem. 231 5.5 Why do we need a specific AS number? 233 Erroneous advertisements are a frequent source of errors in inter- 234 domain routing. A misconfigured AS will advertise that it can reach 235 some random network, divert the traffic, and effectively cut that 236 network from some parts of the Internet. As a protection, many 237 managers of border routers use databases to check the relation 238 between the advertised network and the last hop in the AS path. If 239 we use a specific AS to denote that "this is a path to IPv6", then 240 we can enter the relation between that AS and the 6to4 access prefix 241 in the databases used to check inter-domain routing. 243 5.6 Why not use Neighbor Discovery? 245 The ND alternative would be to use the anycast address for 246 discovering the nearest relay, and then to build a "regular" 247 association with this relay. It can be argued that using ND will be 248 more a more standard way to do routing, that with a regular 249 association failures will be easier to detect, and also that nailing 250 the default connection to a specific 6to4 relay router will avoid 251 any transient failure caused by the routing protocol. On the other 252 hand, there are many arguments against this type of association. 254 Using ND to discover the next hop router may be in line with the 255 generic IPv6 architecture, but is actually not in line with the 256 specific software written for 6to4, in which the IPv4 next hop is 257 derived algorithmically from the IPv6 destination address. In any 258 case, maintaining ND associations for each 6to4 router that they 259 serve will increase the load of 6to4 relay routers. 261 If the default connection is nailed to a specific 6to4 relay router, 262 the 6to4 router must actively monitor that router, detect failures, 263 and then try to find a secondary router, which will only be possible 264 if routing tables have been updated. In contrast, with a pure 265 anycast tunnelling solution, the packets will be routed to the 266 functioning 6to4 relay router as soon as the routing tables have 267 been updated. 269 After a failure of the nearest 6to4 relay router, if we use ND, the 270 default connection will be nailed to a back-up 6to4 relay router, 271 and will only be nailed back to the nearest 6to4 relay router if the 272 back-up fails. In contrast, with a pure anycast tunnelling solution, 273 the packets will always be routed to the nearest available 6to4 274 relay router. 276 Another line of argument is that the use of ND between routers is 277 not entirely defined, and that using ND in this scenario is 278 potentially more complex and more error-prone than just forwarding 279 the packets to a well-known anycast address. In the absence of a 280 clear-cut advantage for the ND solution, it is preferable to chose 281 the simpler alternative, pure anycast tunnelling. 283 5.7 Will this slow down the move to IPv6 ? 285 Some have expressed a concern that, while the assignment of an 286 anycast address to 6to4 access routers would make life a bit easier, 287 it would also tend to leave things in a transition state in 288 perpetuity. In fact, we believe that the opposite is true. 290 A condition for easy migration out of the "tunnelling" state is that 291 it be easy to have connectivity to the "real" IPv6 network; this 292 means that people trust that opting for a real IPv6 address will not 293 somehow result in lower performances. So the anycast proposal 294 actually ensures that we don't stay in a perpetual transition. 296 6 Future Work 298 Using a default route to reach the IPv6 Internet has a potential 299 drawback: the chosen relay may not be on the most direct path to the 300 target v6 address. In fact, on might argue that, in the early phase 301 of deployment, a relay close to the 6to4 site would probably not be 302 the site's ISP or the native destination's ISP... it would probably 303 be some third party ISP's relay which would be used for transit and 304 may have lousy connectivity. Using the relay closest to the native 305 destination would more closely match the v4 route, and quite 306 possibly provide a higher degree of reliability. A potential way to 307 deal with this issue is to use a "redirection" procedure, by which 308 the 6to4 router learns the most appropriate route for a specific 309 destination. This is left for further study. 311 7 Security Considerations 313 The generic security risks of 6to4 tunneling and the appropriate 314 protections are discussed in [6to4]. The anycast technique 315 introduces an additional risk, that a rogue router or a rogue AS 316 would introduce a bogus route to the 6to4 anycast prefix, and thus 317 divert the traffic. IPv4 network manager have to guarantee the 318 integrity of their routing to the 6to4 anycast prefix in much the 319 same way that they guarantee the integrity of the generic v4 320 routing. 322 8 IANA Considerations 324 The purpose of this memo is to back a demand to IANA to allocate an 325 IPv4 prefix dedicated to the 6to4 gateways to the native v6 326 Internet, and an autonomous system number dedicated to a pseudo-AS. 327 The prefix length should be determined by the IANA; the prefix 328 should be large enough to guarantee advertisement in the default- 329 free BGP networks; a length of 16 will meet this requirement. This 330 is a one time effort; there is no need for any recurring assignment 331 after this stage. 333 9 Copyright 335 The following copyright notice is copied from RFC 2026 [Bradner, 336 1996], Section 10.4, and describes the applicable copyright for this 337 document. 339 Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved. 341 This document and translations of it may be copied and furnished to 342 others, and derivative works that comment on or otherwise explain it 343 or assist in its implementation may be prepared, copied, published 344 and distributed, in whole or in part, without restriction of any 345 kind, provided that the above copyright notice and this paragraph 346 are included on all such copies and derivative works. However, this 347 document itself may not be modified in any way, such as by removing 348 the copyright notice or references to the Internet Society or other 349 Internet organizations, except as needed for the purpose of 350 developing Internet standards in which case the procedures for 351 copyrights defined in the Internet Standards process must be 352 followed, or as required to translate it into languages other than 353 English. 355 The limited permissions granted above are perpetual and will not be 356 revoked by the Internet Society or its successors or assignees. 358 This document and the information contained herein is provided on an 359 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 360 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 361 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 362 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 363 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 365 10 Intellectual Property 366 The following notice is copied from RFC 2026 [Bradner, 1996], 367 Section 10.4, and describes the position of the IETF concerning 368 intellectual property claims made against this document. 370 The IETF takes no position regarding the validity or scope of any 371 intellectual property or other rights that might be claimed to 372 pertain to the implementation or use other technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; neither does it represent that it 375 has made any effort to identify any such rights. Information on the 376 IETF's procedures with respect to rights in standards-track and 377 standards-related documentation can be found in BCP-11. Copies of 378 claims of rights made available for publication and any assurances 379 of licenses to be made available, or the result of an attempt made 380 to obtain a general license or permission for the use of such 381 proprietary rights by implementers or users of this specification 382 can be obtained from the IETF Secretariat. 384 The IETF invites any interested party to bring to its attention any 385 copyrights, patents or patent applications, or other proprietary 386 rights which may cover technology that may be required to practice 387 this standard. Please address the information to the IETF Executive 388 Director. 390 11 Acknowledgements 392 The discussion presented here was triggered by a note that Brad 393 Huntting sent to the NGTRANS and IPNG working groups. The note 394 revived previous informal discussions, for which we have to 395 acknowledge the members of the NGTRANS and IPNG working groups, in 396 particular Scott Bradner, Randy Bush, Brian Carpenter, Steve 397 Deering, Bob Fink, Tony Hain, Bill Manning, Keith Moore and Dave 398 Thaler. 400 12 References 402 [6TO4] B. Carpenter, K. Moore. Connection of IPv6 Domains via IPv4 403 Clouds. Work in Progress. 405 13 Author's Addresses 407 Christian Huitema 408 Microsoft Corporation 409 One Microsoft Way 410 Redmond, WA 98052-6399 412 Email: huitema@exchange.microsoft.com