ND Prefix Robustness Improvements
draft-vv-6man-nd-prefix-robustness-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Eduard V , Paolo Volpato , Loba Olopade | ||
| Last updated | 2022-03-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vv-6man-nd-prefix-robustness-02
IPv6 Maintenance (6man) Working Group E. Vasilenko
Internet Draft P. Volpato
Updates: 4861, 4862 (if approved) Huawei Technologies
Intended status: Standards Track Olorunloba Olopade
Expires: September 2022 Virgin Media
March 4, 2022
ND Prefix Robustness Improvements
draft-vv-6man-nd-prefix-robustness-02
Abstract
IPv6 prefixes could become invalid abruptly as a result of outages,
network administrator actions, or particular product shortcomings.
That could lead to connectivity problems for the hosts attached to
the subtended network.
This document has two targets: on one hand, to analyze the cases
that may lead to network prefix invalidity; on the other to develop
a root cause analysis for those cases and propose a solution.
This may bring to extensions of the protocols used to convey prefix
information and other options.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2022.
Expires September 4, 2022 [Page 1]
Internet-Draft ND-prefix-robustness March 2022
Copyright Notice
Copyright (c) 2022 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Terminology and pre-requisite..................................3
2. Introduction...................................................4
3. Problem Scenarios..............................................4
3.1. Reference architectures...................................5
3.2. Discussion on the scenarios...............................5
3.2.1. Non-graceful reload due to unexpected events .........5
3.2.2. Graceful reload without precautions ..................6
3.2.3. Abrupt hardware replacement without the possibility
for graceful prefix deprecation.......................7
3.2.4. Non-graceful configuration change ....................8
3.2.5. An uplink breaks connectivity without a relevant
notification to the connected hosts...................8
4. Root cause analysis...........................................10
4.1. What to protect..........................................10
4.2. Where to protect.........................................12
4.3. When to protect: technology scenarios....................12
5. Solutions.....................................................13
5.1. Multi-homing multi-prefix (MHMP) environment.............13
5.2. A provider is not reachable in MHMP environment..........16
5.3. Administrator abruptly replaces PA prefix................17
5.4. Planned router outage....................................18
5.5. Prefix information lost because of abrupt router outage..19
5.6. Prefix information lost after hardware replacement.......19
5.7. Link layer address of the router should be changed.......20
5.8. Dependency between solutions and extensions..............20
6. Extensions of the existing standards..........................20
Expires September 4, 2022 [Page 2]
Internet-Draft ND-prefix-robustness March 2022
6.1. Default router choice by host............................20
6.2. Prefixes become dynamic..................................21
6.3. Do not forget to deprecate prefixes on renumbering.......22
6.4. Do not forget to deprecate prefixes on shutdown..........23
6.5. Store prefixes in non-volatile memory....................23
6.6. Find lost information by "Synchronization"...............24
6.7. Default router announcement rules........................26
6.8. Faster detection of the stale default router.............26
6.9. Clean orphaned prefixes after default router list change.27
7. Interoperability analysis.....................................27
8. Applicability analysis........................................28
9. Security Considerations.......................................28
10. IANA Considerations..........................................29
11. References...................................................29
11.1. Normative References....................................29
11.2. Informative References..................................30
12. Acknowledgments..............................................31
1. Terminology and pre-requisite
[ND] and [SLAAC] are pre-requisite to understand this document.
The terms are inherited from these standards.
Additional terms:
Home Gateway - a small consumer-grade router that provides network
access between hosts on the local area network (LAN) and the
Internet behind the wide area network (WAN)
PA - Provider-Aggregatable addresses leased to the client or
subscriber
MHMP - Multi-Homing Multi-Prefix. An environment with hosts
connected to different PA providers (multi-homing) through
different address spaces announced from different providers
(multi-prefix)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Expires September 4, 2022 [Page 3]
Internet-Draft ND-prefix-robustness March 2022
2. Introduction
It has been reported that some number of cases could lead to loss of
information (primarily prefixes) by [ND]. Current [ND] protocol's
default timers may lead to many days of outage for hosts. This is
not acceptable.
This document analyses all potential cases when an outage could
happen and proposes solutions. Discussion is restricted to potential
[ND] extensions only.
MHMP environment has been considered. It has been discovered that
[ND] problems could be isolated from the overall complex [MHMP]
environment, and could be fixed separately.
The document is organized to introduce, in section 3, the scenarios
where the issue of prefix invalidity may happen and the cases of
invalidity.
Section 4 provides a root cause analysis for the cases of invalidity
and identifies the corner-cases which are subject of our discussion.
Section 5 proposes a solution for the cases identified.
Section 6 brings the discussion forward, proposing extensions to
[ND].
3. Problem Scenarios
[ND] distributes prefixes as Prefix Information Options (PIOs) in
Router Advertisements (RA) messages from routers.
Once a router assigns a prefix to a host, this prefix is assumed to
be stable so that hosts can employ it to configure the IPv6
addresses associated with their interfaces [SLAAC] or to forward
packets to the network.
Prefix changes may happen and are governed by the rules of [ND],
[SLAAC].
Yet, cases exist where prefix instability may happen. An example is
provided by the so-called "flash-renumbering" event: when flash-
renumbering happens a network prefix in use suddenly becomes invalid
because it is replaced by a new prefix.
Expires September 4, 2022 [Page 4]
Internet-Draft ND-prefix-robustness March 2022
The router causing or forced to cause the network renumbering may
not be able to cope with the effects of this sudden change (for
example, deprecating the previously assigned prefixes). Another
possibility is that the subtended hosts do not have the means of
overcoming the effects of renumbering.
This section describes problems that were found in live networks.
Most of the information in this section comes from [Flash-
Renumbering], [SLAAC Robustness]. Their contributions are greatly
acknowledged.
3.1. Reference architectures
Home broadband networks, SOHO (Small Office Home Office) networks
are the typical scenarios affected by renumbering. Some problems
discussed below applicable on the more general basis.
In typical case a router (e.g. Home Gateway, Customer Premise
Equipment (CPE), Customer Edge (CE), etc.) is deployed to provide
connectivity to a Service Provider network for the attached devices.
A second router may be deployed for redundancy, especially for
business scenarios.
Two reference architecture can be considered:
Architecture #1. Hosts are directly connected to the router. For
example, a Home Gateway embeds the functions of L2 device (Ethernet
switch, WiFi AP) and L3 device (router).
Architecture #2. Hosts connect to an intermediate L2 device (e.g. a
wired Ethernet switch or a Wi-Fi access point) that, in turn,
connects to the router (or routers, if uplink redundancy is
requested).
3.2. Discussion on the scenarios
The discussion provided here is introductory to both the root cause
analysis provided in section 4. and the solutions proposed in
section 5.
3.2.1. Non-graceful reload due to unexpected events
A router could be reloaded abruptly for many reasons: hardware or
software bug, power outage, manual intervention. This last one is
very probable for home broadband subscribers that tend to fix every
problem with power recycle.
Expires September 4, 2022 [Page 5]
Internet-Draft ND-prefix-robustness March 2022
Usually, it does not create additional problems for [ND] and [SLAAC]
because the same PIO information would be advertised by the router
in RA messages after each reload. In such cases, a Home Gateway
would initialize its Ethernet and WiFI connections, clearing all
stale information on directly connected hosts.
It should not create problems for proper home network design where
all CPEs are routers - see [HomeNet Architecture]. The delegated
prefix would not be changed in the case of subtended CPE reload.
Prefix change in the case of upstream CPE reload should be properly
discontinued by subtended CPE. There is the need for a special
protocol for prefix distribution that is out of the scope of this
document - see [HNCP].
For architecture #2 implemented in home environments, there is a
corner case when Home Gateway's abrupt reload would not be visible
to hosts connected to subtended "bridged" CPE. If it would coincide
with the situation when a different prefix would be delegated from
Carrier (at 37% probability according to [Residential practices]),
it would lead to the situation that hosts would receive a new prefix
without deprecation of the previous one. Hosts do not have any
standard mechanism to choose only the new prefix for communication.
That would lead to a connectivity problem.
How long a non-preferred prefix would be kept in a stale state on
the host is not important (default AdvValidLifetime is 30 days in
section 6.2.1 of [ND]), because according to [Default Address]
section 5 rule#3, it should have a lower priority to be chosen.
[SLAAC] section 5.5.4 is another good reference highlighting that
address should be avoided after it would reach the deprecated
status.
How long an address would stay in the preferred state is important.
[ND] instructs hosts to prefer certain prefix for 7 days - see
default AdvPreferredLifetime in section 6.2.1.
It is not realistic for the subscriber to wait for 7 days.
It practically means that the subscriber in this corner case would
have a few options to fix the problem: (1) reload all hosts, or (2)
reconnect the physical link of every host, or (3) reload subtended
bridge, or (4) manually delete the prefix on the hosts to clear
stale information.
3.2.2. Graceful reload without precautions
Specifically this scenario may happen when developers don't apply
precautions in case previous prefixes are not deprecated. It may
happen in both architectures.
Expires September 4, 2022 [Page 6]
Internet-Draft ND-prefix-robustness March 2022
The router could be reloaded by graceful procedure (reboot or
shutdown that would use "init 6" in Unix). It is still possible that
software would not send RA with prefix Preferred Lifetime zero to
inform hosts about prefix deprecation. This practice prevails
because IPv4's centralized address assignments by DHCP does not need
similar precautions.
Again, like in the previous section, it would not create a problem
in the majority of the cases for directly connected hosts
(architecture #1) because link layer would be reinitialized too. The
same corner case (architecture #2) would lead to the same result: a
connectivity problem that could be resolved only by 4 types of
manual intervention mentioned in the previous section.
3.2.3. Abrupt hardware replacement without the possibility for graceful
prefix deprecation
Such type of an outage is again may happen only for architecture #2.
It would lead to up to 30 minutes (including time for hardware
replacement) outage in all cases (to detect missing router) and up
to 1 week additional outage if a different prefix would be announced
after the hardware replacement.
The hardware could fail or be replaced with an abrupt power
disconnect. The latter is very probable for the home environment.
Graceful notification of hosts may not happen.
The new hardware may have a different link layer address and a
different link local address as a result. The router would look like
a new one on the link. Any communication with it could not be the
reason to deprecate announcements made early by the router perceived
as a different one.
[ND] section 6.2.1 has recommended the AdvDefaultLifetime as
3*MaxRtrAdvInterval. Hosts would send traffic to a non-existent
router for up to 30 minutes.
According to section 4.2 of [ND] "Router Lifetime" is related only
to router default status. PIO announced early may be preferred up to
7 days according to AdvPreferredLifetime in section 6.2.1 of [ND]
even after the router default status is deprecated. The probability
for such a situation is the same low as discussed in section 3.2.1.
because a different prefix should be announced after hardware reload
and a switch should be present between the host and the router. The
same corner case would lead to the same result: a connectivity
Expires September 4, 2022 [Page 7]
Internet-Draft ND-prefix-robustness March 2022
problem that could be resolved only by 4 types of manual
intervention mentioned in section 3.2.1. .
3.2.4. Non-graceful configuration change
This situation may happen due to abrupt prefix change on the router
(in both architectures) or VLAN change on the switch (it may happen
in architecture #2).
Router configuration could be changed manually, by automation tools,
or by protocols (for example, prefix distribution).
Additionally for architecture #2, L2 domain could be abruptly
changed by configuration (for example, VLAN change from "quarantine"
to "production" without any chance for the router to send a
message).
It could lead to the situation that prefix would change abruptly,
without any notification to hosts about the necessity to deprecate
the previous prefix. Hosts should be notified by prefix announcement
with Preferred Lifetime set to zero.
It should not happen for residential CPE because [CPE Requirements]
section 4.3 requirement L-13 clearly instructs: "If the delegated
prefix changes, i.e., the current prefix is replaced with a new
prefix without any overlapping period of time, then the IPv6 CE
router MUST immediately advertise the old prefix with a Preferred
Lifetime of zero".
But it is perfectly possible for other environments (except
residential CPEs) because other routers are not required to do the
same: [Node Requirements] does not clarify the exact router behavior
in the case of abrupt prefix change. [SLAAC] does not have any
recommendations either.
3.2.5. An uplink breaks connectivity without a relevant notification
to the connected hosts
It may happen in both architectures #1 and #2.
A router could lose uplink. The probability for such an event is
much bigger for a mobile uplink (modem). It would invalidate the
possibility to use a PA prefix advertised from this carrier even in
the case that another carrier uplink is available on this or
redundant router (connectivity to the Internet is not lost). Some
mechanism is needed to inform hosts not to use address space from
Expires September 4, 2022 [Page 8]
Internet-Draft ND-prefix-robustness March 2022
the disconnected carrier because another carrier would filter it out
by anti-spoofing security protection.
The multi-homing multi-prefix PA environment has been properly
explained in [MHMP]. The discussion of how traffic should be source-
routed by routers in [MHMP] environment is not relevant to our [ND]
discussion. Unfortunately, an improper address used as a source
would cause a traffic drop as soon as traffic gets to the different
carrier.
[Default Address] section 5 (source address selection) rule 5 (for
different interfaces on the host) and rule 5.5 (for the same
interface) partially prepare hosts for such situation: "Prefer
addresses in a prefix advertised by the next-hop. If SA or SA's
prefix is assigned by the selected next-hop that will be used to
send to D [...] then prefer SA". This algorithm has an assumption
that the source address should be chosen after the next hop.
Unfortunately, the rules mentioned above in [Default Address]
section 5 would work only if the default router would cease to be
default after it loses route to its carrier. It would work only in
simplified topology where all hosts connect by L2 to different CPEs,
each leading to its separate carrier prefix. It could be called a
"common-link environment for all hosts and routers". It is not
possible in practice because hosts on the most popular link layer
technology (WiFi) are rooted to only one CPE (with AP inside) - they
would not switch automatically to different CPE where the Internet
connectivity may be still available.
[CPE Requirements] have G-3/4/5 specifically for this simplified
multi-homing residential design. It recommends announcing Router
Lifetime as zero on LAN if CPE does not have "default router from
the uplink" - it would push the host to use another source address
by the mentioned above source address selection algorithm.
It is not explained in [CPE Requirements] what should happen with PA
delegated prefix after the respective uplink is disconnected.
Probably, this is because it was not needed to deprecate stale
prefix for the above mentioned mechanism (based on default router
withdrawal) to work.
The local residential network could be left without any default
router as a result of using the above mechanism - it is especially
probable in the single CPE environment. Hence, [CPE Requirements]
promotes [ULA] addresses for local connectivity. Default router
functionality is returned specifically for [ULA] addresses by
Expires September 4, 2022 [Page 9]
Internet-Draft ND-prefix-robustness March 2022
requirement L-3: use "Route Information Option" from [Route
Preferences]. It needs hosts' participation in routing through the
RIO option.
Unfortunately, this long chain of fixes explained above is strictly
optimized for the environment "common-link for all hosts and
routers". It is not the case for single WiFi inside any CPE or other
topologies.
Neither [ND] nor [SLAAC] instruct the router what to do when the PA
delegated prefix is withdrawn abruptly.
[Multi-Homing] section 3 has a good discussion about the proper
relationship between default routers and prefixes advertised by
respective routers in a stable situation. This would be discussed in
more details in section 5.1. . [Multi-Homing] does not discuss what
to do in the situation when the router is available, but some
uplinks (with delegated prefixes) are lost.
[MHMP] discusses the problem in deep detail with two tools proposed
to regulate [ND] behavior: [Policy by DHCP] to change [Default
Address] algorithm and [Route Preferences] to inform about
appropriate exit points. There are more details later in section
5.1.
4. Root cause analysis
Let's further analyze to be sure that all corner cases are found.
It is assumed in all discussions below that [RA-Guard] is
implemented, and all messages are from routers under legitimate
administrative control. Security issues are considered as resolved
by [RA-Guard], and possibly with extensions in [RA-Guard+].
DHCP is almost as vulnerable as SLAAC for cases found below. DHCP's
typical lease time (hours) is shorter than SLAAC's prefix lifetime
(days), but is too long for users to accept self-repairing time.
Root cause analysis below applies to all possible environments:
DHCP, SLAAC, and mixed.
4.1. What to protect
[ND] Router Advertisements deliver configuration information to
hosts. Such information could become inaccurate in two different
periods of time:
Expires September 4, 2022 [Page 10]
Internet-Draft ND-prefix-robustness March 2022
a) "Recoverable". Time is needed for some process to finish and
update information (example: router reload or uplink re-connect).
b) "Non-recoverable". Time, dependent on some timer expiration
(example: complete loss of prefix or default router).
A careful look at the information distributed by RA would give us
the understanding that the most problematic is the information that
is already protected by deprecation timers: Prefix Information
Option and Default Router. Section 3 discusses that the handling of
this information is still susceptible to recoverable and non-
recoverable periods of inaccuracy.
For example, in the case of abrupt router reload described in
sections 3.2.1. -3.2.3. , the recoverable part is the time spent by
router and hosts to update their cache after the router reload. The
non-recoverable part is related to the setting of the
AdvPreferredLifetime timer which would probably force a user to
solve the issue with manual intervention.
The next problematic case is the abrupt change of source link-layer
address. This problem is not discovered yet in production because it
has a low probability. Indeed, a router with a different link-layer
address would be treated as a new router, the old router would just
disappear from the link. It would affect primarily default router
information because all other information should be immediately re-
advertised from the new link layer address. Section 6.2.8 of [ND]
already discusses how to properly deprecate the default router
status of the old link layer address, but no recommendation is given
in [ND] for prefix deprecation in this situation. A corner case is
possible that software would not treat the new virtual interface as
identical concerning the prefix information that should be
announced. Different prefixes may be announced. Some additional
precautions are needed.
Other information in RA (Hop Limit, MTU, DHCP flags, Reachable
timer, and Retransmit timer) are not so sensitive because (1) it is
typically static and (2) it does not affect connectivity for
respective parameters change in the wide range.
Flag "A" in PIO deserves special attention. It could be cleared
abruptly (signaling that hosts should not use this prefix for
[SLAAC] anymore). That should not create any problem, because the
prefix is still available from a respected PA provider - traffic
could be routed to the global Internet. Therefore, it is not vitally
important for the host to immediately deprecate the address from
Expires September 4, 2022 [Page 11]
Internet-Draft ND-prefix-robustness March 2022
this prefix.
A similar situation is with flag "M" in RA: DHCP address should be
deprecated. It should not create a connectivity problem because
prefixes could be routed to the global Internet.
4.2. Where to protect
[ND] is the protocol for first-hop connection between host and
router. It is designed for one link only. One link could have more
than one router.
It is assumed below that a more complex topology (many other
routers) is shielded from this link by some other protocol that
would deliver all necessary information to those routers.
[HomeNet Architecture] discusses many types of information that
should be distributed to every home router. Let's focus on delegated
prefixes for our discussion.
The number of uplinks on every router is not important, as long as
proper information about prefixes is up to date on the router.
Hence, all our topologies could be simplified into the following
scenarios:
I. L2 device (switch, WiFi AP) and L3 device (router) are in the
same device (sharing the fate for power, reboot) (refer to
architecture #1 in section 3.1. ).
II. Separate L2 device (probably a switch) and an arbitrary number of
L3 devices (routers) are connected to the same IPv6 link (refer
to architecture #2 in section 3.1. ).
4.3. When to protect: technology scenarios
Let's reorder scenarios discussed in section 3. in the way that it
would be better to map to the technology modifications and account
for some corner cases found in root cause analysis:
1. Proper prefix usage for Multi-Homing Multi-Prefix environment.
Hosts should be capable of choosing in a coordinated way
(1) a source address (from proper PA prefix) and (2) a next hop:
A.1. In a normal situation: all providers and prefixes are
available
Expires September 4, 2022 [Page 12]
Internet-Draft ND-prefix-robustness March 2022
A.2. In a faulty situation: one provider is not reachable, but some
hosts and links on the routed path to this provider may still be
reachable
A.3. In the case when an administrator abruptly replaces delegated
prefix
2. Proper prefix usage for the case of router outage that:
A.4. Planned for this interface
(reboot, shutdown, or ceasing to be a router)
A.5. Abrupt (power outage, software or hardware bug)
A.6. Abrupt (power outage, hardware fault) with hardware
replacement
3. Proper prefix usage for the case of link layer address of the
router.
These cases are discussed from section 5.1. to section 5.6.
There is no big difference for [ND] between ULA and GUA at the
considered link because both could be disjoined at any routed hop
upstream. It would need the same invalidation mechanisms on the
link. ULA could be invalidated too for the case that ULA spans many
sites in a big company. The residential network would probably have
a separate ULA for every household that would decrease the
probability of ULA prefixes invalidation. It is the responsibility
of another protocol (for example, [HNCP]) to decide when ULA should
be invalidated, if ever.
5. Solutions
Let's look at the solutions for scenarios listed in section 4.3.
5.1. Multi-homing multi-prefix (MHMP) environment
Let's consider here host capability to choose a proper PA prefix and
next hop router in a stable multi-homing multi-prefix (MHMP)
environment.
Expires September 4, 2022 [Page 13]
Internet-Draft ND-prefix-robustness March 2022
The complex MHMP situation is properly discussed in [MHMP] section
3.1 - it is critical to read it to understand the rest of this
section. Our discussion is restricted to [ND] protocol only (one
link) - it would cut the number of topologies discussed in section
4.2. MHMP may need additional complex routing interactions that are
out of the scope of this document.
It is possible to introduce one additional classification to clearly
separate what it is possible to implement now from what needs
additional standardization efforts:
1. Case "equal prefixes": Announced prefixes are fully equal by
scope and value, all resources interested for hosts could be
reachable through any announced PA prefix; additionally, traffic
distribution between carriers could be round-robin (no any
traffic engineering or policing).
2. Case "non-equal prefixes": Announced prefixes are not equal
because (1) some resources could be accessed only through a
particular prefix (for example walled garden of one carrier) or
(2) it is desirable to have some policy for traffic distribution
between PA prefixes (cost of traffic, delay, packet loss, jitter,
proportional load).
There are two reminders before the discussion of the above cases:
o [ND] section 6.3.6 recommends next hop choice between default
routers in a round-robin style. Traffic policy or even
reachability of particular resources through a particular default
router is not considered at the [ND] level.
o [Default Address] section 7 assumes that source and destination
address selection should happen after the next hop (or interface)
choice by [ND] or routing, source address is chosen after this.
Case "equal prefixes" does not create any requirement on what prefix
should be used for the source address. It is only needed that the
source address would be chosen to be compatible with the next hop
that should be in the direction of the respective carrier.
No problem is possible for the topology with only one router on the
link. The router itself may need source routing to choose next hop
properly but it is out of the scope of ND protocol and this
document.
Host on a multi-homing link would better be compliant to [Default
Address] section 5 (source address selection) rule 5 (for different
interfaces on the host) or rule 5.5 (for different next hops on the
Expires September 4, 2022 [Page 14]
Internet-Draft ND-prefix-robustness March 2022
same interface). It would help to properly choose a source address
compliant to the next hop chosen first. Moreover, if the source
address would be chosen wrongly then it is still possible to reroute
the packet later by source routing.
Hence, it is possible to satisfy the "equal prefixes" case on the
current level of standardization developed.
Case "non-equal prefixes" is more complicated. It would be too late
to try to solve this problem on a router, because the wrong source
address may be already chosen by the host - it would not be possible
to contact the appropriate resource in the "walled garden". Only NAT
could be left as an option, but that is not a valid choice for IPv6.
There are 2 methods to resolve the case of "non-equal prefixes":
1. The same policies could be formatted differently and fed to the
host by two mechanisms: 1) "Routing Information Options" of [Route
Preferences] and 2) [Policy by DHCP] to modify policies in
[Default Address] selection algorithm. Then current priority of
mechanisms could be preserved the same: initially [ND] or routing
would choose the next hop, then [Default Address] would choose a
source address (and destination if multiple answers from DNS are
available). It is the method that is assumed in [MHMP].
2. Alternatively, policies could be supplied only by [Policy by DHCP]
to [Default Address] selection algorithm. [Default Address]
discusses potential capability in section 7 to reverse algorithm's
order: source address may be chosen first, only then to choose
next hop (default router).
Source address selected from proper carrier is potentially the
complete information needed for the host to choose the next hop,
but not for the default round-robin distribution between available
routers that specified in [ND]. [ND] extension is needed for this
method for the host to prioritize default routers that have
announced prefixes used for the source address of the considered
flow.
It is this method that is assumed in [Multi-Homing] section 3.2.
This document is different in that the same rules are formulated
not as the general advice, but as the particular extension to [ND]
- see section 6.1 of this document.
The second method has the advantage that there is no need to
download RIO policies by [Route Preferences]. It would simplify the
implementation of the MHMP environment.
Only the second method is universal and extendable because some
policies may not be translated as RIO of [Route Preferences].
For example, dynamic policies (packet loss, delay, and jitter) could
Expires September 4, 2022 [Page 15]
Internet-Draft ND-prefix-robustness March 2022
be measured on hosts. Hence, the decision about source address and
next hop should be local.
5.2. A provider is not reachable in MHMP environment
Let's assume the fault situation when one provider is not reachable
in the [MHMP] environment. A prefix may be very dynamic for a few
reasons. It could be received from some protocols (DHCP-PD, HNCP).
The prefix could become invalid (at least for the global Internet
connectivity) as a result of the abrupt link loss in the upstream
direction to the carrier that distributed this prefix.
Additionally, consider the more complicated case when some hosts on
the upstream routed path to this provider may still be reachable
using a particular prefix but Internet connectivity is broken later.
Let's consider the last problem. Because Internet connectivity is
lost for this prefix, it should be announced to hosts by zero
Preferred Lifetime. [Route Preferences] gives the possibility to
inform hosts that particular a prefix (RIO) is still available on-
site but it would be an automation challenge to dynamically
calculate and announce prefix. Additionally, [Route Preferences]
should be supported by hosts.
In general, it is not a good idea to involve [ND] in routing. Hence,
it is better to support on-site connectivity by PI GUA or ULA that
may not be invalidated. There are many reasons to promote [ULA] for
internal site connectivity: (1) hosts may not have GUA address at
all without initial connection to the provider, (2) PA addresses
would be invalidated in 30 days of disconnect anyway, (3) it is not
a good idea to use addresses from PA pool that is disconnected from
global Internet - hosts may have a better option to get global
reachability. ULA has better security (open transport ports that are
not accessible from the Internet) which is an additional bonus.
It is effectively the request to join current [CPE Requirements] and
[HomeNet Architecture] requirements in sections 2.2, 2.4, 3.4.2 that
subscriber's network should have local ULA addresses.
Prefix deprecation should be done by RA with zero Lifetime for this
prefix. It will put the prefix on hosts to the deprecated status
that according to many standards ([ND], [SLAAC], and [Default
Address]) would prioritize other addresses. Global communication
would be disrupted for this prefix anyway. Local communication for
deprecated addresses would continue till normal resolution because
the default Valid Lifetime is 30 days. Moreover, if it would happen
that this delegated prefix was the only one in the local network (no
[ULA] for the same reason), then new sessions would be opened on
Expires September 4, 2022 [Page 16]
Internet-Draft ND-prefix-robustness March 2022
deprecated prefix because it is the only address available.
If connectivity would be re-established and the same prefix would be
delegated to the link - it would be announced again with proper
preferred lifetime. If a different prefix could be delegated by the
PA provider, then the old prefix would stay in deprecated status.
It is an advantage for the host that would know about global
reachability on this prefix (by deprecated status) because the host
may use other means for communication at that time.
Such dynamic treatment of prefixes may have the danger of [ND]
messages flood if the link on the path to PA provider would be
oscillating.
[HNCP] section 1.1 states: "it is desirable for ISPs to provide
large enough valid and preferred lifetimes to avoid unnecessary HNCP
state churn in homes".
It makes sense to introduce dampening for the rate of prefix
announcements.
Such conceptual change in the treatment of prefixes would not affect
current enterprise installations where prefixes are static.
It is important to mention again that it is the responsibility of
the respective protocol (that has delivered prefix to the considered
router) to inform the router that prefix is not routed anymore to
the respective carrier. It is easy to do it in the simplified
topology when the only router could correlate uplink status with the
DHCP-PD prefix delegated early. Some additional protocols like
[HNCP] are needed for a more complex topology.
There is nothing in [ND] or [SLAAC] that prevents us from treating
prefixes as something more dynamic than "renumbering" to reflect the
dynamic path status to the PA provider. Section 6.2. proposes
extensions to [CPE Requirements] and [SLAAC] that follow the logic
of this section.
5.3. Administrator abruptly replaces PA prefix
This is the case when the network administrator (maybe from another
domain) replaces prefix much faster than 2 hours or the remaining
preferred lifetime (as per section 5.5.3 of [SLAAC] on router
advertisement processing). The reason for abrupt replacement is
probably not related to networking.
Abrupt prefix change may be caused by improper configuration, for
example, VLAN change at the switch.
Standards recommend deprecating old prefixes but do not recommend
for developers and system designers to additionally check abrupt
Expires September 4, 2022 [Page 17]
Internet-Draft ND-prefix-robustness March 2022
configuration changes to mitigate human mistakes. IPv4 cannot
mitigate such type of mistake, IPv6 has an advantage here.
Section 6.3. proposes a recommendation for the additional check to
make sure that prefix would be deprecated.
This problem could be exacerbated by the low reliability of
multicast delivery in a wireless environment - the only packet sent
(for example before VLAN change) could be lost. A long-term solution
for this problem is proposed in section 6.6 that permits
synchronizing host states with a new flag in router announcements.
5.4. Planned router outage
A router could be planned to be put out of service for a link
(reboot, shutdown, or ceasing to be a router).
The primary Operating System for routers is LINUX. The following
discussion is based on LINUX as an example - other developers can
find an analogy for their operating system.
Some LINUX shutdown commands are not graceful in principle (like
Halt or Poweroff). It would need extraordinary efforts to send
messages discussed in this section before the system would be
stopped. It is better to restrict network administrators from such
tools on routers.
Other LINUX shutdown commands are safe (Reboot is safe for a long
time, Shutdown and "Init 6" have been safe). It would execute
shutdown scripts that would give the developer the chance to comply
with requirements in this section.
It is up to the developer how reboot and shutdown should be mapped
to particular OS commands in graphical user interface (GUI), command
line interface (CLI), or automation interface (Netconf/YANG), and
what particular actions should be taken. It SHOULD guarantee that
section 6.2.5 of [ND] with updates in section 6.4 of this document
properly inform hosts that the router is going out of service.
The same procedure SHOULD be automatically activated for cases when
an administrator tries manually (via CLI or GUI) or automatically
(via Netcong/YANG/Other) to change Link Layer Address on this router
interface or disable router functionality in [ND] for this link.
Expires September 4, 2022 [Page 18]
Internet-Draft ND-prefix-robustness March 2022
5.5. Prefix information lost because of abrupt router outage
PIO could be lost because of the abrupt reload - the router may not
have a chance to warn hosts, but the router could receive a
different prefix after reload. Reasons could be (1) power outage,
(2) software bug, or (3) hardware problem.
[HomeNet Architecture] section 3.4.3 (Delegated Prefixes) has
already recommended usage of non-volatile memory:
"Provisioning such persistent prefixes may imply the need for stable
storage on routing devices and also a method for a home user to
'reset' the stored prefix should a significant reconfiguration be
required (though ideally the home user should not be involved at
all)".
[SLAAC] section 5.7 has recommended storing acquired addresses on
hosts in non-volatile memory too.
This document joins these requests and propose adding similar
requirements to [CPE Requirements] and [SLAAC] - see section 6.5.
The best long-term solution is to inform the host by [ND] protocol
that RA has all information in one announcement. Any missing
information SHOULD be considered deprecated. It is possible to do it
with the new flag in RA - see section 6.6.
"Complete" flag would become useful only when implemented on both:
host and router. It is proposed to rely on storage improvements in
non-volatile memory till the "Complete" flag would be supported on
many hosts.
5.6. Prefix information lost after hardware replacement
Hardware fault or power outage may follow by hardware replacement.
Prefix storage in non-volatile memory and a "complete" flag would
not protect in such a situation. The new router would not have the
old prefix information and the "complete" flag would be sourced from
a different LLA.
Initially, it would be good to speed up the detection of hardware
replacement to delete the stale hardware from the default router
list of hosts. It is proposed to request all routers availability by
RS all-routers multicast address after new router detection on the
link- see section 6.8. It would permit to detect that old hardware
is not active in 13 seconds (see section 6.3.7 of [ND] for timers
MAX_RTR_SOLICITATIONS * RTR_SOLICITATION_INTERVAL +
MAX_RTR_SOLICITATION_DELAY). 13 seconds is considered a short enough
outage compare to hardware replacement and reload.
Expires September 4, 2022 [Page 19]
Internet-Draft ND-prefix-robustness March 2022
Then it is proposed to detect stale prefixes at the event of the
respective router deletion from the default router list. If the
particular prefix is not announced anymore by any active router on
the default router list then the prefix (and all associated
addresses) should be deprecated - see section 6.9.
5.7. Link layer address of the router should be changed
Sections 6.3 and 6.4 provide an additional check also in the case
of a link layer address change. Hence, additionally resolve LLA
change case.
5.8. Dependency between solutions and extensions
It could be useful to map, for quick reference, the dependency
between the solutions listed in this section and standard's
extensions as presented in section 6.
Solution discussed in Corresponding extension
5.1. -> 6.1.
5.2. -> 6.2. & 6.7.
5.3. -> 6.3. & 6.6.
5.4. -> 6.4.
5.5. -> 6.5. & 6.6.
5.6. -> 6.8. & 6.9.
5.7. -> 6.3. & 6.4.
6. Extensions of the existing standards
The solution requires a number of standard extensions. They are
split into separate sections for better understanding. It is better
to read references from section 5. before reading this section, see
section 5.8. for cross-reference.
6.1. Default router choice by host
* Section 6.3.6 (Default Router Selection) of [ND], add an initial
policy to default router selection:
Expires September 4, 2022 [Page 20]
Internet-Draft ND-prefix-robustness March 2022
0) For the cases when a particular implementation of ND does know
the source address at the time of default router selection
(it means that source address was chosen first),
then default routers that advertise the prefix for respective
source address SHOULD be preferred over routers that do not
advertise respective prefix.
6.2. Prefixes become dynamic
* This document joins the request to [CPE Requirements] that has
been proposed in section 11 (General Requirements for HNCP Nodes) of
[HNCP]:
The requirement L-13 to deprecate prefixes is applied to all
delegated prefixes in the network from which assignments have been
made on the respective interface. Furthermore, the Prefix
Information Options indicating deprecation MUST be included in
Router Advertisements for the remainder of the prefixes' respective
valid lifetime, but MAY be omitted after at least 2 hours have
passed.
* Add section 4.2 into [SLAAC]:
4.2 Dynamic Link Renumbering
Prefix delegation (primarily by DHCP-PD) is adopted by the industry
as the primary mechanism of PA address delegation in the fixed and
mobile broadband environments, including cases of small business and
branches of the big enterprises.
The delegated prefix is tied to dynamic link that has a considerable
probability to be disconnected, especially in a mobile environment.
The delegated prefix is losing the value if the remote site is
disconnected from prefix provider - this fact should be propagated
to all nodes on the disconnected site, including hosts. Information
Options indicating deprecation (multicast RA with zero Preferred
Lifetime) MUST be sent at least one time. It SHOULD be included in
Router Advertisements for the remainder of the prefixes' respective
valid lifetime but MAY be omitted after 2 hours of deprecation
announcements.
There is a high probability that connectivity to the provider would
be restored very soon then the prefix could be announced again to
all nodes on the site.
Expires September 4, 2022 [Page 21]
Internet-Draft ND-prefix-robustness March 2022
There is the probability that in a small period of time the same
problem would disconnect the site again (especially for mobile
uplink). Such oscillation between available and not available
provider could happen frequently that would flood the remote site
with [ND] updates.
Dampening mechanism MAY be implemented to suppress oscillation:
if the time between a particular prefix announcement and previous
deprecation was less than DampeningCheck then delay the next prefix
announcement for DampeningDelay and check the need for the prefix
announcement after DampeningDelay seconds.
It is recommended for protocol designers to implement a dampening
mechanism for protocols (like [HNCP]) that would be used to
distribute prefix delegation inside the site to relieve the majority
of site routers and the protocol itself from the processing of
oscillating messages.
* Section 5.1 (Node Configuration Variables) of [SLAAC], add timers:
DampeningCheck - the time between prefix announcement and previous
deprecation is checked against this value to decide about
dampening need. The timer should use 16bit unsigned integer
measured in seconds. The default value is 10 seconds.
DampeningDelay - the delay (penalty) for the next attempt to
announce the same prefix again. The timer should use 16bit
unsigned integer measured in seconds. The default value is
10 seconds.
These timers should be configurable like all other timers in [SLAAC]
section 5.1.
6.3. Do not forget to deprecate prefixes on renumbering
* Section 4.1 (Site renumbering) of [SLAAC], add at the end:
A network administrator SHOULD avoid the situations when renumbering
is done abruptly (with the time of transition that is less than the
preferred time for the respective prefix). Situations could happen
when it is not possible to archive the above-mentioned goal: (1) the
prefix could be withdrawn by the administrator of another domain,
(2) there could be the urgent need to change the prefix for reasons
not related to networking, (3) prefix could be invalidated after
some network event (example: loss of uplink that was used to receive
this prefix), (4) L2 connection (VLAN or VPN) could be changed
Expires September 4, 2022 [Page 22]
Internet-Draft ND-prefix-robustness March 2022
abruptly by mistake or due to not a proper design.
Prefix deprecation MUST be signaled at least one time by multicast
RA with Preferred Lifetime set to zero for respective PIO. It SHOULD
be included in RA for the remainder of the prefixes' respective
valid lifetime but MAY be omitted after 2 hours of deprecation
announcements.
It is recommended for developers to check and enforce this rule in
router's software: if an administrator, automated system, or other
protocol would try to delete a particular prefix from the link and
if that prefix has the preferred lifetime bigger than zero, then the
software MUST automatically generate deprecation announcements
according to the rules explained above.
System designer SHOULD make sure that in the case of abrupt change
of logical connectivity at L2 (VLAN, VPN) new default router SHOULD
deprecate stale prefixes inherited from the previous default router.
6.4. Do not forget to deprecate prefixes on shutdown
* Section 6.2.5 of [ND] starts from the definition of ceasing cases
for the router on [ND] link. One additional reason SHOULD be added
to the end of the list:
- Link layer address of the interface should be changed.
* Section 6.2.5 (Ceasing To Be an Advertising Interface) and
Section 6.2.8 (Link Local Address Change) of [ND] already discusses
requirements of proper ceasing to be [ND] router advertising
interface. It has requirements to announce zero for a default router
lifetime. It is proposed to add at the end of both sections:
A router MUST also announce in above-mentioned announcements all
previously advertised prefixes with zero Preferred LifeTime. Valid
LifeTime should not be decreased from originally intended - current
hosts sessions should have the possibility to be rerouted to the
redundant router (if available).
6.5. Store prefixes in non-volatile memory
Add the same text:
* [CPE Requirements], new requirement G-6 at the end of section 4.1,
and
* [SLAAC], at the end of section 5.7:
Expires September 4, 2022 [Page 23]
Internet-Draft ND-prefix-robustness March 2022
The IPv6 router SHOULD keep in non-volatile memory all prefixes
advertised on all links, including prefixes received by dynamic
protocols with the reference to the respective protocol (DHCP-PD,
HNCP, others).
A router could experience a non-graceful reload.
If another protocol would delegate any prefixes for router links
then the router SHOULD immediately start announcing them in the
normal way.
Additionally, the router should wait until the end of convergence
for the respective prefix-delegation protocol. The way for how to
decide that convergence is finished is the responsibility of the
respective protocol design. It could be a simple timer after uplink
would go to "up" or successful exchange by some protocol (like DHCP-
PD).
If another protocol would not delegate prefix recorded in non-
volatile memory after assumed convergence is achieved, then the old
prefix MUST be announced on the link at least one time by multicast
RA with the zero Preferred Lifetime. It SHOULD be included in RA for
the remainder of the prefixes' respective valid lifetime but MAY be
omitted after 2 hours of deprecation announcements.
6.6. Find lost information by "Synchronization"
* Section 4.2 (RA format) of [ND], introduce new flag:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved|C| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
O 1-bit "Complete configuration" flag. When set, it
indicates that all configuration information has been put
inside this RA. The last reserved bit has been chosen to
preserve the compatibility with [Route Preferences] that
already propose to use the first reserved bit.
Expires September 4, 2022 [Page 24]
Internet-Draft ND-prefix-robustness March 2022
* Section 6.2.3 (RA content) of [ND], introduce new flag:
- In the C flag: set if it was possible to put all configuration
information into this RA.
* Section 6.2.3 (RA content) of [ND], add at the end:
It is recommended that all configuration information SHOULD be
included in one RA (if MTU permits) for multicast and unicast
distribution. If successful, then the "Complete" flag SHOULD be set
to signal the possibility of synchronization with hosts.
* Section 6.3.4 (RA processing) of [ND], add at the beginning:
After: "the receipt of a Router Advertisement MUST NOT invalidate
all information received in a previous advertisement or from another
source".
Add: "Except for the case when RA received with "Complete" flag set,
then any information from the same router (same Link Local Address)
missing in this RA SHOULD be deprecated. Information protected by
timers SHOULD be put into the deprecated state. Other information
SHOULD be returned to the original state: in compliance to
information from other routers or to default configuration if other
routers do not announce respected information."
* Section 6.3.4 (RA processing) of [ND], add to the list of PIO
processing options:
- If the prefix is missing in RA with the "Complete" flag set, then
respective addresses should be put immediately into deprecated state
up to the original valid lifetime.
[ND] section 9 mentions: "In order to ensure that future extensions
properly coexist with current implementations, all nodes MUST
Expires September 4, 2022 [Page 25]
Internet-Draft ND-prefix-robustness March 2022
silently ignore any options they do not recognize in received ND
packets and continue processing the packet."
There is a possibility for the gradual introduction of the
"Complete" flag:
o If the host is upgraded to the new functionality first, then the
router would send this bit zero (according to the basic [ND])
that would not activate new functionality on the host.
o If the router is upgraded to the new functionality first, then
the host would not pay attention to the flag for Reserved bits.
6.7. Default router announcement rules
* This document joins [HNCP] section 11 (General Requirements for
HNCP Nodes) request to [CPE Requirements]:
The generic requirements G-4 and G-5 are relaxed such that any known
default router on any interface is sufficient for a router to
announce itself as the default router; similarly, only the loss of
all such default routers results in self-invalidation.
6.8. Faster detection of the stale default router
* Section 6.3.7 (sending Router Solicitations) of [ND].
The text: "When an interface becomes enabled, a host may be
unwilling to wait for the next unsolicited Router Advertisement to
locate default routers or learn prefixes. To obtain Router
Advertisements quickly, a host SHOULD transmit up to
MAX_RTR_SOLICITATIONS Router Solicitation messages, each separated
by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations
may be sent after any of the following events:"
Should be replaced by the text: "
Interface enablement or new router arrival could be the signal of
router replacement, a host may be unwilling to wait for the next
unsolicited Router Advertisement to locate and invalidate default
routers or learn prefixes. To obtain Router Advertisements quickly,
a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
Solicitation messages, each separated by at least
RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent
after any of the following events:
Expires September 4, 2022 [Page 26]
Internet-Draft ND-prefix-robustness March 2022
- the new router is discovered from RA
- . . . <list of other reasons>
"
* Section 6.3.7 (sending Router Solicitations) of [ND].
After the text: "If a host sends MAX_RTR_SOLICITATIONS
solicitations, and receives no Router Advertisements after having
waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last
solicitation, the host concludes that there are no routers on the
link for the purpose of [ADDRCONF]."
Add new text: "If a host sends MAX_RTR_SOLICITATIONS solicitations,
and receives no Router Advertisements from the router already
present on the default router list after having waited
MAX_RTR_SOLICITATION_DELAY seconds, the host concludes that the
router SHOULD be deprecated from the default router list."
6.9. Clean orphaned prefixes after default router list change
* Section 6.3.6 (Timing out Prefixes and Default Routers) of [ND]
has:
"Whenever the Lifetime of an entry in the Default Router List
expires, that entry is discarded. When removing a router from the
Default Router list, the node MUST update the Destination Cache in
such a way that all entries using the router perform next-hop
determination again rather than continue sending traffic to the
(deleted) router."
Add at the end:
"All prefixes announced by deprecated default router SHOULD be
checked on the announcement from other default routers. If any
prefix is not anymore announced from any router - it SHOULD be
deprecated."
7. Interoperability analysis
The primary motivation for the proposed changes originated from
residential broadband requirements. [ND] extensions proposed in this
document should not affect other environments (enterprise WAN,
Expires September 4, 2022 [Page 27]
Internet-Draft ND-prefix-robustness March 2022
Campus). Moreover, some precautions proposed could block mistakes
originated by humans in some corner cases in all environments.
This document mostly intersects with Homenet working group documents
[HomeNet Architecture], [HNCP], and [MHMP]. It was shown that it is
possible to isolate [ND] in the context of Homenet to solve specific
[ND] problems without any potential impact to the Homenet
development and directions.
[CPE Requirements] have the assumption of managing simplified
topologies by manipulating routing information injection into [ND].
It has been shown in [MHMP] and in this document that it is better
to signal reachability information to [ND] (reachability information
to ND sounds strange) by the deprecation of delegated prefixes. This
document joins [MHMP] request to change the approach.
[Route Preferences] have been avoided as the mechanism for
environments with PA address space because source address is
selected first. Then next hop choice can be simplified - see section
5.1 for more details.
[Route Preferences] could still be applicable for PI (Provider-
Independent) address environments because only next hops need to be
chosen properly.
8. Applicability analysis
Two standard extensions require changes to hosts. Hence, it would
take a long time to be implemented in live networks. But workaround
exists for the solution to work before it would happen:
o Absence of implementation for RA information synchronization by C
flag on some hosts is not critical because router could use non-
volatile memory for prefix storage.
o Not being capable of excluding a router from the default router
list (for the situation when it does not advertise respective
prefix) is not critical, because it is needed only for the very
advanced MHMP environment with traffic distribution by the policy
between different PA providers.
It is for the far future anyway.
9. Security Considerations
This document does not introduce new vulnerabilities.
Expires September 4, 2022 [Page 28]
Internet-Draft ND-prefix-robustness March 2022
10. IANA Considerations
This document has no any request to IANA.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
editor.org/info/rfc4861>.
[SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI
10.17487/RFC4862, September 2007, <https://www.rfc-
editor.org/info/rfc4862>.
[Route Preferences] R. Draves, D. Thaler, "Default Router
Preferences and More-Specific Routes", RFC 4191, DOI
10.17487/RFC4191, November 2005, <https://www.rfc-
editor.org/info/rfc4191>.
[Multi-Homing] F. Baker, B. Carpenter, "First-Hop Router Selection
by Hosts in a Multi-Prefix Network", RFC 8028, DOI
10.17487/RFC8028, November 2016, <https://www.rfc-
editor.org/info/rfc8028>.
[NUD improvement] E. Nordmark, I. Gashinsky, "Neighbor
Unreachability Detection Is Too Impatient", RFC 7048, DOI
10.17487/RFC7048, July 2010, <https://www.rfc-
editor.org/info/rfc7048>.
[Default Address] D. Thaler, R. Draves, A. Matsumoto, T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
Expires September 4, 2022 [Page 29]
Internet-Draft ND-prefix-robustness March 2022
[Node Requirements] T. Chown, J. Loughney, T. Winters, "IPv6 Node
Requirements", RFC 8504, DOI 10.17487/RFC8504, January
2019, <https://www.rfc-editor.org/info/rfc8504>.
[CPE Requirements] Singh, H., Beebee W., Donley, C., and B. Stark,
"Basic Requirements for IPv6 Customer Edge Routers", RFC
7084, DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[HomeNet Architecture] T. Chown, J. Arkko, A. Brandt, O. Troan, J.
Weil, "IPv6 Home Networking Architecture Principles", RFC
7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>.
[HNCP] M. Stenberg, S. Barth, P. Pfister, "Home Networking Control
Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016,
<https://www.rfc-editor.org/info/rfc7788>.
[Policy by DHCP] A. Matsumoto, T. Fujisaki, T. Chown, "Distributing
Address Selection Policy Using DHCPv6", RFC 7078 DOI
10.17487/RFC7078, January 2014, <https://www.rfc-
editor.org/info/rfc7078>.
[Residential practices] Palet, J., "IPv6 Deployment Survey
Residential/Household Services) How IPv6 is being
deployed?", UK NOF 39, January 2018,
<https://indico.uknof.org.uk/event/41/contributions/542/at
tachments/712/866/bcop-ipv6-prefix-v9.pdf>.
[SLAAC Robustness] F. Gont, J. Zorz, R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-ietf-6man-slaac-renum-
02 (work in progress), January 2021
11.2. Informative References
[RFC8200] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, DOI 10.17487/RFC8200,
July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[Flash-Renumbering] F. Gont, J. Zorz, R. Patterson, "Reaction of
Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events", RFC 8978, March 2021.
Expires September 4, 2022 [Page 30]
Internet-Draft ND-prefix-robustness March 2022
[RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI
10.17487/RFC6105, February 2011, <https://www.rfc-
editor.org/info/rfc6105>.
[RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113, DOI
10.17487/RFC7113, February 2014, <https://www.rfc-
editor.org/info/rfc7113>.
[MHMP] O. Troan, D. Miles, S. Matsushima, T. Okimoto, D. Wing, "IPv6
Multihoming without Network Address Translation", RFC
7157, DOI 10.17487/RFC7157, March 2014, <https://www.rfc-
editor.org/info/rfc7157>.
[ULA] R. Hinden, B. Haberman, "Unique Local IPv6 Unicast Addresses",
RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
12. Acknowledgments
Thanks to 6man working group for problem discussion.
Authors' Addresses
Olorunloba Olopade
Virgin Media
270 & 280 Bartley Way, Bartley Wood Business Park, Hook,
Hampshire RG27 9UP
Email: Loba.Olopade@virginmedia.co.uk
Eduard Vasilenko
Huawei Technologies
17/4 Krylatskaya st, Moscow, Russia 121614
Email: vasilenko.eduard@huawei.com
Paolo Volpato
Huawei Technologies
Via Lorenteggio 240, 20147 Milan, Italy
Email: paolo.volpato@huawei.com
Expires September 4, 2022 [Page 31]