draft-ietf-sunset4-gapanalysis-08.txt   draft-ietf-sunset4-gapanalysis-09.txt 
Network Working Group W. Liu Network Working Group W. Liu
Internet-Draft W. Xu Internet-Draft W. Xu
Intended status: Informational C. Zhou Intended status: Informational C. Zhou
Expires: December 25, 2017 Huawei Technologies Expires: January 28, 2018 Huawei Technologies
T. Tsou T. Tsou
Philips Lighting Philips Lighting
S. Perreault S. Perreault
Jive Communications Jive Communications
P. Fan P. Fan
R. Gu
China Mobile China Mobile
June 26, 2017 C. Xie
China Telecom
Y. Cheng
China Unicom
July 29, 2017
Gap Analysis for IPv4 Sunset Gap Analysis for IPv4 Sunset
draft-ietf-sunset4-gapanalysis-08 draft-ietf-sunset4-gapanalysis-09
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 transition 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
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 December 25, 2017. This Internet-Draft will expire on January 28, 2018.
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 25 skipping to change at page 2, line 25
3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 4 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 4
4. Client Connection Establishment Behavior . . . . . . . . . . 5 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 . . . . . . . . . . 6 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 6
7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 6 7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 6
8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 7 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 Annex 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. Managing Router Identifiers . . . . . . . . . . . . . . . 10 A.4. On-Demand Provisioning of IPv4 Address. . . . . . . . . . 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 transition 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
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 The decision about when to turn off IPv4 is out of scope. This
document merely attempts to enumerate the issues one might encounter document merely attempts to enumerate the issues one might encounter
skipping to change at page 4, line 8 skipping to change at page 4, line 8
o Consideration of whether the specification can operate in an o Consideration of whether the specification can operate in an
environment without IPv4. environment without IPv4.
o Guidance on the use of 32-bit identifiers that are commonly o Guidance on the use of 32-bit identifiers that are commonly
populated by IPv4 addresses. populated by IPv4 addresses.
o Consideration of protocols on which specifications depend or o Consideration of protocols on which specifications depend or
interact, to identify indirect dependencies on IPv4. interact, to identify indirect dependencies on IPv4.
o Consideration of how to migrate from an IPv4 environment to an o Consideration of how to transit from an IPv4 environment to an
IPv6 environment. 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.
skipping to change at page 6, line 17 skipping to change at page 6, 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.
As described in TR-092 and TR-187, NAS(e.g., BRAS, BNG) stores pools of
IPv4 and IPv6 addresses, which are used for DHCP distribution to the
hosts in home network. IPv4 and IPv6 addresses of hosts can be dynamic
assignment from a pool of IPv4 and IPv6 prefixes in NAS.
As the IPv4 sunsets, the number of IPv4 hosts is reduced, therefore the
IPv4 address resource in NAS needs to be reduced too. These reduced
IPv4 addresses will be reclaimed by the address management system
(NMS, controller, IPAM, etc.). At the same time, as the number of IPv6
hosts increases, NAS need incrementally increase the number of IPv6
address resource. The increased IPv6 address resource can be assigned
by the address management system, which makes the transition more
smoothly by dynamically adding / releasing IP address resources in NAS.
In modern network systems, protocols such as NETCONF / RESTCONF / RADIUS
can be used for this process. With NETCONF, NAS acts as NETCONF server
with the opening port to listen for the client connection, while the
address management system as a netconf client that connects and
processes IP address request from NAS.
PROBLEM 10: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] PROBLEM 10: 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 up chooosing IPv6. This means that an IPv4 algorithm end up chooosing IPv6. This means that an IPv4
address will always be requested by the home router, address will always be requested by the home router,
which defeats the purpose of on-demand provisioning. which defeats the purpose of on-demand provisioning.
PROBLEM 11: Many operating systems periodically perform some kind of PROBLEM 11: Many operating systems periodically perform some kind of
network connectivity check as long as an interface is up. network connectivity check as long as an interface is up.
Similarly, applications often send keep-alive traffic Similarly, applications often send keep-alive traffic
continuously. This permanent "background noise" will continuously. This permanent "background noise" will
skipping to change at page 6, line 39 skipping to change at page 6, line 58
PROBLEM 12: Hosts in the LAN have no knowledge that IPv4 is available PROBLEM 12: Hosts in the LAN have no knowledge that IPv4 is available
to them on-demand only. If they had explicit knowledge to them on-demand only. If they had explicit knowledge
of this fact, they could tune their behaviour so as to be of this fact, they could tune their behaviour so as to be
more conservative in their use of IPv4. more conservative in their use of IPv4.
PROBLEM 13: This mechanism is only being proposed for PPP even though PROBLEM 13: This mechanism is only being proposed for PPP even though
it could apply to other provisioning protocols (e.g., it could apply to other provisioning protocols (e.g.,
DHCP). DHCP).
PROBLEM 14: When the number of IPv4 hosts connected to NAS is reduced,
the NAS releases the IPv4 address resource and the NAS
requests more IPv6 address resource for it to serve hosts
transitting from IPv4 to IPv6.
7. IPv4 Address Literals 7. IPv4 Address Literals
IPv4 addresses are often used as resource locators. For example, it IPv4 addresses are often used as resource locators. For example, it
is common to encounter URLs containing IPv4 address literals on web is common to encounter URLs containing IPv4 address literals on web
sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address
literals may be published on media other than web sites, and may literals may be published on media other than web sites, and may
appear in various forms other than URLs. For the operating systems appear in various forms other than URLs. For the operating systems
which exhibit the behavior described in which exhibit the behavior described in
[I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an
increase in the broadcast ARP traffic, which may be undesirable. increase in the broadcast ARP traffic, which may be undesirable.
PROBLEM 14: IPv6-only hosts are unable to access resources identified PROBLEM 15: IPv6-only hosts are unable to access resources identified
by IPv4 address literals. by IPv4 address literals.
8. Managing Router Identifiers 8. Managing Router Identifiers
IPv4 addresses are often conventionally chosen to number a router ID, IPv4 addresses are often conventionally chosen to number a router ID,
which is used to identify a system running a specific protocol. The which is used to identify a system running a specific protocol. The
common practice of tying an ID to an IPv4 address gives much common practice of tying an ID to an IPv4 address gives much
operational convenience. A human-readable ID is easy for network operational convenience. A human-readable ID is easy for network
operators to deal with, and it can be auto-configured, saving the operators to deal with, and it can be auto-configured, saving the
work of planning and assignment. It is also helpful to quickly work of planning and assignment. It is also helpful to quickly
perform diagnosis and troubleshooting, and easy to identify the perform diagnosis and troubleshooting, and easy to identify the
availability and location of the identified router. availability and location of the identified router.
PROBLEM 15: In an IPv6 only network, there is no IP address that can PROBLEM 16: In an IPv6 only network, there is no IP address that can
be directly used to number a router ID. IDs have to be be directly used to number a router ID. IDs have to be
planned individually to meet the uniqueness requirement. planned individually to meet the uniqueness requirement.
Tying the ID directly to an IP address which yields Tying the ID directly to an IP address which yields
human-friendly, auto-configured ID that helps with human-friendly, auto-configured ID that helps with
troubleshooting is not possible. troubleshooting is not possible.
9. IANA Considerations 9. IANA Considerations
None. None.
10. Security Considerations 10. Security Considerations
It is believed that none of the problems identified in this draft are It is believed that none of the problems identified in this draft are
security issues. security issues.
11. Acknowledgements 11. Acknowledgements
Thanks in particular to Andrew Yourtchenko, Lee Howard, Nejc Thanks in particular to Andrew Yourtchenko, Jordi Palet Martinez,
Skoberne, and Wes George for their thorough reviews and comments. Lee Howard, Nejc Skoberne, and Wes George for their thorough reviews
and comments.
Special thanks to Marc Blanchet who was the driving force behind this Special thanks to Marc Blanchet who was the driving force behind this
work and to Jean-Philippe Dionne who helped with the initial version work and to Jean-Philippe Dionne who helped with the initial version
of this document. of this document.
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.
skipping to change at page 9, line 31 skipping to change at page 9, line 31
[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, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. 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 Annex 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
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.
A.1.2. Disabling IPv4 in the LAN A.1.2. Disabling IPv4 in the LAN
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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.
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.
Happy Eyeballs timers and related parameters should get gradually
increased, so even if IPv6 is "slower" than IPv4, IPv6 gains
preference anyway.
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. It would be useful existing dependencies, and how to eliminate them. It would be useful
if operating systems provide functions for users to see what if operating systems provide functions for users to see what
applications uses legacy IPv4-only APIs, so they can know it better applications uses legacy IPv4-only APIs, so they can know it better
whether they can turn off IPv4 completely. Having programs and whether they can turn off IPv4 completely. Having programs and
operating systems that behave well in an IPv6-only environment is a operating systems that behave well in an IPv6-only environment is a
prerequisite for IPv4 sunsetting. prerequisite for IPv4 sunsetting.
A.4. Managing Router Identifiers A.4. On-Demand Provisioning of IPv4 Address
As the sunset of IPv4 in NAS, parts of hosts no longer need IPv4
address. IPv4 address resources in NAS appears surplus, NAS should
obtain the unoccupied IPv4 address, generate a request and send it
to the address management system to release those IPv4 address
resource. Meanwhile, NAS needs more IPv6 address resources for the
host transiting from IPv4 to IPv6. NAS judges whether the usage
status of the IPv6 address resource satisfies certain condition,
and the condition can be IPv6 address utilization ritio. If the
IPv6 address utilization ratio is too high, the NAS generates a
resource request containing IPv6 addresses information that needs
to be applied and sends it to the address management system. When
the address management system receives the IPv6 address resource
request, it allocates IPv6 address pool from its assignable IPv6
address resource according to the information of the resource
request, then it sends a response message with the information of
allocated IPv6 address pool for this NAS to the NAS. Then the NAS
receives the response and gets the information of allocated IPv6
address pool.
A.5. 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
skipping to change at page 11, line 4 skipping to change at page 11, line 13
the mechanism is provided by the system implementation. the mechanism is provided by the system implementation.
If the ID is created from IPv6 address, e.g. by hashing from an IPv6 If the ID is created from IPv6 address, e.g. by hashing from an IPv6
address, then naturally it has relationship with the address. If the address, then naturally it has relationship with the address. If the
ID is created regardless of IP address, one way to build association ID is created regardless of IP address, one way to build association
with IPv6 address is to embed the ID into an IPv6 address that is to with IPv6 address is to embed the ID into an IPv6 address that is to
be configured on the router, e.g. use a /96 IPv6 prefix and append it be configured on the router, e.g. use a /96 IPv6 prefix and append it
with a 32-bit long ID. One can also use some record keeping with a 32-bit long ID. One can also use some record keeping
mechanisms, e.g. text file, DNS or other provisioning system like mechanisms, e.g. text file, DNS or other provisioning system like
network management system to manage the IDs and mapping relations network management system to manage the IDs and mapping relations
with IPv6 addresses, though extra record keeping does introduce with IPv6 addresses, though extra record keeping does introduce
additional work. additional work.
Authors' Addresses Authors' Addresses
Will(Shucheng) Liu Will(Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
Weiping Xu Weiping Xu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China China
Email: xuweiping@huawei.com Email: xuweiping@huawei.com
Cathy Zhou Cathy Zhou
Huawei Technologies Huawei Technologies
Huawei Industrial Base Bantian, Longgang District
Bantian, Shenzhen Shenzhen 518129
China China
Email: cathy.zhou@huawei.com Email: cathy.zhou@huawei.com
Tina Tsou Tina Tsou
Philips Lighting Philips Lighting
United States of America United States of America
Email: tina.tsou@philips.com Email: tina.tsou@philips.com
Simon Perreault Simon Perreault
Jive Communications Jive Communications
Quebec, QC Quebec, QC
Canada Canada
Email: sperreault@jive.com Email: sperreault@jive.com
Peng Fan Peng Fan
China Mobile Beijing
32 Xuanwumen West Street
Beijing, Beijing
China China
Email: fanp08@gmail.com Email: fanp08@gmail.com
Rong Gu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing 100053
China
Email: gurong_cmcc@outlook.com
Chongfeng Xie
China Telecom
China Telecom Beijing Information Science&Technology Innovation Park
Beiqijia Town Changping District, Beijing 102209,
China
Email: xiechf.bri@chinatelecom.cn
Ying Cheng
China Unicom
No.21 Financial Street, XiCheng District
Beijing 100033
China
Email: chengying10@chinaunicom.cn
 End of changes. 24 change blocks. 
23 lines changed or deleted 79 lines changed or added

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