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.

Table of Contents

• 1. Introduction
• 2. IPv4 GoAway Flag
• 3. End node policy
• 3.1. Mandatory end node rules
• 4. Timeline
• 4.1. Phase 1 - Implementation
• 4.2. Phase 2 - Transition Time
• 4.3. Phase 3 - Deprecated
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Change log [RFC Editor: please remove]
• Author's Address

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.

2. IPv4 GoAway Flag

       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

       4   IPv4 Unavailable Flag

RFC 5175 currently defines the flags in the NDP Router Advertisement message and these flags are registered in the IANA IPv6 ND Router Advertisement Flags Registry. This currently contains the following one-bit flags defined in published RFCs. I-D RA IPv4 Unavailable Flag suggests:

       A   IPv4 GoAway Flag

This document defines bit 7 to be the IPv4 GoAway Flag:

       0   No change to your configuration.
       1   IPv4 must be disabled on this link according to
           the policy specified in this document.

This flag has two values. These are:

RFC 5175 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.

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.

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 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 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.

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.

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. The author would like to thank the authors of that draft for their work.

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Change log [RFC Editor: please remove]

v00 2018-04-01 BZ Initial version

Author's Address