draft-ietf-sunset4-gapanalysis-01.txt   draft-ietf-sunset4-gapanalysis-02.txt 
Network Working Group JP. Dionne Network Working Group JP. Dionne
Internet-Draft S. Perreault Internet-Draft S. Perreault
Intended status: Informational Viagenie Intended status: Informational Viagenie
Expires: April 25, 2013 T. Tsou Expires: August 26, 2013 T. Tsou
Huawei Technologies (USA) Huawei Technologies (USA)
C. Zhou C. Zhou
Huawei Technologies Huawei Technologies
October 22, 2012 February 22, 2013
Gap Analysis for IPv4 Sunset Gap Analysis for IPv4 Sunset
draft-ietf-sunset4-gapanalysis-01 draft-ietf-sunset4-gapanalysis-02
Abstract Abstract
Sunsetting IPv4 refers to the process of turning off IPv4 Sunsetting IPv4 refers to the process of turning off IPv4
definitively. It can be seen as the final phase of the migration to definitively. It can be seen as the final phase of the migration to
IPv6. This memo analyses difficulties arising when sunsetting IPv4, IPv6. This memo enumerates difficulties arising when sunsetting
and identifies the gaps resulting in additional work. IPv4, and identifies the gaps requiring additional work.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on August 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . . 3 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 2
3.1. Indicating that IPv4 connectivity is unavailable . . . . . 3 3.1. Indicating that IPv4 connectivity is unavailable . . . . 3
3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . . 3 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 3
4. Client Connection Establishment Behavior . . . . . . . . . . . 4 4. Client Connection Establishment Behavior . . . . . . . . . . 4
5. Disabling IPv4 in Operating System and Applications . . . . . . 5 5. Disabling IPv4 in Operating System and Applications . . . . . 4
6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . . 5 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
10. Informative References . . . . . . . . . . . . . . . . . . . . 6 10. Informative References . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The final phase of the migration to IPv6 is the sunset of IPv4, that The final phase of the migration to IPv6 is the sunset of IPv4, that
is turning off IPv4 definitively on the attached networks and on the is turning off IPv4 definitively on the attached networks and on the
upstream networks. upstream networks.
Some current implementations behavior make it hard to sunset IPv4. Some current implementation behavior makes it hard to sunset IPv4.
Additionally, some new features could be added to IPv4 to make its Additionally, some new features could be added to IPv4 to make its
sunsetting easier. This document analyzes the current situation and sunsetting easier. This document analyzes the current situation and
proposes new work in this area. proposes new work in this area.
The decision about when to turn off IPv4 is out of scope. This
document merely attempts to enumerate the issues one might encounter
if that decision is made.
2. Related Work 2. Related Work
[RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794], [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794],
[RFC3795] and [RFC3796] contain surveys of IETF protocols with their [RFC3795] and [RFC3796] contain surveys of IETF protocols with their
IPv4 dependencies. IPv4 dependencies.
3. Remotely Disabling IPv4 3. Remotely Disabling IPv4
3.1. Indicating that IPv4 connectivity is unavailable 3.1. Indicating that IPv4 connectivity is unavailable
PROBLEM 1: When an IPv4 node boots and requests an IPv4 address PROBLEM 1: When an IPv4 node boots and requests an IPv4 address
(e.g., using DHCP), it typically interprets the absence (e.g., using DHCP), it typically interprets the absence of a
of a response as a failure condition even when it is not. response as a failure condition even when it is not.
PROBLEM 2: Home router devices often identify themselves as default PROBLEM 2: Home router devices often identify themselves as default
routers in DHCP responses that they send to requests routers in DHCP responses that they send to requests coming from
coming from the LAN, even in the absence of IPv4 the LAN, even in the absence of IPv4 connectivity on the WAN.
connectivity on the WAN.
One way to address these issues is to send a signal to an dual-stack One way to address these issues is to send a signal to a dual-stack
node that IPv4 connectivity is unavailable. Given that IPv4 shall be node that IPv4 connectivity is unavailable. Given that IPv4 shall be
off, the message must be delivered through IPv6. off, the message must be delivered through IPv6.
3.2. Disabling IPv4 in the LAN 3.2. Disabling IPv4 in the LAN
PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto-
configure IPv4 addresses [RFC3927] and enable various configure IPv4 addresses [RFC3927] and enable various protocols
protocols over IPv4 such as mDNS over IPv4 such as mDNS [I-D.cheshire-dnsext-multicastdns] and
[I-D.cheshire-dnsext-multicastdns] and LLMNR [RFC4795]. LLMNR [RFC4795]. This can be undesirable for operational or
This can be undesirable for operational or security security reasons, since in the absence of IPv4, no monitoring or
reasons, since in the absence of IPv4, no monitoring or logging of IPv4 will be in place.
logging of IPv4 will be in place.
PROBLEM 4: IPv4 can be completely disabled on a link by filtering it PROBLEM 4: IPv4 can be completely disabled on a link by filtering it
on the L2 switching device. However, this may not be on the L2 switching device. However, this may not be possible in
possible in all cases or complex to deploy. For example, all cases or may be too complex to deploy. For example, an ISP is
an ISP is often not able to control the L2 switching often not able to control the L2 switching device in the
device in the subscriber home network. subscriber home network.
One way to address these issues is to send a signal to an dual-stack One way to address these issues is to send a signal to a dual-stack
node that auto-configuration of IPv4 addresses is undesirable, or node that auto-configuration of IPv4 addresses is undesirable, or
that direct IPv4 communications between nodes on the same link should that direct IPv4 communication between nodes on the same link should
not take place. not take place.
This problem was described in [RFC2563], which standardized a DHCP This problem was described in [RFC2563], which standardized a DHCP
option to disable IPv4 address auto-configuration. However, using option to disable IPv4 address auto-configuration. However, using
this option requires running an IPv4 DHCP server, which is contrary this option requires running an IPv4 DHCP server, which is contrary
to the goal of IPv4 sunsetting. An equivalent way of signalling this to the goal of IPv4 sunsetting. An equivalent way of signalling this
over IPv6 is necessary,, using either Router Advertisements or over IPv6 is necessary, using either Router Advertisements or DHCPv6.
DHCPv6.
Furthermore, it could be useful to have L2 switches snoop this Furthermore, it could be useful to have L2 switches snoop this
signalling and automatically start filtering IPv4 traffic as a signalling and automatically start filtering IPv4 traffic as a
consequence. consequence.
Finally, it could be useful to publish guidelines on how to safely Finally, it could be useful to publish guidelines on how to safely
block IPv4 on an L2 switch. block IPv4 on an L2 switch.
4. Client Connection Establishment Behavior 4. Client Connection Establishment Behavior
PROBLEM 5: Happy Eyeballs [RFC6555] refers to the multiple PROBLEM 5: Happy Eyeballs [RFC6555] refers to multiple approaches to
approaches to dual-stack client implementations that try dual-stack client implementations that try to reduce connection
to reduce connection setup delays by trying both IPv4 and setup delays by trying both IPv4 and IPv6 paths simultaneously.
IPv6 paths simultaneously. Some implementations Some implementations introduce delays which provide an advantage
introduce delays which provide an advantage to IPv6, to IPv6, while others do not [Huston2012]. The latter will pick
while others do not [Huston2012]. The latter will pick the fastest path, no matter whether it is over IPv4 or IPv6,
the fastest path, no matter whether it is over IPv4 or directing more traffic over IPv4 than the other kind of
IPv6, directing more traffic over IPv4 than the other implementations. This can prove problematic in the context of
kind of implementations. This can prove problematic in IPv4 sunsetting, especially for Carrier-Grade NAT phasing out
the context of IPv4 sunsetting, especially for Carrier- because CGN does not add significant latency that would make the
Grade NAT phasing out. IPv6 path more preferable. Traffic will therefore continue using
the CGN path unless other network conditions change.
PROBLEM 6: getaddrinfo() [RFC3493] sends DNS queries for both A and PROBLEM 6: getaddrinfo() [RFC3493] sends DNS queries for both A and
AAAA records regardless of the state of IPv4 or IPv6 AAAA records regardless of the state of IPv4 or IPv6 availability.
availability. The AI_ADDRCONFIG flag can be used to The AI_ADDRCONFIG flag can be used to change this behavior, but it
change this behavior, but it relies on programmers using relies on programmers using the getaddrinfo() function to always
the getaddrinfo() function to always pass this flag to pass this flag to the function. The current situation is that in
the function. The current situation is that in an IPv6- an IPv6-only environment, many useless A queries are made.
only environment, many useless A queries are made.
Recommendations on client connection establishment behavior that Recommendations on client connection establishment behavior that
would facilitate IPv4 sunsetting is therefore appropriate. would facilitate IPv4 sunsetting are therefore appropriate.
5. Disabling IPv4 in Operating System and Applications 5. Disabling IPv4 in Operating System and Applications
PROBLEM 7: Completely disabling IPv4 at runtime often reveals PROBLEM 7: Completely disabling IPv4 at runtime often reveals
implementation bugs. Hard-coded dependencies on IPv4 implementation bugs. Hard-coded dependencies on IPv4 abound, such
abound, such as on the 127.0.0.1 address assigned to the as on the 127.0.0.1 address assigned to the loopback interface.
loopback interface. It is therefore often operationally It is therefore often operationally impossible to completely
impossible to completely disable IPv4 on individual disable IPv4 on individual nodes.
nodes.
PROBLEM 8: In an IPv6-only world, legacy IPv4 code in operating PROBLEM 8: In an IPv6-only world, legacy IPv4 code in operating
systems and applications incurs a maintenance overhead systems and applications incurs a maintenance overhead and can
and can present security risks. present security risks.
It is possible to completely remove IPv4 support from an operating It is possible to completely remove IPv4 support from an operating
system as has been shown by the work of Bjoern Zeeb on FreeBSD. system as has been shown by the work of Bjoern Zeeb on FreeBSD.
[Zeeb] Removing IPv4 support in the kernel revealed many IPv4 [Zeeb] Removing IPv4 support in the kernel revealed many IPv4
dependencies in libraries and applications. dependencies in libraries and applications.
It would be useful for the IETF to provide guidelines to programmers It would be useful for the IETF to provide guidelines to programmers
on how to avoid creating dependencies on IPv4, how to discover on how to avoid creating dependencies on IPv4, how to discover
existing dependencies, and how to eliminate them. Having programs existing dependencies, and how to eliminate them. Having programs
and operating systems that behave well in an IPv6-only environment is and operating systems that behave well in an IPv6-only environment is
skipping to change at page 5, line 44 skipping to change at page 5, line 17
As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers
will become smaller. This could be exploited by an ISP to save IPv4 will become smaller. This could be exploited by an ISP to save IPv4
addresses by provisioning them on-demand to subscribers and addresses by provisioning them on-demand to subscribers and
reclaiming them when they are no longer used. This idea is described reclaiming them when they are no longer used. This idea is described
in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the
context of PPP sessions. In these scenarios, the home router is context of PPP sessions. In these scenarios, the home router is
responsible for requesting and releasing IPv4 addresses, based on responsible for requesting and releasing IPv4 addresses, based on
snooping the traffic generated by the hosts in the LAN, which are snooping the traffic generated by the hosts in the LAN, which are
still dual-stack and unaware that their traffic is being snooped. still dual-stack and unaware that their traffic is being snooped.
PROBLEM 9: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] PROBLEM 9: Dual-stack hosts that implement Happy-Eyeballs [RFC6555]
will generate both IPv4 and IPv6 traffic even if the will generate both IPv4 and IPv6 traffic even if the algorithm end
algorithm end up chooosing IPv6. This means that an up chooosing IPv6. This means that an IPv4 address will always be
IPv4 address will always be requested by the home requested by the home router, which defeats the purpose of on-
router, which defeats the purpose of on-demand demand provisioning.
provisioning.
PROBLEM 10: Many operating systems periodically perform some kind of PROBLEM 10: Many operating systems periodically perform some kind of
network connectivity check as long as an interface is network connectivity check as long as an interface is up.
up. Similarly, applications often send keep-alive Similarly, applications often send keep-alive traffic
traffic continuously. This permanent "background noise" continuously. This permanent "background noise" will prevent an
will prevent an IPv4 address from being released by the IPv4 address from being released by the home router.
home router.
PROBLEM 11: Hosts in the LAN have no knowledge that IPv4 is PROBLEM 11: Hosts in the LAN have no knowledge that IPv4 is available
available to them on-demand only. If they had explicit to them on-demand only. If they had explicit knowledge of this
knowledge of this fact, they could tune their behaviour fact, they could tune their behaviour so as to be more
so as to be more conservative in their use of IPv4. conservative in their use of IPv4.
PROBLEM 12: This mechanism is only being proposed for PPP even PROBLEM 12: This mechanism is only being proposed for PPP even though
though it could apply to other provisioning protocols it could apply to other provisioning protocols (e.g., DHCP).
(e.g., DHCP).
7. IANA Considerations 7. IANA Considerations
None. None.
8. Security Considerations 8. Security Considerations
TODO TODO
9. Acknowledgements 9. Acknowledgements
TODO Thanks in particular to Nejc Skoberne and Lee Howard for their
thorough reviews and comments.
10. Informative References 10. Informative References
[BBF.TR242] [BBF.TR242]
Broadband Forum, "TR-242: IPv6 Transition Mechanisms for Broadband Forum, "TR-242: IPv6 Transition Mechanisms for
Broadband Networks", August 2012. Broadband Networks", August 2012.
[Huston2012] [Huston2012]
Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual
Stack Behaviour and IPv6 Quality", April 2012. Stack Behaviour and IPv6 Quality", April 2012.
[I-D.cheshire-dnsext-multicastdns] [I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS", Cheshire, S. and M. Krochmal, "Multicast DNS", draft-
draft-cheshire-dnsext-multicastdns-15 (work in progress), cheshire-dnsext-multicastdns-15 (work in progress),
December 2011. December 2011.
[I-D.fleischhauer-ipv4-addr-saving] [I-D.fleischhauer-ipv4-addr-saving]
Fleischhauer, K. and O. Bonness, "On demand IPv4 address Fleischhauer, K. and O. Bonness, "On demand IPv4 address
provisioning in Dual-Stack PPP deployment scenarios", provisioning in Dual-Stack PPP deployment scenarios",
draft-fleischhauer-ipv4-addr-saving-03 (work in progress), draft-fleischhauer-ipv4-addr-saving-03 (work in progress),
August 2012. August 2012.
[RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto-
Configuration in IPv4 Clients", RFC 2563, May 1999. Configuration in IPv4 Clients", RFC 2563, May 1999.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6", RFC
RFC 3493, February 2003. 3493, February 2003.
[RFC3789] Nesser, P. and A. Bergstrom, "Introduction to the Survey [RFC3789] Nesser, P. and A. Bergstrom, "Introduction to the Survey
of IPv4 Addresses in Currently Deployed IETF Standards of IPv4 Addresses in Currently Deployed IETF Standards
Track and Experimental Documents", RFC 3789, June 2004. Track and Experimental Documents", RFC 3789, June 2004.
[RFC3790] Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in [RFC3790] Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in
Currently Deployed IETF Internet Area Standards Track and Currently Deployed IETF Internet Area Standards Track and
Experimental Documents", RFC 3790, June 2004. Experimental Documents", RFC 3790, June 2004.
[RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in [RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in
skipping to change at page 7, line 50 skipping to change at page 7, line 15
[RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in
Currently Deployed IETF Application Area Standards Track Currently Deployed IETF Application Area Standards Track
and Experimental Documents", RFC 3795, June 2004. and Experimental Documents", RFC 3795, June 2004.
[RFC3796] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in [RFC3796] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in
Currently Deployed IETF Operations & Management Area Currently Deployed IETF Operations & Management Area
Standards Track and Experimental Documents", RFC 3796, Standards Track and Experimental Documents", RFC 3796,
June 2004. June 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927, May
May 2005. 2005.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, Multicast Name Resolution (LLMNR)", RFC 4795, January
January 2007. 2007.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[Zeeb] "FreeBSD Snapshots without IPv4 support", [Zeeb] , "FreeBSD Snapshots without IPv4 support", ,
<http://wiki.freebsd.org/IPv6Only>. <http://wiki.freebsd.org/IPv6Only>.
Authors' Addresses Authors' Addresses
Jean-Philippe Dionne Jean-Philippe Dionne
Viagenie Viagenie
246 Aberdeen 246 Aberdeen
Quebec, QC G1R 2E1 Quebec, QC G1R 2E1
Canada Canada
 End of changes. 34 change blocks. 
97 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/