idnits 2.17.1 draft-ietf-ngtrans-6to4anycast-02.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 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 29 instances of lines with control characters in the document. ** The abstract seems to contain references ([TBDIANA], [Bradner,1996], [RFC3056]), 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 (February 19, 2001) is 8461 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? 'RFC3056' on line 359 looks like a reference -- Missing reference section? 'TBD IANA' on line 114 looks like a reference -- Missing reference section? 'Bradner' on line 323 looks like a reference -- Missing reference section? '1996' on line 323 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires August 19, 2001 February 19, 2001 5 An anycast prefix for 6to4 relay routers 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference 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 The operation of 6to4 routers requires either that the routers 31 participate in IPv6 inter-domain routing, or that the routers be 32 provisioned with a default route. This memo proposes a standard 33 method to define the default route. It introduces the IANA assigned 34 "6to4 Relay anycast prefix" from which 6to4 routers can derive the 35 static "6to4 anycast address". In order to enable efficient 36 management of the "6to4 Relay anycast prefix" in IPv4 inter-domain 37 routing, this memo also documents the reservation by IANA of a "6to4 38 Autonomous System ID." With this definition, the proposed scheme 39 guarantees that 6to4 packets will be automatically routed to the 40 nearest available router. It allows the managers of the 6to4 relay 41 routers to control the sources authorized to use their resource. It 42 makes it easy to set up a large number of 6to4 relay routers, thus 43 enabling scalability. 45 1 Introduction 47 According to [RFC3056], there are two deployment options for a 6to4 48 routing domain, depending on whether or not the domain is using an 49 IPv6 exterior routing protocol. If a routing protocol is used, then 50 the 6to4 routers acquire routes to all existing IPv6 networks 51 through the combination of EGP and IGP. If no IPv6 exterior routing 52 protocol is used, the 6to4 routers using a given relay router each 53 have a default IPv6 route pointing to the relay router. This second 54 case is typically used by small networks; for these networks, 55 finding and configuring the default route is in practice a 56 significant hurdle. In addition, even when the managers of these 57 networks find an available route, this route often points to a 58 router on the other side of the Internet, leading to very poor 59 performance. 61 This memo introduces a "6to4 anycast address" in order to simplify 62 the configuration of 6to4 routers. It also defines how this address 63 will be used by 6to4 relay routers, how the corresponding "6to4 64 anycast prefix" will be advertised in the IGP and in the EGP. The 65 memo documents the reservation by IANA of the "6to4 relay anycast 66 prefix" and of a "6to4 Autonomous System ID." 68 2 Definitions 70 This memo uses the definitions introduced in [RFC3056], in 71 particular the definition of a 6to4 router and a 6to4 Relay Router. 72 It adds the definition of the 6to4 Relay anycast prefix, 74 2.1 6to4 router (or 6to4 border router) 76 An IPv6 router supporting a 6to4 pseudo-interface. It is normally 77 the border router between an IPv6 site and a wide-area IPv4 network. 79 2.2 6to4 Relay Router 81 A 6to4 router configured to support transit routing between 6to4 82 addresses and native IPv6 addresses. 84 2.3 6to4 Relay anycast prefix 86 An IPv4 address prefix used to advertise an IPv4 route to an 87 available 6to4 Relay Router, as defined in this memo. 89 The value of this prefix is x.x.x.0/nn [Length and value TBD IANA] 91 2.4 6to4 Relay anycast address 93 An IPv4 address used to reach the nearest 6to4 Relay Router, as 94 defined in this memo. 96 The address corresponds to host number 1 in the 6to4 Relay anycast 97 prefix, x.x.x.1. [Derived from the 6to4 Relay anycast prefix, TBD 98 IANA] 100 2.5 6to4 IPv6 relay anycast address 102 The IPv6 address derived from the 6to4 Relay anycast address 103 according to the rules defined in 6to4, using a null prefix and a 104 null host identifier. 106 The value of the address is "2002:XXXX:XX01::". [Derived from the 107 6to4 Relay anycast address, TBD IANA] 109 2.6 6to4 Autonomous System ID 111 A 16-bit Autonomous system ID, for use in BGP in accordance to this 112 memo. 114 The value of the 6to4 Autonomous System ID is YYYY. [TBD IANA] 116 3 Model, requirements 118 Operation of 6to4 routers in domains that don't run an IPv6 EGP 119 requires that these routers be configured with a default route to 120 the IPv6 Internet. This route will be expressed as a 6to4 address. 121 The packets bound to this route will be encapsulated in IPv4 whose 122 source will be an IPv4 address associated to the 6to4 router, and 123 whose destination will be the IPv4 address that is extracted from 124 the default route. We want to arrive at a model of operation in 125 which the configuration is automatic. 127 It should also be easy to set up a large number of 6to4 relay 128 routers, in order to cope with the demand. The discovery of the 129 nearest relay router should be automatic; if a router fails, the 130 traffic should be automatically redirected to the nearest available 131 router. The managers of the 6to4 relay routers should be able to 132 control the sources authorized to use their resource. 134 4 Description of the solution 136 4.1 Default route in the 6to4 routers 138 The 6to4 routers are configured with the default IPv6 route (::/0) 139 pointing to the 6to4 IPv6 anycast address. 141 4.2 Behavior of 6to4 relay routers 143 The 6to4 relay routers that follow the specification of this memo 144 shall advertise the 6to4 anycast prefix, using the IGP of their IPv4 145 autonomous system, as if it where a connection to an external 146 network. 148 The 6to4 relay routers that advertise the 6to4 anycast prefix will 149 receive packets bound to the 6to4 anycast address. They will relay 150 these packets to the IPv6 Internet, as specified in [RFC3056]. 152 4.3 Interaction with the EGP 154 If the managers of an IPv4 autonomous domain that includes 6to4 155 relay routers want to make these routers available to neighbor ASes, 156 they will advertise reachability of the 6to4 anycast prefix. When 157 this advertisement is done using BGP, the AS path leading to the 158 6to4 anycast prefix shall include the identifier of the local AS and 159 the 6to4 Autonomous System ID. 161 The path to the 6to4 anycast prefix may be propagated using standard 162 EGP procedures. The whole v6 network will appear to v4 as a single 163 AS, with multiple peering points scattered over the whole Internet. 165 5 Discussion of the solution 167 The initial surfacing of the proposal in the NGTRANS working group 168 helped us discover a number of issues, such as scaling concerns, the 169 size of the address prefix, the need for an AS number, and concerns 170 about risking to stay too long in a transition state. 172 5.1 Does it scale? 174 With the proposed scheme, it is easy to first deploy a small number 175 of relay routers, which will carry the limited 6to4 traffic during 176 the initial phases of IPv6 deployment. The routes to these routers 177 will be propagated according to standard peering agreements. 179 As the demand for IPv6 increases, we expect that more ISPs will 180 deploy 6to4 relay routers. Standard IPv4 routing procedures will 181 direct the traffic to the nearest relay router, assuring good 182 performance. 184 5.2 Discovery and failover 186 The 6to4 routers send packets bound to the v6 Internet by tunneling 187 them to the 6to4 anycast address. These packets will reach the 188 closest 6to4 relay router provided by their ISP, or by the closest 189 ISP according to inter-domain routing. 191 The routes to the relay routers will be propagated according to 192 standard IPv4 routing rules. This ensures automatic discovery. 194 If a 6to4 relay router somehow breaks, or loses connectivity to the 195 v6 Internet, it will cease to advertise reachability of the 6to4 196 anycast prefix. At that point, the local IGP will automatically 197 compute a route towards the "next best" 6to4 relay router. 199 5.3 Access control 201 Only those ASes that run 6to4 relay routers and are willing to 202 provide access to the v6 network announce a path to the 6to4 anycast 203 prefix. They can use the existing structure of peering and transit 204 agreements to control to whom they are willing to provide service, 205 and possibly to charge for the service. 207 5.4 Why do we need a large prefix" 209 In theory, a single IP address, a.k.a. a /32 prefix, would be 210 sufficient: all IGPs, and even BGP, can carry routes that are 211 arbitrarily specific. In practice, however, such routes are almost 212 guaranteed not to work. 214 The size of the routing table is of great concern for the managers 215 of Internet "default free" networks: they don't want to waste a 216 routing entry, which is an important resource, for the sole benefit 217 of a small number of Internet nodes. Many have put in place filters 218 that automatically drop the routes that are too specific; most of 219 these filters are expressed as a function of the length of the 220 address prefix, such as "my network will not accept advertisements 221 for a network that is smaller than a /19." The actual limit may vary 222 from network to network, and also over time. We consider that a /16, 223 from the old class B, would be very safe. 225 It could indeed be argued that using a large network is a waste of 226 the precious addressing resource. However, this is a waste for the 227 good cause of actually moving to IPv6, i.e. providing a real relief 228 to the address exhaustion problem. 230 5.5 Why do we need a specific AS number? 232 Erroneous advertisements are a frequent source of errors in inter- 233 domain routing. A misconfigured AS will advertise that it can reach 234 some random network, divert the traffic, and effectively cut that 235 network from some parts of the Internet. As a protection, many 236 managers of border routers use databases to check the relation 237 between the advertised network and the last hop in the AS path. If 238 we use a specific AS to denote that "this is a path to IPv6", then 239 we can enter the relation between that AS and the 6to4 access prefix 240 in the databases used to check inter-domain routing. 242 5.6 Will this slow down the move to IPv6? 244 Some have expressed a concern that, while the assignment of an 245 anycast address to 6to4 access routers would make life a bit easier, 246 it would also tend to leave things in a transition state in 247 perpetuity. In fact, we believe that the opposite is true. 249 A condition for easy migration out of the "tunnelling" state is that 250 it be easy to have connectivity to the "real" IPv6 network; this 251 means that people trust that opting for a real IPv6 address will not 252 somehow result in lower performances. So the anycast proposal 253 actually ensures that we don't stay in a perpetual transition. 255 6 Future Work 257 Using a default route to reach the IPv6 Internet has a potential 258 drawback: the chosen relay may not be on the most direct path to the 259 target v6 address. In fact, one might argue that, in the early phase 260 of deployment, a relay close to the 6to4 site would probably not be 261 the site's ISP or the native destination's ISP... it would probably 262 be some third party ISP's relay which would be used for transit and 263 may have lousy connectivity. Using the relay closest to the native 264 destination would more closely match the v4 route, and quite 265 possibly provide a higher degree of reliability. A potential way to 266 deal with this issue is to use a "redirection" procedure, by which 267 the 6to4 router learns the most appropriate route for a specific 268 destination. This is left for further study. 270 7 Security Considerations 272 The generic security risks of 6to4 tunneling and the appropriate 273 protections are discussed in [RFC3056]. The anycast technique 274 introduces an additional risk, that a rogue router or a rogue AS 275 would introduce a bogus route to the 6to4 anycast prefix, and thus 276 divert the traffic. IPv4 network managers have to guarantee the 277 integrity of their routing to the 6to4 anycast prefix in much the 278 same way that they guarantee the integrity of the generic v4 279 routing. 281 8 IANA Considerations 283 The purpose of this memo is to document the allocation by IANA of an 284 IPv4 prefix dedicated to the 6to4 gateways to the native v6 285 Internet, and an autonomous system number dedicated to a pseudo-AS. 286 This is a one time effort; there is no need for any recurring 287 assignment. 289 9 Copyright 291 The following copyright notice is copied from RFC 2026 [Bradner, 292 1996], Section 10.4, and describes the applicable copyright for this 293 document. 295 Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved. 297 This document and translations of it may be copied and furnished to 298 others, and derivative works that comment on or otherwise explain it 299 or assist in its implementation may be prepared, copied, published 300 and distributed, in whole or in part, without restriction of any 301 kind, provided that the above copyright notice and this paragraph 302 are included on all such copies and derivative works. However, this 303 document itself may not be modified in any way, such as by removing 304 the copyright notice or references to the Internet Society or other 305 Internet organizations, except as needed for the purpose of 306 developing Internet standards in which case the procedures for 307 copyrights defined in the Internet Standards process must be 308 followed, or as required to translate it into languages other than 309 English. 311 The limited permissions granted above are perpetual and will not be 312 revoked by the Internet Society or its successors or assignees. 314 This document and the information contained herein is provided on an 315 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 316 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 317 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 318 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 319 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 321 10 Intellectual Property 323 The following notice is copied from RFC 2026 [Bradner, 1996], 324 Section 10.4, and describes the position of the IETF concerning 325 intellectual property claims made against this document. 327 The IETF takes no position regarding the validity or scope of any 328 intellectual property or other rights that might be claimed to 329 pertain to the implementation or use other technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; neither does it represent that it 332 has made any effort to identify any such rights. Information on the 333 IETF's procedures with respect to rights in standards-track and 334 standards-related documentation can be found in BCP-11. Copies of 335 claims of rights made available for publication and any assurances 336 of licenses to be made available, or the result of an attempt made 337 to obtain a general license or permission for the use of such 338 proprietary rights by implementers or users of this specification 339 can be obtained from the IETF Secretariat. 341 The IETF invites any interested party to bring to its attention any 342 copyrights, patents or patent applications, or other proprietary 343 rights which may cover technology that may be required to practice 344 this standard. Please address the information to the IETF Executive 345 Director. 347 11 Acknowledgements 349 The discussion presented here was triggered by a note that Brad 350 Huntting sent to the NGTRANS and IPNG working groups. The note 351 revived previous informal discussions, for which we have to 352 acknowledge the members of the NGTRANS and IPNG working groups, in 353 particular Scott Bradner, Randy Bush, Brian Carpenter, Steve 354 Deering, Bob Fink, Tony Hain, Bill Manning, Keith Moore and Dave 355 Thaler. 357 12 References 359 [RFC3056] B. Carpenter, K. Moore. Connection of IPv6 Domains via 360 IPv4 Clouds. RFC 3056, February 2001. 362 13 Author's Addresses 364 Christian Huitema 365 Microsoft Corporation 366 One Microsoft Way 367 Redmond, WA 98052-6399 369 Email: huitema@exchange.microsoft.com