< draft-bruneau-intarea-provisioning-domains-00.txt		draft-bruneau-intarea-provisioning-domains-01.txt >
	intarea B. Bruneau		intarea B. Bruneau
	Internet-Draft Ecole polytechnique		Internet-Draft Ecole Polytechnique
	Intended status: Informational P. Pfister		Intended status: Informational P. Pfister
	Expires: September 14, 2017 Cisco		Expires: January 1, 2018 Cisco
	D. Schinazi		D. Schinazi
	T. Pauly		T. Pauly
	Apple		Apple
	E. Vyncke, Ed.		E. Vyncke
	Cisco		Cisco
	March 13, 2017		June 30, 2017
	Proposals to discover Provisioning Domains		Discovering Provisioning Domain Names and Data
	draft-bruneau-intarea-provisioning-domains-00		draft-bruneau-intarea-provisioning-domains-01
	Abstract		Abstract
	This document describes one possible way for hosts to retrieve		An increasing number of hosts and networks are connected to the
	additional information about their Internet access configuration.		Internet through multiple interfaces, some of which may provide
	The set of configuration items required to access the Internet is		multiple ways to access the internet by the mean of multiple IPv6
	called a Provisioning Domain (PvD) and is identified by a Fully		prefix configurations.
	Qualified Domain Name.
	This document separates the way of getting the Provisioning Domain		This document describes a way for hosts to retrieve additional
	identifier, the way of getting the Provisioning Domain information		information about their network access characteristics. The set of
	and the potential information contained in the Provisioning Domain.		configuration items required to access the Internet is called a
			Provisioning Domain (PvD) and is identified by a Fully Qualified
			Domain Name (FQDN). This identifier, retrieved using a new Router
			Advertisement (RA) option, is associated with the set of information
			included within the RA and may later be used to retrieve additional
			information associated to the PvD by the mean of an HTTP request.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 14, 2017.		This Internet-Draft will expire on January 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		3. Provisioning Domain Identification using Router
	3. Retrieving the PvD ID . . . . . . . . . . . . . . . . . . . . 4		Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Using One Router Advertisement per PvD . . . . . . . . . 4		3.1. PvD ID Option for Router Advertisements . . . . . . . . . 4
	3.2. Rationale for not selecting other techniques . . . . . . 5		3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 5
	3.2.1. Using DNS-SD . . . . . . . . . . . . . . . . . . . . 5		3.3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 5
	3.2.2. Using Reverse DNS lookup . . . . . . . . . . . . . . 5		3.3.1. DHCPv6 configuration association . . . . . . . . . . 6
	3.3. IoT Considerations . . . . . . . . . . . . . . . . . . . 6		3.3.2. DHCPv4 configuration association . . . . . . . . . . 7
	3.4. Linking IPv4 Information to an IPv6 PvD . . . . . . . . . 6		3.3.3. Interconnection Sharing by the Host . . . . . . . . . 7
	4. Getting the full set of PvD information . . . . . . . . . . . 6		4. Provisioning Domain Identification using IKEv2 . . . . . . . 7
	4.1. Using the PvD Bootstrap Information Option . . . . . . . 7		5. Provisioning Domain Additional Information . . . . . . . . . 8
	4.2. Downloading a JSON file over HTTPS . . . . . . . . . . . 7		5.1. Retrieving the PvD Additional Information . . . . . . . . 9
	4.2.1. Advantages . . . . . . . . . . . . . . . . . . . . . 7		5.2. Providing the PvD Additional Information . . . . . . . . 10
	4.2.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 8		5.3. PvD Additional Information Format . . . . . . . . . . . . 10
	4.3. Using DNS TXT ressource records (not selected) . . . . . 8		5.3.1. Connectivity Characteristics Information . . . . . . 12
	4.3.1. Advantages . . . . . . . . . . . . . . . . . . . . . 8		5.3.2. Private Extensions . . . . . . . . . . . . . . . . . 12
	4.3.2. Disadvantages . . . . . . . . . . . . . . . . . . . . 8		5.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3.3. Using DNS SRV ressource records . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	5. PvD Information . . . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	5.1. PvD Name . . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Trust of the bootstrap PvD . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.3. Reachability . . . . . . . . . . . . . . . . . . . . . . 11		9.1. Normative references . . . . . . . . . . . . . . . . . . 14
	5.4. DNS Configuration . . . . . . . . . . . . . . . . . . . . 12		9.2. Informative references . . . . . . . . . . . . . . . . . 15
	5.5. Connectivity Characteristics . . . . . . . . . . . . . . 13		Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 16
	5.6. Connection monetary cost . . . . . . . . . . . . . . . . 14		A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 16
	5.6.1. Conditions . . . . . . . . . . . . . . . . . . . . . 15		A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 16
	5.6.2. Price . . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Connection monetary cost . . . . . . . . . . . . . . 17
	5.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . 16		B.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 17
	5.7. Private Extensions . . . . . . . . . . . . . . . . . . . 17		B.2. Price . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17		B.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19
	5.8.1. Using JSON . . . . . . . . . . . . . . . . . . . . . 17
	5.8.2. Using DNS TXT records . . . . . . . . . . . . . . . . 18
	6. Use case examples . . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 19
	6.2. VPN/Extranet example . . . . . . . . . . . . . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative references . . . . . . . . . . . . . . . . . . 19
	9.2. Informative references . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	It has become very common in modern networks that hosts have Internet		It has become very common in modern networks that hosts have Internet
	or more specific access through different networking interfaces,		or more specific network access through different networking
	tunnels, or next-hop routers. The concept of Provisioning Domain		interfaces, tunnels, or next-hop routers. The concept of
	(PvD) was defined in RFC7556 [RFC7556] as a set of network		Provisioning Domain (PvD) was defined in [RFC7556] as a set of
	configuration information which can be used by hosts in order to		network configuration information which can be used by hosts in order
	access the network. In this document, PvDs are associated with a		to access the network.
	Fully Qualified Domain Name (called PvD ID) which is used within the
	host to identify correlated sets of configuration data and also used		In this document, PvDs are identified by Fully Qualified Domain Names
	to retrieve additional information about the services that the		called PvD IDs, which are included in Router Advertisements [RFC4861]
	network provides.		as a new option and are used to identify correlated sets of network
			configuration data.
	Devices connected to the Internet through multiple interfaces would		Devices connected to the Internet through multiple interfaces would
	typically be provisioned with one PvD per interface, but it is worth		typically be provisioned with one PvD per interface, but it is worth
	noting that multiple PvDs with different PvD IDs could be provisioned		noting that multiple PvDs with different PvD IDs could be provisioned
	on any host interface, as well as noting that the same PvD ID could		on any host interface, as well as noting that the same PvD ID could
	be used on different interfaces in order to inform the host that both		be used on different interfaces in order to inform the host that both
	PvDs, on different interfaces, ultimately provide equivalent		PvDs, on different interfaces, ultimately provide identical services.
	services.
	This document proposes multiple methods allowing the host to to		This document also introduces a way for hosts to retrieve additional
	retrieve the PvD ID associated with a set of networking discover the		information related to a specific PvD by the mean of an HTTP-over-TLS
	PvD and retrieve the PvD information. It also explains configuration		query using an URI derived from the PvD ID. The retrieved JSON
	as well as the methods and format in order to retrieve some of the		object contains additional network information that would typically
	parameters that can describe a PvD.		be considered unfit, or too large, to be directly included in the
			Router Advertisements. This information can be used by the
			networking stack, the applications, or even be partially displayed to
			the users (e.g., by displaying a localized network service name).
	2. Terminology		2. Terminology
	PvD A provisioning domain, usually with a set of
	provisioning domain information; for more
	information, see [RFC7556].
	2.1. Requirements Language
	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 RFC		"OPTIONAL" in this document are to be interpreted as described in
	2119 [RFC2119].		[RFC2119].
	3. Retrieving the PvD ID
	In this document, each provisioning domain is identified by a PvD ID.
	The PvD ID is a Fully Qualified Domain Name which belongs to the
	network operator to avoid conflicts among network operators. The
	same PvD ID can exist in several access networks if the set of
	configuration information is identical in all those networks (such as
	in all home networks of a residential subscriber). Within a host,
	the PvD ID SHOULD be associated to all the configuration information
	associated to this PvD ID; this allows for easy update and removal of
	information while keeping a consistent state.
	This section assumes that IPv6 Router Advertisements are used to		In addition, this document uses the following terminology:
	discover the PvD ID and explains why this technique was selected.
	3.1. Using One Router Advertisement per PvD		PvD: A Provisioning Domain, a set of network configuration
			information; for more information, see [RFC7556].
	Hosts receive implicit PvDs by the means of Router Advertisements		PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a
	(RA).		PvD.
	A router MAY add a single PvD ID Option in its RAs. The PvD ID		Explicit PvD: A PvD uniquely identified with a PvD ID.
	specified in this option is then associated with all the Prefix
	Information Options (PIO) included in the RA (albeit it is expected
	that only one PIO will be included in the RA). All other information
	contained in the RA (notably the RDNSS and Route Information Option)
	are to be associated with the PvD ID. The set of information
	contained in the RA forms the bootstrap (or hint) PvD. A new RA
	option will be required to convey the PvD ID.
	When a host receives an RA which does not include a PvD ID Option,		Implicit PvD: A PvD associated with a set of configuration
	the set of information included in the RA (such as Recursive DNS		information that, in the absence of a PvD ID, is associated with
	server, IPv6 prefix) is attached to an implicit PvD identified by the		the advertising router.
	local interface ID on which the RA is received, and by the link-local
	address of the router sending the RA.
	In the cases where a router should provide multiple independent PvDs		3. Provisioning Domain Identification using Router Advertisements
	to all hosts, including non-PvD aware hosts, it should send multiple
	RAs, as proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming]
	using different source link-local addresses (LLA); the datalink layer
	(MAC) address could be the same for all the different RA. If the
	router is actually a VRRP instance, then the procedure is identical
	except that the virtual link-layer address is used as well as virtual
	link-layer addresses.
	Using RA allows for an early discovery of the PvD ID as it is early		Each provisioning domain is identified by a PvD ID. The PvD ID is a
	in the interface start-up. As RA is usually processed in the kernel,		Fully Qualified Domain Name (FQDN) which MUST belong to the network
	this requires a host OS upgrade. The RA SHOULD contain other PvD		operator in order to avoid ambiguity. The same PvD ID MAY be used in
	information as explained in section Section 4.1.		several access networks if the set of configuration information is
			identical (e.g. in all home networks subscribed to the same service).
	3.2. Rationale for not selecting other techniques		3.1. PvD ID Option for Router Advertisements
	There are other techniques to discover the PvD ID that were not		This document introduces a new Router Advertisement (RA) option
	selected by the authors and reviewers, this section explains why.		called the PvD ID Router Advertisement Option, used to convey the
	The design goal was to be as reliable as possible (do not depend on		FQDN identifying a given PvD.
	Internet connectivity) and as fast as possible.
	3.2.1. Using DNS-SD		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length | Seq |H|L| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Lifetime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| PvD ID FQDN |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For each received RA including a RDNSS option as well as a DNS search		PvD ID Router Advertisements Option format
	list option, the host MAY retrieve the PvD ID by querying the
	configured DNS server for records of type PTR associated with
	_pvd.<DNS search name>. If a PvD ID is configured, the DNS recursive
	resolver MUST reply with the PvD ID as a PTR record. NXDOMAIN is
	returned otherwise.
	When the RDNSS address is link-local, the host MAY retrieve the PvD		Type : (8 bits) To be defined by IANA.
	ID before configuring its global scope address(es).
	Relying on a valid DNS service at the interface bootstrap can lead		Length : (8 bits) The length of the option (including the Type
	into delay to start the interface or starting without enough		and Length fields) in units of 8 octets.
	information: for example when the RDNSS is a non local address and
	there is no Internet connectivity.
	3.2.2. Using Reverse DNS lookup		Seq : (4 bits) Sequence number for the PvD Additional
			Information, as described in Section 5.
	[I-D.stenberg-mif-mpvd-dns] proposes a solution to get the name of		H-flag : (1 bit) Whether some PvD Additional Information is
	the PvD using a reverse DNS lookup based on the host global		made available through HTTP over TLS, as described in Section 5.
	address(es). It merely relies on prepending a well-known prefix
	'_pvd' to the reverse lookup, for example ' _pvd....ip6.arpa.'.
	However, the PvD information is typically provided by the network		L-flag : (1 bit) Whether the router is also providing IPv4
	operator, whereas the reverse DNS zone could be delegated from the		access using DHCPv4 (see Section 3.3.2).
	operator to the network user, in which case it would not work.
	It also requires a fully functional global address to retrieve the		Reserved : (10 bits) Reserved for later use. It MUST be set to
	information which may be too late for a correct host configuration.		zero by the sender and ignored by the receiver.
	One advantage is that it does not require any change in the IPv6
	protocol and no change in the host kernel or even in the CPE.
	3.3. IoT Considerations		Lifetime : (32 bits) The length of time in seconds (relative to
			the time the packet is sent) that the PvD ID option is valid. A
			value of all one bits (0xffffffff) represents infinity.
	TBD: should state that when end-host (IoT) cannot impletement		PvD ID FQDN : The FQDN used as PvD ID in DNS binary format
	completely this RFC it MAY select any of the PvD or the router SHOULD		[RFC1035], padded until the next 8 octets boundary. All the bytes
	send a single unicast RA (hence a single PvD) in response to the RS		after the first empty DNS label MUST be set to zero by the sender
	or none if it detects that it cannot offer the right set of network		and MUST be ignored by the receiver. The DNS name compression
	services.		technique described in [RFC1035] MUST NOT be used.
	3.4. Linking IPv4 Information to an IPv6 PvD		Routers MUST NOT include more than one PvD ID Router Advertisement
			Option in each RA. In case multiple PvD ID options are found in a
			given RA, hosts MUST ignore all but the first PvD ID option.
	The document describes IPv6-only PvD but there are multiple ways to		Note: The existence and/or size of the sequence number is subject to
	link the set of IPv4 configuration information received by DHCPv4:		discussion. The validity of a PvD Additional Information object is
			included in the object itself, but this only allows for 'pull based'
			updates, whereas the RA options usually provide 'push based' updates.
	o correlation based on the data-link layer address of the source, if		Note: including the lifetime option is congruent with the lifetime
	the IPv6 RA and the DHCPv4 response have the same data-link layer		option of the other RA option. On the other hand, do we need it ?
	address, then the information contained in the IPv4 DHCP can be
	linked to the IPv6 PvD;
	o correlation based on the interface when there is no data-link		3.2. Router Behavior
	address on the link (such as a 3GPP link), then the information
	contained in the IPv4 PDP context can be linked to the IPv6 PvD
	(*** TO BE VERIFIED before going -01);
	o correlation based on the DNS search list, if the DNS search lists		A router MAY insert at most one PvD ID Option in its RAs. The
	are identical between the IPv6 RDNSS and the DHCPV4 response, then		included PvD ID is associated with all the other options included in
	the information contained in the IPv4 DHCP response can be linked		the same RA (e.g., Prefix Information [RFC4861], Recursive DNS Server
	to the IPv6 PvD.		[RFC6106], Routing Information [RFC4191], Captive Portal [RFC7710]
			options).
	The correlation could be useful for some PvD information such as		In order to provide multiple independent PvDs, a router MUST send
	Internet reachability, use of captive portal, display name of the		multiple RAs using different source link-local addresses (LLA) (as
	PvD, ...		proposed in [I-D.bowbakova-rtgwg-enterprise-pa-multihoming]), each of
			which MAY include a PvD ID option. In such cases, routers MAY
			originate the different RAs using the same datalink layer address.
	In cases where the IPv4 configuration information could not be		If the router is actually a VRRP instance [RFC5798], then the
	associated with a PvD, hosts MUST consider it as attached to an		procedure is identical except that the virtual datalink layer address
	independent implicit PvD containing no other information than what is		is used as well as virtual IPv6 addresses.
	provided through DHCPv4.
	4. Getting the full set of PvD information		3.3. Host Behavior
	Once the PvD ID is known, it MAY be used to retrieve additional		RAs are used to configure IPv6 hosts. When a host receives a RA
	information. PvD Information is modeled as a key-value dictionary		message including a PvD ID Option with a non-zero lifetime, it MUST
	which keys are ASCII strings of arbitrary length, and values are		associate all the configuration options included in the RA (e.g.,
	either strings (encoding can vary), ordered list of values		Prefix Information [RFC4861], Recursive DNS Server [RFC6106], Routing
	(recursively), or a dictionary (recursively).		Information [RFC4191], Captive Portal [RFC7710] options) with the PvD
			ID).
	The PvD Information may be retrieved from multiple sources (from the		If the received RA does not include a PvD ID Option, or whenever the
	bootstrap PvD contained in the RA to the secondary/extended PvD		included PvD ID Option has a lifetime set to zero, the host MUST
	described in this section); the PvD ID is then used to correlate the		associate the options included in the RA with an implicit PvD. This
	information from different sources. The way a host should operate		implicit PvD is identified by the link-local address of the router
	when receiving conflicting information is TBD but it SHOULD at least		sending the RA and the interface on which the RA was received.
	override information from less authenticated sources (RA) by more
	authenticated sources (via TLS).
	4.1. Using the PvD Bootstrap Information Option		This document does not update the way Router Advertisement options
			are processed. But in addition to the option processing defined in
			other documents, hosts implementing this specification MUST associate
			each created or updated object (e.g. address, default route, more
			specific route, DNS server list) with the PvD associated with the
			received RA as well as the interface and link-local address of the
			router which last updated the object.
	Routers MAY transmit, in addition to the PvD ID option, a PvD		Each configuration object has a PvD validity timer set to the PvD ID
	Bootstrap Information option, containing a first subset of PvD		option lifetime whenever an RA that updates the object is received.
	information. The additional pieces of bootstrap PvD information data		If the received RA does not include a PvD ID option, or whenever the
	set are transmitted using the short-hand notation proposed in		PvD ID option lifetime is zero, the associated objects are
	Section 5. This requires another RA option.		immediately associated with an implicit PvD, as mentioned in the
			previous paragraph. Similarly, whenever an object's PvD timer
			reaches zero, the object is immediately associated with an implicit
			PvD identified by the link-local address and interface of the router
			which last updated the object.
	As there is a size limit on the amount of information a single RA can		While resolving names, executing the default address selection
	convey, it is likely that the PvD Bootstrap Information option may		algorithm [RFC6724] or executing the default router selection
	not contain the whole set of PvD Information. The set of PvD		algorithm ([RFC2461], [RFC4191] and [RFC8028]), hosts MAY consider
	information included in the RA is called PvD Bootstrap Information.		only the configuration associated with an arbitrary set of PvDs.
	4.2. Downloading a JSON file over HTTPS		For example, a host MAY associate a given process with a specific
			PvD, or a specific set of PvDs, while associating another process
			with another PvD. A PvD-aware application might also be able to
			select, on a per-connection basis, which PvDs should be used for a
			given connection. And particularly constrained devices such as small
			battery operated devices (e.g. IoT), or devices with limited CPU or
			memory resources may purposefully use a single PvD while ignoring
			some received RAs containing different PvD IDs.
	The host SHOULD try to download a JSON formatted file over HTTPS in		The way an application expresses its desire to use a given PvD, or a
	order to get more PvD information.		set of PvDs, or the way this selection is enforced, is out of the
			scope of this document. Useful insights about these considerations
			can be found in [I-D.kline-mif-mpvd-api-reqs].
	The host MUST perform an HTTP query to https://<PvD-ID>/v1.json. If		3.3.1. DHCPv6 configuration association
	the HTTP status of the answer is greater than 400 the host MUST
	abandon and consider that there is no additional PvD information. If
	the HTTP status of the answer is between 300 and 400 it MUST follow
	the redirection(s). If the HTTP status of the answer is between 200
	and 300 the host MAY get a file containing a single JSON object.
	The host MUST respect the cache information in the HTTP header, if		When a host retrieves configuration information from DHCPv6, the
	any, and at expiration of the downloaded object, it must fetch a		configured elements MUST be associated with the explicit or implicit
	fresher version if any.		PvD of the RA received on the same interface with the O-flag set
	4.2.1. Advantages		[RFC4861]. If multiple RAs with the O-flag set and associated with
			different PvDs are received on the same interface, the link-local
			address of the DHCPv6 server MAY be compared with the routers' link-
			local addresses in order to disambiguate. If the disambiguation is
			impossible, then the DHCPv6 configuration information MUST be
			associated with an implicit PvD.
	The JSON format allows advanced structures.		This process requires hosts to keep track of received RAs, associated
			PvD IDs, and routers link-local addresses.
	It can be secured using HTTPS (and DNSSEC).		3.3.2. DHCPv4 configuration association
	It is easier to update a file on a web server than to edit DNS		When a host retrieves configuration from DHCPv4 on an interface, the
	records. It can be especially important if we want providers to be		configured elements MUST be associated with the explicit PvD,
	able to often update the remaining phone plan of the user.		received on the same interface, whose PVD ID Options L-flag is set.
			If multiple different PvDs are found, the datalink layer address used
			by the DHCPv4 server/relay MAY be compared with the datalink layer
			address used by on-link advertising routers in order to disambiguate.
			If no RA associated with a PvD ID option with the L-flag set is
			found, or if the disambiguation fails, the IPv4 configuration
			information MUST be associated with an implicit PvD.
	4.2.2. Disadvantages		3.3.3. Interconnection Sharing by the Host
	It is slower than using DNS because HTTPS uses TCP and TLS and needs		The situation when a host becomes also a router by acting as a router
	more packets to be exchanged to get the file.		or ND proxy on a different interface (such as WiFi) to share the
			connectivity of another interface (such as cellular), also known as
			"tethering" is TBD but it is expected that the one or several PvD
			associated to the shared interface will be also advertised to the
			clients.
	An additional HTTPS server must be deployed and configured.		4. Provisioning Domain Identification using IKEv2
	4.3. Using DNS TXT ressource records (not selected)		RFC 7296 defines Internet Key Exchange version 2 (IKEv2) which
			includes in sections 2.19 and 3.15 a Configuration Payload (CP) which
			may be used by an IPsec client to request configuration items (e.g.,
			addresses, recursive DNS servers). IKEv2 also negatiates traffic
			selectors which represent the 5-tuple(s) to be protected by the
			Security Association (SA) negotiated by IKEv2. This set of
			information is another PvD and may include INTERNAL_IP6_ADDRESS,
			INTERNAL_IP6_LINK, INTERNAL_IP6_SUBNET (to be used to route traffic
			to this subent), INTERNAL_IP6_DNS, INTERNAL_DNS_DOMAIN.
	This approach was not selected during the design team meeting but has		The PvD ID Configuration option for IKEv2 has the following structure
	kept here for reference, it will be removed after global consensus is		(similar to the RA option):
	reached.
	The host could perform a DNS query for TXT resource records (RR) for		0 1 2 3
	the FQDN used as PvD ID (alternatively for _pvd.<PvD-ID>). For each		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
	retrieved PvD ID, the DNS query MUST be sent to the DNS server		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	configured from the same router advertisement as the PvD ID. Syntax		|R| Attribute Type | Length |
	of the TXT response is defined in Section 5 (Section 5).		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Seq |H|L| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Lifetime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| PvD ID FQDN |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	4.3.1. Advantages		PvD ID IKEv2 Configuration Payload Attributes format
	It requires a single round-time trip in order to retrieve the PvD		R-bit Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
	Information.
	It can be secured using DNSSEC.		Attribute Type (15 bits) tbd by IANA PVD_ID.
	4.3.2. Disadvantages		Length Length (2 octets, unsigned integer) - Length of PvD ID FQDN +
			2.
	A TXT record is limited to 65535 characters in theory but large size		Seq Sequence number (4 bits) for the PvD Additional Information, as
	of TXT records could require either DNS over TCP (so loosing the		described in Section 5.
	1-RTT advantage) or fragmented UDP packets (which could be dropped by
	a bad choice of security policy). Large TXT records could also be
	used to mount an amplification attack.
	4.3.3. Using DNS SRV ressource records		H-flag (1 bit) Whether some PvD Additional Information is made
			available through HTTP over TLS, as described in Section 5.
	It is expected that the DNS TXT records will be sufficient for the		L-flag (1 bit) must be set to 0 if the Configuration Payload
	host to configure itself with basic networking and policy		contains only IPv6 information, else it must be set to 1.
	configuration. Nevertheless, if further information is required, or
	when a different security model shall be used to access the PvD
	Information, a SRV Resource Record including a full URL MAY be
	included as a response, expecting the host to query this URL in order
	to retrieve additional PvD information.
	5. PvD Information		Reserved (10 bits) Reserved for later use. It MUST be set to zero
			by the sender and ignored by the receiver.
	PvD information is a set of key-value pairs. Keys are ASCII		PvD ID FQDN The FQDN used as PvD ID in DNS binary format [RFC1035],
	character strings. Values are either a character string, an ordered		padded until the next 8 octets boundary. All the bytes after the
	list of values, or an embedded dictionary. Value types and default		first empty DNS label MUST be set to zero by the sender and MUST
	behavior with respect to some specific keys MAY be further specified		be ignored by the receiver. The DNS name compression technique
	(recursively). Some keys have a default value as described in the		described in [RFC1035] MUST NOT be used.
	following sections. When there is an expiration time in a PvD, then
	the information MUST be refreshed before the expiration time. The
	behavior of a host when the refresh operation is not successful is
	TBD.
	Nodes using the PvD MUST support the two encodings:		5. Provisioning Domain Additional Information
	JSON syntax for the complete set of PvD information;		Once a new PvD ID is discovered, it may be used to retrieve
			additional information about the characteristics of the provided
			connectivity. This set of information is called PvD Additional
			Information, and is encoded as a JSON object [RFC7159].
	short-hand notation for the bootstrap PvD.		The purpose of this additional set of information is to securely
			provide additional information to hosts about the connectivity that
			is provided using a given interface and source address pair. It
			typically includes data that would be considered too large, or not
			critical enough, to be provided with an RA option. The information
			contained in this object MAY be used by the operating system, network
			libraries, applications, or users, in order to decide which set of
			PvDs should be used for which connection, as described in
			Section 3.3.
	When the PvD information is transferred as a JSON file, then the key		5.1. Retrieving the PvD Additional Information
	used is the second column of the following table. The syntax of the
	JSON file is obvioulsy JSON and is richer than the short-hand
	notation specified in the next paragraph.
	When transmitting more information than the PvD ID in the RA (or when		When the H-flag of the PvD ID Option is set, hosts MAY attempt to
	DNS TXT resource records are used), the shorthand notataion for PvD		retrieve the PvD Additional Information associated with a given PvD
	information is used and consists of a string containing several		by performing an HTTP over TLS [RFC2818] GET query to https://<PvD-
	"key=value;" substrings. The "key" is the first column of the		ID>/pvd.json [RFC5785]. On the other hand, hosts MUST NOT do so
	following tables, the value is encoded as:		whenever the H-flag is not set.
	Shorthand notation for values:		Note: Should the PvD AI retrieval be a MAY or a SHOULD ? Could the
			object contain critical data, or should it only contain informational
			data ?
	integer: expressed in decimal format with a '.' (dot) used for		Note that the DNS name resolution of <PvD-ID> as well as the actual
	decimals;		query MUST be performed in the PvD context associated to the PvD ID.
			In other words, the name resolution, source address selection, as
			well as the next-hop router selection MUST be performed while using
			exclusively the set of configuration information attached with the
			PvD, as defined in Section 3.3.
	string: expressed as UTF-8 encoded string, delimited by single		If the HTTP status of the answer is greater than or equal to 400 the
	quote character, the single quote character can be expressed by		host MUST abandon and consider that there is no additional PvD
	two consecutive single quote character;		information. If the HTTP status of the answer is between 300
			included and 399 included it MUST follow the redirection(s). If the
			HTTP status of the answer is between 200 included and 299 included
			the host MAY get a file containing a single JSON object. When a JSON
			object could not be retrieved, an error message SHOULD be logged and/
			or displayed in a rate-limited fashion.
	boolean: expressed as '0' for false and '1' for true;		After retrieval of the PvD Additional Information, hosts MUST watch
			the PvD ID Seq field for change. In case a different value than the
			one in the RA Seq field is observed, or whenever the validity time
			included in the object is expired, hosts MUST either perform a new
			query and retrieve a new version of the object, or deprecate the
			object and stop using it.
	IPv6 address: printed as RFC5952 [RFC5952].		Hosts retrieving a new PvD Additional Information object MUST check
			for the presence and validity of the mandatory fields Section 5.3. A
			retrieved object including an outdated expiration time or missing a
			mandatory element, MUST be ignored. In order to avoid traffic spikes
			toward the server hosting the PvD Additional Information when an
			object expires, a host which last retrieved an object at a time A,
			including a validity time B, SHOULD renew the object at a uniformly
			random time in the interval [(B-A)/2,A].
	5.1. PvD Name		In order to prevent PvD spoofing by malicious or misconfigured
			routers, PvD Additional Information object includes a set of IPv6
			prefixes which MUST be checked against all the Prefix Information
			Options advertised in the Router Advertisement. If any of the
			prefixes included in the Prefix Information Options is not in the set
			of prefixes contained in the additional information, the PvD (the one
			included in the RA and in the additional information) MUST be
			considered unsafe and MUST NOT be used. While this does not prevent
			a malicious network provider, it can be used to detect
			misconfiguration.
	PvD SHOULD have a human readable name in order to be presented on a		The server serving the JSON files SHOULD also check whether the
	GUI. The name can also be localized.		client address is part of the prefixes listed into the additional
			information and SHOULD return a 403 response code if there is no
			match. The server MAY also use the client address to select the
			right JSON object to be returned.
	+------------+------------+---------------+--------------+----------+		Note: In a similar way, a DNS server names list could be included in
	| DNS TXT ke | JSON key | Description | Type | JSON |		the PvD AI in order to avoid rogue APs from inserting a different DNS
	| y/Bootstra | | | | Example |		resolver. But this would also prevent CPEs from advertising
	| p PvD key | | | | |		themselves as default DNS (which is usually done). SPs which really
	+------------+------------+---------------+--------------+----------+		want to use CPEs as DNS, for caching reasons, might find 'creative'
	| n | name | User-visible | human- | "Foobar |		ways to go around this rule.
	| | | service name, | readable | Service" |
	| | | SHOULD be | UTF-8 string | |
	| | | part of the | | |
	| | | bootstrap PvD | | |
	| nl10n | localizedN | Localized | human- | "Service |
	| | ame | user-visible | readable | Blabla" |
	| | | service name, | UTF-8 string | |
	| | | language can | | |
	| | | be selected | | |
	| | | based on the | | |
	| | | HTTP Accept- | | |
	| | | Language | | |
	| | | header in the | | |
	| | | request. | | |
	+------------+------------+---------------+--------------+----------+
	5.2. Trust of the bootstrap PvD		5.2. Providing the PvD Additional Information
	The content of the bootstrap PvD (from the original RA) cannot be		Whenever the H-flag is set in the PvD RA Option, a valid PvD
	trusted as it is not authenticated. But, the extended PvD can be		Additional Information object MUST be made available to all hosts
	associated with the PvD ID (as the PvD ID is used to construct the		receiving the RA. In particular, when a captive portal is present,
	extended PvD URL) and trusted by the used of TLS. The extended PvD		hosts MUST still be allowed to access the object, even before logging
	SHOULD therefore include the following information elements and, if		into the captive portal.
	they are present, the host MUST verify that the all PIO of the RA
	fits into the master prefix list. If any PIO prefix from the
	bootstrap PvD does not fit in the master prefix array, then all
	information received by the bootstrap PvD must be invalidated. In
	short, the masterIPv6Prefix received over TLS is used to authenticate
	the bootstrap PvD.
	The values of the bootstrap PvD (RDNSS, ...) are overwritten by the		Routers MAY increment the PVD ID Sequence number (Seq) in order to
	values contained in the trusted extended PvD if they are present.		inform host that a new PvD Additional Information object is available
			and should be retrieved.
	+-----+------------------+-------------+----------+-----------------+		5.3. PvD Additional Information Format
	| DNS | JSON key | Description | Type | JSON Example |
	| TXT | | | | |
	| key | | | | |
	+-----+------------------+-------------+----------+-----------------+
	| mp6 | masterIpv6Prefix | All the | Array of | ["2001:db8::/32 |
	| | | IPv6 | IPv6 | "] |
	| | | prefixes | prefixes | |
	| | | linked to | | |
	| | | this PvD | | |
	| | | (such as a | | |
	| | | /29 for the | | |
	| | | ISP). | | |
	+-----+------------------+-------------+----------+-----------------+
	5.3. Reachability		The PvD Additional Information is a JSON object.
	The following set of keys can be used to specify the set of services		The following array presents the mandatory keys which MUST be
	for which the respective PvD should be used. If present they MUST be		included in the object:
	honored by the client, i.e., if the PvD is marked as not usable for
	Internet access (walled garden), then it MUST NOT be used for
	Internet access. If the usability is limited to a certain set of
	domain or address prefixes (typical VPN access), then a different PvD
	MUST be used for other destinations.
	+-----+---------------+---------------+-----------+-----------------+		+----------+-------------------+-----------+------------------------+
	| DNS | JSON key | Description | Type | JSON Example |		| JSON key | Description | Type | Example |
	| TXT | | | | |		+----------+-------------------+-----------+------------------------+
	| key | | | | |		| name | Human-readable | UTF-8 | "Awesome Wifi" |
	+-----+---------------+---------------+-----------+-----------------+		| | service name | string | |
	| s | noInternet | Internet | boolean | true |		| expires | Date after which | ISO 8601 | "2017-07-23T06:00:00Z" |
	| | | inaccessible | | |		| | this object is | | |
	| cp | captivePortal | Presence of a | boolean | false |		| | not valid | | |
	| | | captive | | |		| prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", |
	| | | portal | | |		| | prefixes valid | strings | "2001:db8:4::/48"] |
	| z | dnsZones | DNS zones | array of | ["foo.com","sub |		| | for this PVD | | |
	| | | accessible | DNS zone | .bar.com"] |		+----------+-------------------+-----------+------------------------+
	| | | and | | |
	| | | searchable | | |
	| 6 | prefixes6 | IPv6-prefixes | array of | ["2001:db8:a::/ |
	| | | accessible | IPv6 | 48","2001:db8:b |
	| | | via this PvD | prefixes | :c::/64"] |
	| 4 | prefixes4 | IPv4-prefixes | array of | ["192.0.2.0/24" |
	| | | accessible | IPv4 | ,"2.3.0.0/16"] |
	| | | | prefixes | |
	| | | | in CIDR | |
	| | | | reachable | |
	| | | | via this | |
	| | | | PvD | |
	+-----+---------------+---------------+-----------+-----------------+
	5.4. DNS Configuration		A retrieved object which does not include a valid string associated
			with the "name" key at the root of the object, or a valid date
			associated with the "expiration" key, also at the root of the object,
			MUST be ignored. In such cases, an error message SHOULD be logged
			and/or displayed in a rate-limited fashion.
	The following set of keys can be used to specify the DNS		The following table presents some optional keys which MAY be included
	configuration for the respective PvD. If present, they MUST be		in the object.
	honored and used by the client whenever it wishes to access a
	resource described by the PvD.
	+-----+------------+-------------+-----------+----------------------+		+-----------------+-----------------------+---------+---------------+
	| DNS | JSON key | Description | Value | JSON Example |		| JSON key | Description | Type | Example |
	| TXT | | | | |		+-----------------+-----------------------+---------+---------------+
	| key | | | | |		| localizedName | Localized user- | UTF-8 | "Wifi Genial" |
	+-----+------------+-------------+-----------+----------------------+		| | visible service name, | string | |
	| r | dnsServers | Recursive | array of | ["2001:db8::1","192. |		| | language can be | | |
	| | | DNS server | IPv6 and | 0.2.2"] |		| | selected based on the | | |
	| | | | IPv4 | |		| | HTTP Accept-Language | | |
	| | | | addresses | |		| | header in the | | |
	| d | dnsSearch | DNS search | array of | ["foo.com","sub.bar. |		| | request. | | |
	| | | domains | search | com"] |		| noInternet | No Internet, set when | boolean | true |
	| | | | domains | |		| | the PvD only provides | | |
	+-----+------------+-------------+-----------+----------------------+		| | restricted access to | | |
			| | a set of services. | | |
			| characteristics | Connectivity | JSON | See Section |
			| | characteristics | object | 5.3.1 |
			| metered | metered, when the | boolean | false |
			| | access volume is | | |
			| | limited. | | |
			+-----------------+-----------------------+---------+---------------+
	5.5. Connectivity Characteristics		It is worth noting that the JSON format allows for extensions.
			Whenever an unknown key is encountered, it MUST be ignored along with
			its associated elements, unless specified otherwise in future
			updating documents.
	NOTE: open question to the authors/reviewers: should this document		5.3.1. Connectivity Characteristics Information
	include this section or is it useless?
	The following set of keys can be used to signal certain		The following set of keys can be used to signal certain
	characteristics of the connection towards the PvD.		characteristics of the connection towards the PvD.
	They should reflect characteristics of the overall access technology		They should reflect characteristics of the overall access technology
	which is not limited to the link the host is connected to, but rather		which is not limited to the link the host is connected to, but rather
	a combination of the link technology, CPE upstream connectivity, and		a combination of the link technology, CPE upstream connectivity, and
	further quality of service considerations.		further quality of service considerations.
	+------+------------------+------------+--------------+-------------+		+---------------+--------------+---------------------+--------------+
	| DNS | JSON key | Descriptio | Type | JSON |		| JSON key | Description | Type | Example |
	| TXT | | n | | Example |		+---------------+--------------+---------------------+--------------+
	| key | | | | |		| maxThroughput | Maximum | object({down(int), | {"down": |
	+------+------------------+------------+--------------+-------------+		| | achievable | up(int)}) in kb/s | 10000, "up": |
	| tp | throughputMax | Maximum | object({down | {"down": |		| | throughput | | 5000} |
	| | | achievable | (int), | 10000, |		| minLatency | Minimum | object({down(int), | {"down": 10, |
	| | | throughput | up(int)}) in | "up": 5000} |		| | achievable | up(int)}) in ms | "up": 20} |
	| | | (e.g. CPE | kb/s | |		| | latency | | |
	| | | downlink/u | | |		| rl | Maximum | object({down(int), | {"down": |
	| | | plink) | | |		| | achievable | up(int)}) in losses | 0.1, "up": |
	| lt | latencyMin | Minimum | object({down | {"down": |		| | reliability | every 1000 packets | 1} |
	| | | achievable | (int), | 10, "up": |		+---------------+--------------+---------------------+--------------+
	| | | latency | up(int)}) in | 20} |
	| | | | ms | |
	| rl | reliabilityMax | Maximum | object({down | {"down": |
	| | | achievable | (int), | 1000, "up": |
	| | | reliabilit | up(int)}) in | 800} |
	| | | y | 1/1000 | |
	| cp | captivePortal | Captive | URL of the | "https://ex |
	| | | portal | portal | ample.com" |
	| nat | NAT | IPv4 NAT | boolean | true |
	| | | in place | | |
	| natt | NAT Time-out | The value | Integer | 30 |
	| o | | in seconds | | |
	| | | of the NAT | | |
	| | | time-out | | |
	| srh | segmentRoutingHe | The IPv6 | Binary | ... |
	| | ader | Segment | string | |
	| | | Routing | | |
	| | | Header to | | |
	| | | be used | | |
	| | | between | | |
	| | | the IPv6 | | |
	| | | header and | | |
	| | | any other | | |
	| | | headers | | |
	| | | when using | | |
	| | | this PvD | | |
	| srhD | segmentRoutingHe | The DNS | Ascii string | srh.pvd-foo |
	| NS | aderDnsFQDN | FQDN which | | .example.or |
	| | | is used to | | g |
	| | | retrieved | | |
	| | | the actual | | |
	| | | IPv6 | | |
	| | | Segment | | |
	| | | Routing | | |
	| | | Header to | | |
	| | | be used | | |
	| | | between | | |
	| | | the IPv6 | | |
	| | | header and | | |
	| | | any other | | |
	| | | headers | | |
	| | | when using | | |
	| | | this PvD | | |
	| cost | cost | Cost of | object | See Section |
	| | | using the | | 5.6 |
	| | | connection | | |
	+------+------------------+------------+--------------+-------------+
	5.6. Connection monetary cost		5.3.2. Private Extensions
			JSON keys starting with "x-" are reserved for private use and can be
			utilized to provide information that is specific to vendor, user or
			enterprise. It is RECOMMENDED to use one of the patterns "x-FQDN-
			KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or
			PEN is a private enterprise number [PEN] under control of the author
			of the extension to avoid collisions.
			5.3.3. Example
			Here are two examples based on the keys defined in this section.
			{
			"name": "Foo Wireless",
			"localizedName": "Foo-France Wifi",
			"expires": "2017-07-23T06:00:00Z",
			"prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"],
			"characteristics": {
			"maxThroughput": { "down":200000, "up": 50000 },
			"minLatency": { "down": 0.1, "up": 1 }
			}
			}
			{
			"name": "Bar 4G",
			"localizedName": "Bar US 4G",
			"expires": "2017-07-23T06:00:00Z",
			"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
			"metered": true,
			"characteristics": {
			"maxThroughput": { "down":80000, "up": 20000 }
			}
			}
			6. Security Considerations
			Although some solutions such as IPSec or SEND [RFC3971] can be used
			in order to secure the IPv6 Neighbor Discovery Protocol, actual
			deployments largely rely on link layer or physical layer security
			mechanisms (e.g. 802.1x [IEEE8021X]).
			This specification does not improve the Neighbor Discovery Protocol
			security model, but extends the purely link-local configuration
			retrieval mechanisms with HTTP-over-TLS communications.
			During the exchange, the server authenticity is verified by the mean
			of a certificate, validated based on the FQDN found in the Router
			Advertisement (e.g. using a list of pre-installed CA certificates, or
			DNSSec [RFC4035] with DNS Based Authentication of Named Entities
			[RFC6698]). This authentication creates a secure binding between the
			information provided by the trusted Router Advertisement, and the
			HTTP server.
			The IPv6 prefixes list included in the PvD Additional Information
			JSON object is used to validate that the prefixes included in the
			Router Advertisements are really part of the PvD.
			Note: The previous point does not protect against attacker performing
			NAT66. It would if we mandate the source-address validation on the
			server side, but not protect against tunnels. In other words,
			address based security will not protect against rogue APs, but may
			prevent the use of NAT66.
			For privacy reasons, it is desirable that the PvD Additional
			Information object may only be retrieved by the hosts using the given
			PvD. Host identity SHOULD be validated based on the client address
			that is used during the HTTP query.
			7. IANA Considerations
			IANA is kindly requested to allocate a new IPv6 Neighbor Discovery
			option number for the PvD ID Router Advertisement option and a new
			IKEv2 Configuration Payload Attribute Types for PVD_ID.
			TBD: JSON keys will need a new register.
			8. Acknowledgements
			Many thanks to M. Stenberg and S. Barth for their earlier work:
			[I-D.stenberg-mif-mpvd-dns].
			Thanks also to Ray Bellis, Lorenzo Colitti, Thierry Danis, Marcus
			Keane, Erik Kline, Jen Lenkova, Mark Townsley and James Woodyatt for
			useful and interesting discussions.
			Finally, many thanks to Thierry Danis for his implementation work:
			[github].
			9. References
			9.1. Normative references
			[RFC1035] Mockapetris, P., "Domain names - implementation and
			specification", STD 13, RFC 1035, November 1987.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
			Discovery for IP Version 6 (IPv6)", RFC 2461, December
			1998.
			[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
			RFC2818, May 2000,
			<http://www.rfc-editor.org/info/rfc2818>.
			[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
			"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
			September 2007.
			[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
			Uniform Resource Identifiers (URIs)", RFC 5785, DOI
			10.17487/RFC5785, April 2010,
			<http://www.rfc-editor.org/info/rfc5785>.
			[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
			2014, <http://www.rfc-editor.org/info/rfc7159>.
			9.2. Informative references
			[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
			Neighbor Discovery (SEND)", RFC 3971, March 2005.
			[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
			Rose, "Protocol Modifications for the DNS Security
			Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
			<http://www.rfc-editor.org/info/rfc4035>.
			[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
			More-Specific Routes", RFC 4191, November 2005.
			[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
			Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/
			RFC5798, March 2010,
			<http://www.rfc-editor.org/info/rfc5798>.
			[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
			"IPv6 Router Advertisement Options for DNS Configuration",
			RFC 6106, November 2010.
			[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
			of Named Entities (DANE) Transport Layer Security (TLS)
			Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
			2012, <http://www.rfc-editor.org/info/rfc6698>.
			[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
			"Default Address Selection for Internet Protocol Version 6
			(IPv6)", RFC 6724, September 2012.
			[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
			Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
			<http://www.rfc-editor.org/info/rfc7556>.
			[RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng,
			"Captive-Portal Identification Using DHCP or Router
			Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710,
			December 2015, <http://www.rfc-editor.org/info/rfc7710>.
			[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,
			<http://www.rfc-editor.org/info/rfc8028>.
			[I-D.bowbakova-rtgwg-enterprise-pa-multihoming]
			Baker, F., Bowers, C., and J. Linkova, "Enterprise
			Multihoming using Provider-Assigned Addresses without
			Network Prefix Translation: Requirements and Solution",
			draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 (work
			in progress), October 2016.
			[I-D.stenberg-mif-mpvd-dns]
			Stenberg, M. and S. Barth, "Multiple Provisioning Domains
			using Domain Name System", draft-stenberg-mif-mpvd-dns-00
			(work in progress), October 2015.
			[I-D.kline-mif-mpvd-api-reqs]
			Kline, E., "Multiple Provisioning Domains API
			Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in
			progress), November 2015.
			[PEN] IANA, "Private Enterprise Numbers", <https://www.iana.org/
			assignments/enterprise-numbers>.
			[IEEE8021X]
			IEEE, "IEEE Standards for Local and Metropolitan Area
			Networks: Port based Network Access Control, IEEE Std", .
			[github] Cisco, "IPv6-mPvD github repository", <https://github.com/
			IPv6-mPvD>.
			Appendix A. Changelog
			Note to RFC Editors: Remove this section before publication.
			A.1. Version 00
			Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke
			and based on Basile's work.
			A.2. Version 01
			Major rewrite intended to focus on the the retained solution based on
			corridors, online, and WG discussions. Edited by Pierre Pfister.
			The following list only includes major changes.
			PvD ID is an FQDN retrieved using a single RA option. This option
			contains a sequence number for push-based updates, a new H-flag,
			and a L-flag in order to link the PvD with the IPv4 DHCP server.
			A lifetime is included in the PvD ID option.
			Detailed Hosts and Routers specifications.
			Additional Information is retrieved using HTTP-over-TLS when the
			PvD ID Option H-flag is set. Retrieving the object is optional.
			The PvD Additional Information object includes a validity date.
			DNS-based approach is removed as well as the DNS-based encoding of
			the PvD Additional Information.
			Major cut in the list of proposed JSON keys. This document may be
			extended later if need be.
			Monetary discussion is moved to the appendix.
			Clarification about the 'prefixes' contained in the additional
			information.
			Clarification about the processing of DHCPv6.
			Appendix B. Connection monetary cost
	NOTE: This section is included as a request for comment on the		NOTE: This section is included as a request for comment on the
	potential use and syntax.		potential use and syntax.
	The billing of a connection can be done in a lot of different ways.		The billing of a connection can be done in a lot of different ways.
	The user can have a global traffic threshold per month, after which		The user can have a global traffic threshold per month, after which
	his throughput is limited, or after which he/she pays each megabyte.		his throughput is limited, or after which he/she pays each megabyte.
	He/she can also have an unlimited access to some websites, or an		He/she can also have an unlimited access to some websites, or an
	unlimited access during the weekends.		unlimited access during the weekends.
	We propose to split the final billing in elementary billings, which		An option is to split the bill in elementary billings, which have
	have conditions (a start date, an end date, a destination IP		conditions (a start date, an end date, a destination IP address...).
	address...). The global billing is an ordered list of elementary		The global billing is an ordered list of elementary billings. To
	billings. To know the cost of a transmission, the host goes through		know the cost of a transmission, the host goes through the list, and
	the list, and the first elementary billing whose the conditions are		the first elementary billing whose the conditions are fulfilled gives
	fulfilled gives the cost. If no elementary billing conditions match		the cost. If no elementary billing conditions match the request, the
	the request, the host MUST make no assumption about the cost.		host MUST make no assumption about the cost.
	5.6.1. Conditions		B.1. Conditions
	Here are the potential conditions for an elementary billing. All		Here are the potential conditions for an elementary billing. All
	conditions MUST be fulfill.		conditions MUST be fulfill.
	Note: the final version should use short-hand key names.
	+-----------+-------------+---------------+-------------------------+		+-----------+-------------+---------------+-------------------------+
	| Key | Description | Type | JSON Example |		| Key | Description | Type | JSON Example |
	+-----------+-------------+---------------+-------------------------+		+-----------+-------------+---------------+-------------------------+
	| beginDate | Date before | ISO 8601 | "1977-04-22T06:00:00Z" |		| beginDate | Date before | ISO 8601 | "1977-04-22T06:00:00Z" |
	| | which the | | |		| | which the | | |
	| | billing is | | |		| | billing is | | |
	| | not valid | | |		| | not valid | | |
	| endDate | Date after | ISO 8601 | "1977-04-22T06:00:00Z" |		| endDate | Date after | ISO 8601 | "1977-04-22T06:00:00Z" |
	| | which the | | |		| | which the | | |
	| | billing is | | |		| | billing is | | |
	skipping to change at page 15, line 38 ¶		skipping to change at page 18, line 31 ¶
	| | whose the | | |		| | whose the | | |
	| | billing is | | |		| | billing is | | |
	| | limited | | |		| | limited | | |
	| prefixes6 | IPv6 | array(string) | ["2a00:1450:4007:80e::2 |		| prefixes6 | IPv6 | array(string) | ["2a00:1450:4007:80e::2 |
	| | prefixes | | 00e/64"] |		| | prefixes | | 00e/64"] |
	| | whose the | | |		| | whose the | | |
	| | billing is | | |		| | billing is | | |
	| | limited | | |		| | limited | | |
	+-----------+-------------+---------------+-------------------------+		+-----------+-------------+---------------+-------------------------+
	5.6.2. Price		B.2. Price
	Here are the different possibilities for the cost of an elementary		Here are the different possibilities for the cost of an elementary
	billing. A missing key means "all/unlimited/unrestricted". If the		billing. A missing key means "all/unlimited/unrestricted". If the
	elementary billing selected has a trafficRemaining of 0 kb, then it		elementary billing selected has a trafficRemaining of 0 kb, then it
	means that the user has no access to the network. Actually, if the		means that the user has no access to the network. Actually, if the
	last elementary billing has a trafficRemaining parameter, it means		last elementary billing has a trafficRemaining parameter, it means
	that when the user will reach the threshold, he/she will not have		that when the user will reach the threshold, he/she will not have
	access to the network anymore.		access to the network anymore.
	+------------------+------------------+--------------+--------------+		+------------------+------------------+--------------+--------------+
	| Key | Description | Type | JSON Example |		| Key | Description | Type | JSON Example |
	+------------------+------------------+--------------+--------------+		+------------------+------------------+--------------+--------------+
	| pricePerGb | The price per | float | 2 |		| pricePerGb | The price per | float | 2 |
	| | Gigabit | (currency | |		| | Gigabit | (currency | |
	| | | per Gb) | |		| | | per Gb) | |
	| currency | The currency | ISO 4217 | "EUR" |		| currency | The currency | ISO 4217 | "EUR" |
	| | used | | |		| | used | | |
	| throughputMax | The maximum | float (kb/s) | 1000 |		| throughputMax | The maximum | float (kb/s) | 100000 |
	| | achievable | | |		| | achievable | | |
	| | throughput | | |		| | throughput | | |
	| trafficRemaining | The traffic | float (kb) | 96000000 |		| trafficRemaining | The traffic | float (kB) | 12000000 |
	| | remaining | | |		| | remaining | | |
	+------------------+------------------+--------------+--------------+		+------------------+------------------+--------------+--------------+
	5.6.3. Examples		B.3. Examples
	Example for a user with 20 GB per month for 40 EUR, then reach a		Example for a user with 20 GB per month for 40 EUR, then reach a
	threshold, and with unlimited data during weekends and to deezer:		threshold, and with unlimited data during weekends and to
			example.com:
	[		[
	{		{
	"domains": ["deezer.com"]		"domains": ["example.com"]
	},		},
	{		{
	"prefixes4": ["78.40.123.182/32","78.40.123.183/32"]		"prefixes4": ["78.40.123.182/32","78.40.123.183/32"]
	},		},
	{		{
	"beginDate": "2016-07-16T00:00:00Z",		"beginDate": "2016-07-16T00:00:00Z",
	"endDate": "2016-07-17T23:59:59Z",		"endDate": "2016-07-17T23:59:59Z",
	},		},
	{		{
	"beginDate": "2016-06-20T00:00:00Z",		"beginDate": "2016-06-20T00:00:00Z",
	"endDate": "2016-07-19T23:59:59Z",		"endDate": "2016-07-19T23:59:59Z",
	"trafficRemaining": 96000000		"trafficRemaining": 12000000
	},		},
	{		{
	"throughputMax": 1000		"throughputMax": 100000
	}		}
	]		]
	If the host tries to download data from deezer.com, the conditions of		If the host tries to download data from example.com, the conditions
	the first elementary billing are fulfilled, so the host takes this		of the first elementary billing are fulfilled, so the host takes this
	elementary billing, finds no cost indication in it and so deduces		elementary billing, finds no cost indication in it and so deduces
	that it is totally free. If the host tries to exchange data with		that it is totally free. If the host tries to exchange data with
	youtube.com and the date is 2016-07-14T19:00:00Z, the conditions of		foobar.com and the date is 2016-07-14T19:00:00Z, the conditions of
	the first, second and third elementary billing are not fulfilled.		the first, second and third elementary billing are not fulfilled.
	But the conditions of the fourth are. So the host takes this		But the conditions of the fourth are. So the host takes this
	elementary billing and sees that there is a threshold, 12 GB are		elementary billing and sees that there is a threshold, 12 GB are
	remaining.		remaining.
	Another example for a user abroad, who has 3 GB per year abroad, and		Another example for a user abroad, who has 3 GB per year abroad, and
	then pay each MB:		then pay each MB:
	[		[
	{		{
	"beginDate": "2016-02-10T00:00:00Z",		"beginDate": "2016-02-10T00:00:00Z",
	"endDate": "2017-02-09T23:59:59Z",		"endDate": "2017-02-09T23:59:59Z",
	"trafficRemaining": 9200000		"trafficRemaining": 3000000
	},		},
	{		{
	"pricePerGb": 30,		"pricePerGb": 30,
	"currency": "EUR"		"currency": "EUR"
	}		}
	]		]
	5.7. Private Extensions
	keys starting with "x-" are reserved for private use and can be
	utilized to provide vendor-, user- or enterprise-specific
	information. It is RECOMMENDED to use one of the patterns "x-FQDN-
	KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or
	PEN is a private enterprise number [PEN] under control of the author
	of the extension to avoid collisions.
	5.8. Examples
	5.8.1. Using JSON
	{
	"name": "Orange France",
	"localizedName": "Orange France",
	"dnsServers": ["8.8.8.8", "8.8.4.4"],
	"throughputMax": {
	"down": 100000,
	"up": 20000
	},
	"cost": [
	{
	"domains": ["deezer.com"]
	},
	{
	"prefixes4": ["78.40.123.182/32","78.40.123.183/32"]
	},
	{
	"beginDate": "2016-07-16T00:00:00Z",
	"endDate": "2016-07-17T23:59:59Z",
	},
	{
	"beginDate": "2016-06-20T00:00:00Z",
	"endDate": "2016-07-19T23:59:59Z",
	"trafficRemaining": 96000000
	},
	{
	"throughputMax": 1000
	}
	]
	}
	5.8.2. Using DNS TXT records
	n=Orange France
	r=8.8.8.8,8.8.4.4
	tp=100000,20000
	cost+0+domains=deezer.com
	cost+1+prefixes4=78.40.123.182/32,78.40.123.183/32
	cost+2+beginDate=2016-07-16T00:00:00Z
	cost+2+endDate=2016-07-17T23:59:59Z
	cost+3+beginDate=2016-06-20T00:00:00Z
	cost+3+endDate=2016-07-19T23:59:59Z
	cost+3+trafficRemaining=96000000
	cost+4+throughputMax=1000
	6. Use case examples
	TBD: 1 or 2 examples when PvD are critical
	6.1. Multihoming
	First example could be multihoming (very much in-line with bowbakova
	draft).
	6.2. VPN/Extranet example
	using PvD to reach a specific destination (such as VPN or extranet).
	7. Security Considerations
	While the PvD ID can be forged easily, if the host retrieve the
	extended PvD via TLS, then the host can trust the content of the
	extended PvD and verifies that the RA prefix(es) are indeed included
	in the master prefixed of the extended PvD.
	8. Acknowledgements
	Many thanks to M. Stenberg and S. Barth: Section 5.3, Section 5.5
	and Section 5.7 are from their document [I-D.stenberg-mif-mpvd-dns].
	Thanks also to Ray Bellis, Lorenzo Colitti, Marcus Keane, Erik Kline,
	Jen Lenkova, Mark Townsley and James Woodyatt for useful and
	interesting brainstorming sessions.
	9. References
	9.1. Normative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.
	[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
	Address Text Representation", RFC 5952,
	DOI 10.17487/RFC5952, August 2010,
	<http://www.rfc-editor.org/info/rfc5952>.
	[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
	Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
	<http://www.rfc-editor.org/info/rfc7556>.
	9.2. Informative references
	[I-D.bowbakova-rtgwg-enterprise-pa-multihoming]
	Baker, F., Bowers, C., and J. Linkova, "Enterprise
	Multihoming using Provider-Assigned Addresses without
	Network Prefix Translation: Requirements and Solution",
	draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 (work
	in progress), October 2016.
	[I-D.stenberg-mif-mpvd-dns]
	Stenberg, M. and S. Barth, "Multiple Provisioning Domains
	using Domain Name System", draft-stenberg-mif-mpvd-dns-00
	(work in progress), October 2015.
	[PEN] IANA, "Private Enterprise Numbers",
	<https://www.iana.org/assignments/enterprise-numbers>.
	Authors' Addresses		Authors' Addresses
	Basile Bruneau		Basile Bruneau
	Ecole polytechnique		Ecole Polytechnique
	Vannes 56000		Vannes 56000
	France		France
	Email: basile.bruneau@polytechnique.edu		Email: basile.bruneau@polytechnique.edu
	Pierre Pfister		Pierre Pfister
	Cisco		Cisco
	11 Rue Camille Desmoulins		11 Rue Camille Desmoulins
	Issy-les-Moulineaux 92130		Issy-les-Moulineaux 92130
	France		France
	skipping to change at page 21, line 4 ¶		skipping to change at page 21, line 4 ¶
	David Schinazi		David Schinazi
	Apple		Apple
	Email: dschinazi@apple.com		Email: dschinazi@apple.com
	Tommy Pauly		Tommy Pauly
	Apple		Apple
	Email: tpauly@apple.com		Email: tpauly@apple.com
	Eric Vyncke (editor)		Eric Vyncke
	Cisco		Cisco
	De Kleetlaan, 6		De Kleetlaan, 6
	Diegem 1831		Diegem 1831
	Belgium		Belgium
	Email: evyncke@cisco.com		Email: evyncke@cisco.com
End of changes. 114 change blocks.
	591 lines changed or deleted		654 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/