idnits 2.17.1 draft-ietf-sunset4-gapanalysis-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 : ---------------------------------------------------------------------------- == 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 (January 26, 2015) is 3377 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-fleischhauer-ipv4-addr-saving-03 -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault 3 Internet-Draft Jive Communications 4 Intended status: Informational T. Tsou 5 Expires: July 30, 2015 Huawei Technologies (USA) 6 C. Zhou 7 Huawei Technologies 8 P. Fan 9 China Mobile 10 January 26, 2015 12 Gap Analysis for IPv4 Sunset 13 draft-ietf-sunset4-gapanalysis-05 15 Abstract 17 Sunsetting IPv4 refers to the process of turning off IPv4 18 definitively. It can be seen as the final phase of the migration to 19 IPv6. This memo enumerates difficulties arising when sunsetting 20 IPv4, and identifies the gaps requiring additional work. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 30, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 3 59 3.1. Indicating that IPv4 connectivity is unavailable . . . . 3 60 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 3 61 4. Client Connection Establishment Behavior . . . . . . . . . . 4 62 5. Disabling IPv4 in Operating System and Applications . . . . . 4 63 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 4 64 7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 5 65 8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 5 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 12. Informative References . . . . . . . . . . . . . . . . . . . 6 70 Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 8 71 A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 8 72 A.1.1. Indicating that IPv4 connectivity is unavailable . . 8 73 A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 8 74 A.2. Client Connection Establishment Behavior . . . . . . . . 9 75 A.3. Disabling IPv4 in Operating System and Applications . . . 9 76 A.4. On-Demand Provisioning of IPv4 Addresses . . . . . . . . 9 77 A.5. Managing Router Identifiers . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The final phase of the migration to IPv6 is the sunset of IPv4, that 83 is turning off IPv4 definitively on the attached networks and on the 84 upstream networks. 86 Some current implementation behavior makes it hard to sunset IPv4. 87 Additionally, some new features could be added to IPv4 to make its 88 sunsetting easier. This document analyzes the current situation and 89 proposes new work in this area. 91 The decision about when to turn off IPv4 is out of scope. This 92 document merely attempts to enumerate the issues one might encounter 93 if that decision is made. 95 2. Related Work 97 [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794], 98 [RFC3795] and [RFC3796] contain surveys of IETF protocols with their 99 IPv4 dependencies. 101 3. Remotely Disabling IPv4 103 3.1. Indicating that IPv4 connectivity is unavailable 105 PROBLEM 1: When an IPv4 node boots and requests an IPv4 address 106 (e.g., using DHCP), it typically interprets the absence 107 of a response as a failure condition even when it is not. 109 PROBLEM 2: Home router devices often identify themselves as default 110 routers in DHCP responses that they send to requests 111 coming from the LAN, even in the absence of IPv4 112 connectivity on the WAN. 114 3.2. Disabling IPv4 in the LAN 116 PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- 117 configure IPv4 addresses [RFC3927] and enable various 118 protocols over IPv4 such as mDNS 119 [I-D.cheshire-dnsext-multicastdns] and LLMNR [RFC4795]. 120 This can be undesirable for operational or security 121 reasons, since in the absence of IPv4, no monitoring or 122 logging of IPv4 will be in place. 124 PROBLEM 4: IPv4 can be completely disabled on a link by filtering it 125 on the L2 switching device. However, this may not be 126 possible in all cases or may be too complex to deploy. 127 For example, an ISP is often not able to control the L2 128 switching device in the subscriber home network. 130 PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for 131 everything", as described in Section 2.6.2 of [RFC3927]. 132 Applications running on such a host connected to an 133 IPv6-only network will believe that IPv4 connectivity is 134 available, resulting in various bad or sub-optimal 135 behavior patterns. See 136 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further 137 analysis. 139 Some of these problems were described in [RFC2563], which 140 standardized a DHCP option to disable IPv4 address auto- 141 configuration. However, using this option requires running an IPv4 142 DHCP server, which is contrary to the goal of IPv4 sunsetting. 144 4. Client Connection Establishment Behavior 146 PROBLEM 6: Happy Eyeballs [RFC6555] refers to multiple approaches to 147 dual-stack client implementations that try to reduce 148 connection setup delays by trying both IPv4 and IPv6 149 paths simultaneously. Some implementations introduce 150 delays which provide an advantage to IPv6, while others 151 do not [Huston2012]. The latter will pick the fastest 152 path, no matter whether it is over IPv4 or IPv6, 153 directing more traffic over IPv4 than the other kind of 154 implementations. This can prove problematic in the 155 context of IPv4 sunsetting, especially for Carrier-Grade 156 NAT phasing out because CGN does not add significant 157 latency that would make the IPv6 path more preferable. 158 Traffic will therefore continue using the CGN path unless 159 other network conditions change. 161 PROBLEM 7: getaddrinfo() [RFC3493] sends DNS queries for both A and 162 AAAA records regardless of the state of IPv4 or IPv6 163 availability. The AI_ADDRCONFIG flag can be used to 164 change this behavior, but it relies on programmers using 165 the getaddrinfo() function to always pass this flag to 166 the function. The current situation is that in an 167 IPv6-only environment, many useless A queries are made. 169 5. Disabling IPv4 in Operating System and Applications 171 It is possible to completely remove IPv4 support from an operating 172 system as has been shown by the work of Bjoern Zeeb on FreeBSD. 173 [Zeeb] Removing IPv4 support in the kernel revealed many IPv4 174 dependencies in libraries and applications. 176 PROBLEM 8: Completely disabling IPv4 at runtime often reveals 177 implementation bugs. Hard-coded dependencies on IPv4 178 abound, such as on the 127.0.0.1 address assigned to the 179 loopback interface. It is therefore often operationally 180 impossible to completely disable IPv4 on individual 181 nodes. 183 PROBLEM 9: In an IPv6-only world, legacy IPv4 code in operating 184 systems and applications incurs a maintenance overhead 185 and can present security risks. 187 6. On-Demand Provisioning of IPv4 Addresses 189 As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers 190 will become smaller. This could be exploited by an ISP to save IPv4 191 addresses by provisioning them on-demand to subscribers and 192 reclaiming them when they are no longer used. This idea is described 193 in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the 194 context of PPP sessions. In these scenarios, the home router is 195 responsible for requesting and releasing IPv4 addresses, based on 196 snooping the traffic generated by the hosts in the LAN, which are 197 still dual-stack and unaware that their traffic is being snooped. 199 PROBLEM 10: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] 200 will generate both IPv4 and IPv6 traffic even if the 201 algorithm end up chooosing IPv6. This means that an IPv4 202 address will always be requested by the home router, 203 which defeats the purpose of on-demand provisioning. 205 PROBLEM 11: Many operating systems periodically perform some kind of 206 network connectivity check as long as an interface is up. 207 Similarly, applications often send keep-alive traffic 208 continuously. This permanent "background noise" will 209 prevent an IPv4 address from being released by the home 210 router. 212 PROBLEM 12: Hosts in the LAN have no knowledge that IPv4 is available 213 to them on-demand only. If they had explicit knowledge 214 of this fact, they could tune their behaviour so as to be 215 more conservative in their use of IPv4. 217 PROBLEM 13: This mechanism is only being proposed for PPP even though 218 it could apply to other provisioning protocols (e.g., 219 DHCP). 221 7. IPv4 Address Literals 223 IPv4 addresses are often used as resource locators. For example, it 224 is common to encounter URLs containing IPv4 address literals on web 225 sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address 226 literals may be published on media other than web sites, and may 227 appear in various forms other than URLs. For the operating systems 228 which exhibit the behavior described in 229 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an 230 increase in the broadcast ARP traffic, which may be undesirable. 232 PROBLEM 14: IPv6-only hosts are unable to access resources identified 233 by IPv4 address literals. 235 8. Managing Router Identifiers 237 IPv4 addresses are often conventionally chosen to number a router ID, 238 which is used to identify a system running a specific protocol. The 239 common practice of tying an ID to an IPv4 address gives much 240 operational convenience. A human-readable ID is easy for network 241 operators to deal with, and it can be auto-configured, saving the 242 work of planning and assignment. It is also helpful to quickly 243 perform diagnosis and troubleshooting, and easy to identify the 244 availability and location of the identified router. 246 PROBLEM 15: In an IPv6 only network, there is no IP address that can 247 be directly used to number a router ID. IDs have to be 248 planned individually to meet the uniqueness requirement. 249 Tying the ID directly to an IP address which yields 250 human-friendly, auto-configured ID that helps with 251 troubleshooting is not possible. 253 9. IANA Considerations 255 None. 257 10. Security Considerations 259 It is believed that none of the problems identified in this draft are 260 security issues. 262 11. Acknowledgements 264 Thanks in particular to Andrew Yourtchenko, Lee Howard, Nejc 265 Skoberne, and Wes George for their thorough reviews and comments. 267 Special thanks to Marc Blanchet who was the driving force behind this 268 work and to Jean-Philippe Dionne who helped with the initial version 269 of this document. 271 12. Informative References 273 [BBF.TR242] 274 Broadband Forum, "TR-242: IPv6 Transition Mechanisms for 275 Broadband Networks", August 2012. 277 [Huston2012] 278 Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual 279 Stack Behaviour and IPv6 Quality", April 2012. 281 [I-D.cheshire-dnsext-multicastdns] 282 Cheshire, S. and M. Krochmal, "Multicast DNS", draft- 283 cheshire-dnsext-multicastdns-15 (work in progress), 284 December 2011. 286 [I-D.fleischhauer-ipv4-addr-saving] 287 Fleischhauer, K. and O. Bonness, "On demand IPv4 address 288 provisioning in Dual-Stack PPP deployment scenarios", 289 draft-fleischhauer-ipv4-addr-saving-03 (work in progress), 290 August 2012. 292 [I-D.wing-behave-http-ip-address-literals] 293 Wing, D., "Coping with IP Address Literals in HTTP URIs 294 with IPv6/IPv4 Translators", draft-wing-behave-http-ip- 295 address-literals-02 (work in progress), March 2010. 297 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] 298 Yourtchenko, A. and O. Owen, "Disable "Proxy ARP for 299 Everything" on IPv4 link-local in the presence of IPv6 300 global address", draft-yourtchenko-ipv6-disable- 301 ipv4-proxyarp-00 (work in progress), May 2013. 303 [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- 304 Configuration in IPv4 Clients", RFC 2563, May 1999. 306 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 307 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 308 3493, February 2003. 310 [RFC3789] Nesser, P. and A. Bergstrom, "Introduction to the Survey 311 of IPv4 Addresses in Currently Deployed IETF Standards 312 Track and Experimental Documents", RFC 3789, June 2004. 314 [RFC3790] Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in 315 Currently Deployed IETF Internet Area Standards Track and 316 Experimental Documents", RFC 3790, June 2004. 318 [RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in 319 Currently Deployed IETF Routing Area Standards Track and 320 Experimental Documents", RFC 3791, June 2004. 322 [RFC3792] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 323 Currently Deployed IETF Security Area Standards Track and 324 Experimental Documents", RFC 3792, June 2004. 326 [RFC3793] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 327 Currently Deployed IETF Sub-IP Area Standards Track and 328 Experimental Documents", RFC 3793, June 2004. 330 [RFC3794] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 331 Currently Deployed IETF Transport Area Standards Track and 332 Experimental Documents", RFC 3794, June 2004. 334 [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in 335 Currently Deployed IETF Application Area Standards Track 336 and Experimental Documents", RFC 3795, June 2004. 338 [RFC3796] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 339 Currently Deployed IETF Operations & Management Area 340 Standards Track and Experimental Documents", RFC 3796, 341 June 2004. 343 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 344 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 345 2005. 347 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 348 Multicast Name Resolution (LLMNR)", RFC 4795, January 349 2007. 351 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 352 Dual-Stack Hosts", RFC 6555, April 2012. 354 [Zeeb] "FreeBSD Snapshots without IPv4 support", 355 . 357 Appendix A. Solution Ideas 359 A.1. Remotely Disabling IPv4 361 A.1.1. Indicating that IPv4 connectivity is unavailable 363 One way to address these issues is to send a signal to a dual-stack 364 node that IPv4 connectivity is unavailable. Given that IPv4 shall be 365 off, the message must be delivered through IPv6. 367 A.1.2. Disabling IPv4 in the LAN 369 One way to address these issues is to send a signal to a dual-stack 370 node that auto-configuration of IPv4 addresses is undesirable, or 371 that direct IPv4 communication between nodes on the same link should 372 not take place. 374 A signalling protocol equivalent to the one from [RFC2563] but over 375 IPv6 is necessary, using either Router Advertisements or DHCPv6. 377 Furthermore, it could be useful to have L2 switches snoop this 378 signalling and automatically start filtering IPv4 traffic as a 379 consequence. 381 Finally, it could be useful to publish guidelines on how to safely 382 block IPv4 on an L2 switch. 384 A.2. Client Connection Establishment Behavior 386 Recommendations on client connection establishment behavior that 387 would facilitate IPv4 sunsetting would be appropriate. 389 A.3. Disabling IPv4 in Operating System and Applications 391 It would be useful for the IETF to provide guidelines to programmers 392 on how to avoid creating dependencies on IPv4, how to discover 393 existing dependencies, and how to eliminate them. Having programs 394 and operating systems that behave well in an IPv6-only environment is 395 a prerequisite for IPv4 sunsetting. 397 A.4. On-Demand Provisioning of IPv4 Addresses 399 No idea. 401 A.5. Managing Router Identifiers 403 Router IDs can be manually planned, possibly with some hierarchy or 404 design rule, or can be created automatically. A simple way of 405 automatic creation is to generate pseudo-random numbers, and one can 406 use another source of data such as the clock time at boot or 407 configuration time to provide additional entropy during the 408 generation of unique IDs. Another way is to hash an IPv6 address 409 down to a value as ID. The hash algorithm is supposed to be known 410 and the same across the domain. Since typically the number of 411 routers in a domain is far smaller than the value range of IDs, the 412 hashed IDs are hardly likely to conflict with each other, as long as 413 the hash algorithm is not designed too badly. It is necessary to be 414 able to override the automatically created value, and desirable if 415 the mechanism is provided by the system implementation. 417 If the ID is created from IPv6 address, e.g. by hashing from an IPv6 418 address, then naturally it has relationship with the address. If the 419 ID is created regardless of IP address, one way to build association 420 with IPv6 address is to embed the ID into an IPv6 address that is to 421 be configured on the router, e.g. use a /96 IPv6 prefix and append it 422 with a 32-bit long ID. One can also use some record keeping 423 mechanisms, e.g. text file, DNS or other provisioning system like 424 network management system to manage the IDs and mapping relations 425 with IPv6 addresses, though extra record keeping does introduce 426 additional work. 428 Authors' Addresses 430 Simon Perreault 431 Jive Communications 432 Quebec, QC 433 Canada 435 Email: sperreault@jive.com 437 Tina Tsou 438 Huawei Technologies (USA) 439 2330 Central Expressway 440 Santa Clara, CA 95050 441 USA 443 Phone: +1 408 330 4424 444 Email: tina.tsou.zouting@huawei.com 446 Cathy Zhou 447 Huawei Technologies 448 Huawei Industrial Base 449 Bantian, Shenzhen 450 China 452 Email: cathy.zhou@huawei.com 454 Peng Fan 455 China Mobile 456 32 Xuanwumen West Street 457 Beijing, Beijing 458 China 460 Email: fanp08@gmail.com