IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Updates: 4861, 4862 (if approved) J. Zorz
Intended status: Standards Track February 18, 2019
Expires: August 22, 2019
Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering
Events
draft-gont-6man-slaac-renum-01
Abstract
In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit signaling of that
condition (such as when a CPE crashes and reboots without knowledge
of the previously-employed prefixes), nodes on the local network will
continue using stale prefixes for an unacceptably long period of
time, thus resulting in connectivity problems. This document
analyzes these problem scenarios, and proposes workarounds to improve
network robustness. This document updates RFC4861 and RFC4862 to
allow for a more robust reaction to network configuration changes.
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 August 22, 2019.
Copyright Notice
Copyright (c) 2019 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
Gont & Zorz Expires August 22, 2019 [Page 1]
Internet-Draft Reaction to Renumbering Events February 2019
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 4
3.1. Inappropriate Default Timer Values in IPv6 Stateless
Address Autoconfiguration (SLAAC) . . . . . . . . . . . . 4
3.2. Inability of SLAAC Hosts to Recover from Stale Network
Configuration Information . . . . . . . . . . . . . . . . 5
3.3. Lack of Explicit Signaling about Stale Information . . . 6
3.4. Under-specified Interaction Between DHCPv6-PD and SLAAC . 6
4. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . . . 7
5. Possible workarounds . . . . . . . . . . . . . . . . . . . . 8
5.1. Improvements to SLAAC . . . . . . . . . . . . . . . . . . 8
5.1.1. Default Timer Values . . . . . . . . . . . . . . . . 8
5.1.2. Signaling Stale Configuration Information . . . . . . 9
5.1.3. Recovery from Stale Configuration Information . . . . 10
5.2. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 13
5.3. Improved CPE behavior . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Flowchart for Host Processing of RAs . . . . . . . . 17
Appendix B. Sample Timeline for Host Processing of RAs . . . . . 18
Appendix C. Analysis of Some Suggested Workarounds . . . . . . . 19
C.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 20
C.2. On a Possible Improvement to Source Address Selection . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit signaling of that
condition, nodes on the local network will continue using stale
prefixes for an unacceptably long period of time, thus resulting in
connectivity problems.
Gont & Zorz Expires August 22, 2019 [Page 2]
Internet-Draft Reaction to Renumbering Events February 2019
There are a number of scenarios where this problem may arise. For
example, the most common deployment scenario for IPv6 in home
networks is that in which a CPE router employs DHCPv6 Prefix
Delegation (DHCPv6-PD) [RFC8415] to request a prefix from the
Internet Service Provider (ISP), and a prefix belonging to the leased
prefix is advertised on the LAN-side of the CPE via Stateless Address
Autoconfiguration (SLAAC) [RFC4862]. In scenarios where the CPE
router crashes and reboots, the CPE may be leased (via DHCPv6-PD) a
different prefix from the one previously leased, and will therefore
advertise (via SLAAC) the new prefix on the LAN side. Hosts will
normally configure an address for the new prefix, but will normally
retain and actively employ the previously-configured addresses, since
their associated Preferred Lifetime and Valid Lifetime allow them to
do so.
Lacking any explicit signaling to "obsolete" the previously-
configured addresses (for the now invalid/stale prefix), hosts may
continue employing the previously-configured addresses which will
typically result in packets being blackholed -- whether because of
egress-filtering by the CPE or ISP, or because responses to such
packets will be discarded or routed elsewhere.
The default values for the "Valid Lifetime" and "Preferred Lifetime"
of Prefix Information Options (PIOs), as specified in [RFC4861], are:
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
This means that in the aforementioned scenarios, the stale addresses
would be retained for unacceptably long period of time, thus leading
to interoperability problems, instead of nodes transitioning to the
newly-advertised prefix(es) in a timelier manner.
Some devices have implemented mechanisms to address this problem,
such as sending RAs to invalidate the apparently stale prefixes when
the device receive any packets employing a source address from a
prefix not being advertised for address configuration [FRITZ].
However, this may introduce other interoperability problems,
particularly in multihomed scenarios. This is yet another indication
that advice in this area is warranted.
This unresponsiveness is caused by the both the inability of the
network to deprecate stale information, as well as by the inability
of hosts to react to network configuration changes in a timelier
manner. Clearly, it is desirable that behave in a way that hosts are
explicitly notified when configuration information has become stale.
However, for robustness reasons it is paramount for hosts to be able
Gont & Zorz Expires August 22, 2019 [Page 3]
Internet-Draft Reaction to Renumbering Events February 2019
to recover from stale configuration information even if somehow the
network is unable to explictly notify hosts about such condition.
Section 3 analysis this problem in more detail. Section 5 proposes
workarounds to improve network robustness.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Analysis of the Problem
As noted in Section 1, the problem discussed in this document is
associated with sub-optimal behaviour and policies of different
entities. Each of the following sections analyze each of them in
detail.
3.1. Inappropriate Default Timer Values in IPv6 Stateless Address
Autoconfiguration (SLAAC)
Many protocols, from different layers, normally employ timers. The
general logic is as follows:
o A timer is set with a value that, under normal conditions, the
timer does *not* go off.
o Whenever a fault condition arises, the timer goes off, and the
protocol can perform fault recovery
One common example for the use of timers is when implementing
reliability mechanisms where a packet is transmitted, and unless a
response is received, a retransmission timer will go off to trigger
retransmission of the original packet.
For obvious reasons, the whole point of using timers is that in
problematic scenarios, they will go off, and trigger some recovery
action.
However, IPv6 SLAAC employs, for PIOs, these default values:
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
Under normal network conditions, these timers will be reset/refreshed
to the default values. However, under problematic circumstances such
Gont & Zorz Expires August 22, 2019 [Page 4]
Internet-Draft Reaction to Renumbering Events February 2019
as where the corresponding network information has become stale
without any explicit signal from the network (as described in
Section 1), it will take a host 7 days (one week) to un-prefer 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 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.
The default values for these timers should be such that, under normal
circumstances (including some packet loss), the timers will be
refreshed/rest, but in the presence of network faults (such as
network configuration information becoming stale without explicit
signaling), the timers go off and trigger some fault recovering
action (such as un-preferring the corresponding addresses and
subsequently removing them).
In the context of [RFC8028], where it is clear that use of addresses
configured for a given prefix is mostly tied to using the router that
advertised the prefix as a next hop, one could tell that neither the
"Preferred Lifetime" or the "Valid Lifetime" of a PIO should ever be
longer than the default value for the "Router Lifetime" of Router
Advertisement packets. This means that since [RFC4861] specifies the
default value for the "Router Lifetime" as: AdvDefaultLifetime: 3 *
MaxRtrAdvInterval, and MaxRtrAdvInterval defaults to 600 seconds, the
values employed for the "Preferred Lifetime" (AdvPreferredLifetime)
and "Valid Lifetime" (AdvValidLifetime) of PIOs should never be
larger than 1800 seconds (30 minutes). Capping the lifetimes in PIOs
as suggested would not eliminate the problem discussed in this
document, but certainly reduces the amount of time it takes for hosts
to converge to updated network configuration information.
Section 5.1.1 of this document updates the SLAAC specification to
employ more appropriate timer values.
3.2. Inability of SLAAC Hosts to Recover from Stale Network
Configuration Information
In the absence of explicit signalling from SLAAC routers (such as
sending PIOs with a "Valid Lifetime" set to 0), SLAAC hosts fail to
recover from stale configuration information in a timely manner.
This is exacerbated by the inappropriate timers employed for the
lifetime of PIOs, as discussed in Section 3.1.
It is possible to heuristically infer that network configuration
information has changed. For example, if the same SLAAC router (as
Gont & Zorz Expires August 22, 2019 [Page 5]
Internet-Draft Reaction to Renumbering Events February 2019
identified by its link-local address) is advertising new prefixes via
PIOs, but has ceased to advertise the previously-advertised prefixes,
this should be considered an indication that network configuration
information has changed. Implementing this kind of heuristics would
allow a timelier reaction to network configuration changes even in
scenarios where there is no explicit signaling from the network, thus
improving robustness.
Section 5.1.3 of this document specifies a local policy that SLAAC
hosts can implement to recover from stale prefixes.
3.3. Lack of Explicit Signaling about Stale Information
Whenever prefix information has changed, a SLAAC router should not
only advertise the new information, but should also advertise the
stale information with appropriate lifetime values (both "Preferred
Lifetime" and "Valid Lifetime" set to 0), such that there is explicit
signaling to SLAAC hosts to remove the stale information (including
configured addresses and routes).
In order to cope with the possibility of a SLAAC router crashing and
rebooting without any state of the previously-advertised prefixes, a
SLAAC router should record on stable storage the information of which
prefixes were being advertised on which interfaces, such that upon
reboots, such prefixes may be advertised with appropriate lifetimes
(both "Preferred Lifetime" and "Valid Lifetime" set to 0) to cause
hosts to remove any configuration information derived from previous
announcements of such prefixes.
Explicit signaling of network configuration changes would eliminate
the problem discussed in this document. However, since it is
impossible for a host to know whether such explicit signals will be
received, they are not relieved from inferring changes in network
configuration information, as discussed in Section 3.2.
Section 5.1.2 updates the SLAAC specification such that routers
explicitly signal stale configuration to SLAAC hosts. Section 5.3
specifies the corresponding requirements for CPE routers.
3.4. Under-specified Interaction Between DHCPv6-PD and SLAAC
While DHCPv6-PD is normally employed along with SLAAC, the
interaction between the two protocols is largely unspecified. Not
unusually, the two protocols are specified in two different software
components with the interface between the two implemented by some
sort of script that takes feeds the SLAAC implementation with values
learned from DHCPv6-PD.
Gont & Zorz Expires August 22, 2019 [Page 6]
Internet-Draft Reaction to Renumbering Events February 2019
Quite frequently, the prefix lease time is fed as a constant value to
the SLAAC router implementation, meaning that eventually the prefix
lifetime advertised on the LAN side will span *past* the DHCPv6-PD
lease time. This is clearly incorrect, since the SLAAC router
implementation would be allowing the use of such prefixes for a
longer time than it has been granted usage of those prefixes via
DHCPv6-PD. The lifetime values employed for the "Preferred Lifetime"
(AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) should
never be larger than the remaining lease time for the corresponding
prefix (as learned via DHCPv6-PD).
Section 5.2 of this document specifies this aspect of the interaction
between DHCPv6-PD and SLAAC.
4. Use of Dynamic Prefixes
The problem discussed in this document would be avoided if DHCPv6-PD
would lease "stable" prefixes. However, a recent survey [UK-NOF]
indicates that 37% of the responding ISPs employ dynamic prefixes.
That is, dynamic IPv6 prefixes are an operational reality.
Deployment reality aside, there are a number of possible issues
associated with stable prefixes:
o Provisioning systems may be unable to deliver stable IPv6
prefixes.
o While there is a range of information that may be employed to
correlate network activity [RFC7721], the use of stable prefixes
clearly simplifies network activity correlation, and may
essentially render features such as "temporary addresses"
[RFC4941] irrelevant.
o Applicable legislation may require the ISP to deliver dynamic IPv6
prefixes *by default* (see e.g. [GERMAN-DP]).
The authors of this document understand that, for a number of reasons
(such as the ones stated above), IPv6 deployments may employ dynamic
prefixes, or there might be scenarios in which the dynamics of a
network are such that the network exhibits the behaviour of dynamic
prefixes. Rather than try to preclude how operators may run their
networks, this document aims at improving network robustness in the
deployed Internet.
Gont & Zorz Expires August 22, 2019 [Page 7]
Internet-Draft Reaction to Renumbering Events February 2019
5. Possible workarounds
The following subsections discuss possible workarounds for the
aforementioned problem. Section 5.1 specifies modifications to SLAAC
which include the use of more appropriate lifetime values and a
mechanism for hosts to infer when a previously-advertised prefix has
become stale. This modification leads to more robust behaviour even
for existing deployments.
Section 5.3 specifies the interaction between DHCPv6-PD and SLAAC,
such that devices such as CPEs may be in a better position to convey
current network information to hosts on the LAN-side. For obvious
reasons (legacy CPEs, etc.), this improved behaviour cannot be relied
upon for mitigating the problem described in Section 1. However, it
does contribute to more robust IPv6 networks.
Finally, Section 4 analyzes the trade-offs of employing stable vs.
dynamic network prefixes.
5.1. Improvements to SLAAC
5.1.1. Default Timer Values
5.1.1.1. Router Configuration Variables
The "default" value for the router configuration variable
"MaxRtrAdvInterval" (Section 6.2.1 of [RFC4861] is changed to 300
seconds (5 minutes).
As a result of this change, the default values for two other
configuration variables are indirectly modified (since they are
specified in relation with MaxRtrAdvInterval):
o MinRtrAdvInterval: 0.33 * MaxRtrAdvInterval = 99 seconds
o AdvDefaultLifetime: 3 * MaxRtrAdvInterval = 900 seconds (15
minutes)
Additionally, the default value for the "lifetime" parameters in PIOs
is updated as follows:
AdvValidLifetime: AdvDefaultLifetime (which according to this
specification defaults to 900 seconds / 15 minutes)
AdvPreferredLifetime: 0.50 * AdvValidLifetime (which would result
in 450 seconds, that is, 7.5 minutes)
The motivation of this update is as follows:
Gont & Zorz Expires August 22, 2019 [Page 8]
Internet-Draft Reaction to Renumbering Events February 2019
o Link the lifetimes associated with prefixes to the lifetime of the
router advertising the prefixes, since use of advertised prefixes
is closely tied to the router that has advertised them (as per
[RFC8028]).
o Lacking RAs that refresh information, addresses configured for
such prefixes would become un-preferred, and thus Rule 3 of
[RFC6724] would cause other configured addresses (if available) to
be preferred and used instead.
o Limit the amount of time that a stale prefix needs to be
advertised with a lifetime od "0" on the local network (see
Section 12 of [RFC4861]).
o Employ default router lifetimes that improve the ability of hosts
to recover from fault scenarios.
5.1.1.2. Processing of PIO Lifetimes at Hosts
Hosts should cap the "Valid Lifetime" and "Preferred Lifetime" of
PIOs to the "Router Lifetime" value in the received Router
Advertisement. That is, if the "Valid Lifetime" or "Preferred
Lifetime" of a PIO is larger than the "Router Lifetime" value of the
Router Advertisement carrying the PIO, the corresponding value should
be capped to that of the "Router Lifetime" value of the received RA.
The motivation for this update is as follows:
o Limits the amount of time a host is required to maintain possibly
stale information.
5.1.2. Signaling Stale Configuration Information
In order to phase-out stale configuration information, the SLAAC
specification is updated as follows:
o A router sending RAs that advertise dynamically-learned prefixes
(e.g. via DHCPv6-PD) on an interface MUST record, on stable
storage, the list of prefixes being advertised on each network
segment.
o Upon changes to the advertised prefixes, and after bootstrapping,
the router advertising prefix information via SLAAC should proceed
as follows:
* Any prefixes that were previously advertised via SLAAC, but
that are not currently intended for address configuration, MUST
Gont & Zorz Expires August 22, 2019 [Page 9]
Internet-Draft Reaction to Renumbering Events February 2019
be advertised with a PIO option with the "A" bit set to 1 and
the "Valid Lifetime" and a "Preferred Lifetime" set to 0.
* Any prefixes that were previously advertised via SLAAC as "on-
link", but that are not currently not considered "on-link",
MUST be advertised with a PIO option with the "L" bit set to 1
and the "Valid Lifetime" and a "Preferred Lifetime" set to 0.
* If both of the previous conditions are met (a prefix was
previously advertised with both the "A" and "L" bits set, but
is currently *not* intended for address configuration and is
*not* considered on-link), the prefix MUST be advertised with a
PIO option with both the "A" and "L" bits set to 1 and the
"Valid Lifetime" and a "Preferred Lifetime" set to 0. That is.
the advertisements of the previous two steps can be coalesced
into a single one with both the "A" and "L" bits set.
* The aforementioned advertisement SHOULD be performed for at
least the "Valid Lifetime" previously employed for such prefix.
Additionally, 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.
to:
In such cases, the router MUST transmit
MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using
the same rules as when an interface becomes an advertising
interface.
The rationale for this update is:
o Use of stale information can lead to interoperability problems.
Therefore, it is paramount that new configuration information is
delivered in a timely manner to all hosts.
5.1.3. Recovery from Stale Configuration Information
The goal of the mechanism specified in this section is to allow hosts
to infer when a previously-advertised prefix has become stale, such
that previously-configured addresses are "phased-out" and the host
can transition to the newly-advertised prefixes in a timelier manner.
Gont & Zorz Expires August 22, 2019 [Page 10]
Internet-Draft Reaction to Renumbering Events February 2019
The basic premise behind the mechanism specified in this section is
that, when a router advertises new prefixes for address configuration
(PIO with the "A" bit set), but fails to advertise the previously-
advertised prefixes, this is an indication that the previously-
advertised prefixes have become stale. Therefore, configured
addresses for the stale prefixes are initially "un-preferred" (such
that they are not employed for new communication instances), and they
are subsequently removed (if this condition persists).
Local information maintained for each prefix advertised by each
router is augmented with one boolean flag named "LTA" (Lifetime
Avoidance) that defaults to "FALSE". Note: hosts are already
expected to keep track of which router has advertised which prefix in
order to be able to properly select the first-hop router in multiple-
prefix networks [RFC8028] [RFC8504].
After normal processing of Router Advertisement messages, Router
Advertisements that contain at least one PIO MUST be processed as
follows:
o The LTA flag for each prefix advertised in the current Router
Advertisement should be set to "FALSE".
o For each prefix that had been previously advertised by this router
but that does not have a corresponding PIO with the "A" flag set
in the received RA, proceed as follows:
* IF the LTA flag is "TRUE", then:
+ IF there is any address configured for this prefix with a
"Preferred Lifetime" larger than 0, set its "Preferred
Lifetime" to 0, and the LTA flag of this prefix to "FALSE".
+ ELSE (all addresses for this prefix have a "Preferred
Lifetime" of 0), set the "Valid Lifetime" of all addresses
configured for this prefix to 0, and the LTA flag of this
prefix to "FALSE". This will cause removal of all addresses
for this prefix. Additionally, if the corresponding prefix
had been advertised as on-link ("L"=1) by this router,
remove any routes to this prefix associated with the network
interface card on which the RA packet was received.
* ELSE (the LTA flag is "FALSE"):
+ Set the LTA flag of the corresponding prefix to "TRUE".
Gont & Zorz Expires August 22, 2019 [Page 11]
Internet-Draft Reaction to Renumbering Events February 2019
Appendix B illustrates the packet exchange and operation of the
algorithm for a typical scenario. Appendix A provides a flowchart
for this algorithm.
NOTES:
o The aforementioned processing assumes that while network
configuration information might be split into multiple RAs, PIOs
will be spread among *at most* two RAs. This assumption avoids
the use of any timers for this specific purpose.
o If the only prefix that has so far been advertised on the local
network is the prefix that has become stale, and there is no new
prefix being advertised, the traditional processing is unaffected
(the mechanism discussed in this document will *never* be
triggered because no packets with PIOs with the "A" flag will be
received). The logic here is that it is better to have some
address, than no address at all.
o The processing of RAs that do not contain any PIOs with the "A"
bit set remains unaffected.
o The specified modification takes the conservative approach of
first setting the "Preferred Lifetime" to 0 (such that addresses
become non-preferred), and subsequently setting the "Valid
Lifetime" to 0 (such as the addresses are completely removed).
Once the addresses for this prefix have been removed, routes to
this prefix associated with the network interface on which the RA
packets were received are also removed.
o In cases where this scenario has been triggered by a CPE router
crashing and rebooting, it would take hosts less than one minute
to mark the corresponding addresses as "not preferred", and less
than five minutes to completely remove such addresses from the
system. Section 6.2.4 of [RFC4861] specifies that when an
interface becomes an advertising interface, the first few
unsolicited RAs (up to MAX_INITIAL_RTR_ADVERTISEMENTS, specified
as 3) will be sent at intervals of at most
MAX_INITIAL_RTR_ADVERT_INTERVAL (specified as 16 seconds). This
means that, in the worst-case scenario, it would take hosts 32
seconds to mark stale addresses as "not preferred". The fourth
unsolicited RA will be sent after a random amount of time between
MinRtrAdvInterval (default: 0.33 * MaxRtrAdvInterval) and
MaxRtrAdvInterval (default: 600 seconds) has elapsed, thus meaning
that the stale addresses would be removed between 3.3 and 10
minutes of being marked as "not preferred".
Gont & Zorz Expires August 22, 2019 [Page 12]
Internet-Draft Reaction to Renumbering Events February 2019
5.2. Interaction Between DHCPv6-PD and SLAAC
The "Preferred Lifetime" and "Valid Lifetime" of PIOs corresponding
to prefixes learned via DHCPv6-PD MUST NOT span past the lease time
of the DHCPv6-PD prefixes. This means that the advertised "Preferred
Lifetime" and "Valid Lifetime" MUST be dynamically adjusted such that
the advertised lifetimes never span past the lease time of the
prefixes delegated via DHCPv6-PD.
This is in line with these existing requirements from other
specifications, which we reference here for clarity:
o [RFC8415] specifies, in Section 6.3, that "if the delegated prefix
or a prefix derived from it is advertised for stateless address
autoconfiguration [RFC4862], the advertised preferred and valid
lifetimes MUST NOT exceed the corresponding remaining lifetimes of
the delegated prefix."
5.3. Improved CPE behavior
This section specifies and clarifies requirements for CPE routers
(particularly when they advertise prefixes learned via DHCPv6-PD)
that can help mitigate the problem discussed in Section 1. This
improves the situation for hosts that do not implement the
modification specified in Section 5.1 but would obviously make
robustness dependent on the CPE (on which the user or ISP may have no
control), as opposed to the host itself. This mechanism is mostly
orthogonal to the improved host behaviour specified in Section 5.1.
The updated behaviour is as follows:
o The CPE MUST signal stale configuration information as specified
in Section 5.1.2
o The CPE MUST implement the DHCPv6-PD/SLAAC interface specified in
Section 5.2.
The aforementioned improved behaviour assumes compliance with the
following existing requirements from other specifications, which we
reference here for clarity:
o [RFC7084] specifies (requirement LE-13, in Section 4.3) that when
the delegated prefix changes (i.e., the current prefix is replaced
with a new prefix without any overlapping time period), "the IPv6
CE router MUST immediately advertise the old prefix with a
Preferred Lifetime of zero and a Valid Lifetime of either a) zero
or b) the lower of the current Valid Lifetime and two hours (which
Gont & Zorz Expires August 22, 2019 [Page 13]
Internet-Draft Reaction to Renumbering Events February 2019
must be decremented in real time) in a Router Advertisement
message as described in Section 5.5.3, (e) of [RFC4862]"
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
This document discusses a a problem that may arise in scenarios where
dynamic IPv6 prefixes are employed, and proposes workarounds that
enable such usage while avoiding interoperability problems. The
security and privacy implications of IPv6 addresses are discussed in
[RFC7721].
An attacker that could impersonate a router could forge multiple RA
packets that contain PIOs of prefixes that are currently not
advertised on the local network, to trigger the mechanism specified
in this document to cause addresses currently configured for the
legitimate prefixes to be removed. However, an attacker that can
impersonate a router could more easily achieve the same goal by
advertising the legitimate prefixes with both the "Preferred
Lifetime" and "Valid Lifetime" set to 0.
Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts limit
the length of the effects of a non-sustained attack, since hosts
would now be able to recover in a timelier manner.
Attacks based on forged RA packed can be mitigated with technologies
such as RA-Guard [RFC6105] [RFC7113].
8. Acknowledgments
The authors would lie to thank (in alphabetical order) Mikael
Abrahamsson, Luis Balbinot, Brian Carpenter, Gert Doering, Nick
Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Albert
Manfredi, Jordi Palet Martinez, Richard Patterson, Michael
Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for providing
valuable comments on earlier versions of this document.
Fernando would like to thank Alejandro D'Egidio and Sander Steffann
for a discussion of these issues.
The problem discussed in this document has been previously documented
in [RIPE-690].
Gont & Zorz Expires August 22, 2019 [Page 14]
Internet-Draft Reaction to Renumbering Events February 2019
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>.
[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>.
[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>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[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>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[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
[FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network
(updated with solution)", SI6 Networks Blog, February
2016, <http://blog.si6networks.com/2016/02/
quiz-weird-ipv6-traffic-on-local-network.html>.
Gont & Zorz Expires August 22, 2019 [Page 15]
Internet-Draft Reaction to Renumbering Events February 2019
[GERMAN-DP]
BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im
Privatkundengeschaft und Herstellere", Entschliessung der
84. Konferenz der Datenschutzbeauftragten des Bundes und
der Lander am 7./8. November 2012 in Frankfurt (Oder),
November 2012,
<http://www.bfdi.bund.de/SharedDocs/Publikationen/
Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv
6.pdf?__blob=publicationFile>.
[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>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/info/rfc5927>.
[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>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[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>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
Gont & Zorz Expires August 22, 2019 [Page 16]
Internet-Draft Reaction to Renumbering Events February 2019
[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>.
[UK-NOF] Palet, J., "IPv6 Deployment Survey (Residential/Household
Services) How IPv6 is being deployed?", UK NOF 39, January
2018,
<https://indico.uknof.org.uk/event/41/contributions/542/
attachments/712/866/bcop-ipv6-prefix-v9.pdf>.
Appendix A. Flowchart for Host Processing of RAs
Conceptually, the mechanism operates as follows:
Gont & Zorz Expires August 22, 2019 [Page 17]
Internet-Draft Reaction to Renumbering Events February 2019
+----------------+
| Normal proc. |
| of RA packet |
+---------+------+
|
v
+----------------+
| RA has PIO | No
| with A==1? |------> DONE
+----------------+
|
| Yes
v
+----------------+
| (For each PIO) |
| LTA=TRUE |
+----------------+
|
v
+----------------+ +-----------------+
| (For each Pref | | |
| assoc. with | Yes | |
| this router) |----->| LTA=FALSE |
| Is there corr. | | |
| PIO in the RA? | | |
+----------------+ +-----------------+
|
| No
v
+----------------+ +-----------------+ +----------------+
| | | (For each addr. | | Valid Lftime=0 |
| | Yes | for this Pref.) | Yes | LTA=FALSE |
| LTA==TRUE? |----->| |----->| (REM. ADDR!) |
| | | Pref Lftime==0? | | !
+----------------+ +-----------------+ +----------------+
| |
| No | No
v v
+----------------+ +-----------------+
| | | Pref. Lftime=0 |
| LTA=TRUE | | LTA=FALSE |
+----------------+ +-----------------+
Appendix B. Sample Timeline for Host Processing of RAs
The following example illustrates a sample packet exchange that
illustrates the algorithm specified in Section 5.1:
Gont & Zorz Expires August 22, 2019 [Page 18]
Internet-Draft Reaction to Renumbering Events February 2019
Router Host
RA, PIO={2001:DB8:1::/64, L=1, A=1}
-------------------------------------->
[Host configures addrs
for this prefix]
RA, PIO={2001:DB8:1::/64, L=1, A=1}
-------------------------------------->
[Normal proc. of RA]
.
.
[Router reboots]
RA, PIO={2001:DB8:2::/64, L=1, A=1}
--------------------------------------> {2001:DB8:1::/64,
LTA=TRUE}
.
.
RA, PIO={2001:DB8:2::/64, L=1, A=1}
--------------------------------------> {2001:DB8:1::/64,
LTA=FALSE}
Pref. Lftime=0
.
.
RA, PIO={2001:DB8:2::/64, L=1, A=1}
--------------------------------------> {2001:DB8:1::/64,
LTA=TRUE}
.
.
RA, PIO={2001:DB8:2::/64, L=1, A=1}
--------------------------------------> {2001:DB8:1::/64,
LTA=FALSE}
Valid Lftime=0
(Addr. Removed!)
Appendix C. 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 (e.g. on the 6man list). The following subsections
analyze these suggested workarounds, in the hopes of avoiding
rehashing discussions of such workarounds.
Gont & Zorz Expires August 22, 2019 [Page 19]
Internet-Draft Reaction to Renumbering Events February 2019
C.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]) might 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 might perform
heuristics that might help to mitigate the problem discussed in this
document.
The aforementioned proposal has a number of drawbacks and
limitations:
o It assumes that the CPE enforces 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
to be stale, but also as a selected route being inappropriate/
suboptimal. If the later, un-preferring addresses or removing
addresses upon receipt of these error messages would be
inappropriate.
o Reacting to these error messages would create a new attack vector.
This is of particular concern since ICMP-based attack do not even
require that the Source Address of the attack packets be spoofed
[RFC5927].
C.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.
It has been suggested that 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:
Gont & Zorz Expires August 22, 2019 [Page 20]
Internet-Draft Reaction to Renumbering Events February 2019
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.
o [RFC6724] is updated such that this rule is incorporated:
Rule 3.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).
There are a number of limitations and drawbacks associated with this
approach:
o It may help to improve the selection of a source address, but it
does not help with the housekeeping of configured information:
* If the stale prefix is re-used in another network, nodes
employing stale addresses and routes for this prefixes will be
unable to communicate with the new "owners" of the prefix.
* Given that 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.
o The earlier the above rule is incorporated into the [RFC6724]
rules, the more it could lead to suboptimal address selection.
For example, if incorporated as Rule 3.5 (before Rule #4, but
after Rule 3), an implementation may end up choosing a source
address from a "fresher" prefix rather than one with a longest-
matching prefix, thus leading to suboptimal routing. On the other
hand, the later the rule is incorporated into the [RFC6724] rules,
the more irrelevant the rule becomes (since existing rules might
prefer the stale addresses).
o In scenarios where multiple prefixes are being advertised (whether
by a single router via multiple RAs, multiple routers on the same
LAN segment, or different routers on different LAN segments (when
a host has multiple interfaces)), the new SAS rule is guaranteed
to result in non-deterministic behaviour, with hosts frequently
Gont & Zorz Expires August 22, 2019 [Page 21]
Internet-Draft Reaction to Renumbering Events February 2019
changing the selected address. This is certainly not desirable
from a troubleshooting perspective.
As a result, updating IPv6 source address selection does not relieve
nodes from improving their SLAAC implementations as specified in
Section 5.1, if at all desirable. On the other hand, employing
appropriate timers as specified in Section 5.1.1 would result in Rule
3 of [RFC6724] employing fresh addresses, without leading to
undeterministic behaviour.
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Segurola y Habana 4310, 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Jan Zorz
Email: jan@go6.si
Gont & Zorz Expires August 22, 2019 [Page 22]