idnits 2.17.1 draft-ietf-v6ops-design-choices-09.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 409: '... 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 19, 2015) is 3110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5838' is defined on line 979, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-14 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-host-addr-availability-01 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 0 flaws (~~), 4 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 Alcatel-Lucent 4 Intended status: Informational V. Kuarsingh 5 Expires: April 21, 2016 Cisco 6 October 19, 2015 8 Some Design Choices for IPv6 Networks 9 draft-ietf-v6ops-design-choices-09 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 April 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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. Choice of Addresses in the Core . . . . . . . . . . . 3 58 2.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? . . 7 60 2.2.2. Interfaces with Only Link-Local Addresses? . . . . . 8 61 2.3. Static Routes . . . . . . . . . . . . . . . . . . . . . . 9 62 2.3.1. Link-Local Next-Hop in a Static Route? . . . . . . . 9 63 2.4. IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 2.4.1. IGP Choice . . . . . . . . . . . . . . . . . . . . . 10 65 2.4.2. IS-IS Topology Mode . . . . . . . . . . . . . . . . . 12 66 2.4.3. RIP . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 2.5.1. Which Transport for Which Routes? . . . . . . . . . . 13 69 2.5.1.1. BGP Sessions for Unlabeled Routes . . . . . . . . 15 70 2.5.1.2. BGP sessions for Labeled or VPN Routes . . . . . 16 71 2.5.2. eBGP Endpoints: Global or Link-Local Addresses? . . . 16 72 3. General Observations . . . . . . . . . . . . . . . . . . . . 17 73 3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 17 74 3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 18 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 78 7. Informative References . . . . . . . . . . . . . . . . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 81 1. Introduction 83 This document discusses foundational choices that arise when 84 designing a IPv6-only or dual-stack network. The focus is on routing 85 related design choices that are not normally addressed when designing 86 an IPv4-only network. The document presents each topic area along 87 with the most common design choices along with the pros and cons of 88 each choice (or alternative) in detail. Where consensus currently 89 exists around the best practice, this is documented; otherwise the 90 document simply summarizes the current state of the discussion. Thus 91 this document serves to both document the reasoning behind the best 92 current practices for IPv6, and to allow a designer to make an 93 informed choice where no such consensus exists. 95 The design choices presented apply to both Service Provider and 96 Enterprise network environments. The design areas with the relative 97 choices are not specific to Service Provider or Enterprise networks, 98 but the designer should be aware of their network requirements to 99 best utilize the guidance or choice selection which may differ in 100 each of these general network environments. Where specific choices 101 have selection criteria or analysis requirements which may differ 102 between a Service Provider or Enterprise environment, that will be 103 noted in the text. The designer is encouraged to ensure that they 104 familiarize themselves with any of the discussed technologies to 105 ensure the best selection is made for their environment. 107 This document does not present advice on strategies for adding IPv6 108 to a network, nor does it discuss transition in these areas, see 109 [RFC6180] for general advice,[RFC6782] for wireline service 110 providers, [RFC6342]for mobile network providers, [RFC5963] for 111 exchange point operators, [RFC6883] for content providers, and both 112 [RFC4852] and [RFC7381] for enterprises. Nor does this document 113 discuss the particulars of creating an IPv6 addressing plan; for 114 advice in this area, see [RFC5375] or [v6-addressing-plan]. The 115 details of ULA usage is also not discussed; for this the reader is 116 referred to [I-D.ietf-v6ops-ula-usage-recommendations]. 118 Finally, this document focuses on unicast routing design only and 119 does not cover multicast or the issues involved in running MPLS over 120 IPv6 transport. 122 2. Design Choices 124 Each subsection below presents a design choice and discusses the pros 125 and cons of the various options. If there is consensus in the 126 industry for a particular option, then the consensus position is 127 noted. 129 2.1. Addresses 131 2.1.1. Choice of Addresses in the Core 133 One of the first choices a network designer needs to make is the type 134 of IPv6 addresses to be used in the network core. IPv6, unlike IPv4, 135 introduces new addressing techniques and concepts, as introduced in 136 [RFC4291] which requires specific attention. The introduction of 137 concepts such as using multiple-addresses per interface or the 138 introduction of linked scoped address-types like Link-Local, mean the 139 designer needs to think beyond the constraints of IPv4. There are 140 also operational considerations as with the concept of a provider 141 assign PA (Provider Aggregatable assigned via upstream provider) 142 versus a Regional Internet Registry assigned PI (Provider Independent 143 assigned from Registry) address type. 145 At the time of writing, there are still some known operational issues 146 with IPv6 deployments which expose near term deployments to 147 functional or operational gaps that may one day be eliminated. Once 148 such gap is host address selection challenges as noted in [RFC5220] 149 and renumbering challenges as described in [RFC6879] and [RFC7010]. 151 Within this document, Unique Local Addresses (ULA) [RFC4193] are 152 likened to [RFC1918] addresses from an operational perspective. 153 Although ULAs are not architecturally similar to [RFC1918] private 154 addresses, the reasons for selecting them, and the challenge that may 155 arise if they are the only address type available to achieve external 156 network connectivity are similar. "Private" in this document refers 157 to the nature that ULAs would be typically used for internal 158 communications only, or externally with assistance from technologies 159 like NAT, given the addresses are not routed directly with external 160 networks. 162 A related choice is whether to use only link-local addresses on 163 certain links. That choice is discussed later in the document; this 164 section is about those addresses that must be visible throughout the 165 network. 167 The following table lists the main options available. 169 +---------+------------+---------------------+----------------------+ 170 | GRT | End-User | ISP | Enterprise | 171 | Address | Traffic | | | 172 | Type | | | | 173 +---------+------------+---------------------+----------------------+ 174 | | | | | 175 +---------+------------+---------------------+----------------------+ 176 | PI | Hop-by-hop | Works | Works | 177 +---------+------------+---------------------+----------------------+ 178 | PI | Tunneled | Works. Using | Works. Using private | 179 | | | private space | space likely a | 180 | | | likely a better | better option. | 181 | | | option. | | 182 +---------+------------+---------------------+----------------------+ 183 | PA | Hop-by-hop | Works | Works | 184 +---------+------------+---------------------+----------------------+ 185 | PA | Tunneled | Works. Using | Works. Using private | 186 | | | private addresses | addresses likely | 187 | | | likely better | better option. | 188 | | | option. | | 189 +---------+------------+---------------------+----------------------+ 190 | Private | Hop-by-hop | Will likely cause | Works. Careful | 191 | | | problems. See | consideration due to | 192 | | | discussion below. | NAT implications. | 193 +---------+------------+---------------------+----------------------+ 194 | Private | Tunneled | Works | Works | 195 +---------+------------+---------------------+----------------------+ 197 As the table indicates, there are three options for the type of 198 addresses a network designer can use in the network core: 200 o PI - Globally-unique IPv4 or IPv6 addresses obtained directly from 201 an address registry. An organization which has such addresses is 202 considered to have "its own" address space. 204 o PA - Globally-unique IPv4 or IPv6 addresses obtained from an 205 upstream provider. Such addresses must be returned if the 206 relationship with the upstream provider ceases. 208 o Private - Either IPv4 addresses as per [RFC1918] or unique-local 209 IPv6 addresses [RFC4193]. 211 In all cases, we are talking about the type of addresses used in the 212 GRT context (Global Routing Table aka base router). If end-user 213 traffic is routed hop-by-hop through the network based on the 214 destination address in the IP header, then this context is visible to 215 the end-user. However, if all end-user traffic is tunneled through 216 the core (for example, using MPLS) then this context is not visible 217 to the end-user. 219 First, consider the case where at least some end-user traffic is 220 routed hop-by-hop. In this case, the use of PI space is the best 221 option, as it gives the most flexibility in the future. However, 222 some organizations may be unable or unwilling to obtain PI space - in 223 this case PA space is the next-best choice. For an ISP, the use of 224 private address space is problematic - see [RFC6752] for a 225 discussion. For an enterprise, the use of private address space is 226 an option and may be seen as favourable operationally, but should 227 only be used after careful consideration of the technological 228 drawbacks. If ULAs are the only non-Link-Local address available the 229 hosts, the enterprise will need to use translation technologies such 230 as NPT[RFC6296] or NAT66 to reach the Internet. If the network has 231 no connection to the Internet, or the hosts only assigned a ULA do 232 not need external connectivity, then this limitation is not a 233 problem. 235 Now consider the case where all end-user traffic is tunneled through 236 the core and thus the core is not visible to other networks. In this 237 case, the use of private addresses in the core is the most reasonable 238 and re-enforces the desire that these addresses have limited 239 visibility. The use of PI space is the next-best option - two 240 reasons for selecting this option is to provide flexibility in case 241 some traffic needs to be carried hop-by-hop in the future and to be 242 absolutely sure that there are no address conflicts. Getting IPv4 PI 243 space at this time will be difficult, but IPv6 PI space is fairly 244 easy. 246 The use of PA space is likely a poor option for many organizations 247 since these networks are connected to more then one upstream provider 248 and/or may need flexibility on how Internet reachability needs to be 249 managed. Using PA space subjects the end network to possible 250 reclamation of address space in the future, which requires a 251 renumbering activity. 253 Not shown in the table above are combinations of the basic options. 254 An example of a combination is using both PA and ULA address space in 255 the hop-by-hop enterprise case or multiple PA and/or PI addresses. 256 Combinations can reduce the magnitude of the deficiency with a basic 257 option, but does not eliminate it completely. For example, using PA 258 + ULA for the hop-by-hop enterprise case reduces the amount of 259 renumbering required when changing providers compared with the pure 260 PA case, but does not eliminate it completely. Additional work 261 analyzing the opportunities for using multiple addresses and 262 overcoming limitations can be found in 263 [I-D.ietf-v6ops-host-addr-availability]. 265 2.2. Interfaces 267 2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? 269 If a network is going to carry both IPv4 and IPv6 traffic, as many 270 networks do today, then a fundamental question arises: Should an 271 operator mix IPv4 and IPv6 traffic or keep them separated? More 272 specifically, should the design: 274 a. Mix IPv4 and IPv6 traffic on the same layer-3 interface, OR 276 b. Separate IPv4 and IPv6 by using separate interfaces (e.g., two 277 physical links or two VLANs on the same link)? 279 Option (a) implies a single layer-3 interface at each end of the 280 connection with both IPv4 and IPv6 addresses; while option (b) 281 implies two layer-3 interfaces at each end, one for IPv4 addresses 282 and one with IPv6 addresses. 284 The advantages of option (a) include: 286 o Requires only half as many layer 3 interfaces as option (b), thus 287 providing better scaling; 289 o May require fewer physical ports, thus saving money; 291 o Can make the QoS implementation much easier (for example, rate- 292 limiting the combined IPv4 and IPv6 traffic to or from a 293 customer); 295 o Works well in practice, as any increase in IPv6 traffic is usually 296 counter-balanced by a corresponding decrease in IPv4 traffic to or 297 from the same host (ignoring the common pattern of an overall 298 increase in Internet usage); 300 o And is generally conceptually simpler. 302 For these reasons, there is a relatively strong consensus in the 303 operator community that option (a) is the preferred way to go. Most 304 networks today use option (a) wherever possible. 306 However, there can be times when option (b) is the pragmatic choice. 307 Most commonly, option (b) is used to work around limitations in 308 network equipment. One big example is the generally poor level of 309 support today for individual statistics on IPv4 traffic vs IPv6 310 traffic when option (a) is used. Other, device-specific, limitations 311 exist as well. It is expected that these limitations will go away as 312 support for IPv6 matures, making option (b) less and less attractive 313 until the day that IPv4 is finally turned off. 315 2.2.2. Interfaces with Only Link-Local Addresses? 317 As noted in the introduction, this document does not cover the ins 318 and outs around creating an IPv6 addressing plan. However, there is 319 one fundamental question in this area that often arises: Should an 320 interface: 322 a. Use only a link-local address ("link-local-only"), OR 324 b. Have global and/or unique-local addresses assigned in addition to 325 the link-local? 327 There are two advantages in interfaces with only link-local addresses 328 ("link-local-only interfaces"). The first advantage is ease of 329 configuration. In a network with a large number of link-local-only 330 interfaces, the operator can just enable an IGP on each router, 331 without going through the tedious process of assigning and tracking 332 the addresses for each interface. The second advantage is security. 333 Since packets with Link-Local destination addresses should not be 334 routed, it is very difficult to attack the associated nodes from an 335 off-link device. This implies less effort around maintaining 336 security ACLs. 338 Countering this advantage are various disadvantages to link-local- 339 only interfaces: 341 o It is not possible to ping a link-local-only interface from a 342 device that is not directly attached to the link. Thus, to 343 troubleshoot, one must typically log into a device that is 344 directly attached to the device in question, and execute the ping 345 from there. 347 o A traceroute passing over the link-local-only interface will 348 return the loopback or system address of the router, rather than 349 the address of the interface itself. 351 o In cases of parallel point to point links it is difficult to 352 determine which of the parallel links was taken when attempting to 353 troubleshoot unless one sends packets directly between the two 354 attached link-locals on the specific interfaces. Since many 355 network problems behave differently for traffic to/from a router 356 than for traffic through the router(s) in question, this can pose 357 a significant hurdle to some troubleshooting scenarios. 359 o On some routers, by default the link-layer address of the 360 interface is derived from the MAC address assigned to interface. 361 When this is done, swapping out the interface hardware (e.g. 362 interface card) will cause the link-layer address to change. In 363 some cases (peering config, ACLs, etc) this may require additional 364 changes. However, many devices allow the link-layer address of an 365 interface to be explicitly configured, which avoids this issue. 366 This problem should fade away over time as more and more routers 367 select interface identifiers according to the rules in [RFC7217]. 369 o The practice of naming router interfaces using DNS names is 370 difficult and not recommended when using link-locals only. More 371 generally, it is not recommended to put link-local addresses into 372 DNS; see [RFC4472]. 374 o It is often not possible to identify the interface or link (in a 375 database, email, etc) by giving just its address without also 376 specifying the link in some manner. 378 It should be noted that it is quite possible for the same link-local 379 address to be assigned to multiple interfaces. This can happen 380 because the MAC address is duplicated (due to manufacturing process 381 defaults or the use of virtualization), because a device deliberately 382 re-uses automatically-assigned link-local addresses on different 383 links, or because an operator manually assigns the same easy-to-type 384 link-local address to multiple interfaces. All these are allowed in 385 IPv6 as long as the addresses are used on different links. 387 For more discussion on the pros and cons, see [RFC7404]. See also 388 [RFC5375] for IPv6 unicast address assignment considerations. 390 Today, most operators use interfaces with global or unique-local 391 addresses (option b). 393 2.3. Static Routes 395 2.3.1. Link-Local Next-Hop in a Static Route? 397 For the most part, the use of static routes in IPv6 parallels their 398 use in IPv4. There is, however, one exception, which revolves around 399 the choice of next-hop address in the static route. Specifically, 400 should an operator: 402 a. Use the far-end's link-local address as the next-hop address, OR 404 b. Use the far-end's GUA/ULA address as the next-hop address? 405 Recall that the IPv6 specs for OSPF [RFC5340] and ISIS [RFC5308] 406 dictate that they always use link-locals for next-hop addresses. For 407 static routes, [RFC4861] section 8 says: 409 A router MUST be able to determine the link-local address for each 410 of its neighboring routers in order to ensure that the target 411 address in a Redirect message identifies the neighbor router by 412 its link-local address. For static routing, this requirement 413 implies that the next-hop router's address should be specified 414 using the link-local address of the router. 416 This implies that using a GUA or ULA as the next hop will prevent a 417 router from sending Redirect messages for packets that "hit" this 418 static route. All this argues for using a link-local as the next-hop 419 address in a static route. 421 However, there are two cases where using a link-local address as the 422 next-hop clearly does not work. One is when the static route is an 423 indirect (or multi-hop) static route. The second is when the static 424 route is redistributed into another routing protocol. In these 425 cases, the above text from RFC 4861 notwithstanding, either a GUA or 426 ULA must be used. 428 Furthermore, many network operators are concerned about the 429 dependency of the default link-local address on an underlying MAC 430 address, as described in the previous section. 432 Today most operators use GUAs as next-hop addresses. 434 2.4. IGPs 436 2.4.1. IGP Choice 438 One of the main decisions for a network operator looking to deploy 439 IPv6 is the choice of IGP (Interior Gateway Protocol) within the 440 network. The main options are OSPF, IS-IS and EIGRP. RIPng is 441 another option, but very few networks run RIP in the core these days, 442 so it is covered in a separate section below. 444 OSPF [RFC2328] [RFC5340] and IS-IS [RFC5120][RFC5120] are both 445 standardized and link-state protocols. Standardized means they are 446 widely supported by vendors, while link-state means amongst other 447 things that they can support RSVP-TE, which is widely used for MPLS 448 signaling. Both of these protocols are widely deployed. By 449 contrast, EIGRP [ref] is a proprietary distance-vector protocol. 450 EIGRP is rarely deployed in service-provider networks, but is quite 451 common in enterprise networks. 453 The table below sets out possible combinations of protocols to route 454 both IPv4 and IPv6, and makes some observations on each combination. 456 +---------+---------+---------------+-------------+-----------------+ 457 | IGP for | IGP for | Multiple | Protocol | Similar | 458 | IPv4 | IPv6 | Known | separation | configuration | 459 | | | Deployments | | possible | 460 +---------+---------+---------------+-------------+-----------------+ 461 | | | | | | 462 +---------+---------+---------------+-------------+-----------------+ 463 | OSPFv2 | OSPFv3 | YES (8) | YES | YES | 464 +---------+---------+---------------+-------------+-----------------+ 465 | OSPFv2 | IS-IS | YES (3) | YES | - | 466 +---------+---------+---------------+-------------+-----------------+ 467 | OSPFv2 | EIGRP | - | YES | - | 468 +---------+---------+---------------+-------------+-----------------+ 469 | OSPFv3 | IS-IS | - | YES | - | 470 +---------+---------+---------------+-------------+-----------------+ 471 | OSPFv3 | EIGRP | - | YES | - | 472 +---------+---------+---------------+-------------+-----------------+ 473 | IS-IS | OSPFv3 | YES (2) | YES | - | 474 +---------+---------+---------------+-------------+-----------------+ 475 | IS-IS | IS-IS | YES (12) | - | YES | 476 +---------+---------+---------------+-------------+-----------------+ 477 | IS-IS | EIGRP | - | YES | - | 478 +---------+---------+---------------+-------------+-----------------+ 479 | EIGRP | OSPFv3 | ? (1) | YES | - | 480 +---------+---------+---------------+-------------+-----------------+ 481 | EIGRP | IS-IS | - | YES | - | 482 +---------+---------+---------------+-------------+-----------------+ 483 | EIGRP | EIGRP | ? (2) | - | YES | 484 +---------+---------+---------------+-------------+-----------------+ 486 In the column "Multiple Known Deployments", a YES indicates that a 487 significant number of production networks run this combination, with 488 the number of such networks indicated in parentheses following, while 489 a "?" indicates that the authors are only aware of one or two small 490 networks that run this combination. Data for this column was 491 gathered from an informal poll of operators on a number of mailing 492 lists. This poll was not intended to be a thorough scientific study 493 of IGP choices, but to provide a snapshot of known operator choices 494 at the time of writing (Mid-2015) for successful production dual 495 stack network deployments. There were twenty six (26) network 496 implementations represented by 17 respondents. Some respondents 497 provided information on more then one network or network deployment. 498 Due to privacy considerations, the networks' represented and 499 respondents are not listed in this document. 501 A number of combinations are marked as offering "Protocol 502 separation". These options use a different IGP protocol for IPv4 vs 503 IPv6. With these options, a problem with routing IPv6 is unlikely to 504 affect IPv4 or visa-versa. Some operator may consider this as a 505 benefit when first introducing dual stack capabilities or for ongoing 506 technical reasons. 508 Three combinations are marked "Similar configuration possible". This 509 means it is possible (but not required) to use very similar IGP 510 configuration for IPv4 and IPv6: for example, the same area 511 boundaries, area numbering, link costing, etc. If you are happy with 512 your IPv4 IGP design, then this will likely be a consideration. By 513 contrast, the options that use, for example, IS-IS for one IP version 514 and OSPF for the other version will require considerably different 515 configuration, and will also require the operations staff to become 516 familiar with the difference between the two protocols. 518 It should be noted that a number of ISPs have run OSPF as their IPv4 519 IGP for quite a few years, but have selected IS-IS as their IPv6 IGP. 520 However, there are very few (none?) that have made the reverse 521 choice. This is, in part, because routers generally support more 522 nodes in an IS-IS area than in the corresponding OSPF area, and 523 because IS-IS is seen as more secure because it runs at layer 2. 525 2.4.2. IS-IS Topology Mode 527 When IS-IS is used to route both IPv4 and IPv6, then there is an 528 additional choice of whether to run IS-IS in single-topology or 529 multi-topology mode. Single-topology mode allows IPv4 and IPv6 to 530 share a single topology and a single set of link costs[RFC5308]. 531 Multi-topology mode allows separate IPv4 and IPv6 topologies with 532 potentially different link costs. 534 In the informal poll of operators, out of 12 production networks that 535 ran IS-IS for both IPv4 and IPv6, 6 used Single Topology mode, 4 used 536 Multi-Topology mode, and 2 did not specify. One motivation often 537 cited by then operators for using Single Topology mode was because 538 some device did not support multi-topology mode. 540 Traditional thinking has been that multi-topology mode offers the 541 most flexibility. Never-the-less, as shown by the poll results, a 542 number of operators have used single-topology mode successfully. 544 2.4.3. RIP 546 A protocol option not described in the table above is RIPng 547 [RFC2080]. RIPng is a distance vector protocol with limitations in 548 larger networks. However there is prevalent use case in large 549 operator networks where RIP is used for edge facing core interfaces 550 to manage high count aggregation of dynamic routing endpoints. 551 Although not a mainline option for the network core as a whole, it is 552 commonly used in IPv4, and potentially in IPv6 for a common set of 553 links/functions. 555 2.5. BGP 557 2.5.1. Which Transport for Which Routes? 559 BGP these days is multi-protocol. It can carry routes from many 560 different families, and it can do this when the BGP session, or more 561 accurately the underlying TCP connection, runs over either IPv4 or 562 IPv6 (here referred to as either "IPv4 transport" or "IPv6 563 transport"). Given this flexibility, one of the biggest questions 564 when deploying BGP in a dual-stack network is the question of which 565 routes should be carried over sessions using IPv4 transport and which 566 should be carried over sessions using IPv6 transport. 568 To answer this question, consider the following table: 570 +----------------+-----------+----------------------+ 571 | Route Family | Transport | Comments | 572 +----------------+-----------+----------------------+ 573 | | | | 574 +----------------+-----------+----------------------+ 575 | Unlabeled IPv4 | IPv4 | Works well | 576 +----------------+-----------+----------------------+ 577 | Unlabeled IPv4 | IPv6 | Next-hop issues | 578 +----------------+-----------+----------------------+ 579 | Unlabeled IPv6 | IPv4 | Next-hop issues | 580 +----------------+-----------+----------------------+ 581 | Unlabeled IPv6 | IPv6 | Works well | 582 +----------------+-----------+----------------------+ 583 | | | | 584 +----------------+-----------+----------------------+ 585 | Labeled IPv4 | IPv4 | Works well | 586 +----------------+-----------+----------------------+ 587 | Labeled IPv4 | IPv6 | Next-hop issues | 588 +----------------+-----------+----------------------+ 589 | Labeled IPv6 | IPv4 | (6PE) Works well | 590 +----------------+-----------+----------------------+ 591 | Labeled IPv6 | IPv6 | Needs MPLS over IPv6 | 592 +----------------+-----------+----------------------+ 593 | | | | 594 +----------------+-----------+----------------------+ 595 | VPN IPv4 | IPv4 | Works well | 596 +----------------+-----------+----------------------+ 597 | VPN IPv4 | IPv6 | Next-hop issues | 598 +----------------+-----------+----------------------+ 599 | VPN IPv6 | IPv4 | (6VPE) Works well | 600 +----------------+-----------+----------------------+ 601 | VPN IPv6 | IPv6 | Needs MPLS over IPv6 | 602 +----------------+-----------+----------------------+ 604 The first column in this table lists various route families, where 605 "unlabeled" means SAFI 1, "labeled" means the routes carry an MPLS 606 label (SAFI 4, see [RFC3107]), and "VPN" means the routes are 607 normally associated with a layer-3 VPN (SAFI 128, see [RFC4364] ). 608 The second column lists the protocol used to transport the BGP 609 session, frequently specified by giving either an IPv4 or IPv6 610 address in the "neighbor" statement. 612 The third column comments on the combination in the first two 613 columns: 615 o For combinations marked "Works well", these combinations are 616 widely supported and are generally recommended. 618 o For combinations marked "Next-hop issues", these combinations are 619 less-widely supported and when supported, often have next-hop 620 issues. That is, the next-hop address is typically a v4-mapped 621 IPv6 address, which is based on some IPv4 address on the sending 622 router. This v4-mapped IPv6 address is often not reachable by 623 default using IPv6 routing. One common solution to this problem 624 is to use routing policy to change the next-hop to a different 625 IPv6 address. 627 o For combinations marked as "Needs MPLS over IPv6", these require 628 MPLS over IPv6 for full support, though special policy 629 configuration may allow them to be used with MPLS over IPv4. 631 Also, it is important to note that changing the set of address 632 families being carried over a BGP session requires the BGP session to 633 be reset (unless something like [I-D.ietf-idr-dynamic-cap] or 634 [I-D.ietf-idr-bgp-multisession] is in use). This is generally more 635 of an issue with eBGP sessions than iBGP sessions: for iBGP sessions 636 it is common practice for a router to have two iBGP sessions, one to 637 each member of a route reflector pair, so one can change the set of 638 address families on first one of the sessions and then the other. 640 The following subsections discuss specific scenarios in more detail. 642 2.5.1.1. BGP Sessions for Unlabeled Routes 644 Unlabeled routes are commonly carried on eBGP sessions, as well as on 645 iBGP sessions in networks where Internet traffic is carried unlabeled 646 across the network. In these scenarios, operators today most 647 commonly use two BGP sessions: one session is transported over IPv4 648 and carries the unlabeled IPv4 routes, while the second session is 649 transported over IPv6 and carries the unlabeled IPv6 routes. 651 There are several reasons for this choice: 653 o It gives a clean separation between IPv4 and IPv6. This can be 654 especially useful when first deploying IPv6 and troubleshooting 655 resulting problems. 657 o This avoids the next-hop problem described in note 1 above. 659 o The status of the routes follows the status of the underlying 660 transport. If, for example, the IPv6 data path between the two 661 BGP speakers fails, then the IPv6 session between the two speakers 662 will fail and the IPv6 routes will be withdrawn, which will allow 663 the traffic to be re-routed elsewhere. By contrast, if the IPv6 664 routes were transported over IPv4, then the failure of the IPv6 665 data path might leave a working IPv4 data path, so the BGP session 666 would remain up and the IPv6 routes would not be withdrawn, and 667 thus the IPv6 traffic would be sent into a black hole. 669 o It avoids resetting the BGP session when adding IPv6 to an 670 existing session, or when removing IPv4 from an existing session. 672 2.5.1.2. BGP sessions for Labeled or VPN Routes 674 In these scenarios, it is most common today to carry both the IPv4 675 and IPv6 routes over sessions transported over IPv4. This can be 676 done with either: (a) one session carrying both route families, or 677 (b) two sessions, one for each family. 679 Using a single session is usually appropriate for an iBGP session 680 going to a route reflector handling both route families. Using a 681 single session here usually means that the BGP session will reset 682 when changing the set of address families, but as noted above, this 683 is usually not a problem when redundant route reflectors are 684 involved. 686 In eBGP situations, two sessions are usually more appropriate. 688 2.5.2. eBGP Endpoints: Global or Link-Local Addresses? 690 When running eBGP over IPv6, there are two options for the addresses 691 to use at each end of the eBGP session (or more properly, the 692 underlying TCP session): 694 a. Use link-local addresses for the eBGP session, OR 696 b. Use global addresses for the eBGP session. 698 Note that the choice here is the addresses to use for the eBGP 699 sessions, and not whether the link itself has global (or unique- 700 local) addresses. In particular, it is quite possible for the eBGP 701 session to use link-local addresses even when the link has global 702 addresses. 704 The big attraction for option (a) is security: an eBGP session using 705 link-local addresses is extremely difficult to attack from a device 706 that is off-link. This provides very strong protection against TCP 707 RST and similar attacks. Though there are other ways to get an 708 equivalent level of security (e.g. GTSM [RFC5082], MD5 [RFC5925], or 709 ACLs), these other ways require additional configuration which can be 710 forgotten or potentially mis-configured. 712 However, there are a number of small disadvantages to using link- 713 local addresses: 715 o Using link-local addresses only works for single-hop eBGP 716 sessions; it does not work for multi-hop sessions. 718 o One must use "next-hop self" at both endpoints, otherwise re- 719 advertising routes learned via eBGP into iBGP will not work. 720 (Some products enable "next-hop self" in this situation 721 automatically). 723 o Operators and their tools are used to referring to eBGP sessions 724 by address only, something that is not possible with link-local 725 addresses. 727 o If one is configuring parallel eBGP sessions for IPv4 and IPv6 728 routes, then using link-local addresses for the IPv6 session 729 introduces extra operational differences between the two sessions 730 which could otherwise be avoided. 732 o On some products, an eBGP session using a link-local address is 733 more complex to configure than a session that uses a global 734 address. 736 o If hardware or other issues cause one to move the cable to a 737 different local interface, then reconfiguration is required at 738 both ends: at the local end because the interface has changed (and 739 with link-local addresses, the interface must always be specified 740 along with the address), and at the remote end because the link- 741 local address has likely changed. (Contrast this with using 742 global addresses, where less re-configuration is required at the 743 local end, and no reconfiguration is required at the remote end). 745 o Finally, a strict application of [RFC2545] forbids running eBGP 746 between link-local addresses, as [RFC2545] requires the BGP next- 747 hop field to contain at least a global address. 749 For these reasons, most operators today choose to have their eBGP 750 sessions use global addresses. 752 3. General Observations 754 There are two themes that run though many of the design choices in 755 this document. This section presents some general discussion on 756 these two themes. 758 3.1. Use of Link-Local Addresses 760 The proper use of link-local addresses is a common theme in the IPv6 761 network design choices. Link-layer addresses are, of course, always 762 present in an IPv6 network, but current network design practice 763 mostly ignores them, despite efforts such as [RFC7404]. 765 There are three main reasons for this current practice: 767 o Network operators are concerned about the volatility of link-local 768 addresses based on MAC addresses, despite the fact that this 769 concern can be overcome by manually-configuring link-local 770 addresses; 772 o It is very difficult to impossible to ping a link-local address 773 from a device that is not on the same subnet. This is a 774 troubleshooting disadvantage, though it can also be viewed as a 775 security advantage. 777 o Most operators are currently running networks that carry both IPv4 778 and IPv6 traffic, and wish to harmonize their IPv4 and IPv6 design 779 and operational practices where possible. 781 3.2. Separation of IPv4 and IPv6 783 Currently, most operators are running or planning to run networks 784 that carry both IPv4 and IPv6 traffic. Hence the question: To what 785 degree should IPv4 and IPv6 be kept separate? As can be seen above, 786 this breaks into two sub-questions: To what degree should IPv4 and 787 IPv6 traffic be kept separate, and to what degree should IPv4 and 788 IPv6 routing information be kept separate? 790 The general consensus around the first question is that IPv4 and IPv6 791 traffic should generally be mixed together. This recommendation is 792 driven by the operational simplicity of mixing the traffic, plus the 793 general observation that the service being offered to the end user is 794 Internet connectivity and most users do not know or care about the 795 differences between IPv4 and IPv6. Thus it is very desirable to mix 796 IPv4 and IPv6 on the same link to the end user. On other links, 797 separation is possible but more operationally complex, though it does 798 occasionally allow the operator to work around limitations on network 799 devices. The situation here is roughly comparable to IP and MPLS 800 traffic: many networks mix the two traffic types on the same links 801 without issues. 803 By contrast, there is more of an argument for carrying IPv6 routing 804 information over IPv6 transport, while leaving IPv4 routing 805 information on IPv4 transport. By doing this, one gets fate-sharing 806 between the control and data plane for each IP protocol version: if 807 the data plane fails for some reason, then often the control plane 808 will too. 810 4. IANA Considerations 812 This document makes no requests of IANA. 814 5. Security Considerations 816 This document introduces no new security considerations that are not 817 already documented elsewhere. 819 The following is a brief list of pointers to documents related to the 820 topics covered above that the reader may wish to review for security 821 considerations. 823 For general IPv6 security, [RFC4942] provides guidance on security 824 considerations around IPv6 transition and coexistence. 826 For OSPFv3, the base protocol specification [RFC5340] has a short 827 security considerations section which notes that the fundamental 828 mechanism for protecting OSPFv3 from attacks is the mechanism 829 described in [RFC4552]. 831 For IS-IS, [RFC5308] notes that ISIS for IPv6 raises no new security 832 considerations over ISIS for IPv4 over those documented in [ISO10589] 833 and [RFC5304]. 835 For BGP, [RFC2545] notes that BGP for IPv6 raises no new security 836 considerations over those present in BGP for IPv4. However, there 837 has been much discussion of BGP security recently, and the interested 838 reader is referred to the documents of the IETF's SIDR working group. 840 6. Acknowledgements 842 Many, many people in the V6OPS working group provided comments and 843 suggestions that made their way into this document. A partial list 844 includes: Rajiv Asati, Fred Baker, Michael Behringer, Marc Blanchet, 845 Ron Bonica, Randy Bush, Cameron Byrne, Brian Carpenter, KK 846 Chittimaneni, Tim Chown, Lorenzo Colitti, Gert Doering, Francis 847 Dupont, Bill Fenner, Kedar K Gaonkar, Chris Grundemann, Steinar Haug, 848 Ray Hunter, Joel Jaeggli, Victor Kuarsingh, Jen Linkova, Ivan 849 Pepelnjak, Alexandru Petrescu, Rob Shakir, Mark Smith, Jean-Francois 850 Tremblay, Dave Thaler, Tina Tsou, Eric Vyncke, Dan York, and 851 Xuxiaohu. 853 The authors would also like to thank Pradeep Jain and Alastair 854 Johnson for helpful comments on a very preliminary version of this 855 document. 857 7. Informative References 859 [I-D.ietf-idr-bgp-multisession] 860 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 861 BGP", draft-ietf-idr-bgp-multisession-07 (work in 862 progress), September 2012. 864 [I-D.ietf-idr-dynamic-cap] 865 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 866 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 867 December 2011. 869 [I-D.ietf-v6ops-host-addr-availability] 870 Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 871 "Host address availability recommendations", draft-ietf- 872 v6ops-host-addr-availability-01 (work in progress), 873 September 2015. 875 [I-D.ietf-v6ops-ula-usage-recommendations] 876 Liu, B. and S. Jiang, "Considerations For Using Unique 877 Local Addresses", draft-ietf-v6ops-ula-usage- 878 recommendations-05 (work in progress), May 2015. 880 [ISO10589] 881 International Standards Organization, "Intermediate system 882 to Intermediate system intra-domain routeing information 883 exchange protocol for use in conjunction with the protocol 884 for providing the connectionless-mode Network Service (ISO 885 8473)", International Standard 10589:2002, Nov 2002. 887 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 888 and E. Lear, "Address Allocation for Private Internets", 889 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 890 . 892 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 893 DOI 10.17487/RFC2080, January 1997, 894 . 896 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 897 DOI 10.17487/RFC2328, April 1998, 898 . 900 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 901 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 902 DOI 10.17487/RFC2545, March 1999, 903 . 905 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 906 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 907 . 909 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 910 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 911 . 913 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 914 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 915 2006, . 917 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 918 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 919 2006, . 921 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 922 Considerations and Issues with IPv6 DNS", RFC 4472, 923 DOI 10.17487/RFC4472, April 2006, 924 . 926 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 927 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 928 . 930 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 931 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 932 Focus", RFC 4852, DOI 10.17487/RFC4852, April 2007, 933 . 935 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 936 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 937 DOI 10.17487/RFC4861, September 2007, 938 . 940 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 941 Co-existence Security Considerations", RFC 4942, 942 DOI 10.17487/RFC4942, September 2007, 943 . 945 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 946 Pignataro, "The Generalized TTL Security Mechanism 947 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 948 . 950 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 951 Topology (MT) Routing in Intermediate System to 952 Intermediate Systems (IS-ISs)", RFC 5120, 953 DOI 10.17487/RFC5120, February 2008, 954 . 956 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 957 "Problem Statement for Default Address Selection in Multi- 958 Prefix Environments: Operational Issues of RFC 3484 959 Default Rules", RFC 5220, DOI 10.17487/RFC5220, July 2008, 960 . 962 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 963 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 964 2008, . 966 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 967 DOI 10.17487/RFC5308, October 2008, 968 . 970 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 971 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 972 . 974 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 975 and C. Hahn, "IPv6 Unicast Address Assignment 976 Considerations", RFC 5375, DOI 10.17487/RFC5375, December 977 2008, . 979 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 980 R. Aggarwal, "Support of Address Families in OSPFv3", 981 RFC 5838, DOI 10.17487/RFC5838, April 2010, 982 . 984 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 985 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 986 June 2010, . 988 [RFC5963] Gagliano, R., "IPv6 Deployment in Internet Exchange Points 989 (IXPs)", RFC 5963, DOI 10.17487/RFC5963, August 2010, 990 . 992 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 993 Transition Mechanisms during IPv6 Deployment", RFC 6180, 994 DOI 10.17487/RFC6180, May 2011, 995 . 997 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 998 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 999 . 1001 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 1002 Deployment", RFC 6342, DOI 10.17487/RFC6342, August 2011, 1003 . 1005 [RFC6752] Kirkham, A., "Issues with Private IP Addressing in the 1006 Internet", RFC 6752, DOI 10.17487/RFC6752, September 2012, 1007 . 1009 [RFC6782] Kuarsingh, V., Ed. and L. Howard, "Wireline Incremental 1010 IPv6", RFC 6782, DOI 10.17487/RFC6782, November 2012, 1011 . 1013 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 1014 Network Renumbering Scenarios, Considerations, and 1015 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 1016 . 1018 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 1019 Content Providers and Application Service Providers", 1020 RFC 6883, DOI 10.17487/RFC6883, March 2013, 1021 . 1023 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 1024 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 1025 DOI 10.17487/RFC7010, September 2013, 1026 . 1028 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1029 Interface Identifiers with IPv6 Stateless Address 1030 Autoconfiguration (SLAAC)", RFC 7217, 1031 DOI 10.17487/RFC7217, April 2014, 1032 . 1034 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 1035 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 1036 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 1037 . 1039 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1040 Addressing inside an IPv6 Network", RFC 7404, 1041 DOI 10.17487/RFC7404, November 2014, 1042 . 1044 [v6-addressing-plan] 1045 SurfNet, "Preparing an IPv6 Address Plan", 2013, 1046 . 1050 Authors' Addresses 1052 Philip Matthews 1053 Alcatel-Lucent 1054 600 March Road 1055 Ottawa, Ontario K2K 2E6 1056 Canada 1058 Phone: +1 613-784-3139 1059 Email: philip_matthews@magma.ca 1061 Victor Kuarsingh 1062 Cisco 1063 88 Queens Quay 1064 Toronto, ON M5J0B8 1065 Canada 1067 Email: victor@jvknet.com