< draft-korhonen-dmm-prefix-properties-01.txt		draft-korhonen-dmm-prefix-properties-02.txt >
	Distributed Mobility Management (DMM) J. Korhonen		Distributed Mobility Management (DMM) J. Korhonen
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Updates: 4861,3484 (if approved) B. Patil		Updates: 4861 (if approved) B. Patil
	Intended status: Standards Track Nokia		Intended status: Standards Track Nokia
	Expires: September 12, 2012 S. Gundavelli		Expires: January 8, 2013 S. Gundavelli
	Cisco		Cisco
	March 11, 2012		P. Seite
			France Telecom - Orange
			D. Liu
			China Mobile
			July 7, 2012
	IPv6 Prefix Mobility Management Properties		IPv6 Prefix Mobility Management Properties
	draft-korhonen-dmm-prefix-properties-01.txt		draft-korhonen-dmm-prefix-properties-02.txt
	Abstract		Abstract
	This specification defines an extension to the IPv6 Neighbor		This specification defines an extension to the IPv6 Neighbor
	Discovery protocol and its Prefix Information Option. The Prefix		Discovery protocol and its Prefix Information Option. The Prefix
	Information Option is extended with flag bits that describe the		Information Option is extended with flag bits that describe the
	mobility management properties associated to the prefix. This		mobility management properties associated to the prefix. This
	specification updates RFC4861 and also updates RFC3484 Source Address		specification updates RFC4861.
	Selection algorithm.
	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
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 12, 2012.		This Internet-Draft will expire on January 8, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 25 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Background and Motivation . . . . . . . . . . . . . . . . . . . 3		2. Background and Motivation . . . . . . . . . . . . . . . . . . . 3
	3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 6		4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 6
	4.2. Default Address Selection . . . . . . . . . . . . . . . . . 6		4.2. Default Address Selection . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . . 7		7.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Additions to the Socket Interface and the
	Protocol-Independent Nodename Translation . . . . . . 8
	A.1. Socket Interface . . . . . . . . . . . . . . . . . . . . . 8
	A.2. Protocol-Independent Nodename Translation . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This specification defines an extension to the IPv6 Neighbor		This specification defines an extension to the IPv6 Neighbor
	Discovery protocol and its Prefix Information Option (PIO) [RFC4861].		Discovery protocol and its Prefix Information Option (PIO) [RFC4861].
	The Prefix Information Option is extended with flag bits that		The Prefix Information Option is extended with flag bits that
	describe the mobility management properties associated to the prefix,		describe the mobility management properties associated to the prefix,
	and at the same time defines corresponding source address selection		and at the same time defines corresponding source address selection
	hint flags to the IPv6 Socket API for Source Address Selection		hint flags to the IPv6 Socket API for Source Address Selection
	[RFC5014].		[RFC5014].
	The IPv6 Socket API for Source Address Selection [RFC5014] already		The IPv6 Socket API for Source Address Selection [RFC5014] already
	covers Mobile IPv6 [RFC6275] and allows selecting between a home		covers Mobile IPv6 [RFC6275] and allows selecting between a home
	address (HoA) and a care-of address (CoA). A mobile node (MN) with a		address (HoA) and a care-of address (CoA). A mobile node (MN) with a
	client based mobility IP stack is supposed to know which prefixes are		client based mobility IP stack is supposed to know which prefixes are
	CoA(s) and/or HoA(s). The extensions to [RFC4861] are minimal in a		CoA(s) and/or HoA(s). However, this is not the case with network
	sense that they do not define new functionality to any existing		based mobility management where the MN is expected to be agnostic of
	mobility protocol but instead add an explicit indication of network		the mobility support.
	based mobility knowledge into the IPv6 stateless address
	autoconfiguration (SLAAC). This would allow for network based		The extensions to [RFC4861] are minimal in a sense that they do not
	mobility solutions, such as Proxy Mobile IPv6 [RFC5213] or GTP		define new functionality to any existing mobility protocol but
	[TS.29274] to explicitly indicate that their prefixes have mobility,		instead add an explicit indication of network based mobility
	and therefore, the MN IP stack can make an educated selection between		knowledge into the IPv6 stateless address autoconfiguration (SLAAC).
	prefixes that have mobility and those that do not. There is also a
	potential need to extend both [RFC3493] and [RFC5014] in order to		This would allow for network based mobility solutions, such as Proxy
	provide required hooks into socket APIs.		Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that
			their prefixes have mobility, and therefore, the MN IP stack can make
			an educated selection between prefixes that have mobility and those
			that do not. There is also a 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
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 20 ¶
	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		This specification provides extensions to IPv6 address management and
	source address selection so that end hosts (and their applications)		source address selection so that end hosts (and their applications)
	can select a proper address for their needs.		can select a proper address for their needs.
	[to be enhanced]		This specification also shares similar motivations for classifying
			the prefix properties as described in
			[I-D.bhandari-dhc-class-based-prefix].
	3. Option Formats		3. Option Formats
	Neighbor Discovery messages include zero or more options, some of		Neighbor Discovery messages include zero or more options, some of
	which may appear multiple times in the same message. Options should		which may appear multiple times in the same message. Options should
	be padded when necessary to ensure that they end on their natural 64-		be padded when necessary to ensure that they end on their natural 64-
	bit boundaries. Figure 1 illustrates a Prefix Information Option		bit boundaries. Figure 1 illustrates a Prefix Information Option
	[RFC4861] that is extended with flag bits describing the mobility		[RFC4861] that is extended with a mobility and a security property
	properties of the prefix:		flag bit, and a 'class' describing the properties of the prefix:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 3 | 4 | Prefix Length |L|A| Rsvd1 |		| 3 | 4 | Prefix Length |L|A| Rsvd1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Valid Lifetime |		| Valid Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preferred Lifetime |		| Preferred Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| C | Reserved2 |		|M|S| Class | Reserved2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Prefix +		+ Prefix +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Extended Prefix Information Option		Figure 1: Extended Prefix Information Option
	'C' 2-bit flag field describing the mobility properties of the		'M' 1-bit flag describing the mobility properties of the prefix. The
	prefix. The following properties are defined:		following properties are defined:
	00 No specific property associated to the prefix. The prefix is
	treated according to RFC4861.
	01 The prefix may or may not provide network based mobility, and		0 No specific network based mobility property associated to the
	if mobility is provided that is only within a limited area.		prefix. The prefix is treated according to RFC4861.
	Therefore, the end host must be prepared that the prefix may
	become invalid abruptly before the valid or even the
	preferred lifetime expire.
	10 The prefix provides network based mobility and should remain		1 The prefix provides network based mobility and may remain
	unchanged the valid lifetime of the prefix.		unchanged the valid lifetime of the prefix.
	11 Reserved. Treated as '00' by the receiver.		'S' 1-bit flag providing a hint of the security properties associated
			to the used prefix. When set to '0' the prefix is assigned on an
	A common use case is to define 'C' flags when the 'A'=1 i.e. when		interface whose network connectivity to the first-hop router does
	Stateless Address AutoConfiguration (SLAAC) is used. However, it is		not offer any kind of integrity or confidentiality guarantees.
	possible to associate 'C' flags also to prefixes when 'A'=0. In		When set to '1' the prefix is assigned to an interface whose
	cases when there are multiple learned prefixes with 'C' flags set to		network connectivity offers some level of integrity or
	a non-zero value that can also be aggregated, then the longest prefix		confidentiality guarantees between the end host and the first-hop
	takes precedence.		router. For example, the interface could be associated with a
			VPN.
	If the prefix lifetime(s) is set to infinity that does not override		'Class' 14 bits of prefix class. The prefix class adds
	the prefix mobility properties indicated in 'C' flags. For instance,		complementary information to mobility and security properties, as
	a prefix with an infinite lifetime but 'C' flags set to '01' indicate		also described in [I-D.bhandari-dhc-class-based-prefix]. The
	that the prefix is bound to change abruptly due a handover at some		value '0' is reserved and stated nothing about the prefix.
	point of time.		Unknown Class is treated as value '0'.
	'C' flags also define the prefix preference for an IP stack that		We call the combination of the 'M' flag, the 'S' flag and the 'class'
	understands the extensions defined in this specification. The IP		as the 'prefix property'.
	stack SHOULD use the following preferences to supersede
	[I-D.ietf-6man-rfc3484bis] Source Address Selection Rule 8 when
	selecting a default source address among multiple choices and an
	application has not explicitly indicate what kind of source address
	it prefers:
	00 Medium (default) preference.		A common use case is to define the 'M' flag when the 'A'=1 i.e. when
			Stateless Address AutoConfiguration (SLAAC) is used. However, it is
			possible to associate the 'M' flag also to prefixes when 'A'=0. In
			cases when there are multiple learned prefixes with the 'M' flag set
			to a non-zero value that can also be aggregated, then the longest
			prefix takes precedence.
	01 High preference.		If the prefix lifetime(s) is set to infinity that does not override
			the prefix mobility properties indicated in the 'M' flag. For
			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.
	10 Low preference.		A combination where all the 'M', 'S', and 'class' are set to zero
			('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.
	11 Reserved - MUST NOT be used.		Prefix class values from 8192 to 16367 are vendor specific. Class
			values between 16368 and 16383 are reserved for private and
			experimental use.
	4. Host Considerations		4. Host Considerations
	4.1. Internal Data Structures		4.1. Internal Data Structures
	The host internal data structures need to be extended with 'mobility		The host internal data structures need to be extended with the
	property' flag information associated to the learned prefix and		'prefix property' information associated to the learned prefix and
	configured addresses. How this is accomplished is host		configured addresses. How this is accomplished is host
	implementation specific. It is also a host implementation issue how		implementation specific. It is also a host implementation issue how
	an application can learn or query mobility properties of an address		an application can learn or query mobility properties of an address
	or a prefix. One possibility is to provide such information through		or a prefix. One possibility is to provide such information through
	the socket API extensions (see discussion in Appendix A). Other		the socket API extensions (see discussion in
	possibilities include the use of e.g., ioctl() or NetLink [RFC3549]		[I-D.liu-dmm-mobility-api]). Other possibilities include the use of
	extensions.		e.g., ioctl() or NetLink [RFC3549] extensions.
	4.2. Default Address Selection		4.2. Default Address Selection
	The 'mobility property' flags are only used as a hint. They do not		The 'prefix property' information is only used as a hint. They do
	affect the existing [I-D.ietf-6man-rfc3484bis] automatically. A		not affect the existing [I-D.ietf-6man-rfc3484bis] automatically,
	specific rule to host's policy table has to be inserted by an		except for the 'M' flag as described later. A specific rule to
	application or some daemon process. Alternatively, an application		host's policy table has to be inserted by an application or some
	can express its address mobility property preferences through the		daemon process. Alternatively, an application can express its
	socket API extensions (see discussion in Appendix A), which means the		address mobility property preferences through the socket API
	socket library or middleware has to modify [I-D.ietf-6man-rfc3484bis]		extensions (see discussion in [I-D.liu-dmm-mobility-api]), which
	policy table or algorithm.		means the socket library or middleware has to modify
			[I-D.ietf-6man-rfc3484bis] policy table or algorithm.
			The 'M' flag defines the prefix preference for an IP stack that
			understands the extensions defined in this specification. The IP
			stack SHOULD use the following preferences to supersede
			[I-D.ietf-6man-rfc3484bis] Source Address Selection Rule 8 when
			selecting a default source address among multiple choices and an
			application has not explicitly indicate what kind of source address
			it prefers:
			0 Default preference.
			1 Low preference.
	5. Security Considerations		5. 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 such 'mobility property' flags in a
	Prefix Information Option causing the host to learn wrong information		Prefix Information Option causing the host to learn wrong information
	regarding the prefix and thus make misguided selection of prefixes on		regarding the prefix and thus make misguided selection of prefixes on
	the link. Similarly a malicious middleman on the link could modify		the link. Similarly a malicious middleman on the link could modify
	'mobility property' flags in a Prefix Information Option causing		'mobility property' flags in a Prefix Information Option causing
	misguided selection of prefixes. In order to avoid on-link attacks,		misguided selection of prefixes. In order to avoid on-link attacks,
	SeND [RFC3971] can be used to reject Router Advertisements from		SeND [RFC3971] can be used to reject Router Advertisements from
	potentially malicious nodes and guarantee integrity protection of the		potentially malicious nodes and guarantee integrity protection of the
	Router Advertisements.		Router Advertisements.
	6. IANA Considerations		6. IANA Considerations
	Section 3 defines a new flag bits (2 bit 'C' flag) to the IPv6		Section 3 defines a new flag bits and fields to the IPv6 Neighbor
	Neighbor Discovery protocol's Prefix Information Option [RFC4861].		Discovery protocol's Prefix Information Option [RFC4861].
			Section 3 creates a new 'prefix Class' registry under the Internet
			Control Message Protocol version 6 (ICMPv6) Parameters registry.
			Value 0 is reserved. Values from 1 to 8191 are allocated according
			to the RFC Required policy [RFC5226]. Values between 8192 and 16367
			have the First Come First Served allocation policy [RFC5226].
			Finally, values from 16368 to 16383 are reserved for Private Use
			[RFC5226].
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-6man-rfc3484bis]		[I-D.ietf-6man-rfc3484bis]
	Thaler, D., Draves, R., Matsumoto, A., and T. Chown,		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)", draft-ietf-6man-rfc3484bis-01 (work in progress),		(IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress),
	March 2012.		June 2012.
	[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.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	7.2. Informative References		7.2. Informative References
			[I-D.bhandari-dhc-class-based-prefix]
			Systems, C., Halwasia, G., Bandi, S., Gundavelli, S., and
			H. Deng, "DHCPv6 class based prefix",
			draft-bhandari-dhc-class-based-prefix-01 (work in
			progress), March 2012.
			[I-D.liu-dmm-mobility-api]
			Liu, D. and H. Deng, "Mobility API Extension for DMM",
			draft-liu-dmm-mobility-api-00 (work in progress),
			March 2012.
	[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 3493, February 2003.		RFC 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 2003.		July 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.
	skipping to change at page 8, line 5 ¶		skipping to change at page 9, line 18 ¶
	[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.
	[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 2010.		December 2010.
	Appendix A. Additions to the Socket Interface and the Protocol-
	Independent Nodename Translation
	Following sections are for informational and discussion purposes
	only.
	This specification also describes non-normative extensions to both
	Socket Interface [RFC3493][RFC5014] and the Protocol-Independent
	Nodename Translation [RFC5014]. These socket APIs and DNS resolver
	APIs extension correspond to the Prefix Information option mobility
	properties flag bit settings.
	A.1. Socket Interface
	This specification extends the socket option IPV6_ADDR_PREFERENCES at
	the IPPROTO_IPV6 level. The following new flags are defined to
	query, alter or set the default rule of source address selection
	rules [I-D.ietf-6man-rfc3484bis]. They are also defined as a result
	of including the <netinet/in.h> header:
	IPV6_PREFER_SRC_HNP /* Prefer Home Network Prefix derived IPv6
	address as source */
	IPV6_PREFER_SRC_HNP_TMP /* Prefer temoporary Home Network Prefix
	derived IPv6 address as source */
	A.2. Protocol-Independent Nodename Translation
	the Default Address Selection [I-D.ietf-6man-rfc3484bis] document
	indicates possible implementation strategies for getaddrinfo(). The
	address selection hint flags for the getaddrinfo() specificed in this
	document extend the 'int ai_eflags' field in the struct addrinfo
	[RFC5014][RFC3493].
	The IPV6 source address preference values (IPV6_PREFER_SRC_HNP and
	IPV6_PREFER_SRC_HNP_TMP) defined for the IPV6_ADDR_PREFERENCES socket
	option are also defined as address selection preference flags in
	<netdb.h> header for the "ai_eflags" extended flag-set field of the
	addrinfo data structure.
	Similarly to [RFC5014], if contradictory flags, such as
	IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_HNP*, are set in ai_eflags,
	the getaddrinfo() fails and returns the value EAI_BADEXTFLAGS. This
	error value MUST be interpreted into a descriptive text string when
	passed to the gai_strerror() function [RFC3493].
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen		Jouni Korhonen
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	FIN-02600 Espoo		FIN-02600 Espoo
	Finland		Finland
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
	skipping to change at line 380 ¶		skipping to change at page 10, line 4 ¶
	Email: basavaraj.patil@nokia.com		Email: basavaraj.patil@nokia.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
			France Telecom - Orange
			4, rue du Clos Courtel, BP 91226
			Cesson-Sevigne 35512
			France
			Email: pierrick.seite@orange.com
			Dapeng Liu
			China Mobile
			32 Xuanwumen West Street
			Beijng, Xicheng District 100053
			China
			Email: liudapeng@chinamobile.com
End of changes. 31 change blocks.
	130 lines changed or deleted		128 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/