idnits 2.17.1 draft-ietf-ipngwg-ipv6-2260-01.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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 ([Bates,1998]), 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 (April 12, 2001) is 8407 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? 'Bates' on line 71 looks like a reference -- Missing reference section? '1998' on line 247 looks like a reference -- Missing reference section? 'Hinden' on line 46 looks like a reference -- Missing reference section? 'Durand' on line 48 looks like a reference -- Missing reference section? '1999' on line 48 looks like a reference -- Missing reference section? 'Gilligan' on line 201 looks like a reference -- Missing reference section? '1996' on line 201 looks like a reference -- Missing reference section? 'Ferguson' on line 247 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jun-ichiro Hagino 3 INTERNET-DRAFT Research Laboratory, IIJ 4 Expires: October 12, 2001 April 12, 2001 6 IPv6 multihoming support at site exit routers 7 draft-ietf-ipngwg-ipv6-2260-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 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 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 The internet-draft will expire in 6 months. The date of expiration will 32 be October 12, 2001. 34 Abstract 36 The document describes a mechanism for basic IPv6 multihoming support, 37 and its operational requirements. The mechanism can be combined with 38 more sophisticated (or complex) multihoming support mechanisms, and can 39 be used as a foundation for other mechanisms. The document is largely 40 based on RFC2260 [Bates, 1998] by Tony Bates. 42 1. Problem 44 IPv6 specifications try to decrease the number of backbone routes, to 45 cope with possible memory overflow problem in the backbone routers. To 46 achieve this, the IPv6 addressing architecture [Hinden, 1998] only 47 allows the use of aggregatable addresses. Also, IPv6 network 48 administration rules [Durand, 1999] do not allow non-aggregatable 49 routing announcements to the backbone. 51 In IPv4, a multihomed site uses either of the following technique to 52 achieve better reachability: 54 o Obtain a portable IPv4 address prefix, and announce it from multiple 55 upstream providers. 57 o Obtain single IPv4 address prefix from ISP A, and announce it from 58 multiple upstream providers the site is connected to. 60 The above two methodologies are not available in IPv6, but on the other 61 hand IPv6 sites and hosts may obtain multiple simultaneous address 62 prefixes to achieve the same result. 64 The document provides a way to configure site exit routers and ISP 65 routers, so that the site can achieve better reachability from 66 multihomed connectivity, without violating IPv6 rules. Since the 67 technique uses already-defined routing protocol (BGP or RIPng) and 68 tunnelling of IPv6 packets, the document introduces no new protocol 69 standard. 71 The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. 73 2. Goals and non-goals 75 The goal of this document is to achieve better packet delivery from a 76 site to the outside, or from the outside to the site, even when some of 77 the site exit links are down. 79 Non goals are: 81 o Choose the "best" exit link as possible. Note that there can be no 82 common definition of the "best" exit link. 84 o Achieve load-balancing between multiple exit links. 86 3. Basic mechanisms 88 We use technique described in RFC2260 section 5.2 onto our 89 configuration. To summarize, for IPv4-only networks, RFC2260 says that: 91 o We assume that our site is connected to 2 ISPs, ISP-A and ISP-B. 93 o We are assigned IP address prefix, Pref-A and Pref-B, from ISP-A and 94 ISP-B respectively. Hosts near ISP-A will get an address from Pref- 95 A, and vice versa. 97 o In the site, we locally exchanage routes for Pref-A and Pref-B, so 98 that hosts in the site can communicate with each other without using 99 external link. 101 o ISP-A and our site is connected by ``primary link'' between ISP 102 router ISP-BR-A and our router E-BR-A. ISP B and our site is 103 connected by primary link between ISP router ISP-BR-B and our router 104 E-BR-B. 106 (ISP A) (ISP B) 108 ISP-BR-A ISP-BR-B 109 | | 110 |Primary link | 111 | | 112 | | 113 +---|-----------------------------|--+ 114 | E-BR-A E-BR-B | 115 | | 116 | Pref-A <----------> Pref-B | 117 +------------------------------------+ 119 o Establish a secondary link, between ISP-BR-A and E-BR-B, and ISP-BR-B 120 and E-BR-A, respectively. Secondary link usually is IP-over-IP 121 tunnel. It is important to have secondary link on top of different 122 medium than primary link, so that one of them survives link failure. 123 For example, secondary link between ISP-BR-A and E-BR-B should go 124 through different medium than primary link between ISP-BR-A and E-BR- 125 A. If secondary link is an IPv4-over-IPv4 tunnel, tunnel endpoint at 126 E-BR-A needs to be an address in Pref-A, not in Pref-B (tunnelled 127 packet needs to travel from ISP-BR-B to E-BR-A, over the primary link 128 between ISP-BR-A and E-BR-A). 130 (ISP A) (ISP B) 132 ISP-BR-A ISP-BR-B 133 | | | | 134 | \-----------------------+ | | 135 | Secondary link | | | 136 | +----------------------|-/ | 137 | | | | 138 | | | | 139 | | | | 140 | | | | 141 +---|--|----------------------|---|--+ 142 | E-BR-A E-BR-B | 143 | | 144 | | 145 +------------------------------------+ 147 o For inbound packets, E-BR-A will advertise (1) Pref-A toward ISP-BR-A 148 with strong preference over primary link, and (2) Pref-B toward ISP- 149 BR-B with weak preference over secondary link. Similarly, E-BR-B 150 will advertise (1) Pref-B toward ISP-BR-B with strong preference over 151 primary link, and (2) Pref-A toward ISP-BR-A with weak preference 152 over secondary link. 153 Note that we always announce Pref-A to ISP-BR-A, and Pref-B to ISP- 154 BR-B. 156 o For outbound packets, ISP-BR-A will advertise (1) default route (or 157 specific routes) toward E-BR-A with strong preference over primary 158 link, and (2) default route (or specific routes) toward E-BR-B with 159 weak preference over secondary link. Similarly, ISP-BR-B will 160 advertise (1) default route (or specific routes) toward E-BR-B with 161 strong preference over primary link, and (2) default route (or 162 specific routes) toward E-BR-A with weak preference over secondary 163 link. 165 Under this configuration, both inbound and outbound packet can survive 166 link failure on either side. Routing information with weak preference 167 will be available as backup, for both inbound and outbound cases. 169 4. Extensions for IPv6 171 RFC2260 is written for IPv4 and BGP. With IPv6 and BGP4+, or IPv6 and 172 RIPng, similar result can be achieved, without violating IPv6 173 addressing/routing rules. 175 4.1. IPv6 rule conformance 177 In RFC2260, we announce Pref-A toward ISP-BR-A only, and Pref-B toward 178 ISP-BR-B only. Therefore, there will be no extra routing announcement 179 to the outside of the site. This conforms to the aggregation 180 requirement in IPv6 documents. Also, RFC2260 does not require portable 181 addresses. 183 4.2. Address assignment to the nodes 185 In IPv4, it is usually assumed that a node will be assigned single IPv4 186 address. Therefore, RFC2260 assumed that addresses from Pref-A will be 187 assigned to nodes near E-BR-A, and vice versa (second bullet in the 188 previous section). 190 With IPv6, multiple IPv6 addresses can be assigned to a node. So we can 191 assign (1) one address from Pref-A, (2) one address from Pref-B, or (3) 192 two addresses from both address prefixes, to a single node in the site. 194 This will allow more flexibility in node configuration. However, this 195 may make source address selection on a node more complex. Source 196 address selection itself is out of scope of the document. 198 4.3. Configuration of links 200 With IPv6, primary link can be IPv6 native connectivity, RFC1933 201 [Gilligan, 1996] IPv6-over-IPv4 configured tunnel, 6to4 [Carpenter, 202 2000] IPv6-over-IPv4 encapsulation, or some others. 204 If tunnel-based connectivity is used in some of primary links, 205 administrators may want to avoid IPv6-over-IPv6 tunnels for secondary 206 links. For example, if: 208 o primary links to ISP-A and ISP-B are RFC1933 IPv6-over-IPv4 tunnels, 209 and 211 o ISP-A, ISP-B and the site have IPv4 connectivity with each other, 213 it makes no sense to configure a secondary link by IPv6-over-IPv6 214 tunnel, since it will actually be IPv6-over-IPv6-over-IPv4 tunnel. In 215 this case, IPv6-over-IPv4 tunnel should be used for secondary link. 216 IPv6-over-IPv4 configuration has a big advantage against IPv6-over- 217 IPv6-over-IPv4 configuration, as secondary link will be able to have the 218 same path MTU than the primary link. 220 4.4. Using RFC2260 with IPv6 and BGP4+ 222 RFC2260 approach on top of IPv6 will work fine as documented in RFC2260. 223 There will be no extra twists necessary. 225 4.5. Using RFC2260 with IPv6 and RIPng 227 It is possible to run RFC2260-like configuration with RIPng [Malkin, 228 1997] , with careful control of metric. Routers in the figure needs to 229 increase RIPng metric on secondary link, to make primary link a 230 preferred path. 232 If we denote the RIPng metric for route announcement, from router R1 233 toward router R2, as metric(R1, R2), the invariants that must hold are: 235 o metric(E-BR-A, ISP-BR-A) < metric(E-BR-B, ISP-BR-A) 237 o metric(E-BR-B, ISP-BR-B) < metric(E-BR-A, ISP-BR-B) 239 o metric(ISP-BR-A, E-BR-A) < metric(ISP-BR-A, E-BR-B) 241 o metric(ISP-BR-B, E-BR-B) < metric(ISP-BR-B, E-BR-A) 243 Note that smaller metric means stronger route in RIPng. 245 5. Issues with ingress filters in ISP 247 If the upstream ISP imposes ingress filters [Ferguson, 1998] to outbound 248 traffic, story becomes much more complex. A packet with source address 249 taken from Pref-A must go out from ISP-BR-A. Similarly, a packet with 250 source address taken from Pref-B must go out from ISP-BR-B. Since none 251 of the routers in the site network will route packets based on source 252 address, packets can easily be routed to incorrect border router. 254 One possible way is to negotiate with both ISPs, to allow both Pref-B 255 and Pref-A to be used as source address. This approach does not work if 256 upstream ISP of ISP-A imposes ingress filtering. Since there will be 257 multiple levels of ISP on top of ISP-A, it will be hard to understand 258 which upstream ISP imposes the filter. In reality, this problem will be 259 very rare, as ingress filter is not suitable for use in large ISPs where 260 smaller ISPs are connected beneath. 262 Another possibility is to use source-based routing at E-BR-A and E-BR-B. 263 Here we assume that IPv6-over-IPv6 tunnel is used for secondary links. 264 When an outbound packet arrives to E-BR-A with source address in Pref-B, 265 E-BR-A will forward it to secondary link (tunnel to ISP-BR-B) based on 266 source-based routing decision. The packet will look like this: 268 o Outer IPv6 header: source = address of E-BR-A in Pref-A, dest = ISP- 269 BR-B 271 o Inner IPv6 header: source = address in Pref-B, dest = final dest 273 Tunneled packet will travel across ISP-BR-A toward ISP-BR-B. The packet 274 can go through ingress filter at ISP-BR-A, since it has outer IPv6 275 source address in Pref-A. Packet will reach ISP-BR-B and decapsulated 276 before ingress filter is applied. Decapsulated packet can go through 277 ingress filter at ISP-BR-B, since it now has source address in Pref-B 278 (from inner IPv6 header). Notice the following facts when configuring 279 this: 281 o Not every router implements source-based routing. 283 o The interaction between normal routing and source-based routing at E- 284 BR-A (and/or E-BR-B) varies by router implementations. 286 o At ISP-BR-B (and/or ISP-BR-A), the interaction between tunnel egress 287 processing and filtering rules varies by router implementations and 288 filter configurations. 290 6. Observations 292 The document discussed the cases where a site has two upstream ISPs. 293 The document can easily be extended to the cases where there are 3 or 294 more upstream ISPs. 296 If you have many upstream providers, you would not make all ISPs backup 297 each other, as it requires O(N^2) tunnels for N ISPs. Rather, it is 298 better to make N/2 pairs of ISPs, and let each pair of ISP backup each 299 other. It is important to pick pairs which are unlikely to be down 300 simultaneously. In this way, number of tunnels will be O(N). 302 Suppose that the site is very large and it has ISP links in very distant 303 locations, such as in the United States and in Japan. In such case, it 304 is wiser to use this technique only among ISP links in the US, and only 305 among ISP links in Japan. If you use this technique between ISP link A 306 in the US and ISP link B in Japan, the secondary link makes packets 307 travel very long path, for example, from host in the site in the US, to 308 E-BR-B in Japan, to ISP-BR-B (again in Japan), and then to the final 309 destination in the US. This may not make sense for actual use, due to 310 excessive delay. 312 Similarly, in a large site, addresses must be assigned to end nodes with 313 great care, to minimize delays due to extra path packets may travel. It 314 may be wiser to avoid assigning an address in a prefix assigned from 315 Japanese ISP, to an end node in the US. 317 If one of primary link is down for a long time, administrators may want 318 to control source address selection on end hosts so that secondary link 319 is less likely to be used. This can be achieved by marking unwanted 320 prefix as deprecated. Suppose the primary link toward ISP-A has been 321 down. You will issue router advertisement [Thomson, 1998; Narten, 1998] 322 packets from routers, with preferred lifetime set to 0 in prefix 323 information option for Pref-A. End hosts will consider addresses in 324 Pref-A as deprecated, and will not use any of them as source address for 325 future connections. If an end host in the site makes new connection to 326 outside, the host will use an address in Pref-B as source address, and 327 reply packet to the end host will travel primary link from ISP-BR-B 328 toward E-BR-B. 330 Some of non-goals (such as "best" exit link selection) can be achieved 331 by combining technique described in this document, with some other 332 techniques. One example of the technique would be the 333 source/destination address selection heuristics on the end nodes. 335 7. Security considerations 337 The configuration described in the document introduces no new security 338 problem. 340 If primary links toward ISP-A and ISP-B have different security 341 characteristics (like encrypted link and non-encrypted link), 342 administrators needs to be careful setting up secondary links tunneled 343 on them. Packets may travel unwanted path, if secondary links are 344 configured without care. 346 References 348 Bates, 1998. 349 T. Bates and Y. Rekhter, "Scalable Support for Multi-homed Multi- 350 provider Connectivity" in RFC2260 (January 1998). ftp://ftp.isi.edu/in- 351 notes/rfc2260.txt. 353 Hinden, 1998. 354 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 355 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 357 Durand, 1999. 358 A. Durand and B. Buclin, "6Bone Routing Practice" in RFC2546 (March 359 1999). ftp://ftp.isi.edu/in-notes/rfc2546.txt. 361 Gilligan, 1996. 362 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and 363 Routers" in RFC1933 (April 1996). ftp://ftp.isi.edu/in- 364 notes/rfc1933.txt. 366 Carpenter, 2000. 367 Brian Carpenter and Keith Moore, "Connection of IPv6 Domains via IPv4 368 Clouds without Explicit Tunnels" in draft-ietf-ngtrans-6to4-06.txt (June 369 2000). work in progress. 371 Malkin, 1997. 372 G. Malkin and R. Minnear, "RIPng for IPv6" in RFC2080 (January 1997). 373 ftp://ftp.isi.edu/in-notes/rfc2080.txt. 375 Ferguson, 1998. 376 P. Ferguson and D. Senie, "Network Ingress Filtering: Defeating Denial 377 of Service Attacks which employ IP Source Address Spoofing" in RFC2267 378 (January 1998). ftp://ftp.isi.edu/in-notes/rfc2267.txt. 380 Thomson, 1998. 381 S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in 382 RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt. 384 Narten, 1998. 385 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP 386 Version 6 (IPv6)" in RFC2461 (December 1998). ftp://ftp.isi.edu/in- 387 notes/rfc2461.txt. 389 Acknowledgements 391 The document was made possible by cooperation from people in ipngwg 392 multihoming design team, people in KAME project and George Tsirtsis. 394 Author's address 396 Jun-ichiro Hagino 397 Research Laboratory, Internet Initiative Japan Inc. 398 Takebashi Yasuda Bldg., 399 3-13 Kanda Nishiki-cho, 400 Chiyoda-ku,Tokyo 101-0054, JAPAN 401 Tel: +81-3-5259-6350 402 Fax: +81-3-5259-6351 403 email: itojun@iijlab.net