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/ |