idnits 2.17.1 draft-ietf-v6ops-icp-guidance-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 : ---------------------------------------------------------------------------- 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 (July 11, 2012) is 4307 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) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-6204bis-09 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 == Outdated reference: A later version (-01) exists of draft-matthews-v6ops-design-guidelines-00 -- 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) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: January 12, 2013 Huawei Technologies Co., Ltd 6 July 11, 2012 8 IPv6 Guidance for Internet Content and Application Service Providers 9 draft-ietf-v6ops-icp-guidance-02 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 hosting providers, or to any enterprise network 17 preparing for IPv6 users. 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 January 12, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. General Strategy . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Education and Skills . . . . . . . . . . . . . . . . . . . . . 5 56 4. Arranging IPv6 Connectivity . . . . . . . . . . . . . . . . . 6 57 5. IPv6 Infrastructure . . . . . . . . . . . . . . . . . . . . . 7 58 5.1. Address and subnet assignment . . . . . . . . . . . . . . 7 59 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1. Network Stack . . . . . . . . . . . . . . . . . . . . . . 10 65 8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11 66 8.3. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 11 67 9. Coping with Transition Technologies . . . . . . . . . . . . . 11 68 10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 13 69 11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 13 70 12. Operations and Management . . . . . . . . . . . . . . . . . . 14 71 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 74 16. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 16 75 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 17.1. Normative References . . . . . . . . . . . . . . . . . . . 17 77 17.2. Informative References . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 The deployment of IPv6 [RFC2460] is now in progress, and users with 83 no IPv4 access are likely to appear in increasing numbers in the 84 coming years. Any provider of content or application services over 85 the Internet will need to arrange for IPv6 access or else risk losing 86 large numbers of potential users. In this document, we refer to the 87 users of content or application services as "customers" to clarify 88 the part they play, but this is not intended to limit the scope to 89 commercial sites. 91 The time for action is now, while the number of IPv6-only customers 92 is small, so that appropriate skills, software and equipment can be 93 acquired in good time to scale up the IPv6 service as demand 94 increases. An additional advantage of early support for IPv6 95 customers is that it will reduce the number of customers connecting 96 later via IPv4 "extension" solutions such as double NAT, which will 97 otherwise degrade the user experience. 99 Nevertheless, it is important that the introduction of IPv6 service 100 should not make service for IPv4 customers worse. In some 101 circumstances, technologies intended to assist in the transition from 102 IPv4 to IPv6 are known to have negative effects on the user 103 experience. A deployment strategy for IPv6 must avoid these effects 104 as much as possible. 106 The purpose of this document is to provide guidance and suggestions 107 for Internet Content Providers (ICPs) and Application Service 108 Providers (ASPs) who wish to offer their services to both IPv6 and 109 IPv4 customers, but who are currently supporting only IPv4. For 110 simplicity, the term ICP is mainly used in the body of this document, 111 but the guidance also applies to ASPs. Any hosting provider whose 112 customers include ICPs or ASPs is also concerned. Many of the points 113 in this document will also apply to enterprise networks that do not 114 classify themselves as ICPs. Any enterprise or department that runs 115 at least one externally accessible server, such as an HTTP server, 116 may also be concerned. Although specific managerial and technical 117 approaches are described, this is not a rule book; each operator will 118 need to make its own plan, tailored to its own services and 119 customers. 121 2. General Strategy 123 The most importance advice here is to actually have a general 124 strategy. Adding support for a second network layer protocol is a 125 new experience for most modern organisations, and it cannot be done 126 casually on a unplanned basis. Even if it is impossible to write a 127 precisely dated plan, the intended steps in the process need to be 128 defined well in advance. There is no single blueprint for this. The 129 rest of this document is meant to provide a set of topics to be taken 130 into account in defining the strategy. Other documents about IPv6 131 deployment, such as [I-D.matthews-v6ops-design-guidelines], should be 132 consulted as well. 134 In determining the urgency of this strategy, it should be noted that 135 the central IPv4 registry (IANA) ran out of spare blocks of IPv4 136 addresses in February 2011 and the various regional registries are 137 expected to exhaust their reserves over the next one to two years. 138 After this, Internet Service Providers (ISPs) will run out at dates 139 determined by their own customer base. No precise date can be given 140 for when IPv6-only customers will appear in commercially significant 141 numbers, but - particularly in the case of mobile users - it may be 142 quite soon. Complacency about this is therefore not an option for 143 any ICP that wishes to grow its customer base over the coming years. 145 The most common strategy for an ICP is to provide dual stack services 146 - both IPv4 and IPv6 on an equal basis - to cover both existing and 147 future customers. This is the recommended strategy in [RFC6180] for 148 straightforward situations. Some ICPs who already have satisfactory 149 operational experience with IPv6 might consider an IPv6-only 150 strategy, with IPv4 clients being supported by translation or proxy 151 in front of their IPv6 content servers. However, the present 152 document is addressed to ICPs without IPv6 experience, who are likely 153 to prefer the dual stack model to build on their existing IPv4 154 service. 156 Within the dual stack model, two approaches could be adopted, 157 sometimes referred to as "outside in" and "inside out": 159 o Outside in: start by providing external users with an IPv6 public 160 access to your services, for example by running a reverse proxy 161 that handles IPv6 customers (see Section 7 for details). 162 Progressively enable IPv6 internally. 163 o Inside out: start by enabling internal networking infrastructure, 164 hosts, and applications to support IPv6. Progressively reveal 165 IPv6 access to external customers. 167 Which of these approaches to adopt depends on the precise 168 circumstances of the ICP concerned. "Outside in" has the benefit of 169 giving interested customers IPv6 access at an early stage, and 170 thereby gaining precious operational experience, before meticulously 171 updating every piece of equipment and software. For example, if some 172 back-office system, that is never exposed to users, only supports 173 IPv4, it will not cause delay. "Inside out" has the benefit of 174 completing the implementation of IPv6 as a single project. Any ICP 175 could choose this approach, but it might be most appropriate for a 176 small ICP without complex back-end systems. 178 A point that must be considered in the strategy is that some 179 customers will remain IPv4-only for many years, others will have both 180 IPv4 and IPv6 access, and yet others will have only IPv6. 181 Additionally, mobile customers may find themselves switching between 182 IPv4 and IPv6 access as they travel, even within a single session. 183 Services and applications must be able to deal with this, just as 184 easily as they deal today with a user whose IPv4 address changes (see 185 the discussion of cookies in Section 8.2). 187 Neverthless, the end goal is to have a network that does not need 188 major changes when at some point in the future it becomes possible to 189 transition to IPv6-only, even if only for some parts of the network. 190 That is, the IPv6 deployment should be designed in such a way as to 191 more or less assume that IPv4 is absent, so the network will function 192 seamlessly when it is indeed no longer there. 194 An important step in the strategy is to determine from hardware and 195 software suppliers details of their planned dates for providing 196 sufficient IPv6 support, with performance equivalent to IPv4, in 197 their products and services. Relevant specifications such as 198 [RFC6434] [I-D.ietf-v6ops-6204bis] should be used. Even if complete 199 information cannot be obtained, it is essential to determine which 200 components are on the critical path during successive phases of 201 deployment. This information will make it possible to draw up a 202 logical sequence of events and identify any components that may cause 203 holdups. 205 3. Education and Skills 207 Some older staff may have experience of running multiprotocol 208 networks, which were common twenty years ago before the dominance of 209 IPv4. However, IPv6 will be new to them, and also to younger staff 210 brought up on TCP/IP. It is not enough to have one "IPv6 expert" in 211 a team. On the contrary, everybody who knows about IPv4 needs to 212 know about IPv6, from network architect to help desk responder. 213 Therefore, an early and essential part of the strategy must be 214 education, including practical training, so that all staff acquire a 215 general understanding of IPv6, how it affects basic features such as 216 the DNS, and the relevant practical skills. To take a trivial 217 example, any staff used to dotted-decimal IPv4 addresses need to 218 become familiar with the colon-hexadecimal format used for IPv6. 220 There is an anecdote of one IPv6 deployment in which prefixes 221 including the letters A to F were avoided by design, to avoid 222 confusing sysadmins unfamiliar with hexadecimal notation. This is 223 not a desirable result. There is another anecdote of a help desk 224 responder telling a customer to "disable one-Pv6" in order to solve a 225 problem. It should be a goal to avoid having untrained staff who 226 don't understand hexadecimal or who can't even spell "IPv6". 228 It is very useful to have a small laboratory network available for 229 training and self-training in IPv6, where staff may experiment and 230 make mistakes without disturbing the operational IPv4 service. This 231 lab should run both IPv4 and IPv6, to gain experience with a dual- 232 stack environment and new features such as having multiple addresses 233 per interface, and addresses with lifetimes and deprecation. 235 A final remark about training is that it should not be given too 236 soon, or it will be forgotten. Training has a definite need to be 237 done "just in time" in order to properly "stick." Training, lab 238 experience, and actual deployment should therefore follow each other 239 immediately. If possible, training should even be combined with 240 actual operational experience. 242 4. Arranging IPv6 Connectivity 244 There are, in theory, two ways to obtain IPv6 connectivity to the 245 Internet. 247 o Native. In this case the ISP simply provides IPv6 on exactly the 248 same basis as IPv4 - it will appear at the ICP's border router(s), 249 which must then be configured in dual-stack mode to forward IPv6 250 packets in both directions. This is by far the better method. An 251 ICP should contact all its ISPs to verify when they will provide 252 native IPv6 support, whether this has any financial implications, 253 and whether the same service level agreement will apply as for 254 IPv4. Any ISP that has no definite plan to offer native IPv6 255 service should be avoided. 256 o Tunnel. It is possible to configure an IPv6-in-IPv4 tunnel to a 257 remote ISP that offers such a service. A dual-stack router in the 258 ICP's network will act as a tunnel end-point, or this function 259 could be included in the ICP's border router. 261 A tunnel is a reasonable way to obtain IPv6 connectivity for 262 initial testing and skills acquisition. However, it introduces an 263 inevitable extra latency compared to native IPv6, giving users a 264 noticeably worse response time for complex web pages. A tunnel 265 may become a performance bottleneck (especially if offered as a 266 free service) or a target for malicious attack. It is also likely 267 to limit the IPv6 MTU size. In normal circumstances, native IPv6 268 will provide an MTU size of at least 1500 bytes, but it will 269 almost inevitably be less for a tunnel, possibly as low as 1280 270 bytes (the minimum MTU allowed for IPv6). Apart from the 271 resulting loss of efficiency, there are cases in which Path MTU 272 Discovery fails, therefore IPv6 fragmentation fails, and in this 273 case the lower tunnel MTU will actually cause connectivity 274 failures for customers. 276 For these reasons, ICPs are strongly recommended to obtain native 277 IPv6 service before attempting to offer a production-quality 278 service to their users. 280 5. IPv6 Infrastructure 282 5.1. Address and subnet assignment 284 An ICP must first decide whether to apply for its own Provider 285 Independent (PI) address prefix for IPv6. The default is to obtain a 286 Provider Aggregated (PA) prefix from each of its ISPs, and operate 287 them in parallel. Both solutions are viable in IPv6. However, 288 scaling properties of the wide area routing system (BGP4) limit the 289 routing of PI prefixes, so only large content providers can justify 290 the bother and expense of obtaining a PI prefix and convincing their 291 ISPs to route it. Millions of enterprise networks, including smaller 292 content providers, will use PA prefixes. In this case, a change of 293 ISP would necessitate a change of the corresponding PA prefix, using 294 the procedure outlined in [RFC4192]. 296 An ICP that has multiple connections via multiple ISPs will have 297 multiple PA prefixes. This results in multiple PA-based addresses 298 for the servers, or for load balancers if they are in use. 300 An ICP may also choose to operate a Unique Local Address prefix 301 [RFC4193] for internal traffic only, as described in [RFC4864]. 303 Depending on its projected future size, an ICP might choose to obtain 304 /48 PI or PA prefixes (allowing 16 bits of subnet address) or longer 305 PA prefixes, e.g. /56 (allowing 8 bits of subnet address). Clearly 306 the choice of /48 is more future-proof. Advice on the numbering of 307 subnets may be found in [RFC5375]. 309 Since IPv6 provides for operating multiple prefixes simultaneously, 310 it is important to check that all relevant tools, such as address 311 management packages, can deal with this. In particular, the need to 312 allow for multiple PA prefixes with IPv6, and the possible need to 313 renumber, means that using manually assigned static addresses for 314 servers is problematic [I-D.carpenter-6renum-static-problem]. 316 Theoretically, it would be possible to operate an ICP's IPv6 network 317 using only Stateless Address Autoconfiguration [RFC4862], and Dynamic 318 DNS [RFC3007] or Multicast DNS [RFC4795]. In practice, an ICP of 319 reasonable size will probably choose to operate DHCPv6 [RFC3315] with 320 standard DNS, and use it to support stateful and/or on-demand address 321 assignment. 323 5.2. Routing 325 In a dual stack network, most IPv4 and IPv6 interior routing 326 protocols operate quite independently and in parallel. The common 327 routing protocols all support IPv6, such as OSPFv3 [RFC5340], IS-IS 328 [RFC5308], and even RIPng [RFC2080] [RFC2081]. It is worth noting 329 that whereas OSPF and RIP differ significantly between IPv4 and IPv6, 330 IS-IS has the advantage of handling them both in a single instance of 331 the protocol, with the potential for operational simplification in 332 the long term. In any case, for trained staff, there should be no 333 particular difficulty in deploying IPv6 routing without disturbance 334 to IPv4 services. 336 The performance impact of dual stack routing needs to be evaluated. 337 In particular, what forwarding performance does the router vendor 338 claim for IPv6? If the forwarding performance is significantly 339 inferior compared to IPv4, will this be an operational problem? Is 340 extra memory or TCAM space needed to accommodate both IPv4 and IPv6 341 tables? To answer these questions, the ICP will need a projected 342 model for the amount of IPv6 traffic expected initially, and its 343 likely rate of increase. 345 If a site operates multiple PA prefixes as mentioned in Section 5.1, 346 complexities may appear in routing configuration. In particular, 347 source-based routing rules may be needed to ensure that outgoing 348 packets are routed to the appropriate border router and ISP link. 349 Normally, a packet sourced from an address assigned by ISP X should 350 not be sent via ISP Y, to avoid ingress filtering by Y [RFC2827] 351 [RFC3704]. Additional considerations may be found in 352 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. 354 Each IPv6 subnet that supports end hosts normally has a /64 prefix, 355 leaving another 64 bits for the interface identifiers of individual 356 hosts. In contrast, a typical IPv4 subnet will have no more than 8 357 bits for the host identifier, thus limiting the subnet to 256 or 358 fewer hosts. A dual stack design will typically use the same 359 physical or VLAN subnet topology for IPv4 and IPv6, and therefore the 360 same router topology. In other words the IPv4 and IPv6 topologies 361 are congruent. This means that the limited subnet size of IPv4 (such 362 as 256 hosts) will be imposed on IPv6, even though the IPv6 prefix 363 will allow many more hosts. It would be theoretically possible to 364 avoid this limitation by implementing a different physical or VLAN 365 subnet topology for IPv6. This is not advisable, as it would result 366 in extremely complex fault diagnosis when something went wrong. 368 5.3. DNS 370 This is largely a case of "just do it." Each externally visible host 371 (or virtual host) that has an A record for its IPv4 address needs an 372 AAAA record [RFC3596] for its IPv6 address, and a reverse entry if 373 applicable. One important detail is that some clients (especially 374 Windows XP) can only resolve DNS names via IPv4, even if they can use 375 IPv6 for application traffic. It is therefore advisable for all DNS 376 servers to respond to queries via both IPv4 and IPv6. 378 6. Load Balancers 380 Most available load balancers now support IPv6. However, it is 381 important to obtain appropriate assurances from vendors about their 382 IPv6 support, including performance aspects (as discussed for routers 383 in Section 5.2). The update needs to be planned in anticipation of 384 expected traffic growth. It is to be expected that IPv6 traffic will 385 initially be low, i.e., a small percentage of IPv4 traffic. For this 386 reason, it might be acceptable to have IPv6 traffic bypass load 387 balancing initially, by publishing an AAAA record for a specific 388 server instead of the load balancer. However, it would be more 389 straightforward to implement IPv6 load balancing immediately, which 390 would also provide support for IPv6 server fail-over. 392 The same would apply to TLS or HTTP proxies used for load balancing 393 purposes. 395 7. Proxies 397 An HTTP proxy [RFC2616] can readily be configured to handle incoming 398 connections over IPv6 and to proxy them to a server over IPv4. 399 Therefore, a single proxy can be used as the first step in an 400 outside-in strategy, as shown in the following diagram: 402 ___________________________________________ 403 ( ) 404 ( IPv6 Clients in the Internet ) 405 (___________________________________________) 406 | 407 ------------- 408 | Ingress | 409 | router | 410 ------------- 411 ____________|_____________ 412 | 413 ------------- 414 | IPv6 stack| 415 |-----------| 416 | HTTP proxy| 417 |-----------| 418 | IPv4 stack| 419 ------------- 420 ____________|_____________ 421 | 422 ------------- 423 | IPv4 stack| 424 |-----------| 425 | HTTP | 426 | server | 427 ------------- 429 In this case, the AAAA record for the service would provide the IPv6 430 address of the proxy. This approach will work for any HTTP or HTTPS 431 applications that operate successfully via a proxy, as long as IPv6 432 load remains low. 434 8. Servers 436 8.1. Network Stack 438 The TCP/IP network stacks in popular operating systems have supported 439 IPv6 for many years. In most cases, it is sufficient to enable IPv6 440 and possibly DHCPv6; the rest will follow. Servers inside an ICP 441 network will not need to support any transition technologies beyond a 442 simple dual stack, with a possible exception for 6to4 mitigation 443 noted below in Section 9. 445 8.2. Application Layer 447 Basic HTTP servers have been able to handle an IPv6-enabled network 448 stack for some years, so at the most it will be necessary to update 449 to a more recent software version. The same is true of generic 450 applications such as email protocols. No general statement can be 451 made about other applications, especially proprietary ones, so each 452 ASP will need to make its own determination. 454 One important recommendation here is that all applications should use 455 domain names, which are IP-version-independent, rather than IP 456 addresses. Applications based on middlware platforms which have 457 uniform support for IPv4 and IPv6, for example Java, may be able to 458 support both IPv4 and IPv6 naturally without additional work. 460 A specific issue for HTTP-based services is that IP address-based 461 cookie authentication schemes will need to deal with dual-stack 462 clients. Servers might create a cookie for an IPv4 connection or an 463 IPv6 connection, depending on the setup at the client site and on the 464 whims of the client operating system. There is no guarantee that a 465 given client will consistently use the same address family, 466 especially when accessing a collection of sites rather than a single 467 site. If the client is using privacy addresses [RFC4941], the IPv6 468 address (but usually not its /64 prefix) might change quite 469 frequently. Any cookie mechanism based on 32-bit IPv4 addresses will 470 need significant remodelling. 472 Generic considerations on application transition are discussed in 473 [RFC4038], but many of them will not apply to the dual-stack ICP 474 scenario. An ICP that creates and maintains its own applications 475 will need to review them for any dependency on IPv4. 477 8.3. Geolocation 479 Initially, ICPs may observe some weakness in geolocation for IPv6 480 clients. As time goes on, it is to be assumed that geolocation 481 methods and databases will be updated to fully support IPv6 prefixes. 482 There is no reason they will be more or less accurate in the long 483 term than those available for IPv4. However, we can expect many more 484 clients to be mobile as time goes on, so geolocation based on IP 485 addresses alone may in any case become problematic. 487 9. Coping with Transition Technologies 489 As mentioned above, an ICP should obtain native IPv6 connectivity 490 from its ISPs. In this way, the ICP can avoid most of the 491 complexities of the numerous IPv4-to-IPv6 transition technologies 492 that have been developed; they are all second-best solutions. 493 However, some clients are sure to be using such technologies. An ICP 494 needs to be aware of the operational issues this may cause and how to 495 deal with them. 497 In some cases outside the ICP's control, clients might reach a 498 content server via a network-layer translator from IPv6 to IPv4. 499 ICPs who are offering a dual stack service and providing both A and 500 AAAA records, as recommended in this document, should not normally 501 receive traffic from NAT64 translators [RFC6146]. Exceptionally, 502 however, such traffic could arrive via IPv4 from an IPv6-only client 503 whose DNS resolver failed to receive the ICP's AAAA record for some 504 reason. Such traffic would be indistinguishable from regular IPv4- 505 via-NAT traffic. 507 Alternatively, ICPs who are offering a dual stack service might 508 exceptionally receive IPv6 traffic translated from an IPv4-only 509 client that somehow failed to receive the ICP's A record. An ICP 510 could also receive IPv6 traffic with translated prefixes [RFC6296]. 511 These two cases would only be an issue if the ICP was offering any 512 service that depends on the assumption of end-to-end IPv6 address 513 transparency. 515 In other cases, also outside the ICP's control, IPv6 clients may 516 reach the IPv6 Internet via some form of IPv6-in-IPv4 tunnel. In 517 this case a variety of problems can arise, the most acute of which 518 affect clients connected using the Anycast 6to4 solution [RFC3068]. 519 Advice on how ICPs may mitigate these 6to4 problems is given in 520 Section 4.5. of [RFC6343]. For the benefit of all tunnelled clients, 521 it is essential to verify that Path MTU Discovery works correctly 522 (i.e., the relevant ICMPv6 packets are not blocked) and that the 523 server-side TCP implementation correctly supports the Maximum Segment 524 Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic. 526 Some ICPs have implemented an interim solution to mitigate transition 527 problems by limiting the visibility of their AAAA records to users 528 with validated IPv6 connectivity [RFC6589] (known as "DNS 529 whitelisting"). At the time of this writing, this solution seems to 530 be passing out of use, being replaced by "DNS blacklisting" of 531 customer sites known to have problems with IPv6 connectivity. 532 Neither of these solutions is appropriate in the long term. 534 Another approach taken by some ICPs is to offer IPv6-only support via 535 a specific DNS name, e.g., ipv6.example.com, if the primary service 536 is www.example.com. In this case ipv6.example.com would have an AAAA 537 record only. This has some value for testing purposes, but is 538 otherwise only of interest to hobbyist users willing to type in 539 special URLs. 541 There is little an ICP can do to deal with client-side or remote ISP 542 deficiencies in IPv6 support, but it is hoped that the "happy 543 eyeballs" [RFC6555] approach will improve the ability for clients to 544 deal with such problems. 546 10. Content Delivery Networks 548 DNS-based techniques for diverting users to Content Delivery Network 549 (CDN) points of presence (POPs) will work for IPv6, if AAAA records 550 are provided as well as A records. In general the CDN should follow 551 the recommendations of this document, especially by operating a full 552 dual stack service at each POP. Additionally, each POP will need to 553 handle IPv6 routing exactly like IPv4, for example running BGP4+ 554 [RFC4760] if appropriate. 556 Note that if an ICP supports IPv6 but its external CDN provider does 557 not, its clients will continue to use IPv4 and any IPv6-only clients 558 will have to use a transition solution of some kind. This is not a 559 desirable situation, since the ICP's work to support IPv6 will be 560 wasted. The converse is not true: if the CDN supports IPv6 but the 561 ICP does not, dual-stack and IPv6-only clients will obtain IPv6 562 access, assuming the CDN provider announces AAAA DNS Resource 563 Records. 565 An ICP might face a complex situation, if its CDN provider supports 566 IPv6 at some POPs but not at others. IPv6-only clients could only be 567 diverted to a POP supporting IPv6. There are also scenarios where a 568 dual-stack client would be diverted to a mixture of IPv4 and IPv6 569 POPs for different URLs, according to the A and AAAA records provided 570 and the availability of optimisations such as "happy eyeballs." A 571 related side effect is that copies of the same content viewed at the 572 same time via IPv4 and IPv6 may be different, due to latency in the 573 underlying data synchronisation process used by the CDN. This effect 574 has in fact been observed in the wild for a major social network 575 supporting dual stack. These complications do not affect the 576 viability of relying on a dual-stack CDN, however. 578 The CDN itself faces related complexity: "As IPv6 rolls out, it's 579 going to roll out in pockets, and that's going to make the routing 580 around congestion points that much more important but also that much 581 harder," stated John Summers of Akamai in 2010. 583 11. Business Partners 585 As noted earlier, it is in an ICP's or ASP's best interests that 586 their users have direct IPv6 connectivity, rather than indirect IPv4 587 connectivity via double NAT. If the ICP or ASP has a direct business 588 relationship with some of their clients, or with the networks that 589 connect them to their clients, they are advised to coordinate with 590 those partners to ensure that they have a plan to enable IPv6. They 591 should also verify and test that there is first-class IPv6 592 connectivity end-to-end between the networks concerned. This is 593 especially true for implementations that require IPv6 support in 594 specialized programs or systems in order for the IPv6 support on the 595 ICP/ASP side to be useful. 597 12. Operations and Management 599 There is no doubt that, initially, IPv6 deployment will have 600 operational impact, as well as requiring education and training as 601 mentioned in Section 3. Staff will have to update network elements 602 such as routers, update configurations, provide information to end 603 users, and diagnose new problems. However, for an enterprise 604 network, there is plenty of experience, e.g. on numerous university 605 campuses, showing that dual stack operation is no harder than IPv4- 606 only in the steady state. 608 Whatever management, monitoring and logging is performed for IPv4 is 609 also needed for IPv6. Therefore, all products and tools used for 610 these purposes must be updated to fully support IPv6. Note that 611 since an IPv6 network may operate with more than one IPv6 prefix and 612 therefore more than one address per host, the tools must deal with 613 this as a normal situation. This includes any address management 614 tool in use (see Section 5.1) as well as tools used for creating DHCP 615 and DNS configurations. There is significant overlap here with the 616 tools involved in site renumbering [I-D.jiang-6renum-enterprise]. 618 As far as possible, however, mutual dependency between IPv4 and IPv6 619 operations should be avoided. A failure of one should not cause a 620 failure of the other. One precaution to avoid this would be for 621 back-end systems such as network management databases to be dual 622 stacked as soon as convenient. It should also be possible to use 623 IPv4 connectivity to repair IPv6 configurations, and vice versa. 625 Dual stack, while necessary, does have management scaling and 626 overhead considerations. As noted earlier, the long term goal is to 627 move to single-stack IPv6, when the network and its customers can 628 support this. This is an additional reason why mutual dependency 629 between the address families should be avoided in the management 630 system in particular; a hidden dependency on IPv4 that had been 631 forgotten for many years would be highly inconvenient. In 632 particular, a management tool that manages IPv6 but itself runs only 633 over IPv4 would prove disastrous on the day that IPv4 is switched 634 off. 636 13. Security Considerations 638 Security experience with IPv4 should be used as a guide as to the 639 threats that may exist in IPv6, but they should not be assumed to be 640 equally likely, and nor should they assumed to be the only threats 641 that could exist in IPv6. However, essentially every threat that 642 exists for IPv4 exists or will exist for IPv6, to a greater or lesser 643 extent. It is essential to update firewalls, intrusion detection 644 systems, denial of service precautions, and security auditing 645 technology to fully support IPv6. Otherwise, IPv6 will become an 646 attractive target for attackers. 648 When multiple PA prefixes are in use as mentioned in Section 5.1, 649 firewall rules must allow for all valid prefixes, and must be set up 650 to work as intended even if packets are sent via one ISP but return 651 packets arrive via another. 653 Performance and memory size aspects of dual stack firewalls must be 654 considered (as discussed for routers in Section 5.2). 656 In a dual stack operation, there may be a risk of cross-contamination 657 between the two protocols. For example, a successful IPv4-based 658 denial of service attack might also deplete resources needed by the 659 IPv6 service, or vice versa. This risk strengthens the argument that 660 IPv6 security must be up to the same level as IPv4. 662 A general overview of techniques to protect an IPv6 network against 663 external attack is given in [RFC4864]. Assuming an ICP has native 664 IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4 665 tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this 666 kind should be blocked except for the case noted in Section 4.5 of 667 [RFC6343]. ICMPv6 traffic should only be blocked in accordance with 668 [RFC4890]; in particular, Packet Too Big messages, which are 669 essential for PMTU discovery, must not be blocked. 671 Scanning attacks to discover the existence of hosts are much less 672 likely to succeed for IPv6 than for IPv4 [RFC5157]. However, this is 673 only true if IPv6 hosts are configured with interface identifiers 674 that are hard to guess; for example, it is not advisable to manually 675 configure hosts with consecutive interface identifiers starting from 676 "1". 678 Transport Layer Security version 1.2 [RFC5246] and its predecessors 679 work correctly with TCP over IPv6, meaning that HTTPS-based security 680 solutions are immediately applicable. The same should apply to any 681 other transport-layer or application-layer security techniques. 683 If an ASP uses IPsec [RFC4301] and IKE [RFC5996] in any way to secure 684 connections with clients, these too are fully applicable to IPv6, but 685 only if the software stack at each end has been appropriately 686 updated. 688 14. IANA Considerations 690 This document requests no action by IANA. 692 15. Acknowledgements 694 Valuable contributions were made by Erik Kline. Useful comments were 695 received from Tassos Chatzithomaoglou, Wesley George, Deng Hui, Joel 696 Jaeggli, Roger Jorgensen, Victor Kuarsingh, Bing Liu, Trent Lloyd, 697 John Mann, Michael Newbery, Arturo Servin, Mark Smith, and other 698 participants in the V6OPS working group. 700 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 701 University during part of this work. 703 This document was produced using the xml2rfc tool [RFC2629]. 705 16. Change log [RFC Editor: Please remove] 707 draft-ietf-v6ops-icp-guidance-02: additional WG review, 2012-07-11. 709 draft-ietf-v6ops-icp-guidance-01: additional WG comments, 2012-06-12. 711 draft-ietf-v6ops-icp-guidance-00: adopted by WG, small updates, 2012- 712 04-17. 714 draft-carpenter-v6ops-icp-guidance-03: additional WG comments, 2012- 715 02-23. 717 draft-carpenter-v6ops-icp-guidance-02: additional WG comments, 2012- 718 01-07. 720 draft-carpenter-v6ops-icp-guidance-01: multiple clarifications after 721 WG comments, 2011-12-06. 723 draft-carpenter-v6ops-icp-guidance-00: original version, 2011-10-22. 725 17. References 727 17.1. Normative References 729 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 730 January 1997. 732 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 733 (IPv6) Specification", RFC 2460, December 1998. 735 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 736 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 737 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 739 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 740 Defeating Denial of Service Attacks which employ IP Source 741 Address Spoofing", BCP 38, RFC 2827, May 2000. 743 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 744 Update", RFC 3007, November 2000. 746 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 747 and M. Carney, "Dynamic Host Configuration Protocol for 748 IPv6 (DHCPv6)", RFC 3315, July 2003. 750 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 751 "DNS Extensions to Support IP Version 6", RFC 3596, 752 October 2003. 754 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 755 Networks", BCP 84, RFC 3704, March 2004. 757 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 758 Addresses", RFC 4193, October 2005. 760 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 761 Internet Protocol", RFC 4301, December 2005. 763 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 764 "Multiprotocol Extensions for BGP-4", RFC 4760, 765 January 2007. 767 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 768 Multicast Name Resolution (LLMNR)", RFC 4795, 769 January 2007. 771 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 772 Address Autoconfiguration", RFC 4862, September 2007. 774 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 775 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 777 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 778 October 2008. 780 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 781 for IPv6", RFC 5340, July 2008. 783 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 784 "Internet Key Exchange Protocol Version 2 (IKEv2)", 785 RFC 5996, September 2010. 787 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 788 Requirements", RFC 6434, December 2011. 790 17.2. Informative References 792 [I-D.carpenter-6renum-static-problem] 793 Carpenter, B. and S. Jiang, "Problem Statement for 794 Renumbering IPv6 Hosts with Static Addresses", 795 draft-carpenter-6renum-static-problem-02 (work in 796 progress), February 2012. 798 [I-D.ietf-v6ops-6204bis] 799 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 800 Requirements for IPv6 Customer Edge Routers", 801 draft-ietf-v6ops-6204bis-09 (work in progress), May 2012. 803 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 804 Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. 805 Wing, "IPv6 Multihoming without Network Address 806 Translation", 807 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 808 in progress), February 2012. 810 [I-D.jiang-6renum-enterprise] 811 Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 812 Network Renumbering Scenarios and Guidelines", 813 draft-jiang-6renum-enterprise-02 (work in progress), 814 December 2011. 816 [I-D.matthews-v6ops-design-guidelines] 817 Matthews, P., "Design Guidelines for IPv6 Networks", 818 draft-matthews-v6ops-design-guidelines-00 (work in 819 progress), June 2012. 821 [RFC2081] Malkin, G., "RIPng Protocol Applicability Statement", 822 RFC 2081, January 1997. 824 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 825 June 1999. 827 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 828 RFC 2923, September 2000. 830 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 831 RFC 3068, June 2001. 833 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 834 Castro, "Application Aspects of IPv6 Transition", 835 RFC 4038, March 2005. 837 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 838 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 839 September 2005. 841 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 842 E. Klein, "Local Network Protection for IPv6", RFC 4864, 843 May 2007. 845 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 846 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 848 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 849 Extensions for Stateless Address Autoconfiguration in 850 IPv6", RFC 4941, September 2007. 852 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 853 RFC 5157, March 2008. 855 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 856 and C. Hahn, "IPv6 Unicast Address Assignment 857 Considerations", RFC 5375, December 2008. 859 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 860 NAT64: Network Address and Protocol Translation from IPv6 861 Clients to IPv4 Servers", RFC 6146, April 2011. 863 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 864 Transition Mechanisms during IPv6 Deployment", RFC 6180, 865 May 2011. 867 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 868 Translation", RFC 6296, June 2011. 870 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 871 RFC 6343, August 2011. 873 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 874 Dual-Stack Hosts", RFC 6555, April 2012. 876 [RFC6589] Livingood, J., "Considerations for Transitioning Content 877 to IPv6", RFC 6589, April 2012. 879 Authors' Addresses 881 Brian Carpenter 882 Department of Computer Science 883 University of Auckland 884 PB 92019 885 Auckland, 1142 886 New Zealand 888 Email: brian.e.carpenter@gmail.com 890 Sheng Jiang 891 Huawei Technologies Co., Ltd 892 Q14, Huawei Campus 893 No.156 Beiqing Road 894 Hai-Dian District, Beijing 100095 895 P.R. China 897 Email: jiangsheng@huawei.com