RFC 9898

Neighbor Discovery Considerations in IPv6 Deployments

📅 published November 2025, from ietf

RFC 9898: Neighbor Discovery Considerations in IPv6 Deployments 💖

Okay bestie, let's start with the basics 🎀. This one is an Informational RFC from the IETF (not a Standards Track spec, just published for info 📚). It's dated November 2025, its ISSN is 2070-1721, and it's RFC 9898. It doesn't list any RFC it obsoletes or updates in its title block.

The authors are X. Xiao, E. Vasilenko (with Huawei Technologies listed alongside them), E. Metz (KPN N.V.), G. Mishra (Verizon Inc.), and N. Buraglio (Energy Sciences Network). Iconic team 👑.

Abstract 🌸

Okay so Neighbor Discovery (ND) is a critical part of the IPv6 architecture 😭. It uses multicast in lots of its messages, and it assumes everybody on a link is trusted. That can be inefficient in some situations (like multicast in wireless networks 📡) or cause trouble when nodes aren't trustworthy (like public access networks 🙈). These security and operational issues, plus their mitigation solutions, are written up in more than twenty RFCs, so the people who need to track them were kinda stuck jumping between docs. This RFC fixes that by putting them all in one place ✨.

It summarizes the published ND issues and shows how all of them come from three causes 💜. The big takeaway is that if you address the causes, the issues get way simpler to handle. It also analyzes the mitigation solutions and shows that isolating hosts into different subnets and links can help with those three causes 🧚. Last but not least, it gives guidance on picking a good isolation method to prevent potential ND issues 💅.

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc9898 🦋.

Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and are provided without warranty as described in the Revised BSD License.

Table of Contents 🗂️

1.  Introduction
  1.1.  Terminology
2.  Review of Inventoried ND Issues
  2.1.  Multicast May Cause Performance and Reliability Issues
  2.2.  Trusting-All-Nodes May Cause On-Link Security Issues
  2.3.  Router-NCE-on-Demand May Cause Forwarding Delay, NCE
        Exhaustion, and Address Accountability Issues
  2.4.  Summary of ND Issues
3.  Review of ND Mitigation Solutions
  3.1.  Mobile Broadband IPv6 (MBBv6)
  3.2.  Fixed Broadband IPv6 (FBBv6)
  3.3.  Unique Prefix per Host (UPPH)
  3.4.  Wireless ND (WiND)
  3.5.  Scalable Address Resolution Protocol (SARP)
  3.6.  ND Optimization for TRILL
  3.7.  Proxy ND in Ethernet Virtual Private Networks (ND EVPN)
  3.8.  Reducing Router Advertisements per RFC 7772
  3.9.  Gratuitous Neighbor Discovery (GRAND)
  3.10. Source Address Validation Improvement (SAVI) and Router
        Advertisement Guard (RA-Guard)
  3.11. Dealing with NCE Exhaustion Attacks per RFC 6583
  3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6 per
        RFC 9686
  3.13. Enhanced DAD
  3.14. ND Mediation for IP Interworking of Layer 2 VPNs
  3.15. ND Solutions Defined Before the Latest Versions of ND
    3.15.1.  Secure Neighbor Discovery (SEND)
    3.15.2.  Cryptographically Generated Addresses (CGA)
    3.15.3.  ND Proxy
    3.15.4.  Optimistic DAD
4.  Guidelines for Prevention of Potential ND Issues
  4.1.  Learning Host Isolation from the Existing Solutions
  4.2.  Applicability of Various Isolation Methods
    4.2.1.  Applicability of L3+L2 Isolation
    4.2.2.  Applicability of L3 Isolation
    4.2.3.  Applicability of Partial L2 Isolation
  4.3.  Guidelines for Applying Isolation Methods
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Okay bestie, so Neighbor Discovery (ND) [RFC4861] specifies the mechanisms that IPv6 nodes (hosts and routers) on the same link use to communicate and learn about each other 💅. Stateless Address Autoconfiguration (SLAAC) [RFC4862] builds on those ND mechanisms so nodes can configure their own IPv6 addresses 🦋. When you're figuring out what issues nodes might hit with ND, it helps SO much to look at the ND messages they exchange over their entire life cycle, with SLAAC in the picture too 🧚.

For a host, the overall procedure goes like this 🌈:

  1. LLA DAD: The host forms a Link-Local Address (LLA) and performs Duplicate Address Detection (DAD) using multicast Neighbor Solicitations (NSs).
  2. Router discovery: The host sends multicast Router Solicitations (RSs) to discover a router on the link. The router responds with Router Advertisements (RAs), providing subnet prefixes and other information. The host installs a Neighbor Cache Entry (NCE) for that router upon receiving the RAs. In contrast, the router cannot install an NCE for the host at this moment of the exchange because the host's global IP address is still unknown. When the router later needs to forward a packet to the host's global address, it will perform address resolution and install an NCE for the host.
  3. GUA DAD: The host forms a Global Unicast Address (GUA) [RFC3587] or a Unique Local Address (ULA) [RFC4193] and uses multicast NSs for DAD. For simplicity of description, this document will not further distinguish GUA and ULA.
  4. Next-hop determination and address resolution: When the host needs to send a packet, it first determines whether the next hop is a router or an on-link host (which is the destination). If the next hop is a router, the host already has the NCE for that router. If the next hop is an on-link host, it uses multicast NSs to perform address resolution for the destination host. As a result, the source host installs an NCE for the destination host.
  5. Node Unreachability Detection (NUD): The host uses unicast NSs to determine whether another node with an NCE is still reachable.
  6. Link-layer address change announcement: If a host's link-layer address changes, it may use multicast Neighbor Advertisements (NAs) to announce its new link-layer address to other nodes.

For a router, the procedure is similar except that there is no router discovery. Instead, routers perform a Redirect procedure that hosts do not have 🍓. A router sends a Redirect to inform a node of a better next hop for the node's traffic.

ND uses multicast in many messages and trusts messages from all nodes. On top of that, routers may install NCEs for hosts on demand when they're about to forward packets to those hosts. These can lead to issues 😬. Concretely, various ND issues and mitigation solutions have been published in more than 20 RFCs, including:

  • "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756]
  • "SEcure Neighbor Discovery (SEND)" [RFC3971]
  • "Cryptographically Generated Addresses (CGA)" [RFC3972]
  • "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]
  • "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
  • "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)" [RFC6459]
  • "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" [RFC7066]
  • "IPv6 in the context of TR-101" [TR177]
  • "Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs" [RFC6575]
  • "Operational Neighbor Discovery Problems" [RFC6583]
  • "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
  • "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505]
  • "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928]
  • "IPv6 Backbone Router" [RFC8929]
  • "Architecture and Framework for IPv6 over Non-Broadcast Access" [SND]
  • "Duplicate Address Detection Proxy" [RFC6957]
  • "Source Address Validation Improvement (SAVI) Framework" [RFC7039]
  • "IPv6 Router Advertisement Guard" [RFC6105]
  • "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" [RFC7113]
  • "Enhanced Duplicate Address Detection" [RFC7527]
  • "The Scalable Address Resolution Protocol (SARP) for Large Data Centers" [RFC7586]
  • "Reducing Energy Consumption of Router Advertisements" [RFC7772]
  • "Unique IPv6 Prefix per Host" [RFC8273]
  • "Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization" [RFC8302]
  • "Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers" [RFC9131]
  • "Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks" [RFC9161]
  • "Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks" [RFC9663]

This document summarizes these RFCs into a one-stop reference (as of the time of writing) for easier access. It also identifies three causes of the issues and defines three host isolation methods to address the causes and prevent potential ND issues ✨🎀.

1.1. Terminology

okay so this doc already uses the terms in [RFC4861] 💅 but it also defines a few extra ones in this section, so you don't get lost 🫶

  • MAC: Media Access Control 🎀 To avoid mixing things up with link-local addresses, link-layer addresses are called "MAC addresses" in this doc 💖
  • Host Isolation: separating hosts into different subnets or links 🌸
  • L3 Isolation: giving every host its own Unique Prefix per Host (UPPH) [RFC8273] [RFC9663] so every host is in a different subnet ✨ Since a unique prefix can be handed out per host on shared media, hosts in different subnets can still be on the same link 🧚
  • L2 Isolation: taking steps so a host can't reach other hosts directly at Layer 2 (L2), so every host is on a different link 🦋 Because of Multi-Link Subnet [RFC4903], hosts on different links can still end up in the same subnet 😭 So L2 Isolation doesn't imply L3 Isolation, and L3 Isolation doesn't imply L2 Isolation either 💀
  • L3+L2 Isolation: doing L3 Isolation and L2 Isolation at the same time, so every host is in a different subnet and on a different link 👑
  • Partial L2 Isolation: using an L3 ND Proxy [RFC4389] device to stand in for the hosts behind it when talking to other hosts in the same subnet 🌈 Inside the subnet, ND multicast exchange gets chopped into smaller scopes, and each one is represented by an ND Proxy device 🍓

2. Review of Inventoried ND Issues 🔥

2.1. Multicast May Cause Performance and Reliability Issues

okay so ND uses multicast for NSs, NAs, RSs, and RAs in some cases 🫶 Multicast can be seriously efficient in some setups (like wired networks), but it can be inefficient in others (like big L2 networks or wireless ones) 🙈

Basically, multicast can make a huge pile of protocol traffic in large L2 networks 😭 That can eat up bandwidth, pile on processing overhead, and tank network performance [RFC7342] 💀

In wireless networks, multicast can be inefficient or even unreliable 🥺 The reasons: a higher chance of transmission interference, a lower data rate, and no acknowledgements (Section 3.1 of [RFC9119]) ✨

Here's the rundown of the multicast performance issues for each ND message 💅

  • Issue 1: LLA DAD degrades performance 🎀 In an L2 network of N addresses (which can be way bigger than the number of hosts, since each host can have multiple addresses), there can be N of these multicast messages 😳 That can cause performance problems when N gets big 💖
  • Issue 2: Router's periodic unsolicited RAs drain host's battery 🔋 Multicast RAs are generally limited to one packet every MIN_DELAY_BETWEEN_RAS (3 seconds), and there are usually just one or two routers on the link, so it's unlikely to be a performance problem 🌸 But for battery-powered hosts, these messages can wake them up and drain their batteries [RFC7772] 😭
  • Issue 3: GUA DAD degrades performance 🦋 This is the same as Issue 1 🫶
  • Issue 4: Router's address resolution for hosts degrades performance 🧚 This is the same as Issue 1 🫶
  • Issue 5: Host's address resolution for hosts degrades performance 🌈 This is the same as Issue 1 🫶
  • Issue for further study: Multicast NAs for host's MAC address changes may degrade performance 🔭 With randomized and changing MAC addresses [MADINAS], there may be a lot of these multicast messages 👀

In wireless networks, multicast is more likely to cause packet loss 😬 DAD treats "no response" as "no duplicate address detected," so packet loss can make duplicate addresses slip through undetected 💀 The multicast reliability issues are:

  • Issue 6: LLA DAD not completely reliable in wireless networks 🫠
  • Issue 7: GUA DAD not completely reliable in wireless networks 🫠
Note: IPv6 address collisions are extremely unlikely 🙈 So these two issues are mostly theoretical rather than practical, bestie 💖

in scenarios like public access networks, some nodes may not be trustworthy 🚨 An attacker on the link can cause the following on-link security issues [RFC3756] [RFC9099] 😤

  • Issue 8: Source IP address spoofing 🎭 An attacker can use another node's IP address as the source address of its ND message and pretend to be that node 👻 From there, the attacker can launch various Redirect or Denial-of-Service (DoS) attacks 💀
  • Issue 9: Denial of DAD 🚫 An attacker can keep replying to a victim's DAD messages, making the victim's address configuration procedure fail, which results in a DoS to the victim 😭
  • Issue 10: Rogue RAs 👿 An attacker can send RAs to victim hosts while pretending to be a router 🫣 Then the attacker can launch various Redirect or DoS attacks 💀
  • Issue 11: Spoofed redirects 🪤 An attacker can send forged Redirects to victim hosts to steer their traffic toward the legitimate router itself 🙃
  • Issue 12: Replay attacks 🔁 An attacker can capture valid ND messages and replay them later 🥲

2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion, and Address Accountability Issues ✨

okay so here's the vibe: when a router needs to forward a packet to a node but doesn't have a Neighbor-Cache Entry (NCE) for it yet, it first makes an NCE in the INCOMPLETE state 🧚 Then it multicasts an NS to the node's solicited-node multicast address 📣 When the destination replies with an NA containing its MAC address, the router fills in that address and switches the state to REACHABLE, which completes the entry 💅 This whole process is called "Router-NCE-on-Demand" in this doc 🎀

Router-NCE-on-Demand can cause these issues:

  • Issue 13: NCE exhaustion 🥵 An attacker can send a huge volume of packets aimed at non-existent IP addresses, making the router create tons of NCEs in the INCOMPLETE state 😱 That resource exhaustion may make the router malfunction 💀 This vulnerability is called "NCE exhaustion" in this doc, and the attacker doesn't need to be on-link to pull it off 🫠
  • Issue 14: Router forwarding delay 🐢 When a packet arrives at a router, the router buffers it while it tries to figure out the host's MAC address 😵‍💫 That buffering delays forwarding and, depending on the router's buffer size, may lead to packet loss 💔 This delay is called "Router-NCE-on-Demand forwarding delay" in this doc 🦋
  • Issue 15: Lack of address accountability 🕵️‍♀️ With SLAAC, hosts generate their own IP addresses 🌷 The router doesn't find out about a host's IP address until an NCE entry gets created 😶 With DHCPv6 [RFC8415], the router may not know the host's addresses unless it does DHCPv6 snooping 👀 In public access networks, subscriber management often relies on IP address (or prefix) identification, so this lack of accountability is a real challenge [AddrAcc] 🚩 Without knowing a host's IP address, network admins can't manage subscribers effectively, which is especially a problem in public access networks 😩 And once a router has made its NCEs, ND [RFC4861] offers no mechanism to retrieve them for management or monitoring, as noted in Section 2.6.1 of [RFC9099] 💀

2.4. Summary of ND Issues

the ND issues from Sections 2.1, 2.2, and 2.3 are summed up below 📋 They come from three main causes: multicast, Trusting-all-nodes, and Router-NCE-on-Demand 🎯 Get rid of any one of these causes and you'd also mitigate the issues tied to it 💖 These observations give you guidance for addressing and preventing ND-related issues 🫶

  1. Multicast-related issues:
    • Performance issues:
      • Issue 1: LLA DAD degrades performance
      • Issue 2: Router's periodic unsolicited RAs drain host's battery
      • Issue 3: GUA DAD degrades performance
      • Issue 4: Router's address resolution for hosts degrades performance
      • Issue 5: Host's address resolution for hosts degrades performance
    • Reliability issues:
      • Issue 6: LLA DAD not completely reliable in wireless networks
      • Issue 7: GUA DAD not completely reliable in wireless networks
  2. Trusting-all-nodes related issues:
    • Issue 8: Source IP address spoofing
    • Issue 9: Denial of DAD
    • Issue 10: Rogue RAs
    • Issue 11: Spoofed redirects
    • Issue 12: Replay attacks
  3. Router-NCE-on-Demand related issues:
    • Issue 13: NCE exhaustion
    • Issue 14: Router forwarding delay
    • Issue 15: Lack of address accountability

these issues are potential vulnerabilities, and they may not show up in every usage scenario 🤞

when any of these might happen in a specific deployment, it's smart to look at the mitigation solutions available 🛡️ They're described in the following section 🦋

3. Review of ND Mitigation Solutions ✨

okay so bestie, this is where we look at the fixes 💅 Table 1 sums up the ND mitigation solutions that cover Issues 1-15 from Section 2.4 🎀. Similar solutions are grouped together, starting with the ones that fix the most issues, and the unrelated ones are ordered by which Section 2.4 issues they address. Each solution gets its own sub-section later, where the abbreviations in the table are explained 🦋

In Table 1, a letter code tells you the RFC category of each mitigation solution (see BCP 9 [RFC2026] for what these categories mean) 📚

  • 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 line up with Section 2.4 like this 🍓

  • On-link sec.: Trusting-all-nodes related issues
  • NCE exh.: NCE exhaustion
  • Fwd. delay: Router forwarding delay
  • No addr. acc.: Lack of address accountability
   +==========+====+===========+=======+=========+====+=======+=======+
   | ND       |RFC |Multicast  |Reliabi| On-link |NCE | Fwd.  | No    |
   | solution |cat.|performance|lity   | sec.    |exh.| delay | addr. |
   |          |    |           |       |         |    |       | acc.  |
   |          |    +===+=+=+=+=+=====+=+=========+====+=======+=======+
   |          |    | 1 |2|3|4|5|  6  |7|   8-12  | 13 |   14  |   15  |
   +==========+====+===+=+=+=+=+=====+=+=========+====+=======+=======+
   | MBBv6    | I  |           All identified issues solved           |
   +----------+----+--------------------------------------------------+
   | FBBv6    |N/A |           All identified issues solved           |
   +----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
   | UPPH     | I  |   |X| |X|X|     |X|         | 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| |     | |         |    |   X   |       |
   +----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
   | SAVI/    | I  |   | | | | |     | |    X    |    |       |       |
   | RA-G     |    |   | | | | |     | |         |    |       |       |
   +----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
   | RFC 6583 | I  |   | | | | |     | |         | X  |       |       |
   +----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
   | RFC 9686 | S  |   | | | | |     | |         |    |       |   X   |
   +----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+

                 Table 1: Solutions for Identified Issues

3.1. Mobile Broadband IPv6 (MBBv6)

okay 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], plus the benefits that come with them 🧚

  • Implementing DAD proxy [RFC6957]:

In a P2MP architecture like the one 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)

okay so 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 for 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) 🌸

okay so 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. So basically, 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. It's giving focused 🎯.

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, it's the same energy but in a TRILL outfit 🎀.

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. Same vibe, different network, iykyk 💅.

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). Sleepy phones say thank you 🥹🫶.

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. So close, but not all the way 😤.

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. No identity theft allowed 🙅‍♀️.

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. Nobody gets to LARP as the 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]. Not ideal, bestie 😩.

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). Plot twist, the server just can't see it 👻.

[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). Slay, the server finally knows who's who ✨.

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. Basically, it recognizes its own reflection 💅.

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. Translator energy, honestly iconic 🌸.

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. Throwback era, but still worth knowing 🧸.

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. A whole security glow-up 💜.

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. Hard math is the bouncer here 🙅‍♀️🔢.

CGA is part of SEND. There is no reported deployment. Sad but true 🥀.

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. It's basically wearing the proxy's outfit 👗.
  • 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. Full circle moment 🔄✨.

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). Everyone's using it, no cap 💅.

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. Living its best life in the wild 🌈.

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

4. Guidelines for Prevention of Potential ND Issues ✨

Okay so, if you already know the potential ND issues and the mitigation solutions for them, you can be a total planning queen 👑. Network admins of existing IPv6 deployments can check whether these issues might show up in their networks and, if they do, decide whether to roll out the fixes proactively 🛡️. Deploying these solutions can take time and extra resources, so it's honestly the perfect moment to plan 📅.

Network admins who are just starting their IPv6 deployments can use the issue-solution info to plan from day one. They can also take proactive action to stop potential ND issues before they ever happen 💖.

4.1. Learning Host Isolation from the Existing Solutions

Various ND solutions might look totally unrelated at first, but once you sort them into four groups, something important pops out: host isolation is an effective strategy for mitigating ND-related issues 🦋.

  • Group 1: L3 and L2 Isolation

This group includes MBBv6 and FBBv6, which isolate hosts at both L3 and L2 by placing each host within its own subnet and link 🌸. This prevents ND issues caused by multicast and Trusting-all-nodes, since each host operates inside its isolated domain. Furthermore, because routers can route packets to a host based on its unique prefix, the need for Router-NCE-on-Demand is also eliminated 🎀. Therefore, L3 and L2 Isolation prevent all ND issues 💅.

  • Group 2: L3 Isolation

This group includes UPPH solutions like [RFC8273] and [RFC9663], which isolate hosts into separate subnets while potentially leaving them on the same shared medium 🧚. This approach mitigates ND issues caused by router multicast to hosts, and it eliminates the need for Router-NCE-on-Demand, as detailed in Section 3.3.

  • Group 3: Partial L2 Isolation

This group encompasses solutions such as WiND, SARP, ND optimization for TRILL, and Proxy ND in EVPN ✨. These solutions use a proxy device to represent the hosts behind it, which effectively isolates those hosts into distinct multicast domains. The hosts still live in the same subnet, but since they're split into different multicast domains, the scope of ND issues tied to multicast-based address resolution gets smaller 🫶.

  • Group 4: Non-Isolating Solutions

The final group is the leftovers, the solutions that don't implement host isolation at all 🙈. They don't prevent ND issues. Instead, they focus on fixing specific ND problems one at a time.

The analysis shows that the stronger the isolation of hosts, the more ND issues can be mitigated 🔥. Honestly, this makes total sense, because isolating hosts shrinks the multicast scope, cuts down the number of nodes that have to be trusted, and may even eliminate the need for Router-NCE-on-Demand. Those are the three main causes of ND issues, so tackling them is the whole game 🏆.

This understanding can be used to prevent ND issues 🌈.

4.2. Applicability of Various Isolation Methods

4.2.1. Applicability of L3+L2 Isolation

Benefits:

  • All ND issues (Section 2.4) can be effectively mitigated 💖.

Constraints:

  1. L2 Isolation:

Actions must be taken to isolate hosts in L2 🧱. The required effort depends on the chosen method and the deployment context. For example, the P2P method [RFC7066] is heavyweight, while the Private VLAN method [RFC5517] is more manageable.

  1. Unique prefix allocation:

A large number of prefixes will be required, with one prefix assigned per host. Good news, though: this is generally not a limitation for IPv6 🌍. For instance, members of a Regional Internet Registry (RIR) can obtain a /29 prefix allocation [RIPE738], which provides 32 billion /64 prefixes, more than enough for any foreseeable deployment scenario 🤯. Real-world deployments show this works. MBBv6 assigns /64 prefixes to billions of mobile UEs [RFC6459], and FBBv6 assigns /56 prefixes to hundreds of millions of routed RGs [TR177]. That's the feasibility proof right there 💅.

  1. Privacy issue from unique prefix identifiability:

Assigning a unique prefix to each host may theoretically reduce privacy, since hosts can be directly identified by their assigned prefix 👀. However, other host identification methods, such as cookies, are commonly used. So unique prefix identifiability may not make much difference, and the actual impact on privacy is therefore likely to be limited 🦋.

  1. Router support for L3 Isolation:

The router must support an L3 Isolation solution, e.g., [RFC8273] or [RFC9663] 🛠️.

  1. A large number of router interfaces may be needed:

If the P2P method is used, the router must instantiate a separate logical interface for every attached host. In that case, a large number of interfaces will be needed at the router 📦.

  1. Router as a bottleneck:

Since all communication between hosts is routed through the router, the router may become a performance bottleneck in high-traffic scenarios 🚦.

  1. Incompatibility with host-based multicast services:

Services that rely on multicast communication among hosts, such as the Multicast Domain Name System [RFC6762], will be disrupted 😭.

4.2.2. Applicability of L3 Isolation

Benefits:

  • All ND issues (Section 2.4) are mitigated, with the exception of:
    • LLA DAD multicast degrades performance,
    • LLA DAD not reliable in wireless networks, and
    • on-link security.

These remaining issues depend on the characteristics of the shared medium 🌙:

  • If the shared medium is Ethernet, the issues related to LLA DAD multicast are negligible.
  • If nodes can be trusted, such as in private networks, on-link security concerns are not significant.
  • There is no need for L2 Isolation. Consequently, this method can be applied in a wide range of scenarios, making it possibly the most practical host isolation method 🏅.

Constraints (as discussed in Section 4.2.1):

  1. Unique prefix allocation
  2. Router support for L3 Isolation
  3. Router as a bottleneck
  4. Privacy issue from unique prefix identifiability

4.2.3. Applicability of Partial L2 Isolation

Benefit:

  • Reduced multicast traffic: This method reduces multicast traffic, particularly for address resolution, by dividing the subnet into multiple multicast domains 🍓.

Constraint:

  • Router support for Partial L2 Isolation: The router must implement a Partial L2 Isolation solution such as WiND, SARP, ND optimization for TRILL, and Proxy ND in EVPN to support this method 🧩.

4.3. Guidelines for Applying Isolation Methods

Based on the applicability analysis in the preceding sections, network admins can decide whether to implement an isolation method and, if so, which one fits their specific deployment best 🎯.

A simple guideline is to consider the isolation methods in the order listed in the preceding sections, going from the strongest isolation to the weakest 🪜:

  • Stronger isolation methods can prevent more ND issues, but they may also come with higher entry requirements 💪.
  • Weaker isolation methods have fewer entry requirements, but they may leave some ND issues unmitigated 🤷‍♀️.

The choice between L3+L2 Isolation and L3 Isolation often depends on what it costs to implement L2 Isolation 💸:

  • If the cost is acceptable, L3+L2 Isolation is preferable because it eliminates every ND issue listed in Section 2.4 🫧.
  • Otherwise, L3 Isolation addresses most of those issues while keeping the implementation effort reasonable 🌷.

Picking an isolation method that's either too strong or too weak doesn't lead to serious consequences 🙌:

  • Choosing an overly strong isolation method may require the network admin to meet higher entry requirements at the start, such as measures for L2 Isolation, additional prefixes, or additional router capabilities.
  • Choosing a weaker isolation method may mean deploying supplemental ND mitigation techniques to address any unresolved ND issues.

In either case, the resulting solution can be functional and effective ✨.

5. Security Considerations ✨

This document is a review of known ND issues and solutions, security included 🔐. It does not introduce any new solutions. Therefore, it does not introduce new security issues 💜.

6. IANA Considerations 🌸

This document has no IANA actions.

7. References 📚

7.1. Normative References

7.2. Informative References 📚✨

okay bestie, this is the extra reading list 🧚 these are the "go deeper if you're curious" refs, and they're all listed in full below, no cuts 💅

Acknowledgements ✨

okay bestie, the people who reviewed this doc deserve a whole parade 🎉🎀 The authors want to thank Éric Vyncke, Gunter Van de Velde, Lorenzo Colitti, Erik Kline, Warren Kumari, Mohamed Boucadair, Gorry Fairhurst, Pascal Thubert, Jen Linkova, Brian Carpenter, Mike Ackermann, Nalini Elkins, Ed Horley, Ole Troan, David Thaler, Chongfeng Xie, Chris Cummings, Dale Carder, Tim Chown, Priyanka Sinha, Aijun Wang, Ines Robles, Magnus Westerlund, Barry Leiba, Deb Cooley, and Paul Wouters for their reviews and comments 💜 They also want to shout out Tim Winters for being the document shepherd 🫶 literally iconic work from everyone 👑

Authors' Addresses 🦋

XiPeng Xiao 💖 Huawei Technologies Email: xipengxiao@huawei.com

Eduard Vasilenko 🌸 Huawei Technologies Email: vasilenko.eduard@huawei.com

Eduard Metz 🧚 KPN N.V. Email: eduard.metz@kpn.com

Gyan Mishra 🍓 Verizon Inc. Email: gyan.s.mishra@verizon.com

Nick Buraglio ⭐ Energy Sciences Network Email: buraglio@es.net

📦 where this page comes from