rfc9898v1.txt		rfc9898.txt
	skipping to change at line 72 ¶		skipping to change at line 72 ¶
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Terminology		1.1. Terminology
	2. Review of Inventoried ND Issues		2. Review of Inventoried ND Issues
	2.1. Multicast May Cause Performance and Reliability Issues		2.1. Multicast May Cause Performance and Reliability Issues
	2.2. Trusting-All-Hosts May Cause On-Link Security Issues		2.2. Trusting-All-Nodes May Cause On-Link Security Issues
	2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE		2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE
	Exhaustion, and Address Accountability Issues		Exhaustion, and Address Accountability Issues
	2.4. Summary of ND Issues		2.4. Summary of ND Issues
	3. Review of ND Mitigation Solutions		3. Review of ND Mitigation Solutions
	3.1. ND Solution in Mobile Broadband IPv6		3.1. Mobile Broadband IPv6 (MBBv6)
	3.2. ND Solution in Fixed Broadband IPv6		3.2. Fixed Broadband IPv6 (FBBv6)
	3.3. Unique IPv6 Prefix per Host (UPPH)		3.3. Unique Prefix per Host (UPPH)
	3.4. Wireless ND and Subnet ND		3.4. Wireless ND (WiND)
	3.5. Scalable Address Resolution Protocol		3.5. Scalable Address Resolution Protocol (SARP)
	3.6. ARP and ND Optimization for TRILL		3.6. ND Optimization for TRILL
	3.7. Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN)		3.7. Proxy ND in Ethernet Virtual Private Networks (ND EVPN)
	3.8. Reducing Router Advertisements		3.8. Reducing Router Advertisements per RFC 7772
	3.9. Gratuitous Neighbor Discovery (GRAND)		3.9. Gratuitous Neighbor Discovery (GRAND)
	3.10. Source Address Validation Improvement (SAVI) and Router		3.10. Source Address Validation Improvement (SAVI) and Router
	Advertisement Guard		Advertisement Guard (RA-Guard)
	3.11. RFC 6583 Dealing with NCE Exhaustion Attacks		3.11. Dealing with NCE Exhaustion Attacks per RFC 6583
	3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6		3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6 per
			RFC 9686
	3.13. Enhanced DAD		3.13. Enhanced DAD
	3.14. ND Mediation for IP Interworking of Layer 2 VPNs		3.14. ND Mediation for IP Interworking of Layer 2 VPNs
	3.15. ND Solutions Defined Before the Latest Versions of ND		3.15. ND Solutions Defined Before the Latest Versions of ND
	3.15.1. Secure Neighbor Discovery (SEND)		3.15.1. Secure Neighbor Discovery (SEND)
	3.15.2. Cryptographically Generated Addresses (CGA)		3.15.2. Cryptographically Generated Addresses (CGA)
	3.15.3. ND Proxy		3.15.3. ND Proxy
	3.15.4. Optimistic DAD		3.15.4. Optimistic DAD
	4. Guidelines for Prevention of Potential ND Issues		4. Guidelines for Prevention of Potential ND Issues
	4.1. Learning Host Isolation from the Existing Solutions		4.1. Learning Host Isolation from the Existing Solutions
	4.2. Applicability of Various Isolation Methods		4.2. Applicability of Various Isolation Methods
	skipping to change at line 157 ¶		skipping to change at line 158 ¶
	If the next hop is a router, the host already has the NCE for		If the next hop is a router, the host already has the NCE for
	that router. If the next hop is an on-link host, it will use		that router. If the next hop is an on-link host, it will use
	multicast NSs to perform address resolution for the destination		multicast NSs to perform address resolution for the destination
	host. As a result, the source host installs an NCE for the		host. As a result, the source host installs an NCE for the
	destination host.		destination host.
	5. Node Unreachability Detection (NUD): The host uses unicast NSs to		5. Node Unreachability Detection (NUD): The host uses unicast NSs to
	determine whether another node with an NCE is still reachable.		determine whether another node with an NCE is still reachable.
	6. Link-layer address change announcement: If a host's link-layer		6. Link-layer address change announcement: If a host's link-layer
	address changes, it may use multicast Node Advertisements (NAs)		address changes, it may use multicast Neighbor Advertisements
	to announce its new link-layer address to other nodes.		(NAs) to announce its new link-layer address to other nodes.
	For a router, the procedure is similar except that there is no router		For a router, the procedure is similar except that there is no router
	discovery. Instead, routers perform a Redirect procedure that hosts		discovery. Instead, routers perform a Redirect procedure that hosts
	do not have. A router sends a Redirect to inform a node of a better		do not have. A router sends a Redirect to inform a node of a better
	next hop for the node's traffic.		next hop for the node's traffic.
	ND uses multicast in many messages, trusts messages from all nodes,		ND uses multicast in many messages and trusts messages from all
	and routers may install NCEs for hosts on demand when they are to		nodes; in addition, routers may install NCEs for hosts on demand when
	forward packets to these hosts. These may lead to issues.		they are to forward packets to these hosts. These may lead to
	Concretely, various ND issues and mitigation solutions have been		issues. Concretely, various ND issues and mitigation solutions have
	published in more than 20 RFCs, including:		been published in more than 20 RFCs, including:
	* ND Trust Models and Threats [RFC3756]		* "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756]
	* Secure ND [RFC3971]		* "SEcure Neighbor Discovery (SEND)" [RFC3971]
	* Cryptographically Generated Addresses [RFC3972]		* "Cryptographically Generated Addresses (CGA)" [RFC3972]
	* ND Proxy [RFC4389]		* "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]
	* Optimistic ND [RFC4429]		* "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
	* ND for mobile broadband [RFC6459] [RFC7066]		* "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet
			System (EPS)" [RFC6459]
	* ND for fixed broadband [TR177]		* "IPv6 for Third Generation Partnership Project (3GPP) Cellular
			Hosts" [RFC7066]
	* ND Mediation [RFC6575]		* "IPv6 in the context of TR-101" [TR177]
	* Operational ND Problems [RFC6583]		* "Address Resolution Protocol (ARP) Mediation for IP Interworking
			of Layer 2 VPNs" [RFC6575]
	* Wireless ND (WiND) [RFC6775] [RFC8505] [RFC8928] [RFC8929] [SND]		* "Operational Neighbor Discovery Problems" [RFC6583]
	* DAD Proxy [RFC6957]		* "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
			Personal Area Networks (6LoWPANs)" [RFC6775]
	* Source Address Validation Improvement [RFC7039]		* "Registration Extensions for IPv6 over Low-Power Wireless Personal
			Area Network (6LoWPAN) Neighbor Discovery" [RFC8505]
	* Router Advertisement Guard [RFC6105] [RFC7113]		* "Address-Protected Neighbor Discovery for Low-Power and Lossy
			Networks" [RFC8928]
	* Enhanced Duplicate Address Detection [RFC7527]		* "IPv6 Backbone Router" [RFC8929]
	* Scalable ARP [RFC7586]		* "Architecture and Framework for IPv6 over Non-Broadcast Access"
			[SND]
	* Reducing Router Advertisements [RFC7772]		* "Duplicate Address Detection Proxy" [RFC6957]
	* Unique Prefix Per Host [RFC8273]		* "Source Address Validation Improvement (SAVI) Framework" [RFC7039]
	* ND Optimization for Transparent Interconnection of Lots of Links		* "IPv6 Router Advertisement Guard" [RFC6105]
	(TRILL) [RFC8302]
	* Gratuitous Neighbor Discovery [RFC9131]		* "Implementation Advice for IPv6 Router Advertisement Guard (RA-
			Guard)" [RFC7113]
	* Proxy ARP/ND for EVPN [RFC9161]		* "Enhanced Duplicate Address Detection" [RFC7527]
	* Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6		* "The Scalable Address Resolution Protocol (SARP) for Large Data
	Prefixes per Client in Large Broadcast Networks [RFC9663]		Centers" [RFC7586]
			* "Reducing Energy Consumption of Router Advertisements" [RFC7772]
			* "Unique IPv6 Prefix per Host" [RFC8273]
			* "Transparent Interconnection of Lots of Links (TRILL): ARP and
			Neighbor Discovery (ND) Optimization" [RFC8302]
			* "Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on
			First-Hop Routers" [RFC9131]
			* "Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private
			Networks" [RFC9161]
			* "Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
			IPv6 Prefixes per Client in Large Broadcast Networks" [RFC9663]
	This document summarizes these RFCs into a one-stop reference (as of		This document summarizes these RFCs into a one-stop reference (as of
	the time of writing) for easier access. This document also		the time of writing) for easier access. This document also
	identifies three causes of the issues and defines three host		identifies three causes of the issues and defines three host
	isolation methods to address the causes and prevent potential ND		isolation methods to address the causes and prevent potential ND
	issues.		issues.
	1.1. Terminology		1.1. Terminology
	This document uses the terms defined in [RFC4861]. Additional terms		This document uses the terms defined in [RFC4861]. Additional terms
	are defined in this section.		are defined in this section.
	MAC: Media Access Control. To avoid confusion with link-local		MAC: Media Access Control. To avoid confusion with link-local
	addresses, link-layer addresses are referred to as "MAC addresses"		addresses, link-layer addresses are referred to as "MAC addresses"
	in this document.		in this document.
	Host isolation: Separating hosts into different subnets or links.		Host Isolation: Separating hosts into different subnets or links.
	L3 Isolation: Allocating a Unique Prefix per Host (UPPH) [RFC8273]		L3 Isolation: Allocating a Unique Prefix per Host (UPPH) [RFC8273]
	[RFC9663] so that every host is in a different subnet. Given that		[RFC9663] so that every host is in a different subnet. Given that
	a unique prefix can be allocated per host on shared media, hosts		a unique prefix can be allocated per host on shared media, hosts
	in different subnets may be on the same link.		in different subnets may be on the same link.
	L2 Isolation: Taking measures to prevent a host from reaching other		L2 Isolation: Taking measures to prevent a host from reaching other
	hosts directly in Layer 2 (L2) so that every host is in a		hosts directly in Layer 2 (L2) so that every host is in a
	different link. Due to the existence of Multi-Link Subnet		different link. Due to the existence of Multi-Link Subnet
	[RFC4903], hosts in different links may be in the same subnet.		[RFC4903], hosts in different links may be in the same subnet.
	skipping to change at line 273 ¶		skipping to change at line 297 ¶
	large L2 networks. This can consume network bandwidth, increase		large L2 networks. This can consume network bandwidth, increase
	processing overhead, and degrade network performance [RFC7342].		processing overhead, and degrade network performance [RFC7342].
	In wireless networks, multicast can be inefficient or even unreliable		In wireless networks, multicast can be inefficient or even unreliable
	due to a higher probability of transmission interference, lower data		due to a higher probability of transmission interference, lower data
	rate, and lack of acknowledgements (Section 3.1 of [RFC9119]).		rate, and lack of acknowledgements (Section 3.1 of [RFC9119]).
	Multicast-related performance issues of the various ND messages are		Multicast-related performance issues of the various ND messages are
	summarized below:		summarized below:
	* Issue 1: LLA DAD Degrading Performance		* Issue 1: LLA DAD degrades performance
	In an L2 network of N addresses (which can be much larger than the		In an L2 network of N addresses (which can be much larger than the
	number of hosts, as each host can have multiple addresses), there		number of hosts, as each host can have multiple addresses), there
	can be N such multicast messages. This may cause performance		can be N such multicast messages. This may cause performance
	issues when N is large.		issues when N is large.
	* Issue 2: Router's Periodic Unsolicited RAs Draining Host's Battery		* Issue 2: Router's periodic unsolicited RAs drain host's battery
	Multicast RAs are generally limited to one packet every		Multicast RAs are generally limited to one packet every
	MIN_DELAY_BETWEEN_RAS (3 seconds), and there are usually only one		MIN_DELAY_BETWEEN_RAS (3 seconds), and there are usually only one
	or two routers on the link, so it is unlikely to cause a		or two routers on the link, so it is unlikely to cause a
	performance issue. However, for battery-powered hosts, such		performance issue. However, for battery-powered hosts, such
	messages may wake them up and drain their batteries [RFC7772].		messages may wake them up and drain their batteries [RFC7772].
	* Issue 3: GUA DAD Degrading Performance		* Issue 3: GUA DAD degrades performance
	This is the same as in Issue 1.		This is the same as in Issue 1.
	* Issue 4: Router's Address Resolution for Hosts Degrading		* Issue 4: Router's address resolution for hosts degrades
	Performance		performance
	This is the same as in Issue 1.		This is the same as in Issue 1.
	* Issue 5: Host's Address Resolution for Hosts Degrading Performance		* Issue 5: Host's address resolution for hosts degrades performance
	This is the same as in Issue 1.		This is the same as in Issue 1.
	* Issue for further study: Host's MAC Address Change NAs Degrading		* Issue for further study: Multicast NAs for host's MAC address
	Performance		changes may degrade performance
	With randomized and changing MAC addresses [MADINAS], there may be		With randomized and changing MAC addresses [MADINAS], there may be
	many such multicast messages.		many such multicast messages.
	In wireless networks, multicast is more likely to cause packet loss.		In wireless networks, multicast is more likely to cause packet loss.
	Because DAD treats no response as no duplicate address detected,		Because DAD treats no response as no duplicate address detected,
	packet loss may cause duplicate addresses to be undetected.		packet loss may cause duplicate addresses to be undetected.
	Multicast reliability issues are summarized below:		Multicast reliability issues are summarized below:
	* Issue 6: LLA DAD Not Completely Reliable in Wireless Networks		* Issue 6: LLA DAD not completely reliable in wireless networks
	* Issue 7: GUA DAD Not Completely Reliable in Wireless Networks		* Issue 7: GUA DAD not completely reliable in wireless networks
	Note: IPv6 address collisions are extremely unlikely. As a result,		Note: IPv6 address collisions are extremely unlikely. As a result,
	these two issues are largely theoretical rather than practical.		these two issues are largely theoretical rather than practical.
	2.2. Trusting-All-Hosts May Cause On-Link Security Issues		2.2. Trusting-All-Nodes May Cause On-Link Security Issues
	In scenarios such as public access networks, some nodes may not be		In scenarios such as public access networks, some nodes may not be
	trustworthy. An attacker on the link can cause the following on-link		trustworthy. An attacker on the link can cause the following on-link
	security issues [RFC3756] [RFC9099]:		security issues [RFC3756] [RFC9099]:
	* Issue 8: Source IP Address Spoofing		* Issue 8: Source IP address spoofing
	An attacker can use another node's IP address as the source		An attacker can use another node's IP address as the source
	address of its ND message to pretend to be that node. The		address of its ND message to pretend to be that node. The
	attacker can then launch various Redirect or Denial-of-Service		attacker can then launch various Redirect or Denial-of-Service
	(DoS) attacks.		(DoS) attacks.
	* Issue 9: Denial of DAD		* Issue 9: Denial of DAD
	An attacker can repeatedly reply to a victim's DAD messages,		An attacker can repeatedly reply to a victim's DAD messages,
	causing the victim's address configuration procedure to fail,		causing the victim's address configuration procedure to fail,
	resulting in a DoS to the victim.		resulting in a DoS to the victim.
	* Issue 10: Rogue RAs		* Issue 10: Rogue RAs
	An attacker can send RAs to victim hosts to pretend to be a		An attacker can send RAs to victim hosts to pretend to be a
	router. The attacker can then launch various Redirect or DoS		router. The attacker can then launch various Redirect or DoS
	attacks.		attacks.
	* Issue 11: Spoofed Redirects		* Issue 11: Spoofed redirects
	An attacker can send forged Redirects to victim hosts to redirect		An attacker can send forged Redirects to victim hosts to redirect
	their traffic to the legitimate router itself.		their traffic to the legitimate router itself.
	* Issue 12: Replay Attacks		* Issue 12: Replay attacks
	An attacker can capture valid ND messages and replay them later.		An attacker can capture valid ND messages and replay them later.
	2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion,		2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion,
	and Address Accountability Issues		and Address Accountability Issues
	When a router needs to forward a packet to a node but does not yet		When a router needs to forward a packet to a node but does not yet
	have a Neighbor-Cache Entry (NCE) for that node, it first creates an		have a Neighbor-Cache Entry (NCE) for that node, it first creates an
	NCE in the INCOMPLETE state. The router then multicasts an NS to the		NCE in the INCOMPLETE state. The router then multicasts an NS to the
	node's solicited-node multicast address. When the destination		node's solicited-node multicast address. When the destination
	replies with an NA containing its MAC address, the router updates the		replies with an NA containing its MAC address, the router updates the
	NCE with that address and changes its state to REACHABLE, thereby		NCE with that address and changes its state to REACHABLE, thereby
	completing the entry. This process is referred to as		completing the entry. This process is referred to as
	"Router-NCE-on-Demand" in this document.		"Router-NCE-on-Demand" in this document.
	Router-NCE-on-Demand can cause the following issues:		Router-NCE-on-Demand can cause the following issues:
	* Issue 13: NCE Exhaustion		* Issue 13: NCE exhaustion
	An attacker can send a high volume of packets targeting non-		An attacker can send a high volume of packets targeting non-
	existent IP addresses, causing the router to create numerous NCEs		existent IP addresses, causing the router to create numerous NCEs
	in the INCOMPLETE state. The resulting resource exhaustion may		in the INCOMPLETE state. The resulting resource exhaustion may
	cause the router to malfunction. This vulnerability, described as		cause the router to malfunction. This vulnerability, described as
	"NCE Exhaustion" in this document, does not require the attacker		"NCE exhaustion" in this document, does not require the attacker
	to be on-link.		to be on-link.
	* Issue 14: Router Forwarding Delay		* Issue 14: Router forwarding delay
	When a packet arrives at a router, the router buffers it while		When a packet arrives at a router, the router buffers it while
	attempting to determine the host's MAC address. This buffering		attempting to determine the host's MAC address. This buffering
	delays forwarding and, depending on the router's buffer size, may		delays forwarding and, depending on the router's buffer size, may
	lead to packet loss. This delay is referred to as		lead to packet loss. This delay is referred to as
	"Router-NCE-on-Demand Forwarding Delay" in this document.		"Router-NCE-on-Demand forwarding delay" in this document.
	* Issue 15: Lack of Address Accountability		* Issue 15: Lack of address accountability
	With SLAAC, hosts generate their IP addresses. The router does		With SLAAC, hosts generate their IP addresses. The router does
	not become aware of a host's IP address until an NCE entry is		not become aware of a host's IP address until an NCE entry is
	created. With DHCPv6 [RFC8415], the router may not know the		created. With DHCPv6 [RFC8415], the router may not know the
	host's addresses unless it performs DHCPv6 snooping. In public		host's addresses unless it performs DHCPv6 snooping. In public
	access networks, where subscriber management often relies on IP		access networks, where subscriber management often relies on IP
	address (or prefix) identification, this lack of address		address (or prefix) identification, this lack of address
	accountability poses a challenge [AddrAcc]. Without knowledge of		accountability poses a challenge [AddrAcc]. Without knowledge of
	the host's IP address, network administrators are unable to		the host's IP address, network administrators are unable to
	effectively manage subscribers, which is particularly problematic		effectively manage subscribers, which is particularly problematic
	skipping to change at line 412 ¶		skipping to change at line 436 ¶
	summarized below. These issues stem from three primary causes:		summarized below. These issues stem from three primary causes:
	multicast, Trusting-all-nodes, and Router-NCE-on-Demand. Eliminating		multicast, Trusting-all-nodes, and Router-NCE-on-Demand. Eliminating
	any of these causes would also mitigate the corresponding issues.		any of these causes would also mitigate the corresponding issues.
	These observations provide guidance for addressing and preventing ND-		These observations provide guidance for addressing and preventing ND-
	related issues.		related issues.
	1. Multicast-related issues:		1. Multicast-related issues:
	* Performance issues:		* Performance issues:
	- Issue 1: LLA DAD Degrading Performance		- Issue 1: LLA DAD degrades performance
	- Issue 2: Unsolicited RA Draining Host Battery Life		- Issue 2: Router's periodic unsolicited RAs drain host's
			battery
	- Issue 3: GUA DAD degrading performance		- Issue 3: GUA DAD degrades performance
	- Issue 4: Router Address Resolution for Hosts Degrading		- Issue 4: Router's address resolution for hosts degrades
	Performance		performance
	- Issue 5: Host Address Resolution for Other Hosts Degrading		- Issue 5: Host's address resolution for hosts degrades
	Performance		performance
	* Reliability issues:		* Reliability issues:
	- Issue 6: LLA DAD Not Completely Reliable in Wireless		- Issue 6: LLA DAD not completely reliable in wireless
	Networks		networks
	- Issue 7: GUA DAD Not Completely Reliable in Wireless		- Issue 7: GUA DAD not completely reliable in wireless
	Networks		networks
	2. Trusting-all-nodes related issues:		2. Trusting-all-nodes related issues:
	* Issue 8: Source IP Address Spoofing		* Issue 8: Source IP address spoofing
	* Issue 9: Denial of DAD		* Issue 9: Denial of DAD
	* Issue 10: Rogue RAs		* Issue 10: Rogue RAs
	* Issue 11: Spoofed Redirects		* Issue 11: Spoofed redirects
	* Issue 12: Replay Attacks		* Issue 12: Replay attacks
	3. Router-NCE-on-Demand related issues:		3. Router-NCE-on-Demand related issues:
	* Issue 13: NCE Exhaustion		* Issue 13: NCE exhaustion
	* Issue 14: Router Forwarding Delay		* Issue 14: Router forwarding delay
	* Issue 15: Lack of Address Accountability		* Issue 15: Lack of address accountability
	These issues are potential vulnerabilities and may not manifest in		These issues are potential vulnerabilities and may not manifest in
	all usage scenarios.		all usage scenarios.
	When these issues may occur in a specific deployment, it is advisable		When these issues may occur in a specific deployment, it is advisable
	to consider the mitigation solutions available. They are described		to consider the mitigation solutions available. They are described
	in the following section.		in the following section.
	3. Review of ND Mitigation Solutions		3. Review of ND Mitigation Solutions
	skipping to change at line 472 ¶		skipping to change at line 497 ¶
	described in Section 2.4. Similar solutions are grouped, beginning		described in Section 2.4. Similar solutions are grouped, beginning
	with those that address the most issues. Unrelated solutions are		with those that address the most issues. Unrelated solutions are
	ordered based on the issues (listed in Section 2.4) they address.		ordered based on the issues (listed in Section 2.4) they address.
	Each solution in the table will be explained in a sub-section later,		Each solution in the table will be explained in a sub-section later,
	where abbreviations in the table are described.		where abbreviations in the table are described.
	In Table 1, a letter code indicates the RFC category of the		In Table 1, a letter code indicates the RFC category of the
	mitigation solution (see BCP 9 [RFC2026] for an explanation of these		mitigation solution (see BCP 9 [RFC2026] for an explanation of these
	categories):		categories):
	S: Standards Track (Proposed Standard, Draft Standard, or Internet		S: Standards Track (Proposed Standard or Internet Standard)
	Standard)
	E: Experimental		E: Experimental
	I: Informational		I: Informational
	B: Best Current Practice		B: Best Current Practice
	N/A: Not Applicable (not an RFC)		N/A: Not Applicable (not an RFC)
			The abbreviations in Table 1 correspond to Section 2.4 as follows:
			On-link sec.: Trusting-all-nodes related issues
			NCE exh.: NCE exhaustion
			Fwd. delay: Router forwarding delay
			No addr. acc.: Lack of address accountability
	+==========+====+===========+=======+=========+====+=======+=======+		+==========+====+===========+=======+=========+====+=======+=======+
	| ND |RFC |Multicast |Reliabi| On-link |NCE | Fwd. | No |		| ND |RFC |Multicast |Reliabi| On-link |NCE | Fwd. | No |
	| solution |cat.|performance|lity | sec. |Exh.| Delay | Addr. |		| solution |cat.|performance|lity | sec. |exh.| delay | addr. |
	| | | | | | | | Acc. |		| | | | | | | | acc. |
	| | +===+=+=+=+=+=====+=+=========+====+=======+=======+		| | +===+=+=+=+=+=====+=+=========+====+=======+=======+
	| | | 1 |2|3|4|5| 6 |7| 8-12 | 13 | 14 | 15 |		| | | 1 |2|3|4|5| 6 |7| 8-12 | 13 | 14 | 15 |
	+==========+====+===+=+=+=+=+=====+=+=========+====+=======+=======+		+==========+====+===+=+=+=+=+=====+=+=========+====+=======+=======+
	| MBBv6 | I | All identified issues solved |		| MBBv6 | I | All identified issues solved |
	+----------+----+--------------------------------------------------+		+----------+----+--------------------------------------------------+
	| FBBv6 |N/A | All identified issues solved |		| FBBv6 |N/A | All identified issues solved |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| UPPH | I | |X| |X|X| |X| | X | X | X |		| UPPH | I | |X| |X|X| |X| | X | X | X |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| WiND | S |All issues solved for Low-Power and Lossy Networks|		| WiND | S |All issues solved for Low-Power and Lossy Networks|
	| | | (LLNs) |		| | | (LLNs) |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| SARP | E | | | | |X| | | | | | |		| SARP | E | | | | |X| | | | | | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| ND TRILL | S | | | | |X| | | | | | |		| ND TRILL | S | | | | |X| | | | | | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| ND EVPN | S | | | | |X| | | | | | |		| ND EVPN | S | | | | |X| | | | | | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| 7772 | B | |X| | | | | | | | | |		| RFC 7772 | B | |X| | | | | | | | | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| GRAND | S | | | |X| | | | | | X | |		| GRAND | S | | | |X| | | | | | X | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| SAVI/RA | I | | | | | | | | X | | | |		| SAVI/ | I | | | | | | | | X | | | |
	| G/G+ | | | | | | | | | | | | |		| RA-G | | | | | | | | | | | | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| 6583 | I | | | | | | | | | X | | |		| RFC 6583 | I | | | | | | | | | X | | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| 9686 | S | | | | | | | | | | | X |		| RFC 9686 | S | | | | | | | | | | | X |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	Table 1: Solutions for Identified Issues		Table 1: Solutions for Identified Issues
	3.1. ND Solution in Mobile Broadband IPv6		3.1. Mobile Broadband IPv6 (MBBv6)
	The IPv6 solution defined in "IPv6 in 3rd Generation Partnership		The IPv6 solution defined in "IPv6 in 3rd Generation Partnership
	Project (3GPP) Evolved Packet System (EPS)" [RFC6459], "IPv6 for		Project (3GPP) Evolved Packet System (EPS)" [RFC6459], "IPv6 for
	Third Generation Partnership Project (3GPP) Cellular Hosts"		Third Generation Partnership Project (3GPP) Cellular Hosts"
	[RFC7066], and "Extending an IPv6 /64 Prefix from a Third Generation		[RFC7066], and "Extending an IPv6 /64 Prefix from a Third Generation
	Partnership Project (3GPP) Mobile Interface to a LAN Link" [RFC7278]		Partnership Project (3GPP) Mobile Interface to a LAN Link" [RFC7278]
	is called Mobile Broadband IPv6 (MBBv6) in this document. They are		is called Mobile Broadband IPv6 (MBBv6) in this document. They are
	Informational RFCs. The key points are:		Informational RFCs. The key points are:
	* Putting every host (e.g., the mobile User Equipment (UE)) in a		* Putting every host (e.g., the mobile User Equipment (UE)) in a
	skipping to change at line 547 ¶		skipping to change at line 578 ¶
	* Assigning a unique /64 prefix to each host. Together with the P2P		* Assigning a unique /64 prefix to each host. Together with the P2P
	link, this puts each host on a separate link and subnet.		link, this puts each host on a separate link and subnet.
	* Maintaining (prefix, interface) binding at the router for		* Maintaining (prefix, interface) binding at the router for
	forwarding purposes.		forwarding purposes.
	Since all the three causes of ND issues are addressed, all the issues		Since all the three causes of ND issues are addressed, all the issues
	discussed in Section 2.4 are addressed.		discussed in Section 2.4 are addressed.
	3.2. ND Solution in Fixed Broadband IPv6		3.2. Fixed Broadband IPv6 (FBBv6)
	The IPv6 solution defined in "IPv6 in the context of TR-101" [TR177]		The IPv6 solution defined in "IPv6 in the context of TR-101" [TR177]
	is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has		is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has
	two flavors:		two flavors:
	* P2P: Every host (e.g., the Residential Gateway (RG)) is in a P2P		* P2P: Every host (e.g., the Residential Gateway (RG)) is in a P2P
	link with the router (e.g., the Broadband Network Gateway (BNG)).		link with the router (e.g., the Broadband Network Gateway (BNG)).
	In this case, the solution is functionally similar to MBBv6. All		In this case, the solution is functionally similar to MBBv6. All
	ND issues discussed in Section 2.4 are solved.		ND issues discussed in Section 2.4 are solved.
	skipping to change at line 610 ¶		skipping to change at line 641 ¶
	- Without address resolution, router multicast to hosts is		- Without address resolution, router multicast to hosts is
	limited to unsolicited RAs. As each host resides in its own		limited to unsolicited RAs. As each host resides in its own
	subnet, these RAs are sent as unicast packets to individual		subnet, these RAs are sent as unicast packets to individual
	hosts. This follows the approach specified in [RFC6085], where		hosts. This follows the approach specified in [RFC6085], where
	the host's MAC address replaces the multicast MAC address in		the host's MAC address replaces the multicast MAC address in
	the RA.		the RA.
	Since all three causes of ND issues are addressed, all ND issues		Since all three causes of ND issues are addressed, all ND issues
	(Section 2.4) are also addressed.		(Section 2.4) are also addressed.
	3.3. Unique IPv6 Prefix per Host (UPPH)		3.3. Unique Prefix per Host (UPPH)
	Unique IPv6 Prefix per Host (UPPH) solutions are described in		Unique Prefix per Host (UPPH) solutions are described in [RFC8273]
	[RFC8273] and [RFC9663]. Both are Informational RFCs. [RFC8273]		and [RFC9663]. Both are Informational RFCs. [RFC8273] relies on
	relies on SLAAC for unique prefix allocation while [RFC9663] relies		SLAAC for unique prefix allocation while [RFC9663] relies on DHCPv6
	on DHCPv6 Prefix Delegation (DHCPv6-PD). That difference in		Prefix Delegation (DHCPv6-PD). That difference in allocation
	allocation mechanism does not change the discussion on ND issues,		mechanism does not change the discussion on ND issues, because every
	because every IPv6 node is still required to run SLAAC, even when it		IPv6 node is still required to run SLAAC, even when it receives its
	receives its prefix via DHCPv6-PD. Therefore, discussing [RFC8273]		prefix via DHCPv6-PD. Therefore, discussing [RFC8273] alone is
	alone is sufficient.		sufficient.
	[RFC8273] "improves host isolation and enhanced subscriber management		[RFC8273] "improves host isolation and enhanced subscriber management
	on shared network segments" such as Wi-Fi or Ethernet. The key		on shared network segments" such as Wi-Fi or Ethernet. The key
	points are:		points are:
	* When a prefix is allocated to the host, the router can proactively		* When a prefix is allocated to the host, the router can proactively
	install a forwarding entry for that prefix towards the host.		install a forwarding entry for that prefix towards the host.
	There is no more Router-NCE-on-Demand.		There is no more Router-NCE-on-Demand.
	* Without address resolution, router multicast to hosts consists		* Without address resolution, router multicast to hosts consists
	skipping to change at line 655 ¶		skipping to change at line 686 ¶
	additional measures like Private VLAN [RFC5517]. Without such		additional measures like Private VLAN [RFC5517]. Without such
	additional measures, on a shared medium, hosts can still reach each		additional measures, on a shared medium, hosts can still reach each
	other in L2 as they belong to the same Solicited-Node Multicast		other in L2 as they belong to the same Solicited-Node Multicast
	Group. Therefore, Trusting-all-nodes and host multicast to routers		Group. Therefore, Trusting-all-nodes and host multicast to routers
	may cause issues. Of the host multicast issues (i.e., Issues 1, 3,		may cause issues. Of the host multicast issues (i.e., Issues 1, 3,
	5, 6, and 7), UPPH prevents Issues 5 and 7, because there is no need		5, 6, and 7), UPPH prevents Issues 5 and 7, because there is no need
	for address resolution among hosts (Issue 5), and there is no		for address resolution among hosts (Issue 5), and there is no
	possibility of GUA duplication (Issue 7). However, Issues 1, 3, and		possibility of GUA duplication (Issue 7). However, Issues 1, 3, and
	6 may occur.		6 may occur.
	3.4. Wireless ND and Subnet ND		3.4. Wireless ND (WiND)
	Wireless ND (WiND) [RFC6775] [RFC8505] [RFC8928] [RFC8929] (Standards		The term "Wireless ND (WiND)" is used in this document to describe
	Track) defines a fundamentally different ND solution for Low-Power		the fundamentally different ND solution for Low-Power and Lossy
	and Lossy Networks (LLNs) [RFC7102]. WiND changes host and router		Networks (LLNs) [RFC7102] that is defined in [RFC6775], [RFC8505],
	behaviors to use multicast only for router discovery. The key points		[RFC8928], and [RFC8929] (Standards Track). WiND changes host and
	are:		router behaviors to use multicast only for router discovery. The key
			points are:
	* Hosts use unicast to proactively register their addresses at the		* Hosts use unicast to proactively register their addresses at the
	routers. Routers use unicast to communicate with hosts and become		routers. Routers use unicast to communicate with hosts and become
	an abstract registrar and arbitrator for address ownership.		an abstract registrar and arbitrator for address ownership.
	* The router also proactively installs NCEs for the hosts. This		* The router also proactively installs NCEs for the hosts. This
	avoids the need for address resolution for the hosts.		avoids the need for address resolution for the hosts.
	* The router sets the Prefix Information Option (PIO) L-bit to 0.		* The router sets the Prefix Information Option (PIO) L-bit to 0.
	Each host communicates only with the router (Section 6.3.4 of		Each host communicates only with the router (Section 6.3.4 of
	[RFC4861]).		[RFC4861]).
	* Other functionalities that are relevant only to LLNs.		* Other functionalities that are relevant only to LLNs.
	WiND addresses all ND issues (Section 2.4) in LLNs. However, WiND		WiND addresses all ND issues (Section 2.4) in LLNs. However, WiND
	support is not mandatory for general-purpose hosts. Therefore, it		support is not mandatory for general-purpose hosts. Therefore, it
	cannot be relied upon as a deployment option without imposing		cannot be relied upon as a deployment option without imposing
	additional constraints on the participating nodes.		additional constraints on the participating nodes.
	3.5. Scalable Address Resolution Protocol		3.5. Scalable Address Resolution Protocol (SARP)
	The Scalable Address Resolution Protocol (SARP) [RFC7586] was an		The Scalable Address Resolution Protocol (SARP) [RFC7586] was an
	Experimental solution. That experiment ended in 2017, two years		Experimental solution. That experiment ended in 2017, two years
	after the RFC was published. Because the idea has been used in		after the RFC was published. Because the idea has been used in
	mitigation solutions for more specific scenarios (described in		mitigation solutions for more specific scenarios (described in
	Sections 3.6 and 3.7), it is worth describing here. The usage		Sections 3.6 and 3.7), it is worth describing here. The usage
	scenario is Data Centers (DCs), where large L2 domains span across		scenario is Data Centers (DCs), where large L2 domains span across
	multiple sites. In each site, multiple hosts are connected to a		multiple sites. In each site, multiple hosts are connected to a
	switch. The hosts can be Virtual Machines (VMs), so the number can		switch. The hosts can be Virtual Machines (VMs), so the number can
	be large. The switches are interconnected by a native or overlay L2		be large. The switches are interconnected by a pure or overlay L2
	network.		network.
	The switch will snoop and install a (IP, MAC address) proxy table for		The switch will snoop and install a (IP, MAC address) proxy table for
	the local hosts. The switch will also reply to address resolution		the local hosts. The switch will also reply to address resolution
	requests from other sites to its hosts with its own MAC address. In		requests from other sites to its hosts with its own MAC address. In
	doing so, all hosts within a site will appear to have a single MAC		doing so, all hosts within a site will appear to have a single MAC
	address to other sites. As such, a switch only needs to build a MAC		address to other sites. As such, a switch only needs to build a MAC
	address table for the local hosts and the remote switches, not for		address table for the local hosts and the remote switches, not for
	all the hosts in the L2 domain. Consequently, the MAC address table		all the hosts in the L2 domain. Consequently, the MAC address table
	size of the switches is significantly reduced. A switch will also		size of the switches is significantly reduced. A switch will also
	add the (IP, MAC address) replies from remote switches to its proxy		add the (IP, MAC address) replies from remote switches to its proxy
	ND table so that it can reply to future address resolution requests		ND table so that it can reply to future address resolution requests
	from local hosts for such IPs directly. This greatly reduces the		from local hosts for such IPs directly. This greatly reduces the
	number of address resolution multicast in the network.		number of address resolution multicast in the network.
	Unlike MBBv6, FBBv6, and UPPH, which try to address all ND issues		Unlike MBBv6, FBBv6, and UPPH, which try to address all ND issues
	discussed in Section 2.4, SARP focuses on reducing address resolution		discussed in Section 2.4, SARP focuses on reducing address resolution
	multicast to improve the performance and scalability of large L2		multicast to improve the performance and scalability of large L2
	domains in DCs.		domains in DCs.
	3.6. ARP and ND Optimization for TRILL		3.6. ND Optimization for TRILL
	ARP and ND optimization for Transparent Interconnection of Lots of		ARP and ND optimization for Transparent Interconnection of Lots of
	Links (TRILL) [RFC8302] (Standards Track) is similar to SARP		Links (TRILL) [RFC8302] (Standards Track) is similar to SARP
	(Section 3.5). It can be considered an application of SARP in the		(Section 3.5). It can be considered an application of SARP in the
	TRILL environment.		TRILL environment.
	Like SARP, ARP, and ND optimization for TRILL focuses on reducing		Like SARP, ND optimization for TRILL focuses on reducing multicast
	multicast address resolution. That is, it addresses Issue 5		address resolution. That is, it addresses Issue 5 (Section 2.1).
	(Section 2.1).
	3.7. Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN)		3.7. Proxy ND in Ethernet Virtual Private Networks (ND EVPN)
	Proxy ARP/ND in EVPN is specified in [RFC9161] (Standards Track).		Proxy ARP/ND in EVPN is specified in [RFC9161] (Standards Track).
	The usage scenario is DCs where large L2 domains span across multiple		The usage scenario is DCs where large L2 domains span across multiple
	sites. In each site, multiple hosts are connected to a Provider Edge		sites. In each site, multiple hosts are connected to a Provider Edge
	(PE) router. The PEs are interconnected by EVPN tunnels.		(PE) router. The PEs are interconnected by EVPN tunnels.
	The PE of each site snoops the local address resolution NAs to build		The PE of each site snoops the local address resolution NAs to build
	(IP, MAC address) Proxy ND table entries. PEs then propagate such		(IP, MAC address) Proxy ND table entries. PEs then propagate such
	Proxy ND entries to other PEs via the Border Gateway Protocol (BGP).		Proxy ND entries to other PEs via the Border Gateway Protocol (BGP).
	Each PE also snoops local hosts' address resolution NSs for remote		Each PE also snoops local hosts' address resolution NSs for remote
	hosts. If an entry exists in its Proxy ND table for the remote		hosts. If an entry exists in its Proxy ND table for the remote
	hosts, the PE will reply directly. Consequently, the number of		hosts, the PE will reply directly. Consequently, the number of
	multicast address resolution messages is significantly reduced.		multicast address resolution messages is significantly reduced.
	Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address		Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address
	resolution multicast.		resolution multicast.
	3.8. Reducing Router Advertisements		3.8. Reducing Router Advertisements per RFC 7772
	Maintaining IPv6 connectivity requires that hosts be able to receive		Maintaining IPv6 connectivity requires that hosts be able to receive
	periodic multicast RAs [RFC4861]. Hosts that process unicast packets		periodic multicast RAs [RFC4861]. Hosts that process unicast packets
	while they are asleep must also process multicast RAs while they are		while they are asleep must also process multicast RAs while they are
	asleep. An excessive number of RAs can significantly reduce the		asleep. An excessive number of RAs can significantly reduce the
	battery life of mobile hosts. [RFC7772] (Best Current Practice)		battery life of mobile hosts. [RFC7772] (Best Current Practice)
	specifies a solution to reduce RAs:		specifies a solution to reduce RAs:
	* The router should respond to RS with unicast RA (rather than the		* The router should respond to RS with unicast RA (rather than the
	normal multicast RA) if the host's source IP address is specified		normal multicast RA) if the host's source IP address is specified
	skipping to change at line 773 ¶		skipping to change at line 804 ¶
	* A node sends unsolicited NAs upon assigning a new IPv6 address to		* A node sends unsolicited NAs upon assigning a new IPv6 address to
	its interface.		its interface.
	* A router creates a new NCE for the node and sets its state to		* A router creates a new NCE for the node and sets its state to
	STALE.		STALE.
	When a packet for the host later arrives, the router can use the		When a packet for the host later arrives, the router can use the
	existing STALE NCE to forward it immediately ([RFC4861],		existing STALE NCE to forward it immediately ([RFC4861],
	Section 7.2.2). It then verifies reachability by sending a unicast		Section 7.2.2). It then verifies reachability by sending a unicast
	NS rather than a multicast one for address resolution. In this way,		NS rather than a multicast one for address resolution. In this way,
	GRAND eliminates the Router Forwarding Delay, but it does not solve		GRAND eliminates the router forwarding delay, but it does not solve
	other Router-NCE-on-Demand issues. For example, NCE Exhaustion can		other Router-NCE-on-Demand issues. For example, NCE exhaustion can
	still happen.		still happen.
	3.10. Source Address Validation Improvement (SAVI) and Router		3.10. Source Address Validation Improvement (SAVI) and Router
	Advertisement Guard		Advertisement Guard (RA-Guard)
	Source Address Validation Improvement (SAVI) [RFC7039]		Source Address Validation Improvement (SAVI) [RFC7039]
	(Informational) binds an address to a port on an L2 switch and		(Informational) binds an address to a port on an L2 switch and
	rejects claims from other ports for that address. Therefore, a node		rejects claims from other ports for that address. Therefore, a node
	cannot spoof the IP address of another node.		cannot spoof the IP address of another node.
	Router Advertisement Guard (RA-Guard) [RFC6105] [RFC7113]		Router Advertisement Guard (RA-Guard) [RFC6105] [RFC7113]
	(Informational) only allows RAs from a port that a router is		(Informational) only allows RAs from a port that a router is
	connected to. Therefore, nodes on other ports cannot pretend to be a		connected to. Therefore, nodes on other ports cannot pretend to be a
	router.		router.
	SAVI and RA-Guard address the on-link security issues.		SAVI and RA-Guard address the on-link security issues.
	3.11. RFC 6583 Dealing with NCE Exhaustion Attacks		3.11. Dealing with NCE Exhaustion Attacks per RFC 6583
	[RFC6583] (Informational) deals with the NCE Exhaustion attack issue		[RFC6583] (Informational) deals with the NCE exhaustion attack issue
	(Section 2.3). It recommends that:		(Section 2.3). It recommends that:
	* Operators should:		* Operators should:
	- Filter unused address space so that messages to such addresses		- Filter unused address space so that messages to such addresses
	can be dropped rather than triggering NCE creation.		can be dropped rather than triggering NCE creation.
	- Implement rate-limiting mechanisms for ND message processing to		- Implement rate-limiting mechanisms for ND message processing to
	prevent CPU and memory resources from being overwhelmed.		prevent CPU and memory resources from being overwhelmed.
	* Vendors should:		* Vendors should:
	- Prioritize NDP processing for existing NCEs over creating new		- Prioritize NDP processing for existing NCEs over creating new
	NCEs.		NCEs.
	[RFC6583] acknowledges that "some of these options are 'kludges', and		[RFC6583] acknowledges that "some of these options are 'kludges', and
	can be operationally difficult to manage". [RFC6583] partially		can be operationally difficult to manage". [RFC6583] partially
	addresses the Router NCE Exhaustion issue. In practice, router		addresses the Router NCE exhaustion issue. In practice, router
	vendors cap the number of NCEs per interface to prevent cache		vendors cap the number of NCEs per interface to prevent cache
	exhaustion. If the link has more addresses than that cap, the router		exhaustion. If the link has more addresses than that cap, the router
	cannot keep an entry for every address, and packets destined for		cannot keep an entry for every address, and packets destined for
	addresses without an NCE are simply dropped [RFC9663].		addresses without an NCE are simply dropped [RFC9663].
	3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6		3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6 per RFC
			9686
	In IPv4, network administrators can retrieve a host's IP address from		In IPv4, network administrators can retrieve a host's IP address from
	the DHCP server and use it for subscriber management. In IPv6 and		the DHCP server and use it for subscriber management. In IPv6 and
	SLAAC, this is not possible (Section 2.3).		SLAAC, this is not possible (Section 2.3).
	[RFC9686] (Standards Track) defines a method for informing a DHCPv6		[RFC9686] (Standards Track) defines a method for informing a DHCPv6
	server that a host has one or more self-generated or statically		server that a host has one or more self-generated or statically
	configured addresses. This enables network administrators to		configured addresses. This enables network administrators to
	retrieve the IPv6 addresses for each host from the DHCPv6 server.		retrieve the IPv6 addresses for each host from the DHCPv6 server.
	[RFC9686] provides a solution for Issue 15 (Section 2.3).		[RFC9686] provides a solution for Issue 15 (Section 2.3).
	skipping to change at line 868 ¶		skipping to change at line 900 ¶
	3.15. ND Solutions Defined Before the Latest Versions of ND		3.15. ND Solutions Defined Before the Latest Versions of ND
	The latest versions of ND and SLAAC are specified in [RFC4861] and		The latest versions of ND and SLAAC are specified in [RFC4861] and
	[RFC4862]. Several ND mitigation solutions were published before		[RFC4862]. Several ND mitigation solutions were published before
	[RFC4861]. They are reviewed in this section only for completeness.		[RFC4861]. They are reviewed in this section only for completeness.
	3.15.1. Secure Neighbor Discovery (SEND)		3.15.1. Secure Neighbor Discovery (SEND)
	The purpose of SEND [RFC3971] (Standards Track) is to ensure that		The purpose of SEND [RFC3971] (Standards Track) is to ensure that
	hosts and routers are trustworthy. SEND defined three new ND		hosts and routers are trustworthy. SEND defined three new ND
	options, i.e., Cryptographically Generated Addresses (CGA) [RFC3972]		options: Cryptographically Generated Addresses (CGA) [RFC3972]
	(Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce,		(Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce.
	an authorization delegation discovery process, an address ownership		In addition, SEND also defined an authorization delegation discovery
	proof mechanism, and requirements for the use of these components in		process, an address ownership proof mechanism, and requirements for
	the ND protocol.		the use of these components in the ND protocol.
	3.15.2. Cryptographically Generated Addresses (CGA)		3.15.2. Cryptographically Generated Addresses (CGA)
	The purpose of CGA is to associate a cryptographic public key with an		The purpose of CGA is to associate a cryptographic public key with an
	IPv6 address in the SEND protocol. The key point is to generate the		IPv6 address in the SEND protocol. The key point is to generate the
	Interface Identifier (IID) of an IPv6 address by computing a		Interface Identifier (IID) of an IPv6 address by computing a
	cryptographic hash of the public key. The resulting IPv6 address is		cryptographic hash of the public key. The resulting IPv6 address is
	called a CGA. The corresponding private key can then be used to sign		called a CGA. The corresponding private key can then be used to sign
	messages sent from the address.		messages sent from the address.
	skipping to change at line 1013 ¶		skipping to change at line 1045 ¶
	Constraints:		Constraints:
	1. L2 Isolation:		1. L2 Isolation:
	Actions must be taken to isolate hosts in L2. The required		Actions must be taken to isolate hosts in L2. The required
	effort varies by the chosen method and deployment context. For		effort varies by the chosen method and deployment context. For
	example, the P2P method [RFC7066] is heavyweight, while the		example, the P2P method [RFC7066] is heavyweight, while the
	Private VLAN method [RFC5517] is more manageable.		Private VLAN method [RFC5517] is more manageable.
	2. Unique Prefix Allocation:		2. Unique prefix allocation:
	A large number of prefixes will be required, with one prefix		A large number of prefixes will be required, with one prefix
	assigned per host. This is generally not a limitation for IPv6.		assigned per host. This is generally not a limitation for IPv6.
	For instance, members of a Regional Internet Registry (RIR) can		For instance, members of a Regional Internet Registry (RIR) can
	obtain a /29 prefix allocation [RIPE738], which provides 32		obtain a /29 prefix allocation [RIPE738], which provides 32
	billion /64 prefixes -- sufficient for any foreseeable deployment		billion /64 prefixes -- sufficient for any foreseeable deployment
	scenarios. Practical implementations, such as MBBv6 assigning		scenarios. Practical implementations, such as MBBv6 assigning
	/64 prefixes to billions of mobile UEs [RFC6459], and FBBv6		/64 prefixes to billions of mobile UEs [RFC6459], and FBBv6
	assigning /56 prefixes to hundreds of millions of routed RGs		assigning /56 prefixes to hundreds of millions of routed RGs
	[TR177], demonstrate the feasibility of this approach.		[TR177], demonstrate the feasibility of this approach.
	3. Privacy Issue from Unique Prefix Identifiability:		3. Privacy issue from unique prefix identifiability:
	Assigning a unique prefix to each host may theoretically reduce		Assigning a unique prefix to each host may theoretically reduce
	privacy, as hosts can be directly identified by their assigned		privacy, as hosts can be directly identified by their assigned
	prefix. However, alternative host identification methods, such		prefix. However, alternative host identification methods, such
	as cookies, are commonly used. Therefore, unique prefix		as cookies, are commonly used. Therefore, unique prefix
	identifiability may not make much difference. The actual impact		identifiability may not make much difference. The actual impact
	on privacy is therefore likely to be limited.		on privacy is therefore likely to be limited.
	4. Router Support for L3 Isolation:		4. Router support for L3 Isolation:
	The router must support an L3 Isolation solution, e.g., [RFC8273]		The router must support an L3 Isolation solution, e.g., [RFC8273]
	or [RFC9663].		or [RFC9663].
	5. A Large Number of Router Interfaces May be Needed:		5. A large number of router interfaces may be needed:
	If the P2P method is used, the router must instantiate a separate		If the P2P method is used, the router must instantiate a separate
	logical interface for every attached host. In this case, a large		logical interface for every attached host. In this case, a large
	number of interfaces will be needed at the router.		number of interfaces will be needed at the router.
	6. Router as a Bottleneck:		6. Router as a bottleneck:
	Since all communication between hosts is routed through the		Since all communication between hosts is routed through the
	router, the router may become a performance bottleneck in high-		router, the router may become a performance bottleneck in high-
	traffic scenarios.		traffic scenarios.
	7. Incompatibility with Host-Based Multicast Services:		7. Incompatibility with host-based multicast services:
	Services that rely on multicast communication among hosts, such		Services that rely on multicast communication among hosts, such
	as the Multicast Domain Name System [RFC6762], will be disrupted.		as the Multicast Domain Name System [RFC6762], will be disrupted.
	4.2.2. Applicability of L3 Isolation		4.2.2. Applicability of L3 Isolation
	Benefits:		Benefits:
	* All ND issues (Section 2.4) are mitigated, with the exception of:		* All ND issues (Section 2.4) are mitigated, with the exception of:
	- LLA DAD multicast degrading performance,		- LLA DAD multicast degrades performance,
	- LLA DAD not reliable in wireless networks, and		- LLA DAD not reliable in wireless networks, and
	- on-link security.		- on-link security.
	These remaining issues depend on the characteristics of the shared		These remaining issues depend on the characteristics of the shared
	medium:		medium:
	- If the shared medium is Ethernet, the issues related to LLA DAD		- If the shared medium is Ethernet, the issues related to LLA DAD
	multicast are negligible.		multicast are negligible.
	- If nodes can be trusted, such as in private networks, on-link		- If nodes can be trusted, such as in private networks, on-link
	security concerns are not significant.		security concerns are not significant.
	* There is no need for L2 Isolation. Consequently, this method can		* There is no need for L2 Isolation. Consequently, this method can
	be applied in a wide range of scenarios, making it possibly the		be applied in a wide range of scenarios, making it possibly the
	most practical host isolation method.		most practical host isolation method.
	Constraints (as discussed in Section 4.2.1):		Constraints (as discussed in Section 4.2.1):
	1. Unique Prefix Allocation		1. Unique prefix allocation
	2. Router Support for L3 Isolation		2. Router support for L3 Isolation
	3. Router as a Bottleneck		3. Router as a bottleneck
	4. Privacy Issue from Unique Prefix Identifiability.		4. Privacy issue from unique prefix identifiability
	4.2.3. Applicability of Partial L2 Isolation		4.2.3. Applicability of Partial L2 Isolation
	Benefit:		Benefit:
	* Reduced Multicast Traffic: This method reduces multicast traffic,		* Reduced multicast traffic: This method reduces multicast traffic,
	particularly for address resolution, by dividing the subnet into		particularly for address resolution, by dividing the subnet into
	multiple multicast domains.		multiple multicast domains.
	Constraint:		Constraint:
	* Router Support for Partial L2 Isolation: The router must implement		* Router support for Partial L2 Isolation: The router must implement
	a Partial L2 Isolation solution such as WiND, SARP, ND		a Partial L2 Isolation solution such as WiND, SARP, ND
	optimization for TRILL, and Proxy ND in EVPN to support this		optimization for TRILL, and Proxy ND in EVPN to support this
	method.		method.
	4.3. Guidelines for Applying Isolation Methods		4.3. Guidelines for Applying Isolation Methods
	Based on the applicability analysis provided in the preceding		Based on the applicability analysis provided in the preceding
	sections, network administrators can determine whether to implement		sections, network administrators can determine whether to implement
	an isolation method and, if so, which method is most appropriate for		an isolation method and, if so, which method is most appropriate for
	their specific deployment.		their specific deployment.
End of changes. 96 change blocks.
	138 lines changed or deleted		170 lines changed or added
This html diff was produced by rfcdiff 1.48.