draft-ietf-sunset4-gapanalysis-06.txt   draft-ietf-sunset4-gapanalysis-07.txt 
Network Working Group S. Perreault Network Working Group S. Perreault
Internet-Draft Jive Communications Internet-Draft Jive Communications
Intended status: Informational T. Tsou Intended status: Informational T. Tsou
Expires: September 26, 2015 Huawei Technologies (USA) Expires: October 24, 2015 Huawei Technologies (USA)
C. Zhou C. Zhou
Huawei Technologies Huawei Technologies
P. Fan P. Fan
China Mobile China Mobile
March 25, 2015 April 22, 2015
Gap Analysis for IPv4 Sunset Gap Analysis for IPv4 Sunset
draft-ietf-sunset4-gapanalysis-06 draft-ietf-sunset4-gapanalysis-07
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 enumerates difficulties arising when sunsetting IPv6. This memo enumerates difficulties arising when sunsetting
IPv4, and identifies the gaps requiring additional work. IPv4, and identifies the gaps requiring additional work.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 26, 2015. This Internet-Draft will expire on October 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 4 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 4
3.1. Indicating that IPv4 connectivity is unavailable . . . . 4 3.1. Indicating that IPv4 connectivity is unavailable . . . . 4
3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 4 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 4
4. Client Connection Establishment Behavior . . . . . . . . . . 4 4. Client Connection Establishment Behavior . . . . . . . . . . 5
5. Disabling IPv4 in Operating System and Applications . . . . . 5 5. Disabling IPv4 in Operating System and Applications . . . . . 5
6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 5 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 6
7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 6 7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 6
8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 6 8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. Informative References . . . . . . . . . . . . . . . . . . . 7 12. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 9 Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 9
A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 9 A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 9
A.1.1. Indicating that IPv4 connectivity is unavailable . . 9 A.1.1. Indicating that IPv4 connectivity is unavailable . . 9
A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 9 A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 9
A.2. Client Connection Establishment Behavior . . . . . . . . 10 A.2. Client Connection Establishment Behavior . . . . . . . . 10
A.3. Disabling IPv4 in Operating System and Applications . . . 10 A.3. Disabling IPv4 in Operating System and Applications . . . 10
A.4. On-Demand Provisioning of IPv4 Addresses . . . . . . . . 10 A.4. Managing Router Identifiers . . . . . . . . . . . . . . . 10
A.5. Managing Router Identifiers . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 implementation behavior makes 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
skipping to change at page 3, line 43 skipping to change at page 3, line 43
not necessary for functional parity with IPv4. not necessary for functional parity with IPv4.
This document does not recommend excluding Informational and BCP RFCs This document does not recommend excluding Informational and BCP RFCs
as the previous effort did, due to changes in the way that these as the previous effort did, due to changes in the way that these
documents are used and their relative importance in the RFC Series. documents are used and their relative importance in the RFC Series.
Instead, any documents that are still active (i.e. not declared Instead, any documents that are still active (i.e. not declared
historic or obsolete) and the product of IETF consensus (i.e. not a historic or obsolete) and the product of IETF consensus (i.e. not a
product of the ISE Series) should be included. In addition, the product of the ISE Series) should be included. In addition, the
reviews undertaken by RFCs 3789-3796 were looking for "IPv4 reviews undertaken by RFCs 3789-3796 were looking for "IPv4
dependency" or "usage of IPv4 addresses in standards". This document dependency" or "usage of IPv4 addresses in standards". This document
recommends a slightly more specific set of criteria for review: recommends a slightly more specific set of criteria for review.
review should include consideration of whether the specification can Reviews should include:
operate in an environment without IPv4. Reviews should include
guidance on the use of 32-bit identifiers that are commonly populated o Consideration of whether the specification can operate in an
by IPv4 addresses. Reviews should include consideration of protocols environment without IPv4.
on which specifications depend or interact, to identify indirect
dependencies on IPv4. Finally, reviews should consider how to o Guidance on the use of 32-bit identifiers that are commonly
migrate from an IPv4 environment to an IPv6 environment. populated by IPv4 addresses.
o Consideration of protocols on which specifications depend or
interact, to identify indirect dependencies on IPv4.
o Consideration of how to migrate from an IPv4 environment to an
IPv6 environment.
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 response as a failure condition even when it is not. of a 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 the LAN, even in the absence of IPv4 coming from the LAN, even in the absence of IPv4
connectivity on the WAN. connectivity on the WAN.
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 over IPv4 such as mDNS protocols over IPv4 such as mDNS [RFC6762] and LLMNR
[I-D.cheshire-dnsext-multicastdns] and LLMNR [RFC4795]. [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
reasons, since in the absence of IPv4, no monitoring or 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 all cases or may be too complex to deploy. possible in all cases or may be too complex to deploy.
For example, an ISP is often not able to control the L2 For example, an ISP is often not able to control the L2
switching device in the subscriber home network. switching device in the subscriber home network.
PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for
everything", as described in Section 2.6.2 of [RFC3927]. everything", as described in Section 2.6.2 of [RFC3927].
Applications running on such a host connected to an Applications running on such a host connected to an
skipping to change at page 5, line 34 skipping to change at page 5, line 40
5. Disabling IPv4 in Operating System and Applications 5. Disabling IPv4 in Operating System and Applications
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.
PROBLEM 8: Completely disabling IPv4 at runtime often reveals PROBLEM 8: Completely disabling IPv4 at runtime often reveals
implementation bugs. Hard-coded dependencies on IPv4 implementation bugs. Hard-coded dependencies on IPv4
abound, such as on the 127.0.0.1 address assigned to the abound, such as on the 127.0.0.1 address assigned to the
loopback interface. It is therefore often operationally loopback interface, and legacy IPv4-only APIs are widely
used by applications. It is hard for the administrators
and users to know what applications running on the
operating system have implementation problems of IPv4
dependency. It is therefore often operationally
impossible to completely disable IPv4 on individual impossible to completely disable IPv4 on individual
nodes. nodes.
PROBLEM 9: In an IPv6-only world, legacy IPv4 code in operating PROBLEM 9: 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 present security risks. and can present security risks.
6. On-Demand Provisioning of IPv4 Addresses 6. On-Demand Provisioning of IPv4 Addresses
As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers
skipping to change at page 7, line 42 skipping to change at page 8, line 5
12. Informative References 12. 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]
Cheshire, S. and M. Krochmal, "Multicast DNS", draft-
cheshire-dnsext-multicastdns-15 (work in progress),
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-05 (work in progress),
August 2012. September 2013.
[I-D.wing-behave-http-ip-address-literals] [I-D.wing-behave-http-ip-address-literals]
Wing, D., "Coping with IP Address Literals in HTTP URIs Wing, D., "Coping with IP Address Literals in HTTP URIs
with IPv6/IPv4 Translators", draft-wing-behave-http-ip- with IPv6/IPv4 Translators", draft-wing-behave-http-ip-
address-literals-02 (work in progress), March 2010. address-literals-02 (work in progress), March 2010.
[I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp]
Yourtchenko, A. and O. Owen, "Disable "Proxy ARP for Yourtchenko, A. and O. Owen, "Disable "Proxy ARP for
Everything" on IPv4 link-local in the presence of IPv6 Everything" on IPv4 link-local in the presence of IPv6
global address", draft-yourtchenko-ipv6-disable- global address", draft-yourtchenko-ipv6-disable-
skipping to change at page 9, line 21 skipping to change at page 9, line 25
Configuration of IPv4 Link-Local Addresses", RFC 3927, May Configuration of IPv4 Link-Local Addresses", RFC 3927, 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, January Multicast Name Resolution (LLMNR)", RFC 4795, 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.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[Zeeb] "FreeBSD Snapshots without IPv4 support", [Zeeb] "FreeBSD Snapshots without IPv4 support",
<http://wiki.freebsd.org/IPv6Only>. <http://wiki.freebsd.org/IPv6Only>.
Appendix A. Solution Ideas Appendix A. Solution Ideas
A.1. Remotely Disabling IPv4 A.1. Remotely Disabling IPv4
A.1.1. Indicating that IPv4 connectivity is unavailable A.1.1. Indicating that IPv4 connectivity is unavailable
One way to address these issues is to send a signal to a dual-stack One way to address these issues is to send a signal to a dual-stack
skipping to change at page 10, line 14 skipping to change at page 10, line 21
A.2. Client Connection Establishment Behavior A.2. Client Connection Establishment Behavior
Recommendations on client connection establishment behavior that Recommendations on client connection establishment behavior that
would facilitate IPv4 sunsetting would be appropriate. would facilitate IPv4 sunsetting would be appropriate.
A.3. Disabling IPv4 in Operating System and Applications A.3. Disabling IPv4 in Operating System 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. It would be useful
and operating systems that behave well in an IPv6-only environment is if operating systems provide functions for users to see what
a prerequisite for IPv4 sunsetting. applications uses legacy IPv4-only APIs, so they can know it better
whether they can turn off IPv4 completely. Having programs and
A.4. On-Demand Provisioning of IPv4 Addresses operating systems that behave well in an IPv6-only environment is a
prerequisite for IPv4 sunsetting.
No idea.
A.5. Managing Router Identifiers A.4. Managing Router Identifiers
Router IDs can be manually planned, possibly with some hierarchy or Router IDs can be manually planned, possibly with some hierarchy or
design rule, or can be created automatically. A simple way of design rule, or can be created automatically. A simple way of
automatic creation is to generate pseudo-random numbers, and one can automatic creation is to generate pseudo-random numbers, and one can
use another source of data such as the clock time at boot or use another source of data such as the clock time at boot or
configuration time to provide additional entropy during the configuration time to provide additional entropy during the
generation of unique IDs. Another way is to hash an IPv6 address generation of unique IDs. Another way is to hash an IPv6 address
down to a value as ID. The hash algorithm is supposed to be known down to a value as ID. The hash algorithm is supposed to be known
and the same across the domain. Since typically the number of and the same across the domain. Since typically the number of
routers in a domain is far smaller than the value range of IDs, the routers in a domain is far smaller than the value range of IDs, the
 End of changes. 16 change blocks. 
38 lines changed or deleted 43 lines changed or added

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