3. Review of ND Mitigation Solutions

Table 1 summarizes ND mitigation solutions available for Issues 1-15 described in Section 2.4. Similar solutions are grouped, beginning with those that address the most issues. Unrelated solutions are ordered based on the issues (listed in Section 2.4) they address. Each solution in the table will be explained in a sub-section later, where abbreviations in the table are described.

In Table 1, a letter code indicates the RFC category of the mitigation solution (see BCP 9 [RFC2026] for an explanation of these categories):

• S: Standards Track (Proposed Standard or Internet Standard)
• E: Experimental
• I: Informational
• B: Best Current Practice
• N/A: Not Applicable (not an RFC)

The abbreviations in Table 1 correspond to Section 2.4 as follows:

• On-link sec.: Trusting-all-nodes related issues
• NCE exh.: NCE exhaustion
• Fwd. delay: Router forwarding delay
• No addr. acc.: Lack of address accountability

Table 1: Solutions for Identified Issues

ND solution	RFC cat.	Multicast performance	Reliability	On-link sec.	NCE exh.	Fwd. delay	No addr. acc.
		1	2	3	4	5	6
MBBv6	I	All identified issues solved
FBBv6	N/A	All identified issues solved
UPPH	I		X		X	X
WiND	S	All issues solved for Low-Power and Lossy Networks (LLNs)
SARP	E					X
ND TRILL	S					X
ND EVPN	S					X
RFC 7772	B		X
GRAND	S				X
SAVI/RA-G	I
RFC 6583	I
RFC 9686	S

3.1. Mobile Broadband IPv6 (MBBv6)

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

• Putting every host (e.g., the mobile User Equipment (UE)) in a Point-to-Point (P2P) link with the router (e.g., the mobile gateway) has the following outcomes:

  • All multicast is effectively turned into unicast.
  • The P2P links do not have a MAC address. Therefore, Router-NCE-on-Demand is not needed.
  • Trusting-all-nodes is only relevant to the router. By applying filtering at the router (e.g., dropping RAs from the hosts), even malicious hosts cannot cause harm.

• Assigning a unique /64 prefix to each host. Together with the P2P link, this puts each host on a separate link and subnet.

• Maintaining (prefix, interface) binding at the router for forwarding purposes.

Since all the three causes of ND issues are addressed, all the issues discussed in Section 2.4 are addressed.

3.2. Fixed Broadband IPv6 (FBBv6)

The IPv6 solution defined in "IPv6 in the context of TR-101" [TR177] is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has two flavors:

• P2P: Every host (e.g., the Residential Gateway (RG)) is in a P2P link with the router (e.g., the Broadband Network Gateway (BNG)). In this case, the solution is functionally similar to MBBv6. All ND issues discussed in Section 2.4 are solved.

• Point to Multipoint (P2MP): All hosts (e.g., the RGs) connected to an access device (e.g., the Optical Line Terminal (OLT)) are in a P2MP link with the router (e.g., the BNG). This is achieved by placing all hosts in a single VLAN on the router and configuring the OLT to block any frame from being forwarded between its access ports; traffic from each host can travel only up toward the router, not sideways to another host, thereby preventing direct host-to-host communication.

The following list summarizes the two key aspects of the FBBv6-P2MP architecture as described in [TR177] and the associated benefits:

• Implementing DAD proxy [RFC6957]:

  In a P2MP architecture described above, the normal ND DAD procedure will break down because hosts cannot exchange NSs with one another. To address this, the router participates in the DAD process as a DAD Proxy to resolve address duplication.

  The benefits are:

  • Multicast traffic from all hosts to the router is effectively converted into unicast, as hosts can only communicate directly with the router.
  • The Trusting-all-nodes model is limited to the router. By applying simple filtering (e.g., dropping RAs from hosts), the router can mitigate security risks, even from malicious hosts.

• Assigning a unique /64 prefix to each host:

  Assigning each host a unique /64 prefix results in several operational improvements:

  • The router can proactively install a forwarding entry for that prefix towards the host, eliminating the need for Router-NCE-on-Demand.
  • Since each host resides in a different subnet, traffic between hosts is routed through the router, eliminating the need for hosts to perform address resolution for one another.
  • Without address resolution, router multicast to hosts is limited to unsolicited RAs. As each host resides in its own subnet, these RAs are sent as unicast packets to individual hosts. This follows the approach specified in [RFC6085], where the host's MAC address replaces the multicast MAC address in the RA.

Since all three causes of ND issues are addressed, all ND issues (Section 2.4) are also addressed.

3.3. Unique Prefix per Host (UPPH)

Unique Prefix per Host (UPPH) solutions are described in [RFC8273] and [RFC9663]. Both are Informational RFCs. [RFC8273] relies on SLAAC for unique prefix allocation while [RFC9663] relies on DHCPv6 Prefix Delegation (DHCPv6-PD). That difference in allocation mechanism does not change the discussion on ND issues, because every IPv6 node is still required to run SLAAC, even when it receives its prefix via DHCPv6-PD. Therefore, discussing [RFC8273] alone is sufficient.

[RFC8273] "improves host isolation and enhanced subscriber management on shared network segments" such as Wi-Fi or Ethernet. The key points are:

• When a prefix is allocated to the host, the router can proactively install a forwarding entry for that prefix towards the host. There is no more Router-NCE-on-Demand.

• Without address resolution, router multicast to hosts consists only of unsolicited RAs. They will be sent to hosts one by one in unicast because the prefix for every host is different.

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

Therefore, ND issues caused by Router-NCE-on-Demand and router multicast to hosts are prevented.

[RFC8273] indicates 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". However, when hosts are on a shared medium like Ethernet, ensuring "devices cannot send packets to each other except through the first-hop router" requires additional measures like Private VLAN [RFC5517]. Without such additional measures, on a shared medium, hosts can still reach each other in L2 as they belong to the same Solicited-Node Multicast Group. Therefore, Trusting-all-nodes and host multicast to routers may cause issues. Of the host multicast issues (i.e., Issues 1, 3, 5, 6, and 7), UPPH prevents Issues 5 and 7, because there is no need for address resolution among hosts (Issue 5), and there is no possibility of GUA duplication (Issue 7). However, Issues 1, 3, and 6 may occur.

3.4. Wireless ND (WiND)

The term "Wireless ND (WiND)" is used in this document to describe the fundamentally different ND solution for Low-Power and Lossy Networks (LLNs) [RFC7102] that is defined in [RFC6775], [RFC8505], [RFC8928], and [RFC8929] (Standards Track). WiND changes host and router behaviors to use multicast only for router discovery. The 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 NCEs for the hosts. This avoids the need for address resolution for the hosts.

• The router sets the Prefix Information Option (PIO) L-bit to 0. Each host communicates only with the router (Section 6.3.4 of [RFC4861]).

• Other functionalities that are relevant only to LLNs.

WiND addresses all ND issues (Section 2.4) in LLNs. However, WiND support is not mandatory for general-purpose hosts. Therefore, it cannot be relied upon as a deployment option without imposing additional constraints on the participating nodes.

3.5. Scalable Address Resolution Protocol (SARP)

The Scalable Address Resolution Protocol (SARP) [RFC7586] was an Experimental solution. That experiment ended in 2017, two years after the RFC was published. Because the idea has been used in mitigation solutions for more specific scenarios (described in Sections 3.6 and 3.7), it is worth describing here. The usage scenario is Data Centers (DCs), where large L2 domains span 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 pure or overlay L2 network.

The switch will snoop and install a (IP, MAC address) 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 address. In doing so, all hosts within a site will appear to have a single MAC address to other sites. As such, a switch only needs to build a MAC address table for the local hosts and the remote switches, not for all the hosts in the L2 domain. Consequently, the MAC address table size of the switches is significantly reduced. A switch will also add the (IP, MAC address) replies from remote switches to its proxy ND table so that it can reply to future address resolution requests from local hosts for such IPs directly. This greatly reduces the number of address resolution multicast in the network.

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

3.6. ND Optimization for TRILL

ARP and ND optimization for Transparent Interconnection of Lots of Links (TRILL) [RFC8302] (Standards Track) is similar to SARP (Section 3.5). It can be considered an application of SARP in the TRILL environment.

Like SARP, ND optimization for TRILL focuses on reducing multicast address resolution. That is, it addresses Issue 5 (Section 2.1).

3.7. Proxy ND in Ethernet Virtual Private Networks (ND EVPN)

Proxy ARP/ND in EVPN is specified in [RFC9161] (Standards Track). The usage scenario is DCs where large L2 domains span across multiple sites. In each site, multiple hosts are connected to a Provider Edge (PE) router. The PEs are interconnected by EVPN tunnels.

The PE of each site snoops the local address resolution NAs to build (IP, MAC address) Proxy ND table entries. PEs then propagate such Proxy ND entries to other PEs via the Border Gateway Protocol (BGP). Each PE also snoops local hosts' address resolution NSs for remote hosts. If an entry exists in its Proxy ND table for the remote hosts, 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. Reducing Router Advertisements per RFC 7772

Maintaining IPv6 connectivity requires that hosts be able to receive periodic multicast RAs [RFC4861]. Hosts that process unicast packets while they are asleep must also process multicast RAs while they are asleep. An excessive number of RAs can significantly reduce the battery life of mobile hosts. [RFC7772] (Best Current Practice) specifies a solution to reduce RAs:

• The router should respond to RS with unicast RA (rather than the normal multicast RA) if the host's source IP address is specified and the host's MAC address is valid. This way, other hosts will not receive this RA.

• The router should reduce the multicast RA frequency.

[RFC7772] addresses Issue 2 (Section 2.1).

3.9. Gratuitous Neighbor Discovery (GRAND)

GRAND [RFC9131] (Standards Track) 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 node and sets its state to STALE.

When a packet for the host later arrives, the router can use the existing STALE NCE to forward it immediately ([RFC4861], Section 7.2.2). It then verifies reachability by sending a unicast NS rather than a multicast one for address resolution. In this way, GRAND eliminates the router forwarding delay, but it does not solve other Router-NCE-on-Demand issues. For example, NCE exhaustion can still happen.

3.10. Source Address Validation Improvement (SAVI) and Router Advertisement Guard (RA-Guard)

Source Address Validation Improvement (SAVI) [RFC7039] (Informational) binds an address to a port on an L2 switch and rejects claims from other ports for that address. Therefore, a node cannot spoof the IP address of another node.

Router Advertisement Guard (RA-Guard) [RFC6105] [RFC7113] (Informational) only allows RAs from a port that a router is connected to. Therefore, nodes on other ports cannot pretend to be a router.

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

3.11. Dealing with NCE Exhaustion Attacks per RFC 6583

[RFC6583] (Informational) deals with the NCE exhaustion attack issue (Section 2.3). It recommends that:

• Operators should:

  • Filter unused address space so that messages to such addresses can be dropped rather than triggering NCE creation.
  • Implement rate-limiting mechanisms for ND message processing to prevent CPU and memory resources from being overwhelmed.

• Vendors should:

  • Prioritize NDP processing for existing NCEs over creating new NCEs.

[RFC6583] acknowledges that "some of these options are 'kludges', and can be operationally difficult to manage". [RFC6583] partially addresses the Router NCE exhaustion issue. In practice, router vendors cap the number of NCEs per interface to prevent cache exhaustion. If the link has more addresses than that cap, the router cannot keep an entry for every address, and packets destined for addresses without an NCE are simply dropped [RFC9663].

3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6 per RFC 9686

In IPv4, network administrators can retrieve a host's IP address from the DHCP server and use it for subscriber management. In IPv6 and SLAAC, this is not possible (Section 2.3).

[RFC9686] (Standards Track) defines a method for informing a DHCPv6 server that a host has one or more self-generated or statically configured addresses. This enables network administrators to retrieve the IPv6 addresses for each host from the DHCPv6 server. [RFC9686] provides a solution for Issue 15 (Section 2.3).

3.13. Enhanced DAD

Enhanced DAD [RFC7527] (Standards Track) addresses a DAD failure issue in a specific situation: a 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 [RFC3971] 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 ND issue. It extends ND to work in a new scenario: a looped-back interface. It is reviewed here only for completeness.

3.14. ND Mediation for IP Interworking of Layer 2 VPNs

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

ND mediation does not address any ND issue. It extends ND to work in a new scenario: two ACs of different media interconnected by a VPWS. It is reviewed here only for completeness.

3.15. ND Solutions Defined Before the Latest Versions of ND

The latest versions of ND and SLAAC are specified in [RFC4861] and [RFC4862]. Several ND mitigation solutions were published before [RFC4861]. They are reviewed in this section only for completeness.

3.15.1. Secure Neighbor Discovery (SEND)

The purpose of SEND [RFC3971] (Standards Track) is to ensure that hosts and routers are trustworthy. SEND defined three new ND options: Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce. In addition, SEND also defined an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in the ND protocol.

3.15.2. Cryptographically Generated Addresses (CGA)

The purpose of CGA is to associate a cryptographic public key with an IPv6 address in the SEND protocol. The key point is to generate the Interface Identifier (IID) of an 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 assumes that a legitimate host does not care about the bit combination of the IID that would be created by 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, which is a strong mathematical challenge.

CGA is part of SEND. There is no reported deployment.

3.15.3. ND Proxy

ND Proxy [RFC4389] (Experimental) aims to enable multiple links joined by an ND Proxy device to work as a single link.

• When an ND Proxy receives an ND request from a host on a link, it will proxy the message out the "best" (defined in the next paragraph) outgoing interface. 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 address to the ND Proxy's outgoing interface's IP and MAC address, 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 for 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 proxies the ND message back to the requesting host.

ND Proxy is widely used in SARP (Section 3.5), ND optimization for TRILL (Section 3.6), and Proxy ARP/ND in EVPN (Section 3.7).

3.15.4. Optimistic DAD

Optimistic DAD [RFC4429] (Standards Track) seeks to minimize address configuration delays in the successful case and to reduce disruption as far as possible in the failure case. That is, Optimistic DAD lets hosts immediately use the newly formed address to communicate before DAD completes, assuming that DAD will succeed anyway. If the address turns out to be duplicate, Optimistic DAD provides a set of mechanisms to minimize the impact. Optimistic DAD modified the original ND [RFC2461] and original SLAAC [RFC2462] (both of which are obsolete), but the solution was not incorporated into the latest specifications of ND [RFC4861] and SLAAC [RFC4862]. However, implementations of Optimistic DAD exist.

Optimistic DAD does not solve any ND issue (Section 2). It is reviewed here only for completeness.

---