rfc9926v3.txt		rfc9926.txt
	skipping to change at line 360 ¶		skipping to change at line 360 ¶
	running a different routing protocol in an external network, e.g., a		running a different routing protocol in an external network, e.g., a
	stub network, and acting as a border router. Using the prefix		stub network, and acting as a border router. Using the prefix
	registration method enables decoupling the routing protocol in the		registration method enables decoupling the routing protocol in the
	6LN from the routing protocol that the 6LRs run in the main LLN and		6LN from the routing protocol that the 6LRs run in the main LLN and
	provide signaling to stimulate the redistribution.		provide signaling to stimulate the redistribution.
	4. Updating RFC 4861		4. Updating RFC 4861
	[RFC4861] expects that the NS/NA exchange is for a unicast address,		[RFC4861] expects that the NS/NA exchange is for a unicast address,
	which is indicated in the Target Address field of the ND message.		which is indicated in the Target Address field of the ND message.
	Section 5.5 of [RFC8505] updates [RFC4861] to signal the Registered		Section 5.5 of [RFC8505] extends [RFC4861] to signal the Registered
	Address in the Target Address field.		Address in the Target Address field.
	This specification updates [RFC4861] by allowing a 6LN to advertise a		This specification updates [RFC4861] by allowing a 6LN to advertise a
	prefix in the Target Address field when the NS or NA message is used		prefix in the Target Address field when the NS or NA message is used
	for a registration, per Section 5.5 of [RFC8505]. In that case, the		for a registration, per Section 5.5 of [RFC8505]. In that case, the
	prefix length MUST be indicated in the EARO of the NS message,		prefix length MUST be indicated in the EARO of the NS message,
	overloading the field that is used in the NA response for the Status.		overloading the field that is used in the NA response for the Status.
	If the 6LN owns at least one IPv6 address that is derived from the		If the 6LN owns at least one IPv6 address that is derived from the
	registered prefix with a non-zero interface ID, then it MUST indicate		registered prefix with a non-zero interface ID, then it MUST indicate
	one of these addresses in full in the Target Address field of the		one of these addresses in full in the Target Address field of the
	NS(EARO) message. Else, it MUST indicate the prefix padded with		NS(EARO) message. Else, it MUST indicate the prefix padded with
	zeros in the Target Address field.		zeros in the Target Address field.
	5. Updating RFC 7400		5. Updating RFC 7400
	This specification updates "6LoWPAN-GHC: Generic Header Compression		This specification updates "6LoWPAN-GHC: Generic Header Compression
	for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"		for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"
	[RFC7400] by defining a new capability bit for use in the 6CIO.		[RFC7400] by defining a new capability bit for use in the 6CIO.
	[RFC7400] was already updated by [RFC8505] for use in IPv6 ND		[RFC7400] was already extended by [RFC8505] for use in IPv6 ND
	messages.		messages.
	The new "Registration for prefixes supported" (F) flag indicates to		The new "Registration for prefixes supported" (F) flag indicates to
	the 6LN that the 6LR (1) accepts IPv6 prefix registrations as		the 6LN that the 6LR (1) accepts IPv6 prefix registrations as
	specified in this document, (2) will ensure that packets for the		specified in this document, (2) will ensure that packets for the
	addresses that match this prefix will be routed to the 6LNs that		addresses that match this prefix will be routed to the 6LNs that
	registered the prefix, and (3) will ensure that the route to the		registered the prefix, and (3) will ensure that the route to the
	prefix will be redistributed if the R flag is set to 1.		prefix will be redistributed if the R flag is set to 1.
	Figure 1 illustrates the F flag in its position (16, counting 0 to 47		Figure 1 illustrates the F flag in its position (16, counting 0 to 47
	skipping to change at line 448 ¶		skipping to change at line 448 ¶
	support this specification).		support this specification).
	[RFC6550] uses the Path Lifetime in the TIO to indicate the remaining		[RFC6550] uses the Path Lifetime in the TIO to indicate the remaining
	time for which the advertisement is valid for unicast route		time for which the advertisement is valid for unicast route
	determination, and a Path Lifetime value of 0 invalidates that route.		determination, and a Path Lifetime value of 0 invalidates that route.
	[RFC9010] maps the Address Registration lifetime in the EARO and the		[RFC9010] maps the Address Registration lifetime in the EARO and the
	Path Lifetime in the TIO so they are comparable when both forms of		Path Lifetime in the TIO so they are comparable when both forms of
	advertisements are received.		advertisements are received.
	The RPL router that merges multiple advertisements for the same		The RPL router that merges multiple advertisements for the same
	prefix uses and advertises the longest remaining lifetime across all		prefix MUST use and advertise the longest remaining lifetime across
	the origins of the advertisements for that prefix. When the lifetime		all the origins of the advertisements for that prefix. When the
	expires, the router sends a no-path DAO message (i.e., the lifetime		lifetime expires, the router sends a no-path DAO message (i.e., the
	is 0) using the same value for the ROVR value as for the previous		lifetime is 0) using the same value for the ROVR value as for the
	advertisements. This value refers to either the single descendant		previous advertisements. This value refers to either the single
	that advertised the Target if there is only one or the router itself		descendant that advertised the Target if there is only one or the
	if there is more than one.		router itself if there is more than one.
	Note that the Registration Lifetime, TID, and ROVR fields are also		Note that the Registration Lifetime, TID, and ROVR fields are also
	placed in the EDAR message, so the state created by EDAR is also		placed in the EDAR message, so the state created by EDAR is also
	comparable with that created upon an NS(EARO) or a DAO message. For		comparable with that created upon an NS(EARO) or a DAO message. For
	simplicity, the text below mentions only NS(EARO) but it also applies		simplicity, the text below mentions only NS(EARO) but it also applies
	to EDAR.		to EDAR.
	7. Updating RFC 8505		7. Updating RFC 8505
	This specification updates the EARO and EDAR messages to enable the		This specification updates the EARO and EDAR messages to enable the
	skipping to change at line 843 ¶		skipping to change at line 843 ¶
	"IPv6 Backbone Router" [RFC8929] defines a proxy operation whereby a		"IPv6 Backbone Router" [RFC8929] defines a proxy operation whereby a
	6LoWPAN Border Router (6LBR) may impersonate a 6LN when performing an		6LoWPAN Border Router (6LBR) may impersonate a 6LN when performing an
	address registration. In that case, [RFC8505] messages are used as		address registration. In that case, [RFC8505] messages are used as
	is, with one change that the SLLAO in the proxied NS(EARO) messages		is, with one change that the SLLAO in the proxied NS(EARO) messages
	indicates the Registering Node (the 6LBR) as opposed to the		indicates the Registering Node (the 6LBR) as opposed to the
	Registered Node (the 6LN). See Figure 5 of [RFC8929] for an example		Registered Node (the 6LN). See Figure 5 of [RFC8929] for an example
	of proxy operation by the 6LBR, which generates an NS(EARO) upon		of proxy operation by the 6LBR, which generates an NS(EARO) upon
	receiving an EDAR message.		receiving an EDAR message.
	This specification updates that proxy operation with the updates in		This specification updates that proxy operation with the updates in
	[RFC9685] and this on the formats and content of the EARO, the EDAR,		[RFC9685] and defines the formats and content of the EARO, EDAR, and
	and the EDAC messages, to support the P-Field and the signaling of		EDAC messages in order to support the P-Field and the signaling of
	prefixes. The proxy MUST use the P-Field as received in the EDAR or		prefixes. The proxy MUST use the P-Field as received in the EDAR or
	NS(EARO) message to generate the proxied NS(EARO), and it MUST use		NS(EARO) message to generate the proxied NS(EARO), and it MUST use
	the exact same prefix and prefix length as received in the case of a		the exact same prefix and prefix length as received in the case of a
	prefix registration.		prefix registration.
	11. Security Considerations		11. Security Considerations
	This specification updates [RFC8505], and the security considerations		This specification updates [RFC8505], and the security considerations
	of that document also apply to this document. In particular, the		of that document also apply to this document. In particular, the
	link layer SHOULD be sufficiently protected to prevent rogue access,		link layer SHOULD be sufficiently protected to prevent rogue access,
	skipping to change at line 878 ¶		skipping to change at line 878 ¶
	associated to a prefix in all the 6LNs, but the flow is not clearly		associated to a prefix in all the 6LNs, but the flow is not clearly
	documented and may not complete in due time for all nodes in LLN use		documented and may not complete in due time for all nodes in LLN use
	cases. It may be simpler to install an all-new address with new keys		cases. It may be simpler to install an all-new address with new keys
	over a period of time and switch the traffic to that address when the		over a period of time and switch the traffic to that address when the
	migration is complete.		migration is complete.
	12. Operational Considerations		12. Operational Considerations
	12.1. Partially Upgraded Networks		12.1. Partially Upgraded Networks
	A mix of devices that support only [RFC8505], both [RFC8505] and		Devices may coexist while providing different support (i.e., only
	[RFC9685], and all of the above plus this specification, may coexist.		[RFC8505], both [RFC8505] and [RFC9685], or those two as well as this
	Different cases may occur:		specification). The following cases may occur:
	* A legacy 6LN will not register prefixes, and the service will be		* A legacy 6LN will not register prefixes, and the service will be
	the same when the network is upgraded.		the same when the network is upgraded.
	* A legacy 6LR will not set the F flag in the 6CIO and an upgraded		* A legacy 6LR will not set the F flag in the 6CIO and an upgraded
	6LN will not register prefixes with that router, though it may		6LN will not register prefixes with that router, though it may
	with other 6LRs that do support this specification.		with other 6LRs that do support this specification.
	* Upon an EDAR message, a legacy 6LBR may not realize that the		* Upon an EDAR message, a legacy 6LBR may not realize that the
	address being registered comes with a whole prefix, and return		address being registered comes with a whole prefix, and return
	skipping to change at line 946 ¶		skipping to change at line 946 ¶
	serving virtual machines or applications within the same physical		serving virtual machines or applications within the same physical
	node. Note also that a RPL-aware Leaf would preferably leverage RPL		node. Note also that a RPL-aware Leaf would preferably leverage RPL
	directly to inject routes, to fully leverage the routing protocol.		directly to inject routes, to fully leverage the routing protocol.
	The registration state is periodically renewed by the Registering		The registration state is periodically renewed by the Registering
	Node (the 6LN), before the lifetime indicated in the EARO expires (at		Node (the 6LN), before the lifetime indicated in the EARO expires (at
	the 6LR). As for unicast IPv6 addresses, the 6LR uses an Extended		the 6LR). As for unicast IPv6 addresses, the 6LR uses an Extended
	Duplicate Address Request/Confirmation (EDAR/EDAC) exchange with the		Duplicate Address Request/Confirmation (EDAR/EDAC) exchange with the
	6LBR to notify the 6LBR of the presence of the listeners. With this		6LBR to notify the 6LBR of the presence of the listeners. With this
	specification, a router that owns a prefix or provides reachability		specification, a router that owns a prefix or provides reachability
	to an external prefix but is not a RPL router can also register those		to an external prefix but is not a RPL router can also register those
	prefixes with the R flag set, to enable reachability to the Prefix		prefixes with the R flag set, to enable reachability to the prefix
	within the RPL domain.		within the RPL domain.
	12.3. Application to a Shared Link		12.3. Application to a Shared Link
	A shared link is a situation where more than one prefix is deployed		A shared link is a situation where more than one prefix is deployed
	over an L2 link (say, a switched Ethernet fabric or a Wi-Fi Extended		over an L2 link (say, a switched Ethernet fabric or a Wi-Fi Extended
	Service Set (ESS) federating multiple Access Points (APs)), and not		Service Set (ESS) federating multiple Access Points (APs)), and not
	necessarily all nodes are aware of all prefixes. Figure 6 depicts		necessarily all nodes are aware of all prefixes. Figure 6 depicts
	such a situation, with two routers 6LR1 and 6LR2 that own respective		such a situation, with two routers 6LR1 and 6LR2 that own respective
	prefixes P1:: and P2:: and expose those in their RA messages over the		prefixes P1:: and P2:: and expose those in their RA messages over the
End of changes. 6 change blocks.
	15 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48.