draft-ietf-v6ops-rfc3316bis-01.txt   draft-ietf-v6ops-rfc3316bis-02.txt 
IPv6 Operations (V6OPS) J. Korhonen, Ed. IPv6 Operations (V6OPS) J. Korhonen, Ed.
Internet-Draft Renesas Mobile Internet-Draft Renesas Mobile
Obsoletes: 3316 (if approved) J. Arkko, Ed. Obsoletes: 3316 (if approved) J. Arkko, Ed.
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: August 29, 2013 T. Savolainen Expires: November 7, 2013 T. Savolainen
Nokia Nokia
S. Krishnan S. Krishnan
Ericsson Ericsson
February 25, 2013 May 6, 2013
IPv6 for 3GPP Cellular Hosts IPv6 for 3GPP Cellular Hosts
draft-ietf-v6ops-rfc3316bis-01.txt draft-ietf-v6ops-rfc3316bis-02.txt
Abstract Abstract
As the deployment of third and fourth generation cellular networks As the deployment of third and fourth generation cellular networks
progresses, a large number of cellular hosts are being connected to progresses, a large number of cellular hosts are being connected to
the Internet. Standardization organizations are making Internet the Internet. Standardization organizations are making Internet
Protocol version 6 (IPv6) mandatory in their specifications. Protocol version 6 (IPv6) mandatory in their specifications.
However, the concept of IPv6 covers many aspects and numerous However, the concept of IPv6 covers many aspects and numerous
specifications. In addition, the characteristics of cellular links specifications. In addition, the characteristics of cellular links
in terms of bandwidth, cost and delay put special requirements on how in terms of bandwidth, cost and delay put special requirements on how
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 August 29, 2013. This Internet-Draft will expire on November 7, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 32 skipping to change at page 3, line 32
2.11. Neighbor Discovery and additional host configuration . . . 11 2.11. Neighbor Discovery and additional host configuration . . . 11
3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Extension header considerations . . . . . . . . . . . . . 11 3.1. Extension header considerations . . . . . . . . . . . . . 11
4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative references . . . . . . . . . . . . . . . . . . . 14 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14
8.2. Informative references . . . . . . . . . . . . . . . . . . 15 8.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 15 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 16
Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17 Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17
B.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 17 B.1. Version draft-ietf-v6ops-rfc3316bis-02 . . . . . . . . . . 17
B.2. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 17 B.2. Version draft-ietf-v6ops-rfc3316bis-01 . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 B.3. Version draft-ietf-v6ops-rfc3316bis-00 . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Technologies such as GPRS (General Packet Radio Service), UMTS Technologies such as GPRS (General Packet Radio Service), UMTS
(Universal Mobile Telecommunications System), Evolved Packet System (Universal Mobile Telecommunications System), Evolved Packet System
(EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD (EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD
(Enhanced High Rate Packet Data) are making it possible for cellular (Enhanced High Rate Packet Data) are making it possible for cellular
hosts to have an always-on connection to the Internet. IPv6 hosts to have an always-on connection to the Internet. IPv6
[RFC2460] has become essential to such networks as the number of such [RFC2460] has become essential to such networks as the number of such
cellular hosts is increasing rapidly. Standardization organizations cellular hosts is increasing rapidly. Standardization organizations
skipping to change at page 9, line 27 skipping to change at page 9, line 27
A cellular host in a 3GPP network that supports PPP, must support the A cellular host in a 3GPP network that supports PPP, must support the
IPv6CP interface identifier option. This option is needed to be able IPv6CP interface identifier option. This option is needed to be able
to connect other devices to the Internet using a PPP link between the to connect other devices to the Internet using a PPP link between the
cellular device (MT) and other devices (TE, e.g., a laptop). The MT cellular device (MT) and other devices (TE, e.g., a laptop). The MT
performs the PDP Context activation based on a request from the TE. performs the PDP Context activation based on a request from the TE.
This results in an interface identifier being suggested by the MT to This results in an interface identifier being suggested by the MT to
the TE, using the IPv6CP option. To avoid any duplication in link- the TE, using the IPv6CP option. To avoid any duplication in link-
local addresses between the TE and the GGSN/PGW, the MT must always local addresses between the TE and the GGSN/PGW, the MT must always
reject other suggested interface identifiers by the TE. This results reject other suggested interface identifiers by the TE. This results
in the TE always using the interface identifier suggested by the GGSN in the TE always using the interface identifier suggested by the
for its link-local address. GGSN/PGW for its link-local address.
The rejection of interface identifiers suggested by the TE is only The rejection of interface identifiers suggested by the TE is only
done for creation of link-local addresses, according to 3GPP done for creation of link-local addresses, according to 3GPP
specifications. The use of privacy addresses [RFC4941] for unique specifications. The use of privacy addresses [RFC4941] for unique
local IPv6 unicast addresses (ULA) [RFC4193] and global addresses is local IPv6 unicast addresses (ULA) [RFC4193] and global addresses is
not affected by the above procedure. The above procedure is only not affected by the above procedure. The above procedure is only
concerned with assigning the interface identifier used for forming concerned with assigning the interface identifier used for forming
link-local addresses, and does not preclude TE from using other link-local addresses, and does not preclude TE from using other
interface identifiers for addresses with larger scopes (i.e., ULAs interface identifiers for addresses with larger scopes (i.e., ULAs
and global). and global).
skipping to change at page 12, line 30 skipping to change at page 12, line 30
The authors would like to thank Jim Bound, Brian Carpenter, Steve The authors would like to thank Jim Bound, Brian Carpenter, Steve
Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark,
Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing
list for their comments and input. list for their comments and input.
We would also like to thank David DeCamp, Karim El Malki, Markus We would also like to thank David DeCamp, Karim El Malki, Markus
Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and
Shabnam Sultana for their comments and input in preparation of this Shabnam Sultana for their comments and input in preparation of this
document. document.
For the revised version of the RFC 3316 the authors would like thank
Dave Thaler for his comments and input.
7. Security Considerations 7. Security Considerations
This document does not specify any new protocols or functionality, This document does not specify any new protocols or functionality,
and as such, it does not introduce any new security vulnerabilities. and as such, it does not introduce any new security vulnerabilities.
However, specific profiles of IPv6 functionality are proposed for However, specific profiles of IPv6 functionality are proposed for
different situations, and vulnerabilities may open or close depending different situations, and vulnerabilities may open or close depending
on which functionality is included and what is not. There are also on which functionality is included and what is not. There are also
aspects of the cellular environment that make certain types of aspects of the cellular environment that make certain types of
vulnerabilities more severe. The following issues are discussed: vulnerabilities more severe. The following issues are discussed:
o The suggested limitations (Section 3.1) in the processing of o The suggested limitations (Section 3.1) in the processing of
extension headers limits also exposure to Denial-of-Service (DoS) extension headers limits also exposure to Denial-of-Service (DoS)
attacks through cellular hosts. attacks through cellular hosts.
o IPv6 addressing privacy [RFC4941] may be used in cellular hosts. o IPv6 addressing privacy [RFC4941] may be used in cellular hosts.
However, it should be noted that in the 3GPP model, the network However, it should be noted that in the 3GPP model, the network
would assign new addresses, in most cases, to hosts in roaming would assign new addresses, in most cases, to hosts in roaming
situations and typically, also when the cellular hosts activate a situations and typically, also when the cellular hosts activate a
PDP Context or a PDN Connection. This means that 3GPP networks PDP Context or a PDN Connection. This means that 3GPP networks
will already provide a limited form of addressing privacy, and no will already provide a limited form of addressing privacy, and no
global tracking of a single host is possible through its address. global tracking of a single host is possible through its address.
On the other hand, since a GGSN's coverage area is expected to be On the other hand, since a GGSN/PGW's coverage area is expected to
very large when compared to currently deployed default routers (no be very large when compared to currently deployed default routers
handovers between GGSNs are possible), a cellular host can keep an (no handovers between GGSN/PGWs are possible), a cellular host can
address for a long time. Hence, IPv6 addressing privacy can be keep an address for a long time. Hence, IPv6 addressing privacy
used for additional privacy during the time the host is on and in can be used for additional privacy during the time the host is on
the same area. The privacy features can also be used to e.g., and in the same area. The privacy features can also be used to
make different transport sessions appear to come from different IP e.g., make different transport sessions appear to come from
addresses. However, it is not clear that these additional efforts different IP addresses. However, it is not clear that these
confuse potential observers any further, as they could monitor additional efforts confuse potential observers any further, as
only the network prefix part. they could monitor only the network prefix part.
o The use of various security services such as IPsec or TLS in the o The use of various security services such as IPsec or TLS in the
connection of typical applications in cellular hosts is discussed connection of typical applications in cellular hosts is discussed
in Section 3 and further pointer for recommendations are given in Section 3 and further pointer for recommendations are given
there. there.
o The airtime used by cellular hosts is expensive. In some cases, o The airtime used by cellular hosts is expensive. In some cases,
users are billed according to the amount of data they transfer to users are billed according to the amount of data they transfer to
and from their host. It is crucial for both the network and the and from their host. It is crucial for both the network and the
users that the airtime is used correctly and no extra charges are users that the airtime is used correctly and no extra charges are
applied to users due to misbehaving third parties. The cellular applied to users due to misbehaving third parties. The cellular
links also have a limited capacity, which means that they may not links also have a limited capacity, which means that they may not
skipping to change at page 14, line 19 skipping to change at page 14, line 19
o Section 9 of RFC 6459 discusses further some recent concerns o Section 9 of RFC 6459 discusses further some recent concerns
related to cellular hosts security. related to cellular hosts security.
8. References 8. References
8.1. Normative references 8.1. Normative references
[I-D.ietf-6man-nd-extension-headers] [I-D.ietf-6man-nd-extension-headers]
Gont, F., "Security Implications of IPv6 Fragmentation Gont, F., "Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery", with IPv6 Neighbor Discovery",
draft-ietf-6man-nd-extension-headers-03 (work in draft-ietf-6man-nd-extension-headers-04 (work in
progress), January 2013. progress), March 2013.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
skipping to change at page 15, line 43 skipping to change at page 15, line 43
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012. RFC 6459, January 2012.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[TS.23060]
3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", 3GPP TS 23.060 11.5.0, March 2013.
[TS.23401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 11.5.0, March 2013.
[TS.23402]
3GPP, "Architectural enhancements for non-3GPP accesses",
3GPP TS 23.402 11.6.0, March 2013.
[TS.29061]
3GPP, "Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data
Networks (PDN)", 3GPP TS 29.061 11.4.0, March 2013.
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model
The appendix aims to very briefly describe the 3GPP IPv6 addressing The appendix aims to very briefly describe the 3GPP IPv6 addressing
model for 2G (GPRS), 3G (UMTS) and 4G (EPS) cellular networks from model for 2G (GPRS), 3G (UMTS) and 4G (EPS) cellular networks from
Release-99 onwards. More information for 2G and 3G can be found from Release-99 onwards. More information for 2G and 3G can be found from
3GPP Technical Specifications 23.060 and T29.061. The equivalent 3GPP Technical Specifications [TS.23060] and [TS.29061]. The
documentation for 4G can be found from 3GPP Technical Specifications equivalent documentation for 4G can be found from 3GPP Technical
23.401, 23.402 and 29.061. Specifications [TS.23401], [TS.23402] and [TS.29061].
There are two possibilities to allocate the address for an IPv6 node: There are two possibilities to allocate the address for an IPv6 node:
stateless and stateful autoconfiguration. The stateful address stateless and stateful autoconfiguration. The stateful address
allocation mechanism needs a DHCP server to allocate the address for allocation mechanism needs a DHCP server to allocate the address for
the IPv6 node. On the other hand, the stateless autoconfiguration the IPv6 node. On the other hand, the stateless autoconfiguration
procedure does not need any external entity involved in the address procedure does not need any external entity involved in the address
autoconfiguration (apart from the GGSN/PGW). At the time of writing autoconfiguration (apart from the GGSN/PGW). At the time of writing
this document, the IPv6 stateless address autoconfiguration mechanism this document, the IPv6 stateless address autoconfiguration mechanism
is still the only mandatory and supported address configuration is still the only mandatory and supported address configuration
method for the cellular 3GPP link. method for the cellular 3GPP link.
In order to support the standard IPv6 stateless address In order to support the standard IPv6 stateless address
autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW
shall assign a single /64 IPv6 prefix that is unique within its scope shall assign a single /64 IPv6 prefix that is unique within its scope
to each primary PDP Context or PDN Connection that uses IPv6 to each primary PDP Context or PDN Connection that uses IPv6
stateless address autoconfiguration. This avoids the necessity to stateless address autoconfiguration. This avoids the necessity to
perform Duplicate Address Detection (DAD) at the network level for perform Duplicate Address Detection (DAD) at the network level for
every address built by the mobile host. The GGSN/PGW always provides any address built by the mobile host. The GGSN/PGW always provides
an interface identifier to the mobile host. The Mobile host uses the an interface identifier to the mobile host. The Mobile host uses the
interface identifier provided by the GGSN to generate its link-local interface identifier provided by the GGSN/PGW to generate its link-
address. The GGSN/PGW provides the cellular host with the interface local address. The GGSN/PGW provides the cellular host with the
identifier, usually in a random manner. It must ensure the interface identifier, usually in a random manner. It must ensure the
uniqueness of such identifier on the link (i.e., no collisions uniqueness of such identifier on the link (i.e., no collisions
between its own link-local address and the cellular host's). between its own link-local address and the cellular host's).
In addition, the GGSN/PGW will not use any of the prefixes assigned In addition, the GGSN/PGW will not use any of the prefixes assigned
to cellular hosts to generate any of its own addresses. This use of to cellular hosts to generate any of its own addresses. This use of
the interface identifier, combined with the fact that each PDP the interface identifier, combined with the fact that each PDP
Context or PDN Connection is allocated a unique prefix, will Context or PDN Connection is allocated a unique prefix, will
eliminate the need for DAD messages over the air interface, and eliminate the need for DAD messages over the air interface, and
consequently reduces inefficient use of radio resources. consequently reduces inefficient use of radio resources.
Furthermore, the allocation of a prefix to each PDP context will
allow hosts to implement the privacy extensions in RFC 4941 without Furthermore, the allocation of a prefix to each PDP Context or PDN
the need for further DAD messages. Connection will allow hosts to implement the privacy extensions in
[RFC4941] without the need for further DAD messages.
In practice, the GGSN/PGW only needs to route all traffic to the In practice, the GGSN/PGW only needs to route all traffic to the
cellular host that fall under the prefix assigned to it. This cellular host that fall under the prefix assigned to it. This
implies the GGSN/PGW may implement a minimal neighbor discovery implies the GGSN/PGW may implement a minimal neighbor discovery
protocol subset; since, due the point-to-point link model and the protocol subset; since, due the point-to-point link model and the
absence of link-layer addressing the address resolution can be absence of link-layer addressing the address resolution can be
entirely statically configured per PDP Context or PDN Connection, and entirely statically configured per PDP Context or PDN Connection, and
there is no need to defend any other address than the link-local there is no need to defend any other address than the link-local
address for very unlikely duplicates. This has also an additional address for very unlikely duplicates. This has also an additional
effect on a router to host NUD. There is really no need for one, effect on a router to host NUD. There is really no need for, since
since from the GGSN/PGW point of view it does not need to care for from the GGSN/PGW point of view it does not need to care for single
single addresses, just route the whole prefix to the cellular host addresses, just route the whole prefix to the cellular host
direction. Furthermore, 3GPP specifications at the time of writing direction. However, the cellular host must be prepared for the
unlikely event of receiving a NUD against its link-local address. It
should be noted that the 3GPP specifications at the time of writing
this document are silent what should happen if the router to host NUD this document are silent what should happen if the router to host NUD
fails. fails.
See Sections 5 of RFC 6459 for further discussion on 3GPP address See Sections 5 of [RFC6459] for further discussion on 3GPP address
allocation and link model. allocation and link model.
Appendix B. Changes to RFC 3316 Appendix B. Changes to RFC 3316
B.1. Version -01 B.1. Version draft-ietf-v6ops-rfc3316bis-02
o Clarified explicitly that a NUD from the gateway side to the UE's
link-local address is possible.
o Added references to 3GPP specifications.
B.2. Version draft-ietf-v6ops-rfc3316bis-01
o Additional clarification on NUD on 3GPP cellular links. o Additional clarification on NUD on 3GPP cellular links.
o Added an explicit note that the prefix on the link is /64. o Added an explicit note that the prefix on the link is /64.
o Clarified that DHCPv6 (RFC3315) is not used at all for address o Clarified that DHCPv6 (RFC3315) is not used at all for address
autoconfiguration. autoconfiguration.
B.2. Version -00 B.3. Version draft-ietf-v6ops-rfc3316bis-00
o Removal of all sections that can be directly found from RFC 6434. o Removal of all sections that can be directly found from RFC 6434.
o Clarifications to 3GPP link model and how Neighbor Discovery works o Clarifications to 3GPP link model and how Neighbor Discovery works
on it. on it.
o Addition of RFC 4191 recommendations. o Addition of RFC 4191 recommendations.
o Addition of DHCPv6-based Prefix Delegation recommendations. o Addition of DHCPv6-based Prefix Delegation recommendations.
o Addition of RFC 6106 recommendations. o Addition of RFC 6106 recommendations.
o Addition of RFC 5555 regarding client based mobility. o Addition of RFC 5555 regarding client based mobility.
o Addition of Router Advertisement MTU option handling. o Addition of Router Advertisement MTU option handling.
o Addition of Evolved Packet System text. o Addition of Evolved Packet System text.
o Clarification on the primary 3GPP IPv6 transition mechanism. o Clarification on the primary 3GPP IPv6 transition mechanism.
o Addition of RFC 5095 that deprecates the RH0 o Addition of RFC 5095 that deprecates the RH0
o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers
regarding the IPv6 fragmentation handling. regarding the IPv6 fragmentation handling.
o Addition of RFC 6583 for Neighbor Discovery denial-of-service o Addition of RFC 6583 for Neighbor Discovery denial-of-service
 End of changes. 20 change blocks. 
39 lines changed or deleted 71 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/