Network Working Group B. Zeeb
Internet-Draft April 01, 2018
Intended status: Informational
Expires: October 3, 2018
IPv6 Router Advertisement IPv4 GoAway Flag
draft-bz-v4goawayflag-00
Abstract
This document specifies a Router Advertisement Flag to indicate to
end nodes that IPv4 support must be disabled on this link. In
addition this document presents a policy and a timeline on how to
deal with this flag and the going-away of IPv4. This document
updates RFC5175.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 3, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zeeb Expires October 3, 2018 [Page 1]
Internet-Draft RA IPv4 GoAway Flag April 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IPv4 GoAway Flag . . . . . . . . . . . . . . . . . . . . . . 3
3. End node policy . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Mandatory end node rules . . . . . . . . . . . . . . . . 4
4. Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Phase 1 - Implementation . . . . . . . . . . . . . . . . 4
4.2. Phase 2 - Transition Time . . . . . . . . . . . . . . . . 5
4.3. Phase 3 - Deprecated . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Change log [RFC Editor: please remove] . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document specifies a Router Advertisement Flag to indicate to
end nodes that IPv4 support must be disabled on this link.
In addition this document presents a policy and a timeline on how to
deal with this flag and the going-away of IPv4.
Over the last years various parties have tried to come up with a plan
on how to deal with the "sunset" of IPv4. As IPv6 deployment is
progressing there is a need to allow people to get legacy IP (IPv4)
off their networks. While few people can envision such a world yet,
some have been living it for years.
Most concern seems to be related to either (i) legacy deployments out
of control of the operators, e.g., CPE equipment or end nodes with
questionable or nonexistent support for IPv6 and not breaking these,
or (ii) the design of new networks and products not fully envisioning
the future world falling back to years of comfort of dealing with
things the IPv4 way.
In order to open eyes and make people move forward it is time to
specify a flag day, a concept that a lot of people have wondered if
it should have been used one to two decades ago. As it currently
stands an immediate IPv4 switch-off day does not seem possible, hence
this document aims for a staged transition towards deprecating IPv4.
Zeeb Expires October 3, 2018 [Page 2]
Internet-Draft RA IPv4 GoAway Flag April 2018
2. IPv4 GoAway Flag
RFC 5175 [RFC5175] currently defines the flags in the NDP Router
Advertisement message and these flags are registered in the IANA IPv6
ND Router Advertisement Flags Registry [IANA-RF]. This currently
contains the following one-bit flags defined in published RFCs.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|R|R|
+-+-+-+-+-+-+-+-+
M Managed Address Configuration Flag [RFC4861]
O Other Configuration Flag [RFC4861]
H Mobile IPv6 Home Agent Flag [RFC3775]
Prf Router Selection Preferences [RFC4191]
P Neighbor Discovery Proxy Flag [RFC4389]
R Reserved
In addition I-D RA IPv4 Unavailable Flag [draft-hinden-ipv4flag]
suggests:
4 IPv4 Unavailable Flag
for bit 6.
This document defines bit 7 to be the IPv4 GoAway Flag:
A IPv4 GoAway Flag
This flag has two values. These are:
0 No change to your configuration.
1 IPv4 must be disabled on this link according to
the policy specified in this document.
RFC 5175 [RFC5175] requires that unused flag bits be set to zero.
Therefore, an advertising host which does not support the new flag
will not appear to assert that IPv4 must be disabled and will stay
RFC compliant.
Zeeb Expires October 3, 2018 [Page 3]
Internet-Draft RA IPv4 GoAway Flag April 2018
According to the policy and timeline specified in this document, on
an end node, any single Router Advertisement (RA) seen with this flag
set, may trigger the disabling of IPv4 on that link. This will be
independent of it being a rogue RA or not.
3. End node policy
In order to facilitate a grace period this document defines a minimal
set of rules an end node must implement. If desired an end node may
implement further rules to have more fine grained control over the
behaviour when the IPv4 GoAway Flag is set.
3.1. Mandatory end node rules
The rules an end node must implement are simple:
R1 A node global policy option to control whether or not to observe
the IPv4 GoAway Flag. It is understood that there will always be
exceptions to the rules and only time can possibly fix these.
Hence this rule allows an end-user, administrator, or operator in
control of the end node configuration to knowingly alter the
intention of this document and overrule the IPv4 GoAway Flag
locally. This policy option should only be altered during Phase
1 of the timetable specified in this document. Any change from
the suggested defaults may cause interoperability problems and
undefined behaviour on the end node.
R2 And end node that supports the IPv4 GoAway Flag must also
implement the above policy for as long as it supports IPv4. An
end node no longer supporting IPv4 in any way may chose not to
implement the policy. Developers and vendors are advised that
user space translators from IPv4 may exist and might want to
query the policy despite the operating system no longer
supporting IPv4.
R3 If implemented and enabled the IPv4 GoAway Flag takes precedence
over the IPv4 Unavailable Flag.
4. Timeline
The timeline to deploy and use the IPv4 GoAway Flag is split into 3
phases.
4.1. Phase 1 - Implementation
This phase will commence immediately and will be in effect until the
beginning of phase 2.
Zeeb Expires October 3, 2018 [Page 4]
Internet-Draft RA IPv4 GoAway Flag April 2018
During this phase developers and vendors will implement support for
both the IPv4 GoAway Flag as well as the end node policies described
above.
The default for the IPv4 GoAway Flag shall be 0 but may be changed at
an administrator's or operator's choice.
The default policy on end nodes shall be to ignore the flag but may
be changed by an end-user, administrator, or operator should they no
longer desire to need IPv4. An application trying to query the flag
but not finding it may assume that IPv4 still is supported and adhere
to other policies from outside this document.
Any application or operating system may disable IPv4 support at any
time despite the IPv4 GoAway Flag being 0.
4.2. Phase 2 - Transition Time
This phase will commence on June 6, 2022, about 5 years after RFC
8200 [RFC8200] was published and on the well established day formerly
used for various IPv6 advocacy events. This phase will be in effect
until the beginning of phase 3.
The default of the IPv4 GoAway Flag shall be 1 but may be changed at
an administrator's or operator's choice.
The default policy on end nodes shall be to observe the IPv4 GoAway
Flag if set. An application not finding the local policy anymore
must assume that IPv4 support on the node is gone.
From the beginning of this phase an end node should assume that IPv4
operations on any link can stop working or be no longer possible at
any time.
4.3. Phase 3 - Deprecated
This phase will commence on January 3, 2029, about 30 years after RFC
2460 [RFC2460] was published. This phase will then be in effect
until further notice.
IPv4 is no longer expected to be supported on any kind of node or
link. The IPv4 GoAway Flag bit may be reclaimed.
Any individual networks still running IPv4 are allowed to do so at
their own discretion but must not interface or interfere with any
equipment and networks outside their own control.
Zeeb Expires October 3, 2018 [Page 5]
Internet-Draft RA IPv4 GoAway Flag April 2018
5. IANA Considerations
IANA is requested to assign the new Router Advertisement flag defined
in Section 2 of this document. Bit 7 is a free available bit in this
registry, IANA is requested to use this bit unless there is a reason
to use another bit in this registry. IANA should also register this
new flag bit in the IANA IPv6 ND Router Advertisement flags Registry
[IANA-RF].
6. Security Considerations
This document shares all the security issues with other parts of IPv6
Neighbour Discovery. Do your homework.
In addition this document accepts that from phase 2 and onward a
rogue RA will be able to turn IPv4 off on end nodes even if not
desired by the administrator or operator. This is considered a
feature and not a security problem.
7. Acknowledgements
The author would like to thank everyone not able to turn the internet
off for their inspiration, the sunset4, 6MAN, and v6ops, and all
other working groups which could not previously come to a consensus
on this matter.
This document was heavily inspired by I-D RA IPv4 Unavailable Flag
[draft-hinden-ipv4flag]. The author would like to thank the authors
of that draft for their work.
8. References
8.1. Normative References
[IANA-RF] IANA, "IPv6 ND Router Advertisement flags", 2018,
<https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-11>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router
Advertisement Flags Option", RFC 5175,
DOI 10.17487/RFC5175, March 2008,
<https://www.rfc-editor.org/info/rfc5175>.
Zeeb Expires October 3, 2018 [Page 6]
Internet-Draft RA IPv4 GoAway Flag April 2018
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References
[draft-hinden-ipv4flag]
Hinden, R. and B. Carpenter, "IPv6 Router Advertisement
IPv4 Unavailable Flag", 2018.
Appendix A. Change log [RFC Editor: please remove]
v00 2018-04-01 BZ Initial version
Author's Address
Bjoern A. Zeeb
Email: bzeeb+ietf@zabbadoz.net
Zeeb Expires October 3, 2018 [Page 7]