draft-ietf-intarea-provisioning-domains-07.txt		draft-ietf-intarea-provisioning-domains-08.txt
	Network Working Group P. Pfister		Network Working Group P. Pfister
	Internet-Draft E. Vyncke		Internet-Draft E. Vyncke
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: April 2, 2020 T. Pauly		Expires: April 10, 2020 T. Pauly
	Apple Inc.		Apple Inc.
	D. Schinazi		D. Schinazi
	Google LLC		Google LLC
	W. Shao		W. Shao
	Cisco		Cisco
	September 30, 2019		October 08, 2019
	Discovering Provisioning Domain Names and Data		Discovering Provisioning Domain Names and Data
	draft-ietf-intarea-provisioning-domains-07		draft-ietf-intarea-provisioning-domains-08
	Abstract		Abstract
	Provisioning Domains (PvDs) are defined as consistent sets of network		Provisioning Domains (PvDs) are defined as consistent sets of network
	configuration information. This allows hosts to manage connections		configuration information. This allows hosts to manage connections
	to multiple networks and interfaces simultaneously, such as when a		to multiple networks and interfaces simultaneously, such as when a
	home router provides connectivity through both a broadband and		home router provides connectivity through both a broadband and
	cellular network provider.		cellular network provider.
	This document defines a mechanism for explicitly identifying PvDs		This document defines a mechanism for explicitly identifying PvDs
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 April 2, 2020.		This Internet-Draft will expire on April 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	4. Provisioning Domain Additional Information . . . . . . . . . 12		4. Provisioning Domain Additional Information . . . . . . . . . 12
	4.1. Retrieving the PvD Additional Information . . . . . . . . 13		4.1. Retrieving the PvD Additional Information . . . . . . . . 13
	4.2. Operational Consideration to Providing the PvD Additional		4.2. Operational Consideration to Providing the PvD Additional
	Information . . . . . . . . . . . . . . . . . . . . . . . 15		Information . . . . . . . . . . . . . . . . . . . . . . . 15
	4.3. PvD Additional Information Format . . . . . . . . . . . . 15		4.3. PvD Additional Information Format . . . . . . . . . . . . 15
	4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17		4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17
	4.4. Detecting misconfiguration and misuse . . . . . . . . . . 17		4.4. Detecting misconfiguration and misuse . . . . . . . . . . 17
	5. Operational Considerations . . . . . . . . . . . . . . . . . 18		5. Operational Considerations . . . . . . . . . . . . . . . . . 18
	5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 18		5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 18
	5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts . . . 18		5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts . . . 18
	5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 19		5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 20
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	8.1. Additional Information PvD Keys Registry . . . . . . . . 22		8.1. New entry in the Well-Known URIs Registry . . . . . . . . 22
	8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 22		8.2. Additional Information PvD Keys Registry . . . . . . . . 22
	8.3. PvD JSON Media Type Registration . . . . . . . . . . . . 22		8.3. PvD Option Flags Registry . . . . . . . . . . . . . . . . 22
			8.4. PvD JSON Media Type Registration . . . . . . . . . . . . 23
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . 23		10.1. Normative References . . . . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . 24		10.2. Informative References . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	Provisioning Domains (PvDs) are defined in [RFC7556] as consistent		Provisioning Domains (PvDs) are defined in [RFC7556] as consistent
	sets of network configuration information. This information includes		sets of network configuration information. This information includes
	properties that are traditionally associated with a single networking		properties that are traditionally associated with a single networking
	interface, such as source addresses, DNS configuration, proxy		interface, such as source addresses, DNS configuration, proxy
	configuration, and gateway addresses.		configuration, and gateway addresses.
	Clients that are aware of PvDs can take advantage of multiple network		Clients that are aware of PvDs can take advantage of multiple network
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	operator in order to avoid naming collisions. The same PvD ID MAY be		operator in order to avoid naming collisions. The same PvD ID MAY be
	used in several access networks when they ultimately provide		used in several access networks when they ultimately provide
	identical services (e.g., in all home networks subscribed to the same		identical services (e.g., in all home networks subscribed to the same
	service); else, the PvD ID MUST be different to follow Section 2.4 of		service); else, the PvD ID MUST be different to follow Section 2.4 of
	[RFC7556].		[RFC7556].
	3.1. PvD ID Option for Router Advertisements		3.1. PvD ID Option for Router Advertisements
	This document introduces a Router Advertisement (RA) option called		This document introduces a Router Advertisement (RA) option called
	PvD Option. It is used to convey the FQDN identifying a given PvD		PvD Option. It is used to convey the FQDN identifying a given PvD
	(see Figure 1, bind the PvD ID with configuration information		(see Figure 1), bind the PvD ID with configuration information
	received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over		received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over
	TLS to retrieve the PvD Additional Information JSON object (see		TLS to retrieve the PvD Additional Information JSON object (see
	Section 4), as well as contain any other RA options which would		Section 4), as well as contain any other RA options which would
	otherwise be valid in the RA.		otherwise be valid in the RA.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |H|L|R| Reserved | Delay |		| Type | Length |H|L|R| Reserved | Delay |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 45 ¶		skipping to change at page 6, line 45 ¶
	in Section 4.		in Section 4.
	L-flag: (1 bit) 'Legacy' flag stating whether the router is also		L-flag: (1 bit) 'Legacy' flag stating whether the router is also
	providing IPv4 information using DHCPv4 (see Section 3.4.2).		providing IPv4 information using DHCPv4 (see Section 3.4.2).
	R-flag: (1 bit) 'Router Advertisement' flag stating whether the PvD		R-flag: (1 bit) 'Router Advertisement' flag stating whether the PvD
	Option is followed (right after padding to the next 64 bits		Option is followed (right after padding to the next 64 bits
	boundary) by a Router Advertisement message header (See section		boundary) by a Router Advertisement message header (See section
	4.2 of [RFC4861]).		4.2 of [RFC4861]).
	Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from
	hosts by a randomized backoff (see Section 4.1).
	Reserved: (13 bits) Reserved for later use. It MUST be set to zero		Reserved: (13 bits) Reserved for later use. It MUST be set to zero
	by the sender and ignored by the receiver.		by the sender and ignored by the receiver.
			Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from
			hosts by a randomized backoff (see Section 4.1).
	Sequence Number: (16 bits) Sequence number for the PvD Additional		Sequence Number: (16 bits) Sequence number for the PvD Additional
	Information, as described in Section 4.		Information, as described in Section 4.
	PvD ID FQDN: The FQDN used as PvD ID encoded in DNS format, as		PvD ID FQDN: The FQDN used as PvD ID encoded in DNS format, as
	described in Section 3.1 of [RFC1035]. Domain names compression		described in Section 3.1 of [RFC1035]. Domain names compression
	described in Section 4.1.4 of [RFC1035] MUST NOT be used.		described in Section 4.1.4 of [RFC1035] MUST NOT be used.
	Padding: Zero or more padding octets to the next 8 octet boundary		Padding: Zero or more padding octets to the next 8 octet boundary
	(see Section 4.6 of [RFC4861]). It MUST be set to zero by the		(see Section 4.6 of [RFC4861]). It MUST be set to zero by the
	sender, and ignored by the receiver.		sender, and ignored by the receiver.
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	Advertisement message header as specified in [RFC4861]. The		Advertisement message header as specified in [RFC4861]. The
	sender MUST set the 'Type' to 134, the value for "Router		sender MUST set the 'Type' to 134, the value for "Router
	Advertisement", and set the 'Code' to 0. Receivers MUST ignore		Advertisement", and set the 'Code' to 0. Receivers MUST ignore
	both of these fields. The 'Checksum' MUST be set to 0 by the		both of these fields. The 'Checksum' MUST be set to 0 by the
	sender; non-zero checksums MUST be ignored by the receiver. All		sender; non-zero checksums MUST be ignored by the receiver. All
	other fields are to be set and parsed as specified in [RFC4861] or		other fields are to be set and parsed as specified in [RFC4861] or
	any updating documents.		any updating documents.
	Options: Zero or more RA options that would otherwise be valid as		Options: Zero or more RA options that would otherwise be valid as
	part of the Router Advertisement main body, but are instead		part of the Router Advertisement main body, but are instead
	included in the PvD Option such as to be ignored by hosts that are		included in the PvD Option so as to be ignored by hosts that are
	not PvD-aware.		not PvD-aware.
	Here is an example of a PvD Option with "example.org" as the PvD ID		Here is an example of a PvD Option with "example.org" as the PvD ID
	FQDN and including both an RDNSS option and a prefix information		FQDN and including both an RDNSS option and a prefix information
	option. It has a Sequence Number of 123, and indicates the presence		option. It has a Sequence Number of 123, and indicates the presence
	of additional information that is expected to be fetched with a delay		of additional information that is expected to be fetched with a delay
	factor of 5.		factor of 5.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 6 ¶
	PvD IDs MUST be compared in a case-insensitive manner as defined by		PvD IDs MUST be compared in a case-insensitive manner as defined by
	[RFC4343]. For example, "pvd.example.com." or "PvD.Example.coM."		[RFC4343]. For example, "pvd.example.com." or "PvD.Example.coM."
	would refer to the same PvD.		would refer to the same PvD.
	While resolving names, executing the default address selection		While resolving names, executing the default address selection
	algorithm [RFC6724] or executing the default router selection		algorithm [RFC6724] or executing the default router selection
	algorithm when forwarding packets ([RFC4861], [RFC4191] and		algorithm when forwarding packets ([RFC4861], [RFC4191] and
	[RFC8028]), hosts and applications MAY consider only the		[RFC8028]), hosts and applications MAY consider only the
	configuration associated with an arbitrary set of PvDs.		configuration associated with any non-empty subset of PvDs.
	For example, a host MAY associate a given process with a specific		For example, a host MAY associate a given process with a specific
	PvD, or a specific set of PvDs, while associating another process		PvD, or a specific set of PvDs, while associating another process
	with another PvD. A PvD-aware application might also be able to		with another PvD. A PvD-aware application might also be able to
	select, on a per-connection basis, which PvDs should be used. In		select, on a per-connection basis, which PvDs should be used. In
	particular, constrained devices such as small battery operated		particular, constrained devices such as small battery operated
	devices (e.g. IoT), or devices with limited CPU or memory resources		devices (e.g. IoT), or devices with limited CPU or memory resources
	may purposefully use a single PvD while ignoring some received RAs		may purposefully use a single PvD while ignoring some received RAs
	containing different PvD IDs.		containing different PvD IDs.
	skipping to change at page 15, line 8 ¶		skipping to change at page 15, line 8 ¶
	Since the 'Delay' value is directly within the PvD Option rather than		Since the 'Delay' value is directly within the PvD Option rather than
	the object itself, an operator may perform a push-based update by		the object itself, an operator may perform a push-based update by
	incrementing the Sequence value while changing the Delay value		incrementing the Sequence value while changing the Delay value
	depending on the criticality of the update and its PvD Additional		depending on the criticality of the update and its PvD Additional
	Information servers capacity.		Information servers capacity.
	The PvD Additional Information object includes a set of IPv6 prefixes		The PvD Additional Information object includes a set of IPv6 prefixes
	(under the key "prefixes") which MUST be checked against all the		(under the key "prefixes") which MUST be checked against all the
	Prefix Information Options advertised in the RA. If any of the		Prefix Information Options advertised in the RA. If any of the
	prefixes included in the PIO is not covered by at least one of the		prefixes included in any associated PIO is not covered by at least
	listed prefixes, the associated PvD information MUST be considered to		one of the listed prefixes, the associated PvD information MUST be
	be a misconfiguration, and MUST NOT be used by the host. See		considered to be a misconfiguration, and MUST NOT be used by the
	Section 4.4 for more discussion on handling such misconfigurations.		host. See Section 4.4 for more discussion on handling such
			misconfigurations.
	4.2. Operational Consideration to Providing the PvD Additional		4.2. Operational Consideration to Providing the PvD Additional
	Information		Information
	Whenever the H-flag is set in the PvD Option, a valid PvD Additional		Whenever the H-flag is set in the PvD Option, a valid PvD Additional
	Information object MUST be made available to all hosts receiving the		Information object MUST be made available to all hosts receiving the
	RA by the network operator. In particular, when a captive portal is		RA by the network operator. In particular, when a captive portal is
	present, hosts MUST still be allowed to perform DNS, PKI and HTTP		present, hosts MUST still be allowed to perform DNS, PKI and HTTP
	over TLS operations related to the retrieval of the object, even		over TLS operations related to the retrieval of the object, even
	before logging into the captive portal.		before logging into the captive portal.
	skipping to change at page 16, line 36 ¶		skipping to change at page 16, line 36 ¶
	the future. If the PIO of the received RA is not covered by at least		the future. If the PIO of the received RA is not covered by at least
	one of the "prefixes" key, the retrieved object SHOULD be ignored.		one of the "prefixes" key, the retrieved object SHOULD be ignored.
	The following table presents some optional keys which MAY be included		The following table presents some optional keys which MAY be included
	in the object.		in the object.
	+------------+----------------------+----------+--------------------+		+------------+----------------------+----------+--------------------+
	| JSON key | Description | Type | Example |		| JSON key | Description | Type | Example |
	+------------+----------------------+----------+--------------------+		+------------+----------------------+----------+--------------------+
	| dnsZones | DNS zones searchable | Array of | ["example.com", |		| dnsZones | DNS zones searchable | Array of | ["example.com", |
	| | and accessible | strings | |		| | and accessible | strings | "sub.example.com"] |
	| | | | |
	| | | | "sub.example.com"] |
	| | | | |		| | | | |
	| noInternet | No Internet, set | Boolean | true |		| noInternet | No Internet, set | Boolean | true |
	| | when the PvD is | | |		| | when the PvD is | | |
	| | restricted. | | |		| | restricted. | | |
	+------------+----------------------+----------+--------------------+		+------------+----------------------+----------+--------------------+
	It is worth noting that the JSON format allows for extensions.		It is worth noting that the JSON format allows for extensions.
	Whenever an unknown key is encountered, it MUST be ignored along with		Whenever an unknown key is encountered, it MUST be ignored along with
	its associated elements.		its associated elements.
	skipping to change at page 17, line 27 ¶		skipping to change at page 17, line 27 ¶
	{		{
	"identifier": "cafe.example.com",		"identifier": "cafe.example.com",
	"expires": "2017-07-23T06:00:00Z",		"expires": "2017-07-23T06:00:00Z",
	"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],		"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
	}		}
	{		{
	"identifier": "company.foo.example.com",		"identifier": "company.foo.example.com",
	"expires": "2017-07-23T06:00:00Z",		"expires": "2017-07-23T06:00:00Z",
	"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],		"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
	"vendor-foo": { "private-key": "private-value" },		"vendor-foo":
			{
			"private-key": "private-value",
			},
	}		}
	4.4. Detecting misconfiguration and misuse		4.4. Detecting misconfiguration and misuse
	When a host retrieves the PvD Additional Information, it MUST verify		When a host retrieves the PvD Additional Information, it MUST verify
	that the TLS server certificate is valid for the performed request		that the TLS server certificate is valid for the performed request
	(e.g., that the Subject Name is equal to the PvD ID expressed as an		(e.g., that the Subject Name is equal to the PvD ID expressed as an
	FQDN). This authentication creates a secure binding between the		FQDN). This authentication creates a secure binding between the
	information provided by the trusted Router Advertisement, and the		information provided by the trusted Router Advertisement, and the
	HTTPS server. However, this does not mean the Advertising Router and		HTTPS server. However, this does not mean the Advertising Router and
	the PvD server belong to the same entity.		the PvD server belong to the same entity.
	Hosts MUST verify that all prefixes in the RA PIO are covered by a		Hosts MUST verify that all prefixes in all the RA PIOs are covered by
	prefix from the PvD Additional Information. An adversarial router		a prefix from the PvD Additional Information. An adversarial router
	attempting to spoof the definition of an Explicit PvD, without the		attempting to spoof the definition of an Explicit PvD, without the
	ability to modify the PvD Additional Information, would need to		ability to modify the PvD Additional Information, would need to
	perform NAT66 in order to circumvent this check. Thus, this check		perform NAT66 in order to circumvent this check. Thus, this check
	cannot prevent all spoofing, but it can detect misconfiguration or		cannot prevent all spoofing, but it can detect misconfiguration or
	mismatched routers that are not adding a NAT.		mismatched routers that are not adding a NAT.
	If NAT66 is being added in order to spoof PvD ownership, the HTTPS		If NAT66 is being added in order to spoof PvD ownership, the HTTPS
	server for additional information can detect this misconfiguration.		server for additional information can detect this misconfiguration.
	The HTTPS server SHOULD validate the source addresses of incoming		The HTTPS server SHOULD validate the source addresses of incoming
	connections (see Section 4.1). This check gives reasonable assurance		connections (see Section 4.1). This check gives reasonable assurance
	skipping to change at page 18, line 48 ¶		skipping to change at page 19, line 4 ¶
	Note that a PvD-aware host will receive two different prefixes,		Note that a PvD-aware host will receive two different prefixes,
	2001:db8:cafe::/64 and 2001:db8:f00d::/64, both associated with the		2001:db8:cafe::/64 and 2001:db8:f00d::/64, both associated with the
	same PvD (identified by "example.org."). A non-PvD-aware host will		same PvD (identified by "example.org."). A non-PvD-aware host will
	only receive one prefix, 2001:db8:cafe::/64.		only receive one prefix, 2001:db8:cafe::/64.
	5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts		5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts
	It is expected that for some years, networks will have a mixed		It is expected that for some years, networks will have a mixed
	environment of PvD-aware hosts and non-PvD-aware hosts. If there is		environment of PvD-aware hosts and non-PvD-aware hosts. If there is
	a need to give specific information to PvD-aware hosts only, then it		a need to give specific information to PvD-aware hosts only, then it
	is recommended to send two RA messages (one for each class of hosts).		is RECOMMENDED to send two RA messages, one for each class of hosts.
	For example, here is the RA sent for non-PvD-aware hosts:		If two RA messages are sent for this reason, they MUST be sent from
			two different link-local source addresses (Section 3.2). For
			example, here is the RA sent for non-PvD-aware hosts:
	o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use		o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use
	this router as a default router)		this router as a default router)
	o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64		o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
	o Recursive DNS Server Option: length = 3, addresses=		o Recursive DNS Server Option: length = 3, addresses=
	[2001:db8:cafe::53]		[2001:db8:cafe::53]
	o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org.,		o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org.,
	skipping to change at page 20, line 22 ¶		skipping to change at page 20, line 29 ¶
	o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64		o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
	o Recursive DNS Server Option: length = 3, addresses=		o Recursive DNS Server Option: length = 3, addresses=
	[2001:db8:cafe::53]		[2001:db8:cafe::53]
	o PvD Option header: length = 3, PvD ID FQDN = foo.example.org.,		o PvD Option header: length = 3, PvD ID FQDN = foo.example.org.,
	R-flag = 0 (actual length of the header 24 bytes = 3 * 8 bytes)		R-flag = 0 (actual length of the header 24 bytes = 3 * 8 bytes)
	The second RA contains a prefix usable only by PvD-aware hosts. Non-		The second RA contains a prefix usable only by PvD-aware hosts. Non-
	PvD-aware hosts will ignore this RA.		PvD-aware hosts will ignore this RA; hence, the only PvD-aware hosts
			will be multi-homed.
	o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use		o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use
	this router as a default router)		this router as a default router)
	o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN =		o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN =
	bar.example.org., R-flag = 1 (actual length of the header 24 bytes		bar.example.org., R-flag = 1 (actual length of the header 24 bytes
	= 3 * 8 bytes)		= 3 * 8 bytes)
	* RA Header: router lifetime = 1600 (PvD-aware hosts will use		* RA Header: router lifetime = 1600 (PvD-aware hosts will use
	this router as a default router), implicit length = 2		this router as a default router), implicit length = 2
	* Prefix Information Option: length = 4, prefix =		* Prefix Information Option: length = 4, prefix =
	2001:db8:f00d::/64		2001:db8:f00d::/64
	* Recursive DNS Server Option: length = 3, addresses =		* Recursive DNS Server Option: length = 3, addresses =
	[2001:db8:f00d::53]		[2001:db8:f00d::53]
			Note: the above examples assume that the router has received its PvD
			IDs from upstream routers or via some other configuration mechanism.
			Another document could define ways for the router to generate its own
			PvD IDs to allow the above scenario in the absence of PvD ID
			provisioning.
	6. Security Considerations		6. Security Considerations
	Although some solutions such as IPsec or SeND [RFC3971] can be used		Although some solutions such as IPsec or SeND [RFC3971] can be used
	in order to secure the IPv6 Neighbor Discovery Protocol, in practice		in order to secure the IPv6 Neighbor Discovery Protocol, in practice
	actual deployments largely rely on link layer or physical layer		actual deployments largely rely on link layer or physical layer
	security mechanisms (e.g. 802.1x [IEEE8021X]) in conjunction with RA		security mechanisms (e.g. 802.1x [IEEE8021X]) in conjunction with RA
	Guard [RFC6105].		Guard [RFC6105].
	This specification does not improve the Neighbor Discovery Protocol		This specification does not improve the Neighbor Discovery Protocol
	security model, but extends the purely link-local trust relationship		security model, but extends the purely link-local trust relationship
	skipping to change at page 21, line 14 ¶		skipping to change at page 21, line 28 ¶
	It must be noted that Section 4.4 of this document only provides		It must be noted that Section 4.4 of this document only provides
	reasonable assurance against misconfiguration but does not prevent an		reasonable assurance against misconfiguration but does not prevent an
	hostile network access provider to advertise wrong information that		hostile network access provider to advertise wrong information that
	could lead applications or hosts to select a hostile PvD.		could lead applications or hosts to select a hostile PvD.
	Users cannot be assumed to be able to meaningfully differentiate		Users cannot be assumed to be able to meaningfully differentiate
	between "safe" and "unsafe" networks. This is a known attack surface		between "safe" and "unsafe" networks. This is a known attack surface
	that is present whether or not PvDs are in use, and hence cannot be		that is present whether or not PvDs are in use, and hence cannot be
	addressed by this document. However, a host that correctly		addressed by this document. However, a host that correctly
	implements the MPvD architecture ([RFC7556]) using the mechanism		implements the multiple PvD architecture ([RFC7556]) using the
	described in this document will be less susceptible to such attacks		mechanism described in this document will be less susceptible to such
	than a host that does not by being able to check for the various		attacks than a host that does not by being able to check for the
	misconfigurations described in this document.		various misconfigurations described in this document.
	7. Privacy Considerations		7. Privacy Considerations
	Retrieval of the PvD Additional Information over HTTPS requires early		Retrieval of the PvD Additional Information over HTTPS requires early
	communications between the connecting host and a server which may be		communications between the connecting host and a server which may be
	located further than the first hop router. Although this server is		located further than the first hop router. Although this server is
	likely to be located within the same administrative domain as the		likely to be located within the same administrative domain as the
	default router, this property can't be ensured. Therefore, hosts		default router, this property can't be ensured. Therefore, hosts
	willing to retrieve the PvD Additional Information before using it		willing to retrieve the PvD Additional Information before using it
	without leaking identity information, SHOULD make use of an IPv6		without leaking identity information, SHOULD make use of an IPv6
	skipping to change at page 22, line 5 ¶		skipping to change at page 22, line 19 ¶
	allowed to communicate with. In such scenarios, the host SHOULD		allowed to communicate with. In such scenarios, the host SHOULD
	check that the provided PvD ID, as well as the IP address that it		check that the provided PvD ID, as well as the IP address that it
	resolves into, are part of the allowed whitelist.		resolves into, are part of the allowed whitelist.
	8. IANA Considerations		8. IANA Considerations
	Upon publication of this document, IANA is asked to remove the		Upon publication of this document, IANA is asked to remove the
	'reclaimable' tag off the value 21 for the PvD Option (from the IPv6		'reclaimable' tag off the value 21 for the PvD Option (from the IPv6
	Neighbor Discovery Option Formats registry).		Neighbor Discovery Option Formats registry).
	IANA is asked to assign the value "pvd" from the Well-Known URIs		8.1. New entry in the Well-Known URIs Registry
	registry.
	8.1. Additional Information PvD Keys Registry		IANA is asked to add a new entry in the well-known-uris registry with
			the following information:
			URI suffix: 'pvd'
			Change controller: IETF
			Specification document: this document
			Status: permanent
			Related information: N/A
			8.2. Additional Information PvD Keys Registry
	IANA is asked to create and maintain a new registry called		IANA is asked to create and maintain a new registry called
	"Additional Information PvD Keys", which will reserve JSON keys for		"Additional Information PvD Keys", which will reserve JSON keys for
	use in PvD additional information. The initial contents of this		use in PvD additional information. The initial contents of this
	registry are given in Section 4.3.		registry are given in Section 4.3.
	New assignments for Additional Information PvD Keys Registry will be		New assignments for Additional Information PvD Keys Registry will be
	administered by IANA through Expert Review [RFC8126].		administered by IANA through Expert Review [RFC8126].
	8.2. PvD Option Flags Registry		8.3. PvD Option Flags Registry
	IANA is also asked to create and maintain a new registry entitled		IANA is also asked to create and maintain a new registry entitled
	"PvD Option Flags" reserving bit positions from 0 to 15 to be used in		"PvD Option Flags" reserving bit positions from 0 to 15 to be used in
	the PvD Option bitmask. Bit position 0, 1 and 2 are reserved by this		the PvD Option bitmask. Bit position 0, 1 and 2 are reserved by this
	document (as specified in Figure 1). Future assignments require		document (as specified in Figure 1). Future assignments require
	Standards Action [RFC8126], via a Standards Track RFC document.		Standards Action [RFC8126], via a Standards Track RFC document.
	8.3. PvD JSON Media Type Registration		8.4. PvD JSON Media Type Registration
	This document registers the media type for PvD JSON text,		This document registers the media type for PvD JSON text,
	"application/pvd+json".		"application/pvd+json".
	Type Name: application		Type Name: application
	Subtype Name: pvd+json		Subtype Name: pvd+json
	Required parameters: None		Required parameters: None
	skipping to change at page 23, line 20 ¶		skipping to change at page 23, line 47 ¶
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: None		Restrictions on usage: None
	Author: IETF		Author: IETF
	Change controller: IETF		Change controller: IETF
	9. Acknowledgments		9. Acknowledgments
	Many thanks to M. Stenberg and S. Barth for their earlier work:		Many thanks to M. Stenberg and S. Barth for their earlier work:
	[I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was		[I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was
	author of an early version of this document.		author of an early version of this document.
	Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen		Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen
	Cao, Tim Chown, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer,		Cao, Tim Chown, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer,
	Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted		Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted
	Lemon, Paul Hoffman, Dave Thaler, Suresh Krishnan, Gorry Fairhurst,		Lemon, Paul Hoffman, Dave Thaler, Suresh Krishnan, Gorry Fairhurst,
	Jen Lenkova, Veronika McKillop, Mark Townsley and James Woodyatt for		Jen Lenkova, Veronika McKillop, Mark Townsley and James Woodyatt for
	useful and interesting discussions and reviews.		useful and interesting discussions and reviews.
	Finally, special thanks to Thierry Danis and Wenqin Shao for their		Finally, special thanks to Thierry Danis for his valuable inputs and
	valuable inputs and implementation efforts, Tom Jones for his		implementation efforts, Tom Jones for his integration effort into the
	integration effort into the NEAT project and Rigil Salim for his		NEAT project and Rigil Salim for his implementation work.
	implementation work.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
			[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
			RFC 2131, DOI 10.17487/RFC2131, March 1997,
			<https://www.rfc-editor.org/info/rfc2131>.
			[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
			Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
			<https://www.rfc-editor.org/info/rfc3339>.
	[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic		[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
	Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,		Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
	DOI 10.17487/RFC3646, December 2003,		DOI 10.17487/RFC3646, December 2003,
	<https://www.rfc-editor.org/info/rfc3646>.		<https://www.rfc-editor.org/info/rfc3646>.
			[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
			More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
			November 2005, <https://www.rfc-editor.org/info/rfc4191>.
	[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case		[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
	Insensitivity Clarification", RFC 4343,		Insensitivity Clarification", RFC 4343,
	DOI 10.17487/RFC4343, January 2006,		DOI 10.17487/RFC4343, January 2006,
	<https://www.rfc-editor.org/info/rfc4343>.		<https://www.rfc-editor.org/info/rfc4343>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<https://www.rfc-editor.org/info/rfc4861>.		<https://www.rfc-editor.org/info/rfc4861>.
			[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
			Extensions for Stateless Address Autoconfiguration in
			IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
			<https://www.rfc-editor.org/info/rfc4941>.
			[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
			"Default Address Selection for Internet Protocol Version 6
			(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
			<https://www.rfc-editor.org/info/rfc6724>.
	[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,		[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
	DOI 10.17487/RFC7493, March 2015,		DOI 10.17487/RFC7493, March 2015,
	<https://www.rfc-editor.org/info/rfc7493>.		<https://www.rfc-editor.org/info/rfc7493>.
			[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
			Hosts in a Multi-Prefix Network", RFC 8028,
			DOI 10.17487/RFC8028, November 2016,
			<https://www.rfc-editor.org/info/rfc8028>.
			[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
			"IPv6 Router Advertisement Options for DNS Configuration",
			RFC 8106, DOI 10.17487/RFC8106, March 2017,
			<https://www.rfc-editor.org/info/rfc8106>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,		DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers		[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
	(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,		(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
	<https://www.rfc-editor.org/info/rfc8615>.		<https://www.rfc-editor.org/info/rfc8615>.
	10.2. Informative References		10.2. Informative References
	skipping to change at page 24, line 44 ¶		skipping to change at page 26, line 14 ¶
	[I-D.stenberg-mif-mpvd-dns]		[I-D.stenberg-mif-mpvd-dns]
	Stenberg, M. and S. Barth, "Multiple Provisioning Domains		Stenberg, M. and S. Barth, "Multiple Provisioning Domains
	using Domain Name System", draft-stenberg-mif-mpvd-dns-00		using Domain Name System", draft-stenberg-mif-mpvd-dns-00
	(work in progress), October 2015.		(work in progress), October 2015.
	[IEEE8021X]		[IEEE8021X]
	"IEEE Standards for Local and Metropolitan Area Networks,		"IEEE Standards for Local and Metropolitan Area Networks,
	Port-based Network Access Control, IEEE Std", n.d..		Port-based Network Access Control, IEEE Std", n.d..
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, DOI 10.17487/RFC2131, March 1997,
	<https://www.rfc-editor.org/info/rfc2131>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<https://www.rfc-editor.org/info/rfc3339>.
	[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,		[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", RFC 3971,		"SEcure Neighbor Discovery (SEND)", RFC 3971,
	DOI 10.17487/RFC3971, March 2005,		DOI 10.17487/RFC3971, March 2005,
	<https://www.rfc-editor.org/info/rfc3971>.		<https://www.rfc-editor.org/info/rfc3971>.
	[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
	More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
	November 2005, <https://www.rfc-editor.org/info/rfc4191>.
	[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery		[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
	Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April		Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
	2006, <https://www.rfc-editor.org/info/rfc4389>.		2006, <https://www.rfc-editor.org/info/rfc4389>.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
	<https://www.rfc-editor.org/info/rfc4941>.
	[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.		[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
	Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,		Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
	DOI 10.17487/RFC6105, February 2011,		DOI 10.17487/RFC6105, February 2011,
	<https://www.rfc-editor.org/info/rfc6105>.		<https://www.rfc-editor.org/info/rfc6105>.
	[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful		[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
	NAT64: Network Address and Protocol Translation from IPv6		NAT64: Network Address and Protocol Translation from IPv6
	Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,		Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
	April 2011, <https://www.rfc-editor.org/info/rfc6146>.		April 2011, <https://www.rfc-editor.org/info/rfc6146>.
	[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van		[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
	Beijnum, "DNS64: DNS Extensions for Network Address		Beijnum, "DNS64: DNS Extensions for Network Address
	Translation from IPv6 Clients to IPv4 Servers", RFC 6147,		Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
	DOI 10.17487/RFC6147, April 2011,		DOI 10.17487/RFC6147, April 2011,
	<https://www.rfc-editor.org/info/rfc6147>.		<https://www.rfc-editor.org/info/rfc6147>.
	[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix		[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
	Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,		Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
	<https://www.rfc-editor.org/info/rfc6296>.		<https://www.rfc-editor.org/info/rfc6296>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<https://www.rfc-editor.org/info/rfc6724>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6		[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
	/64 Prefix from a Third Generation Partnership Project		/64 Prefix from a Third Generation Partnership Project
	(3GPP) Mobile Interface to a LAN Link", RFC 7278,		(3GPP) Mobile Interface to a LAN Link", RFC 7278,
	DOI 10.17487/RFC7278, June 2014,		DOI 10.17487/RFC7278, June 2014,
	<https://www.rfc-editor.org/info/rfc7278>.		<https://www.rfc-editor.org/info/rfc7278>.
	[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain		[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
	Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,		Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
	<https://www.rfc-editor.org/info/rfc7556>.		<https://www.rfc-editor.org/info/rfc7556>.
	[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
	Hosts in a Multi-Prefix Network", RFC 8028,
	DOI 10.17487/RFC8028, November 2016,
	<https://www.rfc-editor.org/info/rfc8028>.
	[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
	"IPv6 Router Advertisement Options for DNS Configuration",
	RFC 8106, DOI 10.17487/RFC8106, March 2017,
	<https://www.rfc-editor.org/info/rfc8106>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., Lemon, T., and T. Winters,		Richardson, M., Jiang, S., Lemon, T., and T. Winters,
	"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
	RFC 8415, DOI 10.17487/RFC8415, November 2018,		RFC 8415, DOI 10.17487/RFC8415, November 2018,
	<https://www.rfc-editor.org/info/rfc8415>.		<https://www.rfc-editor.org/info/rfc8415>.
	[URN] "URN Namespaces", n.d..		[URN] "URN Namespaces", n.d..
	Authors' Addresses		Authors' Addresses
	Pierre Pfister		Pierre Pfister
	Cisco		Cisco
	11 Rue Camille Desmoulins		11 Rue Camille Desmoulins
	Issy-les-Moulineaux 92130		Issy-les-Moulineaux 92130
	France		France
	Email: ppfister@cisco.com		Email: ppfister@cisco.com
	Eric Vyncke		Eric Vyncke
	Cisco		Cisco
End of changes. 38 change blocks.
	88 lines changed or deleted		113 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/