Improving the Reaction of Customer Edge Routers to IPv6 Renumbering EventsSI6 NetworksSegurola y Habana 4310, 7mo PisoVilla DevotoCiudad Autonoma de Buenos AiresArgentinafgont@si6networks.comhttps://www.si6networks.com6connectjan@6connect.comSky UKrichard.patterson@sky.ukIndividual Contributor116 Hawkins Pond RoadCenter HarborNH03226United States of Americabevolz@gmail.com
Operations and Management
IPv6 Operations Working Group (v6ops)IPv6problemaddressprefix delegationDHCPv6stale prefixesold prefixes
This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes invalid without any explicit signaling of that condition to the local nodes. This document updates RFC 7084.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further information
on BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
() in effect on the date of
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
IntroductionIn scenarios where network configuration information becomes invalid without any explicit signaling of that condition (such as when a Customer Edge (CE) router crashes and reboots without knowledge of the previously employed configuration information), hosts on the local network will continue using stale information for an unacceptably long period of time, thus resulting in connectivity problems. This problem is documented in detail in .This document specifies improvements to CE routers that help mitigate the aforementioned problem for residential and small office scenarios. It specifies recommendations for the default behavior of CE routers but does not preclude the availability of configuration knobs that might allow an operator or user to manually configure the CE router to deviate from these recommendations. This document updates RFC 7084.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Improved Customer Edge Router BehaviorThis section specifies and clarifies requirements for CE routers that can help mitigate the problem discussed in , particularly when they employ prefixes learned via DHCPv6 Prefix Delegation (DHCPv6-PD) on the WAN side with Stateless Address Autoconfiguration (SLAAC) or DHCPv6 on the LAN side. The recommendations in this document help improve robustness at the CE router (on which the user or ISP may have no control) and do not preclude implementation of host-side improvements such as those specified in .This document specifies additional WAN-side prefix-delegation (WPD) requirements to those specified in :
WPD-9:
CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
messages upon restart events. See for further details.
WPD-10:
CE routers MUST by default use a WAN-side Identity
Association IDentifier (IAID) value that is stable between CE router restarts,
DHCPv6 client restarts, or interface state changes (e.g., transient PPP
interfaces), unless the CE router employs the IAID techniques discussed in
.
See for further details.
This document also replaces LAN-side requirement L-13 from with:
L-13:
CE routers MUST signal stale configuration information as
specified in .
Finally, this document specifies the following additional LAN-side requirements to those from :
L-15:
CE routers MUST NOT advertise prefixes via SLAAC or assign
addresses or delegate prefixes via DHCPv6 on the LAN side using lifetimes that
exceed the remaining lifetimes of the corresponding prefixes learned on the
WAN side via DHCPv6-PD. For more details, see .
L-16:
CE routers SHOULD advertise capped SLAAC option lifetimes,
capped DHCPv6 IA Address option lifetimes, and capped IA Prefix option lifetimes, as specified
in .
Automatic DHCPv6 RELEASEs
Some CE routers are known to automatically send DHCPv6-PD RELEASE
messages upon restart events. However, this may inadvertently
trigger a flash-renumbering scenario, along with the associated
problems discussed in ,
that this document attempts to mitigate.
As a result, requirement WPD-9 from
specifies that CE routers SHOULD NOT automatically send
DHCPv6-PD RELEASE messages upon restart events.
Stability of IAIDs requires that the IAID for an IA
MUST be consistent across restarts of the DHCP
client. However, some popular CE routers are known to select new random
IAIDs, e.g., every time the underlying PPP session is established or when
the device is rebooted. This could be the result of extrapolating the
behavior described in or simply a
consequence of not storing IAIDs on stable storage along with failure to
employ an algorithm that consistently generates the same IAID upon
reboots. Thus, requirement WPD-10 from prevents CE routers from inadvertently triggering
flash-renumbering events on the local network.
Interface between the WAN Side and LAN SideThe "Preferred Lifetime" and "Valid Lifetime" of Prefix Information
Options (PIOs) corresponding
to prefixes learned via DHCPv6-PD on the WAN side MUST NOT span past the remaining preferred and valid lifetimes of
the corresponding DHCPv6-PD prefixes. This means that the "Preferred
Lifetime" and the "Valid Lifetime" advertised in PIOs by the CE router
MUST be dynamically adjusted such that they never span
past the remaining preferred and valid lifetimes of the corresponding
prefixes delegated via DHCPv6-PD on the WAN side.Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6
IA Address options and DHCPv6 IA Prefix options employed with DHCPv6
on the LAN side MUST NOT span past the remaining
preferred and valid lifetimes of the corresponding prefixes learned
via DHCPv6-PD on the WAN side. This means that the
"preferred-lifetime" and "valid-lifetime" of DHCPv6 IA Address options
and DHCPv6 IA Prefix options employed with DHCPv6 on the LAN side
MUST be dynamically adjusted such that they never span
past the remaining preferred and valid lifetimes of the corresponding
prefixes delegated to the CE router on the WAN side via DHCPv6-PD.RATIONALE:
The lifetime values employed for the "Preferred Lifetime"
(AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime)
of SLAAC Prefix Information Options must never be larger than
the remaining lifetimes of the corresponding prefixes (as learned
via DHCPv6-PD on the WAN side). This is in line with the
requirement from , which states:
In particular, if the
delegated prefix or a prefix derived from it is advertised for
stateless address autoconfiguration , 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 SLAAC must be dynamically updated (rather than static
values); otherwise, the advertised lifetimes would eventually
span past the DHCPv6-PD 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.
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 employed for address configuration on the LAN side, and employ shorter lifetime values to improve the robustness to renumbering events, while complying with the requirements from of this document and the recommendations in .
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 of the remaining preferred lifetime of the
corresponding prefix (see ) and ND_PREFERRED_LIMIT, and set the PIO "Valid
Lifetime" to the lesser of the remaining valid lifetime of the
corresponding prefix and ND_VALID_LIMIT.
Additionally, the "Route Lifetime" of Route Information Options (RIOs) , the "Lifetime" of Recursive DNS Server (RDNSS) options
, and the "Lifetime" of DNS Search List (DNSSL) options
SHOULD be set to the lesser of the
longest remaining valid lifetime of a prefix (leased via DHCPv6 on
the WAN side) and ND_VALID_LIMIT, if any of these options are included in
Router Advertisement messages.
NOTE: In scenarios where the valid lifetime and the preferred lifetime of
prefixes learned via DHCPv6 on the WAN side are always larger than
ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively, the lifetime values
advertised on the LAN side will not experience actual changes.
The above text refers to the Neighbor Discovery options that are typically
employed by CE routers. A CE router may need to apply the same policy for
setting the lifetime of other Neighbor Discovery options it employs, if and
where applicable.
CE routers providing stateful address configuration via DHCPv6
SHOULD set the "preferred-lifetime" of a DHCPv6 IA
Address option to the lesser of the remaining preferred lifetime of
the corresponding prefix (see ) and ND_PREFERRED_LIMIT, and set the
"valid-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
"preferred-lifetime" of a DHCPv6 IA Prefix option to the lesser of the
remaining preferred lifetime of the corresponding prefix (see ) and ND_PREFERRED_LIMIT, and set
the "valid-lifetime" of the same option to the lesser of the remaining valid
lifetime of the corresponding prefix and ND_VALID_LIMIT.
RATIONALE:
The "Valid Lifetime" and "Preferred Lifetime" of PIOs have a
direct impact on three different aspects:
The amount of time hosts may end up employing stale
network configuration information (see ).
The amount of time CE routers need to persist trying to
deprecate stale network configuration information (e.g., to
handle cases where hosts miss Router Advertisement messages
and thus still consider the stale information as
valid).
The amount of information that CE routers need to
maintain when, e.g., multiple crash-and-reboot events occur
in the time span represented by the option lifetimes employed
on the LAN side.
CE routers need not employ the (possibly long) WAN-side
DHCPv6-PD lifetimes for the "Valid Lifetime" and "Preferred
Lifetime" of PIOs sent in Router Advertisement messages to
advertise sub-prefixes of the leased prefix. Instead, CE
routers SHOULD use shorter values for the "Valid
Lifetime" and "Preferred Lifetime" of PIOs, since subsequent
Router Advertisement messages will nevertheless refresh the
associated lifetimes, leading to the same effective lifetimes
as specified by the WAN-side DHCPv6-PD lifetimes.
Similarly, CE routers need not employ the (possibly long) WAN-side DHCPv6-PD lifetimes for the "valid-lifetime" and "preferred-lifetime" of IA Address options and IA Prefix options employed by DHCPv6 on the LAN side, since the renewal of bindings by DHCPv6 clients will lead to the same effective lifetimes as specified by the WAN-side DHCPv6-PD lifetimes.
Signaling Stale Configuration InformationWhen a CE router provides LAN-side address-configuration information via SLAAC:
A CE router sending RAs that advertise prefixes belonging to a
dynamically learned prefix (e.g., via DHCPv6-PD)
SHOULD record, on stable storage, the list of
prefixes being advertised via PIOs on each network segment and the
state of the "A" and "L" flags of the corresponding PIOs.
Upon changes to the advertised prefixes, and after
bootstrapping, the CE router advertising prefix information via
SLAAC proceeds as follows:
Any prefixes that were previously advertised by the CE
router via PIOs in RA messages, but that have now become stale,
MUST be advertised with PIOs that have the "Valid
Lifetime" and the "Preferred Lifetime" set to 0 and the "A" and
"L" bits unchanged.
The aforementioned advertisements MUST be
performed for at least the "Valid Lifetime" previously
employed for such prefixes. The CE router MUST
advertise this information with unsolicited Router
Advertisement messages, as described in , and
MAY advertise this information via unicast
Router Advertisement messages when possible and applicable.
NOTE: If requirement L-16 () is followed, the "Valid Lifetime" need
not be saved, and the stale prefix can simply be advertised
for a period of ND_VALID_LIMIT.
CE routers receiving DHCPv6 IA Prefix options with a 0
"valid-lifetime" MUST advertise the corresponding
sub-prefixes (as they would be generated for the same leased prefix
with a non-zero 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", or for a period of
ND_VALID_LIMIT if the recommended lifetimes from are employed.
When a CE router provides LAN-side DHCPv6 (address assignment or
prefix delegation), then:
The CE router SHOULD record, on stable storage,
the DHCPv6 address and delegated-prefix bindings corresponding to
the LAN side.
If the CE router finds that the prefix to be employed for
address assignment and/or prefix delegation has changed (e.g.,
upon a crash-and-reboot event) or the CE router receives DHCPv6 IA
Prefix options with 0 lifetimes, the CE router
MUST:
In Replies to DHCPv6 Request, Renew, and Rebind messages,
send IA Address options or IA Prefix options (as appropriate)
for any address assignments or prefix delegations for the stale
prefixes. The aforementioned options MUST be sent
with both the "valid-lifetime" and the "preferred-lifetime" set
to 0, for at least the "valid-lifetime" originally employed for
them, or for a period of ND_VALID_LIMIT if the recommended
lifetimes from
are employed.
Initiate sending Reconfigure messages, if possible (i.e.,
client requests Reconfigure support and the CE router offers
it), to those clients with address assignments or prefix
delegations for the stale prefixes.
RATIONALE:
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, a number of scenarios may
lead to the so-called "flash-renumbering" events, where a prefix
being employed on a network suddenly becomes invalid and
replaced by a new prefix . One such scenario is when an Internet
Service Provider (ISP) employs dynamic prefixes and the CE
router crashes and reboots. The requirements in this section are
meant to allow CE routers to deprecate stale information in such
scenarios.
The recommendations in this section expand from requirement
L-13 in and .
Hosts configuring addresses via SLAAC on the local network
may employ addresses configured for the previously advertised
prefixes for at most the "Valid Lifetime" of the corresponding
PIOs of the last received Router Advertisement messages. Since
Router Advertisement messages may be lost or fail to be received
for various reasons, CE routers need to try to
deprecate stale prefixes for a period of time equal to the
"Valid Lifetime" of the PIO employed when originally advertising
the prefix.
The requirements in this section to store information on
stable storage are conveyed as "SHOULD" (as
opposed to "MUST"), since they may represent a
challenge for some implementations.
Advertising DHCPv6-leased prefixes with zero lifetimes on
the LAN side would handle the case where a CE router has no
stable storage but receives the prefixes via DHCPv6 with 0
lifetimes.
The above text does not include DHCPv6 Advertise messages
sent in response to DHCPv6 Solicit messages, since requires that a DHCPv6 server that is not
going to assign an address or delegated prefix received as a
hint in the Solicit message MUST NOT include that
address or delegated prefix in the Advertise
message. Additionally, any subsequent Request messages will
trigger the response specified in this section and therefore
cause the address or prefix to be deprecated.
Recommended Option Lifetimes Configuration Values
ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)
ND_VALID_LIMIT: 5400 seconds (90 minutes)
RATIONALE:
These values represent a trade-off among a number of factors, including responsiveness and possible impact on the battery life of connected devices .
ND_PREFERRED_LIMIT is set according to the recommendations in
for the "Router Lifetime",
following the rationale from .
ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some additional leeway before configuration information is finally discarded by the hosts.
IANA Considerations
This document has no IANA actions.
Security ConsiderationsThis document discusses a problem that may arise, e.g., in scenarios where
dynamic IPv6 prefixes are employed, and it proposes improvements to
CE routers to
mitigate the problem for residential or small office scenarios. It does
not introduce new security issues; thus, the same security
considerations as for , , , and
apply.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Default Router Preferences and More-Specific RoutesThis document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]IPv6 Stateless Address AutoconfigurationThis document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]Reducing Energy Consumption of Router AdvertisementsFrequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.Anonymity Profiles for DHCP ClientsSome DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.IPv6 Router Advertisement Options for DNS ConfigurationThis document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Dynamic Host Configuration Protocol for IPv6 (DHCPv6)This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.Informative ReferencesImproving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering EventsSI6 Networks6connectSky UK 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.
Work in ProgressBasic Requirements for IPv6 Customer Edge RoutersThis document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering EventsIn scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed.AcknowledgmentsThe authors would like to thank ,
, ,
and for their valuable help in
improving this document via successive detailed reviews.
The authors would like to thank , , , , , ,
, , , , , , ,
, ,
, , , , , , , ,
, , , , , , , , ,
and for providing valuable comments
on earlier draft versions of this document.Fernando would also like to thank who, over the years, has answered many questions and
provided valuable comments that have benefited his protocol-related
work.Authors' AddressesSI6 NetworksSegurola y Habana 4310, 7mo PisoVilla DevotoCiudad Autonoma de Buenos AiresArgentinafgont@si6networks.comhttps://www.si6networks.com6connectjan@6connect.comSky UKrichard.patterson@sky.ukIndividual Contributor116 Hawkins Pond RoadCenter HarborNH03226United States of Americabevolz@gmail.com