draft-ietf-sunset4-gapanalysis-00.txt   draft-ietf-sunset4-gapanalysis-01.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: February 7, 2013 T. Tsou Expires: April 25, 2013 T. Tsou
Huawei Technologies (USA) Huawei Technologies (USA)
August 6, 2012 C. Zhou
Huawei Technologies
October 22, 2012
Gap Analysis for IPv4 Sunset Gap Analysis for IPv4 Sunset
draft-ietf-sunset4-gapanalysis-00 draft-ietf-sunset4-gapanalysis-01
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 analyses difficulties arising when sunsetting IPv4,
and identifies the gaps resulting in additional work. and identifies the gaps resulting in additional work.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 37
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 February 7, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 15 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . . 3 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Informative References . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
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 implementations behavior make 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
skipping to change at page 5, line 32 skipping to change at page 5, line 32
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
a prerequisite for IPv4 sunsetting. a prerequisite for IPv4 sunsetting.
6. IANA Considerations 6. On-Demand Provisioning of IPv4 Addresses
As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers
will become smaller. This could be exploited by an ISP to save IPv4
addresses by provisioning them on-demand to subscribers and
reclaiming them when they are no longer used. This idea is described
in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the
context of PPP sessions. In these scenarios, the home router is
responsible for requesting and releasing IPv4 addresses, based on
snooping the traffic generated by the hosts in the LAN, which are
still dual-stack and unaware that their traffic is being snooped.
PROBLEM 9: Dual-stack hosts that implement Happy-Eyeballs [RFC6555]
will generate both IPv4 and IPv6 traffic even if the
algorithm end up chooosing IPv6. This means that an
IPv4 address will always be requested by the home
router, which defeats the purpose of on-demand
provisioning.
PROBLEM 10: Many operating systems periodically perform some kind of
network connectivity check as long as an interface is
up. Similarly, applications often send keep-alive
traffic continuously. This permanent "background noise"
will prevent an IPv4 address from being released by the
home router.
PROBLEM 11: Hosts in the LAN have no knowledge that IPv4 is
available to them on-demand only. If they had explicit
knowledge of this fact, they could tune their behaviour
so as to be more conservative in their use of IPv4.
PROBLEM 12: This mechanism is only being proposed for PPP even
though it could apply to other provisioning protocols
(e.g., DHCP).
7. IANA Considerations
None. None.
7. Security Considerations 8. Security Considerations
TODO TODO
8. Acknowledgements 9. Acknowledgements
TODO TODO
9. Informative References 10. Informative References
[BBF.TR242]
Broadband Forum, "TR-242: IPv6 Transition Mechanisms for
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-cheshire-dnsext-multicastdns-15 (work in progress), draft-cheshire-dnsext-multicastdns-15 (work in progress),
December 2011. December 2011.
[I-D.fleischhauer-ipv4-addr-saving]
Fleischhauer, K. and O. Bonness, "On demand IPv4 address
provisioning in Dual-Stack PPP deployment scenarios",
draft-fleischhauer-ipv4-addr-saving-03 (work in progress),
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 3493, February 2003. RFC 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.
skipping to change at line 291 skipping to change at page 9, line 4
URI: http://viagenie.ca URI: http://viagenie.ca
Tina Tsou Tina Tsou
Huawei Technologies (USA) Huawei Technologies (USA)
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Phone: +1 408 330 4424 Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com Email: tina.tsou.zouting@huawei.com
Cathy Zhou
Huawei Technologies
Huawei Industrial Base
Bantian, Shenzhen
China
Email: cathy.zhou@huawei.com
 End of changes. 11 change blocks. 
13 lines changed or deleted 61 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/