IPv6 Router Advertisement IPv6-Only Flag
draft-ietf-6man-ipv6only-flag-04

Network Working Group                                          R. Hinden
Internet-Draft                                      Check Point Software
Updates: 4861, 5175 (if approved)                           B. Carpenter
Intended status: Standards Track                       Univ. of Auckland
Expires: May 9, 2019                                    November 5, 2018

                IPv6 Router Advertisement IPv6-Only Flag
                    draft-ietf-6man-ipv6only-flag-04

Abstract

   This document specifies a Router Advertisement Flag to indicate to
   hosts that the administrator has configured the router to advertise
   that the link is IPv6-Only.  This document updates RFC4861 and
   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 http://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 May 9, 2019.

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
   (http://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.

Hinden & Carpenter         Expires May 9, 2019                  [Page 1]
Internet-Draft               IPv6-Only Flag                November 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Applicability Statements  . . . . . . . . . . . . . . . . . .   4
   4.  IPv6-Only Definition  . . . . . . . . . . . . . . . . . . . .   5
   5.  IPv6-Only Flag  . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Router and Operational Considerations . . . . . . . . . . . .   6
   7.  Host Behavior Considerations  . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   11. Change log [RFC Editor: Please remove]  . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  Implementaton Status . . . . . . . . . . . . . . . .  13
     A.1.  FreeBSD Implementation  . . . . . . . . . . . . . . . . .  13
     A.2.  Test using Scapy  . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document specifies a Router Advertisement Flag to indicate to
   hosts that the administrator has configured the router to advertise
   that the link is IPv6-Only.  The flag only applies to IPv6 default
   routers.

   Hosts that support IPv4 and IPv6, usually called dual stack hosts,
   need to also work efficiently on IPv6-Only links, i.e, links where
   there are no IPv4 routers and/or IPv4 services.  Dual stack is the
   default configuration for most current host operating systems such as
   Windows 10, iOS, Android, Linux, and BSD, as well as devices such as
   some printers.  Monitoring of an IPv6-Only link, for example at the
   IETF 100 meeting in Singapore, shows that current dual stack hosts
   will create local auto-configured IPv4 addresses and attempt to reach
   IPv4 services, even though they cannot configure a normal address
   using DHCP.  This may be a problem for several reasons, depending on
   the equipment in use and its configuration, especially on large
   wireless networks:

   o  It may result in an undesirable level of wasted Layer 2 broadcast
      traffic.

   o  Switches in multi-segment wireless networks may create IPv4 state
      for dual stack hosts (in particular, ARP cache entries to support
      ARP proxying).

Hinden & Carpenter         Expires May 9, 2019                  [Page 2]
Internet-Draft               IPv6-Only Flag                November 2018

   o  Such traffic may drain battery power on wireless hosts that have
      no interest in link-local IPv4, ARP, and DHCPv4 relay traffic, but
      receive unwanted IPv4 packets.  [RFC7772] indicates how this risk
      might be quantified.

   o  Similarly, hosts may waste battery power on futile attempts to
      access services by sending IPv4 packets.

   o  On an IPv6-Only link, IPv4 might be used for malicious purposes
      and pass unnoticed by IPv6-Only monitoring mechanisms.

   In networks with managed infrastructure whose equipment allows it,
   these problems could be mitigated by configuring the Layer 2
   infrastructure to drop IPv4 and ARP traffic by filtering Ethertypes
   0x0800 and 0x0806 [IANA-Ethertype].  IPv6 uses a different Ethertype,
   0x86DD, so this filtering will not interfere with IPv6 traffic.
   Depending on the equipment details, this would limit the traffic to
   the link from an IPv4 sender to the switch, and would drop all IPv4
   and ARP broadcast packets at the switch.  This document recommends
   using such mechanisms when available.

   However, hosts transmitting IPv4 packets would still do so, consuming
   their own battery power and some radio bandwidth.  The intent of this
   specification is to provide a mechanism that prevents such traffic,
   and also works on networks without the ability to filter L2 traffic,
   or where there are portions of a network without the ability to
   filter L2 traffic.  It may also be valuable on unmanaged networks
   using routers pre-configured for IPv6-Only operations and where Layer
   2 filtering is unavailable.

   An assumption of this document is that because it is an IPv6-Only
   link there is no IPv4 DHCP server or relay active on the link.  This
   further means that the DHCP option to disable IPv4 stateless auto-
   configuration [RFC2563] can not be used.

   The remainder of this document therefore assumes that neither
   effective Layer 2 filtering nor the RFC 2563 DHCP option is
   applicable to the link concerned.

   Because there is no IPv4 support on an IPv6-Only link, the only way
   to notify the dual stack hosts that this link is IPv6-Only is to use
   an IPv6 mechanism.  An active notification will be much more precise
   than attempting to deduce this fact by the lack of IPv4 responses or
   traffic.

   This document therefore defines a mechanism that a router
   administrator can use to inform hosts that this is an IPv6-Only link
   on their default routers such that they can disable IPv4 on this

Hinden & Carpenter         Expires May 9, 2019                  [Page 3]
Internet-Draft               IPv6-Only Flag                November 2018

   link, mitigating all of the above problems.  The mechanism is based
   on the IPv6 Router Advertisement message because this is a type of
   message that is certain to be received by every dual stack host,
   regardless of what network management protocols may or may not be in
   use.

   IPv4-only hosts, and dual-stack hosts that do not recognize the new
   flag, may continue to attempt IPv4 operations, in particular IPv4
   discovery protocols typically sent as link-layer broadcasts.  This
   legacy traffic cannot be prevented by any IPv6 mechanism.  The value
   of the new flag is limited to hosts that recognize it.

   A possible subsidiary use of the IPv6-Only flag is using it to
   trigger IPv6-Only testing and validation on a link.

   This document specifies a new flag for Router Advertisement Flag
   [RFC5175].  It updates [RFC5175] to add this flag.  It also updates
   [RFC4861] to add an additional item to check and report.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Applicability Statements

   This OPTIONAL mechanism is designed to allow administrators to notify
   hosts that the link is IPv6-Only.  It SHOULD be only used in
   IPv6-Only links (see below for definition).  For a VLAN, the
   IPv6-Only flag only applies to the specific VLAN on which it was
   received.

   Dual stack hosts that have a good reason to use IPv4, for example for
   a specific IPv4 link-local service, can attempt to do so.  Therefore
   respect of the IPv6-Only flag is recommended, not mandatory, for
   hosts.

   Administrators MUST only use this mechanism if they are certain that
   the link is IPv6-Only.  For example, in cases where there is a need
   to continue to use IPv4, when there are intended to be IPv4-only
   hosts or IPv4 routers on the link, setting this flag to 1 is a
   configuration error.

   This mechanism is intended to be compatible with link-layer solutions
   that filter out IPv4 traffic.

Hinden & Carpenter         Expires May 9, 2019                  [Page 4]
Internet-Draft               IPv6-Only Flag                November 2018

4.  IPv6-Only Definition

   IPv6-Only is defined to mean that no other versions of Internet
   Protocol than IPv6 are intentionally in use directly on the link.
   Today this effectively simply means that IPv4 is not intentionally in
   use on the link, and it includes:

      *  No IPv4 traffic on the link.
      *  No IPv4 routers on the link.
      *  No DHCPv4 servers on the link.
      *  No IPv4 accessible services on the link.
      *  All IPv4 and ARP traffic may be blocked at Layer 2 by the
         administrator.

   It is expected that on IPv6-Only networks it will be common to access
   to IPv4 external services by techniques such as NAT64 [RFC6146] and
   DNS64 [RFC6147]  at the edge of the network.  This is beyond the
   scope of this document.

   Note that IPv6-Only provides no information about other network
   protocols than IP (and ARP) in use directly over the link layer.  It
   is out of scope of this specification whether any such protocol is in
   use on the link or whether any protocol is tunneled over IPv6.

5.  IPv6-Only Flag

   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

   This document defines bit 6 to be the IPv6-Only Flag:

Hinden & Carpenter         Expires May 9, 2019                  [Page 5]
Internet-Draft               IPv6-Only Flag                November 2018

      S    IPv6-Only Flag

   This flag has two values.  These are:

      0    This is not an IPv6-Only link
      1    This is an IPv6-Only link

   RFC 5175 requires that unused flag bits be set to zero.  Therefore, a
   router that does not support the new flag will not appear to assert
   that this is an IPv6-Only link.

   Hosts receiving the Router Advertisement SHOULD only process this
   flag if the advertising router is a Default Router.  Specifically, if
   the Lifetime field in the Router Advertisement is not zero, otherwise
   it SHOULD be ignored.  This is done to allow some IPv6 routers to
   advertise information without being a Default Router and providing
   IPv6 connectivity.

   Note that although this mechanism uses one of only two reserved flag
   bits in the RA, an extension mechanism is defined in Section 4 of
   [RFC5175] in case additional flags are ever required for future
   extensions.  It should be noted that since RFC5175 was published in
   2008, no new RA flags have been assigned in the IANA registry.

6.  Router and Operational Considerations

   Default IPv6 routers that are on an IPv6-Only link SHOULD be
   configured by the administrator to set the IPv6-Only flag to 1 on
   interfaces on this link.  In all other cases the flag SHOULD NOT be
   set to 1.

   The intent is that the administrator of the router configures the
   router to set the IPv6-Only flag if she/he wants to tell the hosts on
   the link that the link is IPv6-Only.  This is a configuration flag,
   it is not something that the router decides on its own.  Routers MAY
   log a configuration error if the flag is set and IPv4 is still active
   on the router's interface to the link.

   Routers implementing this document SHOULD log to system or network
   management inconsistent setting of the IPv6-Only flag.  This extends
   the behaviour specified in Section 6.2.7 of [RFC4861].

   Operators of large IPv6-Only wireless links are advised to also use
   Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800
   and 0x0806) at all switches, and to ensure that IPv4 and ARP features
   are disabled in all switches.

Hinden & Carpenter         Expires May 9, 2019                  [Page 6]
Internet-Draft               IPv6-Only Flag                November 2018

7.  Host Behavior Considerations

   If there are multiple IPv6 default routers on a link, they might send
   different values of the flag.  If at least one IPv6 default router
   sends the flag with value 0, a dual stack host MUST NOT assume that
   the link is IPv6-Only.  If all IPv6 default routers send the flag
   with value 1, a dual stack host SHOULD assume that this is an
   IPv6-Only link.

   A host that receives only RAs with the flag set to 1 SHOULD NOT
   attempt any IPv4 operations, unless it subsequently receives at least
   one RA with the flag set to zero.  As soon as such an RA is received,
   IPv4 operations MAY be started.

   A host MAY delay all IPv4 operations at start-up or reconnection
   until a reasonable time has elapsed for RA messages to arrive.  If
   all RAs received have the flag set to 1, a host SHOULD NOT attempt
   IPv4 operations.

   In all of the above, the flag's value is considered valid for the
   lifetime of the default router concerned, unless a subsequent RA
   delivers a different flag value.  If a default router expires (i.e.,
   no RA is received that refreshes its lifetime), the host must remove
   this router's flag value from consideration.  If the result is that
   all surviving default routers have the flag set to 1, the host SHOULD
   assume that the link is IPv6-Only.  In other words, at any given
   time, the state of the flag as seen by the host is the logical AND of
   the flags sent by all unexpired default IPv6 routers on the link.

   This also means that if all default routers on the link have set the
   flag, the resulting host state for the link is IPv6-Only.  If the
   lifetimes of all the routers on the link subsequently expire, then
   the host state for the link is not IPv6-Only.

8.  IANA Considerations

   IANA is requested to assign the new Router Advertisement flag defined
   in Section 5 of this document.  Bit 6 is the next 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 is also requested to register this new flag bit in the IANA IPv6
   ND Router Advertisement flags Registry [IANA-RF].

Hinden & Carpenter         Expires May 9, 2019                  [Page 7]
Internet-Draft               IPv6-Only Flag                November 2018

9.  Security Considerations

   This document shares the security issues with other parts of IPv6
   Neighbor Discovery.  [RFC6104] discusses certain attacks and
   mitigations.  General techniques to protect Router Advertisement
   traffic such as Router Guard [RFC6105] are useful in protecting
   against these vulnerabilities.

   A bad actor could use this mechanism to attempt turn off IPv4 service
   on a link that is intentionally using IPv4, by sending Router
   Advertisements with the IPv6-Only flag set to 1.  In that case, as
   long as there are one or more routers sending Router Advertisements
   with this flag set to 0, they would override this attack given the
   mechanism in Section 5.  Specifically a host would only turn off IPv4
   service if it wasn't hearing any Router Advertisement with the flag
   set to 0.  If the advice in Section 6 is followed, this attack will
   fail.  In a situation where the bad actor has control of all routers
   on the link and sends Router Advertisements with the IPv6-Only flag
   set to 1 from all of them, the attack will succeed, but so will many
   other forms of router-based attack.

   Conversely, a bad actor could use this mechanism to turn on, or
   pretend to turn on, IPv4 service on an IPv6-Only link, by sending
   Router Advertisements with the flag set to 0.  However, this is
   really no different than what such a bad actor can do anyway, if they
   have the ability to configure a bogus router in the first place.  The
   advice in Section 6 will minimize such an attack by limiting it to a
   single link.

   Note that manipulating the Router Preference [RFC4191] will not
   affect either of these attacks: any IPv6-Only flag of 0 will always
   override all flags set to 1.

   The new flag is neutral from an IPv6 privacy viewpoint, since it does
   not affect IPv6 operations in any way.  From an IPv4 privacy
   viewpoint, it has the potential benefit of suppressing unnecessary
   traffic that might reveal the existence of a host and the correlation
   between its hardware and IPv4 addresses.  It should be noted that
   hosts that don't support this flag are not protected from IPv4-based
   attacks.

10.  Acknowledgments

   A closely related proposal was published earlier as
   [I-D.ietf-sunset4-noipv4].

   Helpful comments were received from Lorenzo Colitti, David Farmer,
   Fernando Gont, Nick Hilliard, Lee Howard, Erik Kline, Jen Linkova,

Hinden & Carpenter         Expires May 9, 2019                  [Page 8]
Internet-Draft               IPv6-Only Flag                November 2018

   Veronika McKillop, George Michaelson, Alexandre Petrescu, Michael
   Richardson, Mark Smith, Barbara Stark, Tatuya Jinmei, Ole Troan,
   James Woodyatt, Bjoern Zeeb, and other members of the 6MAN working
   group.

   Bjoern Zeeb has also produced a variant of this proposal and proposed
   an IPv6 transition plan in [I-D.bz-v4goawayflag].

11.  Change log [RFC Editor: Please remove]

      draft-ietf-6man-ipv6only-flag-04, 2018-November-4:

      *  Added text to Section 1 explaining why the mechanism is based
         on Router Advertisements.
      *  Added text to Section 3 that for a VLAN, the IPv6-Only flag
         only applies to the specific VLAN on which it was received.
      *  Changed Section 3 that administrators MUST only use this
         mechanism if they are certain that the link is IPv6-Only,
         instead of SHOULD.
      *  Added ARP to Section 4 protocols that the IPv6-Only flag
         applies to.
      *  Renamed the IPv6-Only flag label from "6" to "S".
      *  Added pointers to Section 7.2.7 of RFC4861 in Section 6.
      *  Added that RFC4861 is also updated by Section 6 for routers
         implementing this flag.
      *  Changed Section 7 from SHOULD NOT to MUST NOT.
      *  Added Appendix A on implementations and testing.
      *  Many small clarifications based on IPv6 list discussion and
         editorial changes.

      draft-ietf-6man-ipv6only-flag-03, 2018-October-16:

      *  Reorganized text about problem statement and applicability
      *  Added note about shortage of flag bits
      *  Clarified text about logging configuration error in Section 6
      *  Editorial changes.

      draft-ietf-6man-ipv6only-flag-02, 2018-August-14:

      *  Added text to Section 9 to clarify that hosts not supporting
         this flag are not protected from IPv4-based attacks.
      *  Editorial changes.

      draft-ietf-6man-ipv6only-flag-01, 2018-June-29:

Hinden & Carpenter         Expires May 9, 2019                  [Page 9]
Internet-Draft               IPv6-Only Flag                November 2018

      *  Added text to section that defines what IPv6-Only includes to
         clarify that only other version of the Internet Protocol are in
         scope.
      *  Added clarification if the lifetime of all routers expire.
      *  Editorial changes.

      draft-ietf-6man-ipv6only-flag-00, 2018-May-21:

      *  Changed the file name to draft-ietf-6man-ipv6only-flag to match
         the current tile and that it is a w.g. draft.
      *  Added new section that defines what IPv6-Only includes.
      *  Expanded description of using Layer 2 filter to block IPv4 and
         ARP traffic.
      *  Editorial changes.

      draft-hinden-ipv4flag-04, 2018-April-16:

      *  Changed the name of the document and flag to be the IPv6-Only
         flag.
      *  Rewrote text to make it affirmative that this is used by an
         administrator to tell the hosts that the link is IPv6-Only.
      *  Added an Applicability Statements section to scope the intend
         use.
      *  Changed requirement language to upper case, added Requirements
         Language section with references to [RFC2119] and [RFC8174].
      *  Editorial changes.

      draft-hinden-ipv4flag-03, 2018-Feb-15:

      *  Changed terminology to use "link" instead of "network".
      *  Improved text in Section 4.  "Host Behavior Considerations" and
         added suggestion to only perform IPv4 if an application
         requests it.
      *  Added clarification that the bit is set because an
         administrator configured the router to send it.
      *  Editorial changes.

      draft-hinden-ipv4flag-02, 2018-Feb-15:

      *  Improved text in introduction.
      *  Added reference to current IANA registry in Section 2.
      *  Editorial changes.

      draft-hinden-ipv4flag-01, 2017-Dec-12

Hinden & Carpenter         Expires May 9, 2019                 [Page 10]
Internet-Draft               IPv6-Only Flag                November 2018

      *  Inverted name of flag from "Available" to "Unavailable".
      *  Added problem description and clarified scope.
      *  Added router and operational considerations.
      *  Added host behavior considerations.
      *  Extended security considerations.
      *  Added Acknowledgment section, including reference to prior
         sunset4 draft.

      draft-hinden-ipv4flag-00, 2017-Nov-17:

      *  Original version.

12.  References

12.1.  Normative References

   [IANA-Ethertype]
              "Ether Types", <https://www.iana.org/assignments/ieee-802-
              numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1>.

   [IANA-RF]  "IPv6 ND Router Advertisement flags",
              <https://www.iana.org/assignments/icmpv6-parameters/
              icmpv6-parameters.xhtml#icmpv6-parameters-11>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997, <https://www.rfc-editor.org/info/
              rfc2119>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <https://www.rfc-editor.org/info/rfc4191>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
              editor.org/info/rfc4861>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Hinden & Carpenter         Expires May 9, 2019                 [Page 11]
Internet-Draft               IPv6-Only Flag                November 2018

12.2.  Informative References

   [I-D.bz-v4goawayflag]
              Zeeb, B., "IPv6 Router Advertisement IPv4 GoAway Flag",
              draft-bz-v4goawayflag-00 (work in progress), March 2018.

   [I-D.ietf-sunset4-noipv4]
              Perreault, S., George, W., Tsou, T., Yang, T., and J.
              Tremblay, "Turning off IPv4 Using DHCPv6 or Router
              Advertisements", draft-ietf-sunset4-noipv4-01 (work in
              progress), December 2014.

   [RFC2563]  Troll, R., "DHCP Option to Disable Stateless Auto-
              Configuration in IPv4 Clients", RFC 2563, DOI 10.17487/
              RFC2563, May 1999, <https://www.rfc-editor.org/info/
              rfc2563>.

   [RFC6104]  Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
              Problem Statement", RFC 6104, DOI 10.17487/RFC6104,
              February 2011, <https://www.rfc-editor.org/info/rfc6104>.

   [RFC6105]  Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
              Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI
              10.17487/RFC6105, February 2011, <https://www.rfc-
              editor.org/info/rfc6105>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <https://www.rfc-editor.org/info/rfc6146>.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              DOI 10.17487/RFC6147, April 2011, <https://www.rfc-
              editor.org/info/rfc6147>.

   [RFC7772]  Yourtchenko, A. and L. Colitti, "Reducing Energy
              Consumption of Router Advertisements", BCP 202, RFC 7772,
              DOI 10.17487/RFC7772, February 2016, <https://www.rfc-
              editor.org/info/rfc7772>.

   [Scapy_RA]
              "Router Advertisements with scapy (NETLAB)",
              <https://samsclass.info/124/proj11/proj9xN-scapy-ra.html>.

Hinden & Carpenter         Expires May 9, 2019                 [Page 12]
Internet-Draft               IPv6-Only Flag                November 2018

Appendix A.  Implementaton Status

   At the time this document was written there is one implementation and
   a few comparability tests.

A.1.  FreeBSD Implementation

   A FreeBSD implementation was written by Bjoern Zeeb.  It can be found
   at:

      https://lists.freebsd.org/pipermail/svn-src-
      head/2018-October/119360.html

   Summary:

      This change defines the RA "6" (IPv6-Only) flag which routers may
      advertise, kernel logic to check if all routers on a link have the
      flag set and accordingly update a per-interface flag.

      If all routers agree that it is an IPv6-only link,
      ether_output_frame(), based on the interface flag, will filter out
      all ETHERTYPE_IP/ARP frames, drop them, and return EAFNOSUPPORT to
      upper layers.

      The change also updates ndp to show the "6" flag, ifconfig to
      display the IPV6_ONLY nd6 flag if set, and rtadvd to allow
      announcing the flag.

      The code was tested with 2 FreeBSD IPv6 routers, a FreeBSD laptop
      on ethernet as well as wifi, and with Win10 and OSX clients (which
      did not fall over with the "6" flag set but not understood).

A.2.  Test using Scapy

   Independent tests have been done using [Scapy_RA] by Alexandre
   Petrescu and Brian Carpenter to verify that setting the IPv6-Only
   Flag did not break legacy hosts.  Both verified that setting this
   flag did not cause any adverse effects on Windows 10 and Android.

Authors' Addresses

   Robert M. Hinden
   Check Point Software
   959 Skyway Road
   San Carlos, CA  94070
   USA

   Email: bob.hinden@gmail.com

Hinden & Carpenter         Expires May 9, 2019                 [Page 13]
Internet-Draft               IPv6-Only Flag                November 2018

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

Hinden & Carpenter         Expires May 9, 2019                 [Page 14]