IPv6 Operations (v6ops) Working Group                           X. Xiao
Internet Draft                                             E. Vasilenko
Intended status: Informational                      Huawei Technologies
Expires: January 2024                                           E. Metz
                                                                    KPN
                                                              G. Mishra
                                                           Verizon Inc.
                                                            N. Buraglio
                                                Energy Sciences Network
                                                           July 9, 2023

   Selectively Isolating Hosts to Prevent Potential Neighbor Discovery
                   Issues and Simplify IPv6 First-hops
                  draft-ietf-v6ops-nd-considerations-02


Abstract

   Neighbor Discovery (ND) is a key protocol of IPv6 first-hop. ND uses
   multicast extensively and trusts all hosts. In some scenarios like
   wireless networks, multicast can be inefficient. In other scenarios
   like public access networks, hosts may not be trustable.
   Consequently, ND has potential issues in various scenarios. The
   issues and the solutions for them are documented in more than 30
   RFCs. It is difficult to keep track of all these issues and
   solutions. Therefore, an overview is useful.

   This document firstly summarizes the known ND issues and
   optimization solutions into a one-stop reference. Analyzing these
   solutions reveals an insight: isolating hosts is effective in
   preventing ND issues. Five isolation methods are proposed and their
   applicability is discussed. Guidelines are described for selecting a
   suitable isolation method based on the deployment scenario. When ND
   issues are prevented with a proper isolation method, the solutions
   for these issues are not needed. This simplifies the IPv6 first-
   hops.

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





Xiao                   Expires January 9, 2024                 [Page 1]


Internet-Draft            nd-considerations                   July 2023


   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 in Jan. 2024.

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. Introduction...................................................3
      1.1. Terminology...............................................4
   2. Review of ND Issues............................................6
      2.1. Multicast Causes Performance and Reliability Issues.......6
      2.2. Trusting-all-hosts Causes On-link Security Issues.........7
      2.3. Router-NCE-on-Demand Causes Forwarding Delay, NCE Exhaustion
      and Lack of Subscriber Management Issues.......................7
      2.4. Summary of ND Issue.......................................8
   3. Review of ND Solutions.........................................9
      3.1. ND Solution in Mobile Broadband IPv6......................9
      3.2. ND Solution in Fixed Broadband IPv6......................10
      3.3. Unique IPv6 Prefix per Host..............................11
      3.4. Wireless ND and Subnet ND................................12
      3.5. Scalable Address Resolution Protocol.....................12
      3.6. ARP and ND Optimization for Transparent Interconnection of
      Lots of Links (TRILL):........................................13
      3.7. Proxy ARP/ND in EVPN.....................................13
      3.8. Gratuitous Neighbor Discovery............................13
      3.9. Reducing Router Advertisements...........................14
      3.10. Source Address Validation Improvement and Router
      Advertisement Guard...........................................14




Xiao                   Expires January 9, 2024                 [Page 2]


Internet-Draft            nd-considerations                   July 2023


      3.11. Dealing with Off-link Attack that May Cause Router NCE
      Exhaustion....................................................14
      3.12. Enhanced DAD............................................15
      3.13. ND Mediation for IP Interworking of Layer 2 VPNs........15
      3.14. ND Solutions Defined before the Latest Versions of ND...16
         3.14.1. SeND...............................................16
         3.14.2. Cryptographically Generated Addresses (CGA)........16
         3.14.3. ND Proxy...........................................16
         3.14.4. Optimistic DAD.....................................17
      3.15. Observations on the Solutions...........................17
   4. Selectively Isolating Hosts to Prevent Potential ND Issues and
   Simplify IPv6 First-hops.........................................20
      4.1. Applicability of Subnet Isolation with P2P Link..........22
      4.2. Applicability of Subnet Isolation with P2MP Link.........23
      4.3. Applicability of Subnet Isolation with Shared Medium.....23
      4.4. Applicability of Proxy Isolation.........................24
      4.5. Applicability of GUA Isolation...........................24
      4.6. Guidelines for Selecting a Host Isolation Method.........24
      4.7. Impact of Host Isolation on Other Protocols in IPv6 First-
      hops..........................................................28
   5. Security Considerations.......................................28
   6. IANA Considerations...........................................28
   7. References....................................................29
      7.1. Informative References...................................29
   8. Acknowledgments...............................................32

1. Introduction

   Neighbor Discovery [ND] is specified in RFC 4861. It defines how
   hosts and routers in the link interact with each other. ND contains
   seven main procedures:

     1. Hosts generate Link Local Addresses (LLAs) and use multicast
        Neighbor Solicitations (NSs) for Duplicate Address Detection
        (DAD).
     2. Hosts send multicast Router Solicitations (RSs) to discover
        first-hop routers. Routers respond with unicast Router
        Advertisements (RAs) with subnet prefixes for the link and
        other information. Routers also send unsolicited multicast RAs
        from time to time.
     3. Hosts form Global Unicast Address (GUA) or Unique Local Address
        (ULA) and use multicast Neighbor Solicitations (NSs) for DAD.
     4. When a packet is to be sent, routers use multicast NSs to
        perform address resolution for the destination host.
     5. When a packet is to be sent to a destination that is determined
        to be on link, hosts use multicast NSs to perform address



Xiao                   Expires January 9, 2024                 [Page 3]


Internet-Draft            nd-considerations                   July 2023


        resolution for the destination host, and forward the packet to
        their default router otherwise.
     6. Hosts/routers use unicast NS for Node Unreachability Detection
        (NUD).
     7. Hosts may use multicast NSs to announce link layer address
        changes.

   Due to multicast, trusting all hosts, etc, ND has potential issues
   in some scenarios. Various ND issues and solutions for them have
   been described in more than 30 RFCs. These include: ND Trust Models
   and Threats [RFC3756], Secure ND [SeND], Cryptographically Generated
   Addresses [CGA], ND Proxy [RFC4389], Optimistic ND [RFC4429], ND for
   mobile broadband [RFC6459][RFC7066], ND for fixed broadband [TR177],
   ND Mediation [RFC6575], Operational ND Problems [RFC6583], Wireless
   ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929][SND], DAD Proxy
   [RFC6957], Source Address Validation Improvement [SAVI], Router
   Advertisement Guard [RA-Guard][RA-Guard+], Enhanced Duplicate
   Address Detection [RFC7527], Scalable ARP [RFC7586], Reducing Router
   Advertisements [RFC7772], Unique Prefix Per Host [RFC8273], ND
   Optimization for TRILL [RFC8302], Gratuitous Neighbor Discovery
   [GRAND], Proxy ARP/ND for EVPN [RFC9161]. It is difficult to
   understand all these issues and solutions, and how they fit
   together. If IPv6 deployers are not fully informed before their
   deployment, they may encounter problems later and question IPv6's
   value. This document summarizes the potential issues and solutions
   to provide a clear picture. It also provides guidelines for
   preventing the issues as much as possible and for selecting
   solutions for the remaining issues.

   Due to the potential ND issues, there have been efforts over the
   years to redesign the ND protocol to solve the issues. But because
   ND has already been widely deployed, redesigning ND is difficult and
   such efforts have not been widely accepted. Therefore, providing
   operations guidelines to avoid the issues is a practical alternative
   for IPv6 deployers.

1.1. Terminology

   Some important terms are defined in this section.

  MAC -    To avoid confusion with Link Local Address (LLA), link
           layer address is called MAC in this document.

  Subnet isolation for hosts - assigning a unique prefix per host so
           that each host is in its own subnet [RFC8273].




Xiao                   Expires January 9, 2024                 [Page 4]


Internet-Draft            nd-considerations                   July 2023


  P2P link isolation - connecting each host in a P2P link to the
           router. The router has a separate interface for each host.
           Consequently, any L2 message from a host can only reach the
           router, and any L2 message from the router can only reach
           one host.

  P2MP link isolation - connecting multiple hosts in a P2MP link to
           the router. The router has a single interface for all hosts.
           Example P2MP links are Private VLAN [PVLAN] and Wi-Fi with
           Wireless Isolation [W-Iso].  Consequently, any L2 message
           from a host can only reach the router, not other hosts. But
           an L2 multicast message from the router can reach multiple
           hosts simultaneously.

   Proxy isolation - using an ND proxy device to represent the hosts
           behind it. There are two kinds of proxies, bridging and
           routing. When receiving an address resolution message for a
           host, a bridging proxy either passes the message to the host
           or directly answer with the host's MAC. In comparison, a
           routing proxy [WiND][SND] always terminates the address
           resolution messages and replies with its own MAC address.
           Consequently, a bridging proxy will forward packets to the
           destination hosts at L2 based on the destination hosts' MAC
           addresses (i.e. bridging), while a routing proxy will
           receive packets on its own MAC address and then forward the
           packets at L3 to the destination hosts (i.e. routing). From
           a host isolation perspective, bridging proxies have no
           isolating effect while routing proxies effectively isolate
           different groups of hosts behind the proxies into different
           broadcast/multicast domains. In this document, proxy
           isolation refers to routing proxy isolation.

  GUA isolation - setting PIO L-bit=0 so that other hosts appear off-
           link [ND]. There will be no GUA address resolution for other
           hosts in the link, and all GUA traffic will be sent via the
           router. Therefore hosts appear isolated from a GUA
           perspective. This is also applicable to ULA but to be
           simple, it is also called GUA Isolation in this document.








Xiao                   Expires January 9, 2024                 [Page 5]


Internet-Draft            nd-considerations                   July 2023


2. Review of ND Issues

2.1. Multicast Causes Performance and Reliability Issues

   ND uses multicast for Node Solicitations (NSs), Node Advertisements
   (NAs)Router Solicitations (RSs) and Router Advertisements (RAs).
   Multicast can be inefficient in some scenarios, e.g. large L2
   networks or wireless networks.

   In large L2 networks, e.g. DC networks involving many Virtual
   Machines (VMs), ND multicast can create a large amount of protocol
   traffic. This can consume network bandwidth, create a processing
   burden, and reduce network performance [RFC7342].

   In wireless networks, to ensure that the multicast messages reach
   even the remotest hosts, multicast messages are sent at the lowest
   modulation rate. This prolongs channel occupancy and consumes more
   power of the hosts. Some low-power or remote hosts may not receive
   or respond to multicast messages. In addition, multicast messages
   are not acknowledged at L2. Consequently, multicast in wireless
   networks reduces not only network performance but also protocol
   reliability [RFC9119]. For example, ND uses no response as an
   indication of no duplication in Duplicate Address Detection (DAD).
   If the DAD multicast messages are lost, DAD will not work properly.

   ND uses multicast in the following messages. Multicast impact on
   performance and reliability is summarized below:

     . Hosts' LLA DAD: may cause a performance issue, and a
        reliability issue in wireless networks.
     . Router's periodic unsolicited RAs: may cause performance issue
        if it is sent frequently [RFC7772].
     . Hosts' GUA (or ULA) DAD: may cause a performance issue, and a
        reliability issue in wireless networks.
     . Router's address resolution for hosts: in a large L2 network of
        N hosts, there can be N such multicast messages. This may cause
        a performance issue.
     . Hosts address resolution for hosts: in a large L2 network of N
        hosts, there can be N-square such multicast messages. This may
        cause the largest performance issue.
     . Hosts' MAC change NAs: this type of multicast messages is rare
        and will not cause a performance issue. It will not be further
        discussed.

   Multicast originated from hosts and routers will be called host
   multicast and router multicast hereafter.



Xiao                   Expires January 9, 2024                 [Page 6]


Internet-Draft            nd-considerations                   July 2023


2.2. Trusting-all-hosts Causes On-link Security Issues

   ND trusts all hosts. In some scenarios like public access networks,
   some hosts may not be trustable. An attacker host in the link can
   cause the following security issues [RFC3756][RFC9099]:

     . Source IP address spoofing: an attacker can use a victim host's
        IP address as the source address of its ND message to pretend
        to be the victim. The attacker can then launch Redirect or
        Denial of Service (DoS) attacks on the victim.
     . DAD denial: an attacker can repeatedly reply to a victim's DAD
        messages, causing the victim's address configuration procedure
        to fail, and resulting in a denial of service to the victim
        host.
     . Forged RAs: an attacker can send RAs to other hosts to claim to
        be a router and preempt the real router, resulting in a
        Redirect attack.
     . Forged Redirects: an attacker can pretend to be the router and
        send Redirects to other hosts to redirect their traffic to the
        router to itself, resulting in a Redirect attack.
     . Replay attacks: an attacker captures valid ND messages and
        replays them later.

2.3. Router-NCE-on-Demand Causes Forwarding Delay, NCE Exhaustion and
   Lack of Subscriber Management Issues

   In ND, a router does not maintain (IP, MAC) binding (i.e. Neighbor
   Cache Entry or NCE) for a host until it is needed. This is called
   Router-NCE-on-Demand. When a router is to forward a packet to a
   host, it will perform address resolution to find the MAC of the
   host. This can cause multiple issues:

     . The packet has to be buffered before the router finds out the
        MAC of the host. This delays forwarding and depending on the
        router's buffer size may also cause packet loss. This is called
        "Router-NCE-on-Demand Forwarding Delay" in this document.
     . The way ND performs address resolution is the source node will
        create an NCE entry first and set its state to INCOMPLETE, the
        node will then multicast NSs to all the nodes and wait for the
        destination node to reply with its MAC. This creates a security
        vulnerability.  If an attacker sends a large number of packets
        destined to non-existing IP addresses to a router, the router
        will create a large amount of NCEs in INCOMPLETE state while
        trying to resolve the MACs. The router may run out of resources
        and stop functioning. This is called "NCE Exhaustion" in this




Xiao                   Expires January 9, 2024                 [Page 7]


Internet-Draft            nd-considerations                   July 2023


        document. Note that in this case, the attacker can be off-link.
        So this is different from the on-link security issues.
          o  To prevent this NCE Exhaustion problem, some
             implementations limit the maximal number of NCEs a router
             will maintain for each host. When a host uses more IPv6
             addresses than the limit, irregular packet drops may
             result at the router because the router does not maintain
             NCEs for all those IPv6 addresses [Collink]. This can be
             considered as a special flavor of NCE Exhaustion issue.
     . Without an NCE, a router does not know the IP address of a host
        when SLAAC is used rather than [DHCPv6]. In a service provider
        network, subscribers are generally managed by their IP
        addresses. Consequently, if the router does not know a host's
        IP address, the service provider cannot manage the subscriber.
        This is an issue for public access networks.

2.4. Summary of ND Issue

   The ND issues discussed in Sections 2.1 to 2.3 are summarized below.
   It is worth noting that these issues originate from three causes:
   multicast, trusting all hosts and Router-NCE-on-Demand. If a cause
   can be eliminated, the corresponding issues will also be eliminated.
   This points out the directions for ND optimization.

     . Performance issues caused by multicast
          o LLA DAD degrading performance
          o Unsolicited RA degrading performance
          o GUA/ULA DAD degrading performance
          o Router address resolution for hosts degrading performance
          o Host Address resolution for other hosts degrading
             performance
          o Host MAC change announcement degrading performance (minor
             issue, no further discussion)
     . Reliability issues caused by multicast
          o LLA DAD not reliable for wireless networks
          o GUA/ULA DAD not reliable for wireless networks
     . On-link security issues caused by trusting all hosts
          o Source IP address spoofing
          o DAD denial
          o Forged RAs
          o Forged Redirects
          o Replay attacks
     . Off-link attack and other issues caused by Router-NCE-on-Demand
          o Router NCE exhaustion
          o Router forwarding delay
          o Lack of subscriber management using ND with SLAAC



Xiao                   Expires January 9, 2024                 [Page 8]


Internet-Draft            nd-considerations                   July 2023


   It is worth noting that these are just potential issues. Depending
   on the usage scenarios, they may not actually happen. More
   specifically:

     . Performance issues caused by multicast only happens in large L2
        networks. If one's usage scenario is not a large L2 network,
        one needs not be concerned.
     . Reliability issues caused by multicast only happens in wireless
        networks.
     . On-link security issues caused by trusting all hosts are non-
        issues if hosts can be trusted.
     . Off-link attack and other issues caused by Router-NCE-on-Demand
        will not happen if one already deployed an ND-optimized
        solution that installs NCE proactively, e.g. RFC 8273.

   When the above issues can happen, it is advisable to be aware of the
   solutions available for them described in the next section.

3. Review of ND Solutions

   This section reviews the ND optimization solutions developed over
   the years so that network administrators can get an idea of what
   solutions are available for which issues. The solutions are reviewed
   in an order that helps to reveal a theme: isolating hosts can help
   to prevent ND issues.

3.1. ND Solution in Mobile Broadband IPv6

   Mobile Broadband IPv6 (MBBv6) is defined in "IPv6 in 3GPP EPS"
   [RFC6459], "IPv6 for 3GPP Cellular Hosts" [RFC7066], and "Extending
   an IPv6 /64 Prefix from a Third Generation Partnership Project
   (3GPP) Mobile Interface to a LAN Link" [RFC7278]. The solution key
   points are:

     . Putting every host, i.e. the mobile User Equipment (UE), in a
        P2P link with the router, i.e. the mobile gateway. MBBv6 also
        simplifies ND to take advantage of this P2P architecture. As a
        result:
          o All multicast is effectively turned into unicast
          o The P2P links in MBB do not have link layer address.
             Therefore, Router-NCE-on-Demand is not needed.
          o Trusting-all-host is only relevant to the router. By
             applying some filtering at the router, e.g. dropping RAs
             from the host, even malicious hosts cannot cause security
             harm.




Xiao                   Expires January 9, 2024                 [Page 9]


Internet-Draft            nd-considerations                   July 2023


     . Assigning a unique /64 prefix to each host. Together with the
        P2P link, this puts each host in a separate link and subnet.
     . Maintaining (prefix, interface) binding at the router for
        forwarding purpose.

   Since all the three causes of ND issues are addressed, MBBv6 solves
   all ND issues.

3.2. ND Solution in Fixed Broadband IPv6

   FBBv6 is defined in "IPv6 in the context of TR-101" [TR177]. FBBv6
   has two flavors:

     . P2P: every host, i.e. the Residential Gateway (RG), is in a P2P
        link with the router, i.e. the Broadband Network Gateway (BNG).
        In this case, the solution is essentially the same as MBBv6.
        All ND issues are solved.
     . P2MP: all hosts on an access device, e.g. the Optical Line
        Terminal (OLT), are in a P2MP link with the router.  This is
        implemented by aggregating all hosts into a single VLAN at the
        router and implementing Split Horizon at the access device to
        prevent direct host communication.

   The solution key points of FBBv6-P2MP [TR177] are:

     . Putting all hosts in a P2MP link with the router, and
        implementing DAD Proxy. P2MP architecture with Split Horizon
        breaks normal ND's DAD procedure. Because all hosts are in the
        same interface from the router's perspective, the router must
        ensure that the hosts have different LLAs and GUAs. Otherwise,
        the router will not be able to distinguish them. But because
        hosts cannot reach each other, normal DAD will not work.
        Therefore, the router must participate in the hosts' DAD
        process and help hosts resolve duplication. This is called DAD
        Proxy [RFC6957]. With P2MP link and DAD Proxy:
          o All host multicast to the router is effectively turned into
             unicast, as every host can only reach the router.
          o Trusting-all-host is only relevant to the router. By
             applying some simple filtering at the router, e.g.
             dropping RAs from the host, even malicious hosts cannot
             cause security harm.
     . Assigning a unique /64 prefix to each host. As a result:
          o When a prefix is assigned to the host, the router can
             proactively create (IP prefix, MAC) binding and use it for
             forwarding.  There is no need for Router-NCE-on-Demand.




Xiao                   Expires January 9, 2024                [Page 10]


Internet-Draft            nd-considerations                   July 2023


          o Since different hosts are in different subnets, hosts will
             send traffic to other hosts via the router. There is no
             address resolution for other hosts.
          o Without address resolution, router multicast to hosts
             consists only of unsolicited RAs. Because every host is in
             its own subnet, unsolicited RAs will be sent individually
             to each host with the "host's MAC replacing the multicast
             MAC" approach specified in [RFC6085]. Therefore, router
             multicast is turned into unicast.

   Since all the three causes of ND issues are addressed, FBBv6-P2MP
   addresses all ND issues.

3.3. Unique IPv6 Prefix per Host

   Unique IPv6 Prefix per Host is specified in [RFC8273]. The purpose
   is to "improve host isolation and enhanced subscriber management on
   shared network segments" such as Wi-Fi or Ethernet. The solution key
   points are:

     . Assigning a unique prefix to each host with SLAAC. As a result:
          o When a prefix is assigned to the host, the router can
             proactively create (Prefix, MAC) binding and use it for
             forwarding.  There is no need for Router-NCE-on-Demand.
          o Since different hosts are in different subnets, hosts will
             send traffic to other hosts via the router. There is no
             host to host address resolution.
          o Without address resolution, downstream multicast to hosts
             consists only of unsolicited RAs. They will be sent host
             by host in unicast because the prefix for every host is
             different.

   Therefore, ND issues caused by NCE-on-Demand and router multicast
   are avoided.

   RFC 8273 believes that "A network implementing a unique IPv6 prefix
   per host can simply ensure that devices cannot send packets to each
   other except through the first-hop router". But this may not be true
   when hosts are on a certain shared medium like Ethernet. In this
   case, hosts may still reach each other in L2 with their LLAs via
   upgream multicast. So issues caused by host multicast and Trusting-
   all-hosts may happen, e.g. on-link security issues.







Xiao                   Expires January 9, 2024                [Page 11]


Internet-Draft            nd-considerations                   July 2023


3.4. Wireless ND and Subnet ND

   Wireless ND (WiND) is specified in a series of RFCs
   [RFC6775][RFC8505][RFC8928][RFC8929]. WiND defines a fundamentally
   different ND solution for Low-Power and Lossy Networks (LLNs)
   [RFC7102]. WiND changes host and router behaviors to use multicast
   only for router discovery. The solution key points are:

     . Hosts use unicast to proactively register their addresses at
        the routers. Routers use unicast to communicate with hosts and
        become an abstract registrar and arbitrator for address
        ownership.
     . The router also proactively installs Neighbor Cache Entries
        (NCEs) for the hosts. This avoids the need for address
        resolution for the hosts.
     . The router sets PIO L-bit to 0. Each host communicates only
        with the router.
     . Other functionalities that are relevant only to LLNs.

   WiND addresses all ND issues in LLNs. If it is used outside LLNs, it
   avoids ND issues caused by NCE-on-Demand and router multicast.

   Subnet Neighbor Discovery [SND] generalizes the solutions defined in
   WiND and defines a new protocol named Subnet Gateway Protocol (SGP).
   It is being discussed in the IPv6 Maintenance (6man) WG.

3.5. Scalable Address Resolution Protocol

   Scalable Address Resolution Protocol (SARP) is an Experimental
   solution specified in [RFC7586]. The usage scenario is Data Centers
   (DCs) where large L2 domains spanned across multiple sites. In each
   site, multiple hosts are connected to a switch. The hosts can be
   Virtual Machines (VMs) so the number can be large.  The switches are
   interconnected by a native or overlay L2 network.

   The switch will snoop and install (IP, MAC) proxy table for the
   local hosts. The switch will also reply to address resolution
   requests from other sites to its hosts with its own MAC. This way,
   all hosts in a site will appear to have a single MAC to other sites.
   Therefore, a switch only needs to build a MAC table for the local
   hosts and the remote switches, not for all the hosts in the L2
   domain. The MAC table size of the switches is therefore
   significantly reduced. A switch will also add the (IP, MAC) replies
   from remote switches to its proxy ND table so that it can reply to
   future address resolution requests for such IPs directly. This




Xiao                   Expires January 9, 2024                [Page 12]


Internet-Draft            nd-considerations                   July 2023


   greatly reduces the number of address resolution multicast in the
   network.

   Unlike MBBv6, FBBv6 and RFC 8372 which try to address all ND issues,
   SARP focuses on reducing address resolution multicast to improve
   performance and scalability of large L2 domains in DCs.

3.6. ARP and ND Optimization for Transparent Interconnection of Lots of
   Links (TRILL):

   ARP and ND Optimization for TRILL is specified in [RFC8302]. The
   solution is very similar to SARP discussed in Section 3.5.  It can
   be considered as an application of SARP in the TRILL environment.

   Like SARP, ARP and ND Optimization for TRILL focuses on reducing
   address resolution multicast.

3.7. Proxy ARP/ND in EVPN

   Proxy ARP/ND in EVPN is specified in [RFC9161]. The usage scenario
   is Data Centers (DCs) where large L2 domains spanned across multiple
   sites. In each site, multiple hosts are connected to a Provider Edge
   (PE) router acting as a switch.  The PEs are interconnected by an
   overlay network.

   PE of each site snoops the local address resolution NAs to build
   (IP, MAC) Proxy ND table entries. PEs then propagate such Proxy ND
   entries to other PEs via BGP EVPN. Each PE also snoops address
   resolution NSs from its hosts. If an entry exists in its Proxy ND
   table for the specified destination IP address, the PE will reply
   directly.  Consequently, the number of multicast address resolution
   messages is significantly reduced.

   Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address
   resolution multicast.

3.8. Gratuitous Neighbor Discovery

   Gratuitous Neighbor Discovery is specified in [GRAND]. GRAND changes
   ND in the following ways:

     . A node sends unsolicited NAs upon assigning a new IPv6 address
        to its interface.
     . A router creates a new NCE for the host and set its state to
        STALE.




Xiao                   Expires January 9, 2024                [Page 13]


Internet-Draft            nd-considerations                   July 2023


   Later, when the router receives traffic to the host, the existence
   of the NCE entry in STALE state will cause the router to send
   unicast NS to the host to verify its reachability rather than
   sending multicast NS to resolve its MAC. This can shorten the time
   the host's NCE entry reaches REACHABLE state and improve forwarding
   performance.  Therefore, GRAND provides an improvement but does not
   solve the Router-NCE-on-Demand issues. For example, NCE exhaustion
   can still happen.

3.9. Reducing Router Advertisements

   [RFC7772] specifies a solution for reducing RAs. The key points are:

     . The router should respond to RS with unicast RA if the host's
        source IP address is not unspecified (i.e. the RS is not the
        first RS before GUA DAD) and the host's MAC is valid.
     . The router should reduce multicast RA frequency.
     . Sleeping hosts that process unicast packets while asleep must
        also process multicast RAs while asleep.
     . Sleeping hosts that do not intend to maintain IPv6 connectivity
        while asleep should either disconnect from the network and
        clear all IPv6 configuration, or perform Detecting Network
        Attachment in IPv6 (DNAv6) procedures [RFC6059] when waking up.

   RFC 7772 alleviates the multicast RA issue.

3.10. Source Address Validation Improvement and Router Advertisement
   Guard

   Source Address Validation Improvement is specified in [SAVI]. Router
   Advertisement Guard is specified in [RA-Guard][RA-Guard+]. SAVI
   binds an address to a port and rejects claims from other ports for
   that address. Therefore, a node cannot spoof the IP address of
   another node.  RA-Guard and RA-Guard+ only allow RAs from a port
   that a router is connected to. Therefore, nodes on other ports
   cannot pretend to be a router.

   SAVI, RA-Guard and RA-Guard+ address the on-link security issues.

3.11. Dealing with Off-link Attack that May Cause Router NCE Exhaustion

   Router NCE Exhaustion handling is described in [RFC6583]. This is to
   deal with the off-link attack issue discussed in Section 2.3. The
   solution key points are:

     . For operators:



Xiao                   Expires January 9, 2024                [Page 14]


Internet-Draft            nd-considerations                   July 2023


          o Filtering of unused address space so that messages to such
             addresses can be dropped rather than triggering NCE
             creation;
          o Minimizing subnet size so that there are fewer potential
             NCEs to create;
          o Rate-limiting the NDP queue to avoid CPU/memory overflow.
     . For vendors:
          o Prioritizing NDP processing for existing NCEs over creating
             new NCEs

   RFC 6583 acknowledges that "some of these options are 'kludges',
   and can be operationally difficult to manage". RFC 6583 partially
   addresses the Router NCE Exhaustion issue.

3.12. Enhanced DAD

   Enhanced DAD is specified in [RFC7527]. Enhanced DAD addresses a DAD
   failure issue in a specific situation: looped back interface. DAD
   will fail in a looped back interface because the sending host will
   receive the DAD message back and will interpret it as another host
   is trying to use the same address. The solution is to include a
   Nonce option (defined in [SeND]) in each DAD message so that the
   sending host can detect that the looped back DAD message is sent by
   itself.

   Enhanced DAD does not solve any of the ND issues discussed in
   Section 2. It extends ND to work in a new scenario: looped back
   interface.  It is reviewed here for completeness but will not be
   further discussed.

3.13. ND Mediation for IP Interworking of Layer 2 VPNs

   ND mediation is specified in [RFC6575]. When two Attachment Circuits
   (ACs) are interconnected by a Virtual Private Wired Service (VPWS),
   and the two ACs are of different medium (e.g. one is Ethernet while
   the other is Frame Relay), the two Provider Edges (PEs) must
   interwork to provide mediation service so that a Customer Edge (CE)
   can resolve the link layer address of the remote end. RFC 6575
   specifies such a solution.

   ND Mediation does not address any of the ND issues discussed in
   Section 2. It extends ND to work in a new scenario: two ACs of
   different media interconnected by a VPWS. It is reviewed here for
   completeness but will not be further discussed.





Xiao                   Expires January 9, 2024                [Page 15]


Internet-Draft            nd-considerations                   July 2023


3.14. ND Solutions Defined before the Latest Versions of ND

   The latest versions of [ND] and [SLAAC] are specified in RFCs 4861
   and 4862. Several ND optimization solutions are based on the older
   version of ND and SLAAC. They are reviewed in this section for
   completeness but will not be further discussed.

3.14.1. SeND

   Secure Neighbor Discovery [SeND] is specified in RFC 3971. The
   purpose is to ensure that hosts and routers are trustable. SeND
   defined three new ND options (i.e. Cryptographically Generated
   Addresses [CGA], RSA public-key cryptosystem, Timestamp/Nonce), an
   authorization delegation discovery process, an address ownership
   proof mechanism, and requirements for the use of these components in
   NDP.

   SeND addresses the Trusting-all-hosts issues. But it has high
   requirements on the hosts and routers, especially to maintain the
   keys.  SeND is rarely deployed and will not be further discussed in
   this document.

3.14.2. Cryptographically Generated Addresses (CGA)

   Cryptographically Generated Addresses [CGA] is specified in RFC
   3972. The purpose is to associate a cryptographic public key with an
   IPv6 address in [SeND]. The solution key point is to generate the
   Interface Identifier (IID) of the IPv6 address by computing a
   cryptographic hash of the public key.  The resulting IPv6 address is
   called a CGA.  The corresponding private key can then be used to
   sign messages sent from the address.

   CGA uses the fact that a legitimate host does not care about the bit
   combination of IID that would be created as a result of some hash
   procedure. The attacker needs an exact IID to impersonate the
   legitimate hosts but then the attacker is challenged to do a reverse
   hash calculation that is a strong mathematical challenge.

   CGA is part of SeND. It is rarely deployed and will not be further
   discussed in this document.

3.14.3. ND Proxy

   ND Proxy is specified in [RFC4389]. It is an Experimental solution.
   The purpose is to enable multiple links joined by an ND-Proxy device




Xiao                   Expires January 9, 2024                [Page 16]


Internet-Draft            nd-considerations                   July 2023


   to work as a single link. The ND-Proxy acts like a bridge. The
   solution key points are:

     . When it receives an ND request from a host in a link, it will
        "proxy" the message out from the "best" outgoing interface. How
        to determine the "best" interface is explained later. If there
        is no "best" interface, the ND-Proxy will "proxy" the message
        to all other links.  Here "proxy" means acting as if the ND
        message originates from the ND-Proxy itself. That is, the ND-
        Proxy will change the ND message's source IP and source MAC to
        the ND-Proxy's outgoing interface's IP and MAC, and create an
        NCE entry at the outgoing interface accordingly.
     . When ND-Proxy receives an ND reply, it will act as if the ND
        message is destined to itself, and update the NCE entry state
        at the receiving interface. Based on such state information,
        the ND-Proxy can determine the "best" outgoing interface for
        future ND requests. The ND-Proxy then "proxy" the ND message
        back to the requesting host.

   ND Proxy does not solve any of the ND issues discussed in Section 2.
   It extends ND to work in a new scenario: multiple links joined by a
   device that is not a bridge but acting like a bridge.

   The idea of ND Proxy is widely used in SARP, ND Optimization for
   TRILL and Proxy ARP/ND in EVPN which are discussed in Sections 3.4
   to 3.6.

3.14.4. Optimistic DAD

   Optimistic DAD is specified in [RFC4429]. The purpose is to minimize
   address configuration delays in the successful case and to reduce
   disruption as far as possible in the failure case. Optimistic DAD
   modified the original ND (RFC 2461) and SLAAC (RFC 2462) but the
   solution was not incorporated into the latest specification of [ND]
   and [SLAAC].

   Optimistic DAD does not solve any of the ND issues discussed in
   Section 2. It tries to enhance ND's performance for DAD. But the
   changes are big and the benefits are not significant. Optimistic DAD
   has not been widely deployed.

3.15. Observations on the Solutions

   Which ND solution solving which ND issue is tabulated below, for the
   fifteen issues summarized in Section 2.4:




Xiao                   Expires January 9, 2024                [Page 17]


Internet-Draft            nd-considerations                   July 2023


     . Performance issues caused by multicast
          o I1: LLA DAD multicast degrading performance
          o I2: Unsolicited RA multicast degrading performance
          o I3: GUA/ULA DAD multicast degrading performance
          o I4: Router address resolution multicast degrading
             performance
          o I5: Host Address resolution multicast degrading performance
     . Reliability issues caused by multicast
          o I6: LLA DAD not reliable for wireless networks
          o I7: GUA/ULA DAD not reliable for wireless networks
     . On-link security issues caused by trusting all hosts
          o I8: Source IP address spoofing
          o I9: DAD denial
          o I10: Fake RAs
          o I11: Fake Redirect
          o I12: Replay attacks
     . Off-link attack and other issues caused by Router-NCE-on-Demand
          o I13: Router NCE exhaustion
          o I14: Router forwarding delay
          o I15: Lack of subscriber management using ND with SLAAC

   +-----+-------------------+--------+--------+--------+------+-----+

   |     |     Multicast     | Reli-  |On-link |R NCE   |R Fwd.|Sub  |

   |     |     performance   | ability|security|Exhaust.|Delay |Mgmt.|

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |Issue| 1 | 2 | 3 | 4 | 5 | 6 |  7 |  8-12  |   13   |  14  | 15  |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |MBBv6|               All issues solved                           |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |FBBv6|               All issues solved                           |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |8273 |   | X | X | X | X |   |  X |        |    X   |   X  |  X  |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |WiND |               All issues solved for LLNs                  |



Xiao                   Expires January 9, 2024                [Page 18]


Internet-Draft            nd-considerations                   July 2023


   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |SARP |   |   |   |   | X |   |    |        |        |      |     |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |ND   |   |   |   |   | X |   |    |        |        |      |     |

   |TRILL|   |   |   |   |   |   |    |        |        |      |     |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |ND   |   |   |   |   | X |   |    |        |        |      |     |

   |EVPN |   |   |   |   |   |   |    |        |        |      |     |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |7772 |   | X |   |   |   |   |    |        |        |      |     |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |GRAND|   |   |   | X |   |   |    |        |        |Partly|     |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |SAVI/|   |   |   |   |   |   |    |        |        |      |     |

   |RAG  |   |   |   |   |   |   |    |   X    |        |      |     |

   |G+   |   |   |   |   |   |   |    |        |        |      |     |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

   |6583 |   |   |   |   |   |   |    |        |    X   |      |     |

   +-----+---+---+---+---+---+---+----+--------+--------+------+-----+

              Table 1. Which solution solves which issue(s)

   Although the various ND solutions look unrelated, dividing them into
   three groups will help to reveal a common theme: isolating hosts to
   prevent issues.






Xiao                   Expires January 9, 2024                [Page 19]


Internet-Draft            nd-considerations                   July 2023


   The first group contains MBBv6, FBBv6, and Unique Prefix Per Host.
   These solutions isolate hosts in L3 and possibly L2, and they
   prevent all or most ND issues.

   The second group contains WiND, SARP, ND Optimization for TRILL, and
   Proxy ND in EVPN. They use a proxy device to represent the hosts
   behind it, and effectively isolate such hosts into different
   multicast/broadcast domains from other hosts. These solutions
   alleviate address resolution and in the case of WiND other issues.

   The third group contains the remaing solutions. They do not try to
   isolate hosts. They focus on solving a specific ND issue.

   This theme reveals an insight: isolating hosts is effective in
   preventing ND issues. The stronger hosts are isolated, the more ND
   issues can be prevented. This is natural because isolating hosts
   reduces multicast and hosts to trust, two of the causes of ND
   issues.

   This insight can be used to formulate guidelines to prevent ND
   issues and simplify IPv6 first-hops where ND plays a key role.

4. Selectively Isolating Hosts to Prevent Potential ND Issues and
   Simplify IPv6 First-hops

   This section describes how to isolate hosts, and the advantages and
   disadvantages of doing so. It also provides guidelines on how to
   select a suitable isolation method based on the deployment scenario.

   The solution review in Section 3 reveals four different host
   isolation mechanisms:

     . L3/Subnet isolation (i.e. Unique Prefix Per Host), used in
        MBBv6, FBBv6 and RFC 8273.
     . L2/Link isolation, with 2 flavors:
          o P2P link isolation, used in MBBv6 and FBBv6-PPPoE;
          o P2MP link isolation, used in FBBv6-IPoE.
     . Proxy isolation, used in WiND/SND, SARP, ND Optimization for
        TRILL, Proxy ND in EVPN. This effectively divides a subnet into
        multiple multicast domains and can be considered as a L2 host
        isolation method.
     . GUA isolation (i.e. setting PIO L-bit=0), which is a native ND
        mechanism used in many solutions.
          o  GUA isolation is different from link isolation in that
             there can be multiple hosts in the link. It is just that
             each host treats other hosts as off-link and does not



Xiao                   Expires January 9, 2024                [Page 20]


Internet-Draft            nd-considerations                   July 2023


             perform address resolution for other hosts' GUA. The host
             will send messages with GUA via the router instead. But
             all messages with LLA can still reach other hosts in the
             same broadcast domain. In link isolation, there is only
             one host in each link. A host cannot send messages with
             LLAs to other hosts.

   These isolation mechanisms are not completely independent:

   First, [RFC4291] stated that "IPv6 continues the IPv4 model in that
   a subnet prefix is associated with one link". Therefore, link
   isolation and subnet isolation are better used together, otherwise,
   some ND issues may appear:

     . L2 isolation without subnet isolation, which creates a Multi-
        Link SubNet (MLSN), can cause GUA DAD not to work unless the
        router provides DAD Proxy [RFC6957] or address registration and
        arbitration [WiND]. [RFC4903] documented the concerns about
        MLSN.
     . Subnet isolation without L2 isolation, when used for multiple
        hosts on a shared medium, can have on-link security issues if
        the hosts can not be trusted. For example, LLA DAD denial may
        happen if attacker hosts exist.

   However, link isolation depends on the physical media and may not
   always be possible, while subnet isolation requires a prefix for
   each host and may not always be possible either. Therefore,
   solutions using subnet isolation or link isolation separately exist.

   Second, Proxy Isolation divides hosts in the same subnet into
   different broadcast domains. Hosts are isolated in different groups
   but not necessarily individually. This is effectively "L2 (Group)
   Isolation without L3 Isolation".

   Third, GUA isolation is only meaningful for hosts in the same subnet
   and broadcast domain.  Otherwise, setting PIO L-bit to 0 or 1 makes
   no difference.

   Therefore, these different isolation mechanisms produce five
   meaningful combinations:

     . Subnet Isolation with P2P Link
     . Subnet Isolation with P2MP Link
     . Subnet Isolation with Shared Medium.  A shared medium is a
        broadcast domain. So this is "Subnet Isolation without L2
        Isolation"



Xiao                   Expires January 9, 2024                [Page 21]


Internet-Draft            nd-considerations                   July 2023


     . Proxy Isolation, i.e. "L2 Isolation without Subnet Isolation".
     . GUA Isolation, for hosts in the same subnet and same broadcast
        domain

   There is a logic in arranging the five isolation methods this way:
   the first three are L3 isolation with decreasing degree of L2
   isolation, i.e. from P2P Link to P2MP Link to Shared Medium; the
   fourth is "L2 isolation without L3 isolation"; the fifth isolates
   hosts in the same subnet and same broadcast domain from a GUA
   perspective. They go from the strongest degree to the weakest
   degree, and should cover all possible isolation scenarios.

   Their applicability is discussed below.

4.1. Applicability of Subnet Isolation with P2P Link

   The advantages are:

   o  All ND issues are prevented.

   The disadvantages are:

   o  The hosts must be able to set up P2P links with the router.

   o  Many prefixes will be needed, one per host.

       o  This is probably not an issue for IPv6. Today, any member of
          a Regional Internet Registry (RIR) can get a /29 [RIPE738].
          This contains 32 billion /64 prefixes and should be
          sufficient for any scenarios. The fact that MBBv6 assigns a
          /64 to every mobile UE [RFC6459], and FBBv6 assigns a /56 to
          every routed RG [TR177] is evidence.

   o  Each host is easily identifiable by its unique prefix. This
      reduces privacy.

   o  The router must support a "Subnet Isolation with P2P Link"
      solution, e.g. MBBv6.

   o  Many interfaces will be needed at the router, one per host.

   o  All hosts will communicate through the router, and the router may
      become a bottleneck.

   o  Services relying on multicast communication among hosts, e.g.
      mDNS, will not work.



Xiao                   Expires January 9, 2024                [Page 22]


Internet-Draft            nd-considerations                   July 2023


4.2. Applicability of Subnet Isolation with P2MP Link

   The advantages and disadvantages of Subnet Isolation with P2MP Link
   are same as the P2P method, except that:

   o  Hosts do not need the capability to set up P2P links with the
      router. The L2 medium must support P2MP Link, e.g. with [PVLAN]
      or Wireless Isolation [W-Iso].

   o  The router must support a "Subnet Isolation with P2MP Link"
      solution, including DAD Proxy.

   o  Only one interface is needed at the router

4.3. Applicability of Subnet Isolation with Shared Medium

   The advantages are:

   o  All ND issues are prevented except "LLA DAD multicast degrading
      performance", "LLA DAD not reliable for wireless networks", and
      "On-link security" issues. Depending on the shared medium, these
      remaining issues may not happen either. For example, if the
      shared medium is Ethernet, "LLA DAD multicast degrading
      performance" and "LLA DAD not reliable for wireless networks" are
      non-issues. If the network is not a public access network and
      therefore hosts can be trusted, "On-link security" issues will
      not happen either.

   o  There is no new requirement on the hosts. Therefore this method
      can be applied in many scenarios. It is likely the most usable
      host isolation method.

   The disadvantages are:

   o  Many prefixes will be needed, one per host. But as explained
      above, this may not be an issue for most organizations that can
      obtain sufficient IPv6 addresses from RIRs.

   o  The router must support a Subnet Isolation solution, e.g.
      [RFC8273] or [Collink].

   o  All host communication with GUA will go through the router, and
      the router may become a bottleneck.

   o  Each host is easily identifiable by its unique prefix. This
      reduces privacy.



Xiao                   Expires January 9, 2024                [Page 23]


Internet-Draft            nd-considerations                   July 2023


4.4. Applicability of Proxy Isolation

   The advantages of Proxy Isolation are:

   o  Reduced multicast especially for address resolution, as the
      subnet is divided into multiple multicast domains.

   o  For solutions that proactively install NCEs on the router, e.g.
      WiND, all Router-NCE-On-Demand issues are prevented.

   The disadvantages are:

   o  The router must support Proxy Isolation.

   o  Some multicast issues may happen, e.g. those related to multicast
      RSs.

4.5. Applicability of GUA Isolation

   The advantages of GUA Isolation are:

   o  No address resolution for GUA among hosts.

   o  This is normal ND behavior. No additional ND optimization
      solution is needed.

   The disadvantages are:

   o  Only multicast address resolution for GUA among hosts is
      eliminated. All other ND issues may still happen depending on the
      usage scenarios.

   o  All host communication with GUA will go through the router, and
      the router may become a bottleneck.

4.6. Guidelines for Selecting a Host Isolation Method

   Given the applicability analysis above, network administrators can
   decide where to apply which isolation method.

   The guidelines below start from the strongest isolation method. This
   prevents the largest number of ND issues, and therefore, requires
   fewest additional solutions for the remaining issues. But the
   strongest isolation also has the highest entry requirements and the
   fewest applicable scenarios. If the strongest isolation is not
   possible, the next level of isolation is probed, all the way to no



Xiao                   Expires January 9, 2024                [Page 24]


Internet-Draft            nd-considerations                   July 2023


   isolation at the end.  Therefore, network administrators can likely
   find the most suitable isolation method for their deployment
   scenarios.

  1. If Subnet Isolation with P2P Link is feasible:

       a) Applicable scenarios:

            1) The medium is P2P.

            2) Direct host to host communication without going through
               the router is not needed.

            3) Multicast is not desirable (implying mDNS is not
               needed).

            4) Hosts may not be trustable.

            5) Subscriber management is needed.

            6) Privacy of hosts are not a major concern.

            Examples are public access networks such as MBBv6 or FBBv6
            with PPPoE.

       b) Entry requirements:

            1) Hosts must be able to set up P2P links with the router.

            2) There are sufficient IPv6 addresses to provide Unique
               Prefix Per Host.

            3) The router must support a "Subnet Isolation with P2P
               Link" solution, e.g. MBBv6.

       c) Remaining ND issues and solutions:

            1) None.

  2. Otherwise, if Subnet Isolation with P2MP Link is feasible

       a) Applicable scenarios:

            1) Same as the P2P scenarios except that the medium is
               P2MP.




Xiao                   Expires January 9, 2024                [Page 25]


Internet-Draft            nd-considerations                   July 2023


            Examples are FBBv6 with IPoE or public Wi-Fi access.

       b) Entry requirements:

            1) There are sufficient IPv6 addresses to provide Unique
               Prefix Per Host.

            2) The router must support a "Subnet Isolation with P2MP
               Link" solution, including DAD Proxy, e.g. FBBv6-P2MP.

       c) Remaining ND issues and solutions

            1) None

  3. Otherwise, if Subnet Isolation with Shared Medium is feasible

       a) Applicable scenarios:

            1) The medium is a shared medium.

            2) Direct host to host communication is not needed.

            3) Privacy of hosts are not a major concern.

       b) Entry requirements:

            1) There are sufficient IPv6 addresses to provide Unique
               Prefix Per Host.

            2) The router must support Unique Prefix Per Host, e.g.
               [RFC8273] or [Collink].

       c) Remaining ND issues and solutions

            1) "LLA DAD multicast degrading performance", "LLA DAD not
               reliable for wireless networks", and "On-link security"
               issues can theoretically happen. Depending on the shared
               medium, these remaining issues may not actually happen.
               For example, if the shared medium is Ethernet, "LLA DAD
               multicast degrading performance" and "LLA DAD not
               reliable for wireless networks" are non-issues. If the
               link is not a public access link, "On-link security" may
               not be issues either. It is advisable to use this method
               where these remain issues are not a concern. If they are
               a concern, Subnet Isolation with P2P or P2MP Link may be
               more suitable.



Xiao                   Expires January 9, 2024                [Page 26]


Internet-Draft            nd-considerations                   July 2023


  4. Otherwise, if Proxy Isolation is feasible

       a) Applicable scenarios:

            1) The hosts are in a subnet, but it is possible to
               separate them into differentf broadcast/multicast
               domains, e.g. in a multi-link subnet, or a large DC
               involving a large number of VMs spanning across multiple
               sites interconnected by PEs supporting SARP.

       b) Entry requirements:

            1) The PEs must support a Proxy Isolation solution like
               WiND, SARP, or Proxy ND in EVPN.

       c) Remaining ND issues and solutions:

            1) WiND/SND solves all ND issues but they are fundamentally
               different ND solutions that require both router and host
               changes. Other proxy isolation solutions only reduce
               multicast address resolution for GUA among hosts while
               other ND issues may happen. Depending on the deployment
               scenarios, solutions in Table 1 can be selected for the
               issues that will actually happen.

  5. If there are still multiple hosts in a same subnet and broadcast
     domain, if GUA Isolation (i.e. setting PIO L-bit=0) is feasible

       a) Applicable scenarios:

            1) It is desirable to avoid host address resolution for
               other hosts in the same broadcast domain.

       b) Entry requirements:

            1) None as this is a native ND mechanism.

       c) Remaining ND issues and solutions:

            1) Only multicast GUA address resolution hosts is
               eliminated. All other ND issues may happen. Depending on
               the deployment scenarios, solutions in Table 1 can be
               selected for the issues that will actually happen.

  6. Otherwise, no isolation to apply




Xiao                   Expires January 9, 2024                [Page 27]


Internet-Draft            nd-considerations                   July 2023


       a) Applicable scenarios:

            1) ND issues are not a concern. That is, multicast is not a
               problem, hosts can be trusted, and Router-NCE-on-demand
               is not an issue.

            2) Some ND issues are a concern, but it is preferable to
               deploy the corresponding ND optimization solutions than
               to isolate hosts.

       b) Entry requirements:

            1) None.

       c) Remaining issues and solutions

            1) All ND issues can happen theoretically. Depending on
               what are of concern practically, the corresponding ND
               optimization solutions tabulated in Table 1 can be
               applied.

4.7. Impact of Host Isolation on Other Protocols in IPv6 First-hops

   The impact (i.e. the disadvantages) of various isolation methods to
   the IPv6 first-hop has been discussed in the applicability sections.
   The guidelines have taken such applicability into consideration and
   given network adminstrators the option not to apply any isolation.
   Therefore, if an isolation method is indeed selected, its advantages
   likely outweigh its disadvantages.

5. Security Considerations

   This document provides guidelines on how to select a suitable
   isolation method depending on the deployment scenario. When an
   isolation method is selected, the security considerations of the
   used solutions which are defined in the corresponding RFCs apply.
   These security considerations are discussed in Section 4. In
   particular, using Unique Prefix Per Host makes a host easily
   identifiable by the prefix and reduces privacy. It is imcompatible
   with using temporary addresses to increase privacy [RFC8981]. This
   document itself does not introduce any new solutions. Therefore, it
   does not introduce new security issues.

6. IANA Considerations

   This document has no request to IANA.



Xiao                   Expires January 9, 2024                [Page 28]


Internet-Draft            nd-considerations                   July 2023


7. References

7.1. Informative References

   [CGA]     T. Aura, "Cryptographically Generated Addresses (CGA)",
             RFC3972

   [Collink] L. Colitti, J. Linkova, X. Ma, "Using DHCP-PD to Allocate
             Unique IPv6 Prefix per Host in Broadcast Networks", draft-
             collink-v6ops-ent64pd-04.

   [DHCPv6]  T. Mrugalski M. Siodelski B. Volz A. Yourtchenko M.
             Richardson S. Jiang T. Lemon T. Winters, "Dynamic Host
             Configuration Protocol for IPv6 (DHCPv6)", RFC 8415.

   [GRAND]   J. Linkova, "Gratuitous Neighbor Discovery: Creating
             Neighbor Cache Entries on First-Hop Routers", RFC 9131

   [mDNS]    S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762.

   [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, RFC 4861.

   [PVLAN]   https://en.wikipedia.org/wiki/Private_VLAN

   [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, RFC 6105.

   [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router
             Advertisement Guard (RA-Guard)", RFC 7113, DOI
             10.17487/RFC7113, February 2014, RFC 7113.

   [RFC3756] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor
             Discovery (ND) Trust Models and Threats", RFC 3756.

   [RFC4291] R. Hinden, S.Deering, "IP Version 6 Addressing
             Architecture", RFC 4291.

   [RFC4389] D. Thaler, M. Talwar, C. Patel, "Neighbor Discovery
             Proxies (ND Proxy)", RFC 4389.

   [RFC4429] N. Moore, "Optimistic Duplicate Address Detection (DAD)
             for IPv6", RFC 4429.




Xiao                   Expires January 9, 2024                [Page 29]


Internet-Draft            nd-considerations                   July 2023


   [RFC4903] D. Thaler, "Multi-Link Subnet Issues", RFC 4903.

   [RFC6459] J. Korhonen, J. Soininen, B. Patil, T. Savolainen, G.
             Bajko, K. Iisakkila, "IPv6 in 3rd Generation Partnership
             Project (3GPP) Evolved Packet System (EPS)", RFC 6459.

   [RFC6059] S. Krishnan, G. Daley, "Simple Procedures for Detecting
             Network Attachment in IPv6", RFC 6059.

   [RFC6085] S. Gundavelli, M. Townsley, O. Troan, W. Dec, "Address
             Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085.

   [RFC6575] H. Shah, E. Rosen, G. Heron, V. Kompella, "Address
             Resolution Protocol (ARP) Mediation for IP Interworking of
             Layer 2 VPNs", RFC 6575.

   [RFC6583] I. Gashinsky, J. Jaeggli, W. Kumari, "Operational Neighbor
             Discovery Problems", RFC 6583.

   [RFC6775] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann,
             "Neighbor Discovery Optimization for IPv6 over Low-Power
             Wireless Personal Area Networks (6LoWPANs)", RFC 6775.

   [RFC6957] F. Costa, J-M. Combes, X. Pougnard, H. Li, "Duplicate
             Address Detection Proxy", RFC 6957

   [RFC7066] J. Korhonen, J. Arkko, T. Savolainen, S. Krishnan, "IPv6
             for Third Generation Partnership Project (3GPP) Cellular
             Hosts", RFC 7066.

   [RFC7102] JP. Vasseur, "Terms Used in Routing for Low-Power and
             Lossy Networks", RFC 7102.

   [RFC7278] Extending an IPv6 /64 Prefix from a Third Generation
             Partnership Project (3GPP) Mobile Interface to a LAN
             Link", RFC7278.

   [RFC7342] L. Dunbar, W. Kumari, I. Gashinsky, "Practices for Scaling
             ARP and Neighbor Discovery (ND) in Large Data Centers",
             RFC 7342.

   [RFC7527] R. Asati, H. Singh, W. Beebee, C. Pignataro, E. Dart, W.
             George, "Enhanced Duplicate Address Detection", RFC 7527.






Xiao                   Expires January 9, 2024                [Page 30]


Internet-Draft            nd-considerations                   July 2023


   [RFC7586] Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi, "The
             Scalable Address Resolution Protocol (SARP) for Large Data
             Centers", RFC7586.

   [RFC7772] A. Yourtchenko, L. Colitti, "Reducing Energy Consumption
             of Router Advertisements", RFC 7772.

   [RFC8273] J. Brzozowski, G. Van de Velde, "Unique IPv6 Prefix per
             Host", RFC 8273.

   [RFC8302] Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair,
             "Transparent Interconnection of Lots of Links (TRILL): ARP
             and Neighbor Discovery (ND) Optimization", RFC 8302.

   [RFC8505] P. Thubert, E. Nordmark, S. Chakrabarti, C. Perkins,
             "Registration Extensions for IPv6 over  Low-Power Wireless
             Personal Area Network (6LoWPAN) Neighbor Discovery", RFC
             8505.

   [RFC8928] P. Thubert, B. Sarikaya, M. Sethi, R. Struik, "Address-
             Protected Neighbor Discovery for Low-Power and Lossy
             Networks", RFC 8928.

   [RFC8929] P. Thubert, C.E. Perkins, E. Levy-Abegnoli, "IPv6 Backbone
             Router", RFC 8929.

   [RFC8981] F. Gont, S.Krishnan, T.Narten, R. Draves, "Temporary
             Address Extensions for Stateless Address Autoconfiguration
             in IPv6", RFC 8981.

   [RFC9099] E. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey, "Operational
             Security Considerations for IPv6 Networks", RFC 9099.

   [RFC9119] C. Perkins, M. McBride, D. Stanley, W. Kumari, JC. Zuniga,
             "Multicast Considerations over IEEE 802 Wireless Media",
             RFC 9119.

   [RFC9161] J. Rabadan, S. Sathappan, K. Nagaraj, G. Hankins, T. King,
             "Operational Aspects of Proxy ARP/ND in Ethernet Virtual
             Private Networks", RFC 9161.

   [RIPE738] IPv6 Address Allocation and Assignment Policy,
             https://www.ripe.net/publications/docs/ripe-738






Xiao                   Expires January 9, 2024                [Page 31]


Internet-Draft            nd-considerations                   July 2023


   [SAVI]    J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, "Source
             Address Validation Improvement (SAVI) Framework", RFC
             7039.

   [SeND]    J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor
             Discovery (SEND)", RFC3971.

   [SLAAC]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
             Address Autoconfiguration", RFC 4862.

   [SND]     P. Thubert, M. Richardson, "Architecture and Framework for
             IPv6 over Non-Broadcast Access", Internet draft, June
             2023.

   [TR177]   S. Ooghe, B. Varga, W. Dec, D. Allan, "IPv6 in the context
             of TR-101", Broadband Forum, TR-177.

   [W-Iso]   Wireless Isolation, https://www.quora.com/What-is-
             wireless-isolation

8. Acknowledgments

   The authors would like to thank Pascal Thubert, Ole Troan, Brian
   Carpenter, David Thaler, Jen Linkova, Eric Vyncke, Lorenzo Colitti
   for the discussion and input.
























Xiao                   Expires January 9, 2024                [Page 32]


Internet-Draft            nd-considerations                   July 2023


Authors' Addresses

   XiPeng Xiao
   Huawei Technologies Dusseldorf
   Hansaallee 205, 40549 Dusseldorf, Germany

   Email: xipengxiao@huawei.com

   Eduard Vasilenko
   Huawei Technologies
   17/4 Krylatskaya st, Moscow, Russia 121614

   Email: vasilenko.eduard@huawei.com

   Eduard Metz
   KPN N.V.
   Maanplein 55, 2516CK  The Hague, The Netherlands

   Email: eduard.metz@kpn.com

   Gyan Mishra
   Verizon Inc.

   Email: gyan.s.mishra@verizon.com

   Nick Buraglio
   Energy Sciences Network

   Email: buraglio@es.net




















Xiao                   Expires January 9, 2024                [Page 33]