rfc9096.original   rfc9096.txt 
IPv6 Operations Working Group (v6ops) F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft SI6 Networks Request for Comments: 9096 SI6 Networks
Updates: 7084 (if approved) J. Zorz BCP: 234 J. Zorz
Intended status: Best Current Practice 6connect Updates: 7084 6connect
Expires: November 28, 2021 R. Patterson Category: Best Current Practice R. Patterson
Sky UK ISSN: 2070-1721 Sky UK
B. Volz B. Volz
Cisco Individual Contributor
May 27, 2021 August 2021
Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Improving the Reaction of Customer Edge Routers to IPv6 Renumbering
Events Events
draft-ietf-v6ops-cpe-slaac-renum-08
Abstract Abstract
This document specifies improvements to Customer Edge Routers that This document specifies improvements to Customer Edge routers that
help mitigate the problems that may arise when network configuration help mitigate the problems that may arise when network configuration
information becomes invalid, without any explicit signaling of that information becomes invalid without any explicit signaling of that
condition to the local nodes. This document updates RFC7084. condition to the local nodes. This document updates RFC 7084.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 28, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9096.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language
3. Improved Customer Edge Router Behavior . . . . . . . . . . . 3 3. Improved Customer Edge Router Behavior
3.1. Automatic DHCPv6 RELEASEs . . . . . . . . . . . . . . . . 4 3.1. Automatic DHCPv6 RELEASEs
3.2. Stability of IAIDs . . . . . . . . . . . . . . . . . . . 4 3.2. Stability of IAIDs
3.3. Interface Between WAN-side and LAN-side . . . . . . . . . 4 3.3. Interface between the WAN Side and LAN Side
3.4. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5 3.4. LAN-Side Option Lifetimes
3.5. Signaling Stale Configuration Information . . . . . . . . 7 3.5. Signaling Stale Configuration Information
4. Recommended Option Lifetimes Configuration Values . . . . . . 9 4. Recommended Option Lifetimes Configuration Values
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
In scenarios where network configuration information becomes invalid In scenarios where network configuration information becomes invalid
without any explicit signaling of that condition (such as when a without any explicit signaling of that condition (such as when a
Customer Edge Router crashes and reboots without knowledge of the Customer Edge (CE) router crashes and reboots without knowledge of
previously-employed configuration information), hosts on the local the previously employed configuration information), hosts on the
network will continue using stale information for an unacceptably local network will continue using stale information for an
long period of time, thus resulting in connectivity problems. This unacceptably long period of time, thus resulting in connectivity
problem is documented in detail in [RFC8978]. problems. This problem is documented in detail in [RFC8978].
This document specifies improvements to Customer Edge (CE) Routers This document specifies improvements to CE routers that help mitigate
that help mitigate the aforementioned problem for residential and the aforementioned problem for residential and small office
small office scenarios. It specifies recommendations for the default scenarios. It specifies recommendations for the default behavior of
behavior of CE Routers, and does not preclude the availability of CE routers but does not preclude the availability of configuration
configuration knobs that might allow an operator or user to manually- knobs that might allow an operator or user to manually configure the
configure the CE Router to deviate from these recommendations. This CE router to deviate from these recommendations. This document
document updates RFC7084. updates RFC 7084.
2. Requirements Language 2. Requirements Language
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Improved Customer Edge Router Behavior 3. Improved Customer Edge Router Behavior
This section specifies and clarifies requirements for Customer Edge This section specifies and clarifies requirements for CE routers that
Routers that can help mitigate the problem discussed in Section 1, can help mitigate the problem discussed in Section 1, particularly
particularly when they employ prefixes learned via DHCPv6-Prefix when they employ prefixes learned via DHCPv6 Prefix Delegation
Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless (DHCPv6-PD) [RFC8415] on the WAN side with Stateless Address
Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on the LAN
the LAN-side. The recommendations in this document help improve side. The recommendations in this document help improve robustness
robustness at the Customer Edge Router (on which the user or ISP may at the CE router (on which the user or ISP may have no control) and
have no control), and do not preclude implementation of host-side do not preclude implementation of host-side improvements such as
improvements such as those specified in [I-D.ietf-6man-slaac-renum]. those specified in [6MAN-SLAAC-RENUM].
This document specifies additional prefix-delegation requirements to This document specifies additional WAN-side prefix-delegation (WPD)
those specified in [RFC7084]: requirements to those specified in [RFC7084]:
o WPD-9: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE WPD-9: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
messages upon reboot events. See Section 3.1 for further details. messages upon restart events. See Section 3.1 for further
details.
o WPD-10: CE Routers MUST by default use a WAN-side IAID value that WPD-10: CE routers MUST by default use a WAN-side Identity
is stable between CE Router restarts, DHCPv6 client restarts, or Association IDentifier (IAID) value that is stable between CE
interface state changes (e.g., Transient PPP interfaces), unless router restarts, DHCPv6 client restarts, or interface state
the CE Router employs the IAID techniques discussed in Section 4.5 changes (e.g., transient PPP interfaces), unless the CE router
of [RFC7844]. See Section 3.2 for further details. employs the IAID techniques discussed in Section 4.5 of [RFC7844].
See Section 3.2 for further details.
This document also replaces LAN-side requirement L-13 from [RFC7084] This document also replaces LAN-side requirement L-13 from [RFC7084]
with: with:
o L-13: CE routers MUST signal stale configuration information as L-13: CE routers MUST signal stale configuration information as
specified in Section 3.5. specified in Section 3.5.
Finally, this document specifies the following additional LAN-side Finally, this document specifies the following additional LAN-side
requirements to those from [RFC7084]: requirements to those from [RFC7084]:
o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign
addresses or delegate prefixes via DHCPv6 on the LAN-side, addresses or delegate prefixes via DHCPv6 on the LAN side using
employing lifetimes that exceed the remaining lifetimes of the lifetimes that exceed the remaining lifetimes of the corresponding
corresponding prefixes learned from the WAN-side via DHCPv6-PD. prefixes learned on the WAN side via DHCPv6-PD. For more details,
For more details, see Section 3.3. see Section 3.3.
o L-16: CE routers SHOULD advertise capped SLAAC option lifetimes L-16: CE routers SHOULD advertise capped SLAAC option lifetimes,
and capped DHCPv6 IA Address Option and IA Prefix Option capped DHCPv6 IA Address option lifetimes, and capped IA Prefix
lifetimes, as specified in Section 3.4. option lifetimes, as specified in Section 3.4.
3.1. Automatic DHCPv6 RELEASEs 3.1. Automatic DHCPv6 RELEASEs
Some CE Routers are known to automatically send DHCPv6-PD RELEASE Some CE routers are known to automatically send DHCPv6-PD RELEASE
messages upon reboot events. However, this may inadvertently trigger messages upon restart events. However, this may inadvertently
a flash-renumbering scenario, along with the associated problems trigger a flash-renumbering scenario, along with the associated
discussed in [RFC8978], that this document attempts to mitigate. problems discussed in [RFC8978], that this document attempts to
mitigate.
As a result, requirement WPD-9 from Section 3 specifies that CE As a result, requirement WPD-9 from Section 3 specifies that CE
routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon
reboot events. restart events.
3.2. Stability of IAIDs 3.2. Stability of IAIDs
[RFC8415] requires that the IAID for an IA MUST be consistent across [RFC8415] requires that the IAID for an IA MUST be consistent across
restarts of the DHCP client. However, some popular CE Routers are restarts of the DHCP client. However, some popular CE routers are
known to select new random IAIDs e.g. everytime the underlying PPP known to select new random IAIDs, e.g., every time the underlying PPP
session is established. This could be the result of extrapolating session is established or when the device is rebooted. This could be
the behavior described in [RFC7844], or simply a consequence of not the result of extrapolating the behavior described in [RFC7844] or
storing IAIDs on stable storage along with failing to employ an simply a consequence of not storing IAIDs on stable storage along
algorithm that consistently generates the same IAID upon reboots. with failure to employ an algorithm that consistently generates the
Thus, requirement WPD-10 from Section 3 prevents CE Routers from same IAID upon reboots. Thus, requirement WPD-10 from Section 3
inadvertently triggering flash-renumbering events on the local prevents CE routers from inadvertently triggering flash-renumbering
network. events on the local network.
3.3. Interface Between WAN-side and LAN-side 3.3. Interface between the WAN Side and LAN Side
The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information
Options (PIOs) [RFC4861] corresponding to prefixes learned via Options (PIOs) [RFC4861] corresponding to prefixes learned via
DHCPv6-PD MUST NOT span past the remaining preferred and valid DHCPv6-PD on the WAN side MUST NOT span past the remaining preferred
lifetimes of the corresponding DHCPv6-PD prefixes. This means that and valid lifetimes of the corresponding DHCPv6-PD prefixes. This
the "Preferred Lifetime" and the "Valid Lifetime" advertised in PIOs means that the "Preferred Lifetime" and the "Valid Lifetime"
by the CE router MUST be dynamically adjusted such that they never advertised in PIOs by the CE router MUST be dynamically adjusted such
span past the remaining preferred and valid lifetimes of the that they never span past the remaining preferred and valid lifetimes
corresponding prefixes delegated via DHCPv6-PD on the WAN-side. of the corresponding prefixes delegated via DHCPv6-PD on the WAN
side.
Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA
Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on Address options and DHCPv6 IA Prefix options employed with DHCPv6 on
the LAN-side MUST NOT span past the remaining preferred and valid the LAN side MUST NOT span past the remaining preferred and valid
lifetimes of the corresponding prefixes leased via DHCPv6-PD on the lifetimes of the corresponding prefixes learned via DHCPv6-PD on the
WAN-side. This means that the "preferred-lifetime" and "valid- WAN side. This means that the "preferred-lifetime" and "valid-
lifetime" of DHCPv6 IA Address Options and DHCPv6 IA Prefix Options lifetime" of DHCPv6 IA Address options and DHCPv6 IA Prefix options
employed with DHCPv6 on the LAN-side MUST be dynamically adjusted employed with DHCPv6 on the LAN side MUST be dynamically adjusted
such that they never span past the remaining preferred and valid such that they never span past the remaining preferred and valid
lifetimes of the corresponding prefixes delegated to the CE router on lifetimes of the corresponding prefixes delegated to the CE router on
the WAN-side via DHCPv6-PD. the WAN side via DHCPv6-PD.
RATIONALE: RATIONALE:
* The lifetime values employed for the "Preferred Lifetime" * The lifetime values employed for the "Preferred Lifetime"
(AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) of
of SLAAC Prefix Information Options must never be larger than SLAAC Prefix Information Options must never be larger than the
the remaining lifetimes for the corresponding prefix (as remaining lifetimes of the corresponding prefixes (as learned via
learned via DHCPv6-PD on the WAN-side). This is in line with DHCPv6-PD on the WAN side). This is in line with the requirement
the requirement from Section 6.3 of [RFC8415], which states from Section 6.3 of [RFC8415], which states:
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."
* The lifetime values of prefixes advertised on the LAN-side via | In particular, if the delegated prefix or a prefix derived from it
SLAAC must be dynamically updated (rather than static values), | is advertised for stateless address autoconfiguration [RFC4862],
otherwise the advertised lifetimes would eventually span past | the advertised preferred and valid lifetimes MUST NOT exceed the
the DHCPv6-PD lifetimes. | corresponding remaining lifetimes of the delegated prefix.
* The same considerations apply for the valid-lifetime and * The lifetime values of prefixes advertised on the LAN side via
preferred-lifetime of IA Address Options and IA Prefix Options SLAAC must be dynamically updated (rather than static values);
employed with DHCPv6 on the LAN-side. otherwise, the advertised lifetimes would eventually span past the
DHCPv6-PD lifetimes.
3.4. LAN-side Option Lifetimes * The same considerations apply for the "valid-lifetime" and
"preferred-lifetime" of IA Address options and IA Prefix options
employed with DHCPv6 on the LAN side.
CE Routers SHOULD override the default lifetime values of Neighbor 3.4. LAN-Side Option Lifetimes
CE routers SHOULD override the default lifetime values of Neighbor
Discovery options that depend in any way on changes in the prefix Discovery options that depend in any way on changes in the prefix
employed for address configuration on the LAN-side, and employ employed for address configuration on the LAN side, and employ
shorter lifetime values to improve the robustness to renumbering shorter lifetime values to improve the robustness to renumbering
events, while complying with the requirements from Section 3.3 of events, while complying with the requirements from Section 3.3 of
this document and the recommendations in [RFC7772]. this document and the recommendations in [RFC7772].
CE Routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT. CE routers SHOULD set the "Router Lifetime" of Router Advertisement
(RA) messages to ND_PREFERRED_LIMIT.
CE Routers SHOULD also set the PIO Preferred Lifetime to the lesser CE routers SHOULD also set the PIO "Preferred Lifetime" to the lesser
of the remaining preferred lifetime (see Section 3.3) and of the remaining preferred lifetime of the corresponding prefix (see
ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the Section 3.3) and ND_PREFERRED_LIMIT, and set the PIO "Valid Lifetime"
remaining valid lifetime and ND_VALID_LIMIT. Additionally, the Route to the lesser of the remaining valid lifetime of the corresponding
Lifetime of Route Information Options (RIOs) [RFC4191], the Lifetime prefix and ND_VALID_LIMIT. Additionally, the "Route Lifetime" of
of Recursive DNS Search Options (RDNSSO) [RFC8106], and the Lifetime Route Information Options (RIOs) [RFC4191], the "Lifetime" of
of DNS Search List Options (DNSSLO) [RFC8106] SHOULD be set to the Recursive DNS Server (RDNSS) options [RFC8106], and the "Lifetime" of
lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option DNS Search List (DNSSL) options [RFC8106] SHOULD be set to the lesser
(received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of of the longest remaining valid lifetime of a prefix (leased via
these options are included in Router Advertisement messages. DHCPv6 on the WAN side) and ND_VALID_LIMIT, if any of these options
are included in Router Advertisement messages.
NOTES: In scenarios where the valid-lifetime and the preferred- NOTE: In scenarios where the valid lifetime and the preferred
lifetime of the prefix leased via DHCPv6 on the WAN-side are lifetime of prefixes learned via DHCPv6 on the WAN side are always
always larger than ND_VALID_LIMIT and ND_PREFERRED_LIMIT, larger than ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively,
respectively, the lifetime values advertised on the LAN-side will the lifetime values advertised on the LAN side will not experience
not experience actual changes. actual changes.
The above text refers to the Neighbor Discovery Options that are The above text refers to the Neighbor Discovery options that are
typically employed by CE Routers. A CE Router may need to apply typically employed by CE routers. A CE router may need to apply the
the same policy for setting the lifetime of other Neighbor same policy for setting the lifetime of other Neighbor Discovery
Discovery options it employs, if and where applicable. options it employs, if and where applicable.
CE Routers providing stateful address configuration via DHCPv6 SHOULD CE routers providing stateful address configuration via DHCPv6 SHOULD
set the DHCPv6 IA Address Option preferred-lifetime to the lesser of set the "preferred-lifetime" of a DHCPv6 IA Address option to the
the remaining preferred lifetime (see Section 3.3) and lesser of the remaining preferred lifetime of the corresponding
ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the prefix (see Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid-
lesser of the remaining valid lifetime and ND_VALID_LIMIT. lifetime" of the same option to the lesser of the remaining valid
lifetime of the corresponding prefix and ND_VALID_LIMIT.
CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 CE routers providing DHCPv6-PD on the LAN side SHOULD set the
IA Prefix Option preferred-lifetime to the lesser of the remaining "preferred-lifetime" of a DHCPv6 IA Prefix option to the lesser of
preferred lifetime (see Section 3.3) and ND_PREFERRED_LIMIT, and the the remaining preferred lifetime of the corresponding prefix (see
valid-lifetime of the same option to the lesser of the remaining Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid-lifetime" of
valid lifetime and ND_VALID_LIMIT. the same option to the lesser of the remaining valid lifetime of the
corresponding prefix and ND_VALID_LIMIT.
RATIONALE: RATIONALE:
* The Valid Lifetime and Preferred Lifetime of PIOs have a direct * The "Valid Lifetime" and "Preferred Lifetime" of PIOs have a
impact on three different aspects: direct impact on three different aspects:
+ The amount of time hosts may end up employing stale network - The amount of time hosts may end up employing stale network
configuration information (see [RFC8978]). configuration information (see [RFC8978]).
+ The amount of time CE Routers need to persist trying to - The amount of time CE routers need to persist trying to
deprecate stale network configuration information (e.g. to deprecate stale network configuration information (e.g., to
handle cases where hosts miss Router Advertisements and thus handle cases where hosts miss Router Advertisement messages and
still consider the stale information as valid). thus still consider the stale information as valid).
+ The amount of information that CE Routers need to maintain - The amount of information that CE routers need to maintain
when e.g. multiple crash-and-reboot events occur in the when, e.g., multiple crash-and-reboot events occur in the time
timespan represented by the option lifetimes employed on the span represented by the option lifetimes employed on the LAN
LAN-side. side.
* CE Routers need not employ the (possibly long) WAN-side * CE routers need not employ the (possibly long) WAN-side DHCPv6-PD
DHCPv6-PD lifetimes for the Valid Lifetime and Preferred lifetimes for the "Valid Lifetime" and "Preferred Lifetime" of
Lifetime of PIOs sent in Router Advertisements messages to PIOs sent in Router Advertisement messages to advertise sub-
advertise sub-prefixes of the leased prefix. Instead, CE prefixes of the leased prefix. Instead, CE routers SHOULD use
Routers SHOULD use shorter values for the Valid Lifetime and shorter values for the "Valid Lifetime" and "Preferred Lifetime"
Preferred Lifetime of PIOs, since subsequent Router of PIOs, since subsequent Router Advertisement messages will
Advertisement messages will nevertheless refresh the associated nevertheless refresh the associated lifetimes, leading to the same
lifetimes, leading to the same effective lifetimes as specified effective lifetimes as specified by the WAN-side DHCPv6-PD
by the WAN-side DHCPv6-PD lifetimes. lifetimes.
* Similarly, CE Routers need not employ the (possibly long) WAN- * Similarly, CE routers need not employ the (possibly long) WAN-side
side DHCPv6-PD lifetimes for the valid-lifetime and preferred- DHCPv6-PD lifetimes for the "valid-lifetime" and "preferred-
lifetime of IA Address Options and IA Prefix Option employed by lifetime" of IA Address options and IA Prefix options employed by
DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6 DHCPv6 on the LAN side, since the renewal of bindings by DHCPv6
clients will lead to the same effective lifetimes as specified clients will lead to the same effective lifetimes as specified by
by the WAN-side DHCPv6-PD lifetimes. the WAN-side DHCPv6-PD lifetimes.
3.5. Signaling Stale Configuration Information 3.5. Signaling Stale Configuration Information
When a CE Router provides LAN-side address-configuration information When a CE router provides LAN-side address-configuration information
via SLAAC: via SLAAC:
o A CE Router sending RAs that advertise dynamically-learned * A CE router sending RAs that advertise prefixes belonging to a
prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, dynamically learned prefix (e.g., via DHCPv6-PD) SHOULD record, on
the list of prefixes being advertised via PIOs on each network stable storage, the list of prefixes being advertised via PIOs on
segment, and the state of the "A" and "L" flags of the each network segment and the state of the "A" and "L" flags of the
corresponding PIOs. corresponding PIOs.
o Upon changes to the advertised prefixes, and after bootstrapping, * Upon changes to the advertised prefixes, and after bootstrapping,
the CE Router advertising prefix information via SLAAC proceeds as the CE router advertising prefix information via SLAAC proceeds as
follows: follows:
* Any prefixes that were previously advertised by the CE Router - Any prefixes that were previously advertised by the CE router
via PIOs in RA messages, but that have now become stale, MUST via PIOs in RA messages, but that have now become stale, MUST
be advertised with a PIO that has the "Valid Lifetime" and the be advertised with PIOs that have the "Valid Lifetime" and the
"Preferred Lifetime" set to 0, and the "A" and "L" bits "Preferred Lifetime" set to 0 and the "A" and "L" bits
unchanged. unchanged.
* The aforementioned advertisement MUST be performed for at least - The aforementioned advertisements MUST be performed for at
the "Valid Lifetime" previously employed for such prefix. The least the "Valid Lifetime" previously employed for such
CE Router MUST advertise this information with unsolicited prefixes. The CE router MUST advertise this information with
Router Advertisements as described in Section 6.2.4 of unsolicited Router Advertisement messages, as described in
[RFC4861], and MAY advertise this information via unicast Section 6.2.4 of [RFC4861], and MAY advertise this information
Router Advertisements when possible and applicable. via unicast Router Advertisement messages when possible and
applicable.
+ Note: If requirement L-16 (Section 3.4) is followed, the NOTE: If requirement L-16 (Section 3) is followed, the
Valid Lifetime need not be saved and the stale prefix can "Valid Lifetime" need not be saved, and the stale prefix can
simply be advertised for a period of ND_VALID_LIMIT. simply be advertised for a period of ND_VALID_LIMIT.
o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- * CE routers receiving DHCPv6 IA Prefix options with a 0 "valid-
lifetime MUST advertise the corresponding sub-prefixes (as they lifetime" MUST advertise the corresponding sub-prefixes (as they
would be generated for the same leased prefix with a non-zero would be generated for the same leased prefix with a non-zero
lifetime) with a PIO with both the Preferred Lifetime and the lifetime) with PIOs with both the "Preferred Lifetime" and the
Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD "Valid Lifetime" set to 0, for at least the WAN-side DHCPv6-PD
valid-lifetime, or for a period of ND_VALID_LIMIT if the "valid-lifetime", or for a period of ND_VALID_LIMIT if the
recommended lifetimes from Section 3.4 are employed. recommended lifetimes from Section 3.4 are employed.
When a CE Router provides LAN-side DHCPv6 (address assignment or When a CE router provides LAN-side DHCPv6 (address assignment or
prefix delegation), then: prefix delegation), then:
o The CE Router SHOULD record, on stable storage, the DHCPv6 address * The CE router SHOULD record, on stable storage, the DHCPv6 address
and delegated-prefix bindings corresponding to the LAN-side. and delegated-prefix bindings corresponding to the LAN side.
o If the CE Router finds that the prefix to be employed for address * If the CE router finds that the prefix to be employed for address
assignment and/or prefix delegation has changed (e.g., upon a assignment and/or prefix delegation has changed (e.g., upon a
crash-and-reboot event) or the CE Router receives DHCPv6 Prefix crash-and-reboot event) or the CE router receives DHCPv6 IA Prefix
Delegations with 0 lifetimes, the CE Router MUST: options with 0 lifetimes, the CE router MUST:
* In Replies to DHCPv6 Request, Renew, and Rebind messages, send - In Replies to DHCPv6 Request, Renew, and Rebind messages, send
IA Address Options or IA Prefix Options (as appropriate) for IA Address options or IA Prefix options (as appropriate) for
any address assignments or prefix delegations for the any address assignments or prefix delegations for the stale
deprecated prefixes. The aforementioned options MUST be sent prefixes. The aforementioned options MUST be sent with both
with both the valid-lifetime and the preferred-lifetime set to the "valid-lifetime" and the "preferred-lifetime" set to 0, for
0, for at least the valid-lifetime originally employed for at least the "valid-lifetime" originally employed for them, or
them, or for a period of ND_VALID_LIMIT if the recommended for a period of ND_VALID_LIMIT if the recommended lifetimes
lifetimes from Section 3.4 are employed. from Section 3.4 are employed.
* Initiate sending Reconfigure messages (if possible - i.e., - Initiate sending Reconfigure messages, if possible (i.e.,
client requests Reconfigure support and the CE Router offers client requests Reconfigure support and the CE router offers
it) to those clients with address assignments or prefix it), to those clients with address assignments or prefix
delegations for the deprecated prefixes. delegations for the stale prefixes.
RATIONALE: RATIONALE:
* IPv6 network renumbering is expected to take place in a planned * IPv6 network renumbering is expected to take place in a planned
manner, with old/stale prefixes being phased-out via reduced manner with old/stale prefixes being phased out via reduced prefix
prefix lifetimes while new prefixes (with normal lifetimes) are lifetimes while new prefixes (with normal lifetimes) are
introduced. However, a number of scenarios may lead to the so- introduced. However, a number of scenarios may lead to the so-
called "flash-renumbering" events, where the prefix being called "flash-renumbering" events, where a prefix being employed
employed on a network suddenly becomes invalid and replaced by on a network suddenly becomes invalid and replaced by a new prefix
a new prefix [RFC8978]. One such scenario is when a DHCPv6 [RFC8978]. One such scenario is when an Internet Service Provider
server employs dynamic prefixes and the Customer Edge Router (ISP) employs dynamic prefixes and the CE router crashes and
crashes and reboots. The requirements in this section are reboots. The requirements in this section are meant to allow CE
meant to allow Customer Edge Routers to deprecate stale routers to deprecate stale information in such scenarios.
information in such scenarios.
* The recommendations in this section expand from requirement * The recommendations in this section expand from requirement L-13
L-13 in Section 4.3 of [RFC7084], and Section 6.3 of [RFC8415]. in Section 4.3 of [RFC7084] and Section 6.3 of [RFC8415].
* Host configuring addresses via SLAAC on the local network may * Hosts configuring addresses via SLAAC on the local network may
employ addresses configured for the previously advertised employ addresses configured for the previously advertised prefixes
prefixes for at most the "Valid Lifetime" of the corresponding for at most the "Valid Lifetime" of the corresponding PIOs of the
PIO of the last received Router Advertisement message. Since last received Router Advertisement messages. Since Router
Router Advertisement messages may be lost or fail to be Advertisement messages may be lost or fail to be received for
received for various reasons, Customer Edge Routers need to try various reasons, CE routers need to try to deprecate stale
to deprecate stale prefixes for a period of time equal to the prefixes for a period of time equal to the "Valid Lifetime" of the
"Valid Lifetime" of the PIO employed when originally PIO employed when originally advertising the prefix.
advertising the prefix.
* The requirement in this section is conveyed as a "SHOULD" (as * The requirements in this section to store information on stable
opposed to a "MUST"), since the requirement to store storage are conveyed as "SHOULD" (as opposed to "MUST"), since
information on stable storage may represent a challenge for they may represent a challenge for some implementations.
some implementations.
* Advertising DHCPv6-leased prefixes with zero lifetimes on the * Advertising DHCPv6-leased prefixes with zero lifetimes on the LAN
LAN-side would handle the case where a CE Router has no stable side would handle the case where a CE router has no stable storage
storage but receives the prefixes via DHCPv6 with 0 lifetimes. but receives the prefixes via DHCPv6 with 0 lifetimes.
* The above text does not include DHCPv6 Advertise messages sent * The above text does not include DHCPv6 Advertise messages sent in
in response to DHCPv6 Solicit messages, since Section 18.3.9 of response to DHCPv6 Solicit messages, since Section 18.3.9 of
[RFC8415] requires that a DHCPv6 server that is not going to [RFC8415] requires that a DHCPv6 server that is not going to
assign an address or delegated prefix received as a hint in the assign an address or delegated prefix received as a hint in the
Solicit message MUST NOT include that address or delegated Solicit message MUST NOT include that address or delegated prefix
prefix in the Advertise message. Additionally, any subsequent in the Advertise message. Additionally, any subsequent Request
Request messages will trigger the response specified in this messages will trigger the response specified in this section and
section, and therefore cause the address or prefix to be therefore cause the address or prefix to be deprecated.
deprecated.
4. Recommended Option Lifetimes Configuration Values 4. Recommended Option Lifetimes Configuration Values
o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) * ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)
o ND_VALID_LIMIT: 5400 seconds (90 minutes) * ND_VALID_LIMIT: 5400 seconds (90 minutes)
RATIONALE: RATIONALE:
These values represent a trade-off among a number of factors,
* These values represent a trade-off among a number of factors,
including responsiveness and possible impact on the battery life including responsiveness and possible impact on the battery life
of connected devices [RFC7772]. of connected devices [RFC7772].
ND_PREFERRED_LIMIT is set according to the recommendations in * ND_PREFERRED_LIMIT is set according to the recommendations in
[RFC7772] for Router Lifetime, following the rationale from [RFC7772] for the "Router Lifetime", following the rationale from
Section 3.2 of [RFC8978]. Section 3.2 of [RFC8978].
ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some * ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some
additional leeway before configuration information is finally additional leeway before configuration information is finally
discarded by the host. discarded by the hosts.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
This document discusses a problem that may arise in scenarios where This document discusses a problem that may arise, e.g., in scenarios
dynamic IPv6 prefixes are employed, and proposes improvements to where dynamic IPv6 prefixes are employed, and it proposes
Customer Edge Routers [RFC7084] to mitigate the problem for improvements to CE routers [RFC7084] to mitigate the problem for
residential or small office scenarios. It does not introduce new residential or small office scenarios. It does not introduce new
security issues, and thus the same security considerations as for security issues; thus, the same security considerations as for
[RFC4861], [RFC4862], [RFC7084], and [RFC8415] apply. [RFC4861], [RFC4862], [RFC7084], and [RFC8415] apply.
7. Acknowledgments 7. References
The authors would like to thank Owen DeLong, Philip Homburg, Erik
Kline, and Ted Lemon, for their valuable help in improving this
document via successive detailed reviews.
The authors would like to thank Mikael Abrahamsson, Luis Balbinot,
Tim Chown, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Gert
Doering, Fernando Frediani, Guillermo Gont, Steinar Haug, Nick
Hilliard, Lee Howard, Christian Huitema, Sheng Jiang, Benjamin Kaduk,
Suresh Krishnan, Warren Kumari, Albert Manfredi, Olorunloba Olopade,
Jordi Palet Martinez, Richard Patterson, Pete Resnick, Michael
Richardson, Mark Smith, Job Snijders, Sander Steffann, Tarko Tikan,
Ole Troan, Loganaden Velvindron, Eric Vyncke, Robert Wilton, Timothy
Winters, Christopher Wood, and Chongfeng Xie, for providing valuable
comments on earlier versions of this document.
Fernando would also like to thank Brian Carpenter who, over the
years, has answered many questions and provided valuable comments
that have benefited his protocol-related work.
8. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
skipping to change at page 11, line 30 skipping to change at line 485
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-6man-slaac-renum] [6MAN-SLAAC-RENUM]
Gont, F., Zorz, J., and R. Patterson, "Improving the Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC) Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-ietf-6man-slaac- to Flash Renumbering Events", Work in Progress, Internet-
renum-02 (work in progress), January 2021. Draft, draft-ietf-6man-slaac-renum-02, 19 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
slaac-renum-02>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>. <https://www.rfc-editor.org/info/rfc7084>.
[RFC8978] Gont, F., Zorz, J., and R. Patterson, "Reaction of IPv6 [RFC8978] Gont, F., Žorž, J., and R. Patterson, "Reaction of IPv6
Stateless Address Autoconfiguration (SLAAC) to Flash- Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events", RFC 8978, DOI 10.17487/RFC8978, March Renumbering Events", RFC 8978, DOI 10.17487/RFC8978, March
2021, <https://www.rfc-editor.org/info/rfc8978>. 2021, <https://www.rfc-editor.org/info/rfc8978>.
Acknowledgments
The authors would like to thank Owen DeLong, Philip Homburg, Erik
Kline, and Ted Lemon for their valuable help in improving this
document via successive detailed reviews.
The authors would like to thank Mikael Abrahamsson, Luis Balbinot,
Brian Carpenter, Tim Chown, Lorenzo Colitti, Alejandro D'Egidio, Gert
Doering, Fernando Frediani, Guillermo Gont, Steinar Haug, Nick
Hilliard, Lee Howard, Christian Huitema, Sheng Jiang, Benjamin Kaduk,
Suresh Krishnan, Warren Kumari, Albert Manfredi, Olorunloba Olopade,
Jordi Palet Martinez, Pete Resnick, Michael Richardson, Mark Smith,
Job Snijders, Sander Steffann, Tarko Tikan, Ole Troan, Loganaden
Velvindron, Éric Vyncke, Robert Wilton, Timothy Winters, Christopher
Wood, and Chongfeng Xie for providing valuable comments on earlier
draft versions of this document.
Fernando would also like to thank Brian Carpenter who, over the
years, has answered many questions and provided valuable comments
that have benefited his protocol-related work.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks SI6 Networks
Segurola y Habana 4310, 7mo Piso 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires Segurola y Habana 4310
Villa Devoto
Ciudad Autonoma de Buenos Aires
Argentina Argentina
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Jan Zorz Jan Zorz
6connect 6connect
Email: jan@6connect.com Email: jan@6connect.com
Richard Patterson Richard Patterson
Sky UK Sky UK
Email: richard.patterson@sky.uk Email: richard.patterson@sky.uk
Bernie Volz Bernie Volz
Cisco Systems, Inc. Individual Contributor
300 Beaver Brook Rd 116 Hawkins Pond Road
Boxborough, MA 01719 Center Harbor, NH 03226
USA United States of America
Email: volz@cisco.com Email: bevolz@gmail.com
 End of changes. 85 change blocks. 
311 lines changed or deleted 319 lines changed or added

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