Internet DRAFT - draft-vv-6man-nd-support-mhmp

draft-vv-6man-nd-support-mhmp



IPv6 Maintenance (6man) Working Group                      E. Vasilenko
Internet Draft                                               P. Volpato
Updates: 4861, 4862, 6724 (if approved)             Huawei Technologies
Intended status: Standards Track                         March 26, 2023
Expires: September 2023





          Neighbor Discovery support for Multi-home Multi-prefix
                     draft-vv-6man-nd-support-mhmp-02


Abstract

   Multi-home Multi-prefix (MHMP) IPv6 environment is the norm for
   businesses that need to have uplink resiliency.
   Several solutions have been already discussed and proposed to
   address MHMP and how it can be enabled in different network
   contexts. This draft looks at MHMP from the perspective of Neighbour
   Discovery Protocols (NDP).

   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




                      Expires September 26, 2023               [Page 1]

Internet-Draft           ND-prefix-robustness                March 2023


   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 2023.

Copyright Notice

   Copyright (c) 2023 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...................................................3
   3. The NDP analysis in MHMP.......................................5
   4. Solution for the case "equal prefixes".........................7
   5. Solution for the case "non-equal prefixes".....................8
   6. Resolution for a not-reachable provider.......................10
   7. Extensions of the existing standards..........................12
      7.1. Preference to choose source address before the next hop..12
      7.2. Default router choice by host............................13
      7.3. Prefixes become dynamic..................................13
      7.4. Default router announcement rules........................15
      7.5. Clean prefixes for the changed default router list.......15
   8. Interoperability analysis.....................................15
   9. Security Considerations.......................................16
   10. IANA Considerations..........................................16
   11. References...................................................16
      11.1. Normative References....................................16
      11.2. Informative References..................................17
   12. Acknowledgments..............................................18





                      Expires September 26, 2023               [Page 2]

Internet-Draft           ND-prefix-robustness                March 2023


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:

  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.

                               +------+      _________
                               |      |     /         \
                           +---| CPE1 |----/  Carrier  \
                           |   |      |\   \     1     /
               +------+    |   +------+ \   \_________/
               |      |    |             \
               | Host |----+              \
               |      |    |               \
               +------+    |   +------+     \_________
                           |   |      |     /         \
                           +---| CPE2 |----/  Carrier  \
                               |      |    \     2     /
                               +------+     \_________/

      Figure 1: The basic Multi-Homing Multi-Prefix topology




                      Expires September 26, 2023               [Page 3]

Internet-Draft           ND-prefix-robustness                March 2023


   Such a scenario is identified as Multi-Home Multi-Prefix (MHMP) and
   properly discussed in [MHMP] and [MHMP Enterprise] which discuss
   many possible topologies.

   IPv4 is solving such a scenario by independent NAT translation on
   every CPE to the Carrier in combination with private address space
   on site. [IPv6] is capable to avoid NAT.

   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 (DA), a
   host proceeds with the selection of the other parameters necessary
   for sending the packet following the algorithm assumed in [Default
   Address].

   This process determines the Next-Hop (NH) router used for forwarding
   the outgoing packet and its Source Address (SA).

   In MHMP scenarios though a host may experience difficulties to
   determine the "right" SA given the NH router selected to
   communicate. If the network prefix chosen for the SA does not belong
   to the address space advertised by the selected NH router, the
   result is the packet to be filtered out at the ingress of the
   Carrier.

   As explained further in the next sections, two aspects may lead a
   host to select the "wrong" SA.

   A first issue may depend on the lack of support for specific
   functions, such as Rule 5.5 of the SA selection process [Default
   Address] (select a prefix advertised by the NH router) or adoption
   of [Conditional PIO] (use a router advertisement to influence the
   host in the selection of SA).

   A second aspect is related to the complexity of the communication
   service a host may wish to use. This may include destinations



                      Expires September 26, 2023               [Page 4]

Internet-Draft           ND-prefix-robustness                March 2023


   located in controlled environments (e.g. a "walled garden"), or
   reachable via traffic policy (e.g. imposing a low-latency path). The
   network prefixes advertised to the host in these cases have to be
   handled with special care.

   This draft looks at the possibilities provided by Neighbor Discovery
   Protocols (NDP) to solve the MHMP issues. The reason to analyze
   these possibilities is that NDP is key to IPv6 and may offer a
   general solution.

   The next section introduces the rationale for analyzing NDP to solve
   the MHMP issues. Sections 4 and 5 dig further into the relevant
   cases for which NDP may be useful. Section 6 deals with how to
   handle a non-reachable provider. Section 7 proposes some extensions
   to the existing NDP. Section 8 deals with aspects related to
   interoperability.

3. The NDP analysis in MHMP

   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:

   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 the source address first
     (more optimal strategy recommended here).

   Both need some corrections to the [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).




                      Expires September 26, 2023               [Page 5]

Internet-Draft           ND-prefix-robustness                March 2023


   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:

   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 a 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:



                      Expires September 26, 2023               [Page 6]

Internet-Draft           ND-prefix-robustness                March 2023


   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.).

4. 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.

   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
   which 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 the 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.




                      Expires September 26, 2023               [Page 7]

Internet-Draft           ND-prefix-robustness                March 2023


   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 the
   improvement 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.

5. 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 have already been chosen by the
   host - it would not be possible to contact the appropriate resource
   in the "walled garden" or filter for any other purpose.
   Additionally, the wrong choice of source address would not permit
   traffic engineering and host reaction to network quality of
   services.

   [Provisioning domains] is the capability to virtualize router on the
   link, i.e. present many virtual routers (one per domain) with
   different parameters. It is possible to do it explicitly (different
   options specifically developed for virtualization) or implicitly
   (emulate many LLAs on the router). It does not help to resolve the
   MHMP problem because different virtual routers are equal to physical
   routers. It is still a problem if the host would choose initially
   the virtual router looking to the next hop because then the host
   would be restricted for prefixes advertised only from this router
   which may prevent the host to reach the destination or greatly
   affect the quality of communication.

   Currently, there are two standardized 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 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



                      Expires September 26, 2023               [Page 8]

Internet-Draft           ND-prefix-robustness                March 2023


     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.
  2. Application developers may use bind() to choose a source address
     based on many different parameters (including anything from the
     list below). It would effectively revert the default logic of
     [Default Address]. Unfortunately, it is difficult to expect it
     from the client side, which would probably call getaddrinfo()
     which has a good probability to choose the wrong source address.

  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:

  3. Policies could be supplied by [Policy by DHCP] only to the
     [Default Address] selection algorithm. This method has a low
     probability of implementation because of not wide support of
     DHCPv6 in the industry. This method may be more accepted in the
     future.
  4. 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.
  5. The host could use DNS requests with different source addresses to
     understand what is visible for a particular source address.
  6. URL for configuration information could be supplied in RA - see
     [Provisioning domains].
  7. 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.

  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



                      Expires September 26, 2023               [Page 9]

Internet-Draft           ND-prefix-robustness                March 2023


  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
  general advice, but as a particular extension to [ND] and [Default
  Address] - see section 7. of this document.

6. 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 a particular 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 which 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
   [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



                      Expires September 26, 2023              [Page 10]

Internet-Draft           ND-prefix-robustness                March 2023


   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 the global
   reachability of 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 7.3.  proposes
   extensions to [CPE Requirements] and [SLAAC] that follow the logic
   of this section.








                      Expires September 26, 2023              [Page 11]

Internet-Draft           ND-prefix-robustness                March 2023


7. 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.

7.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 September 26, 2023              [Page 12]

Internet-Draft           ND-prefix-robustness                March 2023


   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."

7.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.

7.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 fixed and
   mobile broadband environments, including cases of small businesses
   and branches of 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 value if the remote site



                      Expires September 26, 2023              [Page 13]

Internet-Draft           ND-prefix-robustness                March 2023


   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 which 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 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 16-bit 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 16-
           bit 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 September 26, 2023              [Page 14]

Internet-Draft           ND-prefix-robustness                March 2023


7.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.

7.5. Clean prefixes for the changed default router list

   * Section 6.3.5 (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 the 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."

8. Interoperability analysis

   This document mostly intersects with Homenet working group documents
   [HomeNet Architecture], [HNCP], and [MHMP]. This document simplifies
   the discussion in the [MHMP] solution of updating two 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 September 26, 2023              [Page 15]

Internet-Draft           ND-prefix-robustness                March 2023


   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, the [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.

9. Security Considerations

   This document does not introduce new vulnerabilities.

10. IANA Considerations

   This document has no 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>.



                      Expires September 26, 2023              [Page 16]

Internet-Draft           ND-prefix-robustness                March 2023


   [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>.

11.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 September 26, 2023              [Page 17]

Internet-Draft           ND-prefix-robustness                March 2023


   [Conditional PIO] J. Linkova, M. Stucchi, "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>.

12. 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 September 26, 2023              [Page 18]