rfc9096xml2.original.xml   rfc9096.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc subcompact="no" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" updates="7084" ipr="trust200902"
<?rfc sortrefs="yes"?> docName="draft-ietf-v6ops-cpe-slaac-renum-08" number="9096" obsoletes="" submis
<?rfc strict="no" ?> sionType="IETF"
category="bcp" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" s
ortRefs="true" version="3">
<rfc category="bcp" updates="7084" ipr="trust200902"
docName="draft-ietf-v6ops-cpe-slaac-renum-08">
<front> <front>
<title abbrev="Reaction to Renumbering Events">Improving the Reaction of Cus tomer Edge Routers to IPv6 Renumbering Events</title>
<title abbrev="CE Requirements for Renumbering Events">Improving the
Reaction of Customer Edge Routers to IPv6 Renumbering Events</title>
<seriesInfo name="RFC" value="9096"/>
<seriesInfo name="BCP" value="234"/>
<author fullname="Fernando Gont" initials="F." surname="Gont"> <author fullname="Fernando Gont" initials="F." surname="Gont">
<organization abbrev="SI6 Networks">SI6 Networks</organization> <organization abbrev="SI6 Networks">SI6 Networks</organization>
<address> <address>
<postal> <postal>
<street>Segurola y Habana 4310, 7mo Piso</street> <extaddr>7mo Piso</extaddr>
<street>Segurola y Habana 4310</street>
<city>Villa Devoto</city> <city>Villa Devoto</city>
<region>Ciudad Autonoma de Buenos Aires</region> <region>Ciudad Autonoma de Buenos Aires</region>
<country>Argentina</country> <country>Argentina</country>
</postal> </postal>
<email>fgont@si6networks.com</email> <email>fgont@si6networks.com</email>
<uri>https://www.si6networks.com</uri> <uri>https://www.si6networks.com</uri>
</address> </address>
</author> </author>
<author fullname="Jan Zorz" initials="J." surname="Zorz">
<author fullname="Jan Zorz" initials="J." surname="Zorz">
<organization abbrev="6connect">6connect</organization> <organization abbrev="6connect">6connect</organization>
<address> <address>
<!--
<postal>
<street>Frankovo naselje 165</street>
<code>4220</code>
<city>Skofja Loka</city>
<country>Slovenia</country>
</postal>
<email>jan@6connect.com</email> <email>jan@6connect.com</email>
<!-- <uri>https://www.6connect.com/</uri> -->
</address> </address>
</author> </author>
<author initials="R." surname="Patterson" fullname="Richard Patterson">
<author initials="R." surname="Patterson" fullname="Richard Patterson">
<organization>Sky UK</organization> <organization>Sky UK</organization>
<address> <address>
<email>richard.patterson@sky.uk</email> <email>richard.patterson@sky.uk</email>
</address> </address>
</author> </author>
<author fullname="Bernie Volz" initials="B" surname="Volz"> <author fullname="Bernie Volz" initials="B" surname="Volz">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Individual Contributor">Individual Contributor</orga
nization>
<address> <address>
<postal> <postal>
<street>300 Beaver Brook Rd</street> <street>116 Hawkins Pond Road</street>
<city>Boxborough, MA 01719</city> <city>Center Harbor</city>
<country>USA</country> <region>NH</region>
<code>03226</code>
<country>United States of America</country>
</postal> </postal>
<email>volz@cisco.com</email> <email>bevolz@gmail.com</email>
</address> </address>
</author> </author>
<date year="2021" month="August" />
<date/>
<area>Operations and Management</area> <area>Operations and Management</area>
<workgroup>IPv6 Operations Working Group (v6ops)</workgroup> <workgroup>IPv6 Operations Working Group (v6ops)</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in <keyword>IPv6</keyword>
the title) for use on http://www.rfc-editor.org/search.html. --> <keyword>problem</keyword>
<keyword>address</keyword>
<keyword>prefix delegation</keyword>
<keyword>DHCPv6</keyword>
<keyword>stale prefixes</keyword>
<keyword>old prefixes</keyword>
<keyword></keyword> <keyword/>
<abstract> <abstract>
<t> <t>
This document specifies improvements to Customer Edge Routers that help mitigate the problems that may arise when network configuration information becomes inva lid, without any explicit signaling of that condition to the local nodes. This d ocument updates RFC7084. This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes inva lid without any explicit signaling of that condition to the local nodes. This do cument updates RFC 7084.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>In scenarios where network configuration information becomes invalid without <name>Introduction</name>
any explicit signaling of that condition (such as when a Customer Edge Router cr <t>In scenarios where network configuration information becomes invalid wi
ashes and reboots without knowledge of the previously-employed configuration inf thout any explicit signaling of that condition (such as when a Customer Edge (CE
ormation), hosts on the local network will continue using stale information for ) router crashes and reboots without knowledge of the previously employed config
an unacceptably long period of time, thus resulting in connectivity problems. Th uration information), hosts on the local network will continue using stale infor
is problem is documented in detail in <xref target="RFC8978"/>.</t> mation for an unacceptably long period of time, thus resulting in connectivity p
roblems. This problem is documented in detail in <xref target="RFC8978" format="
<t>This document specifies improvements to Customer Edge (CE) Routers that help default"/>.</t>
mitigate the aforementioned problem for residential and small office scenarios. <t>This document specifies improvements to CE routers that help mitigate t
It specifies recommendations for the default behavior of CE Routers, and does no he aforementioned problem for residential and small office scenarios. It specifi
t preclude the availability of configuration knobs that might allow an operator es recommendations for the default behavior of CE routers but does not preclude
or user to manually-configure the CE Router to deviate from these recommendation the availability of configuration knobs that might allow an operator or user to
s. This document updates RFC7084. manually configure the CE router to deviate from these recommendations. This doc
</t> ument updates RFC 7084.
</section>
<section anchor="reqs-language" title="Requirements Language">
<t>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 <xref target='RFC2119' /> <xref target='RFC8174' /> wh
en, and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section anchor="CPE" title="Improved Customer Edge Router Behavior">
<t>This section specifies and clarifies requirements for Customer Edge Routers t
hat can help mitigate the problem discussed in <xref target="intro"/>, particula
rly when they employ prefixes learned via DHCPv6-Prefix Delegation (DHCPv6-PD) <
xref target="RFC8415"/> on the WAN-side with Stateless Address Autoconfiguration
(SLAAC) <xref target="RFC4862"/> or DHCPv6 <xref target="RFC8415"/> on the LAN-
side. The recommendations in this document help improve robustness at the Custom
er Edge Router (on which the user or ISP may have no control), and do not preclu
de implementation of host-side improvements such as those specified in <xref tar
get="I-D.ietf-6man-slaac-renum"/>.</t>
<t>This document specifies additional prefix-delegation requirements to those sp
ecified in <xref target="RFC7084"/>:
<list style="symbols">
<t>WPD-9: CE routers SHOULD NOT automatically send DHCPv6-PD RELE
ASE messages upon reboot events. See <xref target="dhcpv6-release"/> for further
details.</t>
<!-- OLD text, changed in response to Ben Kaduk's comments
<t>WPD-10: CE Routers MUST by default use a stable IAID value tha
t does not change between CE Router restarts, DHCPv6 client restarts, or interfa
ce state changes. e.g., Transient PPP interfaces. See <xref target="dhcpv6-iaid"
/> for further details.</t>
<t>WPD-10: CE Routers MUST by default use a WAN-side IAID value that is stable b
etween 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 Section 4.5 of <xref target="RFC7844"/>. See <xref target="dhcpv6
-iaid"/> for further details.
</t> </t>
</section>
<section anchor="reqs-language" numbered="true" toc="default">
<name>Requirements Language</name>
</list> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</t> </section>
<section anchor="CPE" numbered="true" toc="default">
<name>Improved Customer Edge Router Behavior</name>
<t>This section specifies and clarifies requirements for CE routers that c
an help mitigate the problem discussed in <xref target="intro" format="default"/
>, particularly when they employ prefixes learned via DHCPv6 Prefix Delegation (
DHCPv6-PD) <xref target="RFC8415" format="default"/> on the WAN side with Statel
ess Address Autoconfiguration (SLAAC) <xref target="RFC4862" format="default"/>
or DHCPv6 <xref target="RFC8415" format="default"/> on the LAN side. The recomme
ndations 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-sid
e improvements such as those specified in <xref target="I-D.ietf-6man-slaac-renu
m" format="default"/>.</t>
<t>This document also replaces LAN-side requirement L-13 from <xref target="RFC7 084"/> with: <t>This document specifies additional WAN-side prefix-delegation (WPD) req uirements to those specified in <xref target="RFC7084" format="default"/>:
<list style="symbols"> </t>
<t>L-13: CE routers MUST signal stale configuration information a
s specified in <xref target="sig-stale-config"/>.</t>
</list>
</t>
<t>Finally, this document specifies the following additional LAN-side requiremen ts to those from <xref target="RFC7084"/>: <dl>
<list style="symbols"> <dt>WPD-9:</dt>
<t>L-15: CE routers MUST NOT advertise prefixes via SLAAC or assi <dd>CE routers <bcp14>SHOULD NOT</bcp14> automatically send DHCPv6-PD RELEASE
gn addresses or delegate prefixes via DHCPv6 on the LAN-side, employing lifetime messages upon restart events. See <xref target="dhcpv6-release"
s that exceed the remaining lifetimes of the corresponding prefixes learned from format="default"/> for further details.
the WAN-side via DHCPv6-PD. For more details, see <xref target="dhcpv6-pd-slaac </dd>
"/>.</t>
<t>L-16: CE routers SHOULD advertise capped SLAAC option lifetime
s and capped DHCPv6 IA Address Option and IA Prefix Option lifetimes, as specifi
ed in <xref target="lan-lifetimes"/>.</t>
</list>
</t>
<!-- <dt>WPD-10:</dt>
XXX: OLD <dd>CE routers <bcp14>MUST</bcp14> by default use a WAN-side Identity
<t>This document specifies additional LAN-side requirements to requirements L-1 Association IDentifier (IAID) value that is stable between CE router restarts,
through L-14 specified in <xref target="RFC7084"/>: DHCPv6 client restarts, or interface state changes (e.g., transient PPP
interfaces), unless the CE router employs the IAID techniques discussed in
<xref target="RFC7844" sectionFormat="of" section="4.5" format="default"/>.
See <xref target="dhcpv6-iaid" format="default"/> for further details.
</dd>
<list style="symbols"> </dl>
<t>L-15: CE routers MUST NOT advertise prefixes via SLAAC or assi
gn addresses or delegate prefixes via DHCPv6 on the LAN-side, employing lifetime
s that exceed the remaining lifetimes of the corresponding prefixes learned from
the WAN-side via DHCPv6-PD. For more details, see <xref target="dhcpv6-pd-slaac
"/>.</t>
<t>L-16: CE routers SHOULD advertise capped SLAAC option lifetime
s and capped DHCPv6 IA Address Option and IA Prefix Option lifetimes, as specifi
ed in <xref target="lan-lifetimes"/>.</t>
<t>L-17: CE routers MUST signal stale configuration information a
s specified in <xref target="sig-stale-config"/>.</t>
<t>L-18: CE routers SHOULD NOT automatically send DHCPv6-PD RELEA
SE messages upon reboot events. See <xref target="dhcpv6-release"/> for further
details.</t>
</list>
</t>
<section title="Automatic DHCPv6 RELEASEs" anchor="dhcpv6-release"> <t>This document also replaces LAN-side requirement L-13 from <xref target
<t> ="RFC7084" format="default"/> with:
Some CE Routers are known to automatically send DHCPv6-PD RELEASE messages upon
reboot events. However, this may inadvertently trigger a flash-renumbering scena
rio, along with the associated problems discussed in <xref target="RFC8978"/>, t
hat this document attempts to mitigate.
</t>
<t>
As a result, requirement WPD-9 from <xref target="CPE"/> specifies that CE route
rs SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot events.
</t> </t>
</section>
<section title="Stability of IAIDs" anchor="dhcpv6-iaid"> <dl>
<t> <dt>L-13:</dt>
<xref target="RFC8415"/> requires that the IAID for an IA MUST be consistent <dd>CE routers <bcp14>MUST</bcp14> signal stale configuration information as
across specified in <xref target="sig-stale-config" format="default"/>.
restarts of the DHCP client. However, some popular CE Routers are </dd>
known to select new random IAIDs e.g. everytime the underlying PPP
session is established. This could be the result of extrapolating the
behavior described in <xref target="RFC7844"/>, or simply a consequence of no
t
storing IAIDs on stable storage along with failing to employ an algorithm
that consistently generates the same IAID upon reboots. Thus, requirement WPD
-10 from <xref target="CPE"/> prevents CE Routers from inadvertently triggering
flash-renumbering events on the local network.
</t>
</section>
<section title="Interface Between WAN-side and LAN-side" anchor="dhcpv6-pd-slaac </dl>
">
<t>The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information Options (
PIOs) <xref target="RFC4861"/> corresponding to prefixes learned via DHCPv6-PD M
UST NOT span past the remaining preferred and valid lifetimes of the correspondi
ng DHCPv6-PD prefixes. This means that the "Preferred Lifetime" and the "Valid L
ifetime" advertised in PIOs by the CE router MUST be dynamically adjusted such t
hat they never span past the remaining preferred and valid lifetimes of the corr
esponding prefixes delegated via DHCPv6-PD on the WAN-side.</t>
<t>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 p refixes leased via DHCPv6-PD on the WAN-side. This means that the "preferred-lif etime" and "valid-lifetime" of DHCPv6 IA Address Options and DHCPv6 IA Prefix Op tions employed with DHCPv6 on the LAN-side MUST be dynamically adjusted such tha t they never span past the remaining preferred and valid lifetimes of the corres ponding prefixes delegated to the CE router on the WAN-side via DHCPv6-PD.</t> <t>Finally, this document specifies the following additional LAN-side requ irements to those from <xref target="RFC7084" format="default"/>:
<!-- </t>
XXX This was repeated in the next section, and hence removed from here.
<t>CE Routers providing stateful address configuration via DHCPv6 SHOULD set the DHCPv6 IA Address Option preferred-lifetime to the lesser of the remaining pref erred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the lesser of the remaining valid lifetime and ND_VALID_LIMIT. <dl>
<list style="hanging"> <dt>L-15:</dt>
<t hangText="NOTE:"> <dd>
ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in <xre
f target="parameters"/></t>
</list>
</t> CE routers <bcp14>MUST NOT</bcp14> 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 <xref target="dhcpv6-pd-slaac"
format="default"/>.
</dd>
<t> <dt>L-16:
CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 IA Prefix O </dt>
ption preferred-lifetime to the lesser of the remaining preferred lifetime and N <dd>CE routers <bcp14>SHOULD</bcp14> advertise capped SLAAC option lifetimes,
D_PREFERRED_LIMIT, and the valid-lifetime of the same option to the lesser of th capped DHCPv6 IA Address option lifetimes, and capped IA Prefix option lifetimes
e remaining valid lifetime and ND_VALID_LIMIT. , as specified
in <xref target="lan-lifetimes" format="default"/>.
</dd>
</t> </dl>
<t> <section anchor="dhcpv6-release" numbered="true" toc="default">
<list style="hanging"> <name>Automatic DHCPv6 RELEASEs</name>
<t hangText="RATIONALE:"> <t>
<list style="symbols"> Some CE routers are known to automatically send DHCPv6-PD RELEASE
<t>The lifetime values employed for the "Preferred Lifeti messages upon restart events. However, this may inadvertently
me" (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) of SLAAC Pref trigger a flash-renumbering scenario, along with the associated
ix Information Options must never be larger than the remaining lifetimes for the problems discussed in <xref target="RFC8978" format="default"/>,
corresponding prefix (as learned via DHCPv6-PD on the WAN-side). This is in lin that this document attempts to mitigate.
e with the requirement from Section 6.3 of <xref target="RFC8415"/>, which state
s that "if the delegated prefix
or a prefix derived from it is advertised for stateless address
autoconfiguration <xref target="RFC4862"/>, the advertised preferred and vali
d
lifetimes MUST NOT exceed the corresponding remaining lifetimes of
the delegated prefix."</t>
<t>The lifetime values of prefixes advertised on the LAN-
side via SLAAC must be dynamically updated (rather than static values), otherwis
e the advertised lifetimes would eventually span past the DHCPv6-PD lifetimes.</
t>
<t>The same considerations apply for the valid-lifetime a
nd preferred-lifetime of IA Address Options and IA Prefix Options employed with
DHCPv6 on the LAN-side.</t>
</list>
</t> </t>
</list> <t>
As a result, requirement WPD-9 from <xref target="CPE" format="default"/>
specifies that CE routers <bcp14>SHOULD NOT</bcp14> automatically send
DHCPv6-PD RELEASE messages upon restart events.
</t> </t>
</section>
</section> <section anchor="dhcpv6-iaid" numbered="true" toc="default">
<name>Stability of IAIDs</name>
<section title="LAN-side Option Lifetimes" anchor="lan-lifetimes"> <t>
<xref target="RFC8415" format="default"/> requires that the IAID for an IA
<t> <bcp14>MUST</bcp14> be consistent across restarts of the DHCP
CE Routers SHOULD override the default lifetime values of Neighbor Discovery opt client. However, some popular CE routers are known to select new random
ions that depend in any way on changes in the prefix employed for address config IAIDs, e.g., every time the underlying PPP session is established or when
uration on the LAN-side, and employ shorter lifetime values to improve the robus the device is rebooted. This could be the result of extrapolating the
tness to renumbering events, while complying with the requirements from <xref ta behavior described in <xref target="RFC7844" format="default"/> or simply a
rget="dhcpv6-pd-slaac"/> of this document and the recommendations in <xref targe consequence of not storing IAIDs on stable storage along with failure to
t="RFC7772"/>. employ an algorithm that consistently generates the same IAID upon
reboots. Thus, requirement WPD-10 from <xref target="CPE"
format="default"/> prevents CE routers from inadvertently triggering
flash-renumbering events on the local network.
</t> </t>
</section>
<section anchor="dhcpv6-pd-slaac" numbered="true" toc="default">
<name>Interface between the WAN Side and LAN Side</name>
<t>The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information
Options (PIOs) <xref target="RFC4861" format="default"/> corresponding
to prefixes learned via DHCPv6-PD on the WAN side <bcp14>MUST
NOT</bcp14> 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
<bcp14>MUST</bcp14> 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.</t>
<t>Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6
IA Address options and DHCPv6 IA Prefix options employed with DHCPv6
on the LAN side <bcp14>MUST NOT</bcp14> 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
<bcp14>MUST</bcp14> 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.</t>
<t>CE Routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT.</t> <t>RATIONALE:</t>
<ul spacing="normal">
<li>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 <xref target="RFC8415" sectionFormat="of"
section="6.3" format="default"/>, which states:</li></ul>
<t>CE Routers SHOULD also set the PIO Preferred Lifetime to the lesser of the re <blockquote>In particular, if the
maining preferred lifetime (see <xref target="dhcpv6-pd-slaac"/>) and ND_PREFERR delegated prefix or a prefix derived from it is advertised for
ED_LIMIT, and the PIO Valid Lifetime to the lesser of the remaining valid lifeti stateless address autoconfiguration <xref target="RFC4862"
me and ND_VALID_LIMIT. Additionally, the Route Lifetime of Route Information Opt format="default"/>, the advertised preferred and valid lifetimes
ions (RIOs) <xref target="RFC4191"/>, the Lifetime of Recursive DNS Search Optio <bcp14>MUST NOT</bcp14> exceed the corresponding remaining
ns (RDNSSO) <xref target="RFC8106"/>, and the Lifetime of DNS Search List Option lifetimes of the delegated prefix.</blockquote>
s (DNSSLO) <xref target="RFC8106"/> SHOULD be set to the lesser of the longest v
alid-lifetime in a DHCPv6 IA Prefix Option (received via DHCPv6 on the WAN-side)
and ND_VALID_LIMIT, if any of these options are included in Router Advertisemen
t messages.
<list style="hanging"> <ul spacing="normal">
<t hangText="NOTES:"> <li>The lifetime values of prefixes advertised on the LAN side
In scenarios where the valid-lifetime and the preferred-lifetime of the prefix l via SLAAC must be dynamically updated (rather than static
eased via DHCPv6 on the WAN-side are always larger than ND_VALID_LIMIT and ND_PR values); otherwise, the advertised lifetimes would eventually
EFERRED_LIMIT, respectively, the lifetime values advertised on the LAN-side will span past the DHCPv6-PD lifetimes.</li>
not experience actual changes.
</t>
<t>The above text refers to the Neighbor Discovery Options that are typically em
ployed 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 applic
able.
</t>
</list>
</t>
<t>CE Routers providing stateful address configuration via DHCPv6 SHOULD set the <li>The same considerations apply for the "valid-lifetime" and
DHCPv6 IA Address Option preferred-lifetime to the lesser of the remaining pref "preferred-lifetime" of IA Address options and IA Prefix options
erred lifetime (see <xref target="dhcpv6-pd-slaac"/>) and ND_PREFERRED_LIMIT, an employed with DHCPv6 on the LAN side.</li>
d the valid-lifetime of the same option to the lesser of the remaining valid lif </ul>
etime and ND_VALID_LIMIT.
</t>
<t> </section>
CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 IA Prefix O <section anchor="lan-lifetimes" numbered="true" toc="default">
ption preferred-lifetime to the lesser of the remaining preferred lifetime (see <name>LAN-Side Option Lifetimes</name>
<xref target="dhcpv6-pd-slaac"/>) and ND_PREFERRED_LIMIT, and the valid-lifetime <t>
of the same option to the lesser of the remaining valid lifetime and ND_VALID_L CE routers <bcp14>SHOULD</bcp14> override the default lifetime values of Neighbo
IMIT. r 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 im
prove the robustness to renumbering events, while complying with the requirement
s from <xref target="dhcpv6-pd-slaac" format="default"/> of this document and th
e recommendations in <xref target="RFC7772" format="default"/>.
</t> </t>
<t>CE routers <bcp14>SHOULD</bcp14> set the "Router Lifetime" of
Router Advertisement (RA) messages to ND_PREFERRED_LIMIT.</t>
<t> <t>CE routers <bcp14>SHOULD</bcp14> also set the PIO "Preferred
<list style="hanging"> Lifetime" to the lesser of the remaining preferred lifetime of the
<t hangText="RATIONALE:"> corresponding prefix (see <xref target="dhcpv6-pd-slaac"
<list style="symbols"> format="default"/>) and ND_PREFERRED_LIMIT, and set the PIO "Valid
<t>The Valid Lifetime and Preferred Lifetime of PIOs have a direct impact on thr Lifetime" to the lesser of the remaining valid lifetime of the
ee different aspects: corresponding prefix and ND_VALID_LIMIT.
<list style="symbols">
<t>The amount of time hosts may end up employing stale network co
nfiguration information (see <xref target="RFC8978"/>).</t>
<t>The amount of time CE Routers need to persist trying to deprec
ate stale network configuration information (e.g. to handle cases where hosts mi
ss Router Advertisements and thus still consider the stale information as valid)
.</t>
<t>The amount of information that CE Routers need to maintain whe
n e.g. multiple crash-and-reboot events occur in the timespan represented by the
option lifetimes employed on the LAN-side.</t>
</list>
</t>
<t> Additionally, the "Route Lifetime" of Route Information Options (RIOs) <xref
CE Routers need not employ the (possibly long) WAN-side DHCPv6-PD lifetimes for target="RFC4191"/>, the "Lifetime" of Recursive DNS Server (RDNSS) options
the Valid Lifetime and Preferred Lifetime of PIOs sent in Router Advertisements <xref target="RFC8106"/>, and the "Lifetime" of DNS Search List (DNSSL) options
messages to advertise sub-prefixes of the leased prefix. Instead, CE Routers SHO <xref target="RFC8106"/> <bcp14>SHOULD</bcp14> be set to the lesser of the
ULD use shorter values for the Valid Lifetime and Preferred Lifetime of PIOs, si longest remaining valid lifetime of a prefix (leased via DHCPv6 on
nce subsequent Router Advertisement messages will nevertheless refresh the assoc the WAN side) and ND_VALID_LIMIT, if any of these options are included in
iated lifetimes, leading to the same effective lifetimes as specified by the WAN Router Advertisement messages.
-side DHCPv6-PD lifetimes.
</t>
<t>
Similarly, CE Routers need not employ the (possibly long) WAN-side DHCPv6-PD lif
etimes for the valid-lifetime and preferred-lifetime of IA Address Options and I
A Prefix Option employed by DHCPv6 on the LAN-side, since the renewal of binding
s by DHCPv6 clients will lead to the same effective lifetimes as specified by th
e WAN-side DHCPv6-PD lifetimes.
</t>
</list>
</t> </t>
</list>
</t>
</section>
<section title="Signaling Stale Configuration Information" anchor="sig-stale-con
fig">
<t>When a CE Router provides LAN-side address-configuration information via SLAA
C:
<list style="symbols"> <t indent="3">
<t>A CE Router sending RAs that advertise dynamically-learned pre NOTE: In scenarios where the valid lifetime and the preferred lifetime of
fixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, the list of prefixe prefixes learned via DHCPv6 on the WAN side are always larger than
s being advertised via PIOs on each network segment, and the state of the "A" an ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively, the lifetime values
d "L" flags of the corresponding PIOs.</t> advertised on the LAN side will not experience actual changes.
<t>Upon changes to the advertised prefixes, and after bootstrapping, the CE Rout
er advertising prefix information via SLAAC proceeds as follows:
<list style="symbols">
<t>Any prefixes that were previously advertised b
y the CE Router via PIOs in RA messages, but that have now become stale, MUST be
advertised with a PIO that has the "Valid Lifetime" and the "Preferred Lifetime
" set to 0, and the "A" and "L" bits unchanged.
</t>
<t>The aforementioned advertisement MUST be performed for at least the "Valid Li
fetime" previously employed for such prefix. The CE Router MUST advertise this i
nformation with unsolicited Router Advertisements as described in Section 6.2.4
of <xref target="RFC4861"/>, and MAY advertise this information via unicast Rout
er Advertisements when possible and applicable.
<list><t>Note: If requirement L-16 (<xref target="lan-lifetimes"/>) is followed,
the Valid Lifetime need not be saved and the stale prefix can simply be adverti
sed for a period of ND_VALID_LIMIT.</t>
</list>
</t>
</list>
</t>
<t>CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid-lifetime MUST a
dvertise the corresponding sub-prefixes (as they would be generated for the same
leased prefix with a non-zero lifetime) with a PIO with both the Preferred Life
time 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 <x
ref target="lan-lifetimes"/> are employed.</t>
</list>
</t> </t>
<t> <t>
When a CE Router provides LAN-side DHCPv6 (address assignment or prefix delegati The above text refers to the Neighbor Discovery options that are typically
on), then: 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.
</t>
<list style="symbols"> <t>CE routers providing stateful address configuration via DHCPv6
<t>The CE Router SHOULD record, on stable storage, the DHCPv6 address and delega <bcp14>SHOULD</bcp14> set the "preferred-lifetime" of a DHCPv6 IA
ted-prefix bindings corresponding to the LAN-side.</t> Address option to the lesser of the remaining preferred lifetime of
<t>If the CE Router finds that the prefix to be employed for address assignment the corresponding prefix (see <xref target="dhcpv6-pd-slaac"
and/or prefix delegation has changed (e.g., upon a crash-and-reboot event) or th format="default"/>) and ND_PREFERRED_LIMIT, and set the
e CE Router receives DHCPv6 Prefix Delegations with 0 lifetimes, the CE Router M "valid-lifetime" of the same option to the lesser of the remaining
UST: valid lifetime of the corresponding prefix and ND_VALID_LIMIT.
<list style="symbols">
<t>In Replies to DHCPv6 Request, Renew, and Rebind messages, sen
d IA Address Options or IA Prefix Options (as appropriate) for any address assig
nments or prefix delegations for the deprecated prefixes. The aforementioned opt
ions 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 perio
d of ND_VALID_LIMIT if the recommended lifetimes from <xref target="lan-lifetime
s"/> are employed.
</t>
<t>Initiate sending Reconfigure messages (if possible - i.e., cli
ent requests Reconfigure support and the CE Router offers it) to those clients w
ith address assignments or prefix delegations for the deprecated prefixes.
</t>
</list>
</t> </t>
</list> <t>
CE routers providing DHCPv6-PD on the LAN side <bcp14>SHOULD</bcp14> set the
"preferred-lifetime" of a DHCPv6 IA Prefix option to the lesser of the
remaining preferred lifetime of the corresponding prefix (see <xref
target="dhcpv6-pd-slaac" format="default"/>) 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.
</t> </t>
<t>RATIONALE:</t>
<ul spacing="normal">
<li>
<t>The "Valid Lifetime" and "Preferred Lifetime" of PIOs have a
direct impact on three different aspects:
</t>
<ul spacing="normal">
<li>The amount of time hosts may end up employing stale
network configuration information (see <xref
target="RFC8978" format="default"/>).</li>
<li>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).</li>
<li>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.</li>
</ul>
</li>
<li>
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 <bcp14>SHOULD</bcp14> 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.
</li>
<li>
Similarly, CE routers need not employ the (possibly long) WAN-side DHCPv6-PD lif
etimes for the "valid-lifetime" and "preferred-lifetime" of IA Address options a
nd IA Prefix options employed by DHCPv6 on the LAN side, since the renewal of bi
ndings by DHCPv6 clients will lead to the same effective lifetimes as specified
by the WAN-side DHCPv6-PD lifetimes.
</li>
</ul>
<t> </section>
<list style="hanging"> <section anchor="sig-stale-config" numbered="true" toc="default">
<t hangText="RATIONALE:"> <name>Signaling Stale Configuration Information</name>
<list style="symbols"> <t>When a CE router provides LAN-side address-configuration information
via SLAAC:
<t>IPv6 network renumbering is expected to take place in a planne
d 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 the prefix
being employed on a network suddenly becomes invalid and replaced by a new pref
ix <xref target="RFC8978"/>. One such scenario is when a DHCPv6 server employs d
ynamic prefixes
and the Customer Edge Router crashes and reboots. The requirements in this secti
on are meant to allow Customer Edge Routers to deprecate stale information in su
ch scenarios.
</t>
<t>The recommendations in this section expand from requirement L-
13 in Section 4.3 of <xref target="RFC7084"/>, and Section 6.3 of <xref target="
RFC8415"/>.</t>
<t>Host configuring addresses via SLAAC on the local network may </t>
employ addresses configured for the previously advertised prefixes for at most t <ul spacing="normal">
he "Valid Lifetime" of the corresponding PIO of the last received Router Adverti <li>A CE router sending RAs that advertise prefixes belonging to a
sement message. Since Router Advertisement messages may be lost or fail to be re dynamically learned prefix (e.g., via DHCPv6-PD)
ceived for various reasons, Customer Edge Routers need to try to deprecate stale <bcp14>SHOULD</bcp14> record, on stable storage, the list of
prefixes for a period of time equal to the "Valid Lifetime" of the PIO employed prefixes being advertised via PIOs on each network segment and the
when originally advertising the prefix.</t> state of the "A" and "L" flags of the corresponding PIOs.</li>
<li>
<t>Upon changes to the advertised prefixes, and after
bootstrapping, the CE router advertising prefix information via
SLAAC proceeds as follows:
</t>
<ul spacing="normal">
<li>Any prefixes that were previously advertised by the CE
router via PIOs in RA messages, but that have now become stale,
<bcp14>MUST</bcp14> be advertised with PIOs that have the "Valid
Lifetime" and the "Preferred Lifetime" set to 0 and the "A" and
"L" bits unchanged.
</li>
<li>
<t>The aforementioned advertisements <bcp14>MUST</bcp14> be
performed for at least the "Valid Lifetime" previously
employed for such prefixes. The CE router <bcp14>MUST</bcp14>
advertise this information with unsolicited Router
Advertisement messages, as described in <xref target="RFC4861"
sectionFormat="of" section="6.2.4" format="default"/>, and
<bcp14>MAY</bcp14> advertise this information via unicast
Router Advertisement messages when possible and applicable.
<t>The requirement in this section is conveyed as a "SHOULD" (as </t>
opposed to a "MUST"), since the requirement to store information on stable stora <ul spacing="normal" empty="true">
ge may represent a challenge for some implementations.</t> <li>NOTE: If requirement L-16 (<xref target="CPE"
<t>Advertising DHCPv6-leased prefixes with zero lifetimes on the LAN-side would format="default"/>) is followed, the "Valid Lifetime" need
handle the case where a CE Router has no stable storage but receives the prefixe not be saved, and the stale prefix can simply be advertised
s via DHCPv6 with 0 lifetimes.</t> for a period of ND_VALID_LIMIT.</li>
<t>The above text does not include DHCPv6 Advertise messages sent in </ul>
response to DHCPv6 Solicit messages, since Section 18.3.9 of </li>
<xref target="RFC8415"/> requires that a DHCPv6 server </ul>
that is not going to assign an address or delegated prefix received </li>
as a hint in the Solicit message MUST NOT include that address or <li>CE routers receiving DHCPv6 IA Prefix options with a 0
delegated prefix in the Advertise message. Additionally, any "valid-lifetime" <bcp14>MUST</bcp14> advertise the corresponding
subsequent Request messages will trigger the response specified in sub-prefixes (as they would be generated for the same leased prefix
this section, and therefore cause the address or prefix to be with a non-zero lifetime) with PIOs with both the "Preferred
deprecated.</t> 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 <xref
target="lan-lifetimes" format="default"/> are employed.</li>
</ul>
<t>
When a CE router provides LAN-side DHCPv6 (address assignment or
prefix delegation), then:
</list>
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>The CE router <bcp14>SHOULD</bcp14> record, on stable storage,
the DHCPv6 address and delegated-prefix bindings corresponding to
the LAN side.</li>
<li>
<t>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
<bcp14>MUST</bcp14>:
</t>
<ul spacing="normal">
<li>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 <bcp14>MUST</bcp14> 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 <xref target="lan-lifetimes" format="default"/>
are employed.
</li>
<li><t>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.</t>
</li>
</ul>
</li>
</ul>
</section> <t>RATIONALE:</t>
<ul spacing="normal">
<li>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 <xref target="RFC8978"
format="default"/>. 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.
</li>
<li>The recommendations in this section expand from requirement
L-13 in <xref target="RFC7084" sectionFormat="of" section="4.3"
format="default"/> and <xref target="RFC8415"
sectionFormat="of" section="6.3" format="default"/>.</li>
<li>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.</li>
<li>The requirements in this section to store information on
stable storage are conveyed as "<bcp14>SHOULD</bcp14>" (as
opposed to "<bcp14>MUST</bcp14>"), since they may represent a
challenge for some implementations.</li>
<li>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.</li>
<li>The above text does not include DHCPv6 Advertise messages
sent in response to DHCPv6 Solicit messages, since <xref
target="RFC8415" sectionFormat="of" section="18.3.9"
format="default"/> requires that a DHCPv6 server that is not
going to assign an address or delegated prefix received as a
hint in the Solicit message <bcp14>MUST NOT</bcp14> 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.</li>
</ul>
</section>
</section> </section>
<section anchor="parameters" numbered="true" toc="default">
<name>Recommended Option Lifetimes Configuration Values</name>
<ul spacing="normal">
<li>ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)</li>
<li>ND_VALID_LIMIT: 5400 seconds (90 minutes)</li>
</ul>
<section title="Recommended Option Lifetimes Configuration Values" anchor="p <t>RATIONALE:</t>
arameters"> <ul empty="false">
<t> <li>These values represent a trade-off among a number of factors, includi
<list style="symbols"> ng responsiveness and possible impact on the battery life of connected devices <
<t>ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)</t> xref target="RFC7772" format="default"/>.
<t>ND_VALID_LIMIT: 5400 seconds (90 minutes)</t> </li>
</list>
</t>
<t> <li>ND_PREFERRED_LIMIT is set according to the recommendations in
<list style="hanging"> <xref target="RFC7772" format="default"/> for the "Router Lifetime",
<t hangText="RATIONALE:"> following the rationale from <xref target="RFC8978" sectionFormat="of"
<vspace blankLines="0" /> section="3.2" format="default"/>.</li>
These values represent a trade-off among a number of factors, inc
luding responsiveness and possible impact on the battery life of connected devic
es <xref target="RFC7772"/>.
</t>
<t>ND_PREFERRED_LIMIT is set according to the recommendations in
<xref target="RFC7772"/> for Router Lifetime, following the rationale from Secti
on 3.2 of <xref target="RFC8978"/>.</t>
<t>ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide som
e additional leeway before configuration information is finally discarded by the
host.</t>
</list>
</t>
<li>ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some addi
tional leeway before configuration information is finally discarded by the hosts
.</li>
</ul>
</section> </section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<t> <t>
This document has no actions for IANA. This document has no IANA actions.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>This document discusses a problem that may arise in scenarios where dyn <t>This document discusses a problem that may arise, e.g., in scenarios wh
amic IPv6 prefixes are employed, and proposes improvements to Customer Edge Rout ere
ers <xref target="RFC7084"/> to mitigate the problem for residential or small of dynamic IPv6 prefixes are employed, and it proposes improvements to
fice scenarios. It does not introduce new security issues, and thus the same sec CE routers <xref target="RFC7084" format="default"/> to
urity considerations as for <xref target="RFC4861"/>, <xref target="RFC4862"/>, mitigate the problem for residential or small office scenarios. It does
<xref target="RFC7084"/>, and <xref target="RFC8415"/> apply.</t> not introduce new security issues; thus, the same security
considerations as for <xref target="RFC4861" format="default"/>, <xref
</section> target="RFC4862" format="default"/>, <xref target="RFC7084"
format="default"/>, and <xref target="RFC8415" format="default"/>
<section title="Acknowledgments"> apply.</t>
<t>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 det
ailed reviews.
</t>
<t>The authors would like to thank Mikael Abrahamsson, Luis Balbinot, Tim Chown,
Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Gert Doering, Fernando Fr
ediani, Guillermo Gont, Steinar Haug, Nick Hilliard, Lee Howard, Christian Huite
ma, Sheng Jiang, Benjamin Kaduk, Suresh Krishnan, Warren Kumari, Albert Manfredi
, Olorunloba Olopade, Jordi Palet Martinez, Richard Patterson, Pete Resnick, Mic
hael Richardson, Mark Smith, Job Snijders, Sander Steffann, Tarko Tikan, Ole Tro
an, Loganaden Velvindron, Eric Vyncke, Robert Wilton, Timothy Winters, Christoph
er Wood, and Chongfeng Xie, for providing valuable comments on earlier versions
of this document.</t>
<t>Fernando would also like to thank Brian Carpenter who, over the years, has an
swered many questions and provided valuable comments that have benefited his pro
tocol-related work.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-6man-slaac-renum" to="6MAN-SLAAC-RENUM"/>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.8174" ?>
<?rfc include="reference.RFC.4191" ?>
<?rfc include="reference.RFC.8106" ?>
<?rfc include="reference.RFC.8415" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.7772" ?>
<?rfc include="reference.RFC.7844" ?>
</references>
<references title="Informative References"> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4191.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8106.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8415.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4862.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7772.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7844.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7084.xml"/>
<?rfc include="reference.RFC.7084" ?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<?rfc include="reference.I-D.ietf-6man-slaac-renum" ?> .ietf-6man-slaac-renum.xml"/>
<?rfc include="reference.RFC.8978" ?>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8978.xml"/>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Owen DeLong"/>,
<contact fullname= "Philip Homburg"/>, <contact fullname="Erik Kline"/>,
and <contact fullname="Ted Lemon"/> for their valuable help in
improving this document via successive detailed reviews.
</t>
<t>The authors would like to thank <contact fullname="Mikael
Abrahamsson"/>, <contact fullname="Luis Balbinot"/>, <contact
fullname="Brian Carpenter"/>, <contact fullname="Tim Chown"/>, <contact
fullname="Lorenzo Colitti"/>, <contact fullname="Alejandro D'Egidio"/>,
<contact fullname="Gert Doering"/>, <contact fullname="Fernando
Frediani"/>, <contact fullname="Guillermo Gont"/>, <contact
fullname="Steinar Haug"/>, <contact fullname="Nick Hilliard"/>, <contact
fullname="Lee Howard"/>, <contact fullname="Christian Huitema"/>,
<contact fullname="Sheng Jiang"/>, <contact fullname="Benjamin Kaduk"/>,
<contact fullname="Suresh Krishnan"/>, <contact fullname="Warren
Kumari"/>, <contact fullname="Albert Manfredi"/>, <contact
fullname="Olorunloba Olopade"/>, <contact fullname="Jordi Palet
Martinez"/>, <contact fullname="Pete Resnick"/>, <contact
fullname="Michael Richardson"/>, <contact fullname="Mark Smith"/>,
<contact fullname="Job Snijders"/>, <contact fullname="Sander
Steffann"/>, <contact fullname="Tarko Tikan"/>, <contact fullname="Ole
Troan"/>, <contact fullname="Loganaden Velvindron"/>, <contact
fullname="Éric Vyncke"/>, <contact fullname="Robert Wilton"/>, <contact
fullname="Timothy Winters"/>, <contact fullname="Christopher Wood"/>,
and <contact fullname="Chongfeng Xie"/> for providing valuable comments
on earlier draft versions of this document.</t>
<t>Fernando would also like to thank <contact fullname="Brian
Carpenter"/> who, over the years, has answered many questions and
provided valuable comments that have benefited his protocol-related
work.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 88 change blocks. 
491 lines changed or deleted 518 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/