idnits 2.17.1 draft-ietf-v6ops-design-choices-03.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 249: '... 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 (September 18, 2014) is 3509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-14 == Outdated reference: A later version (-11) exists of draft-ietf-opsec-lla-only-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: March 22, 2015 Dyn 6 September 18, 2014 8 Design Choices for IPv6 Networks 9 draft-ietf-v6ops-design-choices-03 11 Abstract 13 This document presents advice on the design choices that arise when 14 designing IPv6 networks (both dual-stack and IPv6-only). The 15 intended audience is someone designing an IPv6 network who is 16 knowledgeable about best current practices around IPv4 network 17 design, and wishes to learn the corresponding practices for IPv6. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 22, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1.1. Mix IPv4 and IPv6 on the Same Link? . . . . . . . . . 3 57 2.1.2. Links with Only Link-Local Addresses? . . . . . . . . 4 58 2.2. Static Routes . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2.1. Link-Local Next-Hop in a Static Route? . . . . . . . 6 60 2.3. IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3.1. IGP Choice . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.4.1. BGP Sessions for Unlabeled Routes . . . . . . . . . . 10 64 2.4.2. BGP sessions for Labeled or VPN Routes . . . . . . . 11 65 2.4.3. eBGP Endpoints: Global or Link-Local Addresses? . . . 11 66 3. General Observations . . . . . . . . . . . . . . . . . . . . 12 67 3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 12 68 3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 13 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 7. Informative References . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 This document presents advice on the design choices that arise when 78 designing IPv6 networks (both dual-stack and IPv6-only). The 79 intended audience is someone designing an IPv6 network who is 80 knowledgeable about best current practices around IPv4 network 81 design, and wishes to learn the corresponding practices for IPv6. 83 The focus of the document is on design choices where there are 84 differences between IPv4 and IPv6, either in the range of possible 85 alternatives (e.g. the extra possibilities introduced by link-local 86 addresses in IPv6) or the recommended alternative. The document 87 presents the alternatives and discusses the pros and cons in detail. 88 Where 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 to 91 document the reasoning behind best current practices for IPv6, and to 92 allow a designer to make an intelligent choice where no such 93 consensus exists. 95 This document does not present advice on strategies for adding IPv6 96 to a network, nor does it discuss transition mechanisms. For advice 97 in these areas, see [RFC6180] for general advice, [RFC6782] for 98 wireline service providers, [RFC6342] for mobile network providers, 99 [RFC5963] for exchange point operators, [RFC6883] for content 100 providers, and both [RFC4852] and 101 [I-D.ietf-v6ops-enterprise-incremental-ipv6] for enterprises. Nor 102 does the document cover the ins and outs of creating an IPv6 103 addressing plan; for advice in this area, see [RFC5375]. 105 This document focuses on unicast network design only. It does not 106 cover multicast, nor supporting infrastructure such as DNS. 108 The current version is still work in progress, and it is expected 109 that the presentation and discussion of additional design choices 110 will be added as the document matures. 112 2. Design Choices 114 This section consists of a list of specific design choices a network 115 designer faces when designing an IPv6-only or dual-stack network, 116 along with guidance and advice to the designer when making a choice. 118 2.1. Links 120 2.1.1. Mix IPv4 and IPv6 on the Same Link? 122 Should IPv4 and IPv6 traffic be logically separated on a link? That 123 is: 125 a. Mix IPv4 and IPv6 traffic on the same layer 2 connection, OR 127 b. Separate IPv4 and IPv6 by using separate physical or logical 128 links (e.g., two physical links or two VLANs on the same link)? 130 Option (a) implies a single layer 3 interface at each end with both 131 IPv4 and IPv6 addresses; while option (b) implies two layer 3 132 interfaces, one for IPv4 addresses and one with IPv6 addresses. 134 The advantages of option (a) include: 136 o Requires only half as many layer 3 interfaces as option (b), thus 137 providing better scaling; 139 o May require fewer physical ports, thus saving money; 140 o Can make the QoS implementation much easier (for example, rate- 141 limiting the combined IPv4 and IPv6 traffic to or from a 142 customer); 144 o Works well in practice, as any increase in IPv6 traffic is usually 145 counter-balanced by a corresponding decrease in IPv4 traffic to or 146 from the same host (ignoring the common pattern of an overall 147 increase in Internet usage); 149 o And is generally conceptually simpler. 151 For these reasons, there is a pretty strong consensus in the operator 152 community that option (a) is the preferred way to go. Most networks 153 today use option (a) wherever possible. 155 However, there can be times when option (b) is the pragmatic choice. 156 Most commonly, option (b) is used to work around limitations in 157 network equipment. One big example is the generally poor level of 158 support today for individual statistics on IPv4 traffic vs IPv6 159 traffic when option (a) is used. Other, device-specific, limitations 160 exist as well. It is expected that these limitations will go away as 161 support for IPv6 matures, making option (b) less and less attractive 162 until the day that IPv4 is finally turned off. 164 2.1.2. Links with Only Link-Local Addresses? 166 Should the link: 168 a. Use only link-local addresses ("unnumbered"), OR 170 b. Have global or unique-local addresses assigned in addition to 171 link-locals? 173 There are two advantages of unnumbered links. The first advantage is 174 ease of configuration. In a network with a large number of 175 unnumbered links, the operator can just enable an IGP on each router, 176 without going through the tedious process of assigning and tracking 177 the addresses for each link. The second advantage is security. 178 Since link-local addresses are unroutable, the associated interfaces 179 cannot be attacked from an off-link device. This implies less effort 180 around maintaining security ACLs. 182 Countering this advantage are various disadvantages to unnumbered 183 links in IPv6: 185 o It is not possible to ping an interface that has only a link-local 186 address from a device that is not directly attached to the link. 187 Thus, to troubleshoot, one must typically log into a device that 188 is directly attached to the device in question, and execute the 189 ping from there. 191 o A traceroute passing over the unnumbered link will return the 192 loopback or system address of the router, rather than the address 193 of the interface itself. 195 o In cases of parallel point to point links it is difficult to 196 determine which of the parallel links was taken when attempting to 197 troubleshoot unless one sends packets directly between the two 198 attached link-locals on the specific interfaces. Since many 199 network problems behave differently for traffic to/from a router 200 than for traffic through the router(s) in question, this can pose 201 a significant hurdle to some troubleshooting scenarios. 203 o On some devices, by default the link-layer address of the 204 interface is derived from the MAC address assigned to interface. 205 When this is done, swapping out the interface hardware (e.g. 206 interface card) will cause the link-layer address to change. In 207 some cases (peering config, ACLs, etc) this may require additional 208 changes. However, many devices allow the link-layer address of an 209 interface to be explicitly configured, which avoids this issue. 211 o The practice of naming router interfaces using DNS names is 212 difficult and not recommended when using link-locals only. More 213 generally, it is not recommended to put link-local addresses into 214 DNS; see [RFC4472]. 216 o It is often not possible to identify the interface or link (in a 217 database, email, etc) by giving just its address without also 218 specifying the link in some manner. 220 It should be noted that it is quite possible for the same link-local 221 address to be assigned to multiple interfaces. This can happen 222 because the MAC address is duplicated (due to manufacturing process 223 defaults or the use of virtualization), because a device deliberately 224 re-uses automatically-assigned link-local addresses on different 225 links, or because an operator manually assigns the same easy-to-type 226 link-local address to multiple interfaces. All these are allowed in 227 IPv6 as long as the addresses are used on different links. 229 For more discussion on the pros and cons, see 230 [I-D.ietf-opsec-lla-only]. See also [RFC5375] for IPv6 unicast 231 address assignment considerations. 233 Today, most operators use numbered links (option b). 235 2.2. Static Routes 237 2.2.1. Link-Local Next-Hop in a Static Route? 239 What form of next-hop address should one use in a static route? 241 a. Use the far-end's link-local address as the next-hop address, OR 243 b. Use the far-end's GUA/ULA address as the next-hop address? 245 Recall that the IPv6 specs for OSPF [RFC5340] and ISIS [RFC5308] 246 dictate that they always use link-locals for next-hop addresses. For 247 static routes, [RFC4861] section 8 says: 249 A router MUST be able to determine the link-local address for each 250 of its neighboring routers in order to ensure that the target 251 address in a Redirect message identifies the neighbor router by 252 its link-local address. For static routing, this requirement 253 implies that the next-hop router's address should be specified 254 using the link-local address of the router. 256 This implies that using a GUA or ULA as the next hop will prevent a 257 router from sending Redirect messages for packets that "hit" this 258 static route. All this argues for using a link-local as the next-hop 259 address in a static route. 261 However, there are two cases where using a link-local address as the 262 next-hop clearly does not work. One is when the static route is an 263 indirect (or multi-hop) static route. The second is when the static 264 route is redistributed into another routing protocol. In these 265 cases, the above text from RFC 4861 notwithstanding, either a GUA or 266 ULA must be used. 268 Furthermore, many network operators are concerned about the 269 dependency of the default link-local address on an underlying MAC 270 address, as described in the previous section. 272 Today most operators use GUAs as next-hop addresses. 274 2.3. IGPs 276 2.3.1. IGP Choice 278 One of the main decisions for an IPv6 implementer is the choice of 279 IGP (Interior Gateway Protocol) within the network. The primary 280 choices are the IETF protocols of RIP [RFC2080], OSPF [RFC2328] 281 [RFC5340] and IS-IS [RFC5120] [RFC5308], though some operators may 282 consider non-IETF protocols. Here we limit our discussion to the 283 pros and cons of OSPF vs. IS-IS. 285 Considering just OSPF vs. IS-IS, the discussion in this section 286 revolves around the options in the table below: 288 +--------+--------+---------+---------+------------+----------------+ 289 | Option | IGP | IGP for | Known | Hard | Similar | 290 | | for | IPv6 | to work | separation | configuration | 291 | | IPv4 | | well | | possible | 292 +--------+--------+---------+---------+------------+----------------+ 293 | | | | | | | 294 +--------+--------+---------+---------+------------+----------------+ 295 | a | IS-IS | IS-IS | YES | - | YES | 296 +--------+--------+---------+---------+------------+----------------+ 297 | b | IS-IS | OSPFv3 | - | YES | - | 298 +--------+--------+---------+---------+------------+----------------+ 299 | | | | | | | 300 +--------+--------+---------+---------+------------+----------------+ 301 | c | OSPFv2 | IS-IS | YES | YES | - | 302 +--------+--------+---------+---------+------------+----------------+ 303 | d | OSPFv2 | OSPFv3 | YES | YES | YES | 304 +--------+--------+---------+---------+------------+----------------+ 305 | | | | | | | 306 +--------+--------+---------+---------+------------+----------------+ 307 | e | OSPFv3 | IS-IS | - | YES | - | 308 +--------+--------+---------+---------+------------+----------------+ 309 | f | OSPFv3 | OSPFv3 | - | - | YES | 310 +--------+--------+---------+---------+------------+----------------+ 312 Three of the options above are marked as "Known to work well". These 313 options have seen significant deployments and are generally 314 considered to be good choices. The other options represent valid 315 choices, but have not seen widespread use, so it is hard to offer 316 comments on how well they work. In particular, options (e) and (f) 317 use OSPFv3 to route IPv4 [RFC5838], which is still rather new and 318 untested. 320 A number of options are marked "Gives hard separation". These 321 options use a different IGP for IPv4 vs IPv6. With these options, a 322 problem with routing IPv6 is unlikely to affect IPv4 or visa-versa. 324 Three options are marked "Similar configuration possible". This 325 means it is possible (but not required) to use very similar IGP 326 configuration for IPv4 and IPv6: for example, the same area 327 boundaries, area numbering, link costing, etc. If you are happy with 328 your IPv4 IGP design, then this will likely be a consideration. By 329 contrast, the options that uses IS-IS for one IP version and OSPF for 330 the other version will require quite different configuration, and 331 will also require the operations staff to become familiar with the 332 difference between the two protocols. 334 With option (a), there is an additional choice of whether to run IS- 335 IS in single-topology mode (where IPv4 and IPv6 share a single 336 topology and a single set of link costs[RFC5308]) or multi-topology 337 mode (where IPv4 and IPv6 have separate topologies and potentially 338 different link costs[RFC5120]). A big problem with single-topology 339 mode is that it cannot easily accommodate devices that support 340 IPv4-only or IPv6-only. Thus, today there is general agreement that 341 multi-topology is the right choice as this gives the greatest 342 flexibility in network design. 344 It should be noted that a number of ISPs have run OSPF as their IPv4 345 IGP for quite a few years, but have selected IS-IS as their IPv6 IGP. 346 However, there are very few (none?) that have made the reverse 347 choice. This is, in part, because routers generally support more 348 nodes in an IS-IS area than in the corresponding OSPF area, and 349 because IS-IS is seen as more secure because it runs at layer 2. 351 2.4. BGP 353 The discussion in this section revolves around the following table. 355 +----------------+-----------+-------------------+ 356 | Route Family | Transport | Comments | 357 +----------------+-----------+-------------------+ 358 | | | | 359 +----------------+-----------+-------------------+ 360 | Unlabeled IPv4 | IPv4 | Works well | 361 +----------------+-----------+-------------------+ 362 | Unlabeled IPv4 | IPv6 | Next-hop issues | 363 +----------------+-----------+-------------------+ 364 | Unlabeled IPv6 | IPv4 | Next-hop issues | 365 +----------------+-----------+-------------------+ 366 | Unlabeled IPv6 | IPv6 | Works well | 367 +----------------+-----------+-------------------+ 368 | | | | 369 +----------------+-----------+-------------------+ 370 | Labeled IPv4 | IPv4 | Works well | 371 +----------------+-----------+-------------------+ 372 | Labeled IPv4 | IPv6 | Next-hop issues | 373 +----------------+-----------+-------------------+ 374 | Labeled IPv6 | IPv4 | (6PE) Works well | 375 +----------------+-----------+-------------------+ 376 | Labeled IPv6 | IPv6 | ??? | 377 +----------------+-----------+-------------------+ 378 | | | | 379 +----------------+-----------+-------------------+ 380 | VPN IPv4 | IPv4 | Works well | 381 +----------------+-----------+-------------------+ 382 | VPN IPv4 | IPv6 | Next-hop issues | 383 +----------------+-----------+-------------------+ 384 | VPN IPv6 | IPv4 | (6VPE) Works well | 385 +----------------+-----------+-------------------+ 386 | VPN IPv6 | IPv6 | ??? | 387 +----------------+-----------+-------------------+ 389 The first column lists various route families, where "unlabeled" 390 means SAFI 1, "labeled" means SAFI 4, and "VPN" means SAFI 128. The 391 second column lists the protocol used to transport the BGP session, 392 frequently specified by giving either an IPv4 or IPv6 address in the 393 "neighbor" statement. 395 The third column comments on the combination in the first two 396 columns: 398 o For combinations marked "Works well", these combinations are 399 widely supported and are generally recommended. 401 o For combinations marked "Next-hop issues", these combinations are 402 less-widely supported and when supported, often have next-hop 403 issues. That is, the next-hop address is typically a v4-mapped 404 IPv6 address, which is based on some IPv4 address on the sending 405 router. This v4-mapped IPv6 address is often not reachable by 406 default using IPv6 routing. One common solution to this problem 407 is to use routing policy to change the next-hop to a different 408 IPv6 address. 410 o For combinations marked as "???", it is believed that these 411 combinations will not be supported until MPLS over IPv6 becomes 412 available. [Need to Confirm]. 414 Also, it is important to note that changing the set of address 415 families being carried over a BGP session requires the BGP session to 416 be reset (unless something like [I-D.ietf-idr-dynamic-cap] or 417 [I-D.ietf-idr-bgp-multisession] is in use). This is generally more 418 of an issue with eBGP sessions than iBGP sessions: for iBGP sessions 419 it is common practice for a router to have to two iBGP sessions, one 420 to each member of a route reflector pair, and so one can change the 421 set of address families on first one session and then the other. 423 The following subsections discuss specific scenarios in more detail. 425 2.4.1. BGP Sessions for Unlabeled Routes 427 Unlabeled routes are commonly carried on eBGP sessions, as well as on 428 iBGP sessions in networks where Internet traffic is carried unlabeled 429 across the network. In these scenarios, operators today most 430 commonly use two BGP sessions: one session is transported over IPv4 431 and carries the unlabeled IPv4 routes, while the second session is 432 transported over IPv6 and carries the unlabeled IPv6 routes. 434 There are several reasons for this choice: 436 o It gives a clean separation between IPv4 and IPv6. 438 o This avoids the next-hop problem described in note 1 above. 440 o The status of the routes follows the status of the underlying 441 transport. If, for example, the IPv6 data path between the two 442 BGP speakers fails, then the IPv6 session between the two speakers 443 will fail and the IPv6 routes will be withdrawn, which will allow 444 the traffic to be re-routed elsewhere. By contrast, if the IPv6 445 routes were transported over IPv4, then the failure of the IPv6 446 data path might leave a working IPv4 data path, so the BGP session 447 would remain up and the IPv6 routes would not be withdrawn, and 448 thus the IPv6 traffic would be sent into a black hole. 450 o It avoids resetting the BGP session when adding IPv6 to an 451 existing session, or when removing IPv4 from an existing session. 453 2.4.2. BGP sessions for Labeled or VPN Routes 455 In these scenarios, it is most common today to carry both the IPv4 456 and IPv6 routes over sessions transported over IPv4. This can be 457 done with either: (a) one session carrying both route families, or 458 (b) two sessions, one for each family. 460 Using a single session is usually appropriate for an iBGP session 461 going to a route reflector handling both route families. Using a 462 single session here usually means that the BGP session will reset 463 when changing the set of address families, but as noted above, this 464 is usually not a problem when redundant route reflectors are 465 involved. 467 In eBGP situations, two sessions are usually more appropriate. 469 2.4.3. eBGP Endpoints: Global or Link-Local Addresses? 471 When running eBGP over IPv6, there are two options for the addresses 472 to use at each end of the eBGP session (or more properly, the 473 underlying TCP session): 475 a. Use link-local addresses for the eBGP session, OR 477 b. Use global addresses for the eBGP session. 479 Note that the choice here is the addresses to use for the eBGP 480 sessions, and not whether the link itself has global (or unique- 481 local) addresses. In particular, it is quite possible for the eBGP 482 session to use link-local addresses even when the link has global 483 addresses. 485 The big attraction for option (a) is security: an eBGP session using 486 link-local addresses is impossible to attack from a device that is 487 off-link. This provides very strong protection against TCP RST and 488 similar attacks. Though there are other ways to get an equivalent 489 level of security (e.g. GTSM [RFC5082], MD5 [RFC5925], or ACLs), 490 these other ways require additional configuration which can be 491 forgotten or potentially mis-configured. 493 However, there are a number of small disadvantages to using link- 494 local addresses: 496 o Using link-local addresses only works for single-hop eBGP 497 sessions; it does not work for multi-hop sessions. 499 o One must use "next-hop self" at both endpoints, otherwise re- 500 advertising routes learned via eBGP into iBGP will not work. 501 (Some products enable "next-hop self" in this situation 502 automatically). 504 o Operators and their tools are used to referring to eBGP sessions 505 by address only, something that is not possible with link-local 506 addresses. 508 o If one is configuring parallel eBGP sessions for IPv4 and IPv6 509 routes, then using link-local addresses for the IPv6 session 510 introduces extra operational differences between the two sessions 511 which could otherwise be avoided. 513 o On some products, an eBGP session using a link-local address is 514 more complex to configure than a session that use a global 515 address. 517 o If hardware or other issues cause one to move the cable to a 518 different local interface, then reconfiguration is required at 519 both ends: at the local end because the interface has changed (and 520 with link-local addresses, the interface must always be specified 521 along with the address), and at the remote end because the link- 522 local address has likely changed. (Contrast this with using 523 global addresses, where less re-configuration is required at the 524 local end, and no reconfiguration is required at the remote end). 526 o Finally, a strict interpretation of RFC 2545 can be seen as 527 forbidding running eBGP between link-local addresses, as RFC 2545 528 requires the BGP next-hop field to contain at least a global 529 address. 531 For these reasons, most operators today choose to have their eBGP 532 sessions use global addresses. 534 3. General Observations 536 There are two themes that run though many of the design choices in 537 this document. This section presents some general discussion on 538 these two themes. 540 3.1. Use of Link-Local Addresses 542 The proper use of link-local addresses is a common theme in the IPv6 543 network design choices. Link-layer addresses are, of course, always 544 present in an IPv6 network, but current network design practice 545 mostly ignores them, despite efforts such as 546 [I-D.ietf-opsec-lla-only]. 548 There are three main reasons for this current practice: 550 o Network operators are concerned about the volatility of link-local 551 addresses based on MAC addresses, despite the fact that this 552 concern can be overcome by manually-configuring link-local 553 addresses; 555 o It is impossible to ping a link-local address from a device that 556 is not on the same subnet. This is a troubleshooting 557 disadvantage, though it can also be viewed as a security 558 advantage. 560 o Most operators are currently running networks that carry both IPv4 561 and IPv6 traffic, and wish to harmonize their IPv4 and IPv6 design 562 and operational practices where possible. 564 3.2. Separation of IPv4 and IPv6 566 Currently, most operators are running or planning to run networks 567 that carry both IPv4 and IPv6 traffic. Hence the question: To what 568 degree should IPv4 and IPv6 be kept separate? As can be seen above, 569 this breaks into two sub-questions: To what degree should IPv4 and 570 IPv6 traffic be kept separate, and to what degree should IPv4 and 571 IPv6 routing information be kept separate? 573 The general consensus around the first question is that IPv4 and IPv6 574 traffic should generally be mixed together. This recommendation is 575 driven by the operational simplicity of mixing the traffic, plus the 576 general observation that the service being offered to the end user is 577 Internet connectivity and most users do not know or care about the 578 differences between IPv4 and IPv6. Thus it is very desirable to mix 579 IPv4 and IPv6 on the same link to the end user. On other links, 580 separation is possible but more operationally complex, though it does 581 occasionally allow the operator to work around limitations on network 582 devices. The situation here is roughly comparable to IP and MPLS 583 traffic: many networks mix the two traffic types on the same links 584 without issues. 586 By contrast, there is more of an argument for carrying IPv6 routing 587 information over IPv6 transport, while leaving IPv4 routing 588 information on IPv4 transport. By doing this, one gets fate-sharing 589 between the control and data plane for each IP protocol version: if 590 the data plane fails for some reason, then often the control plane 591 will too. 593 4. IANA Considerations 595 This document makes no requests of IANA. 597 5. Security Considerations 599 (TBD) 601 6. Acknowledgements 603 Many, many people in the V6OPS working group provided comments and 604 suggestions that made their way into this document. A partial list 605 includes: Rajiv Asati, Fred Baker, Michael Behringer, Marc Blanchet, 606 Ron Bonica, Randy Bush, Cameron Byrne, Brian Carpenter, KK 607 Chittimaneni, Tim Chown, Lorenzo Colitti, Gert Doering, Bill Fenner, 608 Kedar K Gaonkar, Chris Grundemann, Steinar Haug, Ray Hunter, Joel 609 Jaeggli, Victor Kuarsingh, Ivan Pepelnjak, Alexandru Petrescu, Rob 610 Shakir, Mark Smith, Jean-Francois Tremblay, Tina Tsou, Dan York, and 611 Xuxiaohu. 613 The authors would also like to thank Pradeep Jain and Alastair 614 Johnson for helpful comments on a very preliminary version of this 615 document. 617 7. Informative References 619 [I-D.ietf-idr-bgp-multisession] 620 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 621 BGP", draft-ietf-idr-bgp-multisession-07 (work in 622 progress), September 2012. 624 [I-D.ietf-idr-dynamic-cap] 625 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 626 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 627 December 2011. 629 [I-D.ietf-opsec-lla-only] 630 Behringer, M. and E. Vyncke, "Using Only Link-Local 631 Addressing Inside an IPv6 Network", draft-ietf-opsec-lla- 632 only-10 (work in progress), July 2014. 634 [I-D.ietf-v6ops-enterprise-incremental-ipv6] 635 Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 636 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 637 Guidelines", draft-ietf-v6ops-enterprise-incremental- 638 ipv6-06 (work in progress), July 2014. 640 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 641 January 1997. 643 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 645 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 646 Considerations and Issues with IPv6 DNS", RFC 4472, April 647 2006. 649 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 650 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 651 Focus", RFC 4852, April 2007. 653 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 654 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 655 September 2007. 657 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 658 Pignataro, "The Generalized TTL Security Mechanism 659 (GTSM)", RFC 5082, October 2007. 661 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 662 Topology (MT) Routing in Intermediate System to 663 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 665 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 666 2008. 668 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 669 for IPv6", RFC 5340, July 2008. 671 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 672 and C. Hahn, "IPv6 Unicast Address Assignment 673 Considerations", RFC 5375, December 2008. 675 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 676 Aggarwal, "Support of Address Families in OSPFv3", RFC 677 5838, April 2010. 679 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 680 Authentication Option", RFC 5925, June 2010. 682 [RFC5963] Gagliano, R., "IPv6 Deployment in Internet Exchange Points 683 (IXPs)", RFC 5963, August 2010. 685 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 686 Transition Mechanisms during IPv6 Deployment", RFC 6180, 687 May 2011. 689 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 690 Deployment", RFC 6342, August 2011. 692 [RFC6782] Kuarsingh, V. and L. Howard, "Wireline Incremental IPv6", 693 RFC 6782, November 2012. 695 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 696 Content Providers and Application Service Providers", RFC 697 6883, March 2013. 699 Authors' Addresses 701 Philip Matthews 702 Alcatel-Lucent 703 600 March Road 704 Ottawa, Ontario K2K 2E6 705 Canada 707 Phone: +1 613-784-3139 708 Email: philip_matthews@magma.ca 710 Victor Kuarsingh 711 Dyn 712 150 Dow Street 713 Manchester, NH 03101 714 USA 716 Email: victor@jvknet.com