idnits 2.17.1 draft-ietf-v6ops-design-choices-02.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 248: '... 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 4, 2014) is 3516 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 8, 2015 Dyn 6 September 4, 2014 8 Design Choices for IPv6 Networks 9 draft-ietf-v6ops-design-choices-02 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 8, 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 not often not possible to identify the interface or link (in 217 a 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]. 232 Today, most operators use numbered links (option b). 234 2.2. Static Routes 236 2.2.1. Link-Local Next-Hop in a Static Route? 238 What form of next-hop address should one use in a static route? 240 a. Use the far-end's link-local address as the next-hop address, OR 242 b. Use the far-end's GUA/ULA address as the next-hop address? 244 Recall that the IPv6 specs for OSPF [RFC5340] and ISIS [RFC5308] 245 dictate that they always use link-locals for next-hop addresses. For 246 static routes, [RFC4861] section 8 says: 248 A router MUST be able to determine the link-local address for each 249 of its neighboring routers in order to ensure that the target 250 address in a Redirect message identifies the neighbor router by 251 its link-local address. For static routing, this requirement 252 implies that the next-hop router's address should be specified 253 using the link-local address of the router. 255 This implies that using a GUA or ULA as the next hop will prevent a 256 router from sending Redirect messages for packets that "hit" this 257 static route. All this argues for using a link-local as the next-hop 258 address in a static route. 260 However, there are two cases where using a link-local address as the 261 next-hop clearly does not work. One is when the static route is an 262 indirect (or multi-hop) static route. The second is when the static 263 route is redistributed into another routing protocol. In these 264 cases, the above text from RFC 4861 notwithstanding, either a GUA or 265 ULA must be used. 267 Furthermore, many network operators are concerned about the 268 dependency of the default link-local address on an underlying MAC 269 address, as described in the previous section. 271 Today most operators use GUAs as next-hop addresses. 273 2.3. IGPs 275 2.3.1. IGP Choice 277 One of the main decisions for an IPv6 implementor is the choice of 278 IGP (Interior Gateway Protocol) within the network. The primary 279 choices are the IETF protocols of RIP [RFC2080], OSPF [RFC2328] 280 [RFC5340] and IS-IS [RFC5120] [RFC5308], though some operators may 281 consider non-IETF protocols. Here we limit our discussion to the 282 pros and cons of OSPF vs. IS-IS. 284 Considering just OSPF vs. IS-IS, the discussion in this section 285 revolves around the options in the table below: 287 +--------+--------+---------+---------+------------+----------------+ 288 | Option | IGP | IGP for | Known | Hard | Similar | 289 | | for | IPv6 | to work | separation | configuration | 290 | | IPv4 | | well | | possible | 291 +--------+--------+---------+---------+------------+----------------+ 292 | | | | | | | 293 +--------+--------+---------+---------+------------+----------------+ 294 | a | IS-IS | IS-IS | YES | - | YES | 295 +--------+--------+---------+---------+------------+----------------+ 296 | b | IS-IS | OSPFv3 | - | YES | - | 297 +--------+--------+---------+---------+------------+----------------+ 298 | | | | | | | 299 +--------+--------+---------+---------+------------+----------------+ 300 | c | OSPFv2 | IS-IS | YES | YES | - | 301 +--------+--------+---------+---------+------------+----------------+ 302 | d | OSPFv2 | OSPFv3 | YES | YES | YES | 303 +--------+--------+---------+---------+------------+----------------+ 304 | | | | | | | 305 +--------+--------+---------+---------+------------+----------------+ 306 | e | OSPFv3 | IS-IS | - | YES | - | 307 +--------+--------+---------+---------+------------+----------------+ 308 | f | OSPFv3 | OSPFv3 | - | - | YES | 309 +--------+--------+---------+---------+------------+----------------+ 311 Three of the options above are marked as "Known to work well". These 312 options have seen significant deployments and are generally 313 considered to be good choices. The other options represent valid 314 choices, but have not seen widespread use, so it is hard to offer 315 comments on how well they work. In particular, options (e) and (f) 316 use OSPFv3 to route IPv4 [RFC5838], which is still rather new and 317 untested. 319 A number of options are marked "Gives hard separation". These 320 options use a different IGP for IPv4 vs IPv6. With these options, a 321 problem with routing IPv6 is unlikely to affect IPv4 or visa-versa. 323 Three options are marked "Similar configuration possible". This 324 means it is possible (but not required) to use very similar IGP 325 configuration for IPv4 and IPv6: for example, the same area 326 boundaries, area numbering, link costing, etc. If you are happy with 327 your IPv4 IGP design, then this will likely be a consideration. By 328 contrast, the options that uses IS-IS for one IP version and OSPF for 329 the other version will require quite different configuration, and 330 will also require the operations staff to become familiar with the 331 difference between the two protocols. 333 With option (a), there is an additional choice of whether to run IS- 334 IS in single-topology mode (where IPv4 and IPv6 share a single 335 topology and a single set of link costs[RFC5308]) or multi-topology 336 mode (where IPv4 and IPv6 have separate topologies and potentially 337 different link costs[RFC5120]). A big problem with single-topology 338 mode is that it cannot easily accommodate devices that support 339 IPv4-only or IPv6-only. Thus, today there is general agreement that 340 multi-topology is the right choice as this gives the greatest 341 flexibility in network design. 343 It should be noted that a number of ISPs have run OSPF as their IPv4 344 IGP for quite a few years, but have selected IS-IS as their IPv6 IGP. 345 However, there are very few (none?) that have made the reverse 346 choice. This is, in part, because routers generally support more 347 nodes in an IS-IS area than in the corresponding OSPF area, and 348 because IS-IS is seen as more secure because it runs at layer 2. 350 2.4. BGP 352 The discussion in this section revolves around the following table. 354 +----------------+-----------+-------------------+ 355 | Route Family | Transport | Comments | 356 +----------------+-----------+-------------------+ 357 | | | | 358 +----------------+-----------+-------------------+ 359 | Unlabeled IPv4 | IPv4 | Works well | 360 +----------------+-----------+-------------------+ 361 | Unlabeled IPv4 | IPv6 | Next-hop issues | 362 +----------------+-----------+-------------------+ 363 | Unlabeled IPv6 | IPv4 | Next-hop issues | 364 +----------------+-----------+-------------------+ 365 | Unlabeled IPv6 | IPv6 | Works well | 366 +----------------+-----------+-------------------+ 367 | | | | 368 +----------------+-----------+-------------------+ 369 | Labeled IPv4 | IPv4 | Works well | 370 +----------------+-----------+-------------------+ 371 | Labeled IPv4 | IPv6 | Next-hop issues | 372 +----------------+-----------+-------------------+ 373 | Labeled IPv6 | IPv4 | (6PE) Works well | 374 +----------------+-----------+-------------------+ 375 | Labeled IPv6 | IPv6 | ??? | 376 +----------------+-----------+-------------------+ 377 | | | | 378 +----------------+-----------+-------------------+ 379 | VPN IPv4 | IPv4 | Works well | 380 +----------------+-----------+-------------------+ 381 | VPN IPv4 | IPv6 | Next-hop issues | 382 +----------------+-----------+-------------------+ 383 | VPN IPv6 | IPv4 | (6VPE) Works well | 384 +----------------+-----------+-------------------+ 385 | VPN IPv6 | IPv6 | ??? | 386 +----------------+-----------+-------------------+ 388 The first column lists various route families, where "unlabeled" 389 means SAFI 1, "labeled" means SAFI 4, and "VPN" means SAFI 128. The 390 second column lists the protocol used to transport the BGP session, 391 frequently specified by giving either an IPv4 or IPv6 address in the 392 "neighbor" statement. 394 The third column comments on the combination in the first two 395 columns: 397 o For combinations marked "Works well", these combinations are 398 widely supported and are generally recommended. 400 o For combinations marked "Next-hop issues", these combinations are 401 less-widely supported and when supported, often have next-hop 402 issues. That is, the next-hop address is typically a v4-mapped 403 IPv6 address, which is based on some IPv4 address on the sending 404 router. This v4-mapped IPv6 address is often not reachable by 405 default using IPv6 routing. One common solution to this problem 406 is to use routing policy to change the next-hop to a different 407 IPv6 address. 409 o For combinations marked as "???", it is believed that these 410 combinations will not be supported until MPLS over IPv6 becomes 411 available. [Need to Confirm]. 413 Also, it is important to note that changing the set of address 414 families being carried over a BGP session requires the BGP session to 415 be reset (unless something like [I-D.ietf-idr-dynamic-cap] or 416 [I-D.ietf-idr-bgp-multisession] is in use). This is generally more 417 of an issue with eBGP sessions than iBGP sessions: for iBGP sessions 418 it is common practice for a router to have to two iBGP sessions, one 419 to each member of a route reflector pair, and so one can change the 420 set of address families on first one session and then the other. 422 The following subsections discuss specific scenarios in more detail. 424 2.4.1. BGP Sessions for Unlabeled Routes 426 Unlabeled routes are commonly carried on eBGP sessions, as well as on 427 iBGP sessions in networks where Internet traffic is carried unlabeled 428 across the network. In these scenarios, operators today most 429 commonly use two BGP sessions: one session is transported over IPv4 430 and carries the unlabeled IPv4 routes, while the second session is 431 transported over IPv6 and carries the unlabeled IPv6 routes. 433 There are several reasons for this choice: 435 o It gives a clean separation between IPv4 and IPv6. 437 o This avoids the next-hop problem described in note 1 above. 439 o The status of the routes follows the status of the underlying 440 transport. If, for example, the IPv6 data path between the two 441 BGP speakers fails, then the IPv6 session between the two speakers 442 will fail and the IPv6 routes will be withdrawn, which will allow 443 the traffic to be re-routed elsewhere. By contrast, if the IPv6 444 routes were transported over IPv4, then the failure of the IPv6 445 data path might leave a working IPv4 data path, so the BGP session 446 would remain up and the IPv6 routes would not be withdrawn, and 447 thus the IPv6 traffic would be sent into a black hole. 449 o It avoids resetting the BGP session when adding IPv6 to an 450 existing session, or when removing IPv4 from an existing session. 452 2.4.2. BGP sessions for Labeled or VPN Routes 454 In these scenarios, it is most common today to carry both the IPv4 455 and IPv6 routes over sessions transported over IPv4. This can be 456 done with either: (a) one session carrying both route families, or 457 (b) two sessions, one for each family. 459 Using a single session is usually appropriate for an iBGP session 460 going to a route reflector handling both route families. Using a 461 single session here usually means that the BGP session will reset 462 when changing the set of address families, but as noted above, this 463 is usually not a problem when redundant route reflectors are 464 involved. 466 In eBGP situations, two sessions are usually more appropriate. 468 2.4.3. eBGP Endpoints: Global or Link-Local Addresses? 470 When running eBGP over IPv6, there are two options for the addresses 471 to use at each end of the eBGP session (or more properly, the 472 underlying TCP session): 474 a. Use link-local addresses for the eBGP session, OR 476 b. Use global addresses for the eBGP session. 478 Note that the choice here is the addresses to use for the eBGP 479 sessions, and not whether the link itself has global (or unique- 480 local) addresses. In particular, it is quite possible for the eBGP 481 session to use link-local addresses even when the link has global 482 addresses. 484 The big attraction for option (a) is security: an eBGP session using 485 link-local addresses is impossible to attack from a device that is 486 off-link. This provides very strong protection against TCP RST and 487 similar attacks. Though there are other ways to get an equivalent 488 level of security (e.g. GTSM [RFC5082], MD5 [RFC5925], or ACLs), 489 these other ways require additional configuration which can be 490 forgotten or potentially mis-configured. 492 However, there are a number of small disadvantages to using link- 493 local addresses: 495 o Using link-local addresses only works for single-hop eBGP 496 sessions; it does not work for multi-hop sessions. 498 o One must use "next-hop self" at both endpoints, otherwise re- 499 advertising routes learned via eBGP into iBGP will not work. 500 (Some products enable "next-hop self" in this situation 501 automatically). 503 o Operators and their tools are used to referring to eBGP sessions 504 by address only, something that is not possible with link-local 505 addresses. 507 o If one is configuring parallel eBGP sessions for IPv4 and IPv6 508 routes, then using link-local addresses for the IPv6 session 509 introduces extra operational differences between the two sessions 510 which could otherwise be avoided. 512 o On some products, an eBGP session using a link-local address is 513 more complex to configure than a session that use a global 514 address. 516 o If hardware or other issues cause one to move the cable to a 517 different local interface, then reconfiguration is required at 518 both ends: at the local end because the interface has changed (and 519 with link-local addresses, the interface must always be specified 520 along with the address), and at the remote end because the link- 521 local address has likely changed. (Contrast this with using 522 global addresses, where less re-configuration is required at the 523 local end, and no reconfiguration is required at the remote end). 525 o Finally, a strict interpretation of RFC 2545 can be seen as 526 forbidding running eBGP between link-local addresses, as RFC 2545 527 requires the BGP next-hop field to contain at least a global 528 address. 530 For these reasons, most operators today choose to have their eBGP 531 sessions use global addresses. 533 3. General Observations 535 There are two themes that run though many of the design choices in 536 this document. This section presents some general discussion on 537 these two themes. 539 3.1. Use of Link-Local Addresses 541 The proper use of link-local addresses is a common theme in the IPv6 542 network design choices. Link-layer addresses are, of course, always 543 present in an IPv6 network, but current network design practice 544 mostly ignores them, despite efforts such as 545 [I-D.ietf-opsec-lla-only]. 547 There are three main reasons for this current practice: 549 o Network operators are concerned about the volatility of link-local 550 addresses based on MAC addresses, despite the fact that this 551 concern can be overcome by manually-configuring link-local 552 addresses; 554 o It is impossible to ping a link-local address from a device that 555 is not on the same subnet. This is a troubleshooting 556 disadvantage, though it can also be viewed as a security 557 advantage. 559 o Most operators are currently running networks that carry both IPv4 560 and IPv6 traffic, and wish to harmonize their IPv4 and IPv6 design 561 and operational practices where possible. 563 3.2. Separation of IPv4 and IPv6 565 Currently, most operators are running or planning to run networks 566 that carry both IPv4 and IPv6 traffic. Hence the question: To what 567 degree should IPv4 and IPv6 be kept separate? As can be seen above, 568 this breaks into two sub-questions: To what degree should IPv4 and 569 IPv6 traffic be kept separate, and to what degree should IPv4 and 570 IPv6 routing information be kept separate? 572 The general consensus around the first question is that IPv4 and IPv6 573 traffic should generally be mixed together. This recommendation is 574 driven by the operational simplicity of mixing the traffic, plus the 575 general observation that the service being offered to the end user is 576 Internet connectivity and most users do not know or care about the 577 differences between IPv4 and IPv6. Thus it is very desirable to mix 578 IPv4 and IPv6 on the same link to the end user. On other links, 579 separation is possible but more operationally complex, though it does 580 occasionally allow the operator to work around limitations on network 581 devices. The situation here is roughly comparable to IP and MPLS 582 traffic: many networks mix the two traffic types on the same links 583 without issues. 585 By contrast, there is more of an argument for carrying IPv6 routing 586 information over IPv6 transport, while leaving IPv4 routing 587 information on IPv4 transport. By doing this, one gets fate-sharing 588 between the control and data plane for each IP protocol version: if 589 the data plane fails for some reason, then often the control plane 590 will too. 592 4. IANA Considerations 594 This document makes no requests of IANA. 596 5. Security Considerations 598 (TBD) 600 6. Acknowledgements 602 Many, many people in the V6OPS working group provided comments and 603 suggestions that made their way into this document. A partial list 604 includes: Rajiv Asati, Fred Baker, Michael Behringer, Marc Blanchet, 605 Ron Bonica, Randy Bush, Cameron Byrne, Brian Carpenter, KK 606 Chittimaneni, Tim Chown, Lorenzo Colitti, Gert Doering, Bill Fenner, 607 Kedar K Gaonkar, Chris Grundemann, Steinar Haug, Ray Hunter, Joel 608 Jaeggli, Victor Kuarsingh, Ivan Pepelnjak, Alexandru Petrescu, Rob 609 Shakir, Mark Smith, Jean-Francois Tremblay, Tina Tsou, Dan York, and 610 Xuxiaohu. 612 The authors would also like to thank Pradeep Jain and Alastair 613 Johnson for helpful comments on a very preliminary version of this 614 document. 616 7. Informative References 618 [I-D.ietf-idr-bgp-multisession] 619 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 620 BGP", draft-ietf-idr-bgp-multisession-07 (work in 621 progress), September 2012. 623 [I-D.ietf-idr-dynamic-cap] 624 Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- 625 4", draft-ietf-idr-dynamic-cap-14 (work in progress), 626 December 2011. 628 [I-D.ietf-opsec-lla-only] 629 Behringer, M. and E. Vyncke, "Using Only Link-Local 630 Addressing Inside an IPv6 Network", draft-ietf-opsec-lla- 631 only-10 (work in progress), July 2014. 633 [I-D.ietf-v6ops-enterprise-incremental-ipv6] 634 Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 635 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 636 Guidelines", draft-ietf-v6ops-enterprise-incremental- 637 ipv6-06 (work in progress), July 2014. 639 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 640 January 1997. 642 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 644 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 645 Considerations and Issues with IPv6 DNS", RFC 4472, April 646 2006. 648 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 649 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 650 Focus", RFC 4852, April 2007. 652 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 653 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 654 September 2007. 656 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 657 Pignataro, "The Generalized TTL Security Mechanism 658 (GTSM)", RFC 5082, October 2007. 660 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 661 Topology (MT) Routing in Intermediate System to 662 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 664 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 665 2008. 667 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 668 for IPv6", RFC 5340, July 2008. 670 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 671 and C. Hahn, "IPv6 Unicast Address Assignment 672 Considerations", RFC 5375, December 2008. 674 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 675 Aggarwal, "Support of Address Families in OSPFv3", RFC 676 5838, April 2010. 678 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 679 Authentication Option", RFC 5925, June 2010. 681 [RFC5963] Gagliano, R., "IPv6 Deployment in Internet Exchange Points 682 (IXPs)", RFC 5963, August 2010. 684 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 685 Transition Mechanisms during IPv6 Deployment", RFC 6180, 686 May 2011. 688 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 689 Deployment", RFC 6342, August 2011. 691 [RFC6782] Kuarsingh, V. and L. Howard, "Wireline Incremental IPv6", 692 RFC 6782, November 2012. 694 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 695 Content Providers and Application Service Providers", RFC 696 6883, March 2013. 698 Authors' Addresses 700 Philip Matthews 701 Alcatel-Lucent 702 600 March Road 703 Ottawa, Ontario K2K 2E6 704 Canada 706 Phone: +1 613-784-3139 707 Email: philip_matthews@magma.ca 709 Victor Kuarsingh 710 Dyn 711 150 Dow Street 712 Manchester, NH 03101 713 USA 715 Email: victor@jvknet.com