< draft-korhonen-dmm-prefix-properties-03.txt		draft-korhonen-dmm-prefix-properties-04.txt >
	Distributed Mobility Management (DMM) J. Korhonen		Distributed Mobility Management (DMM) J. Korhonen
	Internet-Draft Nokia Siemens Networks		Internet-Draft Broadcom Corporation
	Updates: 4861 (if approved) B. Patil		Updates: 4862 (if approved) S. Gundavelli
	Intended status: Standards Track Nokia		Intended status: Standards Track Cisco
	Expires: April 22, 2013 S. Gundavelli		Expires: January 7, 2016 P. Seite
	Cisco		Orange
	P. Seite
	France Telecom - Orange
	D. Liu		D. Liu
	China Mobile		Alibaba
	October 19, 2012		July 6, 2015
	IPv6 Prefix Mobility Management Properties		IPv6 Prefix Properties
	draft-korhonen-dmm-prefix-properties-03.txt		draft-korhonen-dmm-prefix-properties-04.txt
	Abstract		Abstract
	This specification defines an extension to the IPv6 Neighbor		This specification defines an extension to the IPv6 stateless address
	Discovery protocol and its Prefix Information Option. The Prefix		autoconfiguration procedure. New options with meta data are defined
	Information Option is extended with flag bits that describe the		that describe the properties and other prefix class meta data
	mobility management properties associated to the prefix. This		associated with the prefix. The stateless address autoconfiguration
	specification updates RFC4861.		procedure and end hosts can make use of the additional properties and
			class information when selecting source address prefixes for a
			particular uses and use cases. This specification updates RFC4862.
	Requirements Language		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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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 April 22, 2013.		This Internet-Draft will expire on January 7, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the
			Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Background and Motivation . . . . . . . . . . . . . . . . . . . 3		2. Background and Motivation . . . . . . . . . . . . . . . . . . 3
	3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Prefix Meta Data . . . . . . . . . . . . . . . . . . . . 5
	4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 6		3.2. Meta Data Suboptions . . . . . . . . . . . . . . . . . . 6
	4.2. Default Address Selection . . . . . . . . . . . . . . . . . 6		4. Host Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		4.1. Stateless Address Autoconfiguration Enhancements . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Internal Data Structures . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.3. Default Address Selection . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 8		5. Router Considerations . . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . . 8		6. Multiple Provisioning Domain Considerations . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
			10.1. Normative References . . . . . . . . . . . . . . . . . . 10
			10.2. Informational References . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	This specification defines an extension to the IPv6 Neighbor		This specification defines a new neighbor discovery protocol message
	Discovery protocol and its Prefix Information Option (PIO) [RFC4861].		option, the Prefix Information Option with Meta Data (PIOMD), that
	The Prefix Information Option is extended with flag bits that		indicate, for example, the mobility management properties associated
	describe the mobility management properties associated to the prefix,		to the prefix, and a class value that conveys metadata associated to
	and at the same time defines corresponding source address selection		the prefix with a local administrative domain wide importance. The
	hint flags to the IPv6 Socket API for Source Address Selection		solution may use of Multiple Provisioning Domains (MPVD) framework
	[RFC5014].		[RFC7556] [I-D.ietf-mif-mpvd-ndp-support]. Furthermore, the
			specification discusses corresponding source address selection hint
			issues with the IPv6 Socket API and applications in general
			[I-D.ietf-dmm-ondemand-mobility].
	The IPv6 Socket API for Source Address Selection [RFC5014] already		For example, the IPv6 Socket API for Source Address Selection
	covers Mobile IPv6 [RFC6275] and allows selecting between a home		[RFC5014] already covers Mobile IPv6 [RFC6275] and allows selecting
	address (HoA) and a care-of address (CoA). A mobile node (MN) with a		between a home address (HoA) and a care-of address (CoA). A mobile
	client based mobility IP stack is supposed to know which prefixes are		node (MN) with a client based mobility IP stack is supposed to know
	CoA(s) and/or HoA(s). However, this is not the case with network		which prefixes are CoA(s) and/or HoA(s). However, this is not the
	based mobility management where the MN is expected to be agnostic of		case with network based mobility management where the MN is expected
	the mobility support.		to be agnostic of the mobility support.
	The extensions to [RFC4861] are minimal in a sense that they do not		The extensions are minimal in a sense that they do not define new
	define new functionality to any existing mobility protocol but		functionality, for example, to any existing mobility protocol but
	instead add an explicit indication of network based mobility		instead add an explicit indication of network based mobility
	knowledge into the IPv6 stateless address autoconfiguration (SLAAC).		knowledge into the IPv6 stateless address autoconfiguration (SLAAC)
			[RFC4862]. The heavy lifting is mostly on the applications side and
			on the IP stack providing interface for applications, since they need
			to make use of the new functionality. The new functionality is
			achieved by defining a new, backward compatible, IPv6 neighbor
			discovery protocol options that convey the required prefix related
			meta data information the SLAAC procedure may take use of.
	This would allow for network based mobility solutions, such as Proxy		This would allow for network based mobility solutions, such as Proxy
	Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that		Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that
	their prefixes have mobility, and therefore, the MN IP stack can make		their prefixes have mobility, and therefore, the MN IP stack or
	an educated selection between prefixes that have mobility and those		specifically applications can make an educated selection between
	that do not. There is also a potential need to extend both [RFC3493]		prefixes that have mobility and those that do not. There is also a
	and [RFC5014] in order to provide required hooks into socket APIs.		potential need to extend both [RFC3493] and [RFC5014] in order to
			provide required hooks into socket APIs.
	The underlying assumption is that a MN has multiple prefixes to		The underlying assumption is that a MN has multiple prefixes to
	choose from. Typically this means either the MN has multiple		choose from. Typically this means either the MN has multiple
	interfaces or an interface has been configured with multiple		interfaces or an interface has been configured with multiple
	prefixes. This specification does not make a distinction between		prefixes. This specification does not make a distinction between
	these alternatives and does not either make any assumptions how the		these alternatives and does not either make any assumptions how the
	possible transfer of a prefix is done between interfaces in the case		possible transfer of a prefix is done between interfaces in the case
	a network based mobility solution is used.		a network based mobility solution is used.
	2. Background and Motivation		2. Background and Motivation
			This section discusses the motivations behind adding metadata and
			other address selection decision making affecting information into
			IPv6 prefixes. The additional information is conveyed from the
			network to a end host during the IPv6 address configuration phase.
			The motivation example taken from and discussed below is from the
			mobile networks.
	IP mobility and its centralized topological anchoring of IP addresses		IP mobility and its centralized topological anchoring of IP addresses
	has known issues. For instance, non-optimal routing is a classical		has known issues. For instance, non-optimal routing is a classical
	example. Another concerns include excessive tunneling, increased		example. Another concerns include excessive tunneling, increased
	signaling due the maintenance of mobility related bindings,		signaling due the maintenance of mobility related bindings,
	aggregation of traffic to centralized mobility anchor gateways and		aggregation of traffic to centralized mobility anchor gateways and
	unnecessary IP mobility related state management for IP traffic that		unnecessary IP mobility related state management for IP traffic that
	does not as such benefit from mobility. In general, it is observed		does not as such benefit from mobility. In general, it is observed
	that most applications do not need IP level mobility, and work just		that most applications do not need IP level mobility, and work just
	fine with "temporary" IP addresses that come and go. However, IP		fine with "temporary" IP addresses that come and go. However, IP
	mobility still has its virtues making the applications unaware of		mobility still has its virtues making the applications unaware of
	mobility, and certain wireless mobile networking architecture make		mobility, and certain wireless mobile networking architecture make
	extensive use of network based IP mobility.		extensive use of network based IP mobility.
	In order to overcome some of the above issues, use of local resources		In order to overcome some of the above issues, use of local resources
	and topologically local addressing could be enhanced. In many cases		and topologically local addressing could be enhanced. In many cases
	this would lead to use of multiple addresses of which some provide		this would lead to use of multiple addresses of which some provide
	mobility and some do not. However, an end host has to have means to		mobility and some do not. However, an end host has to have means to
	distinguish between addresses that provide mobility, and those that		distinguish between addresses that provide mobility, and those that
	are short lived and usable only within a limited topological area.		are short lived and usable only within a limited topological area.
	This specification provides extensions to IPv6 address management and
	source address selection so that end hosts (and their applications)
	can select a proper address for their needs.
	This specification also shares similar motivations for classifying		[RFC7333] discussed the requirements for distributed mobility
	the prefix properties as described in		management and [RFC7429] describes the gaps from current best
	[I-D.bhandari-dhc-class-based-prefix].		practices and the desired approaches for de-centralized mobility
			management. One approach is using the dynamic anchoring for
			distributed de-centralized mobility management. The idea is to use
			the local allocated prefix for any newly initiated 'IP session' and
			use the previously allocated prefix for the ongoing sessions. This
			specification can be used to implement the prefix selection for
			dynamic anchoring. For example, both the locally allocated and the
			remotely allocated/anchored prefixes can be identified by the prefix
			property option as described in Section 3.2.
			The solution described in this document also shares similar
			motivations for classifying the prefix as described in
			[I-D.bhandari-dhc-class-based-prefix]. Some service providers may
			wish to allocate specific prefixes for some services or type of
			traffic. In this situation, the end host must be able to classify
			prefixes according to type of service.
			This specification provides tools for extending the IPv6 address
			management and source address selection so that end hosts (and their
			applications) can select a proper address for their needs. This
			specification complements [I-D.bhandari-dhc-class-based-prefix] by
			providing the SLAAC version of the additional prefix related meta
			data information delivery compared to the DHCPv6 stateful approach.
	3. Option Formats		3. Option Formats
			3.1. Prefix Meta Data
	Neighbor Discovery messages include zero or more options, some of		This specification defines a new neighbor discovery protocol message
	which may appear multiple times in the same message. Options should		option, the Prefix Information Option with Meta Data (PIOMD), to be
	be padded when necessary to ensure that they end on their natural 64-		used in router advertisement messages. The PIOMD is treated as the
	bit boundaries. Figure 1 illustrates a Prefix Information Option		same as [RFC4861] Prefix Information Option (PIO) except with an
	[RFC4861] that is extended with a mobility and a security property		addition of new meta data suboptions.
	flag bit, and a 'class' describing the properties of the prefix:
	0 1 2 3		The PIOMD can coexist with RFC4861 PIO. The prefixes advertised in
	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		both PIOMD and PIO can even be the same. It is up to the receiving
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		end host to select the appropriate prefix(es) for configuring its
	| 3 | 4 | Prefix Length |L|A| Rsvd1 |		IPv6 addresses. In a case the PIO and the PIOMD share the same
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		prefix, then all the other parameter (like flags and lifetimes) MUST
	| Valid Lifetime |		be the same.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preferred Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|M|S| Class | Reserved2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	+ +
	| |
	+ Prefix +
	| |
	+ +
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Extended Prefix Information Option		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 | Prefix Length |L|A| Reserved1 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Valid Lifetime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Preferred Lifetime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Reserved2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Prefix +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			: Suboptions :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	'M' 1-bit flag describing the mobility properties of the prefix. The		Figure 1: Prefix Information Option with additional meta data
	following properties are defined:
	0 No specific network based mobility property associated to the		Type
	prefix. The prefix is treated according to RFC4861.
	1 The prefix provides network based mobility and may remain		Set to TBD1.
	unchanged the valid lifetime of the prefix.
	'S' 1-bit flag providing a hint of the security properties associated		Length
	to the used prefix. When set to '0' the prefix is assigned on an
	interface whose network connectivity to the first-hop router does
	not offer any kind of integrity or confidentiality guarantees.
	When set to '1' the prefix is assigned to an interface whose
	network connectivity offers some level of integrity or
	confidentiality guarantees between the end host and the first-hop
	router. For example, the interface could be associated with a
	VPN.
	'Class' 14 bits of prefix class. The prefix class adds		4 if no suboptions are present. Greater than 4 if one or more
	complementary information to mobility and security properties, as		suboptions are present.
	also described in [I-D.bhandari-dhc-class-based-prefix]. The
	value '0' is reserved and stated nothing about the prefix.
	Unknown Class is treated as value '0'.
	We call the combination of the 'M' flag, the 'S' flag and the 'class'		Suboptions
	as the 'prefix property'.
	A common use case is to define the 'M' flag when the 'A'=1 i.e. when		Zero or more suboptions that describe properties and other meta
	Stateless Address AutoConfiguration (SLAAC) is used. However, it is		data attached to the advertised prefix. See Section 3.2 for
	possible to associate the 'M' flag also to prefixes when 'A'=0. In		description of the meta data suboption format and suboptions
	cases when there are multiple learned prefixes with the 'M' flag set		already defined in this specification. The existence of
	to a non-zero value that can also be aggregated, then the longest		suboptions can be determined from the length field. If the
	prefix takes precedence.		length is greater than 4, then at least one suboption MUST be
			present.
	If the prefix lifetime(s) is set to infinity that does not override		Rest of the fields are handled exactly as described in Section 4.6.2.
	the prefix mobility properties indicated in the 'M' flag. For		of RFC4861 [RFC4861].
	instance, a prefix with an infinite lifetime but the 'M' flag set to
	'0' indicate that the prefix may change abruptly due a handover at
	some point of time.
	A combination where all the 'M', 'S', and 'class' are set to zero		3.2. Meta Data Suboptions
	('0') is reserved, and used to indicate that the PIO sender has not
	implemented the extension specified in this document or does not want
	to state anything regarding the PIO.
	Prefix class values from 8192 to 16368 are vendor specific. Class		The generic suboption format for the PIO with meta data (PIOMD) is
	values between 16369 and 16383 are reserved for private and		shown in Figure 2. The suboption follows the alignment and length
	experimental use.		rules familiar from [RFC4861]. On a particular note, the flag 'C'
			describes whether the suboption is mandatory to understand by the
			receiver or not. If 'C' is set to zero (0), the receiver can
			silently discard an unknown suboption and skip to the next suboption.
			If 'C' is set to one (1), then an unknown suboption causes the
			receiver to silently discard the entire PIOMT and no further
			suboptions need to be parsed. There can be multiple instances of the
			same suboption type in one PIOMD option.
			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 |C| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ... ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2: Generic meta data suboption format
			Figure 3 shows the Prefix Properties suboption. The prefix
			properties values are defined in Section 6.1. of
			[I-D.bhandari-dhc-class-based-prefix]. When an end host receives a
			router advertisement message with a PIOMD and the prefix properties
			suboption, it can use the suboption information as an additional hint
			for selecting the prefix for a desired purpose and use case. The
			prefix properties have global meaning i.e., they have the same
			treatment and handling cross administrative domains. The value for
			the 'C' flag SHOULD be one (1). This also implies that if the prefix
			properties bit vector has a flag bit set, which the receiving end
			host does not understand and the 'C' flag is also set, then the whole
			PIOMD option MUST be discarded.
			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 |C| Reserved1 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Prefix properties | Reserved2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 3: Prefix Properties suboption
			Figure 4 shows the Prefix Class suboption. The prefix class values
			and usage follow what has been defined in Section 2.3. of
			[I-D.bhandari-dhc-class-based-prefix]. When an end host receives a
			router advertisement message with a PIOMD and the prefix class
			suboption, it can use the suboption information as an additional hint
			for selecting the prefix for a desired purpose and use case. The
			prefix class has only local administrative meaning i.e., they are
			local to the access network and may overlap both semantically and
			registry wise across different administrative domains. How the
			boundaries of an administrative domain are determined is outside the
			scope of this specification. The value for the 'C' flag SHOULD be
			zero (0).
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 1 | 1 |C| Reserved1 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Prefix class | Reserved2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 4: Prefix Class suboption
			Future specifications MAY define new suboptions. One potential
			example could be a suboption to identify the provisioning domain
			where the configuration information originates.
	4. Host Considerations		4. Host Considerations
	4.1. Internal Data Structures		4.1. Stateless Address Autoconfiguration Enhancements
			This specification extends to the [RFC4862] Stateless Address
			Autoconfiguration (SLAAC). As described in Section 3.1, a new
			[RFC4861] PIO like option PIOMD can be used to either complement or
			entirely replace the PIO in a router advertisement. An end host that
			understands the PIOMD option MUST always prefer a prefix found in the
			PIOMD over the same prefix found in the PIO option.
			4.2. Internal Data Structures
	The host internal data structures need to be extended with the		The host internal data structures need to be extended with the
	'prefix property' information associated to the learned prefix and		'prefix property' and the 'prefix class' information associated to
	configured addresses. How this is accomplished is host		the learned prefix and configured addresses. How this is
	implementation specific. It is also a host implementation issue how		accomplished is host implementation specific. It is also a host
	an application can learn or query mobility properties of an address		implementation issue how an application can learn or query both
	or a prefix. One possibility is to provide such information through		properties or class of an address or a prefix. One possibility is to
	the socket API extensions (see discussion in		provide such information through the socket API extensions (see
	[I-D.liu-dmm-mobility-api]). Other possibilities include the use of		discussion in [I-D.ietf-dmm-ondemand-mobility]). Other possibilities
	e.g., ioctl() or NetLink [RFC3549] extensions.		include the use of e.g., ioctl() or NetLink [RFC3549] extensions.
	4.2. Default Address Selection		4.3. Default Address Selection
	The 'prefix property' information is only used as a hint. They do		The 'prefix property' is only used as a hint. It does not affect the
	not affect the existing [RFC6724] automatically, except for the 'M'		existing [RFC6724] automatically. A specific rule to host's policy
	flag as described later. A specific rule to host's policy table has		table has to be inserted by an application or some daemon process.
	to be inserted by an application or some daemon process.
	Alternatively, an application can express its address mobility		Alternatively, an application can express its address mobility
	property preferences through the socket API extensions (see		property preferences through the socket API extensions (see
	discussion in [I-D.liu-dmm-mobility-api]), which means the socket		discussion in [I-D.ietf-dmm-ondemand-mobility]), which means the
	library or middleware has to modify [RFC6724] policy table or		socket library or middleware has to modify [RFC6724] policy table or
	algorithm.		algorithm.
	The 'M' flag defines the prefix preference for an IP stack that		The 'prefix properties' flags MAY define the prefix preference for an
	understands the extensions defined in this specification. The IP		IP stack that understands the extensions defined in this
	stack SHOULD use the following preferences to supersede [RFC6724]		specification. The IP stack SHOULD use the properties preferences to
	Source Address Selection Rule 8 when selecting a default source		supersede [RFC6724] Source Address Selection Rule 8 when selecting a
	address among multiple choices and an application has not explicitly		default source address among multiple choices and an application has
	indicate what kind of source address it prefers:		not explicitly indicate what kind of source address it prefers.
	0 Default preference.		The 'prefix class' defines an application 'class' the advertised
			prefix is intended to be used for. The class has only local
			administrative domain significance. The 'prefix class' can be used,
			for example, to identify prefixes that are meant to be used reach a
			voice over IP (VoIP) service or a video streaming application within
			the local administrative network. A specific application in the end
			host MAY use this additional class information when enumerating
			through multiple available addresses and then select a specific
			address to be used for its purposes.
	1 Low preference.		5. Router Considerations
	5. Security Considerations		A network administrator MAY configure routers complying to this
			specification also send router advertisements with the PIOMD option
			into every router advertisement that also contains the [RFC4861] PIO
			option. Since the PIOMD sending router has no prior knowledge
			whether the end hosts on the link support the PIOMD option, it is
			strongly RECOMMENDED that both [RFC4861] PIO and the PIOMD are always
			included in the router advertisement, even if the advertised prefixes
			were the same. Alternatively (or in addition) multiple provisioning
			domains [I-D.ietf-mif-mpvd-ndp-support] can be used to separate
			prefixes advertised using PIOMD options. See Section 6 for further
			details.
			A router can also make use of the 'C' flag handling in the PIOMD
			suboptions when introducing new functionality into the network.
			Since it is possible to include multiple suboptions of the same type
			into the PIOMD option, the router can easily make a difference
			between e.g., prefix properties that must be understood by the
			receiver and those that can safely be ignored.
			6. Multiple Provisioning Domain Considerations
			Multiple Provisioning Domains (MPVD) framework [RFC7556] allows
			grouping network configuration information under an explicitly named
			provisioning domain (which can be, for example, a Network Access
			Identifier (NAI) of the mobility service provider
			[I-D.ietf-mif-mpvd-id]). This would allow network operators to place
			mobility related configuration information (including prefixes) under
			specific explicit provisioning domains and non-mobile configuration
			information into other explicit domain or implicit provisioning
			domains.
			MPVDs are the RECOMMENDED way to deliver PIOMD options. This allows
			mobile hosts to query for mobility related configuration information
			and network operators selectively advertise mobility related network
			configurations. MPVDs also provide adequate security features for
			mobile hosts to verify the authenticity of the configuration
			information. However, MPVD does not
			7. Security Considerations
	Existing Prefix Information Option related security considerations		Existing Prefix Information Option related security considerations
	apply as described in [RFC4861] and [RFC4191]. A malicious node on		apply as described in [RFC4861] and [RFC4191]. A malicious node on
	the shared link could include such 'mobility property' flags in a		the shared link could include stale metadata in a PIOMD causing the
	Prefix Information Option causing the host to learn wrong information		host to learn wrong information regarding the prefix and thus make
	regarding the prefix and thus make misguided selection of prefixes on		misguided selection of prefixes on the link. Similarly a malicious
	the link. Similarly a malicious middleman on the link could modify		middleman on the link could modify or remove metadata in the PIOMD
	'mobility property' flags in a Prefix Information Option causing		causing misguided selection of prefixes. In order to avoid on-link
	misguided selection of prefixes. In order to avoid on-link attacks,		attacks, SeND [RFC3971] can be used to reject Router Advertisements
	SeND [RFC3971] can be used to reject Router Advertisements from		from potentially malicious nodes and guarantee integrity protection
	potentially malicious nodes and guarantee integrity protection of the		of the Router Advertisements.
	Router Advertisements.
	6. IANA Considerations		If MPVD support for NDP [I-D.ietf-mif-mpvd-ndp-support] is used, then
			the mobile host can use its security features to verify the
			authenticity and correctness of the received PIOMD information.
	Section 3 defines a new flag bits and fields to the IPv6 Neighbor		8. IANA Considerations
	Discovery protocol's Prefix Information Option [RFC4861].
	Section 3 creates a new 'prefix Class' registry under the Internet		Section 3.1 defines a new IPv6 Neighbor Discovery protocol option
	Control Message Protocol version 6 (ICMPv6) Parameters registry.		type TBD1 for the Prefix Information Option with Meta Data. The type
	Value 0 is reserved. Values from 1 to 8191 are allocated according		value is defined in the existing 'IPv6 Neighbor Discovery Option
	to the RFC Required policy [RFC5226]. Values between 8192 and 16368		Formats' IANA registry.
	have the First Come First Served allocation policy [RFC5226].
	Finally, values from 16398 to 16383 are reserved for Private Use
	[RFC5226].
	7. References		Section 3.2 defines a new IANA registry for the Prefix Information
	7.1. Normative References		Option with Meta Data suboptions. The registry allocation policy is
			Standards Action [RFC5226]. The initial allocations for the prefix
			properties and prefix class suboptions are listed in Section 3.2.
			9. Acknowledgements
			The authors thank Ole Troan for his feedback and suggestions on this
			document (the Classed PIO).
			10. References
			10.1. Normative References
			[I-D.ietf-mif-mpvd-id]
			Krishnan, S., Korhonen, J., Bhandari, S., and S.
			Gundavelli, "Identification of provisioning domains",
			draft-ietf-mif-mpvd-id-01 (work in progress), February
			2015.
			[I-D.ietf-mif-mpvd-ndp-support]
			Korhonen, J., Krishnan, S., and S. Gundavelli, "Support
			for multiple provisioning domains in IPv6 Neighbor
			Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-01
			(work in progress), February 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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
			[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
			Address Autoconfiguration", RFC 4862, September 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., 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, September 2012.		(IPv6)", RFC 6724, September 2012.
	7.2. Informative References		10.2. Informational References
	[I-D.bhandari-dhc-class-based-prefix]		[I-D.bhandari-dhc-class-based-prefix]
	Systems, C., Halwasia, G., Bandi, S., Gundavelli, S.,		Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
	Deng, H., and L. Thiebaut, "DHCPv6 class based prefix",		Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
	draft-bhandari-dhc-class-based-prefix-03 (work in		based prefix", draft-bhandari-dhc-class-based-prefix-05
	progress), July 2012.		(work in progress), July 2013.
	[I-D.liu-dmm-mobility-api]		[I-D.ietf-dmm-ondemand-mobility]
	Liu, D. and H. Deng, "Mobility API Extension for DMM",		Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On
	draft-liu-dmm-mobility-api-00 (work in progress),		Demand Mobility Management", draft-ietf-dmm-ondemand-
	March 2012.		mobility-00 (work in progress), May 2015.
	[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.		[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
	Stevens, "Basic Socket Interface Extensions for IPv6",		Stevens, "Basic Socket Interface Extensions for IPv6", RFC
	RFC 3493, February 2003.		3493, February 2003.
	[RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov,		[RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov,
	"Linux Netlink as an IP Services Protocol", RFC 3549,		"Linux Netlink as an IP Services Protocol", RFC 3549, July
	July 2003.		2003.
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[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, November 2005.		More-Specific Routes", RFC 4191, November 2005.
	[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6		[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
	Socket API for Source Address Selection", RFC 5014,		Socket API for Source Address Selection", RFC 5014,
	September 2007.		September 2007.
	[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,		[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
	and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.		and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
	[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support		[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
	in IPv6", RFC 6275, July 2011.		in IPv6", RFC 6275, July 2011.
			[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
			"Requirements for Distributed Mobility Management", RFC
			7333, August 2014.
			[RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
			Bernardos, "Distributed Mobility Management: Current
			Practices and Gap Analysis", RFC 7429, January 2015.
			[RFC7556] Anipko, D., "Multiple Provisioning Domain Architecture",
			RFC 7556, June 2015.
	[TS.29274]		[TS.29274]
	3GPP, "3GPP Evolved Packet System (EPS); Evolved General		3GPP, "3GPP Evolved Packet System (EPS); Evolved General
	Packet Radio Service (GPRS) Tunnelling Protocol for		Packet Radio Service (GPRS) Tunnelling Protocol for
	Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0,		Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, December
	December 2010.		2010.
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen		Jouni Korhonen
	Nokia Siemens Networks		Broadcom Corporation
	Linnoitustie 6		3151 Zanker Rd.
	FIN-02600 Espoo		CA San Jose
	Finland
	Email: jouni.nospam@gmail.com
	Basavaraj Patil
	Nokia
	6021 Connection Drive
	Irving, TX 75039
	USA		USA
	Email: basavaraj.patil@nokia.com		Email: jouni.nospam@gmail.com
	Sri Gundavelli		Sri Gundavelli
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: sgundave@cisco.com		Email: sgundave@cisco.com
	Pierrick Seite		Pierrick Seite
	France Telecom - Orange		Orange
	4, rue du Clos Courtel, BP 91226		4, rue du Clos Courtel, BP 91226
	Cesson-Sevigne 35512		Cesson-Sevigne 35512
	France		France
	Email: pierrick.seite@orange.com		Email: pierrick.seite@orange.com
	Dapeng Liu		Dapeng Liu
	China Mobile		Alibaba
	32 Xuanwumen West Street
	Beijng, Xicheng District 100053
	China
	Email: liudapeng@chinamobile.com		Email: max.ldp@alibaba-inc.com
End of changes. 58 change blocks.
	204 lines changed or deleted		379 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/