idnits 2.17.1 draft-dionne-sunset4-v4gapanalysis-00.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 (July 4, 2012) is 4313 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group JP. Dionne 3 Internet-Draft S. Perreault 4 Intended status: Informational Viagenie 5 Expires: January 5, 2013 T. Tsou 6 Huawei Technologies (USA) 7 July 4, 2012 9 Gap Analysis for IPv4 Sunset 10 draft-dionne-sunset4-v4gapanalysis-00 12 Abstract 14 Sunsetting IPv4 refers to the process of turning off IPv4 15 definitively. It can be seen as the final phase of the migration to 16 IPv6. This memo analyses difficulties arising when sunsetting IPv4, 17 and identifies the gaps resulting in additional work. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 5, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Indicating that IPv4 connectivity is unavailable . . . . . 3 57 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . . 3 58 4. Client Connection Establishment Behavior . . . . . . . . . . . 4 59 5. Disabling IPv4 in Operating System and Applications . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 9. Informative References . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 The final phase of the migration to IPv6 is the sunset of IPv4, that 69 is turning off IPv4 definitively on the attached networks and on the 70 upstream networks. 72 Some current implementations behavior make it hard to sunset IPv4. 73 Additionally, some new features could be added to IPv4 to make its 74 sunsetting easier. This document analyzes the current situation and 75 proposes new work in this area. 77 2. Related Work 79 [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794], 80 [RFC3795] and [RFC3796] contain surveys of IETF protocols with their 81 IPv4 dependencies. 83 3. Remotely Disabling IPv4 85 3.1. Indicating that IPv4 connectivity is unavailable 87 PROBLEM 1: When an IPv4 node boots and requests an IPv4 address 88 (e.g., using DHCP), it typically interprets the absence 89 of a response as a failure condition even when it is not. 91 PROBLEM 2: Home router devices often identify themselves as default 92 routers in DHCP responses that they send to requests 93 coming from the LAN, even in the absence of IPv4 94 connectivity on the WAN. 96 One way to address these issues is to send a signal to an dual-stack 97 node that IPv4 connectivity is unavailable. Given that IPv4 shall be 98 off, the message must be delivered through IPv6. 100 3.2. Disabling IPv4 in the LAN 102 PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- 103 configure IPv4 addresses [RFC3927] and enable various 104 protocols over IPv4 such as mDNS 105 [I-D.cheshire-dnsext-multicastdns] and LLMNR [RFC4795]. 106 This can be undesirable for operational or security 107 reasons, since in the absence of IPv4, no monitoring or 108 logging of IPv4 will be in place. 110 PROBLEM 4: IPv4 can be completely disabled on a link by filtering it 111 on the L2 switching device. However, this may not be 112 possible in all cases or complex to deploy. For example, 113 an ISP is often not able to control the L2 switching 114 device in the subscriber home network. 116 One way to address these issues is to send a signal to an dual-stack 117 node that auto-configuration of IPv4 addresses is undesirable, or 118 that direct IPv4 communications between nodes on the same link should 119 not take place. 121 This problem was described in [RFC2563], which standardized a DHCP 122 option to disable IPv4 address auto-configuration. However, using 123 this option requires running an IPv4 DHCP server, which is contrary 124 to the goal of IPv4 sunsetting. An equivalent way of signalling this 125 over IPv6 is necessary,, using either Router Advertisements or 126 DHCPv6. 128 Furthermore, it could be useful to have L2 switches snoop this 129 signalling and automatically start filtering IPv4 traffic as a 130 consequence. 132 Finally, it could be useful to publish guidelines on how to safely 133 block IPv4 on an L2 switch. 135 4. Client Connection Establishment Behavior 137 PROBLEM 5: Happy Eyeballs [RFC6555] refers to the multiple 138 approaches to dual-stack client implementations that try 139 to reduce connection setup delays by trying both IPv4 and 140 IPv6 paths simultaneously. Some implementations 141 introduce delays which provide an advantage to IPv6, 142 while others do not [Huston2012]. The latter will pick 143 the fastest path, no matter whether it is over IPv4 or 144 IPv6, directing more traffic over IPv4 than the other 145 kind of implementations. This can prove problematic in 146 the context of IPv4 sunsetting, especially for Carrier- 147 Grade NAT phasing out. 149 PROBLEM 6: getaddrinfo() [RFC3493] sends DNS queries for both A and 150 AAAA records regardless of the state of IPv4 or IPv6 151 availability. The AI_ADDRCONFIG flag can be used to 152 change this behavior, but it relies on programmers using 153 the getaddrinfo() function to always pass this flag to 154 the function. The current situation is that in an IPv6- 155 only environment, many useless A queries are made. 157 Recommendations on client connection establishment behavior that 158 would facilitate IPv4 sunsetting is therefore appropriate. 160 5. Disabling IPv4 in Operating System and Applications 162 PROBLEM 7: Completely disabling IPv4 at runtime often reveals 163 implementation bugs. Hard-coded dependencies on IPv4 164 abound, such as on the 127.0.0.1 address assigned to the 165 loopback interface. It is therefore often operationally 166 impossible to completely disable IPv4 on individual 167 nodes. 169 PROBLEM 8: In an IPv6-only world, legacy IPv4 code in operating 170 systems and applications incurs a maintenance overhead 171 and can present security risks. 173 It is possible to completely remove IPv4 support from an operating 174 system as has been shown by the work of Bjoern Zeeb on FreeBSD. 175 [Zeeb] Removing IPv4 support in the kernel revealed many IPv4 176 dependencies in libraries and applications. 178 It would be useful for the IETF to provide guidelines to programmers 179 on how to avoid creating dependencies on IPv4, how to discover 180 existing dependencies, and how to eliminate them. Having programs 181 and operating systems that behave well in an IPv6-only environment is 182 a prerequisite for IPv4 sunsetting. 184 6. IANA Considerations 186 None. 188 7. Security Considerations 190 TODO 192 8. Acknowledgements 194 TODO 196 9. Informative References 198 [Huston2012] 199 Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual 200 Stack Behaviour and IPv6 Quality", April 2012. 202 [I-D.cheshire-dnsext-multicastdns] 203 Cheshire, S. and M. Krochmal, "Multicast DNS", 204 draft-cheshire-dnsext-multicastdns-15 (work in progress), 205 December 2011. 207 [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- 208 Configuration in IPv4 Clients", RFC 2563, May 1999. 210 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 211 Stevens, "Basic Socket Interface Extensions for IPv6", 212 RFC 3493, February 2003. 214 [RFC3789] Nesser, P. and A. Bergstrom, "Introduction to the Survey 215 of IPv4 Addresses in Currently Deployed IETF Standards 216 Track and Experimental Documents", RFC 3789, June 2004. 218 [RFC3790] Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in 219 Currently Deployed IETF Internet Area Standards Track and 220 Experimental Documents", RFC 3790, June 2004. 222 [RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in 223 Currently Deployed IETF Routing Area Standards Track and 224 Experimental Documents", RFC 3791, June 2004. 226 [RFC3792] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 227 Currently Deployed IETF Security Area Standards Track and 228 Experimental Documents", RFC 3792, June 2004. 230 [RFC3793] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 231 Currently Deployed IETF Sub-IP Area Standards Track and 232 Experimental Documents", RFC 3793, June 2004. 234 [RFC3794] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 235 Currently Deployed IETF Transport Area Standards Track and 236 Experimental Documents", RFC 3794, June 2004. 238 [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in 239 Currently Deployed IETF Application Area Standards Track 240 and Experimental Documents", RFC 3795, June 2004. 242 [RFC3796] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 243 Currently Deployed IETF Operations & Management Area 244 Standards Track and Experimental Documents", RFC 3796, 245 June 2004. 247 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 248 Configuration of IPv4 Link-Local Addresses", RFC 3927, 249 May 2005. 251 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 252 Multicast Name Resolution (LLMNR)", RFC 4795, 253 January 2007. 255 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 256 Dual-Stack Hosts", RFC 6555, April 2012. 258 [Zeeb] "FreeBSD Snapshots without IPv4 support", 259 . 261 Authors' Addresses 263 Jean-Philippe Dionne 264 Viagenie 265 246 Aberdeen 266 Quebec, QC G1R 2E1 267 Canada 269 Phone: +1 418 656 9254 270 Email: jean-philippe.dionne@viagenie.ca 271 URI: http://viagenie.ca 273 Simon Perreault 274 Viagenie 275 246 Aberdeen 276 Quebec, QC G1R 2E1 277 Canada 279 Phone: +1 418 656 9254 280 Email: simon.perreault@viagenie.ca 281 URI: http://viagenie.ca 283 Tina Tsou 284 Huawei Technologies (USA) 285 2330 Central Expressway 286 Santa Clara, CA 95050 287 USA 289 Phone: +1 408 330 4424 290 Email: tina.tsou.zouting@huawei.com