IPv6 Operations (v6ops) Working Group                           X. Xiao
Internet Draft                                      Huawei Technologies
Intended status: Informational                                  E. Metz
Expires: Aug. 2022                                                  KPN
                                                              G. Mishra
                                                           Verizon Inc.
                                                      February 16, 2022

            Neighbor Discovery Protocol Deployment Guidelines
               draft-xiao-v6ops-nd-deployment-guidelines-01


Abstract

   Neighbor Discovery (ND) is an integral part of IPv6 first-hop. Due
   to limitation of certain L2 media's support to ND, a number of
   issues can happen in certain scenarios. Solutions for these issues
   have been designed. These issues and solutions are summarized in
   RFC3756, RFC6583, RFC9099.  However, there is no guideline on how to
   prevent the issues or how to select the proper solutions.

   This document analyzes the existing solutions and summarizes their
   wisdoms into an insight: isolating hosts into different L2 links or
   different L3 subnets can be effective in preventing ND issues. In
   deployment scenarios where the ND issues can occur, this prevention
   approach can be more effective than deploying the corresponding
   solutions to solve the issues. Based on this insight, a set of
   guidelines is proposed for future ND deployments. These guidelines
   describe where to isolate hosts in L2 or in subnet to prevent ND
   issues, and how to select suitable solutions for the remaining
   issues. This will likely simplify ND deployment. The impact of such
   isolation to other components of IPv6 first-hop is also analyzed.
   The impact appears small. Therefore, the guidelines will likely
   simplify the overall IPv6 first-hop deployment.

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




Xiao                   Expires August 16, 2022                 [Page 1]


Internet-Draft         ND-deployment-guidelines           February 2022


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

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................2
      1.1. Terminology...............................................3
   2. Summary of ND Issues and Existing Solutions....................4
      2.1. Multicast Issues and Solutions............................4
      2.2. DAD-unreliable Issues and Solutions.......................6
      2.3. On-demand NCE Installation Issues and Solutions...........6
      2.4. Security Issues and Solutions.............................7
      2.5. Observations on the Solutions and an Insight Learned......9
   3. Isolating Hosts in L2 and in Subnet to Simplify ND Deployment.11
      3.1. Applicability of L2 Isolation and Subnet Isolation.......11
      3.2. Deployment Guidelines....................................14
   4. Impact of L2 Isolation and Subnet Isolation to Other Components
   of IPv6 First-hop................................................16
   5. Applying the Guidelines to Real World Scenarios...............18
   6. Security Considerations.......................................19
   7. IANA Considerations...........................................19
   8. References....................................................19
      8.1. Informative References...................................19
   9. Acknowledgments...............................................22

1. Introduction

   ND is an integral part of IPv6 first-hop. Due to limitation of
   certain L2 media's support to the protocol, a number of issues have



Xiao                   Expires August 16, 2022                 [Page 2]


Internet-Draft         ND-deployment-guidelines           February 2022


   been discovered, and the corresponding solutions have been designed.
   These issues and solutions are dispersed in more than 20 RFCs.
   [RFC6583] summarized the issues and solutions up to 2012. [RFC9099]
   summarized known IPv6 security issues, including ND issues, up to
   2021. Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929]
   discussed ND issues and solutions in Low-Power and Lossy Networks
   (LLNs) [RFC7102]. However, two ND deployment problems still exist:

     1. None of [RFC6583], [RFC9099] and WiND provides guidelines on
        how to prevent the issues;
     2. Some issues have multiple solutions. There is no guideline on
        how to select the suitable solutions depending on the
        deployment scenarios.

   [RFC8273] recommends using "Unique IPv6 Prefix per Host" as a best
   practice for ND.  By doing so, certain ND issues can be prevented.
   So, it partially solved Problem 1 above. But [RFC8273] cannot be
   used everywhere. In fact, some concerns about [RFC8273] have been
   expressed in [8273D].

   This document aims to solve both problems by providing deployment
   guidelines for ND.  Depending on the usage scenarios, the guidelines
   firstly try to prevent the issues as much as possible, then
   recommend suitable solutions for the remaining issues. This can
   result in the simplest ND deployment.

1.1. Terminology

   Familiarity with [ND] and [SLAAC] are prerequisite to understand
   this document. Familiarity with the ND issues and solutions
   discussed in [RFC6583] and [RFC9099] Section 2.3 are also essential
   to understand this document.

   Some frequently used terms are defined in this section.

  L2 isolation for hosts - One host per link. Consequently, A host
           cannot send packets via the L2 medium to any other hosts.
           Router will be the only node reachable in L2. This can be
           realized on P2P media, or on multi-access media with Private
           VLAN [PVLAN] or Split Horizon [TR177] or wireless isolation
           [W-Iso] to prevent hosts from communicating with each other
           in L2.

  Subnet isolation for hosts - One host per subnet. This can be done
           by assigning a unique subnet prefix to each host. Therefore,
           it is also known as "unique prefix per host" [RFC8273].



Xiao                   Expires August 16, 2022                 [Page 3]


Internet-Draft         ND-deployment-guidelines           February 2022


  NCE -    Neighbor Cache Entry, a binding of a neighbor's IPv6
           address and link layer address.

2. Summary of ND Issues and Existing Solutions

   This section summarizes the main ND issues and solutions. More
   information can be found in [RFC6583][RFC6775][RFC9099].

2.1. Multicast Issues and Solutions

   ND uses multicast extensively for Node Solicitations (NSs), Router
   Solicitations (RSs) and Router Advertisements (RAs). When multicast
   messages are sent over an L2 medium, they may be mapped into L2
   broadcast messages. For many wireless media, L2 broadcast may
   consume more network resources than multiple P2P unicast combined
   [RFC6775][RFC7668], and have lower probability of delivery. In
   addition, multicast has no acknowledgement. Consequently, multicast
   may cause a number of issues:

     . Multicast-resource-consumption issue: multicast in L3 and the
        resulted broadcast in L2 may consume many times more resources
        than unicast;
     . Multicast-power-consumption issue: multicast consumes more
        power of the sender; In addition, an L2 broadcast message may
        reach more nodes than the L3 multicast intended.  This may
        consume some receiving nodes' power unnecessarily. For power
        constrained nodes, this is an issue;
     . Multicast-reliability issue: some multicast messages may not
        reach the destinations. Sleeping nodes may not respond to a
        multicast message. As a result, protocol procedures that rely
        on multicast can be unreliable.

   Existing ND solutions that can prevent or address multicast issues
   include:















Xiao                   Expires August 16, 2022                 [Page 4]


Internet-Draft         ND-deployment-guidelines           February 2022


     . Mobile Broadband IPv6 (MBBv6) and Fixed Broadband IPv6 (FBBv6):
        MBBv6 is defined in "IPv6 in 3GPP EPS" [RFC6459] and "IPv6 for
        3GPP Cellular Hosts" [RFC7066]. MBBv6 isolates each host in L2
        by putting it in a P2P link with the router. FBBv6 is defined
        in "IPv6 in the context of TR-101" [TR177]. FBBv6 also isolates
        each host in l2, either by putting it in a P2P link with the
        router, or by implementing split horizon on Ethernet to prevent
        direct host communication. Note that a host here is either a
        mobile User Equipment (UE), or a routed Residential Gateway
        (RG), or a real host (e.g. a computer) behind a bridged RG. The
        router here is either the mobile gateway or the Broadband
        Network Gateway (BNG). MBBv6 and FBBv6 also give each host a
        unique prefix and thus put it in its own subnet. Consequently,
        every host can only communicate with the router in both L2 and
        L3, and there is effectively no multicast.

        Note 1: because in FBBv6, bridged RG situation is very similar
        to routed RG situation, except that in the former, the hosts
        are real hosts (e.g. computers), while in the latter, the hosts
        are the routed RGs. For description simplicity, bridged RGs
        will not be further discussed in the document.

     . Wireless ND (WiND): the solution is defined in a series of RFCs
        [RFC6775][RFC8505][RFC8928][RFC8929]. WiND changes host and
        router behaviors to use multicast only for router discovery and
        not for other protocol procedures. The key points are (1) hosts
        use unicast to proactively register their addresses at the
        routers; (2) routers use unicast to communicate with hosts, and
        become the central address register and arbitrator for the
        hosts. Router also proactively installs Neighbor Cache Entries
        (NCEs) for the hosts; (3) each host communicates only with the
        router. Consequently, multicast is largely eliminated;

     . Unique IPv6 Prefix per Host (UPPH) [RFC8273]: this solution
        gives each host a unique prefix, thus puts it in its own
        subnet. Multicast is greatly reduced, because (1) a host will
        not use multicast for address resolution for other hosts,
        because there is no other host in the same subnet; (2)
        downstream multicast from router to hosts are eliminated and
        turned into unicast ([RFC8273] Section 4 Paragraph 3).

        Note 2: the pros and cons of RFC8273 will be briefly reviewed
        in Section 3.1. An in-depth discussion can be found in [8273D].

     . IP Point to Point Ethernet Subnet Model [P2Peth]: if
        progressed, this draft may provide a solution similar to



Xiao                   Expires August 16, 2022                 [Page 5]


Internet-Draft         ND-deployment-guidelines           February 2022


        RFC8273, making use of unique prefix per host to reduce
        multicast.

2.2. DAD-unreliable Issue and Solutions

   Duplicate Address Detection (DAD) uses absence of response as
   indication of no duplicate. This can be unreliable for two reasons.
   Firstly, the Neighbor Solicitation or the Neighbor Advertisement
   messages may be lost in transmission, especially in wireless
   environment. Secondly, sleeping nodes may not respond to the DAD
   messages.

   Existing ND solutions that can prevent or address DAD-unreliable
   issue include:

     . MBBv6 and FBBv6: for MBBv6, the UE's Interface ID (IID) is
        assigned by the mobile gateway, and is guaranteed to be unique
        [RFC6459]. There is no need for DAD. For FBBv6, the RG's Global
        Unicast Address (GUA) prefix is unique. There will be no
        duplicate for GUA address, and no DAD will be performed. RG
        will perform DAD for its Link Local Address (LLA), but only to
        the BNG [TR177]. In such an environment, there is no sleeping
        node or lossy media. DAD has no reliability issue.

     . WiND: every host must register its address at the router before
        using it. The registration will succeed only if the router
        explicitly approves it, and the router will not approve if it
        is a duplicate. Therefore, the DAD procedure becomes reliable.

     . RFC8273: For GUA addresses, since each host is given a
        different prefix, duplicate address will not exist. For link
        local address, since each subnet has only one host, there is no
        possibility of duplication in the subnet. A duplicate link
        local address may exist in another subnet but that does not
        matter. Therefore, DAD-unreliable issue is prevented.

2.3. On-demand NCE Installation Issue and Solutions

   ND address resolution is on-demand. It is done only when a packet
   needs to be sent but the link layer address of the on-link
   destination is unknown. Consequently, the packet has to be queued
   until link layer address is determined. This increases delay and may
   affect application performance. For high performance environment,
   this can be an issue.





Xiao                   Expires August 16, 2022                 [Page 6]


Internet-Draft         ND-deployment-guidelines           February 2022


   Existing ND solutions that can prevent or address on-demand NCE
   installation issue include:

     . MBBv6 and FBBv6: MBBv6 and some FBBv6 use IPv6 over PPP
        [RFC5072]. In this case, there is no need to find out the link
        layer address before sending a packet on the PPP interface. In
        other words, there is no NCE installation issue. Some FBBv6
        implementations use IPoE. There is a need for NCE. But because
        every host is given a unique prefix by the BNG in FBBv6, the
        BNG needs to know the host's link layer address which uniquely
        identify the host in order to do so. Therefore, the BNG can
        install NCE when assigning a prefix to the host, not waiting
        until a data packet is to be sent to that host. On-demand NCE
        installation issue is therefore avoided in this case too.

     . Wireless ND (WiND): when hosts register their IPv6 addresses,
        they will also present their link layer address. Therefore, NCE
        entries can be installed proactively before data packets
        arrive.

     . Gratuitous Neighbor Discovery [GRAND]: this solution changes
        router and host behaviors to allow routers to proactively
        create an NCE when a new IPv6 address is assigned to a host,
        and to recommend that hosts send unsolicited Neighbor
        Advertisements upon having a new IPv6 address. It can be
        considered as the IPv6 equivalent of Gratuitous ARP in IPv4.

2.4. Security Issues and Solutions

   ND assumes all nodes can be trusted. Otherwise, ND has various
   security issues.  These issues are described in [RFC3756][RFC6583]
   and [RFC9099]. They are briefly summarized here.

   The security issues can be classified into two categories:

     . Redirect attacks, in which a malicious node redirects packets
        destined for the first-hop router or a legitimate receiver to
        itself. This is usually done by faking the source IPv6 address
        to pretend to be another node, or by sending Router
        Advertisement to pretend to be a router. For example:

          o  an attacker can send out Router Advertisement claiming
             itself as the first-hop router, and redirect hosts'
             traffic to itself.





Xiao                   Expires August 16, 2022                 [Page 7]


Internet-Draft         ND-deployment-guidelines           February 2022


          o  an attacker can send Neighbor Advertisements to the first-
             hop router, spoofing the IPv6 address of another node
             while using its own link layer address. This will redirect
             traffic from the router to the victim to the attacker
             instead.

     . Denial-of-Service (DoS) attacks, in which a malicious node
        prevents communication between the victim node and other nodes.
        For example:

          o  Whenever a host performs DAD, an attacker can reply to
             claim that the selected address is in use. The host will
             not be able to get an address.

          o  /64 scan attack: an attacker sends packets to up to 2**64
             mostly non-existing hosts, forcing the first-hop router to
             try to install NCEs for this huge number of non-existing
             hosts. If unprotected, the router will run out of resource
             and stop functioning. Note that for other attacks to
             happen, the attacker must be on-link. But for this /64
             scan attack, the attacker can be off-link.

   It is worth noting that redirect attacks are generally considered as
   more harmful than DoS attacks. Therefore, higher priority is given
   to protect against redirect attacks.

   Existing ND solutions that can prevent or address the security
   issues include:

     . MBBv6 and FBBv6: because every host is isolated in L2, all on-
        link security issues are prevented. Because every host has its
        own prefix, and the mobile gateway or BNG maintains state
        information for the prefix instead of for individual IPv6
        address, off-link /64 scan attack will not cause harm - the
        mobile gateway or BNG will not create an NCE for every IP
        address in the /64. Such attack messages can simply be dropped.

     . WiND: normally, every host is isolated in L2 and can only
        communicate with the first-hop router. Therefore, all on-link
        security issues are prevented. But if hosts are not isolated in
        L2, e.g. when there is a bridge between the hosts and the
        router, then on-link security issue can happen.  Off-link /64
        scan attack will not cause harm because in WiND, NCE
        installation is proactive. In other words, the router will not
        create any NCE when receiving such messages. Such attack
        messages can simply be dropped.



Xiao                   Expires August 16, 2022                 [Page 8]


Internet-Draft         ND-deployment-guidelines           February 2022


     . RFC8273: by giving each host a different prefix and keep track
        of host-prefix binding, an attacker host cannot change the NCE
        at the router for another host by sending Neighbor
        Advertisement with a spoofed source IPv6 address of that host.
        The attacker thus cannot redirect traffic from router to that
        host to itself. The router will maintain only one NCE entry for
        each prefix/host. Therefore, off-link /64 scan attack will not
        cause harm. RFC8273's protection effect against other security
        issues depends on whether the hosts are also isolated in L2. If
        yes, all the on-link security issues will be prevented. If not,
        certain on-link security issues remain.

     . Source Address Validation Improvement [SAVI], Router
        Advertisement Guard [RA-Guard][RA-Guard+]: these solutions
        protect against redirect attacks and some DoS attacks. 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. Therefore, nodes on other
        ports cannot pretend to be a router.  In order to protect
        against some other DoS attacks, e.g. off-link /64 scan attack,
        other security measures are needed, e.g. rate limiting on NSs,
        and filtering on NAs/RAs.

     . Secure Neighbor Discovery [SeND] and Cryptographically
        Generated Addresses [CGA]: these solutions have tried to make
        ND secure, but have not been widely deployed. They will not be
        further discussed in this document.

2.5. Observations on the Solutions and an Insight Learned

   MBBv6 and FBBv6 prevent or solve all the ND issues. These solutions
   have two common characteristics that are effective for preventing or
   solving ND issues:

      (1)  Hosts (i.e. UEs or RGs or real hosts) are isolated in L2 and
           in different subnets.
      (2)  The first-hop router (i.e. mobile gateway or BNG) maintains
           some state information across reboots, e.g. prefix to host
           binding. The router also maintains some controls over the
           hosts, e.g. which prefix each host gets.

   WiND prevents or solves all the ND issues in its deployment
   scenarios, e.g. Low power and Lossy Networks (LLNs) [RFC7102]. WiND
   also has two characteristics:




Xiao                   Expires August 16, 2022                 [Page 9]


Internet-Draft         ND-deployment-guidelines           February 2022


      (1)  Hosts are normally isolated in L2 but not in different
           subnets. In the rare cases where hosts are not isolated in
           L2, e.g. because there is a bridge between the hosts and the
           router, then some ND issues like on-link security issues may
           happen, and additional solutions will be needed to address
           those issues.
      (2)  The first-hop router maintains some state information across
           reboots, e.g. host's address registration result including
           IPv6 address to link layer address binding. The router also
           uses such state information to maintain some controls over
           the hosts, e.g. which host wins when there is an address
           contention.

   RFC8273 solves certain ND issues but not all. It has two
   characteristics:

      (1)  Hosts are isolated in different subnets, but RFC8273 does
           not specify whether hosts should also be isolated in L2. If
           hosts are also isolated in L2, all ND issues will be
           prevented.
      (2)  The first-hop router maintains some state information across
           reboots, e.g. prefix-host binding. The router also maintains
           some controls over the hosts, e.g. which prefix a host gets.

   SAVI, RA-Guard, RA-Guard+ and GRAND solve specific ND issues. They
   have two characteristics:

      (1)  These solutions make no assumptions on L2 isolation or
           subnet isolation. They just solve the ND issues that they
           are designed to solve.
      (2)  SAVI maintains some state information at the Ethernet switch
           between the hosts and the first-hop router(s). Such states
           are learned dynamically from packet snooping, or configured
           manually. The Ethernet switch uses such state information to
           control the hosts, e.g., RAs are not allowed from the hosts.

   An insight can be learned from these observations. That is, L2
   isolation and subnet isolation can be effective in preventing ND
   issues. But L2 isolation and subnet isolation also have their cost.
   For example, because hosts are isolated and cannot directly
   coordinate with each other, the router must have new functionality
   to coordinate the hosts, e.g. to be the arbitrator when there is an
   address contention. In order to do so, the router must maintain some
   state information, e.g. the (IP address, link layer address) binding
   for each host.




Xiao                   Expires August 16, 2022                [Page 10]


Internet-Draft         ND-deployment-guidelines           February 2022


   The next section discusses how to apply this insight to future ND
   deployments.

3. Isolating Hosts in L2 and in Subnet to Simplify ND Deployment

3.1. Applicability of L2 Isolation and Subnet Isolation

   This section describes how to isolate hosts in L2 and in subnet, and
   the advantages and disadvantages of doing so.

   Isolating hosts in L2 can be done by: (1) putting a host in a P2P
   link with the router, or (2) using private VLAN [PVLAN], or split
   horizon [TR177], or wireless isolation [W-Iso] on multi-access
   medium to prevent hosts from communicating with each other. These
   are a matter of device configuration so it can usually be done as
   long as the devices support these isolating features.

   Isolating hosts in L2 is different from setting ND Prefix
   Information Option (PIO) L-bit=0. For example, in the latter, there
   can be multiple hosts in a link, and a malicious host can launch on-
   link security attacks at other hosts.

   When hosts are isolated in L2, DAD messages can only reach the
   router but no other hosts. Therefore, the router must act to prevent
   hosts from using duplicate GUA or link local address.  This
   functionality is called DAD Proxy [TR177][RFC6957].

   The advantages of isolating hosts in L2 include:

   o  Prevention of on-link security and upstream multicast issues
      (from hosts), because hosts cannot reach each other directly.

   The disadvantage of isolating hosts in L2 include:

   o  The router must support additional functionality: DAD Proxy.

   o  Downstream multicast issues, DAD-unreliable issue, On-demand NCE
      Installation issue and off-link /64 scan issue still remain.

   o  All host communication must go through the router. In a high
      performance environment, the router may become the bottleneck.

   o  Services relying on multicast, e.g. Multicast DNS [mDNS], will
      not work, unless the router can provide multicast proxy.





Xiao                   Expires August 16, 2022                [Page 11]


Internet-Draft         ND-deployment-guidelines           February 2022


   o  There is additional work (e.g. PVLAN, split horizon or wireless
      isolation) to isolate hosts in L2 in multi-access media, but this
      is small amount of work.

   o  Many more interfaces or sub-interfaces are likely needed on the
      router, for example if point-to-point VLANs are used for L2
      isolation.

   From the analysis above, it is clear that L2 isolation alone is not
   advantageous. The benefits are small while the costs are high.
   Therefore, L2 isolation is better used with something else, e.g.
   subnet isolation or some specially designed solutions like WiND.

   The known solutions supporting host isolation in L2 include WiND,
   and in more special cases (i.e. with both L2 and subnet isolation),
   MBBv6 and FBBv6.

   Host isolation in subnet (i.e. Unique Prefix Per Host, or UPPH) can
   be done either with [DHCPv6], where the prefix can be of any length
   supported by DHCPv6, or with SLAAC as specified in RFC8273, where
   the prefix must be /64 or shorter. If [P2Peth] is progressed, it can
   provide another solution.

   In order to isolate hosts in subnet, the router must be able to
   assign a unique prefix to each host and keep track of the prefix-
   host link layer address binding. This will be referred to as "UPPH
   support" later in this document. This may be achieved by some
   mechanism that RFC8273 alluded to but did not specify, or by some
   other mechanisms if DHCPv6 is used [TR177]. Note that with
   SLAAC/RFC8273, such router implementation exists [8273D], while with
   DHCPv6, FBBv6-capable BNG is one of such implementations.

   The advantages of isolating hosts in subnet are:

   o  Downstream Multicast, DAD-unreliable, on-demand NCE installation
      and off-link /64 scan issues are prevented.

   o  It is the only way for the router to do subscriber management for
      the hosts in a SLAAC environment. Imagine a public Wi-Fi scenario
      where the mobile UEs only support SLAAC. If the router does not
      give each UE a unique prefix and keep track of UE-prefix binding,
      network administrators do not know which IPv6 address corresponds
      to which UE, because each UE picks its own IID and uses the same
      prefix.  Therefore, network administrators cannot keep track of
      which UE did what. This would be unacceptable from an operation
      perspective.



Xiao                   Expires August 16, 2022                [Page 12]


Internet-Draft         ND-deployment-guidelines           February 2022


   The disadvantages of isolating hosts in subnet are:

   o  The routers must support new functionality: "UPPH support".

   o  Upstream multicast and on-link security issues can happen, unless
      the hosts are also isolated in L2

   o  Many prefixes will be needed instead of just one. But this
      disadvantage may not be as severe as it appears. After all, 3GPP
      has given every mobile UE a /64 [RFC6459], and BBF has given
      every routed RG a /56 with DHCPv6 PD [TR177]. Outside of MBB, FBB
      and IoT, not many scenarios have a large number of hosts. Giving
      each host a /64 prefix may not be a problem.

   o  Many more interfaces or sub-interfaces are needed on the router.

   The known solutions supporting subnet isolation include RFC8273, and
   in more special cases (i.e. supporting both L2 isolation and subnet
   isolation), MBBv6 and FBBv6.

   The above analysis reveals that L2 isolation and subnet isolation
   are synergetic.  When they are done together, the advantages are:

   o  All ND issues are prevented.

   o  It provides a way for the router to do subscriber management for
      the hosts in a SLAAC environment.

   o  DAD Proxy needed for L2 isolation is no longer needed, because
      with unique prefix per host, GUA cannot be duplicate. For link
      local address, since each subnet has only one host, there is no
      possibility of duplication. A duplicate link local address may
      exist in another subnet but that does not matter. Therefore,
      there is no need for DAD Proxy to prevent duplicate GUA/LLA
      addresses.

   The disadvantages are:

   o  The routers must support new functionality: "UPPH support".

   o  Many prefixes will be needed, one per host.

   o  All host communication must go through the router. In a high
      performance environment, the router may become the bottleneck.





Xiao                   Expires August 16, 2022                [Page 13]


Internet-Draft         ND-deployment-guidelines           February 2022


   o  Services relying on multicast, e.g. mDNS, will not work, unless
      the router can provide multicast proxy.

   o  There is additional work (e.g. PVLAN, split horizon or wireless
      isolation) to isolate hosts in L2 in multi-access media, but this
      is small amount of work.

   o  Many more interfaces or sub-interfaces are needed on the router.

   The known solutions supporting host isolation in L2 and in subnet
   include RFC8273, MBBv6 and FBBv6.

3.2. Deployment Guidelines

   Given the applicability analysis in Section 3.1, network
   administrators can decide where to use which isolation option. Note
   that in all the following steps, if DHCPv6 (IA_NA or PD) is
   supported and desired, use DHCPv6 to assign address prefix, as it
   may provide prefix length flexibility. Otherwise, use SLAAC as SLAAC
   is more widely supported.

  1. If isolating hosts in both L2 and in subnet is desirable and
     feasible:

     Based on the applicability discussion in Section 3.1, the
     scenarios here likely have some or all of the following
     characteristics: (1) It is a public access environment where
     subscriber management is needed; (2) Many ND issues can happen and
     will require solutions. This is why it is desirable to prevent as
     many issues as possible, to simplify the deployment; (3) Neither
     high performance communication nor multicast service discovery is
     applicable here.

     With suitable "UPPH support", all the ND issues will be prevented.
     Some possible "UPPH support" solutions are:

       a) If the deployment scenario is MBB or FBB, then MBBv6 or FBBv6
          can be used.

       b) Otherwise, use a RFC8273 implementation (using SLAAC) to
          realize "UPPH support". Note that this is a special use case
          of RFC8273 where each host is not only given a unique prefix,
          but also isolated from other hosts in L2.

  2. Otherwise, if isolating hosts in L2 but not in subnet is
     considered appropriate:



Xiao                   Expires August 16, 2022                [Page 14]


Internet-Draft         ND-deployment-guidelines           February 2022


     In this scenario, hosts are in different links but in the same
     subnet. This architecture is called Multi-Link SubNet (MLSN). MLSN
     has been a controversial scheme in the IETF. The original IPv6
     Addressing Architecture [RFC1884] stated that "IPv6 continues the
     IPv4 model that a subnet is associated with one link.  Multiple
     subnets may be assigned to the same link". This ruled out MLSN in
     the IPv6 WG (now 6man). However, some other WGs like MANET and 6lo
     use MLSN in their solutions [RFC7668][RFC8929]. [RFC4903]
     documented the concerns about MLSN.

     For solutions related to ND, only WiND supports MLSN. Therefore,
     the deployment scenario here is most likely one that WiND is
     suitable for, e.g. Low-power and Lossy Networks (LLNs). WiND has
     all functionalities needed for this scenario, including proactive
     address registration. WiND prevents all the ND issues but is a
     relatively sophisticated protocol that requires changes to both
     router and host behaviors from normal ND.

  3. Otherwise, if isolating hosts in subnet but not in L2 is
     considered appropriate:

     Based on the applicability discussion in Section 3.1, the
     scenarios here likely have the following characteristics: (1)
     Subscriber management is needed. This is likely a public access
     scenario. (2) Upstream multicast is needed or cannot be avoided
     (otherwise L2 host isolation would have been selected to prevent
     more issues), e.g. for service discovery. RFC8273 can be used as
     the solution here. On-link security is not prevented in this case.
     Because this is a public access scenario, SAVI/RA-Guard/RA-Guard+
     may be needed to address the on-link security issue.

  4. Otherwise, no isolation in L2 or subnet is desired or feasible.

     The scenarios here likely have the following characteristics: (1)
     It is a private environment, because subscriber management is not
     needed. As such, on-link security is not a big concern. (2) Either
     multicast service is needed, or this is a high performance
     scenario, because L2 host isolation is not desired.  Either way,
     multicast and DAD-unreliable are not a concern. Normal ND can be
     used as the solution. Off-link /64 scan and on-demand NCE
     installation are the two issues left. Off-link /64 scan issue can
     be handled by rate limiting or unused-address filtering. If this
     is indeed a high performance environment, e.g. a DC network, GRAND
     can be used to enable proactive NCE installation.





Xiao                   Expires August 16, 2022                [Page 15]


Internet-Draft         ND-deployment-guidelines           February 2022


   In short, the guidelines can be summarized as: if many of the ND
   issues discussed in Section 3 are valid concerns and need to be
   addressed, then isolate hosts in L2 and in subnet to prevent the
   issues, and use RFC8273. If the scenario is LLN, use WiND. But if
   the scenario is a private environment where many ND issues are not
   real concerns, then just use normal ND, and adds other solutions
   like GRAND only when needed. Overall, these guidelines will likely
   result in the simplest ND solution.

4. Impact of L2 Isolation and Subnet Isolation to Other Components of
   IPv6 First-hop

   The guidelines in section 3 will likely simplify ND deployment. But
   will they complicate other components of IPv6 first-hop?  A
   preliminary impact analysis is done in this section.

   IPv6 first-hop consists of:

   o  The routers and the hosts, whose requirements & behaviors are
      defined in [RFC8504];

   o  Addressing scheme;

   o  The basic protocol suite: ND, SLAAC, DHCPv6, DNS, ICMPv6, MLD
      v1/v2;

   o  Other extended protocols: mDNS.

   The impact of host isolation in L2 and in subnet to other components
   of IPv6 first-hop comes from five parts: (1) the special topology
   introduced by L2 isolation; (2) the special addressing scheme
   introduced by subnet isolation (i.e. unique prefix per host); (3)
   the new functionalities introduced to the router, i.e. "DAD Proxy"
   for L2 isolation. (4) The increased number of interfaces on the
   router (5) When WiND is used, hosts must be changed to support
   proactive address registration etc. This is a high requirement that
   can be considered as complicating the IPv6 first-hops.  But WiND
   appears to be the only solution in its applicable scenarios like
   LLNs.  When there is no alternative, there is no need to discuss
   whether the solution unduly complicates other components of IPv6
   first-hop.  Therefore, WiND will not be further discussed. Because
   DAD Proxy is only needed in L2 isolation but not in subnet
   isolation, and this scenario uses WiND which already provides DAD
   Proxy, DAD Proxy will not be further discussed either.

   First, regarding the impact from the special topology:



Xiao                   Expires August 16, 2022                [Page 16]


Internet-Draft         ND-deployment-guidelines           February 2022


   Isolating hosts should only affect the protocols that rely on
   multicast, i.e. ND, SLAAC and mDNS, but not the multicast protocols
   themselves, i.e. MLD v1/v2. As discussed in Sections 2 and 3, the
   impact to ND and SLAAC are positive. The impact to mDNS is negative.
   But the guidelines give network administrators the option not to
   isolate hosts at all. So if network administrators choose to
   isolate, the benefit must outweigh the cost, e.g. mDNS may not be
   needed in the deployment scenario.

   Second, regarding the impact from the special addressing scheme:

   IPv6 first-hop should allow any addressing scheme. Other than using
   more prefixes, it is not envisioned that unique prefix per host
   complicates addressing scheme in any way. After all, unique prefix
   per host is already widely in use in MBBv6 and FBBv6 deployments.

   Third, regarding the impact of new router functionality "UPPH
   support":

   The impact of "UPPH support" with RFC8273 using SLAAC has been
   discussed in [8273D] before RFC8273 became an RFC. The following
   concerns had been raised:

     . RFC8273 makes the router stateful;
     . How to reclaim unused prefix is not specified;
     . If there are multiple first-hop routers, how the solution works
        is unspecified: (1) do they assign prefixes to hosts
        independently? (2) do they need to sync up with each other?
     . Resiliency of SLAAC may be reduced as a result of the increased
        state at the router, i.e. the prefix-host binding.

   Given that RFC8273 became an RFC, the rough consensus has been its
   benefit outweighs the cost. Because MBBv6 and FBBv6 also support
   UPPH and are widely deployed, the impact of "UPPH support" appears
   manageable.

   Fourth, regarding the impact of increased number of interfaces on
   the router: for the consumer market where the number of hosts (i.e.
   subscribers) is large, this may increase the number of routers
   needed in the first-hop. However, for the consumer market, MBBv6,
   FBBv6 and some public Wi-Fi deployments are already using L2
   isolation & subnet isolation before the guidelines are proposed. So
   the guidelines bring no additional burden.  Outside of consumer
   market, a router can generally provide more interfaces than needed.
   So this increase should not be a problem either.




Xiao                   Expires August 16, 2022                [Page 17]


Internet-Draft         ND-deployment-guidelines           February 2022


   All things considered, it appears that isolating hosts in L2 and in
   subnet can simplify ND without unduly complicating other components
   of IPv6 first-hop.

5. Applying the Guidelines to Real World Scenarios

   The guidelines are intended for future IPv6 first-hop deployments.
   But if we test the guidelines on well-known IPv6 first-hop scenarios
   to find the suitable ND solution, the result will be as follows:

   o  MBB and FBB will end at Step 1.a: isolating hosts in L2 and in
      subnet, with MBBv6 as the solution with SLAAC and FBBv6 as the
      solution with DHCPv6, respectively;

   o  Public Wi-Fi network will end at Step 1.b: isolating hosts in L2
      and in subnet, with RFC8273 as the solution with SLAAC, since the
      hosts here may be mobile UEs that do not support DHCPv6. Note
      that in Wi-Fi with the Infrastructure Mode [WiFi-inf], each host
      (i.e. STA) communicates only with the Access Point (AP). With
      wireless isolation, every host can only communicate with the AP
      (and the router if the AP is not a router), not directly with
      other hosts. This is how L2 isolation can be achieved in this
      scenario. If L2 isolation is not done, then public Wi-Fi will end
      at Step 3. SAVI/RA-Guard/RA-Guard+ may be needed to address the
      on-link security issue.

   o  Low-power and Lossy Networks (LLNs) will end at Step 2: isolating
      hosts in L2 but not in subnet, with WiND as the solution with
      SLAAC. Note that although WiND did not mandate L2 isolation, WiND
      works better when hosts are isolated in L2. Otherwise, additional
      mechanisms may be needed to address on-link security issues.

   o  High speed DC Networks will end at Step 4: using normal ND with
      GRAND without host isolation in L2 or in subnet. SAVI, RA-Guard
      and RA-Guard+ may not be needed as high physical access security
      is likely maintained.

   o  Common enterprise LANs with mixed Ethernet and Wi-Fi (not DC
      networks) will end at:

       o  If security is a concern to justify host isolations:

            . Step 1.b: isolating hosts in L2 and in subnet, with
               RFC8273 as the solution with SLAAC;.

       o  If security is not a concern to justify host isolations:



Xiao                   Expires August 16, 2022                [Page 18]


Internet-Draft         ND-deployment-guidelines           February 2022


            . Step 4: using normal ND with no special host isolation.
               GRAND and SAVI, RA-Guard and RA-Guard+ may not be
               needed.

   o  [HomeNet] will end at Step 4: using normal ND with no special
      host isolation. GRAND and SAVI, RA-Guard and RA-Guard+ are not
      needed.

   These results match current practices in reality. This validates the
   guidelines to some extent.

6. Security Considerations

   This document provides guidelines on where to isolate hosts in L2
   and in subnet to prevent ND issues, and how to select existing
   solutions for the remaining issues.  When a solution is selected,
   the security considerations of that solution apply. This document
   does not introduce any new mechanisms. Therefore, it does not
   introduce new security issues.

7. IANA Considerations

   This document has no request to IANA.

8. References

8.1. Informative References

   [8273D]   Discussion on the pros and cons of RFC8273,
             https://mailarchive.ietf.org/arch/msg/v6ops/M47lN8lyXaWVcx
             8nitvkxMfbGNA/

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

   [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",
             https://datatracker.ietf.org/doc/html/draft-ietf-6man-
             grand-07






Xiao                   Expires August 16, 2022                [Page 19]


Internet-Draft         ND-deployment-guidelines           February 2022


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

   [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, <https://www.rfc-
             editor.org/info/rfc4861>.

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

   [P2Peth]  O. Troan, "IP Point to Point Ethernet Subnet Model",
             https://datatracker.ietf.org/doc/draft-troan-6man-p2p-
             ethernet/

   [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J.
             Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI
             10.17487/RFC6105, February 2011, <https://www.rfc-
             editor.org/info/rfc6105>.

   [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router
             Advertisement Guard (RA-Guard)", RFC 7113, DOI
             10.17487/RFC7113, February 2014, <https://www.rfc-
             editor.org/info/rfc7113>.

   [RFC1884] R. Hinden, S.Deering, "IP Version 6 Addressing
             Architecture", RFC 1884.

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

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

   [RFC5072] S. Varada, D. Haskins, E. Allen, "IP Version 6 over PPP",
             RFC 5072

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

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




Xiao                   Expires August 16, 2022                [Page 20]


Internet-Draft         ND-deployment-guidelines           February 2022


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

   [RFC7668] J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z.
             Shelby, C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy",
             RFC7668.

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

   [RFC8504] T. Chown, J. Loughney, T. Winters, "IPv6 Node
             Requirements", RFC 8504, January 2019, <https://www.rfc-
             editor.org/info/rfc8504>.

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

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

   [RIPE IPv6 security] RIPE NCC, "IPv6 Security Training Course",
             https://www.ripe.net/support/training/material/ipv6-
             security/ipv6security-slides.pdf

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



Xiao                   Expires August 16, 2022                [Page 21]


Internet-Draft         ND-deployment-guidelines           February 2022


   [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, DOI
             10.17487/RFC4862, September 2007, <https://www.rfc-
             editor.org/info/rfc4862>.

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

   [WiFi-inf] Wi-Fi Infrastructure Mode,
             https://www.howtogeek.com/180649/htg-explains-whats-the-
             difference-between-ad-hoc-and-infrastructure-mode/

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

9. Acknowledgments

   The authors would like to thank Eduard Vasilenko, Pascal Thubert,
   and Ole Troan for the discussion and input.

Authors' Addresses

   XiPeng Xiao
   Huawei Technologies
   Hansaallee 205, 40549 Dusseldorf, Germany

   Email: xipengxiao@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







Xiao                   Expires August 16, 2022                [Page 22]