IPv6 Operations (v6ops) Working Group X. Xiao
Internet Draft E. Vasilenko
Intended status: Informational Huawei Technologies
Expires: March 2025 E. Metz
KPN
G. Mishra
Verizon Inc.
N. Buraglio
Energy Sciences Network
September 23, 2024
Neighbor Discovery Considerations in IPv6 Deployments
draft-ietf-v6ops-nd-considerations-06
Abstract
Neighbor Discovery (ND) is a critical part of IPv6. ND uses
multicast extensively and trusts all hosts. In some scenarios, such
as wireless networks, multicast can be inefficient. In other
scenarios, such as public access networks, hosts may not be
trustworthy. Consequently, ND can have issues in some scenarios. The
issues and mitigation solutions are documented in more than 20 RFCs,
making it challenging to track all these issues and solutions.
Therefore, an overview document is helpful.
This document first summarizes the published ND issues and the
solutions. This provides a one-stop reference. This document then
analyzes these mitigation solutions to reveal that isolating hosts
into different subnets or links can help prevent ND issues. Three
isolation methods and their applicability are described. A simple
guideline is provided for selecting a suitable isolation method to
prevent potential ND issues.
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 March 23, 2025 [Page 1]
Internet-Draft nd-considerations September 2024
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire in Mar. 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
1.1. Terminology...............................................4
2. Review of ND Issues............................................5
2.1. Multicast May Cause Performance and Reliability Issues....5
2.2. Trusting-all-hosts May Cause On-link Security Issues......6
2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE
Exhaustion, and Lack of Subscriber Management/Address
Accountability Issues..........................................7
2.4. Summary of ND Issue.......................................7
3. Review of ND Mitigation Solutions..............................8
3.1. ND Solution in Mobile Broadband IPv6.....................10
3.2. ND Solution in Fixed Broadband IPv6......................10
3.3. Unique IPv6 Prefix per Host..............................12
3.4. Wireless ND and Subnet ND................................12
3.5. Scalable Address Resolution Protocol.....................13
3.6. ARP and ND Optimization for Transparent Interconnection of
Lots of Links (TRILL):........................................13
3.7. Proxy ARP/ND in EVPN.....................................14
3.8. Gratuitous Neighbor Discovery............................14
3.9. Reducing Router Advertisements...........................14
3.10. Source Address Validation Improvement and Router
Advertisement Guard...........................................15
3.11. RFC 6583 Dealing with Operational Neighbor Discovery
Problems......................................................15
Xiao Expires March 23, 2025 [Page 2]
Internet-Draft nd-considerations September 2024
3.12. Registering Self-generated IPv6 Addresses using DHCPv6..16
3.13. Enhanced DAD............................................16
3.14. ND Mediation for IP Interworking of Layer 2 VPNs........16
3.15. ND Solutions Defined before the Latest Versions of ND...16
3.15.1. SeND...............................................17
3.15.2. Cryptographically Generated Addresses (CGA)........17
3.15.3. ND Proxy...........................................17
3.15.4. Optimistic DAD.....................................18
4. Guidelines for Prevention of Potential ND Issues..............18
4.1. Learning Host Isolation from the Existing Solutions......19
4.2. Applicability of Various Isolation Methods and a Simple
Guideline.....................................................20
4.2.1. Applicability of L3 & L2 Isolation..................20
4.2.2. Applicability of L3 Isolation.......................20
4.2.3. Applicability of Partial L2 Isolation...............21
4.2.4. A Simple Guideline..................................21
5. Security Considerations.......................................22
6. IANA Considerations...........................................22
7. References....................................................22
7.1. Informative References...................................22
8. Acknowledgments...............................................25
1. Introduction
Neighbor Discovery [ND] is specified in RFC 4861. It defines how
hosts and routers on the link interact with each other. ND contains
eight main procedures:
1. Host's Duplicate Address Detection (DAD): hosts generate Link-
Local Addresses (LLAs) and use multicast Neighbor Solicitations
(NSs) for DAD.
2. Router Discovery: hosts send multicast Router Solicitations
(RSs) to discover the routers. Routers respond with unicast
Router Advertisements (RAs) with subnet prefixes for the link
and other information. Routers also send unsolicited multicast
RAs from time to time.
3. Host's Global Unicast Address (GUA) DAD: hosts form GUA and use
multicast NSs for DAD.
4. Router's Neighbor Discovery: When a router is to forward a
packet to an on-link host for the first time, the router uses
multicast NSs to perform address resolution for the host.
5. Host's Neighbor Discovery: When a host is to send a packet to
another on-link host, the source host uses multicast NSs to
perform address resolution for the destination host.
6. Host/router's Node Unreachability Detection (NUD):
hosts/routers use unicast NSs for NUD.
Xiao Expires March 23, 2025 [Page 3]
Internet-Draft nd-considerations September 2024
7. Host's link-layer address change announcement: hosts may use
multicast NAs to announce link-layer address changes.
8. Router's Redirect: Routers send Redirect packets to inform a
host of a better router or that the destination host is on-
link.
ND can have issues in some scenarios due to the use of multicast,
trusting all hosts, or installing NCE entries on demand. Various ND
issues and mitigation solutions have been published in more than 20
RFCs, including:
. ND Trust Models and Threats [RFC3756],
. Secure ND [SeND],
. Cryptographically Generated Addresses [CGA],
. ND Proxy [RFC4389],
. Optimistic ND [RFC4429],
. ND for mobile broadband [RFC6459][RFC7066],
. ND for fixed broadband [TR177],
. ND Mediation [RFC6575],
. Operational ND Problems [RFC6583],
. Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929][SND],
. DAD Proxy [RFC6957],
. Source Address Validation Improvement [SAVI],
. Router Advertisement Guard [RA-Guard][RA-Guard+],
. Enhanced Duplicate Address Detection [RFC7527],
. Scalable ARP [RFC7586],
. Reducing Router Advertisements [RFC7772],
. Unique Prefix Per Host [RFC8273],
. ND Optimization for TRILL [RFC8302],
. Gratuitous Neighbor Discovery [GRAND],
. Proxy ARP/ND for EVPN [RFC9161].
Because of the number of RFCs involved, it can become difficult to
track issues and solutions. This document summarizes these RFCs into
a one-stop reference to better inform network administrators about
potential ND issues and mitigation solutions. This document also
identifies three host isolation methods that are useful for
preventing potential ND issues and provides a simple guideline for
selecting one of them.
1.1. Terminology
Some important terms are defined in this section.
MAC - link-layer addresses are referred to as MAC addresses in
this document.
Xiao Expires March 23, 2025 [Page 4]
Internet-Draft nd-considerations September 2024
Host Isolation - separating hosts into different subnets or links.
Subnet & Link Isolation - assigning a unique prefix to each host,
and connecting each host in a P2P link to the router. Every
host is therefore in its subnet and its link. This is also
called L3 & L2 Isolation.
Subnet Isolation - assigning a unique prefix per host so that each
host is in its subnet. The hosts may be in the same link or
different links. This is also called L3 Isolation.
Proxy Isolation - using a routing proxy device to represent the
hosts behind it and separating hosts in a subnet into
multiple multicast domains. This is also called Partial L2
Isolation.
2. Review of ND Issues
2.1. Multicast May Cause Performance and Reliability Issues
ND uses multicast for Node Solicitations (NSs), Node Advertisements
(NAs), Router Solicitations (RSs) and Router Advertisements (RAs).
Multicast can be inefficient in some scenarios, e.g. large L2
networks and wireless networks.
In large L2 networks, ND multicast can create a large amount of
protocol traffic. This can consume network bandwidth, create a
processing burden, and reduce network performance [RFC7342].
In wireless networks, multicast messages often require special
processing. For example, many mobile devices drop substantial
percentages of multicast traffic on Wi-Fi by listening to only one
out of multiple Delivery Traffic Indication Message (DTIM) beacons.
Consequently, multicast in wireless networks reduces not only
performance but also reliability [RFC9119]. For example, DAD uses
the lack of a response as an indication that the address is not
currently in use. If the DAD multicast messages are lost, DAD will
not work properly.
ND uses multicast in the following messages. Multicast impact on
performance and reliability is summarized below:
. Hosts' LLA, GUA DAD: may cause performance issues in both wired
and wireless networks, and possibly reliability issues in
wireless networks.
Xiao Expires March 23, 2025 [Page 5]
Internet-Draft nd-considerations September 2024
. Router's periodic unsolicited RAs: multicast RAs are generally
limited to one packet every 3s, and there are usually only one
or two routers on the link, so it is unlikely to cause a
performance issue. However, for battery-powered hosts, such
messages may wake them up and create battery life issues
[RFC7772]. Additionally, three RAs in a row may be lost in
wireless which depreciates the router on the host.
. Router's address resolution for hosts: in an L2 network of N
hosts, there can be N such multicast messages. This may cause
performance issues when N is large.
. Hosts address resolution for hosts: in an L2 network of N
hosts, there can be N-square such multicast messages. This may
cause performance issues when N is large.
. Hosts' MAC address change NAs: this type of multicast message
is rare and will not cause a performance or reliability issue.
It will not be further discussed.
Multicast originated from hosts and routers will be called host
multicast and router multicast hereafter.
2.2. Trusting-all-hosts May Cause On-link Security Issues
ND trusts all hosts. In some scenarios, such as public access
networks, some hosts may not be trustworthy. An attacker on the link
can cause the following security issues [RFC3756][RFC9099]:
. Source IP address spoofing: an attacker can use a victim host's
IP address as the source address of its ND message to pretend
to be the victim. The attacker can then launch Redirect or
Denial of Service (DoS) attacks on the victim.
. DAD denial: an attacker can repeatedly reply to a victim's DAD
messages, causing the victim's address configuration procedure
to fail, resulting in a denial of service to the victim host.
. Forged RAs: an attacker can send RAs to other hosts to claim to
be a router and preempt the real router, resulting in a
Redirect attack [RA-Guard].
. Forged Redirects: an attacker can pretend to be the router and
send Redirects to other hosts to redirect their traffic from
the router to itself, resulting in a Redirect attack.
. Replay attacks: an attacker can capture valid ND messages and
replay them later.
Xiao Expires March 23, 2025 [Page 6]
Internet-Draft nd-considerations September 2024
2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion,
and Lack of Subscriber Management/Address Accountability Issues
In ND, a router does not maintain (IP, MAC address) binding (i.e.
Neighbor Cache Entry or NCE) for a host until it is needed. This is
called Router-NCE-on-Demand in this document. When a router is to
forward a packet to a host, it will perform address resolution to
find the MAC address of the host. This can cause multiple issues:
. The packet has to be buffered before the router finds out the
MAC address of the host. This delays forwarding, and depending
on the router's buffer size, may also cause packet loss. This
is called "Router-NCE-on-Demand Forwarding Delay" in this
document.
. The way ND performs address resolution is the source node will
create an NCE entry first and set its state to INCOMPLETE, then
the node will multicast NSs to all the nodes and wait for the
destination node to reply with its MAC address. This creates a
security vulnerability. If an attacker sends a large number of
packets destined to non-existing IP addresses, the router will
create a large number of NCEs in INCOMPLETE state while trying
to resolve the MAC addresses. The router may run out of
resources and stop functioning. This is called "NCE Exhaustion"
in this document. Note that in this case, the attacker can be
off-link.
. With SLAAC, a host forms its own IP address. A router does not
know the host's IP address until an NCE entry is installed. In
a service provider network, subscribers are typically managed
by their IP addresses. Consequently, if the router does not
know a host's IP address, the service provider cannot manage
the subscriber. This is an issue for public access networks. In
addition, after the NCE entries are installed on the router,
there is no clearly defined method to retrieve them for
management purpose [RFC9099, Section 2.6.1.4].
2.4. Summary of ND Issue
The ND issues discussed in Sections 2.1 to 2.3 are summarized below.
It is worth noting that these issues originate from three causes:
multicast, trusting all hosts, and Router-NCE-on-Demand. If a cause
can be eliminated, the corresponding issues will also be eliminated.
This points out the directions for preventing ND issues.
. Performance issues caused by multicast
o I1: LLA DAD degrading performance
o I2: Unsolicited RA draining hosts' battery
Xiao Expires March 23, 2025 [Page 7]
Internet-Draft nd-considerations September 2024
o I3: GUA DAD degrading performance
o I4: Router address resolution for hosts degrading
performance
o I5: Host Address resolution for other hosts degrading
performance
. Reliability issues caused by multicast
o I6: LLA DAD is not reliable for wireless networks
o I7: GUA DAD is not reliable for wireless networks
. On-link security issues caused by trusting all hosts
o I8: Source IP address spoofing
o I9: DAD denial
o I10: Forged RAs
o I11: Forged Redirects
o I12: Replay attacks
. Router-NCE-on-Demand related issues
o I13: Router NCE exhaustion
o I14: Router forwarding delay
o I15: Lack of subscriber management/address accountability
with SLAAC
It is worth noting that these are just potential issues. Depending
on the usage scenarios, they may not actually occur.
When the above issues can happen, it is advisable to be aware of the
mitigation solutions available for them, as described in the next
section.
3. Review of ND Mitigation Solutions
This section reviews the ND mitigation solutions developed over the
years so that network administrators can get an idea of what
solutions are available for which issues. They are summarized in
Table 1 below for easy reference. The solutions are reviewed in an
order that helps to reveal a methodology that can be useful for
preventing ND issues, which will be discussed in Section 4.
+-----+-------------------+--------+--------+--------+------+-----+
| | Multicast | Reli- |On-link |R NCE |Fwd. |NoSub|
| | performance | ability|security|Exhaust.|Delay |Mgmt.|
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|Issue| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8-12 | 13 | 14 | 15 |
Xiao Expires March 23, 2025 [Page 8]
Internet-Draft nd-considerations September 2024
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|MBBv6| All issues solved |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|FBBv6| All issues solved |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|8273 | | X | X | X | X | | X | | X | X | X |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|WiND | All issues solved for LLNs |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|SARP | | | | | X | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|ND | | | | | X | | | | | | |
|TRILL| | | | | | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|ND | | | | | X | | | | | | |
|EVPN | | | | | | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|7772 | | X | | | | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|GRAND| | | | X | | | | | |Partly| |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|SAVI/| | | | | | | | | | | |
|RA | | | | | | | | X | | | |
Xiao Expires March 23, 2025 [Page 9]
Internet-Draft nd-considerations September 2024
|G/G+ | | | | | | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|6583 | | | | | | | | | X | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|AddrR| | | | | | | | | | | X |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
Table 1. Solutions for identified issues
3.1. ND Solution in Mobile Broadband IPv6
Mobile Broadband IPv6 (MBBv6) is defined in "IPv6 in 3GPP EPS"
[RFC6459], "IPv6 for 3GPP Cellular Hosts" [RFC7066], and "Extending
an IPv6 /64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link" [RFC7278]. The solution key
points are:
. Putting every host, i.e. the mobile User Equipment (UE), in a
P2P link with the router, i.e. the mobile gateway. MBBv6 also
simplifies ND to take advantage of this P2P architecture. As a
result:
o All multicast is effectively turned into unicast.
o The P2P links in MBB do not have MAC address. Therefore,
Router-NCE-on-Demand is not needed.
o Trusting-all-host is only relevant to the router. By
applying some filtering at the router, e.g. dropping RAs
from the host, even malicious hosts cannot cause security
harm.
. Assigning a unique /64 prefix to each host. Together with the
P2P link, this puts each host in a separate link and subnet.
. Maintaining (prefix, interface) binding at the router for
forwarding purpose.
Since all the three causes of ND issues are addressed, MBBv6 solves
all ND issues.
3.2. ND Solution in Fixed Broadband IPv6
FBBv6 is defined in "IPv6 in the context of TR-101" [TR177]. FBBv6
has two flavors:
Xiao Expires March 23, 2025 [Page 10]
Internet-Draft nd-considerations September 2024
. P2P: every host, i.e. the Residential Gateway (RG), is in a P2P
link with the router, i.e. the Broadband Network Gateway (BNG).
In this case, the solution is essentially the same as MBBv6.
All ND issues are solved.
. P2MP: all hosts on an access device are in a P2MP link with the
router. This is implemented by aggregating all hosts into a
single VLAN at the router and implementing Split Horizon at the
access device to prevent direct host communication.
The key points of FBBv6-P2MP [TR177] are:
. Implementing DAD Proxy [RFC6957]: P2MP architecture with Split
Horizon breaks normal ND's DAD procedure. Because all hosts are
in the same interface from the router's perspective, the router
must ensure that the hosts have different LLAs and GUAs.
Otherwise, the router will not be able to distinguish them.
However, because hosts cannot reach each other, normal DAD will
not function as expected. Therefore, the router must
participate in the hosts' DAD process and help hosts resolve
duplication. With P2MP link and DAD Proxy:
o All host multicast to the router is effectively turned into
unicast, as every host can only reach the router.
o Trusting-all-host is only relevant to the router. By
applying some simple filtering at the router, e.g.
dropping RAs from the host, even malicious hosts cannot
cause security harm.
. Results of assigning a unique /64 prefix to each host:
o The router can proactively create (IP prefix, MAC address)
binding and use it for forwarding. There is no Router-
NCE-on-Demand.
o Since different hosts are in different subnets, hosts will
send traffic to other hosts via the router. There is no
address resolution for other hosts.
o Without address resolution, router multicast to hosts
consists only of unsolicited RAs. Because every host is in
its subnet, unsolicited RAs will be sent individually to
each host with the "host's MAC address replacing the
multicast MAC address" approach specified in [RFC6085].
Therefore, router multicast is turned into unicast.
Since all three causes of ND issues are addressed, FBBv6-P2MP
addresses all ND issues.
Xiao Expires March 23, 2025 [Page 11]
Internet-Draft nd-considerations September 2024
3.3. Unique IPv6 Prefix per Host
Unique IPv6 Prefix per Host is specified in [RFC8273]. The purpose
is to "improve host isolation and enhanced subscriber management on
shared network segments" such as Wi-Fi or Ethernet. The solution key
points are:
. Assigning a unique prefix to each host with SLAAC. As a result:
o When a prefix is assigned to the host, the router can
proactively create (Prefix, MAC address) binding and use
it for forwarding. There is no more Router-NCE-on-Demand.
o Since different hosts are in different subnets, hosts will
send traffic to other hosts via the router. There is no
host-to-host address resolution.
o Without address resolution, downstream multicast to hosts
consists only of unsolicited RAs. They will be sent to
hosts one by one in unicast because the prefix for every
host is different.
Therefore, ND issues caused by NCE-on-Demand and router multicast
are avoided.
RFC 8273 believes that "A network implementing a unique IPv6 prefix
per host can simply ensure that devices cannot send packets to each
other except through the first-hop router". But this may not be true
when hosts are on a shared medium like Ethernet. In this case, hosts
may still reach each other in L2 with their LLAs via upstream
multicast. So, issues caused by host multicast and Trusting-all-
hosts may happen.
3.4. Wireless ND and Subnet ND
Wireless ND (WiND) is specified in a series of RFCs
[RFC6775][RFC8505][RFC8928][RFC8929]. WiND defines a fundamentally
different ND solution for Low-Power and Lossy Networks (LLNs)
[RFC7102]. WiND changes host and router behaviors to use multicast
only for router discovery. The solution key points are:
. Hosts use unicast to proactively register their addresses at
the routers. Routers use unicast to communicate with hosts and
become an abstract registrar and arbitrator for address
ownership.
. The router also proactively installs Neighbor Cache Entries
(NCEs) for the hosts. This avoids the need for address
resolution for the hosts.
Xiao Expires March 23, 2025 [Page 12]
Internet-Draft nd-considerations September 2024
. The router sets PIO L-bit to 0. Each host communicates only
with the router.
. Other functionalities that are relevant only to LLNs.
WiND addresses all ND issues in LLNs. If it is used outside LLNs, it
avoids ND issues caused by NCE-on-Demand and router multicast.
Subnet Neighbor Discovery [SND] generalizes the solutions defined in
WiND and defines a new protocol named Subnet Gateway Protocol (SGP).
It is being discussed in the IPv6 Maintenance (6man) WG.
3.5. Scalable Address Resolution Protocol
Scalable Address Resolution Protocol (SARP) is an Experimental
solution specified in [RFC7586]. The usage scenario is DCs where
large L2 domains span across multiple sites. In each site, multiple
hosts are connected to a switch. The hosts can be VMs so the number
can be large. The switches are interconnected by a native or
overlay L2 network.
The switch will snoop and install (IP, MAC 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.
This way, all hosts in a site will appear to have a single MAC
address to other sites. Therefore, 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. The MAC address table size of
the switches is therefore 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
for such IPs directly. This greatly reduces the number of address
resolution multicast in the network.
Unlike MBBv6, FBBv6, and RFC 8372 which try to address all ND
issues, SARP focuses on reducing address resolution multicast to
improve the performance and scalability of large L2 domains in DCs.
3.6. ARP and ND Optimization for Transparent Interconnection of Lots of
Links (TRILL):
ARP and ND Optimization for TRILL is specified in [RFC8302]. The
solution is very similar to SARP discussed in Section 3.5. It can
be considered as an application of SARP in the TRILL environment.
Like SARP, ARP, and ND Optimization for TRILL focuses on reducing
multicast address resolution.
Xiao Expires March 23, 2025 [Page 13]
Internet-Draft nd-considerations September 2024
3.7. Proxy ARP/ND in EVPN
Proxy ARP/ND in EVPN is specified in [RFC9161]. The usage scenario
is Data Centers (DCs) where large L2 domains span across multiple
sites. In each site, multiple hosts are connected to a Provider Edge
(PE) router acting as a switch. The PEs are interconnected by an
overlay network.
PE of each site snoops the local address resolution NAs to build
(IP, MAC address) Proxy ND table entries. PEs then propagate such
Proxy ND entries to other PEs via BGP EVPN. Each PE also snoops
address resolution NSs from its hosts. If an entry exists in its
Proxy ND table for the specified destination IP address, the PE will
reply directly. Consequently, the number of multicast address
resolution messages is significantly reduced.
Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address
resolution multicast.
3.8. Gratuitous Neighbor Discovery
Gratuitous Neighbor Discovery is specified in [GRAND]. GRAND changes
ND in the following ways:
. A node sends unsolicited NAs upon assigning a new IPv6 address
to its interface.
. A router creates a new NCE for the host and sets its state to
STALE.
Later, when the router receives traffic to the host, the existence
of the NCE entry in the STALE state will cause the router to send
unicast NS to the host to verify its reachability rather than
sending multicast NS to resolve its MAC address. This can shorten
the time the host's NCE entry reaches the REACHABLE state and
improve forwarding performance. Therefore, GRAND provides an
improvement but does not fully solve the Router-NCE-on-Demand
issues. For example, NCE exhaustion can still happen.
3.9. Reducing Router Advertisements
[RFC7772] specifies a solution for reducing RAs:
. The router should respond to RS with unicast RA if the host's
source IP address is specified (i.e. the RS is not the first RS
before GUA DAD) and the host's MAC address is valid.
. The router should reduce multicast RA frequency.
Xiao Expires March 23, 2025 [Page 14]
Internet-Draft nd-considerations September 2024
. Sleeping hosts that process unicast packets while asleep must
also process multicast RAs while asleep.
. Sleeping hosts that do not intend to maintain IPv6 connectivity
while asleep should either disconnect from the network and
clear all IPv6 configuration or perform Detecting Network
Attachment in IPv6 (DNAv6) procedures [RFC6059] when waking up.
By reducing RAs, RFC 7772 reduces the energy consumption of battery-
powered hosts that can be awakened by RAs.
3.10. Source Address Validation Improvement and Router Advertisement
Guard
Source Address Validation Improvement [SAVI] binds an address to a
port and rejects claims from other ports for that address.
Therefore, a node cannot spoof the IP address of another node.
[RA-Guard] and [RA-Guard+] only allow RAs from a port that a router
is connected to. Therefore, nodes on other ports cannot pretend to
be a router.
[SAVI], [RA-Guard], and [RA-Guard+] address the on-link security
issues.
3.11. RFC 6583 Dealing with Operational Neighbor Discovery Problems
Router NCE Exhaustion handling is described in [RFC6583]. This is to
deal with the off-link attack issue discussed in Section 2.3. The
solution key points are:
. For operators:
o Filtering of unused address space so that messages to such
addresses can be dropped rather than triggering NCE
creation;
o Rate-limiting the NDP queue to avoid CPU/memory overflow.
. For vendors:
o Prioritizing NDP processing for existing NCEs over creating
new NCEs
RFC 6583 acknowledges that "some of these options are 'kludges',
and can be operationally difficult to manage". RFC 6583 partially
addresses the Router NCE Exhaustion issue. In the real world,
network equipment vendors simply limit the number of NCE entries on
a router interface to prevent Router NCE Exhaustion. But this can
have a side-effect. When a host uses more IPv6 addresses than the
Xiao Expires March 23, 2025 [Page 15]
Internet-Draft nd-considerations September 2024
limit, irregular packet drops may result because the router does not
maintain NCEs for all those IPv6 addresses [DHCP-PD].
3.12. Registering Self-generated IPv6 Addresses using DHCPv6
This document defines a method for informing a DHCPv6 server that a
device has one or more self-generated or statically configured
addresses [AddrReg]. This enables network administrators to retrieve
the IPv6 addresses for each host from the DHCPv6 server. With IPv4,
network administrators can retrieve a host's IP address from the
DHCP server. With IPv6 and SLAAC, this is not possible, as discussed
in Section 2.3. [AddrReg] makes this possible.
3.13. Enhanced DAD
Enhanced DAD is specified in [RFC7527]. Enhanced DAD addresses a DAD
failure issue in a specific situation: looped back interface. DAD
will fail in a looped-back interface because the sending host will
receive the DAD message back and will interpret it as another host
trying to use the same address. The solution is to include a Nonce
option (defined in [SeND]) in each DAD message so that the sending
host can detect that the looped-back DAD message is sent by itself.
Enhanced DAD does not solve any ND issue discussed in Section 2. 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]. 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 Provider Edges (PEs) must
interwork to provide mediation service so that a Customer Edge (CE)
can resolve the MAC address of the remote end. RFC 6575 specifies
such a solution.
ND Mediation does not address any ND issue discussed in Section 2.
It extends ND to work in a new scenario: two ACs of different media
interconnected by a VPWS. It is reviewed here only for completeness.
3.15. ND Solutions Defined before the Latest Versions of ND
The latest versions of [ND] and [SLAAC] are specified in RFCs 4861
and 4862. Several ND mitigation solutions are based on the older
Xiao Expires March 23, 2025 [Page 16]
Internet-Draft nd-considerations September 2024
version of ND and SLAAC. They are reviewed in this section only for
completeness.
3.15.1. SeND
Secure Neighbor Discovery [SeND] is specified in RFC 3971. The
purpose is to ensure that hosts and routers are trustworthy. SeND
defined three new ND options (i.e. Cryptographically Generated
Addresses [CGA], RSA public-key cryptosystem, Timestamp/Nonce), an
authorization delegation discovery process, an address ownership
proof mechanism, and requirements for the use of these components in
NDP.
SeND addresses the Trusting-all-hosts issues. But it has high
requirements on the hosts and routers, especially to maintain the
keys. It has very low market adoption.
3.15.2. Cryptographically Generated Addresses (CGA)
Cryptographically Generated Addresses [CGA] is specified in RFC
3972. The purpose is to associate a cryptographic public key with an
IPv6 address in [SeND]. The solution key point is to generate the
Interface Identifier (IID) of the IPv6 address by computing a
cryptographic hash of the public key. The resulting IPv6 address is
called a CGA. The corresponding private key can then be used to
sign messages sent from the address.
CGA uses the fact that a legitimate host does not care about the bit
combination of IID that would be created 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
that is a strong mathematical challenge.
CGA is part of SeND. It has low market adoption.
3.15.3. ND Proxy
ND Proxy is specified in [RFC4389]. It is an Experimental solution.
The purpose is to enable multiple links joined by an ND-Proxy device
to work as a single link. The ND-Proxy acts like a bridge:
. When it receives an ND request from a host in a link, it will
"proxy" the message out the "best" 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,
Xiao Expires March 23, 2025 [Page 17]
Internet-Draft nd-considerations September 2024
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 to itself, and update the NCE entry state
at the receiving interface. Based on such state information,
the ND-Proxy can determine the "best" outgoing interface for
future ND requests. The ND-Proxy then "proxy" the ND message
back to the requesting host.
ND Proxy does not solve any ND issue discussed in Section 2. It
extends ND to work in a new scenario: multiple links joined by a
device that is not a bridge but acting like a bridge.
The idea of ND Proxy is widely used in SARP, ND Optimization for
TRILL, and Proxy ARP/ND in EVPN which are discussed in Sections 3.5
to 3.7.
3.15.4. Optimistic DAD
Optimistic DAD is specified in [RFC4429]. The purpose is to minimize
address configuration delays in the successful case and to reduce
disruption as far as possible in the failure case. That is,
Optimistic DAD lets hosts immediately use the newly formed address
to communicate before DAD actually 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 (RFC 2461) and SLAAC (RFC 2462) but the
solution was not incorporated into the latest specification of [ND]
and [SLAAC].
Optimistic DAD does not solve any ND issue discussed in Section 2.
It is reviewed here only for completeness.
4. Guidelines for Prevention of Potential ND Issues
By knowing the potential ND issues and associated mitigation
solutions, network administrators of existing IPv6 deployments can
assess whether these issues may occur in their networks and, if so,
whether to deploy the mitigation solutions proactively. Deploying
these solutions may take time and additional resources; therefore,
it is advisable to plan ahead.
Network administrators who plan to start their IPv6 deployments can
use the issue-solution information to help plan their deployments.
Xiao Expires March 23, 2025 [Page 18]
Internet-Draft nd-considerations September 2024
Moreover, they can take proactive action to prevent potential ND
issues.
4.1. Learning Host Isolation from the Existing Solutions
Although the various ND solutions look unrelated, dividing them into
four groups helps to reveal an important point: isolating hosts can
help to prevent ND issues.
The first group contains MBBv6 and FBBv6. These solutions isolate
hosts in both L3 and L2 by putting each host in its subnet and its
link. This isolation method is called "L3 & L2 Isolation" or "Subnet
& Link Isolation". It prevents ND issues caused by multicast and
Trusting-all-hosts as every host is in its subnet and link. Because
a router can route packets to a host based on its unique prefix,
there is no need for Router-NCE-on-Demand, therefore ND issues
caused by Router-NCE-on-Demand are also prevented.
The second group contains a Unique Prefix Per Host (UPPH) [RFC8273].
UPPH also isolates hosts into different subnets but may leave all
hosts in the same shared medium. This isolation method is called "L3
Isolation" or "Subnet Isolation". As discussed in Section 3.3, this
isolation method prevents ND issues caused by router multicast and
Router-NCE-on-Demand.
The third group contains WiND, SARP, ND Optimization for TRILL, and
Proxy ND in EVPN. They use a proxy device to represent the hosts
behind it and effectively isolate such hosts into different
multicast domains from other hosts. Multiple hosts are still in a
multicast domain and all hosts are still in the same subnet.
Therefore, this isolation method is called Partial L2 Isolation" or
"Proxy Isolation". This isolation method alleviates ND issues from
host multicast for address resolution.
The fourth group contains the remaining solutions. They do not
isolate hosts. They do not prevent any ND issues but focus on
solving a specific ND issue.
The above reveals that the stronger hosts are isolated, the more ND
issues can be prevented. This is natural because isolating hosts
reduces multicast scope, the number of hosts to trust, and possibly
the need for Router-NCE-on-Demand, the three causes of ND issues.
This understanding can be used to prevent ND issues.
Xiao Expires March 23, 2025 [Page 19]
Internet-Draft nd-considerations September 2024
4.2. Applicability of Various Isolation Methods and a Simple Guideline
4.2.1. Applicability of L3 & L2 Isolation
The benefits are:
o All ND issues can be prevented.
The constraints or entry requirements are:
o The hosts must be able to set up P2P links with the router.
o Many prefixes will be needed, one per host.
o This is unlikely to be an issue for IPv6. Today, any member
of a Regional Internet Registry (RIR) can get a /29
[RIPE738]. This contains 32 billion /64 prefixes and should
be sufficient for any scenario. MBBv6 assigning /64 prefixes
to billions of mobile UEs [RFC6459] and FBBv6 assigning /56
prefixes to hundreds of millions of routed RGs [TR177] are
evidence that this is doable.
o Each host is easily identifiable by its unique prefix. This
theoretically reduces privacy. However, hosts can be identified
by many other methods, e.g. by using cookies. Therefore, the real
impact on privacy may be limited.
o The router must support a "Subnet Isolation with P2P Link"
solution, e.g. MBBv6, as described in Section 3.1.
o Many interfaces will be needed at the router, one per host.
o All hosts will communicate through the router, and the router may
become a bottleneck.
o Services relying on multicast communication among hosts, e.g.
mDNS, will not work.
4.2.2. Applicability of L3 Isolation
The benefits are:
Xiao Expires March 23, 2025 [Page 20]
Internet-Draft nd-considerations September 2024
o All ND issues are prevented except "LLA DAD multicast degrading
performance", "LLA DAD not reliable for wireless networks", and
"On-link security" issues. Depending on the shared medium, these
remaining issues may not happen. For example, if the shared
medium is Ethernet, "LLA DAD multicast degrading performance" and
"LLA DAD not reliable for wireless networks" are non-issues. If
the hosts can be trusted, e.g. in a private network, "On-link
security" is also a non-issue.
o There is no new requirement on the hosts. Therefore, this method
can be applied in many scenarios. It is practically the most
usable host isolation method.
The constraints are:
o Many prefixes will be needed, one per host. However as explained
above, this may not be an issue for organizations that can obtain
sufficient IPv6 addresses from RIRs.
o The router must support a Subnet Isolation solution, e.g.
[RFC8273] or [DHCP-PD].
o All host-to-host communication with GUA will go through the
router, and the router may become a bottleneck.
o Each host is identifiable by its unique prefix. This might be a
privacy issue as discussed previously.
4.2.3. Applicability of Partial L2 Isolation
The benefit is:
o Reduced multicast especially for address resolution, as the
subnet is divided into multiple multicast domains.
The constraint is:
o The router must support Proxy Isolation.
4.2.4. A Simple Guideline
Given the applicability analysis above, network administrators can
decide whether to apply any isolation method.
A simple guideline is to consider the isolation methods one by one
in the order listed in the previous sections, that is, from the
Xiao Expires March 23, 2025 [Page 21]
Internet-Draft nd-considerations September 2024
strongest isolation to the weakest. With stronger isolation, more ND
issues can be prevented but the entry requirements will also be
higher. All things considered, L3 Isolation can be a good tradeoff
because the benefits are clear while the entry requirements are
manageable.
It is worth noting that, if a network administrator picks an
isolation method that is too strong or too weak, there is no serious
consequence. Picking an isolation method that is too strong means
that the network administrator needs to meet more entry requirements
upfront, while picking an isolation method that is too weak means
that the network administrator may need to deploy more ND mitigation
solutions to deal with ND issues. Either way, the resulting solution
can still work.
5. Security Considerations
This document is a review of known ND issues and solutions. It does
not introduce any new solutions. Therefore, it does not introduce
new security issues.
6. IANA Considerations
This document has no request to IANA.
7. References
7.1. Informative References
[AddrReg] W. Kumari, S. Krishnan, R. Asati, L. Colitti, J. Linkova,
S. Jiang, "Registering Self-generated IPv6 Addresses using
DHCPv6", draft-ietf-dhc-addr-notification-13.
[CGA] T. Aura, "Cryptographically Generated Addresses (CGA)",
RFC3972
[DHCP-PD] L. Colitti, J. Linkova, X. Ma, "Using DHCP-PD to Allocate
Unique IPv6 Prefix per Host in Broadcast Networks", draft-
ietf-v6ops-dhcp-pd-per-device-08.
[GRAND] J. Linkova, "Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on First-Hop Routers", RFC 9131
[mDNS] S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762.
Xiao Expires March 23, 2025 [Page 22]
Internet-Draft nd-considerations September 2024
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, RFC 4861.
[RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI
10.17487/RFC6105, February 2011, RFC 6105.
[RA-Guard+]F. Gont, "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113, DOI
10.17487/RFC7113, February 2014, RFC 7113.
[RFC3756] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756.
[RFC4389] D. Thaler, M. Talwar, C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389.
[RFC4429] N. Moore, "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429.
[RFC6459] J. Korhonen, J. Soininen, B. Patil, T. Savolainen, G.
Bajko, K. Iisakkila, "IPv6 in 3rd Generation Partnership
Project (3GPP) Evolved Packet System (EPS)", RFC 6459.
[RFC6059] S. Krishnan, G. Daley, "Simple Procedures for Detecting
Network Attachment in IPv6", RFC 6059.
[RFC6085] S. Gundavelli, M. Townsley, O. Troan, W. Dec, "Address
Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085.
[RFC6575] H. Shah, E. Rosen, G. Heron, V. Kompella, "Address
Resolution Protocol (ARP) Mediation for IP Interworking of
Layer 2 VPNs", RFC 6575.
[RFC6583] I. Gashinsky, J. Jaeggli, W. Kumari, "Operational Neighbor
Discovery Problems", RFC 6583.
[RFC6775] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775.
Xiao Expires March 23, 2025 [Page 23]
Internet-Draft nd-considerations September 2024
[RFC6957] F. Costa, J-M. Combes, X. Pougnard, H. Li, "Duplicate
Address Detection Proxy", RFC 6957
[RFC7066] J. Korhonen, J. Arkko, T. Savolainen, S. Krishnan, "IPv6
for Third Generation Partnership Project (3GPP) Cellular
Hosts", RFC 7066.
[RFC7102] JP. Vasseur, "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102.
[RFC7278] Extending an IPv6 /64 Prefix from a Third Generation
Partnership Project (3GPP) Mobile Interface to a LAN
Link", RFC7278.
[RFC7342] L. Dunbar, W. Kumari, I. Gashinsky, "Practices for Scaling
ARP and Neighbor Discovery (ND) in Large Data Centers",
RFC 7342.
[RFC7527] R. Asati, H. Singh, W. Beebee, C. Pignataro, E. Dart, W.
George, "Enhanced Duplicate Address Detection", RFC 7527.
[RFC7586] Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi, "The
Scalable Address Resolution Protocol (SARP) for Large Data
Centers", RFC7586.
[RFC7772] A. Yourtchenko, L. Colitti, "Reducing Energy Consumption
of Router Advertisements", RFC 7772.
[RFC8273] J. Brzozowski, G. Van de Velde, "Unique IPv6 Prefix per
Host", RFC 8273.
[RFC8302] Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair,
"Transparent Interconnection of Lots of Links (TRILL): ARP
and Neighbor Discovery (ND) Optimization", RFC 8302.
[RFC8505] P. Thubert, E. Nordmark, S. Chakrabarti, C. Perkins,
"Registration Extensions for IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN) Neighbor Discovery", RFC
8505.
[RFC8928] P. Thubert, B. Sarikaya, M. Sethi, R. Struik, "Address-
Protected Neighbor Discovery for Low-Power and Lossy
Networks", RFC 8928.
[RFC8929] P. Thubert, C.E. Perkins, E. Levy-Abegnoli, "IPv6 Backbone
Router", RFC 8929.
Xiao Expires March 23, 2025 [Page 24]
Internet-Draft nd-considerations September 2024
[RFC9099] E. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey, "Operational
Security Considerations for IPv6 Networks", RFC 9099.
[RFC9119] C. Perkins, M. McBride, D. Stanley, W. Kumari, JC. Zuniga,
"Multicast Considerations over IEEE 802 Wireless Media",
RFC 9119.
[RFC9161] J. Rabadan, S. Sathappan, K. Nagaraj, G. Hankins, T. King,
"Operational Aspects of Proxy ARP/ND in Ethernet Virtual
Private Networks", RFC 9161.
[RIPE738] IPv6 Address Allocation and Assignment Policy,
https://www.ripe.net/publications/docs/ripe-738
[SAVI] J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, "Source
Address Validation Improvement (SAVI) Framework", RFC
7039.
[SeND] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor
Discovery (SEND)", RFC3971.
[SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862.
[SND] P. Thubert, M. Richardson, "Architecture and Framework for
IPv6 over Non-Broadcast Access", Internet draft, June
2023.
[TR177] S. Ooghe, B. Varga, W. Dec, D. Allan, "IPv6 in the context
of TR-101", Broadband Forum, TR-177.
8. Acknowledgments
The authors would like to thank Lorenzo Colitti, Warren Kumari,
Pascal Thubert, Jen Linkova, Brian Carpenter, Eric Vyncke, Mike
Ackermann, Nalini Elkins, Ed Horley, Ole Troan, David Thaler,
Chongfeng Xie, Chris Cummings, Dale Carder, Tim Chown, Priyanka
Sinha, Aijun Wang for their reviews and comments. The authors would
also like to thank Tim Winters for being the document shepherd.
Xiao Expires March 23, 2025 [Page 25]
Internet-Draft nd-considerations September 2024
Authors' Addresses
XiPeng Xiao
Huawei Technologies Dusseldorf
Hansaallee 205, 40549 Dusseldorf, Germany
Email: xipengxiao@huawei.com
Eduard Vasilenko
Huawei Technologies
17/4 Krylatskaya st, Moscow, Russia 121614
Email: vasilenko.eduard@huawei.com
Eduard Metz
KPN N.V.
Maanplein 55, 2516CK The Hague, The Netherlands
Email: eduard.metz@kpn.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Nick Buraglio
Energy Sciences Network
Email: buraglio@es.net
Xiao Expires March 23, 2025 [Page 26]
