IPv6 Router Advertisement IPv6-Only Flag

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 does not apply to non-default IPv6 routers. Hosts that support IPv4 and IPv6, usually called dual stack hosts, need to also work efficiently on IPv6 only links. That is, a link 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 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: It may result in an undesirable level of wasted Layer 2 broadcast traffic. In particular, this may overload switches in multi-segment wireless networks if the switches create IPv4 state for every dual stack host. 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. indicates how this risk might be quantified. Similarly, hosts may waste battery power on futile attempts to access services by sending IPv4 packets. On an IPv6-only link, IPv4 might be used for malicious purposes and pass unnoticed by IPv6-only monitoring mechanisms. In managed networks 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 0x806 . 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 no IPv4 DHCP server or relay is active on the link, because it is an IPv6-only link. If this assumption is false, the DHCP option to disable IPv4 stateless auto-configuration could 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 IPv6-only routers, 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 link, mitigating all of the above problems. 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 . It updates to add this flag.

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 when, and only when, they appear in all capitals, as shown here.

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

IPv6-Only is defined to mean that no other versions of internet protocol than IPv6 are intentionally running directly on the link. Today this effectively simply means that IPv4 is not running 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 for access to IPv4 external services to be reached by techniques such as NAT64 and DNS64 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 running directly over the link layer. It is out of scope of this specification whether any such protocol is running on the link or whether any protocol is tunneled over IPv6.

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 . This currently contains the following one-bit flags defined in published RFCs:

Managed Address Configuration Flag Other Configuration Flag Mobile IPv6 Home Agent Flag [RFC3775] Router Selection Preferences [RFC4191] Neighbor Discovery Proxy Flag [RFC4389] Reserved This document defines bit 6 to be the IPv6-Only Flag: IPv6-Only Flag This flag has two values. These are: This is not an IPv6-Only link 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 SHOUD 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 in case additional flags are ever required for future extensions.

Default IPv6 routers that are on an IPv6-Only link SHOULD be configured 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 it's own. Routers MAY log a configuration error if the flag is set and IPv4 is still active on the routers interface to the link. Operators of large IPv6-only wireless links are advised to also use Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800 and 0x806) at all switches, and to ensure that IPv4 and ARP features are disabled in all switches.

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 SHOULD 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 SHOULD be started. A host MAY choose to delay all IPv4 operations at start-up until a reasonable time has elapsed for RA messages to arrive. If all RAs received have the flag set, a host SHOULD also choose to not attempt IPv4 operations until an application asks it to, specifically delay performing DHCPV4 until it gets a request from an application to use IPv4. This would avoid attempting to obtain IPv4 addresses if there are no applications trying to use IPv4. 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. This also means that if all default routers have set the flag, the flag for the host is thereby set. If the lifetimes of all the routers subsequently expire, then the state of the flag for the host becomes cleared.

IANA is requested to assign the new Router Advertisement flag defined in 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 .

This document shares the security issues with other parts of IPv6 Neighbor Discovery. discusses certain attacks and mitigations. General techniques to protect Router Advertisement traffic such as Router Guard 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 . 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 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 will minimize such an attack by limiting it to a single link. Note that manipulating the Router Preference 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.

A closely related proposal was published earlier as . Helpful comments were received from Lorenzo Colitti, David Farmer, Fernando Gont, Nick Hilliard, Erik Kline, Jen Linkova, Veronika McKillop, George Michaelson, Michael Richardson, Mark Smith, Barbara Stark, Tatuya Jinmei, Ole Troan, James Woodyatt, 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 .

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 Editorial changes. draft-ietf-6man-ipv6only-flag-02, 2018-August-14: Added text to 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: 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 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.