draft-ietf-sunset4-gapanalysis-05.txt   draft-ietf-sunset4-gapanalysis-06.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: July 30, 2015 Huawei Technologies (USA) Expires: September 26, 2015 Huawei Technologies (USA)
C. Zhou C. Zhou
Huawei Technologies Huawei Technologies
P. Fan P. Fan
China Mobile China Mobile
January 26, 2015 March 25, 2015
Gap Analysis for IPv4 Sunset Gap Analysis for IPv4 Sunset
draft-ietf-sunset4-gapanalysis-05 draft-ietf-sunset4-gapanalysis-06
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 July 30, 2015. This Internet-Draft will expire on September 26, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 3 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 4
3.1. Indicating that IPv4 connectivity is unavailable . . . . 3 3.1. Indicating that IPv4 connectivity is unavailable . . . . 4
3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 3 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 4
4. Client Connection Establishment Behavior . . . . . . . . . . 4 4. Client Connection Establishment Behavior . . . . . . . . . . 4
5. Disabling IPv4 in Operating System and Applications . . . . . 4 5. Disabling IPv4 in Operating System and Applications . . . . . 5
6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 4 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 5
7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 5 7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 6
8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 5 8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. Informative References . . . . . . . . . . . . . . . . . . . 6 12. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 8 Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 9
A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 8 A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 9
A.1.1. Indicating that IPv4 connectivity is unavailable . . 8 A.1.1. Indicating that IPv4 connectivity is unavailable . . 9
A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 8 A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 9
A.2. Client Connection Establishment Behavior . . . . . . . . 9 A.2. Client Connection Establishment Behavior . . . . . . . . 10
A.3. Disabling IPv4 in Operating System and Applications . . . 9 A.3. Disabling IPv4 in Operating System and Applications . . . 10
A.4. On-Demand Provisioning of IPv4 Addresses . . . . . . . . 9 A.4. On-Demand Provisioning of IPv4 Addresses . . . . . . . . 10
A.5. Managing Router Identifiers . . . . . . . . . . . . . . . 9 A.5. Managing Router Identifiers . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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
sunsetting easier. This document analyzes the current situation and sunsetting easier. This document analyzes the current situation and
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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
if that decision is made. 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.
Additionally, although reviews in RFCs 3789-3796 ensured that IETF
standards then in use could support IPv6, no IETF-wide effort has
been undertaken to ensure that the issues identified in those drafts
are all addressed, nor to ensure that standards written after RFC3100
(where the previous review efforts stopped) function properly on
IPv6-only networks.
The IETF needs to ensure that existing standards and protocols have
been actively reviewed, and any parity gaps either identified so that
they can be fixed, or documented as unnecessary to address because it
is unused or superseded by other features.
First, the IETF must review RFCs 3789-3796 to ensure that any gaps in
specifications identified in these documents and still in active use
have been updated as necessary to enable operation in IPv6-only
environments (or if no longer in use, are declared historic).
Second, the IETF must review documents written after the existing
review stopped (according to RFC 3790, this review stopped with
approximately RFC 3100) to identify specifications where IPv6-only
operation is not possible, and update them as necessary and
appropriate, or document why an identified gap is not an issue i.e.
not necessary for functional parity with IPv4.
This document does not recommend excluding Informational and BCP RFCs
as the previous effort did, due to changes in the way that these
documents are used and their relative importance in the RFC Series.
Instead, any documents that are still active (i.e. not declared
historic or obsolete) and the product of IETF consensus (i.e. not a
product of the ISE Series) should be included. In addition, the
reviews undertaken by RFCs 3789-3796 were looking for "IPv4
dependency" or "usage of IPv4 addresses in standards". This document
recommends a slightly more specific set of criteria for review:
review should include consideration of whether the specification can
operate in an environment without IPv4. Reviews should include
guidance on the use of 32-bit identifiers that are commonly populated
by IPv4 addresses. Reviews should include consideration of protocols
on which specifications depend or interact, to identify indirect
dependencies on IPv4. Finally, reviews should consider 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
 End of changes. 7 change blocks. 
24 lines changed or deleted 65 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/