idnits 2.17.1 draft-ietf-sunset4-gapanalysis-08.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Liu 3 Internet-Draft W. Xu 4 Intended status: Informational C. Zhou 5 Expires: December 25, 2017 Huawei Technologies 6 T. Tsou 7 Philips Lighting 8 S. Perreault 9 Jive Communications 10 P. Fan 11 China Mobile 12 June 26, 2017 14 Gap Analysis for IPv4 Sunset 15 draft-ietf-sunset4-gapanalysis-08 17 Abstract 19 Sunsetting IPv4 refers to the process of turning off IPv4 20 definitively. It can be seen as the final phase of the migration to 21 IPv6. This memo enumerates difficulties arising when sunsetting 22 IPv4, and identifies the gaps requiring additional work. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 25, 2017. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 4 61 3.1. Indicating that IPv4 connectivity is unavailable . . . . 4 62 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 4 63 4. Client Connection Establishment Behavior . . . . . . . . . . 5 64 5. Disabling IPv4 in Operating System and Applications . . . . . 5 65 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 6 66 7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 6 67 8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 12. Informative References . . . . . . . . . . . . . . . . . . . 7 72 Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 9 73 A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 9 74 A.1.1. Indicating that IPv4 connectivity is unavailable . . 9 75 A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 9 76 A.2. Client Connection Establishment Behavior . . . . . . . . 10 77 A.3. Disabling IPv4 in Operating System and Applications . . . 10 78 A.4. Managing Router Identifiers . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 The final phase of the migration to IPv6 is the sunset of IPv4, that 84 is turning off IPv4 definitively on the attached networks and on the 85 upstream networks. 87 Some current implementation behavior makes it hard to sunset IPv4. 88 Additionally, some new features could be added to IPv4 to make its 89 sunsetting easier. This document analyzes the current situation and 90 proposes new work in this area. 92 The decision about when to turn off IPv4 is out of scope. This 93 document merely attempts to enumerate the issues one might encounter 94 if that decision is made. 96 2. Related Work 98 [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794], 99 [RFC3795] and [RFC3796] contain surveys of IETF protocols with their 100 IPv4 dependencies. 102 Additionally, although reviews in RFCs 3789-3796 ensured that IETF 103 standards then in use could support IPv6, no IETF-wide effort has 104 been undertaken to ensure that the issues identified in those drafts 105 are all addressed, nor to ensure that standards written after RFC3100 106 (where the previous review efforts stopped) function properly on 107 IPv6-only networks. 109 The IETF needs to ensure that existing standards and protocols have 110 been actively reviewed, and any parity gaps either identified so that 111 they can be fixed, or documented as unnecessary to address because it 112 is unused or superseded by other features. 114 First, the IETF must review RFCs 3789-3796 to ensure that any gaps in 115 specifications identified in these documents and still in active use 116 have been updated as necessary to enable operation in IPv6-only 117 environments (or if no longer in use, are declared historic). 119 Second, the IETF must review documents written after the existing 120 review stopped (according to RFC 3790, this review stopped with 121 approximately RFC 3100) to identify specifications where IPv6-only 122 operation is not possible, and update them as necessary and 123 appropriate, or document why an identified gap is not an issue i.e. 124 not necessary for functional parity with IPv4. 126 This document does not recommend excluding Informational and BCP RFCs 127 as the previous effort did, due to changes in the way that these 128 documents are used and their relative importance in the RFC Series. 129 Instead, any documents that are still active (i.e. not declared 130 historic or obsolete) and the product of IETF consensus (i.e. not a 131 product of the ISE Series) should be included. In addition, the 132 reviews undertaken by RFCs 3789-3796 were looking for "IPv4 133 dependency" or "usage of IPv4 addresses in standards". This document 134 recommends a slightly more specific set of criteria for review. 135 Reviews should include: 137 o Consideration of whether the specification can operate in an 138 environment without IPv4. 140 o Guidance on the use of 32-bit identifiers that are commonly 141 populated by IPv4 addresses. 143 o Consideration of protocols on which specifications depend or 144 interact, to identify indirect dependencies on IPv4. 146 o Consideration of how to migrate from an IPv4 environment to an 147 IPv6 environment. 149 3. Remotely Disabling IPv4 151 3.1. Indicating that IPv4 connectivity is unavailable 153 PROBLEM 1: When an IPv4 node boots and requests an IPv4 address 154 (e.g., using DHCP), it typically interprets the absence 155 of a response as a failure condition even when it is not. 157 PROBLEM 2: Home router devices often identify themselves as default 158 routers in DHCP responses that they send to requests 159 coming from the LAN, even in the absence of IPv4 160 connectivity on the WAN. 162 3.2. Disabling IPv4 in the LAN 164 PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- 165 configure IPv4 addresses [RFC3927] and enable various 166 protocols over IPv4 such as mDNS [RFC6762] and LLMNR 167 [RFC4795]. This can be undesirable for operational or 168 security reasons, since in the absence of IPv4, no 169 monitoring or logging of IPv4 will be in place. 171 PROBLEM 4: IPv4 can be completely disabled on a link by filtering it 172 on the L2 switching device. However, this may not be 173 possible in all cases or may be too complex to deploy. 174 For example, an ISP is often not able to control the L2 175 switching device in the subscriber home network. 177 PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for 178 everything", as described in Section 2.6.2 of [RFC3927]. 179 Applications running on such a host connected to an 180 IPv6-only network will believe that IPv4 connectivity is 181 available, resulting in various bad or sub-optimal 182 behavior patterns. See 183 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further 184 analysis. 186 Some of these problems were described in [RFC2563], which 187 standardized a DHCP option to disable IPv4 address auto- 188 configuration. However, using this option requires running an IPv4 189 DHCP server, which is contrary to the goal of IPv4 sunsetting. 191 4. Client Connection Establishment Behavior 193 PROBLEM 6: Happy Eyeballs [RFC6555] refers to multiple approaches to 194 dual-stack client implementations that try to reduce 195 connection setup delays by trying both IPv4 and IPv6 196 paths simultaneously. Some implementations introduce 197 delays which provide an advantage to IPv6, while others 198 do not [Huston2012]. The latter will pick the fastest 199 path, no matter whether it is over IPv4 or IPv6, 200 directing more traffic over IPv4 than the other kind of 201 implementations. This can prove problematic in the 202 context of IPv4 sunsetting, especially for Carrier-Grade 203 NAT phasing out because CGN does not add significant 204 latency that would make the IPv6 path more preferable. 205 Traffic will therefore continue using the CGN path unless 206 other network conditions change. 208 PROBLEM 7: getaddrinfo() [RFC3493] sends DNS queries for both A and 209 AAAA records regardless of the state of IPv4 or IPv6 210 availability. The AI_ADDRCONFIG flag can be used to 211 change this behavior, but it relies on programmers using 212 the getaddrinfo() function to always pass this flag to 213 the function. The current situation is that in an 214 IPv6-only environment, many useless A queries are made. 216 5. Disabling IPv4 in Operating System and Applications 218 It is possible to completely remove IPv4 support from an operating 219 system as has been shown by the work of Bjoern Zeeb on FreeBSD. 220 [Zeeb] Removing IPv4 support in the kernel revealed many IPv4 221 dependencies in libraries and applications. 223 PROBLEM 8: Completely disabling IPv4 at runtime often reveals 224 implementation bugs. Hard-coded dependencies on IPv4 225 abound, such as on the 127.0.0.1 address assigned to the 226 loopback interface, and legacy IPv4-only APIs are widely 227 used by applications. It is hard for the administrators 228 and users to know what applications running on the 229 operating system have implementation problems of IPv4 230 dependency. It is therefore often operationally 231 impossible to completely disable IPv4 on individual 232 nodes. 234 PROBLEM 9: In an IPv6-only world, legacy IPv4 code in operating 235 systems and applications incurs a maintenance overhead 236 and can present security risks. 238 6. On-Demand Provisioning of IPv4 Addresses 240 As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers 241 will become smaller. This could be exploited by an ISP to save IPv4 242 addresses by provisioning them on-demand to subscribers and 243 reclaiming them when they are no longer used. This idea is described 244 in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the 245 context of PPP sessions. In these scenarios, the home router is 246 responsible for requesting and releasing IPv4 addresses, based on 247 snooping the traffic generated by the hosts in the LAN, which are 248 still dual-stack and unaware that their traffic is being snooped. 250 PROBLEM 10: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] 251 will generate both IPv4 and IPv6 traffic even if the 252 algorithm end up chooosing IPv6. This means that an IPv4 253 address will always be requested by the home router, 254 which defeats the purpose of on-demand provisioning. 256 PROBLEM 11: Many operating systems periodically perform some kind of 257 network connectivity check as long as an interface is up. 258 Similarly, applications often send keep-alive traffic 259 continuously. This permanent "background noise" will 260 prevent an IPv4 address from being released by the home 261 router. 263 PROBLEM 12: Hosts in the LAN have no knowledge that IPv4 is available 264 to them on-demand only. If they had explicit knowledge 265 of this fact, they could tune their behaviour so as to be 266 more conservative in their use of IPv4. 268 PROBLEM 13: This mechanism is only being proposed for PPP even though 269 it could apply to other provisioning protocols (e.g., 270 DHCP). 272 7. IPv4 Address Literals 274 IPv4 addresses are often used as resource locators. For example, it 275 is common to encounter URLs containing IPv4 address literals on web 276 sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address 277 literals may be published on media other than web sites, and may 278 appear in various forms other than URLs. For the operating systems 279 which exhibit the behavior described in 280 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an 281 increase in the broadcast ARP traffic, which may be undesirable. 283 PROBLEM 14: IPv6-only hosts are unable to access resources identified 284 by IPv4 address literals. 286 8. Managing Router Identifiers 288 IPv4 addresses are often conventionally chosen to number a router ID, 289 which is used to identify a system running a specific protocol. The 290 common practice of tying an ID to an IPv4 address gives much 291 operational convenience. A human-readable ID is easy for network 292 operators to deal with, and it can be auto-configured, saving the 293 work of planning and assignment. It is also helpful to quickly 294 perform diagnosis and troubleshooting, and easy to identify the 295 availability and location of the identified router. 297 PROBLEM 15: In an IPv6 only network, there is no IP address that can 298 be directly used to number a router ID. IDs have to be 299 planned individually to meet the uniqueness requirement. 300 Tying the ID directly to an IP address which yields 301 human-friendly, auto-configured ID that helps with 302 troubleshooting is not possible. 304 9. IANA Considerations 306 None. 308 10. Security Considerations 310 It is believed that none of the problems identified in this draft are 311 security issues. 313 11. Acknowledgements 315 Thanks in particular to Andrew Yourtchenko, Lee Howard, Nejc 316 Skoberne, and Wes George for their thorough reviews and comments. 318 Special thanks to Marc Blanchet who was the driving force behind this 319 work and to Jean-Philippe Dionne who helped with the initial version 320 of this document. 322 12. Informative References 324 [BBF.TR242] 325 Broadband Forum, "TR-242: IPv6 Transition Mechanisms for 326 Broadband Networks", August 2012. 328 [Huston2012] 329 Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual 330 Stack Behaviour and IPv6 Quality", April 2012. 332 [I-D.fleischhauer-ipv4-addr-saving] 333 Fleischhauer, K. and O. Bonness, "On demand IPv4 address 334 provisioning in Dual-Stack PPP deployment scenarios", 335 draft-fleischhauer-ipv4-addr-saving-05 (work in progress), 336 September 2013. 338 [I-D.wing-behave-http-ip-address-literals] 339 Wing, D., "Coping with IP Address Literals in HTTP URIs 340 with IPv6/IPv4 Translators", draft-wing-behave-http-ip- 341 address-literals-02 (work in progress), March 2010. 343 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] 344 Yourtchenko, A. and O. Owen, "Disable "Proxy ARP for 345 Everything" on IPv4 link-local in the presence of IPv6 346 global address", draft-yourtchenko-ipv6-disable- 347 ipv4-proxyarp-00 (work in progress), May 2013. 349 [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- 350 Configuration in IPv4 Clients", RFC 2563, May 1999. 352 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 353 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 354 3493, February 2003. 356 [RFC3789] Nesser, P. and A. Bergstrom, "Introduction to the Survey 357 of IPv4 Addresses in Currently Deployed IETF Standards 358 Track and Experimental Documents", RFC 3789, June 2004. 360 [RFC3790] Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in 361 Currently Deployed IETF Internet Area Standards Track and 362 Experimental Documents", RFC 3790, June 2004. 364 [RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in 365 Currently Deployed IETF Routing Area Standards Track and 366 Experimental Documents", RFC 3791, June 2004. 368 [RFC3792] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 369 Currently Deployed IETF Security Area Standards Track and 370 Experimental Documents", RFC 3792, June 2004. 372 [RFC3793] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 373 Currently Deployed IETF Sub-IP Area Standards Track and 374 Experimental Documents", RFC 3793, June 2004. 376 [RFC3794] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 377 Currently Deployed IETF Transport Area Standards Track and 378 Experimental Documents", RFC 3794, June 2004. 380 [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in 381 Currently Deployed IETF Application Area Standards Track 382 and Experimental Documents", RFC 3795, June 2004. 384 [RFC3796] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 385 Currently Deployed IETF Operations & Management Area 386 Standards Track and Experimental Documents", RFC 3796, 387 June 2004. 389 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 390 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 391 2005. 393 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 394 Multicast Name Resolution (LLMNR)", RFC 4795, January 395 2007. 397 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 398 Dual-Stack Hosts", RFC 6555, April 2012. 400 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 401 February 2013. 403 [Zeeb] "FreeBSD Snapshots without IPv4 support", 404 . 406 Appendix A. Solution Ideas 408 A.1. Remotely Disabling IPv4 410 A.1.1. Indicating that IPv4 connectivity is unavailable 412 One way to address these issues is to send a signal to a dual-stack 413 node that IPv4 connectivity is unavailable. Given that IPv4 shall be 414 off, the message must be delivered through IPv6. 416 A.1.2. Disabling IPv4 in the LAN 418 One way to address these issues is to send a signal to a dual-stack 419 node that auto-configuration of IPv4 addresses is undesirable, or 420 that direct IPv4 communication between nodes on the same link should 421 not take place. 423 A signalling protocol equivalent to the one from [RFC2563] but over 424 IPv6 is necessary, using either Router Advertisements or DHCPv6. 426 Furthermore, it could be useful to have L2 switches snoop this 427 signalling and automatically start filtering IPv4 traffic as a 428 consequence. 430 Finally, it could be useful to publish guidelines on how to safely 431 block IPv4 on an L2 switch. 433 A.2. Client Connection Establishment Behavior 435 Recommendations on client connection establishment behavior that 436 would facilitate IPv4 sunsetting would be appropriate. 438 A.3. Disabling IPv4 in Operating System and Applications 440 It would be useful for the IETF to provide guidelines to programmers 441 on how to avoid creating dependencies on IPv4, how to discover 442 existing dependencies, and how to eliminate them. It would be useful 443 if operating systems provide functions for users to see what 444 applications uses legacy IPv4-only APIs, so they can know it better 445 whether they can turn off IPv4 completely. Having programs and 446 operating systems that behave well in an IPv6-only environment is a 447 prerequisite for IPv4 sunsetting. 449 A.4. Managing Router Identifiers 451 Router IDs can be manually planned, possibly with some hierarchy or 452 design rule, or can be created automatically. A simple way of 453 automatic creation is to generate pseudo-random numbers, and one can 454 use another source of data such as the clock time at boot or 455 configuration time to provide additional entropy during the 456 generation of unique IDs. Another way is to hash an IPv6 address 457 down to a value as ID. The hash algorithm is supposed to be known 458 and the same across the domain. Since typically the number of 459 routers in a domain is far smaller than the value range of IDs, the 460 hashed IDs are hardly likely to conflict with each other, as long as 461 the hash algorithm is not designed too badly. It is necessary to be 462 able to override the automatically created value, and desirable if 463 the mechanism is provided by the system implementation. 465 If the ID is created from IPv6 address, e.g. by hashing from an IPv6 466 address, then naturally it has relationship with the address. If the 467 ID is created regardless of IP address, one way to build association 468 with IPv6 address is to embed the ID into an IPv6 address that is to 469 be configured on the router, e.g. use a /96 IPv6 prefix and append it 470 with a 32-bit long ID. One can also use some record keeping 471 mechanisms, e.g. text file, DNS or other provisioning system like 472 network management system to manage the IDs and mapping relations 473 with IPv6 addresses, though extra record keeping does introduce 474 additional work. 476 Authors' Addresses 478 Will(Shucheng) Liu 479 Huawei Technologies 480 Bantian, Longgang District 481 Shenzhen 518129 482 P.R. China 484 Email: liushucheng@huawei.com 486 Weiping Xu 487 Huawei Technologies 488 Bantian, Longgang District 489 Shenzhen 518129 490 P.R. China 492 Email: xuweiping@huawei.com 494 Cathy Zhou 495 Huawei Technologies 496 Huawei Industrial Base 497 Bantian, Shenzhen 498 China 500 Email: cathy.zhou@huawei.com 502 Tina Tsou 503 Philips Lighting 504 United States of America 506 Email: tina.tsou@philips.com 508 Simon Perreault 509 Jive Communications 510 Quebec, QC 511 Canada 513 Email: sperreault@jive.com 515 Peng Fan 516 China Mobile 517 32 Xuanwumen West Street 518 Beijing, Beijing 519 China 521 Email: fanp08@gmail.com