IPv6 Operations (v6ops) Working Group X. Xiao
Internet Draft E. Vasilenko
Intended status: Informational Huawei Technologies
Expires: October 2023 E. Metz
KPN
G. Mishra
Verizon Inc.
N. Buraglio
Energy Sciences Network
April 27, 2023
Selectively Isolating Hosts to Prevent Potential Neighbor Discovery
Protocol Issues
draft-ietf-v6ops-nd-considerations-01
Abstract
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 and some guidelines are 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 then described for
selecting a suitable isolation method based on the deployment
scenario.
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 April 27, 2023 [Page 1]
Internet-Draft nd-considerations April 2023
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 Oct. 2023.
Copyright Notice
Copyright (c) 2023 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 Causes Performance and Reliability Issues.......5
2.2. Trusting-all-hosts Causes On-link Security Issues.........6
2.3. NCE-on-Demand Causes Performance, NCE Exhaustion and Lack of
Subscriber Management Issues...................................7
2.4. Summary of ND Issue.......................................7
3. Review of ND Solutions.........................................8
3.1. ND Solution in Mobile Broadband IPv6......................9
3.2. ND Solution in Fixed Broadband IPv6.......................9
3.3. Unique IPv6 Prefix per Host..............................10
3.4. Wireless ND..............................................11
3.5. Scalable Address Resolution Protocol.....................11
3.6. ARP and ND Optimization for Transparent Interconnection of
Lots of Links (TRILL):........................................12
3.7. Proxy ARP/ND in EVPN.....................................12
3.8. Gratuitous Neighbor Discovery............................13
3.9. Reducing Router Advertisements...........................13
3.10. Source Address Validation Improvement and Router
Advertisement Guard...........................................13
3.11. Dealing with Off-link Attack that May Cause Router NCE
Exhaustion....................................................14
3.12. Enhanced DAD............................................14
Xiao Expires October 27, 2023 [Page 2]
Internet-Draft nd-considerations April 2023
3.13. ND Mediation for IP Interworking of Layer 2 VPNs........14
3.14. ND Solutions Defined before the Latest Versions of ND...15
3.14.1. SeND...............................................15
3.14.2. Cryptographically Generated Addresses (CGA)........15
3.14.3. ND Proxy...........................................16
3.14.4. Optimistic DAD.....................................16
3.15. Observations on the Solutions...........................17
4. Selectively Isolating Hosts to Prevent Potential ND Issues....19
4.1. Applicability of Subnet Isolation with P2P Link..........21
4.2. Applicability of Subnet Isolation with P2MP Link.........22
4.3. Applicability of Subnet Isolation with Shared Medium.....22
4.4. Applicability of GUA Isolation...........................23
4.5. Applicability of Proxy Isolation.........................23
4.6. Guidelines for Selecting a Host Isolation Method.........23
4.7. Impact of Host Isolation on Other Protocols in IPv6 First-
hops..........................................................27
5. Security Considerations.......................................27
6. IANA Considerations...........................................27
7. References....................................................28
7.1. Informative References...................................28
8. Acknowledgments...............................................31
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
seven main procedures:
1. Hosts generate Link Local Addresses (LLAs) and use multicast
Neighbor Solicitations (NSs) for Duplicate Address Detection
(DAD).
2. 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. Hosts form Global Unicast Address (GUA) or Unique Local Address
(ULA) and use multicast Neighbor Solicitations (NSs) for DAD.
4. When a packet is to be sent, routers use multicast NSs to
perform address resolution for the destination host.
5. When a packet is to be sent, hosts use multicast NSs to perform
address resolution for the destination host.
6. Hosts/routers use unicast NS for Node Unreachability Detection
(NUD).
7. Hosts may use multicast NSs to announce link layer address
changes.
Xiao Expires October 27, 2023 [Page 3]
Internet-Draft nd-considerations April 2023
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], 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
fully informed before their deployment, they may encounter problems
later and question IPv6's value. 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
and for selecting solutions for the remaining issues.
Due to the potential ND issues, there have been efforts over the
years to redesign the ND protocol to solve the issues. But because
ND has already been widely deployed, redesigning ND is difficult and
such efforts have not been widely accepted. Therefore, providing
operations guidelines to avoid the issues is a practical alternative
for IPv6 deployers.
1.1. Terminology
Some important terms are defined in this section.
MAC - To avoid confusion with link local address, link layer
address is called MAC in this document.
Link isolation for hosts - isolating hosts in L2. This includes 2
flavors: P2P link isolation and P2MP link isolation.
P2P link isolation - connecting each host in a P2P link to the
router. 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.
Xiao Expires October 27, 2023 [Page 4]
Internet-Draft nd-considerations April 2023
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.
Subnet isolation for hosts - assigning a unique prefix per host so
each host is in its own subnet [RFC8273].
GUA/ULA isolation for hosts - setting PIO L-bit=0 so that other
hosts appear off-link [ND]. There will be no GUA/ULA
resolution for other hosts in the link, and all GUA/ULA
traffic will be sent via the router. Therefore hosts appear
isolated from a GUA/ULA perspective. To be simple, this is
also called GUA Isolation in this document.
Proxy isolation for hosts - using an ND proxy device to represent
the hosts behind it, and effectively isolate such hosts from
other hosts.
2. Review of ND Issues
2.1. Multicast Causes Performance and Reliability Issues
ND uses multicast extensively for Node Solicitations (NSs), 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, to ensure that the multicast messages reach
even the remotest hosts, multicast messages are sent at the lowest
modulation rate. This prolongs receiving time and consumes more
power of the hosts. Some low-power or remote hosts may not receive
or respond to multicast messages. In addition, multicast messages
are not acknowledged at L2. Consequently, multicast in wireless
networks reduces not only network performance but also protocol
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.
Xiao Expires October 27, 2023 [Page 5]
Internet-Draft nd-considerations April 2023
ND uses the following multicast messages. Their impact on
performance and reliability is summarized below:
. Hosts' LLA DAD: may cause a performance issue, and a
reliability issue in wireless networks.
. Router's periodic unsolicited RAs: may cause performance issue
if it is sent frequently [RFC7772].
. Hosts' GUA (or ULA) DAD: may cause a performance issue, and a
reliability issue in wireless networks.
. Router's address resolution for hosts: in a large network of N
hosts, there can be N such multicast messages. This may cause a
performance issue.
. Hosts address resolution for hosts: in a large network of N
hosts, there can be N-square such multicast messages. This may
cause the largest performance issue.
. 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.
. 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 captures valid ND messages and
replays them later.
Xiao Expires October 27, 2023 [Page 6]
Internet-Draft nd-considerations April 2023
2.3. NCE-on-Demand Causes Performance, NCE Exhaustion and Lack of
Subscriber Management Issues
In ND, a node (router or host) does not maintain (IP, MAC) binding
(i.e. Neighbor Cache Entry or NCE) for another node until it is
needed. This is called NCE-on-Demand. When a node is to forward a
packet to another on-link node, it will perform address resolution
to find the MAC of the destination node. This can cause multiple
issues:
. The packet has to be queued before the router finds out the MAC
of the destination node. This reduces forwarding performance
and may be an issue in high-performance computing environment,
e.g. DCs. This is called "NCE-on-Demand Performance
Degradation" 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, 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 node, the node will
create a large amount of NCEs with INCOMPLETE state while
trying to resolve the MACs. The node 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 [Collink]. This can be
considered as a special flavor of NCE Exhaustion issue.
. Without an NCE, a router does not know the IP address of a host
when SLAAC is used rather than [DHCPv6]. 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
Xiao Expires October 27, 2023 [Page 7]
Internet-Draft nd-considerations April 2023
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 degrading performance
o GUA (or 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 (or ULA) DAD not reliable for wireless networks
. On-link security issues caused by trusting all hosts
o Source IP address spoofing
o DAD denial
o Forged RAs
o Forged Redirects
o Replay attacks
. Off-link security issues caused by NCE-on-Demand
o Router NCE exhaustion
. Performance issue caused by NCE-on-Demand
o NCE on demand degrading performance
. Subscriber management issue caused by NCE-on-Demand at the
router
o Lack of subscriber management using ND with SLAAC
It is worth noting again that these are just potential issues.
Depending on the usage scenarios, they may not actually happen, and
when they do happen, they do not necessarily cause harm. But it is
advisable to be aware of these potential issues and the solutions
for them.
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 to avoid
ND issues. This theme will be further analyzed in Section 3.15 after
all the solutions are reviewed.
Xiao Expires October 27, 2023 [Page 8]
Internet-Draft nd-considerations April 2023
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.
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
Xiao Expires October 27, 2023 [Page 9]
Internet-Draft nd-considerations April 2023
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.
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.
. 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 need for 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 need for 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.
Xiao Expires October 27, 2023 [Page 10]
Internet-Draft nd-considerations April 2023
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 certain shared medium like Ethernet. In this
case, hosts may still reach each other in L2 with their LLAs via
upgream multicast. So issues caused by host multicast and Trusting-
all-hosts may happen, e.g. on-link security issues.
3.4. Wireless ND
Wireless ND (WiND) is specified in a series of RFCs
[RFC6775][RFC8505][RFC8928][RFC8929]. WiND defines a new 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 the central address register and arbitrator for the
hosts.
. 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 is a totally new ND solution. It addresses all ND issues in
LLNs. If it is used outside LLNs, it avoids ND issues caused by NCE-
on-Demand and router multicast. But if it is used with shared media,
its use of host multicast for router discovery means that host-
multicast related issues and Trusting-all-host related issues may
happen.
3.5. Scalable Address Resolution Protocol
Scalable Address Resolution Protocol (SARP) is specified in
[RFC7586]. It is an Experimental solution. The usage scenario is
Xiao Expires October 27, 2023 [Page 11]
Internet-Draft nd-considerations April 2023
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.
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
Xiao Expires October 27, 2023 [Page 12]
Internet-Draft nd-considerations April 2023
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
router and host behaviors to allow routers to proactively create an
NCE when a new IPv6 address is assigned to a host, and to recommend
that hosts send unsolicited Neighbor Advertisements upon having a
new IPv6 address. It can be considered as the IPv6 equivalent of
Gratuitous ARP in IPv4.
GRAND prevents the Router-NCE-on-Demand issue.
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.
RFC 7772 alleviates the multicast RA issue.
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 October 27, 2023 [Page 13]
Internet-Draft nd-considerations April 2023
3.11. Dealing with Off-link Attack that May Cause Router NCE Exhaustion
Router NCE Exhaustion handling is described in [RFC6583]. This is to
deal with the off-link security 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.
Xiao Expires October 27, 2023 [Page 14]
Internet-Draft nd-considerations April 2023
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.
3.14. 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 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 in
this document.
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 in this document.
Xiao Expires October 27, 2023 [Page 15]
Internet-Draft nd-considerations April 2023
3.14.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. 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. 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 tries to enhance ND's performance for DAD. But the
changes are big and the benefits are not significant. Optimistic DAD
has not been widely deployed.
Xiao Expires October 27, 2023 [Page 16]
Internet-Draft nd-considerations April 2023
3.15. Observations on the Solutions
Which ND solution solving which ND issue is tabulated below, for the
fifteen ND issues summarized in Section 2.4:
. Performance issues caused by multicast
o I1: LLA DAD multicast degrading performance
o I2: Unsolicited RA multicast degrading performance
o I3: GUA (or 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 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 security issues caused by NCE-on-Demand
o I13: Router NCE exhaustion
. Performance issue caused by NCE-on-Demand
o I14: NCE on demand degrading performance
. Subscriber management issue caused by NCE-on-Demand at the
router
o I15: Lack of subscriber management using ND with SLAAC
+-----+-------------------+--------+--------+--------+------+-----+
| | Multicast | Reli- |On-link |Off-link|NCE on|Sub |
| | performance | ability|security|security|Demand|Mgmt.|
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|Issue| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8-12 | 13 | 14 | 15 |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|MBBv6| All issues solved |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|FBBv6| All issues solved |
Xiao Expires October 27, 2023 [Page 17]
Internet-Draft nd-considerations April 2023
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|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 | | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|SAVI/| | | | | | | | | | | |
|RAG | | | | | | | | X | | | |
|G+ | | | | | | | | | | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
|6583 | | | | | | | | | X | | |
+-----+---+---+---+---+---+---+----+--------+--------+------+-----+
Xiao Expires October 27, 2023 [Page 18]
Internet-Draft nd-considerations April 2023
Table 1. Which solution solves which issue(s)
It is worth noting again that SARP is an Experimental solution.
Caution should be applied whether to choose this solution.
Although the various ND solutions look unrelated, dividing them into
four groups will help to reveal a common theme: isolating hosts to
prevent issues.
The first group contains MBBv6, FBBv6, Unique Prefix Per Host and
WiND. These solutions all isolate hosts individually in some way,
and they prevent all or most ND issues.
The second group contains 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 from other hosts. The
solutions alleviate the biggest ND performance issue - address
resolution among hosts.
The third group contains Reducing RAs, SAVI, RA-Guard, RA-Guard+,
and Dealing with Off-link Security Issue. They do not try to isolate
hosts. They focus on solving a specific ND issue instead.
The fourth group contains the solutions designated "will not be
further discussed". They are not relevant to the discussion here.
This theme reveals an insight: isolating hosts is effective in
preventing ND issues. 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 insight can be used to formulate guidelines to simplify IPv6
first-hop deployments where ND plays a key role.
4. Selectively Isolating Hosts to Prevent Potential ND Issues
This section describes how to isolate hosts and the advantages and
disadvantages of doing so. It also provides some 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 methods:
. Link isolation, with 2 flavors:
Xiao Expires October 27, 2023 [Page 19]
Internet-Draft nd-considerations April 2023
o P2P link isolation, used in MBBv6 and FBBv6-PPPoE
o P2MP link isolation, used in FBBv6-IPoE
. Subnet isolation (i.e. Unique Prefix Per Host), used in MBBv6,
FBBv6 and RFC 8273
. GUA isolation (i.e. setting PIO L-bit=0), used in WiND and RFC
8273
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 link
isolation, there is only one host in each link. A host
cannot send messages with LLAs to other hosts.
. Proxy isolation, used in SARP, ND Optimization for TRILL, Proxy
ND in EVPN
These different isolation methods 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, so that the
link and the subnet are congruent in scope: both have just one host.
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
arbition [RFC8929]. [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 can not 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 or desirable. Therefore, subnet isolation without
link isolation can still be useful. The suitable usage scenarios
will be described in the applicability section below.
Second, link isolation and subnet isolation automatically imply GUA
isolation. When there is only one host in a link/subnet, setting PIO
L-bit to 1 has the same effect as setting it to 0, because all
communication using GUA will go through the router.
Xiao Expires October 27, 2023 [Page 20]
Internet-Draft nd-considerations April 2023
Third, proxy isolation and other isolation methods are mutually
exclusive. Proxy isolation uses a proxy to represent multiple hosts
at a site. In other words, hosts are not isolated individually like
in link/subnet/GUA isolation.
Therefore, these different isolation methods produce five meaningful
combinations:
. Subnet Isolation with P2P Link
. Subnet Isolation with P2MP Link
. Subnet Isolation with Shared Medium
. GUA Isolation (without link or subnet isolation)
. Proxy Isolation
These isolation methods are listed from the highest degree of
isolation to the lowest. 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 probably not an issue for IPv6. Today, any
organization can become a member of a Regional Internet
Registry (RIR) and 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 every mobile
UE [RFC6459], and FBBv6 assigns a /56 to every routed RG
[TR177] is evidence.
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.
o All hosts will communicate through the router, and the router may
become a bottleneck.
Xiao Expires October 27, 2023 [Page 21]
Internet-Draft nd-considerations April 2023
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 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 happen either. 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" issues may not happen either.
o There is no new requirement on the hosts. Therefore this method
can be applied in many scenarios.
The disadvantages are:
o Many prefixes will be needed, one per host. But as explained
above, this may not be an issue for most organizations that can
obtain sufficient IPv6 addresses from RIRs.
o The router must support Subnet Isolation (ie. Unique Prefix Per
Host, e.g. [RFC8273] or [Collink]).
o All host communication with GUA or ULA will go through the
router, and the router may become a bottleneck.
Xiao Expires October 27, 2023 [Page 22]
Internet-Draft nd-considerations April 2023
4.4. Applicability of GUA Isolation
The advantages of GUA Isolation are:
o No address resolution for GUA among hosts. This eliminates the
largest source of multicast in ND.
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 depending on the
usage scenarios. Consequently, other solutions may be needed to
solve such issues.
o All host communication with GUA will go through the router, and
the router may become a bottleneck.
4.5. Applicability of Proxy Isolation
The advantages of Proxy Isolation are:
o Reduced address resolution for GUA among hosts behind different
proxies. This reduces the largest source of multicast in ND.
o Hosts can communicate directly without going through the router.
This can be desirable in a high-performance computing environment
like DCs.
The disadvantages are:
o The router must support Proxy Isolation.
o Only multicast address resolution for GUA among hosts behind
different proxies is reduced. All other ND issues may happen.
Consequently, other solutions may be needed to solve such issues.
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 most ND issues, and therefore, requires fewest
Xiao Expires October 27, 2023 [Page 23]
Internet-Draft nd-considerations April 2023
additional solutions for the remaining issues. The overall solution
will likely be the simplest. 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 tried, until no isolation is applied. Therefore,
network administrators can likely find the most suitable isolation
method for their deployment scenarios.
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
a 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.
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.
3) The router must support a "Subnet Isolation with P2P
Link" solution, e.g. MBBv6 [RFC6459][RFC7066][RFC7278].
c) Remaining issues and solutions:
1) None.
2. Otherwise, if Subnet Isolation with P2MP Link is feasible
a) Applicable scenarios:
Xiao Expires October 27, 2023 [Page 24]
Internet-Draft nd-considerations April 2023
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
[TR177].
c) Remaining 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 without going through
a router is not needed.
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 [Collink].
c) Remaining issues and solutions
1) "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
not be issues either. It is advisable to use this method
Xiao Expires October 27, 2023 [Page 25]
Internet-Draft nd-considerations April 2023
where these remain issues are not a concern. If they are
a concern, Subnet Isolation with P2P or P2MP Link may be
more suitable.
4. Otherwise, if GUA Isolation (i.e. setting PIO L-bit=0) is feasible
a) Applicable scenarios:
1) It is desirable to avoid host address resolution for
other hosts.
2) Multicast among hosts is needed.
Examples are [HomeNet] where mDNS is desired or LLNs.
b) Entry requirements:
1) For LLNs, WiND is required.
2) For other scenarios, no new requirement.
c) Remaining issues and solutions:
1) If WiND is used, all ND issues are prevented, as WiND
has modified ND to handle the issues.
2) If normal ND is used, only multicast GUA address
resolution hosts 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.
5. Otherwise, if Proxy Isolation is feasible
a) Applicable scenarios:
1) Large scale DC involving a large number of VMs, and the
link spanned across multiple sites interconnected by PEs
b) Entry requirements:
1) The PEs must support a Proxy Isolation solution like
SARP, ND Optimization for TRILL or Proxy ND in EVPN.
c) Remaining issues and solutions:
Xiao Expires October 27, 2023 [Page 26]
Internet-Draft nd-considerations April 2023
1) Only multicast address resolution for GUA among hosts is
reduced. 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 NCE-on-demand is not
an issue.
b) Entry requirements:
1) None.
c) Remaining issues and solutions
1) All ND issues may happen. Depending on the deployment
scenarios, solutions in Table 1 can be selected for the
issues that will actually happen..
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 haven taken such applicability into account and given
network adminstrators the option not to use any isolation method at
all. Therefore, if an isolation method is indeed selected, its
benefits likely outweigh its cost.
5. Security Considerations
This document provides guidelines on how to select a suitable
isolation method depending on the deployment scenario. 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. This
document does not introduce any new solutions. Therefore, it does
not introduce new security issues.
6. IANA Considerations
This document has no request to IANA.
Xiao Expires October 27, 2023 [Page 27]
Internet-Draft nd-considerations April 2023
7. References
7.1. Informative References
[CGA] T. Aura, "Cryptographically Generated Addresses (CGA)",
RFC3972
[Collink] L. Colitti, J. Linkova, X. Ma, "Using DHCP-PD to Allocate
Unique IPv6 Prefix per Host in Broadcast Networks", draft-
collink-v6ops-ent64pd-03.
[DHCPv6] T. Mrugalski M. Siodelski B. Volz A. Yourtchenko M.
Richardson S. Jiang T. Lemon T. Winters, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 8415.
[GRAND] J. Linkova, "Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on First-Hop Routers", RFC 9131
[HomeNet] T. Chown, J. Arkko, A. Brandt, O. Troan, J. Weil, "IPv6
Home Networking Architecture Principles", RFC 7368, DOI
10.17487/RFC7368, October 2014, RFC 7368.
[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.
[RFC3756] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor
Discovery (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.
Xiao Expires October 27, 2023 [Page 28]
Internet-Draft nd-considerations April 2023
[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.
[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.
Xiao Expires October 27, 2023 [Page 29]
Internet-Draft nd-considerations April 2023
[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.
[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
Xiao Expires October 27, 2023 [Page 30]
Internet-Draft nd-considerations April 2023
[SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI
10.17487/RFC4862, September 2007, <https://www.rfc-
editor.org/info/rfc4862>.
[TR177] S. Ooghe, B. Varga, W. Dec, D. Allan, "IPv6 in the context
of TR-101", Broadband Forum, TR-177.
[W-Iso] Wireless Isolation, https://www.quora.com/What-is-
wireless-isolation
8. Acknowledgments
The authors would like to thank Pascal Thubert, Ole Troan, Brian
Carpenter, David Thaler, Jen Linkova, Eric Vyncke, Lorenzo Colitti
for the discussion and input.
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 October 27, 2023 [Page 31]
