< draft-ietf-mif-mpvd-ndp-support-02.txt		draft-ietf-mif-mpvd-ndp-support-03.txt >
	MIF J. Korhonen		MIF J. Korhonen
	Internet-Draft Broadcom Corporation		Internet-Draft Broadcom Limited
	Intended status: Standards Track S. Krishnan		Intended status: Standards Track S. Krishnan
	Expires: April 21, 2016 Ericsson		Expires: August 28, 2016 Ericsson
	S. Gundavelli		S. Gundavelli
	Cisco Systems		Cisco Systems
	October 19, 2015		February 25, 2016
	Support for multiple provisioning domains in IPv6 Neighbor Discovery		Support for multiple provisioning domains in IPv6 Neighbor Discovery
	Protocol		Protocol
	draft-ietf-mif-mpvd-ndp-support-02		draft-ietf-mif-mpvd-ndp-support-03
	Abstract		Abstract
	The MIF working group is producing a solution to solve the issues		The MIF working group is producing a solution to solve the issues
	that are associated with nodes that can be attached to multiple		that are associated with nodes that can be attached to multiple
	networks. One part of the solution requires associating		networks. One part of the solution requires associating
	configuration information with provisioning domains. This document		configuration information with provisioning domains. This document
	details how configuration information provided through IPv6 Neighbor		details how configuration information provided through IPv6 Neighbor
	Discovery Protocol can be associated with provisioning domains.		Discovery Protocol can be associated with provisioning domains.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 April 21, 2016.		This Internet-Draft will expire on August 28, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. PVD Container option . . . . . . . . . . . . . . . . . . . . 3		3. PVD Container option . . . . . . . . . . . . . . . . . . . . 3
	4. PVD Identity option . . . . . . . . . . . . . . . . . . . . . 5		4. Set of allowable options . . . . . . . . . . . . . . . . . . 5
	5. Set of allowable options . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8
	A.1. One implicit PVD and one explicit PVD . . . . . . . . . . 8		A.1. One implicit PVD and one explicit PVD . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The MIF working group is producing a solution to solve the issues		The MIF working group is producing a solution to solve the issues
	that are associated with nodes that can be attached to multiple		that are associated with nodes that can be attached to multiple
	networks based on the Multiple Provisioning Domains (MPVD)		networks based on the Multiple Provisioning Domains (MPVD)
	architecture work [RFC7556]. One part of the solution requires		architecture work [RFC7556]. One part of the solution requires
	associating configuration information with Provisioning Domains		associating configuration information with Provisioning Domains
	(PVD). This document describes an IPv6 Neighbor Discovery Protocol		(PVD). This document describes an IPv6 Neighbor Discovery Protocol
	(NDP) [RFC4861] mechanism for explicitly indicating provisioning		(NDP) [RFC4861] mechanism for explicitly indicating provisioning
	domain information along with any configuration which is associated		domain information along with any configuration which is associated
	with that provisioning domain. The proposed mechanism uses an NDP		with that provisioning domain. The proposed mechanism uses an NDP
	option that indicates the identity of the provisioning domain and		option that indicates the identity of the provisioning domain and
	encapsulates the options that contain the configuration information		encapsulates the options that contain the configuration information
	as well as any accompanying authentication/authorization information.		as well as optional authentication/authorization information. The
	The solution defined in this document aligns as much as possible with		solution defined in this document aligns as much as possible with the
	the existing IPv6 Neighbor Discovery security, namely with Secure		existing IPv6 Neighbor Discovery security, namely with Secure
	Neighbor Discovery (SeND) [RFC3971].		Neighbor Discovery (SeND) [RFC3971].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. PVD Container option		3. PVD Container option
	The PVD container option (PVD_CO) is used to mark the start of the		The PVD container option (PVD_CO) is used to encapsulate the
	configuration options that belong to the explicitly identified		configuration options that belong to the explicitly identified
	provisioning domain. The PVD container option MUST encapsulate		provisioning domain. The PVD container option always encapsulates
	exactly one PVD identity option (PVD_ID, see Section 4). The PVD		exactly one PVD identity. The PVD container option MAY occur
	container option MAY occur multiple times in a Router Advertisement		multiple times in a Router Advertisement (RA) message. In this case
	(RA) message. In this case each PVD container MUST belong to a		each PVD container MUST belong to a different provisioning domain.
	different provisioning domain. The PVD container options MUST NOT be		The PVD container options MUST NOT be nested. The PVD Container
	nested. The PVD Container option is defined only for the RA and		option is defined only for the RA NDP message.
	Router Solicitation (RS) NDP messages, and intended to be only used
	with IPv6 RA messages. However, if a host wants to solicit
	information for a specific provisioning domain it can include the PVD
	identity option into an RS message and use the PVD container to sign
	the PVD identity option.
	Since implementations are required to ignore any unrecognized options		Since implementations are required to ignore any unrecognized options
	[RFC4861], the backward compatibility and the reuse of existing NDP		[RFC4861], the backward compatibility and the reuse of existing NDP
	options is implicitly enabled. Implementations that do not recognize		options is implicitly enabled. Implementations that do not recognize
	the PVD container option will ignore it, and any PVD container option		the PVD container option will ignore it, and any PVD container option
	"encapsulated" NDP options without associating them into any		"encapsulated" NDP options without associating them into any
	provisioning domain (since the implementation has no notion of		provisioning domain (since the implementation has no notion of
	provisioning domains). For example, the PVD container could		provisioning domains). For example, the PVD container could
	"encapsulate" a Prefix Information Option (PIO), which would mark		"encapsulate" a Prefix Information Option (PIO), which would mark
	that this certain advertised IPv6 prefix belongs and originates from		that this certain advertised IPv6 prefix belongs and originates from
	a specific provisioning domain. However, if the implementation does		a specific provisioning domain. However, if the implementation does
	not understand provisioning domains, then this specific PIO is also		not understand provisioning domains, then this specific PIO is also
	skipped and not configured to the interface.		skipped and not configured on the interface.
	The optional security for the PVD container is based on X.509		The optional security for the PVD container is based on X.509
	certificates [RFC6487] and reuses mechanisms already defined for SeND		certificates [RFC6487] and reuses mechanisms already defined for SeND
	[RFC3971] [RFC6495]. However, the use of PVD containers does not		[RFC3971] [RFC6495]. However, the use of PVD containers does not
	assume or depend on SeND being deployed or even implemented. The PVD		assume or depend on SeND being deployed or even implemented. The PVD
	containers SHOULD be signed per PVD certificates, which provides both		containers SHOULD be signed per PVD certificates, which provides both
	integrity protection and proves that the configuration information		integrity protection and proves that the configuration information
	source is authorized for advertising the given information. See		source is authorized for advertising the given information. See
	[RFC6494] for discussion how to enable deployments where the		[RFC6494] for discussion how to enable deployments where the
	certificates needed to sign PVD containers belong to different		certificates needed to sign PVD containers belong to different
	administrative domains i.e. to different provisioning domains.		administrative domains i.e., to different provisioning domains.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=PVD_CO | Length |S| Reserved | Name Type |		| Type=PVD_CO | Length | Name Type | r | Sec
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: :		Length | ID Length | Key Hash (optional) ~
	: Key Hash (optional) :
	: :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: :		~ Digital Signature (optional) ~
	: Digital Signature (optional) :
	: :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Possible zero padding to ensure 8 octets alignment |		| PVD Identity ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Possible zero padding to ensure 8 octets alignment |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Zero or more "encapsulated" NDP options ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: PVD Container Option		Figure 1: PVD Container Option
	Type		Type
	PVD Container; Set to TBD1.		PVD Container; Set to TBD1.
	Length		Length
	Length of the PVD_CO. The actual length depends on the number of		Length of the PVD_CO. The actual length depends on the number of
	"encapsulated" NDP options, the length of the PVD identifier		"encapsulated" NDP options, length of the PVD Identity, and the
	option, and the optional Key Hash/Digital Signature/Padding.		optional Key Hash/Digital Signature/Padding.
	S
	Security enabled/disabled flag. If S=0 then security (signing)
	of the PVD_CO is disabled. If S=1 then security (signing) is
	enabled.
	Name Type		Name Type
	Names the algorithm used to identify a specific X.509 certificate		Names the algorithm used to identify a specific X.509 certificate
	using the method defined for the Subject Key Identifier (SKI)		using the method defined for the Subject Key Identifier (SKI)
	extension for the X.509 certificates. The usage and the Name		extension for the X.509 certificates. The usage and the Name
	Type registry aligns with the mechanism defined for SeND		Type registry aligns with the mechanism defined for SeND
	[RFC6495]. Name Type values starting from 3 are supported and an		[RFC6495]. Name Type values starting from 3 are supported and an
	implementation MUST at least support SHA-1 (value 3). Note that		implementation MUST at least support SHA-1 (value 3). Note that
	if S=0 the Name field serves no use.		if Sec Length=0 the Name field serves no use and MUST be set to
			0.
			r
			Reserved. MUST be set to 0 and ignored when received.
			Sec Length
			11-bit length of the Key Hash and Digital Signature in a units of
			1 octet. When no security is enabled the Sec Length MUST be set
			to value of 0.
			ID Length
			11-bit length of the PVD Identity in a units of 1 octet. The ID
			Length MUST be greater than 0.
	Key Hash		Key Hash
	This field is only present when S=1. A hash of the public key		This field is only present when Sec Length>0. A hash of the
	using the algorithm identified by the Name Type. The procedure		public key using the algorithm identified by the Name Type. The
	how the Key Hash is calculated is defined in [RFC3971] and		procedure how the Key Hash is calculated is defined in [RFC3971]
	[RFC6495].		and [RFC6495].
	Digital Signature		Digital Signature
	This field is only present when S=1. A signature calculated over		This field is only present when Sec Length>0. A signature
	the PVD_CO option including all option data from the beginning of		calculated over the PVD_CO option including all option data from
	the option until to the end of the container. The procedure of		the beginning of the option until to the end of the container.
	calculating the signature is identical to the one defined for		The procedure of calculating the signature is identical to the
	SeND [RFC3971]. During the signature calculation the contents of		one defined for SeND [RFC3971]. During the signature calculation
	the Digital Signature option MUST be treated as all zero.		the contents of the Digital Signature option MUST be treated as
			all zero.
			PVD Identity
			The provisioning domain identity. The contents of this field is
			defined in a separate document [I-D.ietf-mif-mpvd-id].
	Implementations MUST ensure that the PVD container option meets the 8		Implementations MUST ensure that the PVD container option meets the 8
	octets NDP option alignment requirement as described in [RFC4861].		octets NDP option alignment requirement as described in [RFC4861].
	If the PVD_CO does not contain a digital signature, then other means		If the PVD_CO does not contain a digital signature, then other means
	to secure the integrity of the NDP message SHOULD be provided, such		to secure the integrity of the NDP message SHOULD be provided, such
	as utilizing SeND. However, the security provided by SeND is for the		as utilizing SeND. However, the security provided by SeND is for the
	entire NDP message and does not allow verifying whether the sender of		entire NDP message and does not allow verifying whether the sender of
	the NDP message is actually authorized for the information for the		the NDP message is actually authorized for the information for the
	provisioning domain.		provisioning domain.
	If the PVD_CO contains a signature and the verification fails, then		If the PVD_CO contains a signature and the verification fails, then
	the whole PVD_CO, PVD_ID and other NDP options MUST be silently		the whole PVD_CO option MUST be silently ignored and the event SHOULD
	ignored and the event SHOULD be logged.		be logged.
	4. PVD Identity option
	The PVD identity option (PVD_ID) is used to explicitly identity a
	provisioning domain. In an RA message the PVD identity option MUST
	be and in an RS message the PVD identity option SHOULD be
	encapsulated into the associated PVD container option. However, in
	the RS message PVD identity options MAY be included without any PVD
	container options and in this case the PVD identity options serve
	only as a hint for a specific provisioning domains.
	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=PVD_ID | Length | Identity ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: PVD_ID Option
	Type
	PVD identifier; Set to TBD2.
	Length
	Length of the PVD_ID.
	Identity
	The provisioning domain identity. The contents of this field is
	defined in a separate document [I-D.ietf-mif-mpvd-id]. Note that
	the Identity field may need to be zero padded at the tail to
	meets the natural NDP option's alignment.
	If the receiver of a PVD identity option does not have one (or more)
	of the received ID-Type format's implemented, then all configuration
	and options which are associated with the unimplemented PVD(s) MUST
	be silently discarded.
	5. Set of allowable options		4. Set of allowable options
	The PVD container option MAY be used to encapsulate any allocated		The PVD container option MAY be used to encapsulate any allocated
	IPv6 NDP options, which may appear more than once in a NDP message.		IPv6 NDP options, which may appear more than once in a NDP message.
	The PVD container option MUST NOT be used to encapsulate other PVD_CO		The PVD container option MUST NOT be used to encapsulate other PVD_CO
	option(s).		option(s).
	6. Security Considerations		5. Security Considerations
	An attacker may attempt to modify the information provided inside the		An attacker may attempt to modify the information provided inside the
	PVD container option. These attacks can easily be prevented by using		PVD container option. These attacks can easily be prevented by using
	SeND [RFC3971] or per PVD container signature that would detect any		SeND [RFC3971] or per PVD container signature that would detect any
	form of tampering with the IPv6 NDP message contents.		form of tampering with the IPv6 NDP message contents.
	A compromised router may advertise configuration information related		A compromised router may advertise configuration information related
	to provisioning domains it is not authorized to advertise. e.g. A		to provisioning domains it is not authorized to advertise. e.g. A
	coffee shop router may provide configuration information purporting		coffee shop router may provide configuration information purporting
	to be from an enterprise and may try to attract enterprise related		to be from an enterprise and may try to attract enterprise related
	skipping to change at page 7, line 15 ¶		skipping to change at page 6, line 34 ¶
	A compromised configuration source or an on-link attacker may try to		A compromised configuration source or an on-link attacker may try to
	capture advertised configuration information and replay it on a		capture advertised configuration information and replay it on a
	different link or at a future point in time. This can be avoided by		different link or at a future point in time. This can be avoided by
	including some replay protection mechanism such as a timestamp or a		including some replay protection mechanism such as a timestamp or a
	nonce inside the PVD container to ensure freshness of the provided		nonce inside the PVD container to ensure freshness of the provided
	information. This specification does not define a replay protection		information. This specification does not define a replay protection
	solution. Rather it is assumed that if replay protection is		solution. Rather it is assumed that if replay protection is
	required, the access network and hosts also deploy existing security		required, the access network and hosts also deploy existing security
	solutions such as SeND [RFC3971].		solutions such as SeND [RFC3971].
	7. IANA Considerations		6. IANA Considerations
	This document defines two new IPv6 NDP options into the "IPv6		This document defines two new IPv6 NDP options into the "IPv6
	Neighbor Discovery Option Formats" registry. Options TBD1 and TBD2		Neighbor Discovery Option Formats" registry. Option TBD1 is
	are described in Section 3 and Section 4 respectively.		described in Section 3.
	8. Acknowledgements		7. Acknowledgements
	The authors would like to thank the members of the MIF architecture		The authors would like to thank the members of the MIF architecture
	design team for their comments that led to the creation of this		design team for their comments that led to the creation of this
	draft.		draft.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[I-D.ietf-mif-mpvd-id]		[I-D.ietf-mif-mpvd-id]
	Krishnan, S., Korhonen, J., Bhandari, S., and S.		Krishnan, S., Korhonen, J., Bhandari, S., and S.
	Gundavelli, "Identification of provisioning domains",		Gundavelli, "Identification of provisioning domains",
	draft-ietf-mif-mpvd-id-01 (work in progress), February		draft-ietf-mif-mpvd-id-02 (work in progress), October
	2015.		2015.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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,
	skipping to change at page 8, line 15 ¶		skipping to change at page 7, line 36 ¶
	[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate		[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
	Profile and Certificate Management for SEcure Neighbor		Profile and Certificate Management for SEcure Neighbor
	Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494,		Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494,
	February 2012, <http://www.rfc-editor.org/info/rfc6494>.		February 2012, <http://www.rfc-editor.org/info/rfc6494>.
	[RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key		[RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key
	Identifier (SKI) SEcure Neighbor Discovery (SEND) Name		Identifier (SKI) SEcure Neighbor Discovery (SEND) Name
	Type Fields", RFC 6495, DOI 10.17487/RFC6495, February		Type Fields", RFC 6495, DOI 10.17487/RFC6495, February
	2012, <http://www.rfc-editor.org/info/rfc6495>.		2012, <http://www.rfc-editor.org/info/rfc6495>.
	9.2. Informative References		8.2. Informative References
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<http://www.rfc-editor.org/info/rfc6487>.		<http://www.rfc-editor.org/info/rfc6487>.
	[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,
	<http://www.rfc-editor.org/info/rfc7556>.		<http://www.rfc-editor.org/info/rfc7556>.
	skipping to change at page 8, line 27 ¶		skipping to change at page 8, line 4 ¶
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<http://www.rfc-editor.org/info/rfc6487>.		<http://www.rfc-editor.org/info/rfc6487>.
	[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,
	<http://www.rfc-editor.org/info/rfc7556>.		<http://www.rfc-editor.org/info/rfc7556>.
	Appendix A. Examples		Appendix A. Examples
	A.1. One implicit PVD and one explicit PVD		A.1. One implicit PVD and one explicit PVD
	Figure 3 shows how the NDP options are laid out in an RA for one		Figure 2 shows how the NDP options are laid out in an RA for one
	implicit provisioning domain and one explicit provisioning domain.		implicit provisioning domain and one explicit provisioning domain.
	The example does not include security (and signing of the PVD		The example does not include security (and signing of the PVD
	container). The assumption is the PVD identity consumes 14 octets.		container). The assumption is the PVD identity consumes total 18
			octets (for example encoding a NAI Realm string "dana.example.com").
	The explicit provisioning domain ("starducks.example.com" in a NAI		The explicit provisioning domain contains a specific PIO for
	Realm format) contains a specific PIO for 2001:db8:abad:cafe::/64 and		2001:db8:abad:cafe::/64 and the MTU of 1337 octets. The implicit
	the MTU of 1337 octets. The implicit provisioning domain configures		provisioning domain configures a prefix 2001:db8:cafe:babe::/64 and
	a prefix 2001:db8:cafe:babe::/64 and the link MTU of 1500 octets.		the link MTU of 1500 octets. There are two cases: 1) the host
	There are two cases: 1) the host receiving the RA implements		receiving the RA implements provisioning domains and 2) the host does
	provisioning domains and 2) the host does not understand provisioning		not understand provisioning domains.
	domains.
	1. The host recognizes the PVD_CO and "starts" a provisioning domain		1. The host recognizes the PVD_CO and "starts" a provisioning domain
	specific configuration. Security is disabled, thus there are no		specific configuration. Security is disabled, thus there are no
	Key Hash or Digital Signature fields to process. The prefix		Key Hash or Digital Signature fields to process. The prefix
	2001:db8:abad:cafe::/64 is found and configured on the interface.		2001:db8:abad:cafe::/64 is found and configured on the interface.
	Once the PVD_ID option is located the interface prefix		Once the PVD_ID option is located the interface prefix
	configuration for 2001:db8:abad:cafe::/64 and the MTU of 1337		configuration for 2001:db8:abad:cafe::/64 and the MTU of 1337
	octets can be associated to the provisioning domain found in the		octets can be associated to the provisioning domain found in the
	PVD_ID option.		PVD_CO option.
	The rest of the options are parsed and configured into the		The rest of the options are parsed and configured into the
	implicit provisioning domain since there is no encapsulating		implicit provisioning domain since there is no encapsulating
	provisioning domain. The interface is configured with prefix		provisioning domain. The interface is configured with prefix
	2001:db8:cafe:babe::/64. The implicit provisioning domain uses		2001:db8:cafe:babe::/64. The implicit provisioning domain uses
	the link MTU of 1500 octets, whereas the "starducks.example.com"		the link MTU of 1500 octets, whereas the "dana.example.com"
	provisioning domain uses the MTU of 1337 octets (this means when		provisioning domain uses the MTU of 1337 octets (this means when
	packets are sourced using 2001:db8:abad:cafe::/64 prefix the link		packets are sourced using 2001:db8:abad:cafe::/64 prefix the link
	MTU is different than when sourcing packets using		MTU is different than when sourcing packets using
	2001:db8:cafe:babe::/64 prefix).		2001:db8:cafe:babe::/64 prefix).
	2. The host ignores the PVD_CO (including the PVD_ID and other		2. The host ignores the PVD_CO and ends up configuring one prefix on
	options) and ends up configuring one prefix on its interface (		its interface ( 2001:db8:cafe:babe::/64) with a link MTU of 1500
	2001:db8:cafe:babe::/64) with a link MTU of 1500 octets.		octets.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 134 | 0 | Checksum |		| 134 | 0 | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cur Hop Limit |0|1| Reserved | Router Lifetime |		| Cur Hop Limit |0|1| Reserved | Router Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Time |		| Reachable Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Retrans Timer |		| Retrans Timer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
	| Type=PVD_CO | 10 |0| Reserved | 0 | |		| Type=PVD_CO | 8 | 0 | 0 | 0 ~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| 0 | |		~ | 18 | PVD_ID consuming 18 octets | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| 3 | 4 | 64 |1|1| Reserved1 | |		| 3 | 4 | 64 |1|1| Reserved1 | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Valid Lifetime | P		| Valid Lifetime | P
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
	| Preferred Lifetime | D		| Preferred Lifetime | D
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved2 | |		| Reserved2 | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| 2001:db8:abad:cafe:: ~ |		| 2001:db8:abad:cafe:: ~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Type=PVD_ID | 4 | id-type=4 | 21 | |		| 5 | 1 | Reserved | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	~ "starducks.example.com",'\0','\0','\0','\0','\0','\0','\0' | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| 5 | 1 | Reserved | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| 1337 | |		| 1337 | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
	| 3 | 4 | Prefix Length |1|1| Reserved1 |		| 3 | 4 | Prefix Length |1|1| Reserved1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Valid Lifetime |		| Valid Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preferred Lifetime |		| Preferred Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved2 |		| Reserved2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2001:db8:cafe:babe:: ~		| 2001:db8:cafe:babe:: ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 5 | 1 | Reserved |		| 5 | 1 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1500 |		| 1500 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: An RA with one implicit PVD and one explicit PVD		Figure 2: An RA with one implicit PVD and one explicit PVD
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen		Jouni Korhonen
	Broadcom Corporation		Broadcom Limited
	3151 Zanker Road		3151 Zanker Road
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
	Suresh Krishnan		Suresh Krishnan
	Ericsson		Ericsson
	8400 Decarie Blvd.		8400 Decarie Blvd.
	Town of Mount Royal, QC		Town of Mount Royal, QC
End of changes. 42 change blocks.
	133 lines changed or deleted		100 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/