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. ND in Ethernet Virtual Private Networks (ND EVPN)
	3.8. Reducing Router Advertisements		3.8. Reducing Router Advertisements
	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. RFC 6583 Dealing with NCE Exhaustion Attacks
	3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6		3.12. Registering Self-Generated IPv6 Addresses Using DHCPv6
	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
	skipping to change at line 165 ¶		skipping to change at line 165 ¶
	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 Node Advertisements (NAs)
	to announce its new link-layer address to other nodes.		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
	skipping to change at line 273 ¶		skipping to change at line 296 ¶
	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 435 ¶
	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 505 ¶		skipping to change at line 529 ¶
	| 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| | | | | | | | | |		| 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 | | |		| 6583 | I | | | | | | | | | X | | |
	+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+		+----------+----+---+-+-+-+-+-----+-+---------+----+-------+-------+
	| 9686 | S | | | | | | | | | | | X |		| 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 571 ¶
	* 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 634 ¶
	- 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 679 ¶
	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		Wireless ND (WiND) [RFC6775] [RFC8505] [RFC8928] [RFC8929] (Standards
	Track) defines a fundamentally different ND solution for Low-Power		Track) defines a fundamentally different ND solution for Low-Power
	and Lossy Networks (LLNs) [RFC7102]. WiND changes host and router		and Lossy Networks (LLNs) [RFC7102]. WiND changes host and router
	behaviors to use multicast only for router discovery. The key points		behaviors to use multicast only for router discovery. The key points
	are:		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.
	skipping to change at line 681 ¶		skipping to change at line 705 ¶
	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 native or overlay L2
	skipping to change at line 712 ¶		skipping to change at line 736 ¶
	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, ARP, and ND optimization for TRILL focuses on reducing
	multicast address resolution. That is, it addresses Issue 5		multicast 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. 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
	skipping to change at line 778 ¶		skipping to change at line 802 ¶
	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.
End of changes. 63 change blocks.
	89 lines changed or deleted		113 lines changed or added
This html diff was produced by rfcdiff 1.48.