Neighbor Discovery support for Multi-home Multi-prefix
draft-vv-6man-nd-support-mhmp-00
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 | ||
| Last updated | 2022-07-01 | ||
| 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-support-mhmp-00
IPv6 Maintenance (6man) Working Group E. Vasilenko
Internet Draft P. Volpato
Updates: 4861, 4862, 6724 (if approved) Huawei Technologies
Intended status: Standards Track July 1, 2022
Expires: January 2023
Neighbor Discovery support for Multi-home Multi-prefix
draft-vv-6man-nd-support-mhmp-00
Abstract
Multi-home Multi-prefix IPv6 environment is the norm for businesses
that need to have uplink resiliency.
For any considered destination, the MHMP challenge may be split into
3 sub-challenges (important to solve in the below order):
1) the host should choose the proper source address for the packet,
2) the host should choose the best default router as the next-hop,
3) site topology may be complicated and may need the source routing
through the site.
This draft is concerned with the solution for the first two problems
that need improvement for the ND (RFC 4861) SLAAC (RFC 4862) and
Default Address Selection (RFC 6724). The last problem is considered
as properly discussed by Multihoming in Enterprise (RFC 8678).
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 January 2021.
Expires January 1, 2023 [Page 1]
Internet-Draft ND-prefix-robustness July 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..................................2
2. Introduction...................................................3
3. Solution for the case "equal prefixes".........................5
4. Solution for the case "non-equal prefixes".....................6
5. Resolution for a not reachable provider........................8
6. Extensions of the existing standards..........................10
6.1. Preference to choose source address before the next-hop..10
6.2. Default router choice by host............................11
6.3. Prefixes become dynamic..................................11
6.4. Default router announcement rules........................13
6.5. Clean orphaned prefixes after default router list change.13
7. Interoperability analysis.....................................13
8. Security Considerations.......................................14
9. IANA Considerations...........................................14
10. References...................................................14
10.1. Normative References....................................14
10.2. Informative References..................................15
11. Acknowledgments..............................................16
1. Terminology and pre-requisite
[Default Address], [ND], and [SLAAC] are pre-requisite to
understanding this document.
The terms are inherited from these standards.
Additional terms:
Expires January 1, 2023 [Page 2]
Internet-Draft ND-prefix-robustness July 2022
PA - Provider-Aggregatable addresses leased by the Carrier to the
client or subscriber
PI - Provider-Independent addresses received from some Regional
Internet Registry
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.
2. Introduction
Businesses usually have multiple network connections with different
service providers to guarantee network resiliency. Such a scenario
is identified as Multi-Home Multi-Prefix (MHMP) and properly
discussed in [MHMP], [MHMP Enterprise].
An MHMP site may have a complex architecture in [IPv6], potentially,
with many links and routers (CPEs) connected to different carriers.
CPEs may receive different Provider Aggregatable (PA) prefixes from
the upstream carriers.
Hosts located in an MHMP environment may also have multiple
different addresses assigned to their interfaces that come from
multiple delegations (from different carriers).
This may create challenges when a host located in an MHMP
environment wishes to communicate with a certain destination. Such a
host typically receives the list of destination addresses from DNS
sorted by [Default Address]. Knowing the destination address, a host
proceeds with the selection of the other parameters necessary for
sending the packet.
The desired destination address is the pre-request for the
discussion of this document, as pointed out in [Default Address].
This document does not change the way how destination addresses are
sorted by [Default Address] or [Happy Eyeballs] rather it analyzes
the options once the destination address is selected:
Expires January 1, 2023 [Page 3]
Internet-Draft ND-prefix-robustness July 2022
1. choose next-hop first (current practice for clients that prevail
in MHMP environment; servers probably use bind() to choose source
address but the server side is not relevant to the discussion
because it typically has Provider Independent addresses),
or
2. choose source address first
(more optimal strategy recommended here).
Both need some corrections to [ND] and [Default Address] selection.
In some cases, these choices may create issues, in particular when a
faulty situation occurs (e.g. network prefixes invalidity due to
loss of connectivity or abrupt CPE reconfiguration). During such
events, a host may find it difficult to establish communication with
a destination if the proper next-hop or source address is not
selected, for example, due to the packet filtering policies applied
by the upstream carriers (for anti-spoofing).
So, overall the association between a destination address, the next-
hop, and the source address in an MHMP environment may be
challenging.
The MHMP challenge may be split into 3 sub-challenges (important to
solve in the below order):
1) the host should choose the proper source address for the packet
by [Default Address],
2) the host should choose the best default router as the next-hop
[ND] (not strictly mandatory, may be fixed later by the source
routing with some loss of efficiency),
3) despite the assumed good choice for the default router selection,
site topology may be complicated and as a result, may need the
source routing through the site anyway - see [MHMP Enterprise].
It is important to point out that the challenge of selecting the
next-hop and source address exists for every desired destination.
There are two reminders before the discussion for solutions:
Expires January 1, 2023 [Page 4]
Internet-Draft ND-prefix-robustness July 2022
o [ND] section 6.3.6 recommends the 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 (and a few other places) assumes that
source address selection should happen after the next-hop (or
interface) choice by [ND].
Before digging into the discussions, it is worth noticing that:
o This document has put NAT (including NPT) out of consideration.
The attempt is here to get fully transparent E2E connectivity.
o This document assumes PA environment only, PI (Provider
Independent) address space needs BGP connection to Carrier that
does not create a problem to solve from the technology point of
view but it creates an enormous problem of scalability for the
Internet with tens of millions of routes.
It is possible to introduce one additional classification to
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 non-predictable (no
traffic engineering or policy).
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, etc.).
3. Solution for the case "equal prefixes"
This use case is potentially possible to operate without any changes
to standardization but it would be not optimal (because currently
next-hop is chosen first) and would need additional functionality on
routers and hosts anyway (rule 5.5 of [Default Address],
[Conditional PIO], source routing). Let's discuss the current
standardization situation.
Expires January 1, 2023 [Page 5]
Internet-Draft ND-prefix-robustness July 2022
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.
There are 4 potential scenarios possible in respect of the next-hop
choice:
1. A single router on the link does not create a choice for the host
in principle. If the site is complex (multi-hop) then the router
itself may need source routing to choose next-hop properly, it is
considered resolved and properly discussed in [MHMP Enterprise].
2. A Host on a multi-homing link would be better compliant with
[Default Address] section 5 (source address selection) rule 5
(for different interfaces on the host) and rule 5.5 (for
different next-hops on the same interface). It would help to
properly choose a source address compliant with the next-hop
chosen first.
3. [MHMP Enterprise] proposes a substitution for rule 5.5 absence on
hosts by [Conditional PIO] that should not leave a choice to host
for what source address to choose.
4. If the source address would be chosen wrongly (because of no
support for rule 5.5 of [Default Address] and no support for
[Conditional PIO]) then it is still possible to reroute the
packet later by source routing proposed in [MHMP Enterprise].
Albeit, the performance would be affected by pushing traffic
through redundant routing hop.
The reversal of choice to source address first would permit to
improve of the functionality (see next section) and simplify the
"equal prefixes" case because it is much easier to choose next-hop
after source address by simply excluding default routers that do not
advertise particular PIOs.
4. Solution for the case "non-equal prefixes"
This case is more complicated. It is not fully resolved yet in the
standardization. It is the primary motivation for the development of
this document.
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" or filtered for any other purpose. Additionally, the
Expires January 1, 2023 [Page 6]
Internet-Draft ND-prefix-robustness July 2022
wrong choice for source address would not permit traffic engineering
and host reaction to network quality of services.
Currently, there is only one standardized method to resolve the case
of "non-equal prefixes":
1. The same policies could be formatted differently and fed to the
host by two mechanisms at the same time: 1) "Routing Information
Options" of [Route Preferences] and 2) [Policy by DHCP] to modify
policies in [Default Address] selection algorithm. Then the
current priority of mechanisms could be preserved the same:
initially [ND] or routing would choose the next-hop, then [Default
Address] would choose a proper source address. It is the method
that is assumed in [MHMP]. This method is complicated and costly,
and the probability of acceptance is very low. Moreover, [Policy
by DHCP] was not adopted by the market - it is not available on
the major operating systems and home gateways.
Alternatively, [Default Address] section 7 discusses the potential
capability to reverse the decision's order: source address may be
chosen first, only then to choose next-hop (default router). Then
many additional methods are possible for how to choose a source
address first:
2. Only policies could be supplied by [Policy by DHCP] to the
[Default Address] selection algorithm. This method has a low
probability of implementation because of not wide support of
DHCPv6 in the industry. Maybe this method would have more
acceptance in the future.
3. It is possible to check the longest match between the source and
the destination address to choose the potentially closest address.
This method looks most promising, it is partially discussed in
[Default Address] section 7.
4. The host could use DNS requests with different source addresses to
understand what is visible for a particular source address.
5. URL for configuration information could be supplied in RA - see
[Provisioning domains].
6. The host may have local performance management capabilities
(packet loss, delay, jitter, etc) to choose the best source for
the application.
It is possible to have other methods for how the host could decide
locally on the best source address as its first decision. This
document is readily extensible in this direction.
Expires January 1, 2023 [Page 7]
Internet-Draft ND-prefix-robustness July 2022
The source address selected from the proper carrier is the complete
information needed for the host to choose the next-hop, but it needs
improvement of [ND] and [Default Address].
[ND] default round-robin distribution between available routers
should be extended for the host to prioritize default routers that
have announced prefixes used for the source address of the
considered packet.
Section 7 of [Default Address] should be extended and recommended
for hosts to support MHMP.
This document's proposals are inspired by [Multi-Homing] section
3.2. The difference is that the same rules are formulated not as the
general advice, but as a particular extension to [ND] and [Default
Address] - see section 6. of this document.
5. Resolution for a not reachable provider
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 problem. Because Internet connectivity is lost
for this prefix, it should be announced to hosts with 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 the 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 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 within 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
Expires January 1, 2023 [Page 8]
Internet-Draft ND-prefix-robustness July 2022
[HomeNet Architecture] requirements in sections 2.2, 2.4, 3.4.2 that
the 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 the
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 the 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 flooding if the link on the path to the 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 the prefix to the
considered router) to inform the router that the 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.3. proposes
extensions to [CPE Requirements] and [SLAAC] that follow the logic
of this section.
Expires January 1, 2023 [Page 9]
Internet-Draft ND-prefix-robustness July 2022
6. Extensions of the existing standards
The solution is about several standard extensions that are needed to
fulfill the solutions discussed above. They are split into separate
sections for better understanding.
6.1. Preference to choose source address before the next-hop.
* Section 7 (Interactions with routing) of [Default Address] has at
the beginning:
"This specification of source address selection assumes that routing
(more precisely, selecting an outgoing interface on a node with
multiple interfaces) is done before source address selection.
However, implementations MAY use source address considerations as a
tiebreaker when choosing among otherwise equivalent routes."
Replace the above text with the text:
"This specification of source address selection did assume that
routing (more precisely, selecting an outgoing interface on a node
with multiple interfaces) is done after source address selection.
MHMP support strongly demands choosing the source address first.
Hence, an implementation SHOULD change the preference to source
address choice first. There are a few methods below for how to
choose a source address for any particular destination. The list is
not exhaustive - it should be augmented later. The implementation
MAY develop their method for choosing source address first."
The next 2 paragraphs of the original RFC 6724 should be preserved.
The one is about choosing the source address that has the longest
much with the destination address. Another one is equivalent to the
methods proposed in [Conditional PIO].
Add 4 new methods for source address choice at the end of the
section:
"The [Default Address] policy table may be updated by [Policy by
DHCP] to guide source address selection.
The implementation may generate DNS requests from an address of
every IPv6 PIO available to make sure that a particular source
address has the reachability to the resource (split DNS may be
implemented for "walled garden").
Expires January 1, 2023 [Page 10]
Internet-Draft ND-prefix-robustness July 2022
URL for configuration information could be supplied in RA - see
[Provisioning domains].
The host may have local performance management capabilities (packet
loss, delay, jitter, etc) to choose the best source for the
application."
6.2. Default router choice by host
* Section 6.3.6 (Default Router Selection) of [ND], add an initial
policy to default router selection:
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 the source address was chosen first),
then default routers that advertise the prefix for the respective
source address SHOULD be preferred over routers that do not
advertise the respective prefix.
6.3. 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 businesses
and branches of the big enterprises.
The delegated prefix is tied to a 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
Expires January 1, 2023 [Page 11]
Internet-Draft ND-prefix-robustness July 2022
site is disconnected from the 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.
There is the probability that in a small period the same problem
would disconnect the site again (especially for mobile uplink). Such
oscillation between available and not available providers could
happen frequently that would flood the remote site with [ND]
updates.
A 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
the dampening need. The timer should use a 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 a 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.
Expires January 1, 2023 [Page 12]
Internet-Draft ND-prefix-robustness July 2022
6.4. 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.5. 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
This document mostly intersects with Homenet working group documents
[HomeNet Architecture], [HNCP], and [MHMP]. This document simplifies
the discussed in the [MHMP] solution of updating 2 tables on the
host (routing and default address selection policy) by reversing the
choice for the source address first.
[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 the host by the deprecation of
delegated prefixes. This document joins [MHMP] request to change the
approach.
Expires January 1, 2023 [Page 13]
Internet-Draft ND-prefix-robustness July 2022
This document does not contradict in any way to [Conditional PIO] or
[MHMP Enterprise] that explain in detail the "equal prefixes" case
but expend MHMP solution to the "non-equal prefixes" case.
[Happy Eyeballs] are sorting destination addresses. The proposals of
this document are coming into the discussion after the destination
addresses are chosen. Hence, [Happy Eyeballs] operation is not
impacted.
[Route Preferences] have been avoided as the mechanism for
environments with PA address space because it is better to select
the source address first for the more general case.
[Route Preferences] could still be applicable for PI (Provider-
Independent) address environments where only next-hops need to be
chosen properly.
8. Security Considerations
This document does not introduce new vulnerabilities.
9. IANA Considerations
This document has no request to IANA.
10. References
10.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>.
Expires January 1, 2023 [Page 14]
Internet-Draft ND-prefix-robustness July 2022
[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>.
[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>.
[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>.
[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>.
[MHMP Enterprise] F. Baker, C. Bowers, J. Linkova, "Enterprise
Multihoming Using Provider-Assigned IPv6 Addresses without
Network Prefix Translation: Requirements and Solutions",
RFC 8678 DOI 10.17487/RFC8678, December 2019,
<https://www.rfc-editor.org/info/rfc8678>.
[Provisioning domains] P. Pfister, E. Vyncke, T. Pauly, D. Schinazi,
W. Shao, " Discovering Provisioning Domain Names and
Data", RFC 8801 DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/info/rfc8801>.
[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>.
10.2. Informative References
[IPv6] 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>.
[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>.
Expires January 1, 2023 [Page 15]
Internet-Draft ND-prefix-robustness July 2022
[Conditional PIO] J. Linkova, M. Stucch, "Using Conditional Router
Advertisements for Enterprise Multihoming", RFC 8475 DOI
10.17487/RFC8475, October 2018, <https://www.rfc-
editor.org/info/rfc8475>.
[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>.
[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>.
[Happy Eyeballs] D. Schinazi, T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, DOI
10.17487/RFC8305, April 2016, <https://www.rfc-
editor.org/info/rfc8305>.
[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>.
11. Acknowledgments
Thanks to the 6man working group for problem discussion.
Authors' Addresses
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 January 1, 2023 [Page 16]