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/