idnits 2.17.1 draft-ietf-v6ops-design-choices-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 372: '... A router MUST be able to determi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2708 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'RFC5220' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC5838' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 1085, but no explicit reference was found in the text == Unused Reference: 'RFC6752' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'RFC6879' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC7010' is defined on line 1111, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-14 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS Working Group P. Matthews 3 Internet-Draft Nokia 4 Intended status: Informational V. Kuarsingh 5 Expires: May 1, 2017 Cisco 6 October 28, 2016 8 Some Design Choices for IPv6 Networks 9 draft-ietf-v6ops-design-choices-11 11 Abstract 13 This document presents advice on certain routing-related design 14 choices that arise when designing IPv6 networks (both dual-stack and 15 IPv6-only). The intended audience is someone designing an IPv6 16 network who is knowledgeable about best current practices around IPv4 17 network design, and wishes to learn the corresponding practices for 18 IPv6. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 1, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1.1. Where to Use Addresses . . . . . . . . . . . . . . . 4 58 2.1.2. Which Addresses to Use . . . . . . . . . . . . . . . 6 59 2.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? . . 7 61 2.3. Static Routes . . . . . . . . . . . . . . . . . . . . . . 8 62 2.3.1. Link-Local Next-Hop in a Static Route? . . . . . . . 8 63 2.4. IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.4.1. IGP Choice . . . . . . . . . . . . . . . . . . . . . 9 65 2.4.2. IS-IS Topology Mode . . . . . . . . . . . . . . . . . 12 66 2.4.3. RIP / RIPng . . . . . . . . . . . . . . . . . . . . . 13 67 2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 2.5.1. Which Transport for Which Routes? . . . . . . . . . . 14 69 2.5.1.1. BGP Sessions for Unlabeled Routes . . . . . . . . 16 70 2.5.1.2. BGP sessions for Labeled or VPN Routes . . . . . 17 71 2.5.2. eBGP Endpoints: Global or Link-Local Addresses? . . . 18 72 3. General Observations . . . . . . . . . . . . . . . . . . . . 19 73 3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 19 74 3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 20 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 78 7. Informative References . . . . . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 81 1. Introduction 83 This document discusses routing-related design choices that arise 84 when designing a Pv6-only or dual-stack network. The focus is on 85 choices that do not come up when designing an IPv4-only network. The 86 document presents each choice and the alternatives, and then 87 discusses the pros and cons of the alternatives in detail. Where 88 consensus currently exists around the best practice, this is 89 documented; otherwise the document simply summarizes the current 90 state of the discussion. Thus this document serves to both document 91 the reasoning behind best current practices for IPv6, and to allow a 92 designer to make an informed choice where no such consensus exists. 94 The design choices presented apply to both Service Provider and 95 Enterprise network environments. Where choices have selection 96 criteria which differ between the Service Provider and the Enterprise 97 environment, this is noted. The designer is encouraged to ensure 98 that they familiarize themselves with any of the discussed 99 technologies to ensure the best selection is made for their 100 environment. 102 This document does not present advice on strategies for adding IPv6 103 to a network, nor does it discuss transition in these areas, see 104 [RFC6180] for general advice,[RFC6782] for wireline service 105 providers, [RFC6342]for mobile network providers, [RFC5963] for 106 exchange point operators, [RFC6883] for content providers, and both 107 [RFC4852] and [RFC7381] for enterprises. Nor does this document 108 discuss the particulars of creating an IPv6 addressing plan; for 109 advice in this area, see [RFC5375] or [v6-addressing-plan]. 111 Finally, this document focuses on unicast routing design only and 112 does not cover multicast or the issues involved in running MPLS over 113 IPv6 transport. 115 2. Design Choices 117 Each subsection below presents a design choice and discusses the pros 118 and cons of the various options. If there is consensus in the 119 industry for a particular option, then the consensus position is 120 noted. 122 2.1. Addresses 124 This section discusses the choice of addresses for router loopbacks 125 and links between routers. It does not cover the choice of addresses 126 for end hosts. 128 In IPv6, all interfaces are assigned a Link-Local Address (LLA) 129 [ref]. The Link-Local address can only be used for communicating 130 with devices that are on-link, so often additional addresses are 131 assigned which are able to communicate off-link. These additional 132 addresses can be one of three types: 134 o Provider-Independent Global Unicast Address (PI GUA): IPv6 address 135 allocated by a regional address registry [RFC4291] 137 o Provider-Aggregatable Global Unicast Address (PA GUA): IPv6 138 Address allocated by your upstream service provider 140 o Unique Local Address (ULA): IPv6 address locally assigned 141 [RFC4193] 143 This document uses the term "multi-hop address" to collectively refer 144 to these three types of addresses. 146 PI GUAs are, for many situations, the most flexible of these choices. 147 Their main disadvantages are that a regional address registry will 148 only allocate them to organizations that meet certain qualifications, 149 and one must pay an annual fee. These disadvantages mean that some 150 smaller organization may not qualify or be willing to pay for these 151 addresses. 153 PA GUAs have the advantage that they are usually provided at no extra 154 charge when you contract with an upstream provider. However, they 155 have the disadvantage that, when switching upstream providers, one 156 must give back the old addresses and get new addresses from the new 157 provider ("renumbering"). Though IPv6 has mechanisms to make 158 renumbering easier than IPv4, these techniques are not generally 159 applicable to routers and renumbering is still fairly hard [RFC 160 5887]. PA GUAs also have the disadvantage that it is not easy to 161 have multiple upstream providers ("multi-homing") if they are used 162 (see section 1 of [RFC5533] ). 164 ULAs have the advantage that they are extremely easy to obtain and 165 cost nothing. However, they have the disadvantage that they cannot 166 be routed on the Internet, so must be used only within a limited 167 scope. In many situations, this is not a problem, but in certain 168 situations this can be problematic. Though there is currently no 169 document that describes these situations, many of them are similar to 170 those described in RFC 6752. See also 171 [I-D.ietf-v6ops-ula-usage-recommendations]. 173 Not discussed in this document is the possibility of using the 174 technology described in RFC 6296 to work around some of the 175 limitations of PA GUAs and ULAs. 177 2.1.1. Where to Use Addresses 179 As mentioned above, all interfaces in IPv6 always have a link-local 180 address. This section addresses the question of when and where to 181 assign multi-hop addresses in addition to the LLA. We consider four 182 options: 184 a. Use only link-local addresses on all router interfaces. 186 b. Assign multi-hop addresses to all link interfaces on each router, 187 and use only a link-local address on the loopback interfaces. 189 c. Assign multi-hop addresses to the loopback interface on each 190 router, and use only a link-local address on all link interfaces. 192 d. Assign multi-hop addresses to both link and loopback interfaces 193 on each router. 195 Option (a) means that the router cannot be reached (ping, management, 196 etc.) from farther than one-hop away. The authors are not aware of 197 anyone using this option. 199 Option (b) means that the loopback interfaces are effectively 200 useless, since link-local addresses cannot be used for the purposes 201 that loopback interfaces are usually used for. So option (b) 202 degenerates into option (d). 204 Thus the real choice comes down to option (c) vs. option (d). 206 Option (c) has two advantages over option (d). The first advantage 207 is ease of configuration. In a network with a large number of links, 208 the operator can just assign one multi-hop address to each router and 209 then enable the IGP, without going through the tedious process of 210 assigning and tracking the addresses on each link. The second 211 advantage is security. Since packets with link-local addresses 212 cannot be should not be routed, it is very difficult to attack the 213 associated nodes from an off-link device. This implies less effort 214 around maintaining security ACLs. 216 Countering these advantages are various disadvantages to option (c) 217 compared with option (d): 219 o It is not possible to ping a link-local-only interface from a 220 device that is not directly attached to the link. Thus, to 221 troubleshoot, one must typically log into a device that is 222 directly attached to the device in question, and execute the ping 223 from there. 225 o A traceroute passing over the link-local-only interface will 226 return the loopback address of the router, rather than the address 227 of the interface itself. 229 o In cases of parallel point to point links it is difficult to 230 determine which of the parallel links was taken when attempting to 231 troubleshoot unless one sends packets directly between the two 232 attached link-locals on the specific interfaces. Since many 233 network problems behave differently for traffic to/from a router 234 than for traffic through the router(s) in question, this can pose 235 a significant hurdle to some troubleshooting scenarios. 237 o On some routers, by default the link-layer address of the 238 interface is derived from the MAC address assigned to interface. 239 When this is done, swapping out the interface hardware (e.g. 240 interface card) will cause the link-layer address to change. In 241 some cases (peering config, ACLs, etc) this may require additional 242 changes. However, many devices allow the link-layer address of an 243 interface to be explicitly configured, which avoids this issue. 244 This problem should fade away over time as more and more routers 245 select interface identifiers according to the rules in [RFC7217]. 247 o The practice of naming router interfaces using DNS names is 248 difficult and not recommended when using link-locals only. More 249 generally, it is not recommended to put link-local addresses into 250 DNS; see [RFC4472]. 252 o It is often not possible to identify the interface or link (in a 253 database, email, etc) by giving just its address without also 254 specifying the link in some manner. 256 It should be noted that it is quite possible for the same link-local 257 address to be assigned to multiple interfaces. This can happen 258 because the MAC address is duplicated (due to manufacturing process 259 defaults or the use of virtualization), because a device deliberately 260 re-uses automatically-assigned link-local addresses on different 261 links, or because an operator manually assigns the same easy-to-type 262 link-local address to multiple interfaces. All these are allowed in 263 IPv6 as long as the addresses are used on different links. 265 For more discussion on the pros and cons, see [RFC7404]. See also 266 [RFC5375] for IPv6 unicast address assignment considerations. 268 Today, most operators use option (d). 270 2.1.2. Which Addresses to Use 272 Having considered above whether or not to use a "multi-hop address", 273 we now consider which of the addresses to use. 275 When selecting between these three "multi-hop address" types, one 276 needs to consider exactly how they will be used. An important 277 consideration is how Internet traffic is carried across the core of 278 the network. There are two main options: (1) the classic approach 279 where Internet traffic is carried as unlabeled traffic hop-by-hop 280 across the network, and (2) the more recent approach where Internet 281 traffic is carried inside an MPLS LSP (typically as part of a L3 282 VPN). 284 Under the classic approach: 286 o PI GUAs are a very reasonable choice, if they are available. 288 o PA GUAs suffer from the "must renumber" and "difficult to multi- 289 home" problems mentioned above. 291 o ULAs suffer from the "may be problematic" issues described above. 293 Under the MPLS approach: 295 o PA GUAs are a reasonable choice, if they are available. 297 o PA GUAs suffer from the "must renumber" problem, but the 298 "difficult to multi-home" problem does not apply. 300 o ULAs are a reasonable choice, since (unlike in the classic 301 approach) these addresses are not visible to the Internet, so the 302 problematic cases do not occur. 304 2.2. Interfaces 306 2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? 308 If a network is going to carry both IPv4 and IPv6 traffic, as many 309 networks do today, then a question arises: Should an operator mix 310 IPv4 and IPv6 traffic or keep them separated? More specifically, 311 should the design: 313 a. Mix IPv4 and IPv6 traffic on the same layer-3 interface, OR 315 b. Separate IPv4 and IPv6 by using separate interfaces (e.g., two 316 physical links or two VLANs on the same link)? 318 Option (a) implies a single layer-3 interface at each end of the 319 connection with both IPv4 and IPv6 addresses; while option (b) 320 implies two layer-3 interfaces at each end, one for IPv4 addresses 321 and one with IPv6 addresses. 323 The advantages of option (a) include: 325 o Requires only half as many layer 3 interfaces as option (b), thus 326 providing better scaling; 328 o May require fewer physical ports, thus saving money and 329 simplifying operations; 331 o Can make the QoS implementation much easier (for example, rate- 332 limiting the combined IPv4 and IPv6 traffic to or from a 333 customer); 335 o Works well in practice, as any increase in IPv6 traffic is usually 336 counter-balanced by a corresponding decrease in IPv4 traffic to or 337 from the same host (ignoring the common pattern of an overall 338 increase in Internet usage); 340 o And is generally conceptually simpler. 342 For these reasons, there is a relatively strong consensus in the 343 operator community that option (a) is the preferred way to go. Most 344 networks today use option (a) wherever possible. 346 However, there can be times when option (b) is the pragmatic choice. 347 Most commonly, option (b) is used to work around limitations in 348 network equipment. One big example is the generally poor level of 349 support today for individual statistics on IPv4 traffic vs IPv6 350 traffic when option (a) is used. Other, device-specific, limitations 351 exist as well. It is expected that these limitations will go away as 352 support for IPv6 matures, making option (b) less and less attractive 353 until the day that IPv4 is finally turned off. 355 2.3. Static Routes 357 2.3.1. Link-Local Next-Hop in a Static Route? 359 For the most part, the use of static routes in IPv6 parallels their 360 use in IPv4. There is, however, one exception, which revolves around 361 the choice of next-hop address in the static route. Specifically, 362 should an operator: 364 a. Use the far-end's link-local address as the next-hop address, OR 366 b. Use the far-end's GUA/ULA address as the next-hop address? 368 Recall that the IPv6 specs for OSPF [RFC5340] and ISIS [RFC5308] 369 dictate that they always use link-locals for next-hop addresses. For 370 static routes, [RFC4861] section 8 says: 372 A router MUST be able to determine the link-local address for each 373 of its neighboring routers in order to ensure that the target 374 address in a Redirect message identifies the neighbor router by 375 its link-local address. For static routing, this requirement 376 implies that the next-hop router's address should be specified 377 using the link-local address of the router. 379 This implies that using a GUA or ULA as the next hop will prevent a 380 router from sending Redirect messages for packets that "hit" this 381 static route. All this argues for using a link-local as the next-hop 382 address in a static route. 384 However, there are two cases where using a link-local address as the 385 next-hop clearly does not work. One is when the static route is an 386 indirect (or multi-hop) static route. The second is when the static 387 route is redistributed into another routing protocol. In these 388 cases, the above text from RFC 4861 notwithstanding, either a GUA or 389 ULA must be used. 391 Furthermore, many network operators are concerned about the 392 dependency of the default link-local address on an underlying MAC 393 address, as described in the previous section. 395 Today most operators use GUAs as next-hop addresses. 397 2.4. IGPs 399 2.4.1. IGP Choice 401 One of the main decisions for a network operator looking to deploy 402 IPv6 is the choice of IGP (Interior Gateway Protocol) within the 403 network. The main options are OSPF, IS-IS and EIGRP. RIPng is 404 another option, but very few networks run RIP in the core these days, 405 so it is covered in a separate section below. 407 OSPF [RFC2328] [RFC5340] and IS-IS [RFC5120][RFC5120] are both 408 standardized link-state protocols. Both protocols are widely 409 supported by vendors, and both are widely deployed. By contrast, 410 EIGRP [RFC7868] is a Cisco proprietary distance-vector protocol. 411 EIGRP is rarely deployed in service-provider networks, but is quite 412 common in enterprise networks, which is why it is discussed here. 414 It is out of scope for this document to describe all the differences 415 between the three protocols; the interested reader can find books and 416 websites that go into the differences in quite a bit of detail. 417 Rather, this document simply highlights a few differences that can be 418 important to consider when designing IPv6 or dual-stack networks. 420 Versions: There are two versions of OSPF: OSPFv2 and OSPFv3. The two 421 versions share many concepts, are configured in a similar manner and 422 seem very similar to most casual users, but have very different 423 packet formats and other "under the hood" differences. The most 424 important difference is that OSPFv2 will only route IPv4, while 425 OSPFv3 will route both IPv4 and IPv6. OSPFv2 was by far the most 426 widely deployed version of OSPF when this document was published. By 427 contrast, both IS-IS and EIGRP have just a single version, which can 428 route both IPv4 and IPv6. 430 Transport. IS-IS runs over layer 2 (e.g. Ethernet). This means 431 that the functioning of IS-IS has no dependencies on the IP layer: if 432 there is a problem at the IP layer (e.g. bad addresses), two routers 433 can still exchange IS-IS packets. By contrast, OSPF and EIGRP both 434 run over the IP layer. This means that the IP layer must be 435 configured and working OSPF or EIGRP packets to be exchanged between 436 routers. For EIGRP, the dependency on the IP layer is simple: EIGRP 437 for IPv4 runs over IPv4, while EIGRP for IPv6 runs over IPv6. For 438 OSPF, the story is more complex: OSPFv2 runs over IPv4, but OSPFv3 439 can run over either IPv4 or IPv6. Thus it is possible to route both 440 IPv4 and IPv6 with OSPFv3 running over IPv6 or with OSPFv3 running 441 over IPv4. This means that there are number of choices for how to 442 run OSPF in a dual-stack network: 444 o Use OSPFv2 for routing IPv4 , and OSPFv3 running over IPv6 for 445 routing IPv6, OR 447 o Use OSPFv3 running over IPv6 for routing both IPv4 and IPv6, OR 449 o Use OSPFv3 running over IPv4 for routing both IPv4 and IPv6. 451 Summarization and MPLS: For most casual users, the three protocols 452 are fairly similar in what they can do, with two glaring exceptions: 453 summarization and MPLS. For summarization, both OSPF and IS-IS have 454 the concept of summarization between areas, but the two area concepts 455 are quite different, and an area design that works for one protocol 456 will usually not work for the other. EIGRP has no area concept, but 457 has the ability to summarize at any router. Thus a large network 458 will typically have a very different OSPF, IS-IS and EIGRP designs, 459 which is important to keep in mind if you are planning on using one 460 protocol to route IPv4 and a different protocol for IPv6. The other 461 difference is that OSPF and IS-IS both support RSVP-TE, a widely-used 462 MPLS signaling protocol, while EIGRP does not: this is due to OSPF 463 and IS-IS both being link-state protocols while EIGRP is a distance- 464 vector protocol. 466 The table below sets out possible combinations of protocols to route 467 both IPv4 and IPv6, and makes some observations on each combination. 468 Here "EIGRP-v4" means "EIGRP for IPv4" and similarly for "EIGRP-v6". 469 For OSPFv3, it is possible to run it over either IPv4 or IPv6; this 470 is not indicated in the table. 472 +----------+----------+-------------+----------------+--------------+ 473 | IGP for | IGP for | Protocol | Similar | Multiple | 474 | IPv4 | IPv6 | separation | configuration | Known | 475 | | | | possible | Deployments | 476 +----------+----------+-------------+----------------+--------------+ 477 | | | | | | 478 +----------+----------+-------------+----------------+--------------+ 479 | OSPFv2 | OSPFv3 | YES | YES | YES (8) | 480 +----------+----------+-------------+----------------+--------------+ 481 | OSPFv2 | IS-IS | YES | - | YES (3) | 482 +----------+----------+-------------+----------------+--------------+ 483 | OSPFv2 | EIGRP-v6 | YES | - | - | 484 +----------+----------+-------------+----------------+--------------+ 485 | OSPFv3 | OSPFv3 | NO | YES | - | 486 +----------+----------+-------------+----------------+--------------+ 487 | OSPFv3 | IS-IS | YES | - | - | 488 +----------+----------+-------------+----------------+--------------+ 489 | OSPFv3 | EIGRP-v6 | YES | - | - | 490 +----------+----------+-------------+----------------+--------------+ 491 | IS-IS | OSPFv3 | YES | - | YES (2) | 492 +----------+----------+-------------+----------------+--------------+ 493 | IS-IS | IS-IS | - | YES | YES (12) | 494 +----------+----------+-------------+----------------+--------------+ 495 | IS-IS | EIGRP-v6 | YES | - | - | 496 +----------+----------+-------------+----------------+--------------+ 497 | EIGRP-v4 | OSPFv3 | YES | - | ? (1) | 498 +----------+----------+-------------+----------------+--------------+ 499 | EIGRP-v4 | IS-IS | YES | - | - | 500 +----------+----------+-------------+----------------+--------------+ 501 | EIGRP-v4 | EIGRP-v6 | - | YES | ? (2) | 502 +----------+----------+-------------+----------------+--------------+ 504 In the column "Multiple Known Deployments", a YES indicates that a 505 significant number of production networks run this combination, with 506 the number of such networks indicated in parentheses following, while 507 a "?" indicates that the authors are only aware of one or two small 508 networks that run this combination. Data for this column was 509 gathered from an informal poll of operators on a number of mailing 510 lists. This poll was not intended to be a thorough scientific study 511 of IGP choices, but to provide a snapshot of known operator choices 512 at the time of writing (Mid-2015) for successful production dual 513 stack network deployments. There were twenty six (26) network 514 implementations represented by 17 respondents. Some respondents 515 provided information on more then one network or network deployment. 516 Due to privacy considerations, the networks' represented and 517 respondents are not listed in this document. 519 A number of combinations are marked as offering "Protocol 520 separation". These options use a different IGP protocol for IPv4 vs 521 IPv6. With these options, a problem with routing IPv6 is unlikely to 522 affect IPv4 or visa-versa. Some operator may consider this as a 523 benefit when first introducing dual stack capabilities or for ongoing 524 technical reasons. 526 Three combinations are marked "Similar configuration possible". This 527 means it is possible (but not required) to use very similar IGP 528 configuration for IPv4 and IPv6: for example, the same area 529 boundaries, area numbering, link costing, etc. If you are happy with 530 your IPv4 IGP design, then this will likely be a consideration. By 531 contrast, the options that use, for example, IS-IS for one IP version 532 and OSPF for the other version will require considerably different 533 configuration, and will also require the operations staff to become 534 familiar with the difference between the two protocols. 536 It should be noted that a number of ISPs have run OSPF as their IPv4 537 IGP for quite a few years, but have selected IS-IS as their IPv6 IGP. 538 However, there are very few (none?) that have made the reverse 539 choice. This is, in part, because routers generally support more 540 nodes in an IS-IS area than in the corresponding OSPF area, and 541 because IS-IS is seen as more secure because it runs at layer 2. 543 2.4.2. IS-IS Topology Mode 545 When IS-IS is used to route both IPv4 and IPv6, then there is an 546 additional choice of whether to run IS-IS in single-topology or 547 multi-topology mode. 549 With single-topology mode (also known as Native mode) [RFC5308]: 551 o IS-IS keeps a single link-state database for both IPv4 and IPv6. 553 o There is a single set of link costs which apply to both IPv4 and 554 IPv6. 556 o All links in the network must support both IPv4 and IPv6, as the 557 calculation of routes does not take this into account. If some 558 links do not support IPv6 (or IPv4), then packets may get routed 559 across links where support is lacking and get dropped. This can 560 cause problems if some network devices do not support IPv6 (or 561 IPv4). 563 o It is also important to keep the previous point in mind when 564 adding or removing support for either IPv4 or IPv6. 566 With multi-topology mode [ref]: 568 o IS-IS keeps two link-state databases, one for IPv4 and one for 569 IPv6. 571 o IPv4 and IPv6 can have separate link metrics. Note that most 572 implementations today require separate link metrics: a number of 573 operators have rudely discovered that they have forgotten to 574 configure the IPv6 metric until sometime after deploying IPv6 in 575 multi-topology mode! 577 o Some links can be IPv4-only, some IPv6-only, and some dual-stack. 578 Routes to IPv4 and IPv6 addresses are computed separately and may 579 take different paths even if the addresses are located on the same 580 remote device. 582 o The previous point may help when adding or removing support for 583 either IPv4 or IPv6. 585 In the informal poll of operators, out of 12 production networks that 586 ran IS-IS for both IPv4 and IPv6, 6 used single topology mode, 4 used 587 multi-topology mode, and 2 did not specify. One motivation often 588 cited by then operators for using Single Topology mode was because 589 some device did not support multi-topology mode. 591 When asked, many people feel multi-topology mode is superior to 592 single-topology mode because it provides greater flexibility at 593 minimal extra cost. Never-the-less, as shown by the poll results, a 594 number of operators have used single-topology mode successfully. 596 Note that this issue does not come up with OSPF, since there is 597 nothing that corresponds to IS-IS single-topology mode with OSPF. 599 2.4.3. RIP / RIPng 601 A protocol option not described in the table above is RIP for IPv4 602 and RIPng for IPv6 [RFC2080]. These are distance vector protocols 603 that are almost universally considered to be inferior to OSPF, IS-IS, 604 or EIGRP for general use. 606 However, there is one specialized use where RIP/RIPng is still 607 considered to be appropriate: in star topology networks where a 608 single core device has lots and lots of links to edge devices and 609 each edge device has only a single path back to the core. In such 610 networks, the single path means that the limitations of RIP/RIPng are 611 mostly not relevant and the very light-weight nature of RIP/RIPng 612 gives it an advantage over the other protocols mentioned above. One 613 concrete example of this scenario is the use of RIP/RIPng between 614 cable modems and the CMTS. 616 2.5. BGP 618 2.5.1. Which Transport for Which Routes? 620 BGP these days is multi-protocol. It can carry routes of many 621 different types, or more precisely, many different AFI/SAFI 622 combinations. It can also carry routes when the BGP session, or more 623 accurately the underlying TCP connection, runs over either IPv4 or 624 IPv6 (here referred to as either "IPv4 transport" or "IPv6 625 transport"). Given this flexibility, one of the biggest questions 626 when deploying BGP in a dual-stack network is the question of which 627 route types should be carried over sessions using IPv4 transport and 628 which should be carried over sessions using IPv6 transport. 630 This section discusses this question for the three most-commonly-used 631 SAFI values: unlabeled (SAFI 1), labeled (SAFI 4) and VPN (SAFI 128). 632 Though we do not explicitly discuss other SAFI values, many of the 633 comments here can be applied to the other values. 635 Consider the following table: 637 +----------------+-----------+----------------------------+ 638 | Route Family | Transport | Comments | 639 +----------------+-----------+----------------------------+ 640 | | | | 641 +----------------+-----------+----------------------------+ 642 | Unlabeled IPv4 | IPv4 | Works well | 643 +----------------+-----------+----------------------------+ 644 | Unlabeled IPv4 | IPv6 | Next-hop | 645 +----------------+-----------+----------------------------+ 646 | Unlabeled IPv6 | IPv4 | Next-hop | 647 +----------------+-----------+----------------------------+ 648 | Unlabeled IPv6 | IPv6 | Works well | 649 +----------------+-----------+----------------------------+ 650 | | | | 651 +----------------+-----------+----------------------------+ 652 | Labeled IPv4 | IPv4 | Works well | 653 +----------------+-----------+----------------------------+ 654 | Labeled IPv4 | IPv6 | Next-hop | 655 +----------------+-----------+----------------------------+ 656 | Labeled IPv6 | IPv4 | (6PE) Works well | 657 +----------------+-----------+----------------------------+ 658 | Labeled IPv6 | IPv6 | Next-hop or MPLS over IPv6 | 659 +----------------+-----------+----------------------------+ 660 | | | | 661 +----------------+-----------+----------------------------+ 662 | VPN IPv4 | IPv4 | Works well | 663 +----------------+-----------+----------------------------+ 664 | VPN IPv4 | IPv6 | Next-hop | 665 +----------------+-----------+----------------------------+ 666 | VPN IPv6 | IPv4 | (6VPE) Works well | 667 +----------------+-----------+----------------------------+ 668 | VPN IPv6 | IPv6 | Next-hop or MPLS over IPv6 | 669 +----------------+-----------+----------------------------+ 671 The first column in this table lists various route families, where 672 "unlabeled" means SAFI 1, "labeled" means the routes carry an MPLS 673 label (SAFI 4, see [RFC3107]), and "VPN" means the routes are 674 normally associated with a layer-3 VPN (SAFI 128, see [RFC4364]). 675 The second column lists the protocol used to transport the BGP 676 session, frequently specified by giving either an IPv4 or IPv6 677 address in the "neighbor" statement. 679 The third column comments on the combination in the first two 680 columns: 682 o For combinations marked "Works well", these combinations are 683 standardized, widely supported and widely deployed. 685 o For combinations marked "Next-hop", these combinations are not 686 standardized and are less-widely supported. These combinations 687 all have the "next-hop mismatch" problem: the transported route 688 needs a next-hop address from the other address family than the 689 transport address (for example, an IPv4 route needs an IPv4 next- 690 hop, even when transported over IPv6). Some vendors have 691 implemented ways to solve this problem for specific combinations, 692 but for combinations marked "next-hop", these solutions have not 693 been standardized (cf. 6PE and 6VPE, where the solution has been 694 standardized). 696 o For combinations marked as "Next-hop or MPLS over IPv6", these 697 combinations either require a non-standard solution to the next- 698 hop problem, or require MPLS over IPv6. At the time of writing, 699 MPLS over IPv6 is not widely supported or deployed. 701 Also, it is important to note that changing the set of address 702 families being carried over a BGP session requires the BGP session to 703 be reset (unless something like [I-D.ietf-idr-dynamic-cap] or 704 [I-D.ietf-idr-bgp-multisession] is in use). This is generally more 705 of an issue with eBGP sessions than iBGP sessions: for iBGP sessions 706 it is common practice for a router to have two iBGP sessions, one to 707 each member of a route reflector pair, so one can change the set of 708 address families on first one of the sessions and then the other. 710 The following subsections discuss specific combinations in more 711 detail. 713 2.5.1.1. BGP Sessions for Unlabeled Routes 715 Unlabeled routes are commonly carried on eBGP sessions, as well as on 716 iBGP sessions in networks where Internet traffic is carried unlabeled 717 across the network. 719 In these scenarios, there are three reasonable choices: 721 a. Carry unlabeled IPv4 and IPv6 routes over IPv4, OR 723 b. Carry unlabeled IPv4 and IPv6 routes over IPv6, OR 725 c. Carry unlabeled IPv4 routes over IPv4, and unlabeled IPv6 routes 726 over IPv6 728 Options (a) and (b) have the advantage that one one BGP session is 729 required between pairs of routers. However, option (c) is widely 730 considered to be the best choice. There are several reasons for this 731 : 733 o It gives a clean separation between IPv4 and IPv6. This can be 734 especially useful when first deploying IPv6 and troubleshooting 735 resulting problems. 737 o This avoids the next-hop problem described above. 739 o The status of the routes follows the status of the underlying 740 transport. If, for example, the IPv6 data path between the two 741 BGP speakers fails, then the IPv6 session between the two speakers 742 will fail and the IPv6 routes will be withdrawn, which will allow 743 the traffic to be re-routed elsewhere. By contrast, if the IPv6 744 routes were transported over IPv4, then the failure of the IPv6 745 data path might leave a working IPv4 data path, so the BGP session 746 would remain up and the IPv6 routes would not be withdrawn, and 747 thus the IPv6 traffic would be sent into a black hole. 749 o It avoids resetting the BGP session when adding IPv6 to an 750 existing session, or when removing IPv4 from an existing session. 752 Rarely, there are situations where option (c) is not practical. In 753 those cases today, most operators use option (a), carrying both route 754 types over a single BGP session. 756 2.5.1.2. BGP sessions for Labeled or VPN Routes 758 When carrying labeled or VPN routes, the only widely-supported 759 solution at time of writing is to carry both route types over IPv4. 760 This may change in as MPLS over IPv6 becomes more widely implemented. 762 There are two options when carrying both over IPv4: 764 a. Carry all routes over a single BGP session, OR 766 b. Carry the routes over multiple BGP sessions (e.g. one for VPN 767 IPv4 routes and one for VPN IPv6 routes) 769 Using a single session is usually simplest for an iBGP session going 770 to a route reflector handling both route families. Using a single 771 session here usually means that the BGP session will reset when 772 changing the set of address families, but as noted above, this is 773 usually not a problem when redundant route reflectors are involved. 775 In eBGP situations, two sessions are usually more appropriate. 776 [JUSTIFICATION?] 778 2.5.2. eBGP Endpoints: Global or Link-Local Addresses? 780 When running eBGP over IPv6, there are two options for the addresses 781 to use at each end of the eBGP session (or more properly, the 782 underlying TCP session): 784 a. Use link-local addresses for the eBGP session, OR 786 b. Use global addresses for the eBGP session. 788 Note that the choice here is the addresses to use for the eBGP 789 sessions, and not whether the link itself has global (or unique- 790 local) addresses. In particular, it is quite possible for the eBGP 791 session to use link-local addresses even when the link has global 792 addresses. 794 The big attraction for option (a) is security: an eBGP session using 795 link-local addresses is extremely difficult to attack from a device 796 that is off-link. This provides very strong protection against TCP 797 RST and similar attacks. Though there are other ways to get an 798 equivalent level of security (e.g. GTSM [RFC5082], MD5 [RFC5925], or 799 ACLs), these other ways require additional configuration which can be 800 forgotten or potentially mis-configured. 802 However, there are a number of small disadvantages to using link- 803 local addresses: 805 o Using link-local addresses only works for single-hop eBGP 806 sessions; it does not work for multi-hop sessions. 808 o One must use "next-hop self" at both endpoints, otherwise re- 809 advertising routes learned via eBGP into iBGP will not work. 810 (Some products enable "next-hop self" in this situation 811 automatically). 813 o Operators and their tools are used to referring to eBGP sessions 814 by address only, something that is not possible with link-local 815 addresses. 817 o If one is configuring parallel eBGP sessions for IPv4 and IPv6 818 routes, then using link-local addresses for the IPv6 session 819 introduces extra operational differences between the two sessions 820 which could otherwise be avoided. 822 o On some products, an eBGP session using a link-local address is 823 more complex to configure than a session that uses a global 824 address. 826 o If hardware or other issues cause one to move the cable to a 827 different local interface, then reconfiguration is required at 828 both ends: at the local end because the interface has changed (and 829 with link-local addresses, the interface must always be specified 830 along with the address), and at the remote end because the link- 831 local address has likely changed. (Contrast this with using 832 global addresses, where less re-configuration is required at the 833 local end, and no reconfiguration is required at the remote end). 835 o Finally, a strict application of [RFC2545] forbids running eBGP 836 between link-local addresses, as [RFC2545] requires the BGP next- 837 hop field to contain at least a global address. 839 For these reasons, most operators today choose to have their eBGP 840 sessions use global addresses. 842 3. General Observations 844 There are two themes that run though many of the design choices in 845 this document. This section presents some general discussion on 846 these two themes. 848 3.1. Use of Link-Local Addresses 850 The proper use of link-local addresses is a common theme in the IPv6 851 network design choices. Link-layer addresses are, of course, always 852 present in an IPv6 network, but current network design practice 853 mostly ignores them, despite efforts such as [RFC7404]. 855 There are three main reasons for this current practice: 857 o Network operators are concerned about the volatility of link-local 858 addresses based on MAC addresses, despite the fact that this 859 concern can be overcome by manually-configuring link-local 860 addresses; 862 o It is very difficult to impossible to ping a link-local address 863 from a device that is not on the same subnet. This is a 864 troubleshooting disadvantage, though it can also be viewed as a 865 security advantage. 867 o Most operators are currently running networks that carry both IPv4 868 and IPv6 traffic, and wish to harmonize their IPv4 and IPv6 design 869 and operational practices where possible. 871 3.2. Separation of IPv4 and IPv6 873 Currently, most operators are running or planning to run networks 874 that carry both IPv4 and IPv6 traffic. Hence the question: To what 875 degree should IPv4 and IPv6 be kept separate? As can be seen above, 876 this breaks into two sub-questions: To what degree should IPv4 and 877 IPv6 traffic be kept separate, and to what degree should IPv4 and 878 IPv6 routing information be kept separate? 880 The general consensus around the first question is that IPv4 and IPv6 881 traffic should generally be mixed together. This recommendation is 882 driven by the operational simplicity of mixing the traffic, plus the 883 general observation that the service being offered to the end user is 884 Internet connectivity and most users do not know or care about the 885 differences between IPv4 and IPv6. Thus it is very desirable to mix 886 IPv4 and IPv6 on the same link to the end user. On other links, 887 separation is possible but more operationally complex, though it does 888 occasionally allow the operator to work around limitations on network 889 devices. The situation here is roughly comparable to IP and MPLS 890 traffic: many networks mix the two traffic types on the same links 891 without issues. 893 By contrast, there is more of an argument for carrying IPv6 routing 894 information over IPv6 transport, while leaving IPv4 routing 895 information on IPv4 transport. By doing this, one gets fate-sharing 896 between the control and data plane for each IP protocol version: if 897 the data plane fails for some reason, then often the control plane 898 will too. 900 4. IANA Considerations 902 This document makes no requests of IANA. 904 5. Security Considerations 906 This document introduces no new security considerations that are not 907 already documented elsewhere. 909 The following is a brief list of pointers to documents related to the 910 topics covered above that the reader may wish to review for security 911 considerations. 913 For general IPv6 security, [RFC4942] provides guidance on security 914 considerations around IPv6 transition and coexistence. 916 For OSPFv3, the base protocol specification [RFC5340] has a short 917 security considerations section which notes that the fundamental 918 mechanism for protecting OSPFv3 from attacks is the mechanism 919 described in [RFC4552]. 921 For IS-IS, [RFC5308] notes that ISIS for IPv6 raises no new security 922 considerations over ISIS for IPv4 over those documented in [ISO10589] 923 and [RFC5304]. 925 For BGP, [RFC2545] notes that BGP for IPv6 raises no new security 926 considerations over those present in BGP for IPv4. However, there 927 has been much discussion of BGP security recently, and the interested 928 reader is referred to the documents of the IETF's SIDR working group. 930 6. Acknowledgements 932 Many, many people in the V6OPS working group provided comments and 933 suggestions that made their way into this document. A partial list 934 includes: Rajiv Asati, Fred Baker, Michael Behringer, Marc Blanchet, 935 Ron Bonica, Randy Bush, Cameron Byrne, Brian Carpenter, KK 936 Chittimaneni, Tim Chown, Lorenzo Colitti, Gert Doering, Francis 937 Dupont, Bill Fenner, Kedar K Gaonkar, Chris Grundemann, Steinar Haug, 938 Ray Hunter, Joel Jaeggli, Victor Kuarsingh, Jen Linkova, Ivan 939 Pepelnjak, Alexandru Petrescu, Rob Shakir, Mark Smith, Jean-Francois 940 Tremblay, Dave Thaler, Tina Tsou, Eric Vyncke, Dan York, and 941 Xuxiaohu. 943 The authors would also like to thank Pradeep Jain and Alastair 944 Johnson for helpful comments on a very preliminary version of this 945 document. 947 7. Informative References 949 [I-D.ietf-idr-bgp-multisession] 950 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 951 BGP", draft-ietf-idr-bgp-multisession-07 (work in 952 progress), September 2012. 954 [I-D.ietf-idr-dynamic-cap] 955 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 956 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 957 December 2011. 959 [I-D.ietf-v6ops-ula-usage-recommendations] 960 Liu, B. and S. Jiang, "Considerations For Using Unique 961 Local Addresses", draft-ietf-v6ops-ula-usage- 962 recommendations-05 (work in progress), May 2015. 964 [ISO10589] 965 International Standards Organization, "Intermediate system 966 to Intermediate system intra-domain routeing information 967 exchange protocol for use in conjunction with the protocol 968 for providing the connectionless-mode Network Service (ISO 969 8473)", International Standard 10589:2002, Nov 2002. 971 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 972 and E. Lear, "Address Allocation for Private Internets", 973 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 974 . 976 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 977 DOI 10.17487/RFC2080, January 1997, 978 . 980 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 981 DOI 10.17487/RFC2328, April 1998, 982 . 984 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 985 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 986 DOI 10.17487/RFC2545, March 1999, 987 . 989 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 990 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 991 . 993 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 994 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 995 . 997 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 998 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 999 2006, . 1001 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1002 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1003 2006, . 1005 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 1006 Considerations and Issues with IPv6 DNS", RFC 4472, 1007 DOI 10.17487/RFC4472, April 2006, 1008 . 1010 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1011 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1012 . 1014 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1015 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1016 Focus", RFC 4852, DOI 10.17487/RFC4852, April 2007, 1017 . 1019 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1020 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1021 DOI 10.17487/RFC4861, September 2007, 1022 . 1024 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1025 Co-existence Security Considerations", RFC 4942, 1026 DOI 10.17487/RFC4942, September 2007, 1027 . 1029 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 1030 Pignataro, "The Generalized TTL Security Mechanism 1031 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 1032 . 1034 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1035 Topology (MT) Routing in Intermediate System to 1036 Intermediate Systems (IS-ISs)", RFC 5120, 1037 DOI 10.17487/RFC5120, February 2008, 1038 . 1040 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 1041 "Problem Statement for Default Address Selection in Multi- 1042 Prefix Environments: Operational Issues of RFC 3484 1043 Default Rules", RFC 5220, DOI 10.17487/RFC5220, July 2008, 1044 . 1046 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1047 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1048 2008, . 1050 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1051 DOI 10.17487/RFC5308, October 2008, 1052 . 1054 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1055 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1056 . 1058 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1059 and C. Hahn, "IPv6 Unicast Address Assignment 1060 Considerations", RFC 5375, DOI 10.17487/RFC5375, December 1061 2008, . 1063 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1064 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1065 June 2009, . 1067 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 1068 R. Aggarwal, "Support of Address Families in OSPFv3", 1069 RFC 5838, DOI 10.17487/RFC5838, April 2010, 1070 . 1072 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1073 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1074 June 2010, . 1076 [RFC5963] Gagliano, R., "IPv6 Deployment in Internet Exchange Points 1077 (IXPs)", RFC 5963, DOI 10.17487/RFC5963, August 2010, 1078 . 1080 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1081 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1082 DOI 10.17487/RFC6180, May 2011, 1083 . 1085 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1086 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1087 . 1089 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 1090 Deployment", RFC 6342, DOI 10.17487/RFC6342, August 2011, 1091 . 1093 [RFC6752] Kirkham, A., "Issues with Private IP Addressing in the 1094 Internet", RFC 6752, DOI 10.17487/RFC6752, September 2012, 1095 . 1097 [RFC6782] Kuarsingh, V., Ed. and L. Howard, "Wireline Incremental 1098 IPv6", RFC 6782, DOI 10.17487/RFC6782, November 2012, 1099 . 1101 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 1102 Network Renumbering Scenarios, Considerations, and 1103 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 1104 . 1106 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 1107 Content Providers and Application Service Providers", 1108 RFC 6883, DOI 10.17487/RFC6883, March 2013, 1109 . 1111 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 1112 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 1113 DOI 10.17487/RFC7010, September 2013, 1114 . 1116 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1117 Interface Identifiers with IPv6 Stateless Address 1118 Autoconfiguration (SLAAC)", RFC 7217, 1119 DOI 10.17487/RFC7217, April 2014, 1120 . 1122 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 1123 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 1124 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 1125 . 1127 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1128 Addressing inside an IPv6 Network", RFC 7404, 1129 DOI 10.17487/RFC7404, November 2014, 1130 . 1132 [RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and 1133 R. White, "Cisco's Enhanced Interior Gateway Routing 1134 Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 1135 2016, . 1137 [v6-addressing-plan] 1138 SurfNet, "Preparing an IPv6 Address Plan", 2013, 1139 . 1143 Authors' Addresses 1145 Philip Matthews 1146 Nokia 1147 600 March Road 1148 Ottawa, Ontario K2K 2E6 1149 Canada 1151 Phone: +1 613-784-3139 1152 Email: philip_matthews@magma.ca 1153 Victor Kuarsingh 1154 Cisco 1155 88 Queens Quay 1156 Toronto, ON M5J0B8 1157 Canada 1159 Email: victor@jvknet.com