draft-ietf-intarea-provisioning-domains-02.txt		draft-ietf-intarea-provisioning-domains-03.txt
	intarea P. Pfister		intarea P. Pfister
	Internet-Draft E. Vyncke, Ed.		Internet-Draft E. Vyncke, Ed.
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: December 6, 2018 T. Pauly		Expires: April 22, 2019 T. Pauly
	D. Schinazi		D. Schinazi
	Apple		Apple
	W. Shao		W. Shao
	Telecom-ParisTech		Telecom-ParisTech
	June 4, 2018		October 19, 2018
	Discovering Provisioning Domain Names and Data		Discovering Provisioning Domain Names and Data
	draft-ietf-intarea-provisioning-domains-02		draft-ietf-intarea-provisioning-domains-03
	Abstract		Abstract
	An increasing number of hosts access the Internet via multiple		An increasing number of hosts access the Internet via multiple
	interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix		interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix
	configurations context.		configurations context.
	This document describes a way for hosts to identify such contexts,		This document describes a way for hosts to identify such contexts,
	called Provisioning Domains (PvDs), where Fully Qualified Domain		called Provisioning Domains (PvDs), where Fully Qualified Domain
	Names (FQDNs) act as PvD identifiers. Those identifiers are		Names (FQDNs) act as PvD identifiers. Those identifiers are
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 December 6, 2018.		This Internet-Draft will expire on April 22, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 39 ¶		skipping to change at page 2, line 39 ¶
	3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 8		3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 8
	3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 8		3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 8
	3.4.1. DHCPv6 configuration association . . . . . . . . . . 9		3.4.1. DHCPv6 configuration association . . . . . . . . . . 9
	3.4.2. DHCPv4 configuration association . . . . . . . . . . 9		3.4.2. DHCPv4 configuration association . . . . . . . . . . 9
	3.4.3. Connection Sharing by the Host . . . . . . . . . . . 9		3.4.3. Connection Sharing by the Host . . . . . . . . . . . 9
	4. Provisioning Domain Additional Information . . . . . . . . . 10		4. Provisioning Domain Additional Information . . . . . . . . . 10
	4.1. Retrieving the PvD Additional Information . . . . . . . . 10		4.1. Retrieving the PvD Additional Information . . . . . . . . 10
	4.2. Operational Consideration to Providing the PvD Additional		4.2. Operational Consideration to Providing the PvD Additional
	Information . . . . . . . . . . . . . . . . . . . . . . . 12		Information . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. PvD Additional Information Format . . . . . . . . . . . . 12		4.3. PvD Additional Information Format . . . . . . . . . . . . 12
	4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 13		4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 14
	4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 13		4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 14
	4.4. Detecting misconfiguration and misuse . . . . . . . . . . 14		4.4. Detecting misconfiguration and misuse . . . . . . . . . . 14
	5. Operational Considerations . . . . . . . . . . . . . . . . . 14		5. Operational Considerations . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative references . . . . . . . . . . . . . . . . . . 18		10.1. Normative references . . . . . . . . . . . . . . . . . . 18
	10.2. Informative references . . . . . . . . . . . . . . . . . 19		10.2. Informative references . . . . . . . . . . . . . . . . . 19
	Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 20		A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 21
	A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 20		A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 21
	A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 21		A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 22
	A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 22		A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 22
	A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 22		A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 23
	A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 23		A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	It has become very common in modern networks for hosts to access the		It has become very common in modern networks for hosts to access the
	internet through different network interfaces, tunnels, or next-hop		internet through different network interfaces, tunnels, or next-hop
	routers. To describe the set of network configurations associated		routers. To describe the set of network configurations associated
	with each access method, the concept of Provisioning Domain (PvD) was		with each access method, the concept of Provisioning Domain (PvD) was
	defined in [RFC7556].		defined in [RFC7556].
	This document specifies a way to identify PvDs with Fully Qualified		This document specifies a way to identify PvDs with Fully Qualified
	skipping to change at page 7, line 48 ¶		skipping to change at page 7, line 48 ¶
	otherwise be valid as part of the same RA. Such options are		otherwise be valid as part of the same RA. Such options are
	processed by PvD-aware hosts, while ignored by others.		processed by PvD-aware hosts, while ignored by others.
	In order to provide multiple different PvDs, a router MUST send		In order to provide multiple different PvDs, a router MUST send
	multiple RAs. Different explicit PvDs MAY be advertised with RAs		multiple RAs. Different explicit PvDs MAY be advertised with RAs
	using the same IPv6 source address; but different implicit PvDs,		using the same IPv6 source address; but different implicit PvDs,
	advertised by different RAs, MUST use different link-local addresses		advertised by different RAs, MUST use different link-local addresses
	because these implicit PvDs are identified by the source addresses of		because these implicit PvDs are identified by the source addresses of
	the RAs.		the RAs.
	Whenever an RA, for a single PvD, would need to be sent via multiple		As specified in [RFC4861], when the set of options causes the size of
	packets, the PvD option header (i.e., all fields except the 'Options'		an advertisement to exceed the link MTU, multiple router
	field) MUST be repeated in all the transmitted RAs. But the options		advertisements can be sent, each containing a subset of the options.
	within the 'Options' field, MAY be transmitted only once, included in		In such cases, the PvD option header (i.e., all fields except the
	one of the transmitted PvD options.		'Options' field) MUST be repeated in all the transmitted RAs. But
			the options within the 'Options' field, MAY be transmitted only once,
			included in one of the transmitted PvD options.
	3.3. Non-PvD-aware Host Behavior		3.3. Non-PvD-aware Host Behavior
	As the PvD Option has a new option code, non-PvD-aware hosts will		As the PvD Option has a new option code, non-PvD-aware hosts will
	simply ignore the PvD Option and all the options it contains. This		simply ignore the PvD Option and all the options it contains. This
	ensure the backward compatibility required in section 3.3 of		ensure the backward compatibility required in section 3.3 of
	[RFC7556]. This behavior allows for a mixed-mode network with a mix		[RFC7556]. This behavior allows for a mixed-mode network with a mix
	of PvD-aware and non-PvD-aware hosts coexist.		of PvD-aware and non-PvD-aware hosts coexist.
	3.4. PvD-aware Host Behavior		3.4. PvD-aware Host Behavior
	skipping to change at page 9, line 41 ¶		skipping to change at page 9, line 42 ¶
	whose PVD Options L-flag is set and, in the case of a non point-to-		whose PVD Options L-flag is set and, in the case of a non point-to-
	point link, using the same datalink address. If no such PvD is		point link, using the same datalink address. If no such PvD is
	found, or whenever multiple different PvDs are found, the		found, or whenever multiple different PvDs are found, the
	configuration elements coming from DHCPv4 MUST be associated with the		configuration elements coming from DHCPv4 MUST be associated with the
	implicit PvD identified by the interface on which the DHCPv4		implicit PvD identified by the interface on which the DHCPv4
	transaction happened. The case of multiple explicit PvD for an IPv4		transaction happened. The case of multiple explicit PvD for an IPv4
	interface is undefined.		interface is undefined.
	3.4.3. Connection Sharing by the Host		3.4.3. Connection Sharing by the Host
	The situation when a node receives an RA on one interface (e.g.		The situation when a host shares connectivity from an upstream
	cellular) and shares this connectivity by also acting as a router by		interface (e.g. cellular) to a downstream interface (e.g. WiFi) is
	transmitting RA on another interface (e.g. WiFi) is known as		known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share
	'tethering'. It can be done as ND proxy. The exact behavior is out		[RFC7278] or prefix delegation (e.g. using DHCPv6-PD [RFC3633]) may
	of scope of this document but it is expected that the one or several		be used for that purpose.
	PvD associated to the shared interface (e.g. cellular) will also be
	advertised to the clients on the other interface (e.g. WiFi).		Whenever the RAs received from the upstream interface contain a PVD
			RA option, hosts that are sharing connectivity SHOULD include a PVD
			Option within the RAs sent downstream with:
			The same PVD-ID FQDN.
			The same H-bit, Delay and Sequence Number values.
			The L bit set whenever the host is sharing IPv4 connectivity
			received from the same upstream interface.
			The bits from the Reserved field set to 0.
			The values of the R-bit, Router Advertisement message header and
			Options field depend on whether the connectivity should be shared
			only with PvD aware hosts or not (see Section 3.2). In particular,
			all options received within the upstream PvD option and included in
			the downstream RA SHOULD be included in the downstream PvD option.
	4. Provisioning Domain Additional Information		4. Provisioning Domain Additional Information
	Additional information about the network characteristics can be		Additional information about the network characteristics can be
	retrieved based on the PvD ID. This set of information is called PvD		retrieved based on the PvD ID. This set of information is called PvD
	Additional Information, and is encoded as a JSON object [RFC7159].		Additional Information, and is encoded as a JSON object [RFC7159].
	The purpose of this additional set of information is to securely		The purpose of this additional set of information is to securely
	provide additional information to applications about the connectivity		provide additional information to applications about the connectivity
	that is provided using a given interface and source address pair. It		that is provided using a given interface and source address pair. It
	skipping to change at page 14, line 35 ¶		skipping to change at page 15, line 5 ¶
	information provided by the trusted Router Advertisement, and the		information provided by the trusted Router Advertisement, and the
	HTTPS server. But this does not mean the Advertising Router and the		HTTPS server. But this does not mean the Advertising Router and the
	PvD server belong to the same entity.		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 the RA PIO are covered by a
	prefix from the PvD Additional Information. An adversarial router		prefix from the PvD Additional Information. An adversarial router
	willing to fake the use of a given explicit PvD, without any access		willing to fake the use of a given explicit PvD, without any access
	to the actual PvD Additional Information, would need to perform NAT66		to the actual PvD Additional Information, would need to perform NAT66
	in order to circumvent this check.		in order to circumvent this check.
	It is also RECOMMENDED that the HTTPS server checks the source		It is also RECOMMENDED that the HTTPS server checks the IPv6 source
	addresses of incoming connections (see Section 4.1). This check give		addresses of incoming connections (see Section 4.1). This check give
	reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used		reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used
	and restricts the information to the valid network users.		and restricts the information to the valid network users.
			Note that this check cannot be performed when the HTTPS query is
			performed over IPv4. Therefore, the PvD ID FQDN SHOULD NOT have a
			DNS A record whenever all hosts using the given PvD have IPv6
			connectivity.
	5. Operational Considerations		5. Operational Considerations
	This section describes some use cases of PvD. For the sake of		This section describes some use cases of PvD. For the sake of
	simplicity, the RA messages will not be described in the usual ASCII		simplicity, the RA messages will not be described in the usual ASCII
	art but rather in an indented list. For example, a RA message		art but rather in an indented list. For example, a RA message
	containing some options and a PvD option that also contains other		containing some options and a PvD option that also contains other
	options will be described as:		options will be described as:
	o RA Header: router lifetime = 6000		o RA Header: router lifetime = 6000
	skipping to change at page 19, line 31 ¶		skipping to change at page 19, line 45 ¶
	IEEE, "IEEE Standards for Local and Metropolitan Area		IEEE, "IEEE Standards for Local and Metropolitan Area
	Networks: Port based Network Access Control, IEEE Std".		Networks: Port based Network Access Control, IEEE Std".
	[PEN] IANA, "Private Enterprise Numbers",		[PEN] IANA, "Private Enterprise Numbers",
	<https://www.iana.org/assignments/enterprise-numbers>.		<https://www.iana.org/assignments/enterprise-numbers>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<https://www.rfc-editor.org/info/rfc3339>.		<https://www.rfc-editor.org/info/rfc3339>.
			[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
			Host Configuration Protocol (DHCP) version 6", RFC 3633,
			DOI 10.17487/RFC3633, December 2003,
			<https://www.rfc-editor.org/info/rfc3633>.
	[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		[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
	More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,		More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
	November 2005, <https://www.rfc-editor.org/info/rfc4191>.		November 2005, <https://www.rfc-editor.org/info/rfc4191>.
			[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
			Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
			2006, <https://www.rfc-editor.org/info/rfc4389>.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,		IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
	<https://www.rfc-editor.org/info/rfc4941>.		<https://www.rfc-editor.org/info/rfc4941>.
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,
	DOI 10.17487/RFC5785, April 2010,		DOI 10.17487/RFC5785, April 2010,
	<https://www.rfc-editor.org/info/rfc5785>.		<https://www.rfc-editor.org/info/rfc5785>.
	skipping to change at page 20, line 24 ¶		skipping to change at page 20, line 47 ¶
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<https://www.rfc-editor.org/info/rfc6724>.		<https://www.rfc-editor.org/info/rfc6724>.
	[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved		[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
	Recursive DNS Server Selection for Multi-Interfaced		Recursive DNS Server Selection for Multi-Interfaced
	Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,		Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
	<https://www.rfc-editor.org/info/rfc6731>.		<https://www.rfc-editor.org/info/rfc6731>.
			[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
			/64 Prefix from a Third Generation Partnership Project
			(3GPP) Mobile Interface to a LAN Link", RFC 7278,
			DOI 10.17487/RFC7278, June 2014,
			<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		[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
	Hosts in a Multi-Prefix Network", RFC 8028,		Hosts in a Multi-Prefix Network", RFC 8028,
	DOI 10.17487/RFC8028, November 2016,		DOI 10.17487/RFC8028, November 2016,
	<https://www.rfc-editor.org/info/rfc8028>.		<https://www.rfc-editor.org/info/rfc8028>.
	[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,		[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
End of changes. 18 change blocks.
	28 lines changed or deleted		67 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/