IPv6 Operations (v6ops) Working Group X. Xiao
Internet Draft E. Vasilenko
Intended status: Informational Huawei Technologies
Expires: September 2024 E. Metz
KPN
G. Mishra
Verizon Inc.
N. Buraglio
Energy Sciences Network
March 3, 2024
Selectively Isolating Hosts to Prevent Potential Neighbor Discovery Issues and Simplify IPv6 First-hops draft-ietf-v6ops-nd-considerations-03Abstract
Neighbor Discovery (ND) is a key protocol of IPv6 first-hop. ND uses multicast extensively and trusts all hosts. In some scenarios like wireless networks, multicast can be inefficient. In other scenarios like public access networks, hosts may not be trustable. Consequently, ND has potential issues in various scenarios. The issues and the solutions for them are documented in more than 30 RFCs. It is difficult to keep track of all these issues and solutions. Therefore, an overview is useful.
This document firstly summarizes the known ND issues and optimization solutions into a one-stop reference. Analyzing these solutions reveals an insight: isolating hosts is effective in preventing ND issues. Five isolation methods are proposed and their applicability is discussed. Guidelines are described for selecting a suitable isolation method based on the deployment scenario. When ND issues are prevented with a proper isolation method, the solutions for these issues are not needed. This simplifies the IPv6 first- hops.
Status of this Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
Xiao Expires September 3, 2024 [Page 1]
Internet-Draft nd-considerations March 2024
This Internet-Draft will expire in Sept. 2024.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............................................6
2.1. Multicast Causes Performance and Reliability Issues.......6
2.2. Trusting-all-hosts Causes On-link Security Issues.........7
2.3. Router-NCE-on-Demand Causes Forwarding Delay, NCE Exhaustion
and Lack of Subscriber Management Issues.......................7
2.4. Summary of ND Issue.......................................8
3. Review of ND Solutions.........................................9
3.1. ND Solution in Mobile Broadband IPv6......................9
3.2. ND Solution in Fixed Broadband IPv6......................10
3.3. Unique IPv6 Prefix per Host..............................11
3.4. Wireless ND and Subnet ND................................12
3.5. Scalable Address Resolution Protocol.....................12
3.6. ARP and ND Optimization for Transparent Interconnection of
Lots of Links (TRILL):........................................13
3.7. Proxy ARP/ND in EVPN.....................................13
3.8. Gratuitous Neighbor Discovery............................13
3.9. Reducing Router Advertisements...........................14
3.10. Source Address Validation Improvement and Router Advertisement Guard...........................................14 3.11. Dealing with Off-link Attack that May Cause Router NCE
Xiao Expires September 3, 2024 [Page 2]
Internet-Draft nd-considerations March 2024
Exhaustion....................................................15
3.12. Enhanced DAD............................................15
3.13. ND Mediation for IP Interworking of Layer 2 VPNs........15
3.14. ND Solutions Defined before the Latest Versions of ND...16
3.14.1. SeND...............................................16
3.14.2. Cryptographically Generated Addresses (CGA)........16
3.14.3. ND Proxy...........................................17
3.14.4. Optimistic DAD.....................................17
3.15. Observations on the Solutions...........................18
4. Selectively Isolating Hosts to Prevent Potential ND Issues and
Simplify IPv6 First-hops.........................................20
4.1. Applicability of Subnet Isolation with P2P Link..........22
4.2. Applicability of Subnet Isolation with P2MP Link.........23
4.3. Applicability of Subnet Isolation with Shared Medium.....23
4.4. Applicability of Proxy Isolation.........................24
4.5. Applicability of GUA Isolation...........................24
4.6. Guidelines for Selecting a Host Isolation Method.........24
4.7. Impact of Host Isolation on Other Protocols in IPv6 First-
hops..........................................................28
5. Security Considerations.......................................29
6. IANA Considerations...........................................29
7. References....................................................29
7.1. Informative References...................................29
8. Acknowledgments...............................................32
1. Introduction
Neighbor Discovery [ND] is specified in RFC 4861. It defines how hosts and routers in the link interact with each other. ND contains eight main procedures:1. Host's LLA DAD: hosts generate Link Local Addresses (LLAs) and use multicast Neighbor Solicitations (NSs) for Duplicate Address Detection (DAD).
2. Host's Router Discovery: hosts send multicast Router
Solicitations (RSs) to discover first-hop routers. Routers respond with unicast Router Advertisements (RAs) with subnet prefixes for the link and other information. Routers also send unsolicited multicast RAs from time to time.
3. Host's GUA DAD: hosts form Global Unicast Address (GUA) or
Unique Local Address (ULA) 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.
Xiao Expires September 3, 2024 [Page 3]
Internet-Draft nd-considerations March 2024
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 NUD: hosts/routers use unicast NS for Node
Unreachability Detection (NUD).
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 first-hop router or that the destination host is on-link.
Due to multicast, trusting all hosts, etc., ND has potential issues in some scenarios. Various ND issues and solutions for them have been described in more than 30 RFCs. These include: ND Trust Models and Threats [RFC3756], Secure ND [SeND], Cryptographically Generated Addresses [CGA], ND Proxy [RFC4389], Optimistic ND [RFC4429], ND for mobile broadband [RFC6459][RFC7066], ND for fixed broadband [TR177], ND Mediation [RFC6575], Operational ND Problems [RFC6583], Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929][SND], DAD Proxy [RFC6957], Source Address Validation Improvement [SAVI], Router Advertisement Guard [RA-Guard][RA-Guard+], Enhanced Duplicate Address Detection [RFC7527], Scalable ARP [RFC7586], Reducing Router Advertisements [RFC7772], Unique Prefix Per Host [RFC8273], ND Optimization for TRILL [RFC8302], Gratuitous Neighbor Discovery [GRAND], Proxy ARP/ND for EVPN [RFC9161]. It is difficult to understand all these issues and solutions, and how they fit together. If IPv6 deployers are not sufficiently informed before their deployment, they may encounter problems later. This document summarizes the potential issues and solutions to provide a clear picture. It also provides guidelines for preventing the issues as much as possible.
1.1. Terminology
Some important terms are defined in this section.MAC - To avoid confusion with Link Local Address (LLA), link
layer address is called MAC in this document.
Subnet isolation for hosts - assigning a unique prefix per host so
that each host is in its own subnet [RFC8273].
Xiao Expires September 3, 2024 [Page 4]
Internet-Draft nd-considerations March 2024
P2P link isolation - connecting each host in a P2P link to therouter. The router has a separate interface for each host. Consequently, any L2 message from a host can only reach the router, and any L2 message from the router can only reach one host.
P2MP link isolation - connecting multiple hosts in a P2MP link to
the router. The router has a single interface for all hosts. Example P2MP links are Private VLAN [PVLAN] and Wi-Fi with Wireless Isolation [W-Iso]. Consequently, any L2 message from a host can only reach the router, not other hosts. But an L2 multicast message from the router can reach multiple hosts simultaneously.
Proxy isolation - using an ND proxy device to represent the hosts
behind it. There are two kinds of proxies, bridging and routing. When receiving an address resolution message for a host, a bridging proxy either passes the message to the host or directly answer with the host's MAC. In comparison, a routing proxy [SND] always terminates the address resolution messages and replies with its own MAC address. Consequently, a bridging proxy will forward packets to the destination hosts at L2 based on the destination hosts' MAC addresses (i.e. bridging), while a routing proxy will receive packets on its own MAC address and then forward the packets at L3 to the destination hosts (i.e. routing). From a host isolation perspective, bridging proxies have no isolating effect while routing proxies effectively isolate different groups of hosts behind the proxies into different broadcast/multicast domains. In this document, proxy isolation refers to routing proxy isolation.
GUA isolation - setting PIO L-bit=0 so that other hosts appear off-
link [ND]. There will be no GUA address resolution for other hosts in the link, and all GUA traffic will be sent via the router. Therefore, hosts appear isolated from a GUA perspective. This is also applicable to ULA but to be simple, it is also called GUA Isolation in this document.
Xiao Expires September 3, 2024 [Page 5]
Internet-Draft nd-considerations March 2024 2. Review of ND Issues 2.1. Multicast Causes Performance and Reliability IssuesND uses multicast for Node Solicitations (NSs), Node Advertisements (NAs)Router Solicitations (RSs) and Router Advertisements (RAs). Multicast can be inefficient in some scenarios, e.g. large L2 networks or wireless networks.
In large L2 networks, e.g. DC networks involving many Virtual Machines (VMs), ND multicast can create a large amount of protocol traffic. This can consume network bandwidth, create a processing burden, and reduce network performance [RFC7342].
In wireless networks, multicast messages often require special processing. For example, to ensure that the multicast messages reach even the remotest hosts, multicast messages may be sent at the lowest modulation rate. Alternatively, multicast may be converted into multiple unicast messages. In addition, 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, ND uses no response as an indication of no duplication in Duplicate Address Detection (DAD). If the DAD multicast messages are lost, DAD will not work properly.
ND uses multicast in the following messages. Multicast impact on performance and reliability is summarized below:
. Hosts' LLA DAD: may cause performance issues in both wired and
wireless networks, and possibly reliability issues in wireless networks.
. 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].
. Hosts' GUA (or ULA) DAD: may cause performance issues in both
wired and wireless networks, and possibly reliability issues in wireless networks.
. Router's address resolution for hosts: in a large L2 network of
N hosts, there can be N such multicast messages. This may cause performance issues.
Xiao Expires September 3, 2024 [Page 6]
Internet-Draft nd-considerations March 2024
. Hosts address resolution for hosts: in a large L2 DC network ofN hosts, there can be N-square such multicast messages. This may cause performance issues.
. Hosts' MAC change NAs: this type of multicast messages is rare
and will not cause a performance issue. It will not be further discussed.
Multicast originated from hosts and routers will be called host multicast and router multicast hereafter.
2.2. Trusting-all-hosts Causes On-link Security Issues
ND trusts all hosts. In some scenarios like public access networks, some hosts may not be trustable. An attacker host in the link can cause the following security issues [RFC3756][RFC9099]:. Source IP address spoofing: an attacker can use a victim host's
IP address as the source address of its ND message to pretend to be the victim. The attacker can then launch Redirect or Denial of Service (DoS) attacks on the victim.
. DAD denial: an attacker can repeatedly reply to a victim's DAD
messages, causing the victim's address configuration procedure to fail, and resulting in a denial of service to the victim host.
. Forged RAs: an attacker can send RAs to other hosts to claim to
be a router and preempt the real router, resulting in a Redirect attack [RA-Guard].
. Forged Redirects: an attacker can pretend to be the router and
send Redirects to other hosts to redirect their traffic to the router to itself, resulting in a Redirect attack.
. Replay attacks: an attacker can capture valid ND messages and
replay them later.
2.3. Router-NCE-on-Demand Causes Forwarding Delay, NCE Exhaustion and Lack of Subscriber Management Issues
In ND, a router does not maintain (IP, MAC) binding (i.e. Neighbor Cache Entry or NCE) for a host until it is needed. This is called Router-NCE-on-Demand. When a router is to forward a packet to a host, it will perform address resolution to find the MAC of the host. This can cause multiple issues:
. The packet has to be buffered before the router finds out the
MAC of the host. This delays forwarding and depending on the router's buffer size may also cause packet loss. This is called "Router-NCE-on-Demand Forwarding Delay" in this document.
Xiao Expires September 3, 2024 [Page 7]
Internet-Draft nd-considerations March 2024
. The way ND performs address resolution is the source node willcreate an NCE entry first and set its state to INCOMPLETE, the node will then multicast NSs to all the nodes and wait for the destination node to reply with its MAC. This creates a security vulnerability. If an attacker sends a large number of packets destined to non-existing IP addresses to a router, the router will create a large amount of NCEs in INCOMPLETE state while trying to resolve the MACs. The router may run out of resources and stop functioning. This is called "NCE Exhaustion" in this document. Note that in this case, the attacker can be off-link. So, this is different from the on-link security issues.
o To prevent this NCE Exhaustion problem, some
implementations limit the maximal number of NCEs a router will maintain for each host. When a host uses more IPv6 addresses than the limit, irregular packet drops may result at the router because the router does not maintain NCEs for all those IPv6 addresses [DHCP-PD]. This can be considered as a special flavor of NCE Exhaustion issue.
. 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 generally managed by their IP addresses. Consequently, if the router does not know a host's IP address, the service provider cannot manage the subscriber. This is an issue for public access networks.
2.4. Summary of ND Issue
The ND issues discussed in Sections 2.1 to 2.3 are summarized below. It is worth noting that these issues originate from three causes: multicast, trusting all hosts and Router-NCE-on-Demand. If a cause can be eliminated, the corresponding issues will also be eliminated. This points out the directions for ND optimization.. Performance issues caused by multicast
o LLA DAD degrading performance o Unsolicited RA draining hosts' battery o GUA/ULA DAD degrading performance o Router address resolution for hosts degrading performance o Host Address resolution for other hosts degrading
performance
o Host MAC change announcement degrading performance (minor
issue, no further discussion)
. Reliability issues caused by multicast
o LLA DAD not reliable for wireless networks o GUA/ULA DAD not reliable for wireless networks
. On-link security issues caused by trusting all hosts
Xiao Expires September 3, 2024 [Page 8]
Internet-Draft nd-considerations March 2024
o Source IP address spoofing o DAD denial o Forged RAs o Forged Redirects o Replay attacks. Off-link attack and other issues caused by Router-NCE-on-Demand
o Router NCE exhaustion o Router forwarding delay o Lack of subscriber management with SLAAC
It is worth noting that these are just potential issues. Depending on the usage scenarios, they may not actually happen. More specifically:
. Performance issues caused by multicast only happens in large L2
networks. If one's usage scenario is not a large L2 network, one needs not be concerned.
. Reliability issues caused by multicast only happens in wireless
networks.
. On-link security issues caused by trusting all hosts are non-
issues if hosts can be trusted.
. Off-link attack and other issues caused by Router-NCE-on-Demand
will not happen if one already deployed an optimized ND solution such as [RFC8273] or [DHCP-PD].
When the above issues can happen, it is advisable to be aware of the solutions available for them, as described in the next section.
3. Review of ND Solutions
This section reviews the ND optimization solutions developed over the years so that network administrators can get an idea of what solutions are available for which issues. The solutions are reviewed in an order that helps to reveal a theme: isolating hosts can help to prevent ND issues.
3.1. ND Solution in Mobile Broadband IPv6
Mobile Broadband IPv6 (MBBv6) is defined in "IPv6 in 3GPP EPS" [RFC6459], "IPv6 for 3GPP Cellular Hosts" [RFC7066], and "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link" [RFC7278]. The solution key points are:. Putting every host, i.e. the mobile User Equipment (UE), in a
P2P link with the router, i.e. the mobile gateway. MBBv6 also simplifies ND to take advantage of this P2P architecture. As a result: o All multicast is effectively turned into unicast o The P2P links in MBB do not have link layer address.
Xiao Expires September 3, 2024 [Page 9]
Internet-Draft nd-considerations March 2024
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:. P2P: every host, i.e. the Residential Gateway (RG), is in a P2P
link with the router, i.e. the Broadband Network Gateway (BNG). In this case, the solution is essentially the same as MBBv6. All ND issues are solved.
. P2MP: all hosts on an access device, e.g. the Optical Line
Terminal (OLT), are in a P2MP link with the router. This is implemented by aggregating all hosts into a single VLAN at the router and implementing Split Horizon at the access device to prevent direct host communication.
The solution key points of FBBv6-P2MP [TR177] are:
. Putting all hosts in a P2MP link with the router, and
implementing DAD Proxy. P2MP architecture with Split Horizon breaks normal ND's DAD procedure. Because all hosts are in the same interface from the router's perspective, the router must ensure that the hosts have different LLAs and GUAs. Otherwise, the router will not be able to distinguish them. But because hosts cannot reach each other, normal DAD will not work. Therefore, the router must participate in the hosts' DAD process and help hosts resolve duplication. This is called DAD Proxy [RFC6957]. With P2MP link and DAD Proxy:
o All host multicast to the router is effectively turned into
unicast, as every host can only reach the router.
Xiao Expires September 3, 2024 [Page 10]
Internet-Draft nd-considerations March 2024
o Trusting-all-host is only relevant to the router. Byapplying some simple filtering at the router, e.g. dropping RAs from the host, even malicious hosts cannot cause security harm.
. Assigning a unique /64 prefix to each host. As a result:
o When a prefix is assigned to the host, the router can
proactively create (IP prefix, MAC) binding and use it for forwarding. There is no 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 own subnet, unsolicited RAs will be sent individually to each host with the "host's MAC replacing the multicast MAC" approach specified in [RFC6085]. Therefore, router multicast is turned into unicast.
Since all the three causes of ND issues are addressed, FBBv6-P2MP addresses all ND issues.
3.3. Unique IPv6 Prefix per Host
Unique IPv6 Prefix per Host is specified in [RFC8273]. The purpose is to "improve host isolation and enhanced subscriber management on shared network segments" such as Wi-Fi or Ethernet. The solution key points are:. Assigning a unique prefix to each host with SLAAC. As a result:
o When a prefix is assigned to the host, the router can
proactively create (Prefix, MAC) binding and use it for forwarding. There is no 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 host by host in unicast because the prefix for every host is different.
Therefore, ND issues caused by NCE-on-Demand and router multicast are avoided.
RFC 8273 believes that "A network implementing a unique IPv6 prefix per host can simply ensure that devices cannot send packets to each other except through the first-hop router". But this may not be true when hosts are on a 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.
Xiao Expires September 3, 2024 [Page 11]
Internet-Draft nd-considerations March 2024 3.4. Wireless ND and Subnet NDWireless ND (WiND) is specified in a series of RFCs [RFC6775][RFC8505][RFC8928][RFC8929]. WiND defines a fundamentally different ND solution for Low-Power and Lossy Networks (LLNs) [RFC7102]. WiND changes host and router behaviors to use multicast only for router discovery. The solution key points are:
. Hosts use unicast to proactively register their addresses at
the routers. Routers use unicast to communicate with hosts and become an abstract registrar and arbitrator for address ownership.
. The router also proactively installs Neighbor Cache Entries
(NCEs) for the hosts. This avoids the need for address resolution for the hosts.
. The router sets PIO L-bit to 0. Each host communicates only
with the router.
. Other functionalities that are relevant only to LLNs.
WiND addresses all ND issues in LLNs. If it is used outside LLNs, it avoids ND issues caused by NCE-on-Demand and router multicast.
Subnet Neighbor Discovery [SND] generalizes the solutions defined in WiND and defines a new protocol named Subnet Gateway Protocol (SGP). It is being discussed in the IPv6 Maintenance (6man) WG.
3.5. Scalable Address Resolution Protocol
Scalable Address Resolution Protocol (SARP) is an Experimental solution specified in [RFC7586]. The usage scenario is Data Centers (DCs) where large L2 domains spanned across multiple sites. In each site, multiple hosts are connected to a switch. The hosts can be Virtual Machines (VMs) so the number can be large. The switches are interconnected by a native or overlay L2 network.The switch will snoop and install (IP, MAC) proxy table for the local hosts. The switch will also reply to address resolution requests from other sites to its hosts with its own MAC. This way, all hosts in a site will appear to have a single MAC to other sites. Therefore, a switch only needs to build a MAC table for the local hosts and the remote switches, not for all the hosts in the L2 domain. The MAC table size of the switches is therefore significantly reduced. A switch will also add the (IP, MAC) replies from remote switches to its proxy ND table so that it can reply to future address resolution requests for such IPs directly. This greatly reduces the number of address resolution multicast in the network.
Xiao Expires September 3, 2024 [Page 12]
Internet-Draft nd-considerations March 2024
Unlike MBBv6, FBBv6 and RFC 8372 which try to address all ND issues, SARP focuses on reducing address resolution multicast to improve performance and scalability of large L2 domains in DCs.3.6. ARP and ND Optimization for Transparent Interconnection of Lots of Links (TRILL):
ARP and ND Optimization for TRILL is specified in [RFC8302]. The solution is very similar to SARP discussed in Section 3.5. It can be considered as an application of SARP in the TRILL environment.
Like SARP, ARP and ND Optimization for TRILL focuses on reducing address resolution multicast.
3.7. Proxy ARP/ND in EVPN
Proxy ARP/ND in EVPN is specified in [RFC9161]. The usage scenario is Data Centers (DCs) where large L2 domains spanned across multiple sites. In each site, multiple hosts are connected to a Provider Edge (PE) router acting as a switch. The PEs are interconnected by an overlay network.PE of each site snoops the local address resolution NAs to build (IP, MAC) Proxy ND table entries. PEs then propagate such Proxy ND entries to other PEs via BGP EVPN. Each PE also snoops address resolution NSs from its hosts. If an entry exists in its Proxy ND table for the specified destination IP address, the PE will reply directly. Consequently, the number of multicast address resolution messages is significantly reduced.
Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address resolution multicast.
3.8. Gratuitous Neighbor Discovery
Gratuitous Neighbor Discovery is specified in [GRAND]. GRAND changes ND in the following ways:
Xiao Expires September 3, 2024 [Page 13]
Internet-Draft nd-considerations March 2024
. A node sends unsolicited NAs upon assigning a new IPv6 addressto its interface.
. A router creates a new NCE for the host and set its state to
STALE.
Later, when the router receives traffic to the host, the existence of the NCE entry in STALE state will cause the router to send unicast NS to the host to verify its reachability rather than sending multicast NS to resolve its MAC. This can shorten the time the host's NCE entry reaches REACHABLE state and improve forwarding performance. Therefore, GRAND provides an improvement but does not 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 key points are:. The router should respond to RS with unicast RA if the host's
source IP address is not unspecified (i.e. the RS is not the first RS before GUA DAD) and the host's MAC is valid. . The router should reduce multicast RA frequency. . Sleeping hosts that process unicast packets while asleep must
also process multicast RAs while asleep.
. Sleeping hosts that do not intend to maintain IPv6 connectivity
while asleep should either disconnect from the network and clear all IPv6 configuration, or perform Detecting Network Attachment in IPv6 (DNAv6) procedures [RFC6059] when waking up.
By reducing RAs, RFC 7772 reduces energy consumption of battery- powered hosts that can be waken up by RAs.
3.10. Source Address Validation Improvement and Router Advertisement Guard
Source Address Validation Improvement is specified in [SAVI]. Router Advertisement Guard is specified in [RA-Guard][RA-Guard+]. SAVI binds an address to a port and rejects claims from other ports for that address. Therefore, a node cannot spoof the IP address of another node. RA-Guard and RA-Guard+ only allow RAs from a port that a router is connected to. Therefore, nodes on other ports cannot pretend to be a router.
SAVI, RA-Guard and RA-Guard+ address the on-link security issues.
Xiao Expires September 3, 2024 [Page 14]
Internet-Draft nd-considerations March 2024 3.11. Dealing with Off-link Attack that May Cause Router NCE ExhaustionRouter 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 Minimizing subnet size so that there are fewer potential
NCEs to create;
o Rate-limiting the NDP queue to avoid CPU/memory overflow.
. For vendors:
o Prioritizing NDP processing for existing NCEs over creating
new NCEs
RFC 6583 acknowledges that "some of these options are 'kludges', and can be operationally difficult to manage". RFC 6583 partially addresses the Router NCE Exhaustion issue.
3.12. Enhanced DAD
Enhanced DAD is specified in [RFC7527]. Enhanced DAD addresses a DAD failure issue in a specific situation: looped back interface. DAD will fail in a looped back interface because the sending host will receive the DAD message back and will interpret it as another host is trying to use the same address. The solution is to include a Nonce option (defined in [SeND]) in each DAD message so that the sending host can detect that the looped back DAD message is sent by itself.Enhanced DAD does not solve any of the ND issues discussed in Section 2. It extends ND to work in a new scenario: looped back interface. It is reviewed here for completeness but will not be further discussed.
3.13. ND Mediation for IP Interworking of Layer 2 VPNs
ND mediation is specified in [RFC6575]. When two Attachment Circuits (ACs) are interconnected by a Virtual Private Wired Service (VPWS), and the two ACs are of different medium (e.g. one is Ethernet while the other is Frame Relay), the two Provider Edges (PEs) must interwork to provide mediation service so that a Customer Edge (CE) can resolve the link layer address of the remote end. RFC 6575 specifies such a solution. ND Mediation does not address any of the ND issues discussed in Section 2. It extends ND to work in a new scenario: two ACs of different media interconnected by a VPWS. It is reviewed here for completeness but will not be further discussed.
Xiao Expires September 3, 2024 [Page 15]
Internet-Draft nd-considerations March 2024 3.14. ND Solutions Defined before the Latest Versions of NDThe latest versions of [ND] and [SLAAC] are specified in RFCs 4861 and 4862. Several ND optimization solutions are based on the older version of ND and SLAAC. They are reviewed in this section for completeness but will not be further discussed.
3.14.1. SeND
Secure Neighbor Discovery [SeND] is specified in RFC 3971. The purpose is to ensure that hosts and routers are trustable. SeND defined three new ND options (i.e. Cryptographically Generated Addresses [CGA], RSA public-key cryptosystem, Timestamp/Nonce), an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in NDP.SeND addresses the Trusting-all-hosts issues. But it has high requirements on the hosts and routers, especially to maintain the keys. SeND is rarely deployed and will not be further discussed.
3.14.2. Cryptographically Generated Addresses (CGA)
Cryptographically Generated Addresses [CGA] is specified in RFC 3972. The purpose is to associate a cryptographic public key with an IPv6 address in [SeND]. The solution key point is to generate the Interface Identifier (IID) of the IPv6 address by computing a cryptographic hash of the public key. The resulting IPv6 address is called a CGA. The corresponding private key can then be used to sign messages sent from the address.CGA uses the fact that a legitimate host does not care about the bit combination of IID that would be created as a result of some hash procedure. The attacker needs an exact IID to impersonate the legitimate hosts but then the attacker is challenged to do a reverse hash calculation that is a strong mathematical challenge.
CGA is part of SeND. It is rarely deployed and will not be further discussed.
Xiao Expires September 3, 2024 [Page 16]
Internet-Draft nd-considerations March 2024 3.14.3. ND ProxyND 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. The solution key points are:
. When it receives an ND request from a host in a link, it will
"proxy" the message out from the "best" outgoing interface. How to determine the "best" interface is explained later. If there is no "best" interface, the ND-Proxy will "proxy" the message to all other links. Here "proxy" means acting as if the ND message originates from the ND-Proxy itself. That is, the ND- Proxy will change the ND message's source IP and source MAC to the ND-Proxy's outgoing interface's IP and MAC, and create an NCE entry at the outgoing interface accordingly.
. When ND-Proxy receives an ND reply, it will act as if the ND
message is destined to itself, and update the NCE entry state at the receiving interface. Based on such state information, the ND-Proxy can determine the "best" outgoing interface for future ND requests. The ND-Proxy then "proxy" the ND message back to the requesting host.
ND Proxy does not solve any of the ND issues discussed in Section 2. It extends ND to work in a new scenario: multiple links joined by a device that is not a bridge but acting like a bridge.
The idea of ND Proxy is widely used in SARP, ND Optimization for TRILL and Proxy ARP/ND in EVPN which are discussed in Sections 3.4 to 3.6.
3.14.4. Optimistic DAD
Optimistic DAD is specified in [RFC4429]. The purpose is to minimize address configuration delays in the successful case and to reduce disruption as far as possible in the failure case. 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 a 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 of the ND issues discussed in Section 2. It is reviewed here for completeness.
Xiao Expires September 3, 2024 [Page 17]
Internet-Draft nd-considerations March 2024 3.15. Observations on the SolutionsWhich ND solution solving which ND issue is tabulated below, for the fifteen issues summarized in Section 2.4:
. Performance issues caused by multicast
o I1: LLA DAD multicast degrading performance o I2: Unsolicited RA multicast draining hosts' battery o I3: GUA/ULA DAD multicast degrading performance o I4: Router address resolution multicast degrading
performance
o I5: Host Address resolution multicast degrading performance
. Reliability issues caused by multicast
o I6: LLA DAD not reliable for wireless networks o I7: GUA/ULA DAD not reliable for wireless networks
. On-link security issues caused by trusting all hosts
o I8: Source IP address spoofing o I9: DAD denial o I10: Fake RAs o I11: Fake Redirect o I12: Replay attacks
. Off-link attack and other issues caused by Router-NCE-on-Demand
o I13: Router NCE exhaustion o I14: Router forwarding delay o I15: Lack of subscriber management with SLAAC
+-----+-------------------+--------+--------+--------+------+-----+
| | Multicast | Reli- |On-link |R NCE |R Fwd.|Sub |
| | performance | ability|security|Exhaust.|Delay |Mgmt.|
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|Issue| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8-12 | 13 | 14 | 15 |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|MBBv6| All issues solved |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|FBBv6| All issues solved |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
Xiao Expires September 3, 2024 [Page 18]
Internet-Draft nd-considerations March 2024
|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/| | | | | | | | | | | |
|RAG | | | | | | | | X | | | |
|G+ | | | | | | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|6583 | | | | | | | | | X | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
Table 1. Which solution solves which issue(s)
Xiao Expires September 3, 2024 [Page 19]
Internet-Draft nd-considerations March 2024
Although the various ND solutions look unrelated, dividing them into three groups will help to reveal a theme: isolating hosts can prevent issues.The first group contains MBBv6, FBBv6, and Unique Prefix Per Host. These solutions isolate hosts in L3 and possibly L2, and they prevent all or most ND issues.
The second group contains WiND, SARP, ND Optimization for TRILL, and Proxy ND in EVPN. They use a proxy device to represent the hosts behind it, and effectively isolate such hosts into different multicast/broadcast domains from other hosts. These solutions alleviate address resolution and in the case of WiND other issues.
The third group contains the remaining solutions. They do not try to isolate hosts. They focus on solving a specific ND issue.
This theme reveals that, the stronger hosts are isolated, the more ND issues can be prevented. This is natural because isolating hosts reduces multicast and hosts to trust, two of the causes of ND issues.
This understanding can be used to formulate guidelines to prevent ND issues and simplify IPv6 first-hops where ND plays a key role.
4. Selectively Isolating Hosts to Prevent Potential ND Issues and Simplify IPv6 First-hops
This section describes how to isolate hosts, and the advantages and disadvantages of doing so. It also provides guidelines on how to select a suitable isolation method based on the deployment scenario.
The solution review in Section 3 reveals four different host isolation mechanisms:
. L3/Subnet isolation (i.e. Unique Prefix Per Host), used in
MBBv6, FBBv6 and RFC 8273.
. L2/Link isolation, with two flavors:
o P2P link isolation, used in MBBv6 and FBBv6-PPPoE; o P2MP link isolation, used in FBBv6-IPoE.
. Proxy isolation, used in WiND/SND, SARP, ND Optimization for
TRILL, Proxy ND in EVPN. This effectively divides a subnet into multiple multicast domains and can be considered as a L2 host isolation method.
. GUA isolation (i.e. setting PIO L-bit=0), which is a native ND
mechanism used in many solutions.
Xiao Expires September 3, 2024 [Page 20]
Internet-Draft nd-considerations March 2024
o GUA isolation is different from link isolation in that there can be multiple hosts in the link. It is just that each host treats other hosts as off-link and does not perform address resolution for other hosts' GUA. The host will send messages with GUA via the router instead. But all messages with LLA can still reach other hosts in the same broadcast domain. In link isolation, there is only one host in each link. A host cannot send messages with LLAs to other hosts.These isolation mechanisms are not completely independent:
First, [RFC4291] stated that "IPv6 continues the IPv4 model in that a subnet prefix is associated with one link". Therefore, link isolation and subnet isolation are better used together, otherwise, some ND issues may appear:
. L2 isolation without subnet isolation, which creates a Multi-
Link SubNet (MLSN), can cause GUA DAD not to work unless the router provides DAD Proxy [RFC6957] or address registration and arbitration [SND]. [RFC4903] documented the concerns about MLSN.
. Subnet isolation without L2 isolation, when used for multiple
hosts on a shared medium, can have on-link security issues if the hosts cannot be trusted. For example, LLA DAD denial may happen if attacker hosts exist.
However, link isolation depends on the physical media and may not always be possible, while subnet isolation requires a prefix for each host and may not always be possible either. Therefore, solutions using subnet isolation or link isolation separately exist.
Second, Proxy Isolation divides hosts in the same subnet into different broadcast domains. Hosts are isolated in different groups but not necessarily individually. This is effectively "L2 (Group) Isolation without L3 Isolation".
Third, GUA isolation is only meaningful for hosts in the same subnet and broadcast domain. Otherwise, setting PIO L-bit to 0 or 1 makes no difference.
Therefore, these different isolation mechanisms produce six meaningful combinations:
. Subnet Isolation with P2P Link . Subnet Isolation with P2MP Link . Subnet Isolation with Shared Medium. A shared medium is a broadcast domain. So, this is "Subnet Isolation without L2 Isolation" . Proxy Isolation, i.e. "L2 Isolation without Subnet Isolation" . GUA Isolation, i.e. "No L2 or L3 Isolation but GUA Isolation" . No isolation whatsoever
Xiao Expires September 3, 2024 [Page 21]
Internet-Draft nd-considerations March 2024
There is a logic in arranging the six isolation methods this way: the first three are L3 isolation with decreasing degree of L2 isolation, i.e. from P2P Link to P2MP Link to Shared Medium. The fourth is "L2 isolation without L3 isolation". Here the L2-isolated entity is usually a group of hosts but it can also be a single host. The fifth isolates hosts in the same subnet and broadcast domain from a GUA perspective. The sixth is no isolation at all. They go from the strongest degree to the weakest degree, and cover all possible isolation scenarios.Their applicability is discussed below.
4.1. Applicability of Subnet Isolation with P2P Link
The advantages are:o All ND issues are prevented.
The disadvantages are:
o The hosts must be able to set up P2P links with the router.
o Many prefixes will be needed, one per host.
o This is 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 scenarios. The fact that MBBv6 assigns a /64 to billions of mobile UEs [RFC6459], and FBBv6 assigns a /56 to millions of routed RGs [TR177] is evidence.
o Each host is easily identifiable by its unique prefix. This reduces privacy.
o The router must support a "Subnet Isolation with P2P Link" solution, e.g. MBBv6.
o Many interfaces will be needed at the router, one per host.
Xiao Expires September 3, 2024 [Page 22]
Internet-Draft nd-considerations March 2024
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. Applicability of Subnet Isolation with P2MP Link
The advantages and disadvantages of Subnet Isolation with P2MP Link are same as the P2P method, except that:o Hosts do not need the capability to set up P2P links with the router. The L2 medium must support P2MP Link, e.g. with [PVLAN] or Wireless Isolation [W-Iso].
o The router must support a "Subnet Isolation with P2MP Link" solution, including DAD Proxy.
o Only one interface is needed at the router
4.3. Applicability of Subnet Isolation with Shared Medium
The advantages are:o All ND issues are prevented except "LLA DAD multicast degrading performance", "LLA DAD not reliable for wireless networks", and "On-link security" issues. Depending on the shared medium, these remaining issues may not actually happen. For example, if the shared medium is Ethernet, "LLA DAD multicast degrading performance" and "LLA DAD not reliable for wireless networks" are non-issues. If the 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 likely the most usable host isolation method.
The disadvantages are:
o Many prefixes will be needed, one per host. But as explained above, this may not be an issue for organizations that can obtain sufficient IPv6 addresses from RIRs.
o The router must support a Subnet Isolation solution, e.g. [RFC8273] or [DHCP-PD].
Xiao Expires September 3, 2024 [Page 23]
Internet-Draft nd-considerations March 2024
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 can be a privacy issue.
4.4. Applicability of Proxy Isolation
The advantages of Proxy Isolation are:o Reduced multicast especially for address resolution, as the subnet is divided into multiple multicast domains.
o For solutions that proactively install NCEs on the router, e.g. WiND, all Router-NCE-On-Demand issues are prevented.
The disadvantages are:
o The router must support Proxy Isolation.
o Except WiND, other Proxy Isolation solutions are mainly to reduce address resolution. Other multicast, Trusting-all-hosts and Router-NCE-on-Demand issues will remain.
4.5. Applicability of GUA Isolation
The advantages of GUA Isolation are:o No address resolution for GUA among hosts.
o This is normal ND behavior. No additional ND optimization solution is needed.
The disadvantages are:
o Only multicast address resolution for GUA among hosts is eliminated. All other ND issues may still happen.
o All host communication with GUA will go through the router, and the router may become a bottleneck.
4.6. Guidelines for Selecting a Host Isolation Method
Given the applicability analysis above, network administrators can decide where to apply which isolation method. The guidelines below start from the strongest isolation method. This prevents the largest number of ND issues, and therefore, requires fewest additional solutions for the remaining issues. But the strongest isolation also has the highest entry requirements and the fewest applicable scenarios. If the strongest isolation is not possible, the next level of isolation is probed, all the way to no isolation at the end. Therefore, network administrators can likely find the most suitable isolation method for their deployment scenarios.
Xiao Expires September 3, 2024 [Page 24]
Internet-Draft nd-considerations March 2024
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 a too-strong isolation method means that the network administrator needs to do more work in meeting the higher entry requirement, while picking a too-weak isolation method means that the network administrator may need to deploy more ND optimization solutions to deal with potential issues. Either way, the overall solution can still work.1. If Subnet Isolation with P2P Link is feasible:
a) Applicable scenarios:
1) The medium is P2P.
2) Direct host to host communication without going through the router is not needed.
3) Multicast is not desirable (implying mDNS is not needed).
4) Hosts may not be trustable.
5) Subscriber management is needed.
6) Privacy of hosts are not a major concern.
Examples are public access networks such as MBBv6 or FBBv6 with PPPoE.
b) Entry requirements:
1) Hosts must be able to set up P2P links with the router.
2) There are sufficient IPv6 addresses to provide Unique Prefix Per Host.
Xiao Expires September 3, 2024 [Page 25]
Internet-Draft nd-considerations March 2024
3) The router must support a "Subnet Isolation with P2P Link" solution, e.g. MBBv6.c) Remaining ND issues and solutions:
1) None.
2. Otherwise, if Subnet Isolation with P2MP Link is feasible
a) Applicable scenarios:
1) Same as the P2P scenarios except that the medium is P2MP.
Examples are FBBv6 with IPoE or public Wi-Fi access.
b) Entry requirements:
1) There are sufficient IPv6 addresses to provide Unique Prefix Per Host.
2) The router must support a "Subnet Isolation with P2MP Link" solution, including DAD Proxy, e.g. FBBv6-P2MP.
c) Remaining ND issues and solutions
1) None
3. Otherwise, if Subnet Isolation with Shared Medium is feasible
a) Applicable scenarios:
1) The medium is a shared medium.
2) Direct host to host communication is not needed.
3) Privacy of hosts is not a major concern.
b) Entry requirements:
1) There are sufficient IPv6 addresses to provide Unique Prefix Per Host.
2) The router must support Unique Prefix Per Host, e.g. [RFC8273] or [DHCP-PD].
Xiao Expires September 3, 2024 [Page 26]
Internet-Draft nd-considerations March 2024
c) Remaining ND issues and solutions1) "LLA DAD multicast degrading performance", "LLA DAD not reliable for wireless networks", and "On-link security" issues can theoretically happen. Depending on the shared medium, these remaining issues may not actually happen. For example, if the shared medium is Ethernet, "LLA DAD multicast degrading performance" and "LLA DAD not reliable for wireless networks" are non-issues. If the link is not a public access link, "On-link security" may also be non-issues. It is advisable to use this method where these remain issues are not a big concern. If they are a concern, Subnet Isolation with P2P or P2MP Link may be more suitable.
4. Otherwise, if Proxy Isolation is feasible
a) Applicable scenarios:
1) The hosts are in a subnet, but it is possible to separate them into different broadcast/multicast domains, e.g. in a multi-link subnet, or a large DC involving a large number of VMs spanning across multiple sites interconnected by PEs supporting SARP.
b) Entry requirements:
1) The PEs must support a Proxy Isolation solution like WiND, SARP, or Proxy ND in EVPN.
c) Remaining ND issues and solutions:
1) WiND/SND solves all ND issues but they are fundamentally different ND solutions that require both router and host changes. Other proxy isolation solutions only reduce multicast address resolution for GUA among hosts while other ND issues may happen. Depending on the deployment scenarios, solutions in Table 1 can be selected for the issues that will actually happen.
5. If there are still multiple hosts in a same subnet and broadcast domain, if GUA Isolation (i.e. setting PIO L-bit=0) is feasible
a) Applicable scenarios:
Xiao Expires September 3, 2024 [Page 27]
Internet-Draft nd-considerations March 2024
1) It is desirable to avoid host address resolution for other hosts in the same broadcast domain.b) Entry requirements:
1) None as this is a native ND mechanism.
c) Remaining ND issues and solutions:
1) Only multicast GUA address resolution is eliminated. All other ND issues may happen. Depending on the deployment scenarios, solutions in Table 1 can be selected for the issues that will actually happen.
6. Otherwise, no isolation to apply
a) Applicable scenarios:
1) ND issues are not a concern. That is, multicast is not a problem, hosts can be trusted, and Router-NCE-on-demand is not an issue.
2) Some ND issues are a concern, but it is preferable to deploy the corresponding ND optimization solutions than to isolate hosts.
b) Entry requirements:
1) None.
c) Remaining issues and solutions
1) All ND issues can happen theoretically. Depending on what are of concern practically, the corresponding ND optimization solutions tabulated in Table 1 can be applied.
4.7. Impact of Host Isolation on Other Protocols in IPv6 First-hops
The impact (i.e. the disadvantages) of various isolation methods to the IPv6 first-hop has been discussed in the applicability sections. The guidelines have taken such applicability into consideration and given network administrators the option not to apply any isolation. Therefore, if an isolation method is indeed selected, its advantages likely outweigh its disadvantages.
Xiao Expires September 3, 2024 [Page 28]
Internet-Draft nd-considerations March 2024 5. Security ConsiderationsThis document provides guidelines on how to select a suitable isolation method depending on the deployment scenarios. When an isolation method is selected, the security considerations of the used solutions which are defined in the corresponding RFCs apply. These security considerations are discussed in Section 4. In particular, using Unique Prefix Per Host makes a host identifiable by the prefix and reduces privacy. It is incompatible with using temporary addresses to increase privacy [RFC8981]. This document itself does not introduce any new solutions. Therefore, it does not introduce new security issues.
6. IANA Considerations
This document has no request to IANA.7. References 7.1. Informative References[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-07.
[GRAND] J. Linkova, "Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on First-Hop Routers", RFC 9131
[mDNS] S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, RFC 4861.
[PVLAN] https://en.wikipedia.org/wiki/Private_VLAN
[RA-Guard]E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, RFC 6105.
[RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, RFC 7113.
Xiao Expires September 3, 2024 [Page 29]
Internet-Draft nd-considerations March 2024
[RFC3756] P. Nikander, J. Kempf, E. Nordmark, "IPv6 NeighborDiscovery (ND) Trust Models and Threats", RFC 3756.
[RFC4291] R. Hinden, S.Deering, "IP Version 6 Addressing
Architecture", RFC 4291.
[RFC4389] D. Thaler, M. Talwar, C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389.
[RFC4429] N. Moore, "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429.
[RFC4903] D. Thaler, "Multi-Link Subnet Issues", RFC 4903.
[RFC6459] J. Korhonen, J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459.
[RFC6059] S. Krishnan, G. Daley, "Simple Procedures for Detecting
Network Attachment in IPv6", RFC 6059.
[RFC6085] S. Gundavelli, M. Townsley, O. Troan, W. Dec, "Address
Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085.
[RFC6575] H. Shah, E. Rosen, G. Heron, V. Kompella, "Address
Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs", RFC 6575.
[RFC6583] I. Gashinsky, J. Jaeggli, W. Kumari, "Operational Neighbor
Discovery Problems", RFC 6583.
[RFC6775] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775.
[RFC6957] F. Costa, J-M. Combes, X. Pougnard, H. Li, "Duplicate
Address Detection Proxy", RFC 6957
[RFC7066] J. Korhonen, J. Arkko, T. Savolainen, S. Krishnan, "IPv6
for Third Generation Partnership Project (3GPP) Cellular Hosts", RFC 7066.
[RFC7102] JP. Vasseur, "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102.
Xiao Expires September 3, 2024 [Page 30]
Internet-Draft nd-considerations March 2024
[RFC7278] Extending an IPv6 /64 Prefix from a Third GenerationPartnership 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.
[RFC8981] F. Gont, S.Krishnan, T.Narten, R. Draves, "Temporary
Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981.
[RFC9099] E. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey, "Operational
Security Considerations for IPv6 Networks", RFC 9099.
Xiao Expires September 3, 2024 [Page 31]
Internet-Draft nd-considerations March 2024
[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.
[W-Iso] Wireless Isolation, https://www.quora.com/What-is-
wireless-isolation
8. Acknowledgments
The authors would like to thank Lorenzo Colitti, Pascal Thubert, Jen Linkova, Brian Carpenter, Mike Ackermann, Nalini Elkins, Ed Horley, Ole Troan, David Thaler, Eric Vyncke for their reviews and comments.
Xiao Expires September 3, 2024 [Page 32]
Internet-Draft nd-considerations March 2024
Authors' AddressesXiPeng 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 September 3, 2024 [Page 33]