draft-ietf-6man-ipv6only-flag-04.txt   draft-ietf-6man-ipv6only-flag-05.txt 
Network Working Group R. Hinden Network Working Group R. Hinden
Internet-Draft Check Point Software Internet-Draft Check Point Software
Updates: 4861, 5175 (if approved) B. Carpenter Updates: 4861, 5175 (if approved) B. Carpenter
Intended status: Standards Track Univ. of Auckland Intended status: Standards Track Univ. of Auckland
Expires: May 9, 2019 November 5, 2018 Expires: September 8, 2019 B. Zeeb
March 7, 2019
IPv6 Router Advertisement IPv6-Only Flag IPv6 Router Advertisement IPv6-Only Flag
draft-ietf-6man-ipv6only-flag-04 draft-ietf-6man-ipv6only-flag-05
Abstract Abstract
This document specifies a Router Advertisement Flag to indicate to This document specifies a Router Advertisement Flag to indicate to
hosts that the administrator has configured the router to advertise hosts that the administrator has configured the router to advertise
that the link is IPv6-Only. This document updates RFC4861 and that the link is IPv6-Only. This document updates RFC4861 and
RFC5175. RFC5175.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 9, 2019. This Internet-Draft will expire on September 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 14 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statements . . . . . . . . . . . . . . . . . . 4 3. Applicability Statements . . . . . . . . . . . . . . . . . . 4
4. IPv6-Only Definition . . . . . . . . . . . . . . . . . . . . 5 4. IPv6-Only Definition . . . . . . . . . . . . . . . . . . . . 5
5. IPv6-Only Flag . . . . . . . . . . . . . . . . . . . . . . . 5 5. IPv6-Only Flag . . . . . . . . . . . . . . . . . . . . . . . 5
6. Router and Operational Considerations . . . . . . . . . . . . 6 6. Router and Operational Considerations . . . . . . . . . . . . 6
7. Host Behavior Considerations . . . . . . . . . . . . . . . . 7 7. Host Behavior Considerations . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Implementaton Status . . . . . . . . . . . . . . . . 13 Appendix A. Implementaton Status [RFC Editor: Please remove] . . 14
A.1. FreeBSD Implementation . . . . . . . . . . . . . . . . . 13 A.1. FreeBSD Implementation . . . . . . . . . . . . . . . . . 14
A.2. Test using Scapy . . . . . . . . . . . . . . . . . . . . 13 A.2. Test using Scapy . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies a Router Advertisement Flag to indicate to This document specifies a Router Advertisement Flag to indicate to
hosts that the administrator has configured the router to advertise hosts that the administrator has configured the router to advertise
that the link is IPv6-Only. The flag only applies to IPv6 default that the link is IPv6-Only. The flag only applies to IPv6 default
routers. routers.
Hosts that support IPv4 and IPv6, usually called dual stack hosts, Hosts that support IPv4 and IPv6, usually called dual stack hosts,
need to also work efficiently on IPv6-Only links, i.e, links where need to also work efficiently on IPv6-Only links, i.e, links where
skipping to change at page 4, line 35 skipping to change at page 4, line 39
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Applicability Statements 3. Applicability Statements
This OPTIONAL mechanism is designed to allow administrators to notify This OPTIONAL mechanism is designed to allow administrators to notify
hosts that the link is IPv6-Only. It SHOULD be only used in 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 links (see Section 4 for definition of IPv6-Only). For a
IPv6-Only flag only applies to the specific VLAN on which it was VLAN, the IPv6-Only flag only applies to the specific VLAN on which
received. it was received.
Dual stack hosts that have a good reason to use IPv4, for example for Dual stack hosts that have IPv4 active configuration obtained from
a specific IPv4 link-local service, can attempt to do so. Therefore the network (e.g., via DHCP), can ignore the flag and continue to use
respect of the IPv6-Only flag is recommended, not mandatory, for IPv4.
hosts.
Administrators MUST only use this mechanism if they are certain that 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 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 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 hosts or IPv4 routers on the link, setting this flag to 1 is a
configuration error. configuration error.
This mechanism is intended to be compatible with link-layer solutions This mechanism is intended to be compatible with link-layer solutions
that filter out IPv4 traffic. that filter out IPv4 traffic.
skipping to change at page 6, line 37 skipping to change at page 6, line 40
2008, no new RA flags have been assigned in the IANA registry. 2008, no new RA flags have been assigned in the IANA registry.
6. Router and Operational Considerations 6. Router and Operational Considerations
Default IPv6 routers that are on an IPv6-Only link SHOULD be 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 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 interfaces on this link. In all other cases the flag SHOULD NOT be
set to 1. set to 1.
The intent is that the administrator of the router configures the 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 router to set the IPv6-Only flag if and only if she/he wants to tell
the link that the link is IPv6-Only. This is a configuration flag, the hosts on the link that the link is IPv6-Only. This is a
it is not something that the router decides on its own. Routers MAY configuration flag, it is not something that the router decides on
log a configuration error if the flag is set and IPv4 is still active its own. Routers MAY log a configuration error if the flag is set
on the router's interface to the link. and IPv4 is still active on the router's interface to the link.
Routers implementing this document SHOULD log to system or network Routers implementing this document SHOULD log to system or network
management inconsistent setting of the IPv6-Only flag. This extends management inconsistent setting of the IPv6-Only flag. This extends
the behaviour specified in Section 6.2.7 of [RFC4861]. the behaviour specified in Section 6.2.7 of [RFC4861].
Operators of large IPv6-Only wireless links are advised to also use Operators of large IPv6-Only wireless links are advised to also use
Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800 Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800
and 0x0806) at all switches, and to ensure that IPv4 and ARP features and 0x0806) at all switches, and to ensure that IPv4 and ARP features
are disabled in all switches. are disabled in all switches.
7. Host Behavior Considerations 7. Host Behavior Considerations
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 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 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 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 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 with value 1, a dual stack host SHOULD assume that this is an
IPv6-Only link. IPv6-Only link.
A host that receives only RAs with the flag set to 1 SHOULD NOT A host that receives only RAs with the flag set to 1 SHOULD NOT
attempt any IPv4 operations, unless it subsequently receives at least 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, one RA with the flag set to zero. As soon as such an RA is received,
IPv4 operations MAY be started. 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 A host MAY delay all IPv4 operations at start-up or reconnection
until a reasonable time has elapsed for RA messages to arrive. If 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 all RAs received have the flag set to 1, a host SHOULD NOT attempt
IPv4 operations. IPv4 operations.
In all of the above, the flag's value is considered valid for the In all of the above, the flag's value is considered valid for the
lifetime of the default router concerned, unless a subsequent RA lifetime of the default router concerned, unless a subsequent RA
delivers a different flag value. If a default router expires (i.e., delivers a different flag value. If a default router expires (i.e.,
no RA is received that refreshes its lifetime), the host must remove no RA is received that refreshes its lifetime), the host must remove
this router's flag value from consideration. If the result is that this router's flag value from consideration. If the result is that
skipping to change at page 8, line 15 skipping to change at page 8, line 33
9. Security Considerations 9. Security Considerations
This document shares the security issues with other parts of IPv6 This document shares the security issues with other parts of IPv6
Neighbor Discovery. [RFC6104] discusses certain attacks and Neighbor Discovery. [RFC6104] discusses certain attacks and
mitigations. General techniques to protect Router Advertisement mitigations. General techniques to protect Router Advertisement
traffic such as Router Guard [RFC6105] are useful in protecting traffic such as Router Guard [RFC6105] are useful in protecting
against these vulnerabilities. against these vulnerabilities.
A bad actor could use this mechanism to attempt turn off IPv4 service A bad actor could use this mechanism to attempt turn off IPv4 service
on a link that is intentionally using IPv4, by sending Router on a link that is intentionally using IPv4, by sending Router
Advertisements with the IPv6-Only flag set to 1. In that case, as Advertisements with the IPv6-Only flag set to 1. There are several
long as there are one or more routers sending Router Advertisements protections to reduce this attack. These are:
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 o There is configuration setting that controls if the host should
service if it wasn't hearing any Router Advertisement with the flag process the IPv6-Only flag. This gives local control over using
set to 0. If the advice in Section 6 is followed, this attack will the flag and reduces the ability of a bad actor to turn off IPv4
fail. In a situation where the bad actor has control of all routers for hosts that support the flag.
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 o As long as there are one or more routers sending Router
other forms of router-based attack. 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.
o An attack would not succeed if the dual stack hosts had active
IPv4 configuration. As specified in Section 7, 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 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 pretend to turn on, IPv4 service on an IPv6-Only link, by sending
Router Advertisements with the flag set to 0. However, this is 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 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 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 advice in Section 6 will minimize such an attack by limiting it to a
single link. single link.
Note that manipulating the Router Preference [RFC4191] will not Note that manipulating the Router Preference [RFC4191] will not
skipping to change at page 9, line 6 skipping to change at page 9, line 40
10. Acknowledgments 10. Acknowledgments
A closely related proposal was published earlier as A closely related proposal was published earlier as
[I-D.ietf-sunset4-noipv4]. [I-D.ietf-sunset4-noipv4].
Helpful comments were received from Lorenzo Colitti, David Farmer, Helpful comments were received from Lorenzo Colitti, David Farmer,
Fernando Gont, Nick Hilliard, Lee Howard, Erik Kline, Jen Linkova, Fernando Gont, Nick Hilliard, Lee Howard, Erik Kline, Jen Linkova,
Veronika McKillop, George Michaelson, Alexandre Petrescu, Michael Veronika McKillop, George Michaelson, Alexandre Petrescu, Michael
Richardson, Mark Smith, Barbara Stark, Tatuya Jinmei, Ole Troan, Richardson, Mark Smith, Barbara Stark, Tatuya Jinmei, Ole Troan,
James Woodyatt, Bjoern Zeeb, and other members of the 6MAN working James Woodyatt, and other members of the 6MAN working group.
group.
Bjoern Zeeb has also produced a variant of this proposal and proposed Bjoern Zeeb has also produced a variant of this proposal and proposed
an IPv6 transition plan in [I-D.bz-v4goawayflag]. an IPv6 transition plan in [I-D.bz-v4goawayflag].
11. Change log [RFC Editor: Please remove] 11. Change log [RFC Editor: Please remove]
draft-ietf-6man-ipv6only-flag-05, 2019-March-7:
* Added a host configuration option to Section 7 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 Section 7 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 Section 3 and
Section 9
* Clarification in Section 6 to strengthen the text about the
administrators intent.
* Added Bjoern Zeeb as an author.
* Updated information on FreeBSD implementation in Appendix A.1
* Editorial changes.
draft-ietf-6man-ipv6only-flag-04, 2018-November-4: draft-ietf-6man-ipv6only-flag-04, 2018-November-4:
* Added text to Section 1 explaining why the mechanism is based * Added text to Section 1 explaining why the mechanism is based
on Router Advertisements. on Router Advertisements.
* Added text to Section 3 that for a VLAN, the IPv6-Only flag * Added text to Section 3 that for a VLAN, the IPv6-Only flag
only applies to the specific VLAN on which it was received. only applies to the specific VLAN on which it was received.
* Changed Section 3 that administrators MUST only use this * Changed Section 3 that administrators MUST only use this
mechanism if they are certain that the link is IPv6-Only, mechanism if they are certain that the link is IPv6-Only,
instead of SHOULD. instead of SHOULD.
* Added ARP to Section 4 protocols that the IPv6-Only flag * Added ARP to Section 4 protocols that the IPv6-Only flag
skipping to change at page 13, line 5 skipping to change at page 14, line 9
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772, Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016, <https://www.rfc- DOI 10.17487/RFC7772, February 2016, <https://www.rfc-
editor.org/info/rfc7772>. editor.org/info/rfc7772>.
[Scapy_RA] [Scapy_RA]
"Router Advertisements with scapy (NETLAB)", "Router Advertisements with scapy (NETLAB)",
<https://samsclass.info/124/proj11/proj9xN-scapy-ra.html>. <https://samsclass.info/124/proj11/proj9xN-scapy-ra.html>.
Appendix A. Implementaton Status Appendix A. Implementaton Status [RFC Editor: Please remove]
At the time this document was written there is one implementation and At the time this document was written there is one implementation and
a few comparability tests. a few comparability tests.
A.1. FreeBSD Implementation A.1. FreeBSD Implementation
A FreeBSD implementation was written by Bjoern Zeeb. It can be found A FreeBSD implementation was written by Bjoern A. Zeeb.
at:
https://lists.freebsd.org/pipermail/svn-src-
head/2018-October/119360.html
Summary: Summary:
This change defines the RA "6" (IPv6-Only) flag which routers may Changes for the IPv6-Only flag include updates of user space
advertise, kernel logic to check if all routers on a link have the utilities to announce the "S" (IPv6-Only) flag to the network and
flag set and accordingly update a per-interface flag. to show it in management utilities.
If all routers agree that it is an IPv6-only link, The kernel logic includes a global flag to disable processing of
ether_output_frame(), based on the interface flag, will filter out the IPv6-Only flag even if the logic to act upon the IPv6-Only
all ETHERTYPE_IP/ARP frames, drop them, and return EAFNOSUPPORT to flag is compiled in. There are checks for IPv4 configuration on a
upper layers. receiving interface, which if found, will also force the IPv6-Only
flag to be ignored.
The change also updates ndp to show the "6" flag, ifconfig to Further there are input and output filters for IPv4, ARP, and
display the IPV6_ONLY nd6 flag if set, and rtadvd to allow REVARP in place for when the flag passes the aforementioned checks
announcing the flag. 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 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 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). 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/IPv6OnlyRAFlag
A.2. Test using Scapy A.2. Test using Scapy
Independent tests have been done using [Scapy_RA] by Alexandre Independent tests have been done using [Scapy_RA] by Alexandre
Petrescu and Brian Carpenter to verify that setting the IPv6-Only 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 break legacy hosts. Both verified that setting this
flag did not cause any adverse effects on Windows 10 and Android. flag did not cause any adverse effects on Windows 10 and Android.
Authors' Addresses Authors' Addresses
skipping to change at page 14, line 4 skipping to change at page 15, line 16
Authors' Addresses Authors' Addresses
Robert M. Hinden Robert M. Hinden
Check Point Software Check Point Software
959 Skyway Road 959 Skyway Road
San Carlos, CA 94070 San Carlos, CA 94070
USA USA
Email: bob.hinden@gmail.com Email: bob.hinden@gmail.com
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
Bjoern A. Zeeb
Bruehlstr. 19
Bondorf 71149
Germany
Email: bzeeb+ietf@zabbadoz.net
 End of changes. 23 change blocks. 
54 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/