]>
IPv6 Router Advertisement IPv6-Only FlagCheck Point Software959 Skyway RoadSan CarlosCA94070USAbob.hinden@gmail.comDepartment of Computer ScienceUniversity of AucklandPB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comBruehlstr. 19Bondorf71149Germanybzeeb+ietf@zabbadoz.netThis 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.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:
It may result in an undesirable level of wasted Layer 2 broadcast traffic.Switches in multi-segment wireless networks may create IPv4 state
for dual stack hosts (in particular, ARP cache entries to support ARP
proxying).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 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
. 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
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 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
. It updates to add
this flag. It also updates to add an
additional item to check and report.
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 for definition of
IPv6-Only). For a VLAN, the IPv6-Only flag only applies to the
specific VLAN on which it was received.
Dual stack hosts that have IPv4 active configuration
obtained from the network (e.g., via DHCP), can ignore the
flag and continue to use IPv4.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.
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 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 (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.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]ReservedThis document defines bit 6 to be the IPv6-Only Flag:IPv6-Only FlagThis flag has two values. These are:This is not an IPv6-Only linkThis is an IPv6-Only linkRFC 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
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.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 and only 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 .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.Hosts that support the IPv6-Only RA flag MUST have a configuration
option to ignore or process the flag.
The motivation for this
configuration option is for hosts that are capable of processing the
IPv6-Only flag to only act on the flag if they are configured to do so.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.
If the host has active IPv4
configuration information obtained from the network (e.g., via DHCP), the
flag can be ignored and IPv4 operations can continue. The
host MAY implement a policy overriding these default behaviors.
In the event that the host subsequently receives at least
one RA with the flag set to zero 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.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. There are several protections to reduce
this attack. These are:There is configuration setting that controls if the host should process
the IPv6-Only flag. This gives local control over using
the flag and reduces the ability of a bad actor to turn off IPv4 for
hosts that support the flag.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.An attack would not succeed if the dual
stack hosts had active IPv4 configuration. As specified in , a dual stack host will ignore the flag if it has
active IPv4 configuration.
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 and if the hosts
don't have assigned IPv4 addresses, 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,
Lee Howard,
Erik Kline,
Jen Linkova,
Veronika McKillop,
George Michaelson,
Alexandre Petrescu,
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-05, 2019-March-7:Added a host configuration option to that
controls if the host should process the IPv6-Only flag. This provides
local control over using the use of flag and reduces the
ability of a bad actor to turn off IPv4 for hosts that support the
flag.
Changed to specify that the host can ignore
flag set to 1 if it has active IPv4 configuration obtained from the
network (e.g., via DHCP). Similar changes to
and Clarification in to strengthen the text
about the administrators intent.Added Bjoern Zeeb as an author.Updated information on FreeBSD implementation in Editorial changes.draft-ietf-6man-ipv6only-flag-04, 2018-November-4:Added text to explaining why the mechanism is
based on Router Advertisements.Added text to that for a VLAN, the
IPv6-Only flag only applies to the specific VLAN on which it was
received.Changed that administrators MUST only use this
mechanism if they are certain that the link is IPv6-Only, instead of
SHOULD.Added ARP to 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 .Added that RFC4861 is also updated by for
routers implementing this flag.Changed from SHOULD NOT to MUST NOT.Added 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 applicabilityAdded note about shortage of flag bitsClarified 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-12Inverted 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.IPv6 ND Router Advertisement flagsEther Types
&rfc6146;
&rfc6147;
&I-D.bz-v4goawayflag;
Router Advertisements with scapy (NETLAB)At the time this document was written there is one implementation
and a few comparability tests.A FreeBSD implementation was written by Bjoern A. Zeeb.Summary:Changes for the IPv6-Only flag include updates of user space utilities
to announce the "S" (IPv6-Only) flag to the network and to show it in
management utilities.The kernel logic includes a global flag to disable processing of the
IPv6-Only flag even if the logic to act upon the IPv6-Only flag is
compiled in. There are checks for IPv4 configuration on a receiving
interface, which if found, will also force the IPv6-Only flag to be
ignored.Further there are input and output filters for IPv4, ARP, and REVARP in
place for when the flag passes the aforementioned checks and is enabled.In addition to the draft there is a manual option to enable the
IPv6-Only filtering logic manually to observe the system behaviour
on links without router(s) advertising the IPv6-Only 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 "S" flag set but not understood).More information and updates can be found at:https://wiki.freebsd.org/IPv6/IPv6OnlyRAFlagIndependent tests have been done using
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.