draft-ietf-6man-pio-pflag-01.txt		draft-ietf-6man-pio-pflag-02.txt
	IPv6 Maintenance L. Colitti		IPv6 Maintenance L. Colitti
	Internet-Draft J. Linkova		Internet-Draft J. Linkova
	Updates: 4861, 4862 (if approved) X. Ma, Ed.		Updates: 4861, 4862 (if approved) X. Ma, Ed.
	Intended status: Standards Track Google		Intended status: Standards Track Google
	Expires: 18 September 2024 D. Lamparter		Expires: 22 September 2024 D. Lamparter
	NetDEF, Inc.		NetDEF, Inc.
	17 March 2024		21 March 2024
	Signalling DHCPv6 Prefix Delegation Availability to Hosts		Signalling DHCPv6 Prefix Delegation Availability to Hosts
	draft-ietf-6man-pio-pflag-01		draft-ietf-6man-pio-pflag-02
	Abstract		Abstract
	This document defines a "P" flag in the Prefix Information Option of		This document defines a "P" flag in the Prefix Information Option of
	IPv6 Router Advertisements (RAs). The flag is used to indicate that		IPv6 Router Advertisements (RAs). The flag is used to indicate that
	the network prefers that clients do not use the prefix provided in		the network prefers that clients do not use the prefix provided in
	the PIO for SLAAC but request a prefix via DHCPv6 PD instead, and use		the PIO for SLAAC but request a prefix via DHCPv6 PD instead, and use
	that delegated prefix to form addresses.		that delegated prefix to form addresses.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 18 September 2024.		This Internet-Draft will expire on 22 September 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Router Behaviour . . . . . . . . . . . . . . . . . . . . . . 4		4. Router Behaviour . . . . . . . . . . . . . . . . . . . . . . 4
	5. Host Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4		5. Host Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. Tracking and requesting prefixes . . . . . . . . . . . . 4		5.1. Tracking and requesting prefixes . . . . . . . . . . . . 4
	5.2. Using received prefix(es) . . . . . . . . . . . . . . . . 5		5.2. Using received prefix(es) . . . . . . . . . . . . . . . . 6
	5.3. Absence of PIOs with P bit set . . . . . . . . . . . . . 6		5.3. Absence of PIOs with P bit set . . . . . . . . . . . . . 6
	5.4. Source Address Selection . . . . . . . . . . . . . . . . 6		5.4. Source Address Selection . . . . . . . . . . . . . . . . 7
	6. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Modifications to RFC-Mandated Behavior . . . . . . . . . . . 7		7. Modifications to RFC-Mandated Behavior . . . . . . . . . . . 7
	7.1. Changes to RFC4861 . . . . . . . . . . . . . . . . . . . 7		7.1. Changes to RFC4861 . . . . . . . . . . . . . . . . . . . 7
	7.2. Changes to RFC4862 . . . . . . . . . . . . . . . . . . . 8		7.2. Changes to RFC4862 . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . 11		11.2. Informative References . . . . . . . . . . . . . . . . . 11
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	IPv6-capable devices, especially mobile devices, usually have		IPv6-capable devices, especially mobile devices, usually have
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Rationale		3. Rationale
	The network administrator might want to indicate to hosts that		The network administrator might want to indicate to hosts that
	requesting a prefix via DHCPv6-PD and using that prefix for address		requesting a prefix via DHCPv6 PD and using that prefix for address
	assignment (see [I-D.ietf-v6ops-dhcp-pd-per-device]) should be		assignment (see [I-D.ietf-v6ops-dhcp-pd-per-device]) should be
	preferred over forming SLAAC addresses from the prefix provided in		preferred over using individual addresses from the on-link prefix.
	the PIO. The information is passed to the host via a P flag in the		The information is passed to the host via a P flag in the Prefix
	Prefix Information Option (PIO). The reason for it being a PIO flag		Information Option (PIO). The reason for it being a PIO flag is as
	is as follows:		follows:
	* The information should be contained in the Router Advertisement		* The information must be contained in the Router Advertisement
	because it must be available to the host before it decides to form		because it must be available to the host before it decides to form
	IPv6 addresses from the PIO prefix using SLAAC. Otherwise, the		IPv6 addresses from the PIO prefix using SLAAC. Otherwise, the
	host might form IPv6 addresses from the PIO provided and start		host might use SLAAC to form IPv6 addresses from the PIO provided
	using them, even if a unique per-host prefix is available via		and start using them, even if a unique per-host prefix is
	DHCPv6 PD. This is suboptimal because if the host later acquires		available via DHCPv6 PD. This is suboptimal because if the host
	a prefix using DHCPv6 PD, it can either use both the prefix and		later acquires a prefix using DHCPv6 PD, it can either use both
	SLAAC addresses, reducing the scalability benefits of using DHCPv6		the prefix and SLAAC addresses, reducing the scalability benefits
	PD, or can remove the SLAAC addresses, which would be disruptive		of using DHCPv6 PD, or can remove the SLAAC addresses, which would
	for applications that are using them.		be disruptive for applications that are using them.
	* This information is specific to the particular prefix being		* This information is specific to the particular prefix being
	announced. For example, a network administrator might want hosts		announced. For example, a network administrator might want hosts
	to assign global addresses from delegated prefixes, but use the		to assign global addresses from delegated prefixes, but use the
	PIO prefix to form ULA addresses. Also, in a multihoming		PIO prefix to form ULA addresses. Also, in a multihoming
	situation, one upstream network might choose to assign prefixes		situation, one upstream network might choose to assign prefixes
	via prefix delegation, and another via PIOs.		via prefix delegation, and another via PIOs.
	Note that the prefix(es) that the client obtains via DHCPv6 PD are		Note that the prefix(es) that the client obtains via DHCPv6 PD are
	not related in any way to the prefix(es) in the Router Advertisement		not related in any way to the prefix(es) in the Router Advertisement
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	4. Router Behaviour		4. Router Behaviour
	Routers SHOULD set the P flag to zero by default, unless explicitly		Routers SHOULD set the P flag to zero by default, unless explicitly
	configured by the administrator, and SHOULD allow the opearator to		configured by the administrator, and SHOULD allow the opearator to
	set the P flag value for any given prefix.		set the P flag value for any given prefix.
	5. Host Behaviour		5. Host Behaviour
	5.1. Tracking and requesting prefixes		5.1. Tracking and requesting prefixes
	The host SHOULD NOT use SLAAC to obtain IPv6 addresses from
	prefix(es) with the P bit set.
	For each interface, the host MUST keep a list of every PIO it has		For each interface, the host MUST keep a list of every PIO it has
	received that has the P flag set and a nonzero Preferred Lifetime.		received that has the P flag set and a nonzero Preferred Lifetime.
	The list affects the behaviour of the DHCPv6 client as follows:		The list affects the behaviour of the DHCPv6 client as follows:
	* When a prefix's Preferred Lifetime decreases to zero, the prefix		* When a prefix's Preferred Lifetime decreases to zero, the prefix
	MUST be removed from the list.		MUST be removed from the list.
	* When the length of the list increases to one, the host SHOULD		* When the length of the list increases to one, the host SHOULD
	start DHCPv6 prefix delegation if it is not already running.		start DHCPv6 prefix delegation if it is not already running.
	* When the length of the list decreases to zero, the host SHOULD		* When the length of the list decreases to zero, the host SHOULD
	stop DHCPv6 prefix delegation if it has no other reason to run it.		stop DHCPv6 prefix delegation if it has no other reason to run it.
	The lifetimes of any prefixes already obtained via DHCPv6 are		The lifetimes of any prefixes already obtained via DHCPv6 are
	unaffected.		unaffected.
	* If the client has already received delegated prefix(es) from one		* If the host has already received delegated prefix(es) from one or
	or more servers, then any time a prefix is added to or removed		more servers, then any time a prefix is added to or removed from
	from the list, the client MUST consider this to be a change in		the list, the host MUST consider this to be a change in
	configuration information as described in Section 18.2.12 of		configuration information as described in Section 18.2.12 of
	[RFC8415], and it MUST perform a REBIND, unless it is going to		[RFC8415], and it MUST perform a REBIND, unless it is going to
	stop the client because the list became empty. This is in		stop the DHCPv6 client because the list became empty. This is in
	addition to performing a REBIND in the other cases required by		addition to performing a REBIND in the other cases required by
	that section. Issuing a REBIND allows the host to obtain new		that section. Issuing a REBIND allows the host to obtain new
	prefixes if necessary, e.g., when the network is being renumbered.		prefixes if necessary, e.g., when the network is being renumbered.
	It also refreshes state related to the delegated prefix(es).		It also refreshes state related to the delegated prefix(es).
	When a host requests a prefix via DHCPv6 PD, it MUST use the prefix		When a host requests a prefix via DHCPv6 PD, it MUST use the prefix
	length hint Section 18.2.4 of [RFC8415] to request a prefix that is		length hint Section 18.2.4 of [RFC8415] to request a prefix that is
	short enough to form addresses via SLAAC.		short enough to form addresses via SLAAC.
			In order to achieve the scalability benefits of using DHCPv6 PD, the
			host SHOULD prefer to form addresses from the delegated prefix
			instead of using individual addresses in the on-link prefixes.
			Therefore, when the host requests a prefix using DHCPv6 PD:
			* It SHOULD NOT use SLAAC to obtain IPv6 addresses from prefix(es)
			with the P bit set.
			* It SHOULD NOT request individual IPv6 addresses from DHPCv6, i.e.,
			it SHOULD NOT include any IA_NA or IA_TA options in Solicit, Renew
			or Rebind messages.
			If the host does not obtain any suitable prefixes via DHCPv6 PD, it
			MAY choose to fall back to other address assignment mechanisms, such
			as forming addresses via SLAAC (if the PIO has the A flag set to 1)
			and/or requesting addresses via DHCPv6.
	The P flag is meaningless for link-local prefixes and any Prefix		The P flag is meaningless for link-local prefixes and any Prefix
	Information Option containing the link-local prefix MUST be ignored		Information Option containing the link-local prefix MUST be ignored
	as specified in Section 5.5.3 of [RFC4862].		as specified in Section 5.5.3 of [RFC4862].
	5.2. Using received prefix(es)		5.2. Using received prefix(es)
	If the received prefix is too long to be used for SLAAC, the host		If the received prefix is too long to be used for SLAAC, the host
	MUST ignore it. If the prefix is shorter than required for SLAAC,		MUST ignore it. If the prefix is shorter than required for SLAAC,
	the host SHOULD accept it, allocate one or more longer prefix		the host SHOULD accept it, allocate one or more longer prefix
	suitable for SLAAC and use the prefixes as described below.		suitable for SLAAC and use the prefixes as described below.
End of changes. 15 change blocks.
	27 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/