draft-ietf-v6ops-3gpp-eps-00.txt		draft-ietf-v6ops-3gpp-eps-01.txt
	Individual Submission J. Korhonen, Ed.		Individual Submission J. Korhonen, Ed.
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Informational J. Soininen		Intended status: Informational J. Soininen
	Expires: October 2, 2011 Renesas Mobile		Expires: November 3, 2011 Renesas Mobile
	B. Patil		B. Patil
	T. Savolainen		T. Savolainen
	G. Bajko		G. Bajko
	Nokia		Nokia
	K. Iisakkila		K. Iisakkila
	Renesas Mobile		Renesas Mobile
	March 31, 2011		May 2, 2011
	IPv6 in 3GPP Evolved Packet System		IPv6 in 3GPP Evolved Packet System
	draft-ietf-v6ops-3gpp-eps-00		draft-ietf-v6ops-3gpp-eps-01
	Abstract		Abstract
	Internet connectivity and use of data services in 3GPP based mobile		Internet connectivity and use of data services in 3GPP based mobile
	networks has increased rapidly as a result of smart phones, broadband		networks has increased rapidly as a result of smart phones, broadband
	service via HSPA and HSPA+ networks, competitive service offerings by		service via HSPA and HSPA+ networks, competitive service offerings by
	operators and a large number of applications. Operators who have		operators and a large number of applications. Operators who have
	deployed networks based on 3GPP architectures are facing IPv4 address		deployed networks based on 3GPP architectures are facing IPv4 address
	shortages. With the impending exhaustion of available IPv4 addresses		shortages. With the impending exhaustion of available IPv4 addresses
	from the registries there is an increased emphasis for operators to		from the registries there is an increased emphasis for operators to
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	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 October 2, 2011.		This Internet-Draft will expire on November 3, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 3, line 22		skipping to change at page 3, line 22
	3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 9		3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 9
	3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 10		3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 10
	4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 11		4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 11		4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 11
	4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 12		4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 13		4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 13
	5. Address Management . . . . . . . . . . . . . . . . . . . . . . 13		5. Address Management . . . . . . . . . . . . . . . . . . . . . . 13
	5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 14		5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 14
	5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 14		5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 14
	5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 15		5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 15
	6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 15		5.4. IPv6 Neighbor Discovery Considerations . . . . . . . . . . 15
	6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 15		6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 16
	6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 16		6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 16
	6.3. PDN Connection Establishment Process . . . . . . . . . . . 17		6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 17
	6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 20		6.3. PDN Connection Establishment Process . . . . . . . . . . . 18
	7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 20		6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 21
	8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 21		7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 21
	8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 21		8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 22
	8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 22		8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 22
	8.3. Operational Aspects of Running Dual-Stack Networks . . . . 23		8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 23
			8.3. Operational Aspects of Running Dual-Stack Networks . . . . 24
	8.4. Operational Aspects of Running a Network with IPv6		8.4. Operational Aspects of Running a Network with IPv6
	Only Bearers . . . . . . . . . . . . . . . . . . . . . . . 23		Only Bearers . . . . . . . . . . . . . . . . . . . . . . . 24
	8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 24		8.5. Restricting Outbound IPv6 Roaming . . . . . . . . . . . . 25
	8.6. Inter-rat Handovers and IP Versions . . . . . . . . . . . 25		8.6. Inter-rat Handovers and IP Versions . . . . . . . . . . . 26
	8.7. Provisioning of IPv6 Subscribers and Various		8.7. Provisioning of IPv6 Subscribers and Various
	Combinations During Initial Network Attachment . . . . . . 26		Combinations During Initial Network Attachment . . . . . . 27
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 27		10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 27		11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 28
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
	13. Informative References . . . . . . . . . . . . . . . . . . . . 28		13. Informative References . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	IPv6 has been specified in the 3rd Generation Partnership Project		IPv6 has been specified in the 3rd Generation Partnership Project
	(3GPP) standards since the early architectures developed for R99		(3GPP) standards since the early architectures developed for R99
	General Packet Radio Service (GPRS). However, the support for IPv6		General Packet Radio Service (GPRS). However, the support for IPv6
	in commercially deployed networks by the end of 2010 is nearly non-		in commercially deployed networks by the end of 2010 is nearly non-
	existent. There are many factors that can be attributed to the lack		existent. There are many factors that can be attributed to the lack
	of IPv6 deployment in 3GPP networks. The most relevant one is		of IPv6 deployment in 3GPP networks. The most relevant one is
	essentially the same as the reason for IPv6 not being deployed by		essentially the same as the reason for IPv6 not being deployed by
	skipping to change at page 14, line 27		skipping to change at page 14, line 27
	Stateful DHCPv6-based address configuration is not supported by 3GPP		Stateful DHCPv6-based address configuration is not supported by 3GPP
	specifications [RFC3315]. On the other hand, Stateless DHCPv6-		specifications [RFC3315]. On the other hand, Stateless DHCPv6-
	service to obtain other configuration information is supported		service to obtain other configuration information is supported
	[RFC3736]. This implies that the M-bit must always be set to zero		[RFC3736]. This implies that the M-bit must always be set to zero
	and the O-bit may be set to one in the Router Advertisement (RA) sent		and the O-bit may be set to one in the Router Advertisement (RA) sent
	to the UE.		to the UE.
	3GPP network allocates each default bearer a unique /64 prefix, and		3GPP network allocates each default bearer a unique /64 prefix, and
	uses layer-2 signaling to suggest user equipment an Interface		uses layer-2 signaling to suggest user equipment an Interface
	Identifier that is guaranteed not to conflict with gateway's		Identifier that is guaranteed not to conflict with gateway's
	Interface Identifier. The UE may configure link local address using		Interface Identifier. The UE must configure its link-local address
	this Interface Identifier, but is allowed to use also other Interface		using this Interface Identifier. The UE is allowed to use any
	Identifiers and as many globally scoped addresses as it needs. There		Interface Identifier it wishes for the other addresses it configures.
	is no restriction, for example, of using Privacy Extension for SLAAC		There is no restriction, for example, of using Privacy Extension for
	[RFC4941] or other similar types of mechanisms.		SLAAC [RFC4941] or other similar types of mechanisms.
	In the 3GPP link model the /64 prefix assigned to the UE is always		In the 3GPP link model the /64 prefix assigned to the UE is always
	off-link (i.e. the L-bit in the Prefix Information Option (PIO) in		off-link (i.e. the L-bit in the Prefix Information Option (PIO) in
	the RA must be set to zero). If the advertised prefix is used for		the RA must be set to zero). If the advertised prefix is used for
	SLAAC then the A-bit in the PIO must be set to one. The details of		SLAAC then the A-bit in the PIO must be set to one. The details of
	the 3GPP link-model and address configuration is described in Section		the 3GPP link-model and address configuration is described in Section
	11.2.1.3.2a of [3GPP.29.061]. More specifically, the GGSN/PDN-GW		11.2.1.3.2a of [3GPP.29.061]. More specifically, the GGSN/PDN-GW
	guarantees that the /64 prefix is unique for the mobile host.		guarantees that the /64 prefix is unique for the mobile host.
	Therefore, there is no need to perform any Duplicate Address		Therefore, there is no need to perform any Duplicate Address
	Detection (DAD) on addresses the mobile host creates (i.e., the		Detection (DAD) on addresses the mobile host creates (i.e., the
	skipping to change at page 15, line 31		skipping to change at page 15, line 31
	described in Section 12.1 of [RFC3633] that a prefix delegated to a		described in Section 12.1 of [RFC3633] that a prefix delegated to a
	requesting router cannot be used by the delegating router (i.e., the		requesting router cannot be used by the delegating router (i.e., the
	PDN-GW in this case). This implies the shorter 'delegated prefix'		PDN-GW in this case). This implies the shorter 'delegated prefix'
	cannot be given to the requesting router (i.e. the user equipment) as		cannot be given to the requesting router (i.e. the user equipment) as
	such but has to be delivered by the delegating router (i.e. the		such but has to be delivered by the delegating router (i.e. the
	PDN-GW) in such a way the /64 prefix allocated to the default bearer		PDN-GW) in such a way the /64 prefix allocated to the default bearer
	is not part of the 'delegated prefix'. IETF is working on a solution		is not part of the 'delegated prefix'. IETF is working on a solution
	for DHCPv6-based prefix delegation to exclude a specific prefix from		for DHCPv6-based prefix delegation to exclude a specific prefix from
	the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].		the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].
			5.4. IPv6 Neighbor Discovery Considerations
			3GPP link between the UE and the next hop router (e.g. GGSN)
			resemble a point to point (p2p) link, which has no link-layer
			addresses [RFC3316] and this has not changed from 2G/3G GPRS to EPS.
			The UE IP stack has to take this into consideration. When the 3GPP
			PDP Context appears as a PPP interface/link to the UE, the IP stack
			is usually prepared to handle Neighbor Discovery protocol and the
			related Neighbor Cache state machine transitions in an appropriate
			way, even thought Neighbor Discovery protocol messages contain no
			link layer address information. However, some operating systems
			discard Router Advertisements on their PPP interface/link as a
			default setting. This causes the SLAAC to fail when the 3GPP PDP
			Context gets established, thus stalling all IPv6 traffic.
			Currently several operating systems and their network drivers can
			make the 3GPP PDP Context to appear as an IEEE802 interface/link to
			the IP stack. This has few known issues, especially when the IP
			stack is made to believe the underlying link has link-layer
			addresses. First, the Neighbor Advertisement sent by a GGSN as a
			response to an address resolution triggered Neighbor Solicitation may
			not contain a Target Link-Layer address option (as suggested in
			[RFC4861] Section 4.4). Then it is possible that the address
			resolution never completes when the UE tries to resolve the link-
			layer address of the GGSN, thus stalling all IPv6 traffic.
			Second, the GGSN may simply discard all address resolution triggered
			Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1
			that address resolution and next-hop determination are not needed).
			As a result the address resolution never completes when the UE tries
			to resolve the link-layer address of the GGSN, thus stalling all IPv6
			traffic.
	6. 3GPP Dual-Stack Approach to IPv6		6. 3GPP Dual-Stack Approach to IPv6
	6.1. 3GPP Networks Prior to Release-8		6.1. 3GPP Networks Prior to Release-8
	3GPP standards prior to Release-8 provide IPv6 access for cellular		3GPP standards prior to Release-8 provide IPv6 access for cellular
	devices with PDP contexts of type IPv6 [3GPP.23.060]. For dual-stack		devices with PDP contexts of type IPv6 [3GPP.23.060]. For dual-stack
	access, a PDP context of type IPv6 is established in parallel to the		access, a PDP context of type IPv6 is established in parallel to the
	PDP context of type IPv4, as shown in Figure 5 and Figure 6. For		PDP context of type IPv4, as shown in Figure 5 and Figure 6. For
	IPv4-only service, connections are created over the PDP context of		IPv4-only service, connections are created over the PDP context of
	type IPv4 and for IPv6-only service connections are created over the		type IPv4 and for IPv6-only service connections are created over the
	skipping to change at page 23, line 50		skipping to change at page 24, line 50
	was defined that a dual-stack mobile host (or when the radio		was defined that a dual-stack mobile host (or when the radio
	equipment has no knowledge of the host IP stack capabilities) must		equipment has no knowledge of the host IP stack capabilities) must
	first attempt to establish a dual-stack bearer and then possibly fall		first attempt to establish a dual-stack bearer and then possibly fall
	back to single IP version bearer. A Release-8 (or later) mobile host		back to single IP version bearer. A Release-8 (or later) mobile host
	with IPv6 only stack can directly attempt to establish an IPv6 only		with IPv6 only stack can directly attempt to establish an IPv6 only
	bearer. The IPv6 only behavior is up to a subscription provisioning		bearer. The IPv6 only behavior is up to a subscription provisioning
	or a PDN-GW configuration, and the fallback scenarios do not		or a PDN-GW configuration, and the fallback scenarios do not
	necessarily cause additional signaling.		necessarily cause additional signaling.
	Although the bullets below introduce IPv6 to IPv4 address translation		Although the bullets below introduce IPv6 to IPv4 address translation
	and specifically discuss NAT64 technology		and specifically discuss NAT64 technology [RFC6144], the current 3GPP
	[I-D.ietf-behave-v6v4-framework], the current 3GPP Release-8		Release-8 architecture does not describe the use of address
	architecture does not describe the use of address translation or		translation or NAT64. It is up to a specific deployment whether
	NAT64. It is up to a specific deployment whether address translation		address translation is part of the network or not. Some operational
	is part of the network or not. Some operational aspects to consider		aspects to consider for running a network with IPv6 only bearers:
	for running a network with IPv6 only bearers:
	o The mobile hosts must have an IPv6 capable stack and a radio		o The mobile hosts must have an IPv6 capable stack and a radio
	interface capable of establishing an IPv6 PDP context or PDN		interface capable of establishing an IPv6 PDP context or PDN
	connection.		connection.
	o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6		o The GGSN/PDN-GW must be IPv6 capable in order to support IPv6
	bearers. Furthermore, the SGSN/MME must allow the creation of PDP		bearers. Furthermore, the SGSN/MME must allow the creation of PDP
	Type or PDN Type of IPv6.		Type or PDN Type of IPv6.
	o Many of the common applications are IP version agnostic and hence		o Many of the common applications are IP version agnostic and hence
	skipping to change at page 26, line 37		skipping to change at page 27, line 36
	mobile host that is IPv6 only capable must attempt to establish a		mobile host that is IPv6 only capable must attempt to establish a
	PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4 only		PDP/PDN Type IPv6 bearer. Last, a mobile host that is IPv4 only
	capable must attempt to establish a PDN/PDP Type IPv4 bearer.		capable must attempt to establish a PDN/PDP Type IPv4 bearer.
	In a case the PDP/PDN Type requested by a mobile host does not match		In a case the PDP/PDN Type requested by a mobile host does not match
	what has been provisioned for the subscriber in the HSS (or HLR), the		what has been provisioned for the subscriber in the HSS (or HLR), the
	mobile host possibly falls back to a different PDP/PDN Type. The		mobile host possibly falls back to a different PDP/PDN Type. The
	network (i.e. the MME or the SGSN) is able to inform the mobile host		network (i.e. the MME or the SGSN) is able to inform the mobile host
	during the network attachment signaling why it did not get the		during the network attachment signaling why it did not get the
	requested PDP/PDN Type. These response/cause codes are documented in		requested PDP/PDN Type. These response/cause codes are documented in
	[3GPP.24.008][3GPP.24.301]. Possible fall back cases include (as		[3GPP.24.008][3GPP.24.301]:
	documented in [3GPP.23.401]):
			o ESM cause #50 "PDN type IPv4 only allowed".
			o ESM cause #51 "PDN type IPv6 only allowed".
			o ESM cause #52 "single address bearers only allowed".
			The above respone/cause codes apply to Release-8 and onwards. In
			pre-Release-8 networks used response/cause codes vary depending on
			the vendor, unfortunately.
			Possible fall back cases include (as documented in [3GPP.23.401]):
	o Requested & provisioned PDP/PDN Types match -> requested.		o Requested & provisioned PDP/PDN Types match -> requested.
	o Requested IPv4v6 & provisioned IPv6 -> IPv6 and a mobile host		o Requested IPv4v6 & provisioned IPv6 -> IPv6 and a mobile host
	receives indication that IPv6-only bearer is allowed.		receives indication that IPv6-only bearer is allowed.
	o Requested IPv4v6 & provisioned IPv4 -> IPv4 and the mobile host		o Requested IPv4v6 & provisioned IPv4 -> IPv4 and the mobile host
	receives indication that IPv4-only bearer is allowed.		receives indication that IPv4-only bearer is allowed.
	o Requested IPv4v6 & provisioned IPv4_or_IPv6 -> IPv4 or IPv6 is		o Requested IPv4v6 & provisioned IPv4_or_IPv6 -> IPv4 or IPv6 is
	skipping to change at page 29, line 18		skipping to change at page 30, line 29
	[3GPP.29.274]		[3GPP.29.274]
	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.
	[GSMA.IR.34]		[GSMA.IR.34]
	GSMA, "Inter-PLMN Backbone Guidelines", GSMA		GSMA, "Inter-PLMN Backbone Guidelines", GSMA
	PRD IR.34.4.9, March 2010.		PRD IR.34.4.9, March 2010.
	[I-D.ietf-behave-v6v4-framework]
	Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
	IPv4/IPv6 Translation",
	draft-ietf-behave-v6v4-framework-10 (work in progress),
	August 2010.
	[I-D.ietf-dhc-pd-exclude]		[I-D.ietf-dhc-pd-exclude]
	Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,		Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
	"Prefix Exclude Option for DHCPv6-based Prefix		"Prefix Exclude Option for DHCPv6-based Prefix
	Delegation", draft-ietf-dhc-pd-exclude-01 (work in		Delegation", draft-ietf-dhc-pd-exclude-01 (work in
	progress), January 2011.		progress), January 2011.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets",		E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, March 1997.		RFC 2131, March 1997.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
			[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
			Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
			Second and Third Generation Cellular Hosts", RFC 3316,
			April 2003.
	[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic		[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol		[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
	(DHCP) Service for IPv6", RFC 3736, April 2004.		(DHCP) Service for IPv6", RFC 3736, April 2004.
	[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery		[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
	Proxies (ND Proxy)", RFC 4389, April 2006.		Proxies (ND Proxy)", RFC 4389, April 2006.
			[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
			"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
			September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, September 2007.		IPv6", RFC 4941, 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.
			[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
			IPv4/IPv6 Translation", RFC 6144, April 2011.
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen (editor)		Jouni Korhonen (editor)
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	FI-02600 Espoo		FI-02600 Espoo
	FINLAND		FINLAND
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
	Jonne Soininen		Jonne Soininen
	Renesas Mobile		Renesas Mobile
			Porkkalankatu 24
			FI-00180 Helsinki
			FINLAND
	Email: jonne.soininen@renesasmobile.com		Email: jonne.soininen@renesasmobile.com
	Basavaraj Patil		Basavaraj Patil
	Nokia		Nokia
	6021 Connection drive		6021 Connection drive
	Irving, TX 75039		Irving, TX 75039
	USA		USA
	Email: basavaraj.patil@nokia.com		Email: basavaraj.patil@nokia.com
	Teemu Savolainen		Teemu Savolainen
	Nokia		Nokia
	skipping to change at page 31, line 14		skipping to change at page 32, line 30
	Gabor Bajko		Gabor Bajko
	Nokia		Nokia
	323 Fairchild drive 6		323 Fairchild drive 6
	Mountain view, CA 94043		Mountain view, CA 94043
	USA		USA
	Email: gabor.bajko@nokia.com		Email: gabor.bajko@nokia.com
	Kaisu Iisakkila		Kaisu Iisakkila
	Renesas Mobile		Renesas Mobile
			Porkkalankatu 24
			FI-00180 Helsinki
			FINLAND
	Email: kaisu.iisakkila@renesasmobile.com		Email: kaisu.iisakkila@renesasmobile.com
End of changes. 18 change blocks.
	44 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/