idnits 2.17.1 draft-carpenter-v6ops-icp-guidance-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2012) is 4417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-02) exists of draft-carpenter-6renum-static-problem-01 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: August 26, 2012 Huawei Technologies Co., Ltd 6 February 23, 2012 8 IPv6 Guidance for Internet Content and Application Service Providers 9 draft-carpenter-v6ops-icp-guidance-03 11 Abstract 13 This document provides guidance and suggestions for Internet Content 14 Providers and Application Service Providers who wish to offer their 15 service to both IPv6 and IPv4 customers. Many of the points will 16 also apply to any enterprise network preparing for IPv6 users. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 26, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. General Strategy . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Education and Skills . . . . . . . . . . . . . . . . . . . . . 5 55 4. Arranging IPv6 Connectivity . . . . . . . . . . . . . . . . . 6 56 5. IPv6 Infrastructure . . . . . . . . . . . . . . . . . . . . . 6 57 5.1. Address and subnet assignment . . . . . . . . . . . . . . 6 58 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. Network Stack . . . . . . . . . . . . . . . . . . . . . . 9 64 8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 10 65 8.3. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. Coping with Transition Technologies . . . . . . . . . . . . . 11 67 10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 12 68 11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 12 69 12. Operations and Management . . . . . . . . . . . . . . . . . . 13 70 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 73 16. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 15 74 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 17.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 17.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 The deployment of IPv6 [RFC2460] is now in progress, and users with 82 no IPv4 access are likely to appear in increasing numbers in the 83 coming years. Any provider of content or application services over 84 the Internet will need to arrange for IPv6 access or else risk losing 85 large numbers of potential customers. The time for action is now, 86 while the number of such customers is small, so that appropriate 87 skills, software and equipment can be acquired in good time to scale 88 up the IPv6 service as demand increases. An additional advantage of 89 early support for IPv6 customers is that it will reduce the number of 90 customers connecting later via IPv4 "extension" solutions such as 91 double NAT, which will otherwise degrade the user experience. 93 Nevertheless, it is important that the introduction of IPv6 service 94 should not make service for IPv4 customers worse. In some 95 circumstances, technologies intended to assist in the transition from 96 IPv4 to IPv6 are known to have negative effects on the user 97 experience. A deployment strategy for IPv6 must avoid these effects 98 as much as possible. 100 The purpose of this document is to provide guidance and suggestions 101 for Internet Content Providers (ICPs) and Application Service 102 Providers (ASPs) who wish to offer their services to both IPv6 and 103 IPv4 customers. For simplicity, the term ICP is mainly used in the 104 body of this document, but the guidance also applies to ASPs. Many 105 of the points in this document will also apply to enterprise networks 106 that do not classify themselves as ICPs. Any enterprise or 107 department that runs at least one externally accessible server, such 108 as an HTTP server, may also be concerned. Although specific 109 managerial and technical approaches are described, this is not a rule 110 book; each operator will need to make its own plan, tailored to its 111 own services and customers. 113 2. General Strategy 115 The most importance advice here is to actually have a general 116 strategy. Adding support for a second network layer protocol is a 117 new departure for most modern organisations, and it cannot be done 118 casually on a day-by-day basis. Even if it is impossible to write a 119 precisely dated plan, the intended steps in the process need to be 120 defined well in advance. There is no single blueprint for this. The 121 rest of this document is meant to provide a set of topics to be taken 122 into account in defining the strategy. 124 In determining the urgency of this strategy, it should be noted that 125 the central IPv4 registry (IANA) ran out of spare blocks of IPv4 126 addresses in February 2011 and the various regional registries are 127 expected to exhaust their reserves over the next one to two years. 128 After this, Internet Service Providers (ISPs) will run out at dates 129 determined by their own customer base. No precise date can be given 130 for when IPv6-only customers will appear in commercially significant 131 numbers, but - particularly in the case of mobile users - it may be 132 quite soon. Complacency about this is therefore not an option for 133 any ICP that wishes to grow its customer base over the coming years. 135 The most common strategy for an ICP is to provide dual stack services 136 - both IPv4 and IPv6 on an equal basis - to cover both existing and 137 future customers. This is the recommended strategy in [RFC6180] for 138 straightforward situations. Some ICPs who already have satisfactory 139 operational experience with IPv6 might consider an IPv6-only 140 strategy, with IPv4 clients being supported by translation or proxy 141 at their ISP border. However, the present document is addressed to 142 ICPs without IPv6 experience, who are likely to prefer the dual stack 143 model to build on their existing IPv4 service. 145 Within the dual stack model, two approaches could be adopted, 146 sometimes referred to as "outside in" and "inside out": 148 o Outside in: start by providing external users with an IPv6 public 149 access to your services, for example by running a reverse proxy 150 that handles IPv6 customers (see Section 7 for details). 151 Progressively enable IPv6 internally. 152 o Inside out: start by enabling internal networking infrastructure, 153 hosts, and applications to support IPv6. Progressively reveal 154 IPv6 access to external customers. 156 Which of these approaches to adopt depends on the precise 157 circumstances of the ICP concerned. "Outside in" has the benefit of 158 giving interested customers IPv6 access at an early stage, and 159 thereby gaining precious operational experience, before meticulously 160 updating every piece of equipment and software. For example, if some 161 back-office system, that is never exposed to users, only supports 162 IPv4, it will not cause delay. "Inside out" has the benefit of 163 completing the implementation of IPv6 as a single project. Any ICP 164 could choose this approach, but it might be most appropriate for a 165 small ICP without complex back-end systems. 167 A point that must be considered in the strategy is that some 168 customers will remain IPv4-only for many years, others will have both 169 IPv4 and IPv6 access, and yet others will have only IPv6. 170 Additionally, mobile customers may find themselves switching between 171 IPv4 and IPv6 access as they travel, even within a single session. 172 Services and applications must be able to deal with this, just as 173 easily as they deal today with a user whose IPv4 address changes (see 174 the discussion of cookies in Section 8.2). 176 Neverthless, the end goal is to have a network that does not need 177 major changes when at some point in the future it becomes possible to 178 transition to IPv6-only, even if only for some parts of the network. 179 That is, the IPv6 deployment should be designed in such a way as to 180 more or less assume that IPv4 is absent, so the network will function 181 seamlessly when it is indeed no longer there. 183 An important first step in every strategy is to determine from every 184 hardware and software supplier details of their planned dates for 185 providing full IPv6 support, with performance equivalent to IPv4, in 186 their products and services. 188 3. Education and Skills 190 Some older staff may have experience of running multiprotocol 191 networks, which were common twenty years ago before the dominance of 192 IPv4. However, IPv6 will be new to them, and also to younger staff 193 brought up on TCP/IP. It is not enough to have one "IPv6 expert" in 194 a team. On the contrary, everybody who knows about IPv4 needs to 195 know about IPv6, from network architect to help desk responder. 196 Therefore, an early and essential part of the strategy must be 197 education, including practical training, so that all staff acquire a 198 general understanding of IPv6, how it affects basic features such as 199 the DNS, and the relevant practical skills. To take a trivial 200 example, any staff used to dotted-decimal IPv4 addresses need to 201 become familiar with the colon-hexadecimal format used for IPv6. 203 There is an anecdote of one IPv6 deployment in which prefixes 204 including the letters A to F were avoided by design, to avoid 205 confusing sysadmins unfamiliar with hexadecimal notation. This is 206 not a desirable result. There is another anecdote of a help desk 207 responder telling a customer to "disable one-Pv6" in order to solve a 208 problem. It should be a goal to avoid having untrained staff who 209 don't understand hexadecimal or who can't even spell "IPv6". 211 It is very useful to have a small laboratory network available for 212 training and self-training in IPv6, where staff may experiment and 213 make mistakes without disturbing the operational IPv4 service. This 214 lab should run both IPv4 and IPv6, to gain experience with a dual- 215 stack environment and new features such as having multiple addresses 216 per interface. 218 A final remark about training is that it should not be given too 219 soon, or it will be forgotten. Training has a definite need to be 220 done "just in time" in order to properly "stick." Training, lab 221 experience, and actual deployment should therefore follow each other 222 immediately. If possible, training should even be combined with 223 actual operational experience. 225 4. Arranging IPv6 Connectivity 227 There are, in theory, two ways to obtain IPv6 connectivity to the 228 Internet. 230 o Native. In this case the ISP simply provides IPv6 on exactly the 231 same basis as IPv4 - it will appear at the ICP's border router(s), 232 which must then be configured in dual-stack mode to forward IPv6 233 packets in both directions. This is by far the better method. An 234 ICP should contact all its ISPs to verify when they will provide 235 native IPv6 support, whether this has any financial implications, 236 and whether the same service level agreement will apply as for 237 IPv4. Any ISP that has no definite plan to offer native IPv6 238 service should be avoided. 239 o Tunnel. It is possible to configure an IPv6-in-IPv4 tunnel to a 240 remote ISP that offers such a service. A dual-stack router in the 241 ICP's network will act as a tunnel end-point, or this function 242 could be included in the ICP's border router. 244 A tunnel is a reasonable way to obtain IPv6 connectivity for 245 initial testing and skills acquisition. However, it introduces an 246 inevitable extra latency compared to native IPv6, giving users a 247 noticeably worse response time for complex web pages. It is also 248 likely to limit the IPv6 MTU size. In normal circumstances, 249 native IPv6 will provide an MTU size of at least 1500 bytes, but 250 it will almost inevitably be less for a tunnel, possibly as low as 251 1280 bytes (the minimum MTU allowed for IPv6). Apart from the 252 resulting loss of efficiency, there are cases in which Path MTU 253 Discovery fails, therefore IPv6 fragmentation fails, and in this 254 case the lower tunnel MTU will actually cause connectivity 255 failures for customers. 257 For these reasons, ICPs are strongly recommended to obtain native 258 IPv6 service before attempting to offer a production-quality 259 service to their users. 261 5. IPv6 Infrastructure 263 5.1. Address and subnet assignment 265 An ICP must first decide whether to apply for its own Provider 266 Independent (PI) address prefix for IPv6. The default is to obtain a 267 Provider Aggregated (PA) prefix from each of its ISPs, and operate 268 them in parallel. Both solutions are viable in IPv6. However, 269 scaling properties of the wide area routing system (BGP4) limit the 270 routing of PI prefixes, so only large content providers can justify 271 the bother and expense of obtaining a PI prefix and convincing their 272 ISPs to route it. Millions of enterprise networks, including smaller 273 content providers, will use PA prefixes. In this case, a change of 274 ISP would necessitate a change of the corresponding PA prefix, using 275 the procedure outlined in [RFC4192]. 277 An ICP that has multiple connections via multiple ISPs will have 278 multiple PA prefixes. This results in multiple PA-based addresses 279 for the servers, or for load balancers if they are in use. 281 An ICP may also choose to operate a Unique Local Address prefix 282 [RFC4193] for internal traffic only, as described in [RFC4864]. 284 Depending on its projected future size, an ICP might choose to obtain 285 /48 PI or PA prefixes (allowing 16 bits of subnet address) or longer 286 PA prefixes, e.g. /56 (allowing 8 bits of subnet address). Clearly 287 the choice of /48 is more future-proof. Advice on the numbering of 288 subnets may be found in [RFC5375]. 290 Since IPv6 provides for operating multiple prefixes simultaneously, 291 it is important to check that all relevant tools, such as address 292 management packages, can deal with this. In particular, the need to 293 allow for multiple PA prefixes with IPv6, and the possible need to 294 renumber, means that using manually assigned static addresses for 295 servers is problematic [I-D.carpenter-6renum-static-problem]. 297 Theoretically, it would be possible to operate an ICP's IPv6 network 298 using only Stateless Address Autoconfiguration [RFC4862]. In 299 practice, an ICP of reasonable size will probably choose to operate 300 DHCPv6 [RFC3315] and use it to support stateful and/or on-demand 301 address assignment. 303 5.2. Routing 305 In a dual stack network, IPv4 and IPv6 routing protocols operate 306 quite independently and in parallel. The common routing protocols 307 all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS 308 [RFC5308], and even RIPng [RFC2080] [RFC2081]. For trained staff, 309 there should be no particular difficulty in deploying IPv6 routing 310 without disturbance to IPv4 services. 312 The performance impact of dual stack routing needs to be evaluated. 313 In particular, what performance does the router vendor claim for 314 IPv6? If the performance is significantly inferior compared to IPv4, 315 will this be an operational problem? To answer this question, the 316 ICP will need a projected model for the amount of IPv6 traffic 317 expected initially, and its likely rate of increase. [[Note: further 318 input from the WG is needed on this point.]] 320 If a site operates multiple PA prefixes as mentioned in Section 5.1, 321 complexities may appear in routing configuration. In particular, 322 source-based routing rules may be needed to ensure that outgoing 323 packets are routed to the appropriate border router and ISP link. 324 Normally, a packet sourced from an address assigned by ISP X should 325 not be sent via ISP Y, to avoid ingress filtering by Y [RFC2827] 326 [RFC3704]. Additional considerations may be found in 327 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. 329 Each IPv6 subnet normally has a /64 prefix, leaving another 64 bits 330 for the interface identifiers of individual hosts. In contrast, a 331 typical IPv4 subnet will have no more than 8 bits for the host 332 identifier, thus limiting the subnet to 256 or fewer hosts. A dual 333 stack design will typically use the same subnet topology for IPv4 and 334 IPv6, and therefore the same router topology. This means that the 335 limited subnet size of IPv4 will be imposed on IPv6. It would be 336 theoretically possible to avoid this limitation by implementing a 337 different subnet and router topology for IPv6, for example by 338 ingenious use of VLANs. This is not advisable, as it would result in 339 extremely complex fault diagnosis when something went wrong. 341 5.3. DNS 343 This is largely a case of "just do it." Each externally visible host 344 (or virtual host) that has an A record for its IPv4 address needs an 345 AAAA record [RFC3596] for its IPv6 address, and a reverse entry if 346 applicable. One important detail is that some clients (especially 347 Windows XP) can only resolve DNS names via IPv4, even if they can use 348 IPv6 for application traffic. It is therefore advisable for all DNS 349 servers to respond to queries via both IPv4 and IPv6. 351 6. Load Balancers 353 It is to be expected that IPv6 traffic will initially be low, i.e. a 354 small percentage of IPv4 traffic. For this reason, updating load 355 balancers to fully support IPv6 can perhaps be delayed; however, such 356 an update needs to be planned in anticipation of significant growth 357 over a period of several years. The same would apply to TLS or HTTP 358 proxies used for load balancing purposes. It is important to obtain 359 appropriate assurances from vendors about their IPv6 support, 360 including performance aspects (as discussed for routers in 361 Section 5.2). 363 7. Proxies 365 An HTTP proxy [RFC2616] can readily be configured to handle incoming 366 connections over IPv6 and to proxy them to a server over IPv4. 367 Therefore, a single proxy can be used as the first step in an 368 outside-in strategy, as shown in the following diagram: 370 ___________________________________________ 371 ( ) 372 ( IPv6 Clients in the Internet ) 373 (___________________________________________) 374 | 375 ------------- 376 | Ingress | 377 | router | 378 ------------- 379 ____________|_____________ 380 | 381 ------------- 382 | IPv6 stack| 383 |-----------| 384 | HTTP proxy| 385 |-----------| 386 | IPv4 stack| 387 ------------- 388 ____________|_____________ 389 | 390 ------------- 391 | IPv4 stack| 392 |-----------| 393 | HTTP | 394 | server | 395 ------------- 397 In this case, the AAAA record for the service would provide the IPv6 398 address of the proxy. This approach will work for any HTTP or HTTPS 399 applications that operate successfully via a proxy, as long as IPv6 400 load remains low. 402 8. Servers 404 8.1. Network Stack 406 The TCP/IP network stacks in popular operating systems have supported 407 IPv6 for many years. In most cases, it is sufficient to enable IPv6 408 and possibly DHCPv6; the rest will follow. Servers inside an ICP 409 network will not need to support any transition technologies beyond a 410 simple dual stack, with a possible exception for 6to4 mitigation 411 noted below in Section 9. 413 8.2. Application Layer 415 Basic HTTP servers have been able to handle an IPv6-enabled network 416 stack for some years, so at the most it will be necessary to update 417 to a more recent software version. The same is true of generic 418 applications such as email protocols. No general statement can be 419 made about other applications, especially proprietary ones, so each 420 ASP will need to make its own determination. 422 One important recommendation here is that all applications should use 423 domain names, which are IP-version-independent, rather than IP 424 addresses. Applications based on middlware platforms which have 425 uniform support for IPv4 and IPv6, for example Java, may be able to 426 support both IPv4 and IPv6 naturally without additional work. 428 A specific issue for HTTP-based services is that IP address-based 429 cookie authentication schemes will need to deal with dual-stack 430 clients. Servers might create a cookie for an IPv4 connection or an 431 IPv6 connection, depending on the setup at the client site and on the 432 whims of the client operating system. There is no guarentee that a 433 given client will consistently use the same address family, 434 especially when accessing a collection of sites rather than a single 435 site. If the client is using privacy addresses [RFC4941], the IPv6 436 address (but not its /64 prefix) might change quite frequently. Any 437 cookie mechanism based on 32-bit IPv4 addresses will need significant 438 remodelling. 440 Generic considerations on application transition are discussed in 441 [RFC4038], but many of them will not apply to the dual-stack ICP 442 scenario. An ICP that creates and maintains its own applications 443 will need to review them for any dependency on IPv4. 445 8.3. Geolocation 447 As time goes on, it is to be assumed that geolocation methods and 448 databases will be updated to fully support IPv6 prefixes. There is 449 no reason they will be more or less accurate in the long term than 450 those available for IPv4. However, we can expect many more clients 451 to be mobile as time goes on, so geolocation based on IP addresses 452 alone may become problematic. Initially, at least, ICPs may observe 453 some weakness in geolocation for IPv6 clients. 455 9. Coping with Transition Technologies 457 As mentioned above, an ICP should obtain native IPv6 connectivity 458 from its ISPs. In this way, the ICP can avoid most of the 459 complexities of the numerous IPv4-to-IPv6 transition technologies 460 that have been developed; they are all second-best solutions. 461 However, some clients are sure to be using such technologies. An ICP 462 needs to be aware of the operational issues this may cause and how to 463 deal with them. 465 In some cases outside the ICP's control, clients might reach a 466 content server via a network-layer translator from IPv6 to IPv4. 467 ICPs who are offering a dual stack service and providing both A and 468 AAAA records, as recommended in this document, should not normally 469 receive traffic from NAT64 translators [RFC6146]. Exceptionally, 470 however, such traffic could arrive via IPv4 from an IPv6-only client 471 whose DNS resolver failed to receive the ICP's AAAA record for some 472 reason. Such traffic would be indistinguishable from regular IPv4- 473 via-NAT traffic. 475 Alternatively, ICPs who are offering a dual stack service might 476 exceptionally receive IPv6 traffic translated from an IPv4-only 477 client that somehow failed to receive the ICP's A record. An ICP 478 could also receive IPv6 traffic with translated prefixes [RFC6296]. 479 These two cases would only be an issue if the ICP was offering any 480 service that depends on the assumption of end-to-end IPv6 address 481 transparency. 483 In other cases, also outside the ICP's control, IPv6 clients may 484 reach the IPv6 Internet via some form of IPv6-in-IPv4 tunnel. In 485 this case a variety of problems can arise, the most acute of which 486 affect clients connected using the Anycast 6to4 solution [RFC3068]. 487 Advice on how ICPs may mitigate these 6to4 problems is given in 488 Section 4.5. of [RFC6343]. For the benefit of all tunnelled clients, 489 it is essential to verify that Path MTU Discovery works correctly 490 (i.e., the relevant ICMPv6 packets are not blocked) and that the 491 server-side TCP implementation correctly supports the Maximum Segment 492 Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic. 494 Some ICPs have implemented an interim solution to mitigate transition 495 problems by limiting the visibility of their AAAA records to users 496 with validated IPv6 connectivity 497 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]. 499 Another approach taken by some ICPs is to offer IPv6-only support via 500 a specific DNS name, e.g., ipv6.example.com, if the primary service 501 is www.example.com. In this case ipv6.example.com would have an AAAA 502 record only. This has some value for testing purposes, but is 503 otherwise only of interest to hobbyist users willing to type in 504 special URLs. 506 There is little an ICP can do to deal with client-side or remote ISP 507 deficiencies in IPv6 support, but it is hoped that the "happy 508 eyeballs" [I-D.ietf-v6ops-happy-eyeballs] approach will improve the 509 ability for clients to deal with such problems. 511 10. Content Delivery Networks 513 DNS-based techniques for diverting users to Content Delivery Network 514 (CDN) points of presence (POPs) will work for IPv6, if AAAA records 515 are provided as well as A records. In general the CDN should follow 516 the recommendations of this document, especially by operating a full 517 dual stack service at each POP. Additionally, each POP will need to 518 handle IPv6 routing exactly like IPv4, for example running BGP4+ 519 [RFC4760] if appropriate. 521 Note that if an ICP supports IPv6 but its CDN does not, its clients 522 will continue to use IPv4 and any IPv6-only clients will have to use 523 a transition solution of some kind. This is not a desirable 524 situation, since the ICP's work to support IPv6 will be wasted. The 525 converse is not true: if the CDN supports IPv6 but the ICP does not, 526 dual-stack and IPv6-only clients will obtain IPv6 access. 528 An ICP might face a complex situation, if its CDN provider supports 529 IPv6 at some POPs but not at others. IPv6-only clients could only be 530 diverted to a POP supporting IPv6. There are also scenarios where a 531 dual-stack client would be diverted to a mixture of IPv4 and IPv6 532 POPs for different URLs, according to the A and AAAA records provided 533 and the availability of optimisations such as "happy eyeballs." 534 These complications do not affect the viability of relying on a dual- 535 stack CDN, however. 537 The CDN itself faces related complexity: "As IPv6 rolls out, it's 538 going to roll out in pockets, and that's going to make the routing 539 around congestion points that much more important but also that much 540 harder," stated John Summers of Akamai in 2010. 542 11. Business Partners 544 As noted earlier, it is in an ICP's or ASP's best interests that 545 their users have direct IPv6 connectivity, rather than indirect IPv4 546 connectivity via double NAT. If the ICP or ASP has a direct business 547 relationship with some of their clients, or with the networks that 548 connect them to their clients, they are advised to coordinate with 549 those partners to ensure that they have a plan to enable IPv6. They 550 should also verify and test that there is first-class IPv6 551 connectivity end-to-end between the networks concerned. This is 552 especially true for implementations that require IPv6 support in 553 specialized programs or systems in order for the IPv6 support on the 554 ICP/ASP side to be useful. 556 12. Operations and Management 558 There is no doubt that, initially, IPv6 deployment will have 559 operational impact, as well as requiring education and training as 560 mentioned in Section 3. Staff will have to update network elements 561 such as routers, update configurations, provide information to end 562 users, and diagnose new problems. However, for an enterprise 563 network, there is plenty of experience, e.g. on numerous university 564 campuses, showing that dual stack operation is no harder than IPv4- 565 only in the steady state. 567 Whatever management, monitoring and logging is performed for IPv4 is 568 also needed for IPv6. Therefore, all products and tools used for 569 these purposes must be updated to fully support IPv6. Note that 570 since an IPv6 network may operate with more than one IPv6 prefix and 571 therefore more than one address per host, the tools must deal with 572 this as a normal situation. This includes any address management 573 tool in use (see Section 5.1) as well as tools used for creating DHCP 574 and DNS configurations. There is significant overlap here with the 575 tools involved in site renumbering [I-D.jiang-6renum-enterprise]. 577 As far as possible, however, mutual dependency between IPv4 and IPv6 578 operations should be avoided. A failure of one should not cause a 579 failure of the other. One precaution to avoid this would be for 580 back-end systems such as network management databases to be dual 581 stacked as soon as convenient. It should also be possible to use 582 IPv4 connectivity to repair IPv6 configurations, and vice versa. 584 Dual stack, while necessary, does have management scaling and 585 overhead considerations. As noted earlier, the long term goal is to 586 move to single-stack IPv6, when the network and its customers can 587 support this. This is an additional reason why mutual dependency 588 between the address families should be avoided in the management 589 system in particular; a hidden dependency on IPv4 that had been 590 forgotten for many years would be highly inconvenient. 592 13. Security Considerations 594 Essentially every threat that exists for IPv4 exists or will exist 595 for IPv6. Therefore, it is essential to update firewalls, intrusion 596 detection systems, denial of service precautions, and security 597 auditing technology to fully support IPv6. Otherwise, IPv6 will 598 become an attractive target for attackers. 600 When multiple PA prefixes are in use as mentioned in Section 5.1, 601 firewall rules must allow for all valid prefixes, and must be set up 602 to work as intended even if packets are sent via one ISP but return 603 packets arrive via another. 605 Performance aspects of dual stack firewalls must be considered (as 606 discussed for routers in Section 5.2). 608 In a dual stack operation, there may be a risk of cross-contamination 609 between the two protocols. For example, a successful IPv4-based 610 denial of service attack might also deplete resources needed by the 611 IPv6 service, or vice versa. This risk strengthens the argument that 612 IPv6 security must be up to the same level as IPv4. 614 A general overview of techniques to protect an IPv6 network against 615 external attack is given in [RFC4864]. Assuming an ICP has native 616 IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4 617 tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this 618 kind should be blocked except for the case noted in Section 4.5 of 619 [RFC6343]. ICMPv6 traffic should only be blocked in accordance with 620 [RFC4890]; in particular, Packet Too Big messages, which are 621 essential for PMTU discovery, must not be blocked. 623 Scanning attacks to discover the existence of hosts are much less 624 likely to succeed for IPv6 than for IPv4 [RFC5157]. However, this is 625 only true if IPv6 hosts are configured with interface identifiers 626 that are hard to guess; for example, it is not advisable to manually 627 configure servers with static interface identifiers starting from 628 "1". 630 Transport Layer Security version 1.2 [RFC5246] and its predecessors 631 work correctly with TCP over IPv6, meaning that HTTPS-based security 632 solutions are immediately applicable. The same should apply to any 633 other transport-layer or application-layer security techniques. 635 If an ASP uses IPsec [RFC4301] and IKE [RFC5996] in any way to secure 636 connections with clients, these too are fully applicable to IPv6, but 637 only if the software stack at each end has been appropriately 638 updated. 640 14. IANA Considerations 642 This document requests no action by IANA. 644 15. Acknowledgements 646 Valuable contributions were made by Erik Kline. Useful comments were 647 received from Tassos Chatzithomaoglou, Wesley George, Victor 648 Kuarsingh, Bing Liu, John Mann, and other participants in the V6OPS 649 working group. 651 This document was produced using the xml2rfc tool [RFC2629]. 653 16. Change log [RFC Editor: Please remove] 655 draft-carpenter-v6ops-icp-guidance-03: additional WG comments, 2012- 656 02-23. 658 draft-carpenter-v6ops-icp-guidance-02: additional WG comments, 2012- 659 01-07. 661 draft-carpenter-v6ops-icp-guidance-01: multiple clarifications after 662 WG comments, 2011-12-06. 664 draft-carpenter-v6ops-icp-guidance-00: original version, 2011-10-22. 666 17. References 668 17.1. Normative References 670 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 671 January 1997. 673 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 674 (IPv6) Specification", RFC 2460, December 1998. 676 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 677 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 678 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 680 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 681 Defeating Denial of Service Attacks which employ IP Source 682 Address Spoofing", BCP 38, RFC 2827, May 2000. 684 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 685 and M. Carney, "Dynamic Host Configuration Protocol for 686 IPv6 (DHCPv6)", RFC 3315, July 2003. 688 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 689 "DNS Extensions to Support IP Version 6", RFC 3596, 690 October 2003. 692 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 693 Networks", BCP 84, RFC 3704, March 2004. 695 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 696 Addresses", RFC 4193, October 2005. 698 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 699 Internet Protocol", RFC 4301, December 2005. 701 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 702 "Multiprotocol Extensions for BGP-4", RFC 4760, 703 January 2007. 705 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 706 Address Autoconfiguration", RFC 4862, September 2007. 708 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 709 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 711 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 712 October 2008. 714 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 715 for IPv6", RFC 5340, July 2008. 717 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 718 "Internet Key Exchange Protocol Version 2 (IKEv2)", 719 RFC 5996, September 2010. 721 17.2. Informative References 723 [I-D.carpenter-6renum-static-problem] 724 Carpenter, B. and S. Jiang, "Problem Statement for 725 Renumbering IPv6 Hosts with Static Addresses", 726 draft-carpenter-6renum-static-problem-01 (work in 727 progress), December 2011. 729 [I-D.ietf-v6ops-happy-eyeballs] 730 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 731 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07 732 (work in progress), December 2011. 734 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 735 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 736 Wing, "IPv6 Multihoming without Network Address 737 Translation", 738 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 739 in progress), February 2012. 741 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications] 742 Livingood, J., "Considerations for Transitioning Content 743 to IPv6", 744 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09 745 (work in progress), February 2012. 747 [I-D.jiang-6renum-enterprise] 748 Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 749 Network Renumbering Scenarios and Guidelines", 750 draft-jiang-6renum-enterprise-02 (work in progress), 751 December 2011. 753 [RFC2081] Malkin, G., "RIPng Protocol Applicability Statement", 754 RFC 2081, January 1997. 756 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 757 June 1999. 759 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 760 RFC 2923, September 2000. 762 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 763 RFC 3068, June 2001. 765 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 766 Castro, "Application Aspects of IPv6 Transition", 767 RFC 4038, March 2005. 769 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 770 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 771 September 2005. 773 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 774 E. Klein, "Local Network Protection for IPv6", RFC 4864, 775 May 2007. 777 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 778 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 780 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 781 Extensions for Stateless Address Autoconfiguration in 782 IPv6", RFC 4941, September 2007. 784 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 785 RFC 5157, March 2008. 787 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 788 and C. Hahn, "IPv6 Unicast Address Assignment 789 Considerations", RFC 5375, December 2008. 791 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 792 NAT64: Network Address and Protocol Translation from IPv6 793 Clients to IPv4 Servers", RFC 6146, April 2011. 795 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 796 Transition Mechanisms during IPv6 Deployment", RFC 6180, 797 May 2011. 799 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 800 Translation", RFC 6296, June 2011. 802 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 803 RFC 6343, August 2011. 805 Authors' Addresses 807 Brian Carpenter 808 Department of Computer Science 809 University of Auckland 810 PB 92019 811 Auckland, 1142 812 New Zealand 814 Email: brian.e.carpenter@gmail.com 816 Sheng Jiang 817 Huawei Technologies Co., Ltd 818 Q14, Huawei Campus 819 No.156 Beiqing Road 820 Hai-Dian District, Beijing 100095 821 P.R. China 823 Email: jiangsheng@huawei.com