[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-gont-6man-slaac-renum) 00 01
IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks
Updates: 4861, 4862 (if approved) J. Zorz
Intended status: Standards Track 6connect
Expires: February 27, 2021 R. Patterson
Sky UK
August 26, 2020
Improving the Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events
draft-ietf-6man-slaac-renum-01
Abstract
In renumbering scenarios where an IPv6 prefix suddenly becomes
invalid, hosts on the local network will continue using stale
prefixes for an unacceptably long period of time, thus resulting in
connectivity problems. This document improves the reaction of IPv6
Stateless Address Autoconfiguration to such renumbering scenarios.
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 February 27, 2021.
Copyright Notice
Copyright (c) 2020 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
Gont, et al. Expires February 27, 2021 [Page 1]
Internet-Draft Reaction to Renumbering Events August 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4
3.1. Renumbering without Explicit Signaling . . . . . . . . . 4
3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5
4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6
4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7
4.1.1. Router Configuration Variables . . . . . . . . . . . 7
4.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7
4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7
4.3. Interface Initialization . . . . . . . . . . . . . . . . 8
4.4. Conveying Information in Router Advertisement (RA)
Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Recovery from Stale Configuration Information without
Explicit Signaling . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 9
6.1.1. Router Configuration Variables . . . . . . . . . . . 9
6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 9
6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 10
6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 10
6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 10
6.3. Conveying Information in Router Advertisement (RA)
Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Recovery from Stale Configuration Information without
Explicit Signaling . . . . . . . . . . . . . . . . . . . 10
6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 10
6.5. Other mitigations implemented in products . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 15
A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 15
A.2. On a Possible Improvement to Source Address Selection . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Gont, et al. Expires February 27, 2021 [Page 2]
Internet-Draft Reaction to Renumbering Events August 2020
1. Introduction
IPv6 network renumbering is expected to take place in a planned
manner, with old/stale prefixes being phased-out via reduced prefix
lifetimes while new prefixes (with normal lifetimes) are introduced.
However, there are a number of scenarios that may lead to the so-
called "flash-renumbering" events, where the prefix being employed on
a network suddenly becomes invalid and replaced by a new prefix
[I-D.ietf-v6ops-slaac-renum]. In such scenarios, hosts on the local
network will continue using stale prefixes for an unacceptably long
period of time, thus resulting in connectivity problems.
[I-D.ietf-v6ops-slaac-renum] discusses this problem in detail.
In some scenarios, the local router producing the network renumbering
event may try to deprecate the currently-employed prefixes (thus
explicitly signaling the network about the renumbering event),
whereas in other scenarios it may be unaware about the renumbering
event and thus unable signal hosts about it.
From the perspective of a Stateless Address Autoconfiguration (SLAAC)
host, there are two different (but related) problems to be solved:
o Avoiding the use of stale addresses for new communication
instances
o Performing "garbage collection" for the stale prefixes (and
related network configuration information)
Clearly, if a host has both working and stale addresses, it is
paramount that it employs working addresses for new communication
instances. Additionally, a host should also perform garbage
collection for the stale prefixes/addresses, since they not only tie
system resources, but also prevent communication with the new
"owners" of the stale prefixes.
2. Terminology
The term "globally reachable" is used in this document as defined in
[RFC8190].
The term "Global Unicast Address" (or its acronym "GUA") is used
throughout this document to refer to "globally reachable" [RFC8190]
addresses. That is, when used throughout this document, GUAs do NOT
include Unique Local Addresses (ULAs) [RFC4193]. Similarly, the term
"Global Unicast prefix" (or "GUA prefix") is employed throughout this
document to refer to network prefixes that specify GUAs, and does NOT
include the ULA prefix (FC00::/7) [RFC4193].
Gont, et al. Expires February 27, 2021 [Page 3]
Internet-Draft Reaction to Renumbering Events August 2020
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. SLAAC reaction to Flash-renumbering Events
As noted in Section 1, in some scenarios the router triggering the
renumbering event may be able to explicitly signal the network about
this event, while in other scenarios the renumbered hosts may need to
infer a renumbering event is taking place. The following subsections
analyze specific considerations for each of these scenarios.
3.1. Renumbering without Explicit Signaling
In the absence of explicit signalling from SLAAC routers (such as
sending Prefix Information Options (PIOs) with small lifetimes to
deprecate the stale prefixes), stale prefixes will remain preferred
and valid according to the Preferred Lifetime and Valid Lifetime
values (respectively) of the last received PIO. IPv6 SLAAC employs
the following default values for PIOs:
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
This means that, in the absence of explicit signaling by a SLAAC
router to deprecate a prefix, it will take a host 7 days (one week)
to deprecate the corresponding addresses, and 30 days (one month) to
eventually remove any addresses configured for the stale prefix.
Clearly, for any practical purposes, employing such long default
values is the equivalent of not using any timers at all, since taking
7 days or 30 days (respectively) to recover from a network problem is
simply unacceptable.
Use of more appropriate timers in Router Advertisement messages can
help limit the amount of time that hosts will maintain stale
configuration information. Additionally, hosts are normally in a
position to infer that a prefix has become stale -- for example, if a
given router ceases to advertise an existing prefix and at the same
time starts to advertise a new prefix.
Section 4.1.1 recommends the use of more appropriate lifetimes for
PIOs, while Section 4.1.2 proposes to cap the accepted Valid Lifetime
and Preferred Lifetime values at hosts, such that more appropriate
values are employed even in the presence of legacy routers.
Gont, et al. Expires February 27, 2021 [Page 4]
Internet-Draft Reaction to Renumbering Events August 2020
Section 4.5 specifies a local policy that SLAAC hosts can implement
to heuristically infer that network configuration information has
changed, such that stale configuration information can be phased out.
3.2. Renumbering with Explicit Signaling
In scenarios where a local router is aware about the renumbering
event, it may try to phase out the stale network configuration
information. In these scenarios, there are two aspects to be
considered:
o The amount of time during which the router should continue trying
to deprecate the stale network configuration information
o The ability of SLAAC hosts to phase out stale configuration in a
timelier manner.
In the absence of Router Advertisements (RAs) that include PIOs that
would reduce the Valid Lifetime and Preferred Lifetime of a prefix,
hosts would normally employ the lifetime values from PIO options of
the last received RA messages. Since the network could be
partitioned for an arbitrarily long period of time, a router would
need to try to deprecate a prefix for the amount of time employed for
the "Preferred Lifetime", and try to invalidate the prefix for the
amount of time employed for the "Valid Lifetime" (see Section 12 of
[RFC4861]).
NOTE:
Once the number of seconds in the original "Preferred Lifetime"
have elapsed, all hosts would have deprecated the corresponding
addresses anyway, while once the number of seconds in the "Valid
Lifetime" have elapsed, the corresponding addresses would be
invalidated and removed.
Thus, use of more appropriate default lifetimes for PIOs, as proposed
in Section 4.1.1, would reduce the amount of time a stale prefix
would need to be announced as such by a router in order to make sure
that it is deprecated/invalidated.
In scenarios where a router has positive knowledge that a prefix has
become invalid and thus could signal this condition to local hosts,
the current specifications will prevent SLAAC hosts from fully
recovering from such stale information. Item "e)" of Section 5.5.3
of [RFC4862] specifies that an RA may never reduce the
"RemainingLifetime" to less than two hours. Additionally, if the
RemainingLifetime of an address is smaller than 2 hours, then a Valid
Lifetime smaller than 2 hours will be ignored. The inability to
invalidate a stale prefix would prevent communication with the new
Gont, et al. Expires February 27, 2021 [Page 5]
Internet-Draft Reaction to Renumbering Events August 2020
"owners" of the stale prefix, and thus is highly undesirable. On the
other hand, the Preferred Lifetime of an address *can* be reduced to
any value to avoid the use of a stale prefix for new communications.
Section 4.2 updates [RFC4862] such that this restriction in removed,
and hosts react to the advertised "Valid Lifetime" (even if it is
smaller than 2 hours).
Finally, Section 4.3 recommends that routers disseminate network
configuration information when a network interface is initialized,
such that possibly new configuration information propagates in a
timelier manner.
4. Improvements to Stateless Address Autoconfiguration (SLAAC)
The following subsections update [RFC4861] and [RFC4862], such that
the problem discussed in this document is mitigated. The
aforementioned updates are mostly orthogonal, and mitigate different
aspects of SLAAC that prevent a timely reaction to flash renumbering
events.
o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs
(Section 4.1.1):
This helps limit the amount of time a host will employ stale
information, and also limits the amount of time a router needs to
try to obsolete stale information.
o Cap the received Valid Lifetime and Preferred Lifetime of PIOs
(Section 4.1.2):
This helps limit the amount of time a host will employ stale
information, even in the presence of legacy ([RFC4861]) routers.
o Honor PIOs with small Valid Lifetimes (Section 4.2):
This allows routers to invalidate stale prefixes, since otherwise
[RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime
smaller than two hours.
o Recommend routers to retransmit configuration information upon
interface initialization/reinitialization (Section 4.3):
This helps spread the new information in a timelier manner, and
also deprecate stale information via host-side heuristics (see
Section 4.5).
o Recommend routers to always send all options (i.e. the complete
configuration information) in RA messages, and in the smallest
possible number of packets (Section 4.4):
Gont, et al. Expires February 27, 2021 [Page 6]
Internet-Draft Reaction to Renumbering Events August 2020
This helps propagate the same information to all hosts, and also
allows hosts to better infer that information missing in RA
messages has become stale (see Section 4.5).
o Infer stale network configuration information from received RAs
(Section 4.5):
This allows hosts to deprecate stale network configuration
information, even in the absence of explicit signaling.
4.1. More Appropriate Lifetime Values
4.1.1. Router Configuration Variables
[TBD]
4.1.2. Processing of PIO Lifetimes at Hosts
[TBD]
4.2. Honor Small PIO Valid Lifetimes
The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is
replaced with the following text:
e) If the advertised prefix is equal to the prefix of an address
configured by stateless autoconfiguration in the list, the valid
lifetime and the preferred lifetime of the address should be
updated by processing the Valid Lifetime and the Preferred
Lifetime (respectively) in the received advertisement.
NOTE:
"Processing" the Valid Lifetime and Preferred Lifetime includes
capping the received values as specified in Section 4.1.2 of this
document.
RATIONALE:
* This change allows hosts to react to the information provided
by a router that has positive knowledge that a prefix has
become invalid.
* The behavior described in RFC4862 had been incorporated during
the revision of the original IPv6 Stateless Address
Autoconfiguration specification ([RFC1971]). At the time, the
IPNG working group decided to mitigate the attack vector
represented by Prefix Information Options with very short
lifetimes, on the premise these packets represented a bigger
risk than other ND-based attack vectors [IPNG-minutes].
Gont, et al. Expires February 27, 2021 [Page 7]
Internet-Draft Reaction to Renumbering Events August 2020
While reconsidering the trade-offs represented by such
decision, we conclude that the drawbacks of mitigating the
aforementioned attack vector outweigh the possible benefits.
In scenarios where RA-based attacks are of concern, proper
mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND
[RFC3971] should be implemented.
4.3. Interface Initialization
When an interface is initialized, it is paramount that network
configuration information is spread on the corresponding network
(particularly in scenarios where an interface has been re-
initialized, and the conveyed information has changed). Thus, this
document replaces the following text from Section 6.2.4 of [RFC4861]:
In such cases, the router MAY transmit up to
MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using
the same rules as when an interface becomes an advertising
interface.
with:
In such cases, the router SHOULD transmit
MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using
the same rules as when an interface becomes an advertising
interface.
RATIONALE:
* Use of stale information can lead to interoperability problems.
Therefore, it is important that new configuration information
propagates in a timelier manner to all hosts.
NOTE:
[I-D.ietf-v6ops-cpe-slaac-renum] specifies recommendations for CPE
routers to deprecate any stale network configuration information.
4.4. Conveying Information in Router Advertisement (RA) Messages
[TBD]
4.5. Recovery from Stale Configuration Information without Explicit
Signaling
[TBD]
Gont, et al. Expires February 27, 2021 [Page 8]
Internet-Draft Reaction to Renumbering Events August 2020
5. IANA Considerations
This document has no actions for IANA.
6. Implementation Status
[NOTE: This section is to be removed by the RFC-Editor before this
document is published as an RFC.]
This section summarizes the implementation status of the updates
proposed in this document. In some cases, they correspond to
variants of the mitigations proposed in this document (e.g., use of
reduced default lifetimes for PIOs, albeit using different values
than those recommended in this document). In such cases, we believe
these implementations signal the intent to deal with the problems
described in [I-D.ietf-v6ops-slaac-renum] while lacking any guidance
on the best possible approach to do it.
6.1. More Appropriate Lifetime Values
6.1.1. Router Configuration Variables
6.1.1.1. rad(8)
We have produced a patch for OpenBSD's rad(8) [rad] that employs the
default lifetimes recommended in this document, albeit it has not yet
been committed to the tree. The patch is available at:
<https://www.gont.com.ar/code/fgont-patch-rad-pio-lifetimes.txt>.
6.1.1.2. radvd(8)
The radvd(8) daemon [radvd], normally employed by Linux-based router
implementations, currently employs different default lifetimes than
those recommended in [RFC4861]. radvd(8) employs the following
default values [radvd.conf]:
o Preferred Lifetime: 14400 seconds (4 hours)
o Valid Lifetime: 86400 seconds (1 day)
This is not following the specific recommendation in this document,
bu is already a deviation from the current standards.
6.1.2. Processing of PIO Lifetimes at Hosts
Gont, et al. Expires February 27, 2021 [Page 9]
Internet-Draft Reaction to Renumbering Events August 2020
6.1.2.1. NetworkManager
NetworkManager [NetworkManager], user-space SLAAC implementation
employed by some Linux-based operating systems (such as Fedora or
Ubuntu), caps the lifetimes of the received PIOs as recommended in
this document.
6.1.2.2. slaacd(8)
slaacd(8) [slaacd], a user-space SLAAC implementation employed by
OpenBSD, caps the lifetimes of the received PIOs as recommended in
this document.
6.1.2.3. systemd-networkd
systemd-networkd [systemd], a user-space SLAAC implementation
employed by some Linux-based operating systems, caps the lifetimes of
the received PIOs as recommended in this document.
6.2. Honor Small PIO Valid Lifetimes
6.2.1. Linux Kernel
A Linux kernel implementation of this document has been committed to
the net-next tree. The implementation was produced in April 2020 by
Fernando Gont <fgont@si6networks.com>. The corresponding patch can
be found at: <https://patchwork.ozlabs.org/project/netdev/
patch/20200419122457.GA971@archlinux-current.localdomain/>
6.2.2. NetworkManager
NetworkManager [NetworkManager] processes RA messages with a Valid
Lifetime smaller than two hours as recommended in this document.
6.3. Conveying Information in Router Advertisement (RA) Messages
We know of no implementation that splits network configuration
information into multiple RA messages.
6.4. Recovery from Stale Configuration Information without Explicit
Signaling
6.4.1. dhcpcd(8)
The dhcpcd(8) daemon [dhcpcd], a user-space SLAAC implementation
employed by some Linux-based and BSD-derived operating systems, will
set the Preferred Lifetime of addresses corresponding to a given
prefix to 0 when a single RA from the router that previously
Gont, et al. Expires February 27, 2021 [Page 10]
Internet-Draft Reaction to Renumbering Events August 2020
advertised the prefix fails to advertise the corresponding prefix.
However, it does not affect the corresponding Valid Lifetime.
Therefore, it can be considered a partial implementation of this
feature.
6.5. Other mitigations implemented in products
[FRITZ] is a Customer Edge Router that tries to deprecate stale
prefixes by advertising stale prefixes with a Preferred Lifetime of
0, and a Valid Lifetime of 2 hours (or less). There are two things
to note with respect to this implementation:
o Rather than recording prefixes on stable storage (as recommended
in [I-D.ietf-v6ops-cpe-slaac-renum]), this implementation checks
the source address of IPv6 packets, and assumes that usage of any
address that does not correspond to a prefix currently-advertised
by the Customer Edge Router is the result of stale network
configuration information. Hence, upon receipt of a packet that
employs a source address that does not correspond to a currently-
advertised prefix, this implementation will start advertising the
corresponding prefix with small lifetimes, with the intent of
deprecating it.
o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3
of [RFC4862] (discussed in Section 4.2 of this document), upon
first occurrence of a stale prefix, this implementation will
employ a decreasing Valid Lifetime, starting from 2 hours (7200
seconds), as opposed to a Valid Lifetime of 0.
7. Security Considerations
The protocol update in Section 4.2 could allow an on-link attacker to
perform a Denial of Service attack againts local hosts, by sending a
forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of
that packet, local hosts would invalidate the corresponding prefix,
and therefore remove any addresses configured for that prefix,
possibly terminating e.g. TCP connections employing such addresses.
However, an attacker may achieve similar effects via a number for ND-
based attack vectors, such as directing traffic to a non-existing
node until ongoing TCP connections time out, or performing a ND-based
man-in-the-middle (MITM) attack and subsequently forging TCP RST
segments to cause on-going TCP connections to be aborted. Thus, for
all practical purposes, this attack vector does not really represent
a greater risk than other ND attack vectors. As noted in Section 4.2
, in scenarios where RA-based attacks are of concern, proper
mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND [RFC3971]
should be implemented.
Gont, et al. Expires February 27, 2021 [Page 11]
Internet-Draft Reaction to Renumbering Events August 2020
8. Acknowledgments
The authors would like to thank (in alphabetical order) Mikael
Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Lorenzo
Colitti, Owen DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob
Hinden, Philip Homburg, Lee Howard, Christian Huitema, Tatuya Jinmei,
Erik Kline, Ted Lemon, Jen Linkova, Albert Manfredi, Roy Marples,
Florian Obser, Jordi Palet Martinez, Michael Richardson, Hiroki Sato,
Mark Smith, Hannes Frederic Sowa, Dave Thaler, Tarko Tikan, Ole
Troan, Eduard Vasilenko, and Loganaden Velvindron, for providing
valuable comments on earlier versions of this document.
The algorithm specified in Section 4.5 is the result of mailing-list
discussions over previous versions of this document with Philip
Homburg.
Fernando would like to thank Alejandro D'Egidio and Sander Steffann
for a discussion of these issues, which led to the publication of
[I-D.ietf-v6ops-slaac-renum], and eventually to this document.
Fernando would also like to thank Brian Carpenter who, over the
years, has answered many questions and provided valuable comments
that has benefited his protocol-related work.
The problem discussed in this document has been previously documented
by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update],
and also in [RIPE-690].
9. References
9.1. Normative References
[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>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[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>.
Gont, et al. Expires February 27, 2021 [Page 12]
Internet-Draft Reaction to Renumbering Events August 2020
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
[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>.
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
"Updates to the Special-Purpose IP Address Registries",
BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
<https://www.rfc-editor.org/info/rfc8190>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
9.2. Informative References
[dhcpcd] Marples, R., "dhcpcd - a DHCP client",
<https://roy.marples.name/projects/dhcpcd/>.
[FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network
(updated with solution)", SI6 Networks Blog, February
2016, <https://www.si6networks.com/2016/02/16/quiz-weird-
ipv6-traffic-on-the-local-network-updated-with-solution/>.
[I-D.ietf-v6ops-cpe-slaac-renum]
Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving
the Reaction of Customer Edge Routers to Renumbering
Events", draft-ietf-v6ops-cpe-slaac-renum-04 (work in
progress), August 2020.
[I-D.ietf-v6ops-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Reaction of
Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work
in progress), August 2020.
Gont, et al. Expires February 27, 2021 [Page 13]
Internet-Draft Reaction to Renumbering Events August 2020
[I-D.linkova-6man-default-addr-selection-update]
Linkova, J., "Default Address Selection and Subnet
Renumbering", draft-linkova-6man-default-addr-selection-
update-00 (work in progress), March 2017.
[IPNG-minutes]
IETF, "IPNG working group (ipngwg) Meeting Minutes",
Proceedings of the thirty-eightt Internet Engineering Task
Force , April 1997, <https://www.ietf.org/
proceedings/38/97apr-final/xrtftr47.htm>.
[NetworkManager]
NetworkManager, "NetworkManager web site",
<https://wiki.gnome.org/Projects/NetworkManager>.
[rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)",
<https://cvsweb.openbsd.org/src/usr.sbin/rad/>.
[radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router
Advertisement Daemon (radvd)",
<http://www.litech.org/radvd/>.
[radvd.conf]
Hawkins, R. and R. Johnson, "radvd.conf - configuration
file of the router advertisement daemon",
<https://github.com/reubenhwk/radvd/blob/master/
radvd.conf.5.man>.
[RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August
1996, <https://www.rfc-editor.org/info/rfc1971>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/info/rfc5927>.
Gont, et al. Expires February 27, 2021 [Page 14]
Internet-Draft Reaction to Renumbering Events August 2020
[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>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113,
DOI 10.17487/RFC7113, February 2014,
<https://www.rfc-editor.org/info/rfc7113>.
[RIPE-690]
Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston,
J., Doering, G., Palet, J., Linkova, J., Balbinot, L.,
Meynell, K., and L. Howard, "Best Current Operational
Practice for Operators: IPv6 prefix assignment for end-
users - persistent vs non-persistent, and what size to
choose", RIPE 690, October 2017,
<https://www.ripe.net/publications/docs/ripe-690>.
[slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)",
<https://cvsweb.openbsd.org/src/usr.sbin/slaacd/>.
[systemd] systemd, "systemd web site", <https://systemd.io/>.
Appendix A. Analysis of Some Suggested Workarounds
[This section is to be removed before publication of this document as
an RFC].
During the discussion of this document, some alternative workarounds
were suggested on the 6man mailing-list. The following subsections
analyze these suggested workarounds, in the hopes of avoiding
rehashing the same discussions.
A.1. On a Possible Reaction to ICMPv6 Error Messages
It has been suggested that if configured addresses become stale, a
CPE enforcing ingress/egress filtering (BCP38) ([RFC2827]) could send
ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed
ingress/egress policy) error messages to the sending node, and that,
upon receipt of such error messages, the sending node could perform
heuristics that might help to mitigate the problem discussed in this
document.
Gont, et al. Expires February 27, 2021 [Page 15]
Internet-Draft Reaction to Renumbering Events August 2020
The aforementioned proposal has a number of drawbacks and
limitations:
o It assumes that the CPE routers enforce ingress/egress filtering
[RFC2827]. While this is desirable behaviour, it cannot be relied
upon.
o It assumes that if the CPE enforces ingress/egress filtering, the
CPE will signal the packet drops to the sending node with ICMPv6
Type 1 (Destination Unreachable) Code 5 (Source address failed
ingress/egress policy) error messages. While this may be
desirable, [RFC2827] does not suggest signaling the packet drops
with ICMPv6 error messages, let alone the use of specific error
messages (such as Type 1 Code 5) as suggested.
o ICMPv6 Type 1 Code 5 could be interpreted as the employed address
being stale, but also as a selected route being inappropriate/
suboptimal. If the later, deprecating addresses or invalidating
addresses upon receipt of these error messages would be
inappropriate.
o Reacting to these error messages would create a new attack vector
that could be exploited from remote networks. This is of
particular concern since ICMP-based attacks do not even require
that the Source Address of the attack packets be spoofed
[RFC5927].
A.2. On a Possible Improvement to Source Address Selection
[RFC6724] specifies source address selection (SAS) for IPv6.
Conceptually, it sorts the candidate set of source addresses for a
given destination, based on a number of pair-wise comparison rules
that must be successively applied until there is a "winning" address.
An implementation might improve source address selection, and prefer
the most-recently advertised information. In order to incorporate
the "freshness" of information in source address selection, an
implementation would be updated as follows:
o The node is assumed to maintain a timer/counter that is updated at
least once per second. For example, the time(2) function from
unix-like systems could be employed for this purpose.
o The local information associated with each prefix advertised via
RAs on the local network is augmented with a "LastAdvertised"
timestamp value. Whenever an RA with a PIO with the "A" bit set
for such prefix is received, the "LastAdvertised" timestamp is
updated with the current value of the timer/counter.
Gont, et al. Expires February 27, 2021 [Page 16]
Internet-Draft Reaction to Renumbering Events August 2020
o [RFC6724] is updated such that this rule is incorporated:
Rule 7.5: Prefer fresh information If one of the two source
addresses corresponds to a prefix that has been more recently
advertised, say LastAdvertised(SA) > LastAdvertised(SA), then
prefer that address (SA in our case).
A clear benefit of this approach is that a host will normally prefer
"fresh" addresses over possibly stale addresses.
However, there are a number of drawbacks associated with this
approach:
o In scenarios where multiple prefixes are being advertised on the
same LAN segment, the new SAS rule is *guaranteed* to result in
non-deterministic behaviour, with hosts frequently changing the
default source address. This is certainly not desirable from a
troubleshooting perspective.
o Since the rule must be incorporated before "Rule 8: Use longest
matching prefix" from [RFC6724], it may lead to suboptimal paths.
o This new rule may help to improve the selection of a source
address, but it does not help with the housekeeping (garbage
collection) of configured information:
* If the stale prefix is re-used in another network, nodes
employing stale addresses and routes for this prefix will be
unable to communicate with the new "owner" of the prefix, since
the stale prefix will most likely be considered "on-link".
* Given that the currently recommended default value for the
"Valid Lifetime" of PIOs is 2592000 seconds (30 days), it would
take too long for hosts to remove the configured addresses and
routes for the stale prefix. While the proposed update in
Section 4.1 of this document would mitigate this problem, the
lifetimes advertised by the local SLAAC router are not under
the control of hosts.
As a result, updating IPv6 source address selection does not relieve
nodes from improving their SLAAC implementations as specified in
Section 4, if at all desirable. On the other hand, the algorithm
specified in Section 4.5 would result in Rule 3 of [RFC6724]
employing fresh addresses, without leading to non-deterministic
behaviour.
Gont, et al. Expires February 27, 2021 [Page 17]
Internet-Draft Reaction to Renumbering Events August 2020
Authors' Addresses
Fernando Gont
SI6 Networks
Segurola y Habana 4310, 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires
Argentina
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Jan Zorz
6connect
Email: jan@connect.com
Richard Patterson
Sky UK
Email: richard.patterson@sky.uk
Gont, et al. Expires February 27, 2021 [Page 18]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/