idnits 2.17.1 draft-ietf-v6ops-icp-guidance-05.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 (January 11, 2013) is 4121 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 4941 (Obsoleted by RFC 8981) ** 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 (-06) exists of draft-ietf-6renum-enterprise-05 == Outdated reference: A later version (-06) exists of draft-ietf-opsec-vpn-leakages-00 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 -- 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 5157 (Obsoleted by RFC 7707) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 7 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: July 15, 2013 Huawei Technologies Co., Ltd 6 January 11, 2013 8 IPv6 Guidance for Internet Content and Application Service Providers 9 draft-ietf-v6ops-icp-guidance-05 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 July 15, 2013. 36 Copyright Notice 38 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 10 62 7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 8. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 8.1. Network Stack . . . . . . . . . . . . . . . . . . . . . . 12 65 8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 12 66 8.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 8.4. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. Coping with Transition Technologies . . . . . . . . . . . . . 13 69 10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 15 70 11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 16 71 12. Possible Complexities . . . . . . . . . . . . . . . . . . . . 16 72 13. Operations and Management . . . . . . . . . . . . . . . . . . 17 73 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 76 17. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 20 77 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 18.1. Normative References . . . . . . . . . . . . . . . . . . . 21 79 18.2. Informative References . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 The deployment of IPv6 [RFC2460] is now in progress, and users 85 without direct IPv4 access are likely to appear in increasing numbers 86 in the coming years. Any provider of content or application services 87 over the Internet will need to arrange for IPv6 access or else risk 88 losing large numbers of potential users. For users who already have 89 dual stack connectivity, direct IPv6 access might provide more 90 satisfactory performance than indirect access via NAT. 92 In this document, we often refer to the users of content or 93 application services as "customers" to clarify the part they play, 94 but this is not intended to limit the scope to commercial sites. 96 The time for action is now, while the number of IPv6-only customers 97 is small, so that appropriate skills, software and equipment can be 98 acquired in good time to scale up the IPv6 service as demand 99 increases. An additional advantage of early support for IPv6 100 customers is that it will reduce the number of customers connecting 101 later via IPv4 "extension" solutions such as double NAT or NAT64 102 [RFC6146], which will otherwise degrade the user experience. 104 Nevertheless, it is important that the introduction of IPv6 service 105 should not make service for IPv4 customers worse. In some 106 circumstances, technologies intended to assist in the transition from 107 IPv4 to IPv6 are known to have negative effects on the user 108 experience. A deployment strategy for IPv6 must avoid these effects 109 as much as possible. 111 The purpose of this document is to provide guidance and suggestions 112 for Internet Content Providers (ICPs) and Application Service 113 Providers (ASPs) who wish to offer their services to both IPv6 and 114 IPv4 customers, but who are currently supporting only IPv4. For 115 simplicity, the term ICP is mainly used in the body of this document, 116 but the guidance also applies to ASPs. Any hosting provider whose 117 customers include ICPs or ASPs is also concerned. Many of the points 118 in this document will also apply to enterprise networks that do not 119 classify themselves as ICPs. Any enterprise or department that runs 120 at least one externally accessible server, such as an HTTP server, 121 may also be concerned. Although specific managerial and technical 122 approaches are described, this is not a rule book; each operator will 123 need to make its own plan, tailored to its own services and 124 customers. 126 2. General Strategy 128 The most important advice here is to actually have a general 129 strategy. Adding support for a second network layer protocol is a 130 new experience for most modern organisations, and it cannot be done 131 casually on an unplanned basis. Even if it is impossible to write a 132 precisely dated plan, the intended steps in the process need to be 133 defined well in advance. There is no single blueprint for this. The 134 rest of this document is meant to provide a set of topics to be taken 135 into account in defining the strategy. Other documents about IPv6 136 deployment, such as [I-D.matthews-v6ops-design-guidelines], should be 137 consulted as well. 139 In determining the urgency of this strategy, it should be noted that 140 the central IPv4 registry (IANA) ran out of spare blocks of IPv4 141 addresses in February 2011 and the various regional registries are 142 expected to exhaust their reserves over the next one to two years. 143 After this, Internet Service Providers (ISPs) will run out at dates 144 determined by their own customer base. No precise date can be given 145 for when IPv6-only customers will appear in commercially significant 146 numbers, but - particularly in the case of mobile users - it may be 147 quite soon. Complacency about this is therefore not an option for 148 any ICP that wishes to grow its customer base over the coming years. 150 The most common strategy for an ICP is to provide dual stack services 151 - both IPv4 and IPv6 on an equal basis - to cover both existing and 152 future customers. This is the recommended strategy in [RFC6180] for 153 straightforward situations. Some ICPs who already have satisfactory 154 operational experience with IPv6 might consider an IPv6-only 155 strategy, with IPv4 clients being supported by translation or proxy 156 in front of their IPv6 content servers. However, the present 157 document is addressed to ICPs without IPv6 experience, who are likely 158 to prefer the dual stack model to build on their existing IPv4 159 service. 161 Due to the widespread impact of supporting IPv6 everywhere within an 162 environment, it is important to select a focussed initial approach 163 based on clear business needs and real technical dependencies. 165 Within the dual stack model, two approaches could be adopted, 166 sometimes referred to as "outside in" and "inside out": 168 o Outside in: start by providing external users with an IPv6 public 169 access to your services, for example by running a reverse proxy 170 that handles IPv6 customers (see Section 7 for details). 171 Progressively enable IPv6 internally. 172 o Inside out: start by enabling internal networking infrastructure, 173 hosts, and applications to support IPv6. Progressively reveal 174 IPv6 access to external customers. 176 Which of these approaches to choose depends on the precise 177 circumstances of the ICP concerned. "Outside in" has the benefit of 178 giving interested customers IPv6 access at an early stage, and 179 thereby gaining precious operational experience, before meticulously 180 updating every piece of equipment and software. For example, if some 181 back-office system, that is never exposed to users, only supports 182 IPv4, it will not cause delay. "Inside out" has the benefit of 183 completing the implementation of IPv6 as a single project. Any ICP 184 could choose this approach, but it might be most appropriate for a 185 small ICP without complex back-end systems. 187 A point that must be considered in the strategy is that some 188 customers will remain IPv4-only for many years, others will have both 189 IPv4 and IPv6 access, and yet others will have only IPv6. 190 Additionally, mobile customers may find themselves switching between 191 IPv4 and IPv6 access as they travel, even within a single session. 192 Services and applications must be able to deal with this, just as 193 easily as they deal today with a user whose IPv4 address changes (see 194 the discussion of cookies in Section 8.2). 196 Nevertheless, the end goal is to have a network that does not need 197 major changes when at some point in the future it becomes possible to 198 transition to IPv6-only, even if only for some parts of the network. 199 That is, the IPv6 deployment should be designed in such a way as to 200 more or less assume that IPv4 is already absent, so the network will 201 function seamlessly when it is indeed no longer there. 203 An important step in the strategy is to determine from hardware and 204 software suppliers details of their planned dates for providing 205 sufficient IPv6 support, with performance equivalent to IPv4, in 206 their products and services. Relevant specifications such as 207 [RFC6434] [I-D.ietf-v6ops-6204bis] should be used. Even if complete 208 information cannot be obtained, it is essential to determine which 209 components are on the critical path during successive phases of 210 deployment. This information will make it possible to draw up a 211 logical sequence of events and identify any components that may cause 212 holdups. 214 3. Education and Skills 216 Some staff may have experience of running multiprotocol networks, 217 which were common twenty years ago before the dominance of IPv4. 218 However, IPv6 will be new to them, and also to staff brought up only 219 on TCP/IP. It is not enough to have one "IPv6 expert" in a team. On 220 the contrary, everybody who knows about IPv4 needs to know about 221 IPv6, from network architect to help desk responder. Therefore, an 222 early and essential part of the strategy must be education, including 223 practical training, so that all staff acquire a general understanding 224 of IPv6, how it affects basic features such as the DNS, and the 225 relevant practical skills. To take a trivial example, any staff used 226 to dotted-decimal IPv4 addresses need to become familiar with the 227 colon-hexadecimal format used for IPv6. 229 There is an anecdote of one IPv6 deployment in which prefixes 230 including the letters A to F were avoided by design, to avoid 231 confusing system administrators unfamiliar with hexadecimal notation. 232 This is not a desirable result. There is another anecdote of a help 233 desk responder telling a customer to "disable one-Pv6" in order to 234 solve a problem. It should be a goal to avoid having untrained staff 235 who don't understand hexadecimal or who can't even spell "IPv6". 237 It is very useful to have a small laboratory network available for 238 training and self-training in IPv6, where staff may experiment and 239 make mistakes without disturbing the operational IPv4 service. This 240 lab should run both IPv4 and IPv6, to gain experience with a dual- 241 stack environment and new features such as having multiple addresses 242 per interface, and addresses with lifetimes and deprecation. 244 Once staff are trained, they will likely need to support both IPv4, 245 IPv6, and dual-stack customers. Rather than having separate internal 246 escalation paths for IPv6, it generally makes sense for questions 247 that may have an IPv6 element to follow normal escalation paths; 248 there should not be an "IPv6 Department" once training is completed. 250 A final remark about training is that it should not be given too 251 soon, or it will be forgotten. Training has a definite need to be 252 done "just in time" in order to properly "stick." Training, lab 253 experience, and actual deployment should therefore follow each other 254 immediately. If possible, training should even be combined with 255 actual operational experience. 257 4. Arranging IPv6 Connectivity 259 There are, in theory, two ways to obtain IPv6 connectivity to the 260 Internet. 262 o Native. In this case the ISP simply provides IPv6 on exactly the 263 same basis as IPv4 - it will appear at the ICP's border router(s), 264 which must then be configured in dual-stack mode to forward IPv6 265 packets in both directions. This is by far the better method. An 266 ICP should contact all its ISPs to verify when they will provide 267 native IPv6 support, whether this has any financial implications, 268 and whether the same service level agreement will apply as for 269 IPv4. Any ISP that has no definite plan to offer native IPv6 270 service should be avoided. 272 o Managed Tunnel. It is possible to configure an IPv6-in-IPv4 273 tunnel to a remote ISP that offers such a service. A dual-stack 274 router in the ICP's network will act as a tunnel end-point, or 275 this function could be included in the ICP's border router. 277 A managed tunnel is a reasonable way to obtain IPv6 connectivity 278 for initial testing and skills acquisition. However, it 279 introduces an inevitable extra latency compared to native IPv6, 280 giving customers a noticeably worse response time for complex web 281 pages. A tunnel may become a performance bottleneck (especially 282 if offered as a free service) or a target for malicious attack. 283 It is also likely to limit the IPv6 MTU size. In normal 284 circumstances, native IPv6 will provide an MTU size of at least 285 1500 bytes, but it will almost inevitably be less for a tunnel, 286 possibly as low as 1280 bytes (the minimum MTU allowed for IPv6). 287 Apart from the resulting loss of efficiency, there are cases in 288 which Path MTU Discovery fails, therefore IPv6 fragmentation 289 fails, and in this case the lower tunnel MTU will actually cause 290 connectivity failures for customers. 292 For these reasons, ICPs are strongly recommended to obtain native 293 IPv6 service before attempting to offer a production-quality 294 service to their customers. Unfortunately it is impossible to 295 prevent customers from using unmanaged tunnel solutions (see 296 Section 9). 298 Some larger organizations may find themselves needing multiple forms 299 of IPv6 connectivity, for their ICP data centres and for their staff 300 working elsewhere. It is important to obtain IPv6 connectivity for 301 both, as testing and supporting an IPv6-enabled service is 302 challenging for staff without IPv6 connectivity. This may involved 303 short-term alternatives to provide IPv6 connectivity to operations 304 and support staff, such as a managed tunnel or HTTP proxy server with 305 IPv6 connectivity. Note that unmanaged tunnels (such as 6to4 and 306 Teredo) are generally not useful for support staff as recent client 307 software will avoid them when accessing dual-stack sites. 309 5. IPv6 Infrastructure 311 5.1. Address and subnet assignment 313 An ICP must first decide whether to apply for its own Provider 314 Independent (PI) address prefix for IPv6. This option is available 315 either from an ISP that acts as a Local Internet Registry, or 316 directly from the relevant Regional Internet Registry. The 317 alternative is to obtain a Provider Aggregated (PA) prefix from an 318 ISP. Both solutions are viable in IPv6. However, the scaling 319 properties of the wide area routing system (BGP4) mean that the 320 number of PI prefixes should be limited, so only large content 321 providers can justify obtaining a PI prefix and convincing their ISPs 322 to route it. Millions of enterprise networks, including smaller 323 content providers, will use PA prefixes. In this case, a change of 324 ISP would necessitate a change of the corresponding PA prefix, using 325 the procedure outlined in [RFC4192]. 327 An ICP that has connections via multiple ISPs, but does not have a PI 328 prefix, would therefore have multiple PA prefixes, one from each ISP. 329 This would result in multiple IPv6 addresses for the ICP's servers or 330 load balancers. If one address fails due to an ISP malfunction, 331 sessions using that address would be lost. At the time of this 332 writing, there is very limited operational experience with this 333 approach [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. 335 An ICP may also choose to operate a Unique Local Address prefix 336 [RFC4193] for internal traffic only, as described in [RFC4864]. 338 Depending on its projected future size, an ICP might choose to obtain 339 /48 PI or PA prefixes (allowing 16 bits of subnet address) or longer 340 PA prefixes, e.g. /56 (allowing 8 bits of subnet address). Clearly 341 the choice of /48 is more future-proof. Advice on the numbering of 342 subnets may be found in [RFC5375]. An ICP with multiple locations 343 will probably need a prefix per location 345 An ICP that has its service hosted by a colocation provider, cloud 346 provider, or the like, will need to follow the addressing policy of 347 that provider. 349 Since IPv6 provides for operating multiple prefixes simultaneously, 350 it is important to check that all relevant tools, such as address 351 management packages, can deal with this. In particular, the possible 352 need to allow for multiple PA prefixes with IPv6, and the possible 353 need to renumber, means that the common technique of manually 354 assigned static addresses for servers, proxies or load balancers, 355 with statically defined DNS entries, could be problematic 356 [I-D.ietf-6renum-static-problem]. An ICP of reasonable size might 357 instead choose to operate DHCPv6 [RFC3315] with standard DNS, to 358 support stateful assignment. In either case a configuration 359 management system is likely to be used to support stateful and/or on- 360 demand address assignment. 362 Theoretically, it would also be possible to operate an ICP's IPv6 363 network using only Stateless Address Autoconfiguration [RFC4862], 364 with Dynamic DNS [RFC3007] to publish server addresses for external 365 users. 367 5.2. Routing 369 In a dual stack network, most IPv4 and IPv6 interior routing 370 protocols operate quite independently and in parallel. The common 371 routing protocols all support IPv6, such as OSPFv3 [RFC5340], IS-IS 372 [RFC5308], and even RIPng [RFC2080] [RFC2081]. It is worth noting 373 that whereas OSPF and RIP differ significantly between IPv4 and IPv6, 374 IS-IS has the advantage of handling them both in a single instance of 375 the protocol, with the potential for operational simplification in 376 the long term. Some versions of OSPFv3 may also have this advantage 377 [RFC5838]. In any case, for trained staff, there should be no 378 particular difficulty in deploying IPv6 routing without disturbance 379 to IPv4 services. In some cases, firmware upgrades may be needed on 380 some network devices. 382 The performance impact of dual stack routing needs to be evaluated. 383 In particular, what forwarding performance does the router vendor 384 claim for IPv6? If the forwarding performance is significantly 385 inferior compared to IPv4, will this be an operational problem? Is 386 extra memory or ternary content-addressable memory (TCAM) space 387 needed to accommodate both IPv4 and IPv6 tables? To answer these 388 questions, the ICP will need a projected model for the amount of IPv6 389 traffic expected initially, and its likely rate of increase. 391 If a site has multiple PA prefixes as mentioned in Section 5.1, 392 complexities will appear in routing configuration. In particular, 393 source-based routing rules might be needed to ensure that outgoing 394 packets are routed to the appropriate border router and ISP link. 395 Normally, a packet sourced from an address assigned by ISP X should 396 not be sent via ISP Y, to avoid ingress filtering by Y [RFC2827] 397 [RFC3704]. Additional considerations may be found in 398 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Note that the 399 prefix translation technique discussed in [RFC6296] does not describe 400 a solution for enterprises that offer publicly available content 401 servers. 403 Each IPv6 subnet that supports end hosts normally has a /64 prefix, 404 leaving another 64 bits for the interface identifiers of individual 405 hosts. In contrast, a typical IPv4 subnet will have no more than 8 406 bits for the host identifier, thus limiting the subnet to 256 or 407 fewer hosts. A dual stack design will typically use the same 408 physical or VLAN subnet topology for IPv4 and IPv6, and therefore the 409 same router topology. In other words the IPv4 and IPv6 topologies 410 are congruent. This means that the limited subnet size of IPv4 (such 411 as 256 hosts) will be imposed on IPv6, even though the IPv6 prefix 412 will allow many more hosts. It would be theoretically possible to 413 avoid this limitation by implementing a different physical or VLAN 414 subnet topology for IPv6. This is not advisable, as it would result 415 in extremely complex fault diagnosis when something went wrong. 417 5.3. DNS 419 It must be understood that as soon as an AAAA record for a well-known 420 name is published in the DNS, the corresponding server will start to 421 receive IPv6 traffic. Therefore, it is essential that an ICP tests 422 thoroughly that IPv6 works on its servers, load balancers, etc., 423 before adding their AAAA records to DNS. There have been numerous 424 cases of ICPs breaking their sites for all IPv6 users during a roll- 425 out by returning AAAA records for servers improperly configured for 426 IPv6. 428 Once such tests have succeeded, each externally visible host (or 429 virtual host) that has an A record for its IPv4 address needs an AAAA 430 record [RFC3596] for its IPv6 address, and a reverse entry (in 431 ip6.arpa) if applicable. Note that if CNAME records are in use, the 432 AAAA record must be added alongside the A record at the end of the 433 CNAME chain. It is not possible to have the AAAA record on the same 434 name as a CNAME record, as per [RFC1912]. 436 One important detail is that some clients (especially Windows XP) can 437 only resolve DNS names via IPv4, even if they can use IPv6 for 438 application traffic. Also, a dual stack resolver might attempt to 439 resolve queries for A records via IPv6, or AAAA records via IPv4. It 440 is therefore advisable for all DNS servers to respond to queries via 441 both IPv4 and IPv6. 443 6. Load Balancers 445 Most available load balancers now support IPv6. However, it is 446 important to obtain appropriate assurances from vendors about their 447 IPv6 support, including performance aspects (as discussed for routers 448 in Section 5.2). The update needs to be planned in anticipation of 449 expected traffic growth. It is to be expected that IPv6 traffic will 450 initially be low, i.e., a small but growing percentage of total 451 traffic. For this reason, it might be acceptable to have IPv6 452 traffic bypass load balancing initially, by publishing an AAAA record 453 for a specific server instead of the load balancer. However, load 454 balancers often also provide for server fail-over, in which case it 455 would be better to implement IPv6 load balancing immediately. 457 The same would apply to Transport Layer Security (TLS) or HTTP 458 proxies used for load balancing purposes. 460 7. Proxies 462 An HTTP proxy [RFC2616] can readily be configured to handle incoming 463 connections over IPv6 and to proxy them to a server over IPv4. 464 Therefore, a single proxy can be used as the first step in an 465 outside-in strategy, as shown in the following diagram: 467 ___________________________________________ 468 ( ) 469 ( IPv6 Clients in the Internet ) 470 (___________________________________________) 471 | 472 ------------- 473 | Ingress | 474 | router | 475 ------------- 476 ____________|_____________ 477 | 478 ------------- 479 | IPv6 stack| 480 |-----------| 481 | HTTP proxy| 482 |-----------| 483 | IPv4 stack| 484 ------------- 485 ____________|_____________ 486 | 487 ------------- 488 | IPv4 stack| 489 |-----------| 490 | HTTP | 491 | server | 492 ------------- 494 In this case, the AAAA record for the service would provide the IPv6 495 address of the proxy. This approach will work for any HTTP or HTTPS 496 applications that operate successfully via a proxy, as long as IPv6 497 load remains low. Additionally, many load balancer products 498 incorporate such a proxy, in which case this approach would be 499 possible at high load. 501 Note that in any proxy scenario, an ICP will need to make sure that 502 both IPv4 and IPv6 addresses are being properly passed to application 503 servers in any relevant HTTP headers, and that those application 504 servers are properly handling the IPv6 addresses. 506 8. Servers 508 8.1. Network Stack 510 The TCP/IP network stacks in popular operating systems have supported 511 IPv6 for many years. In most cases, it is sufficient to enable IPv6 512 and possibly DHCPv6; the rest will follow. Servers inside an ICP 513 network will not need to support any transition technologies beyond a 514 simple dual stack, with a possible exception for 6to4 mitigation 515 noted below in Section 9. 517 As some operating systems have separate firewall rule sets for IPv4 518 and IPv6, an ICP should also evaluate those rule sets and ensure that 519 appropriate firewall rules are configured for IPv6. More details are 520 discussed in Section 14. 522 8.2. Application Layer 524 Basic HTTP servers have been able to handle an IPv6-enabled network 525 stack for some years, so at the most it will be necessary to update 526 to a more recent software version. The same is true of generic 527 applications such as email protocols. No general statement can be 528 made about other applications, especially proprietary ones, so each 529 ASP will need to make its own determination. As changes to the 530 network layer to introduce IPv6 addresses can ripple through 531 applications, testing of both client and server applications should 532 be performed in both IPv4-only, IPv6-only, and dual-stack 533 environments prior to dual-stacking a production environment. 535 One important recommendation here is that all applications should use 536 domain names, which are IP-version-independent, rather than IP 537 addresses. Applications based on middlware platforms which have 538 uniform support for IPv4 and IPv6, for example Java, may be able to 539 support both IPv4 and IPv6 naturally without additional work. 540 Security certificates should also contain domain names rather than 541 addresses. 543 A specific issue for HTTP-based services is that IP address-based 544 cookie authentication schemes will need to deal with dual-stack 545 clients. Servers might create a cookie for an IPv4 connection or an 546 IPv6 connection, depending on the setup at the client site and on the 547 whims of the client operating system. There is no guarantee that a 548 given client will consistently use the same address family, 549 especially when accessing a collection of sites rather than a single 550 site, such as when cookies are used for federated authentication. If 551 the client is using privacy addresses [RFC4941], the IPv6 address 552 (but usually not its /64 prefix) might change quite frequently. Any 553 cookie mechanism based on 32-bit IPv4 addresses will need significant 554 remodelling. 556 Generic considerations on application transition are discussed in 557 [RFC4038], but many of them will not apply to the dual-stack ICP 558 scenario. An ICP that creates and maintains its own applications 559 will need to review them for any dependency on IPv4. 561 8.3. Logging 563 The introduction of IPv6 clients will generally also result in IPv6 564 addresses appearing in the "client ip" field of server logs. It 565 might be convenient to use the same log field to hold a client's IP 566 address, whether it is IPv4 or IPv6. Downstream systems looking at 567 logs and client IP addresses may also need testing to ensure that 568 they can properly handle IPv6 addresses. This includes any of an 569 ICP's databases recording client IP addresses, such as for recording 570 IP addresses of online purchases and comment posters. 572 It is worth noting that accurate traceback from logs to individual 573 customers requires end-to-end address transparency. This is 574 additional motivation for an ICP to support native IPv6 connectivity, 575 since otherwise, IPv6-only customers will inevitably connect via some 576 form of translation mechanism, interfering with traceback. 578 8.4. Geolocation 580 Initially, ICPs may observe some weakness in geolocation for IPv6 581 clients. As time goes on, it is to be assumed that geolocation 582 methods and databases will be updated to fully support IPv6 prefixes. 583 There is no reason they will be more or less accurate in the long 584 term than those available for IPv4. However, we can expect many more 585 clients to be mobile as time goes on, so geolocation based on IP 586 addresses alone may in any case become problematic. A more robust 587 technique such as HTTP-Enabled Location Delivery (HELD) [RFC5985] 588 could be considered. 590 9. Coping with Transition Technologies 592 As mentioned above, an ICP should obtain native IPv6 connectivity 593 from its ISPs. In this way, the ICP can avoid most of the 594 complexities of the numerous IPv4-to-IPv6 transition technologies 595 that have been developed; they are all second-best solutions. 596 However, some clients are sure to be using such technologies. An ICP 597 needs to be aware of the operational issues this may cause and how to 598 deal with them. 600 In some cases outside the ICP's control, clients might reach a 601 content server via a network-layer translator from IPv6 to IPv4. 602 ICPs who are offering a dual stack service and providing both A and 603 AAAA records, as recommended in this document, should not normally 604 receive IPv4 traffic from NAT64 translators [RFC6146]. 605 Exceptionally, however, such traffic could arrive via IPv4 from an 606 IPv6-only client whose DNS resolver failed to receive the ICP's AAAA 607 record for some reason. Such traffic would be indistinguishable from 608 regular IPv4-via-NAT traffic. 610 Alternatively, ICPs who are offering a dual stack service might 611 exceptionally receive IPv6 traffic translated from an IPv4-only 612 client that somehow failed to receive the ICP's A record. An ICP 613 could also receive IPv6 traffic with translated prefixes [RFC6296]. 614 These two cases would only be an issue if the ICP was offering any 615 service that depends on the assumption of end-to-end IPv6 address 616 transparency. 618 Finally, some traffic might reach an ICP that has been translated 619 twice en route (e.g., from IPv6 to IPv4 and back again). Again, the 620 ICP will be unable to detect this. It is likely that real-time 621 geolocation will be highly inaccurate for such traffic, since it will 622 at best indicate the location of the second translator, which could 623 be very distant from the customer. 625 In other cases, also outside the ICP's control, IPv6 clients may 626 reach the IPv6 Internet via some form of IPv6-in-IPv4 tunnel. In 627 this case a variety of problems can arise, the most acute of which 628 affect clients connected using the Anycast 6to4 solution [RFC3068]. 629 Advice on how ICPs may mitigate these 6to4 problems is given in 630 Section 4.5. of [RFC6343]. For the benefit of all tunnelled clients, 631 it is essential to verify that Path MTU Discovery works correctly 632 (i.e., the relevant ICMPv6 packets are not blocked) and that the 633 server-side TCP implementation correctly supports the Maximum Segment 634 Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic. 636 Some ICPs have implemented an interim solution to mitigate transition 637 problems by limiting the visibility of their AAAA records to users 638 with validated IPv6 connectivity [RFC6589] (known as "DNS 639 whitelisting"). At the time of this writing, this solution seems to 640 be passing out of use, being replaced by "DNS blacklisting" of 641 customer sites known to have problems with IPv6 connectivity. In the 642 reverse direction, it is worth being aware that some ISPs with 643 significant populations of clients with broken IPv6 setups have begun 644 filtering AAAA record lookups by their clients. None of these 645 solutions is appropriate in the long term. 647 Another approach taken by some ICPs is to offer IPv6-only support via 648 a specific DNS name, e.g., ipv6.example.com, if the primary service 649 is www.example.com. In this case ipv6.example.com would have an AAAA 650 record only. This has some value for testing purposes, but is 651 otherwise only of interest to hobbyist users willing to type in 652 special URLs. 654 There is little an ICP can do to deal with client-side or remote ISP 655 deficiencies in IPv6 support, but it is hoped that the "happy 656 eyeballs" [RFC6555] approach will improve the ability for clients to 657 deal with such problems. 659 10. Content Delivery Networks 661 DNS-based techniques for diverting users to Content Delivery Network 662 (CDN) points of presence (POPs) will work for IPv6, if AAAA records 663 are provided as well as A records. In general the CDN should follow 664 the recommendations of this document, especially by operating a full 665 dual stack service at each POP. Additionally, each POP will need to 666 handle IPv6 routing exactly like IPv4, for example running BGP4+ 667 [RFC4760]. 669 Note that if an ICP supports IPv6 but its external CDN provider does 670 not, its clients will continue to use IPv4 and any IPv6-only clients 671 will have to use a transition solution of some kind. This is not a 672 desirable situation, since the ICP's work to support IPv6 will be 673 wasted. 675 An ICP might face a complex situation, if its CDN provider supports 676 IPv6 at some POPs but not at others. IPv6-only clients could only be 677 diverted to a POP supporting IPv6. There are also scenarios where a 678 dual-stack client would be diverted to a mixture of IPv4 and IPv6 679 POPs for different URLs, according to the A and AAAA records provided 680 and the availability of optimisations such as "happy eyeballs." A 681 related side effect is that copies of the same content viewed at the 682 same time via IPv4 and IPv6 may be different, due to latency in the 683 underlying data synchronisation process used by the CDN. This effect 684 has in fact been observed in the wild for a major social network 685 supporting dual stack. These complications do not affect the 686 viability of relying on a dual-stack CDN, however. 688 The CDN itself faces related complexity: "As IPv6 rolls out, it's 689 going to roll out in pockets, and that's going to make the routing 690 around congestion points that much more important but also that much 691 harder," stated John Summers of Akamai in 2010. 693 A converse situation that might arise is that an ICP has not yet 694 started its deployment of IPv6, but finds that its CDN provider 695 already supports IPv6. Then, assuming the CDN provider announces 696 appropriate AAAA DNS Resource Records, dual-stack and IPv6-only 697 customers will obtain IPv6 access and the ICP's content may well be 698 delivered to them via IPv6. In normal circumstances this should 699 create no problems, but it is a situation that the ICP and its 700 support staff need to be aware of. In particular, support staff 701 should be given IPv6 connectivity in order to be able to investigate 702 any problems that might arise (see Section 4). 704 11. Business Partners 706 As noted earlier, it is in an ICP's or ASP's best interests that 707 their users have direct IPv6 connectivity, rather than indirect IPv4 708 connectivity via double NAT. If the ICP or ASP has a direct business 709 relationship with some of their clients, or with the networks that 710 connect them to their clients, they are advised to coordinate with 711 those partners to ensure that they have a plan to enable IPv6. They 712 should also verify and test that there is first-class IPv6 713 connectivity end-to-end between the networks concerned. This is 714 especially true for implementations that require IPv6 support in 715 specialized programs or systems in order for the IPv6 support on the 716 ICP/ASP side to be useful. 718 12. Possible Complexities 720 Some additional considerations come into play for some types of 721 complex or distributed sites and applications that an ICP may be 722 delivering. For example, an ICP may have a site spread across many 723 hostnames (not all under their control). Other ICPs may have their 724 sites or applications distributed across multiple locations for 725 availability, scale, or performance. 727 Many modern web sites and applications now use a collection of 728 resources and applications, some operated by the ICP and other by 729 third parties. While most clients support sites containing a mixture 730 of IPv4-only and dual-stack elements, an ICP should track the IPv6 731 availability of embedded resources (such as images) as otherwise 732 their site may only be partially functional or may have degraded 733 performance for IPv6-only users. 735 DNS-based load balancing techniques for diverting users to servers in 736 multiple POPs will work for IPv6, if the load balancer supports IPv6 737 and if AAAA records are provided. Depending on the architecture of 738 the load balancer, an ICP may need to operate a full dual stack 739 service at each POP. With other architectures, it may be acceptable 740 to initially only have IPv6 at a subset of locations. Some 741 architectures will make it preferable for IPv6 routing to mirror IPv4 742 routing (for example running BGP4+ [RFC4760] if appropriate) but this 743 may not always be possible as IPv6 and IPv4 connectivity can be 744 independent. 746 Some complexities may arise when a client supporting both IPv4 and 747 IPv6 uses different POPs for each IP version (such as when IPv6 is 748 only available in a subset of locations). There are also scenarios 749 where a dual-stack client would be diverted to a mixture of IPv4 and 750 IPv6 POPs for different URLs, according to the A and AAAA records 751 provided and the availability of optimisations such as "happy 752 eyeballs" [RFC6555]. A related side effect is that copies of the 753 same content viewed at the same time via IPv4 and IPv6 may be 754 different, due to latency in the underlying data synchronisation 755 process used at the application layer. This effect has in fact been 756 observed in the wild for a major social network supporting dual- 757 stack. 759 Even with a single POP, unexpected behaviour may arise if a client 760 switches spontaneously between IPv4 and IPv6 as a performance 761 optimisation [RFC6555] or if its IPv6 address changes frequently for 762 privacy reasons [RFC4941]. Such changes may affect cookies, 763 geolocation, load balancing, and transactional integrity. Although 764 unexpected changes of client address also occur in an IPv4-only 765 environment, they may be more frequent with IPv6. 767 13. Operations and Management 769 There is no doubt that, initially, IPv6 deployment will have 770 operational impact, as well as requiring education and training as 771 mentioned in Section 3. Staff will have to update network elements 772 such as routers, update configurations, provide information to end 773 users, and diagnose new problems. However, for an enterprise 774 network, there is plenty of experience, e.g. on numerous university 775 campuses, showing that dual stack operation is no harder than IPv4- 776 only in the steady state. 778 Whatever management, monitoring and logging is performed for IPv4 is 779 also needed for IPv6. Therefore, all products and tools used for 780 these purposes must be updated to fully support IPv6 management data. 781 It is important to verify that tools have been fully updated to 782 support 128 bit addresses entered and displayed in hexadecimal 783 [RFC5952]. Since an IPv6 network may operate with more than one IPv6 784 prefix and therefore more than one address per host, the tools must 785 deal with this as a normal situation. This includes any address 786 management tool in use (see Section 5.1) as well as tools used for 787 creating DHCP and DNS configurations. There is significant overlap 788 here with the tools involved in site renumbering 790 [I-D.ietf-6renum-enterprise]. 792 At an early stage of IPv6 deployment, it is likely that IPv6 will be 793 mainly managed via IPv4 transport. This allows network management 794 systems to test for dependencies between IPv4 and IPv6 management 795 data. For example, will reports mixing IPv4 and IPv6 addresses 796 display correctly? 798 In a second phase, IPv6 transport should be used to manage the 799 network. Note that it will also be necessary for an ICP to provide 800 IPv6 connectivity for its operations and support staff, even when 801 working remotely. As far as possible mutual dependency between IPv4 802 and IPv6 should be avoided, for both the management data and the 803 transport. Failure of one should not cause a failure of the other. 804 One precaution to avoid this would be for network management systems 805 to be dual-stacked. It would then be possible to use IPv4 806 connectivity to repair IPv6 configurations, and vice versa. 808 Dual stack, while necessary, does have management scaling and 809 overhead considerations. As noted earlier, the long term goal is to 810 move to single-stack IPv6, when the network and its customers can 811 support this. This is an additional reason why mutual dependency 812 between the address families should be avoided in the management 813 system in particular; a hidden dependency on IPv4 that had been 814 forgotten for many years would be highly inconvenient. In 815 particular, a management tool that manages IPv6 but itself runs only 816 over IPv4 would prove disastrous on the day that IPv4 is switched 817 off. 819 An ICP should ensure that any end-to-end availability monitoring 820 systems are updated to monitor dual-stacked servers over both IPv4 821 and IPv6. A particular challenge here may be monitoring systems 822 relying on DNS names as this may result in monitoring only one of 823 IPv4 or IPv6, resulting in a loss of visibility to failures in 824 network connectivity over either address family. 826 As mentioned above, it will also be necessary for an ICP to provide 827 IPv6 connectivity for its operations and support staff, even when 828 working remotely. 830 14. Security Considerations 832 While many ICPs may still be in the process of experimenting with and 833 configuring IPv6, there is mature malware in the wild that will 834 launch attacks over IPv6. For example, if an AAAA DNS record is 835 added for a hostname, malware using client OS libraries may 836 automatically switch from attacking that hostname over IPv4 to 837 attacking that hostname over IPv6. As a result, it is crucial that 838 firewalls and other network security appliances protecting servers 839 support IPv6 and have rules tested and configured. 841 Security experience with IPv4 should be used as a guide as to the 842 threats that may exist in IPv6, but they should not be assumed to be 843 equally likely, and nor should they assumed to be the only threats 844 that could exist in IPv6. However, essentially every threat that 845 exists for IPv4 exists or will exist for IPv6, to a greater or lesser 846 extent. It is essential to update firewalls, intrusion detection 847 systems, denial of service precautions, and security auditing 848 technology to fully support IPv6. Needless to say, it is also 849 essential to turn on well-known security mechanisms such as DNS 850 Security and DHCPv6 Authentication. Otherwise, IPv6 will become an 851 attractive target for attackers. 853 When multiple PA prefixes are in use as mentioned in Section 5.1, 854 firewall rules must allow for all valid prefixes, and must be set up 855 to work as intended even if packets are sent via one ISP but return 856 packets arrive via another. 858 Performance and memory size aspects of dual stack firewalls must be 859 considered (as discussed for routers in Section 5.2). 861 In a dual stack operation, there may be a risk of cross-contamination 862 between the two protocols. For example, a successful IPv4-based 863 denial of service attack might also deplete resources needed by the 864 IPv6 service, or vice versa. This risk strengthens the argument that 865 IPv6 security must be up to the same level as IPv4. Risks can also 866 occur with dual stack Virtual Private Network (VPN) solutions 867 [I-D.ietf-opsec-vpn-leakages]. 869 A general overview of techniques to protect an IPv6 network against 870 external attack is given in [RFC4864]. Assuming an ICP has native 871 IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4 872 tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this 873 kind should be blocked except for the case noted in Section 4.5 of 874 [RFC6343]. ICMPv6 traffic should only be blocked in accordance with 875 [RFC4890]; in particular, Packet Too Big messages, which are 876 essential for PMTU discovery, must not be blocked. 878 Brute-force scanning attacks to discover the existence of hosts are 879 much less likely to succeed for IPv6 than for IPv4 [RFC5157]. 880 However, this should not lull an ICP into a false sense of security, 881 as various naming or addressing conventions can result in IPv6 882 address space being predictable or guessable. In the extreme case, 883 IPv6 hosts might be configured with interface identifiers that are 884 very easy to guess; for example, hosts or subnets manually numbered 885 with consecutive interface identifiers starting from "1" would be 886 much easier to guess. Such practices should be avoided, and other 887 useful precautions are discussed in [RFC6583]. Also, attackers might 888 find IPv6 addresses in logs, packet traces, DNS records (including 889 reverse records), or elsewhere. 891 Protection against rogue Router Advertisements (RA Guard) should also 892 be considered [RFC6105]. 894 Transport Layer Security version 1.2 [RFC5246] and its predecessors 895 work correctly with TCP over IPv6, meaning that HTTPS-based security 896 solutions are immediately applicable. The same should apply to any 897 other transport-layer or application-layer security techniques. 899 If an ASP uses IPsec [RFC4301] and IKE [RFC5996] in any way to secure 900 connections with clients, these too are fully applicable to IPv6, but 901 only if the software stack at each end has been appropriately 902 updated. 904 15. IANA Considerations 906 This document requests no action by IANA. 908 16. Acknowledgements 910 Valuable contributions were made by Erik Kline. Useful comments were 911 received from Tore Anderson, Cameron Byrne, Tassos Chatzithomaoglou, 912 Wesley George, Deng Hui, Joel Jaeggli, Roger Jorgensen, Victor 913 Kuarsingh, Bing Liu, Trent Lloyd, John Mann, Michael Newbery, Erik 914 Nygren, Arturo Servin, Mark Smith, and other participants in the 915 V6OPS working group. 917 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 918 University during part of this work. 920 This document was produced using the xml2rfc tool [RFC2629]. 922 17. Change log [RFC Editor: Please remove] 924 draft-ietf-v6ops-icp-guidance-05: IESG comments, 2013-01-11. 926 draft-ietf-v6ops-icp-guidance-04: text on multiple PA prefixes tuned 927 again, brief mention of NPTv6, 2012-09-17. 929 draft-ietf-v6ops-icp-guidance-03: text on multiple PA prefixes 930 updated, numerous other WGLC comments, 2012-08-31. 932 draft-ietf-v6ops-icp-guidance-02: additional WG review, 2012-07-11. 934 draft-ietf-v6ops-icp-guidance-01: additional WG comments, 2012-06-12. 936 draft-ietf-v6ops-icp-guidance-00: adopted by WG, small updates, 2012- 937 04-17. 939 draft-carpenter-v6ops-icp-guidance-03: additional WG comments, 2012- 940 02-23. 942 draft-carpenter-v6ops-icp-guidance-02: additional WG comments, 2012- 943 01-07. 945 draft-carpenter-v6ops-icp-guidance-01: multiple clarifications after 946 WG comments, 2011-12-06. 948 draft-carpenter-v6ops-icp-guidance-00: original version, 2011-10-22. 950 18. References 952 18.1. Normative References 954 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 955 January 1997. 957 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 958 (IPv6) Specification", RFC 2460, December 1998. 960 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 961 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 962 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 964 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 965 Defeating Denial of Service Attacks which employ IP Source 966 Address Spoofing", BCP 38, RFC 2827, May 2000. 968 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 969 Update", RFC 3007, November 2000. 971 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 972 and M. Carney, "Dynamic Host Configuration Protocol for 973 IPv6 (DHCPv6)", RFC 3315, July 2003. 975 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 976 "DNS Extensions to Support IP Version 6", RFC 3596, 977 October 2003. 979 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 980 Networks", BCP 84, RFC 3704, March 2004. 982 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 983 Addresses", RFC 4193, October 2005. 985 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 986 Internet Protocol", RFC 4301, December 2005. 988 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 989 "Multiprotocol Extensions for BGP-4", RFC 4760, 990 January 2007. 992 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 993 Address Autoconfiguration", RFC 4862, September 2007. 995 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 996 Extensions for Stateless Address Autoconfiguration in 997 IPv6", RFC 4941, September 2007. 999 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1000 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1002 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1003 October 2008. 1005 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1006 for IPv6", RFC 5340, July 2008. 1008 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1009 Aggarwal, "Support of Address Families in OSPFv3", 1010 RFC 5838, April 2010. 1012 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1013 Address Text Representation", RFC 5952, August 2010. 1015 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 1016 RFC 5985, September 2010. 1018 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1019 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1020 RFC 5996, September 2010. 1022 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1023 Requirements", RFC 6434, December 2011. 1025 18.2. Informative References 1027 [I-D.ietf-6renum-enterprise] 1028 Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 1029 Network Renumbering Scenarios, Considerations and 1030 Methods", draft-ietf-6renum-enterprise-05 (work in 1031 progress), December 2012. 1033 [I-D.ietf-6renum-static-problem] 1034 Carpenter, B. and S. Jiang, "Problem Statement for 1035 Renumbering IPv6 Hosts with Static Addresses in Enterprise 1036 Networks", draft-ietf-6renum-static-problem-03 (work in 1037 progress), December 2012. 1039 [I-D.ietf-opsec-vpn-leakages] 1040 Gont, F., "Virtual Private Network (VPN) traffic leakages 1041 in dual-stack hosts/ networks", 1042 draft-ietf-opsec-vpn-leakages-00 (work in progress), 1043 December 2012. 1045 [I-D.ietf-v6ops-6204bis] 1046 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1047 Requirements for IPv6 Customer Edge Routers", 1048 draft-ietf-v6ops-6204bis-12 (work in progress), 1049 October 2012. 1051 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 1052 Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. 1053 Wing, "IPv6 Multihoming without Network Address 1054 Translation", 1055 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 1056 in progress), February 2012. 1058 [I-D.matthews-v6ops-design-guidelines] 1059 Matthews, P., "Design Guidelines for IPv6 Networks", 1060 draft-matthews-v6ops-design-guidelines-01 (work in 1061 progress), October 2012. 1063 [RFC1912] Barr, D., "Common DNS Operational and Configuration 1064 Errors", RFC 1912, February 1996. 1066 [RFC2081] Malkin, G., "RIPng Protocol Applicability Statement", 1067 RFC 2081, January 1997. 1069 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1070 June 1999. 1072 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1073 RFC 2923, September 2000. 1075 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1076 RFC 3068, June 2001. 1078 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 1079 Castro, "Application Aspects of IPv6 Transition", 1080 RFC 4038, March 2005. 1082 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1083 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1084 September 2005. 1086 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1087 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1088 May 2007. 1090 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1091 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1093 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1094 RFC 5157, March 2008. 1096 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1097 and C. Hahn, "IPv6 Unicast Address Assignment 1098 Considerations", RFC 5375, December 2008. 1100 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1101 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1102 February 2011. 1104 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1105 NAT64: Network Address and Protocol Translation from IPv6 1106 Clients to IPv4 Servers", RFC 6146, April 2011. 1108 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1109 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1110 May 2011. 1112 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1113 Translation", RFC 6296, June 2011. 1115 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1116 RFC 6343, August 2011. 1118 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1119 Dual-Stack Hosts", RFC 6555, April 2012. 1121 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1122 Neighbor Discovery Problems", RFC 6583, March 2012. 1124 [RFC6589] Livingood, J., "Considerations for Transitioning Content 1125 to IPv6", RFC 6589, April 2012. 1127 Authors' Addresses 1129 Brian Carpenter 1130 Department of Computer Science 1131 University of Auckland 1132 PB 92019 1133 Auckland, 1142 1134 New Zealand 1136 Email: brian.e.carpenter@gmail.com 1138 Sheng Jiang 1139 Huawei Technologies Co., Ltd 1140 Q14, Huawei Campus 1141 No.156 Beiqing Road 1142 Hai-Dian District, Beijing 100095 1143 P.R. China 1145 Email: jiangsheng@huawei.com