draft-ietf-v6ops-mobile-device-profile-15.txt   draft-ietf-v6ops-mobile-device-profile-16.txt 
V6OPS Working Group D. Binet V6OPS Working Group D. Binet
Internet-Draft M. Boucadair Internet-Draft M. Boucadair
Intended status: Informational France Telecom Intended status: Informational France Telecom
Expires: July 16, 2015 A. Vizdal Expires: August 5, 2015 A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
G. Chen G. Chen
China Mobile China Mobile
N. Heatley N. Heatley
EE EE
R. Chandler R. Chandler
eircom | meteor eircom | meteor
January 12, 2015 February 1, 2015
An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices
draft-ietf-v6ops-mobile-device-profile-15 draft-ietf-v6ops-mobile-device-profile-16
Abstract Abstract
This document defines a profile that is a superset of that of the This document defines a profile that is a superset of that of the
connection to IPv6 cellular networks defined in the IPv6 for Third connection to IPv6 cellular networks defined in the IPv6 for Third
Generation Partnership Project (3GPP) Cellular Hosts document. This Generation Partnership Project (3GPP) Cellular Hosts document. This
document identifies features to deliver IPv4 connectivity service document defines an IPv6 profile that a number of operators recommend
over an IPv6-only transport as well as the required features to in order to connect 3GPP mobile devices to an IPv6-only or dual-stack
connect 3GPP mobile devices to an IPv6-only or dual-stack wireless wireless network (including 3GPP cellular network and IEEE 802.11
network (including 3GPP cellular network and IEEE 802.11 network). network).
Both hosts and devices with capability to share their WAN (Wide Area Both hosts and devices with capability to share their WAN (Wide Area
Network) connectivity are in scope. Network) connectivity are in scope.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 16, 2015. This Internet-Draft will expire on August 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5
2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 7 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 8
3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 8 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 8
4. Recommendations for Cellular Devices with LAN Capabilities . 10 4. Recommendations for Cellular Devices with LAN Capabilities . 10
5. APIs & Applications Recommendations . . . . . . . . . . . . . 12 5. APIs & Applications Recommendations . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
IPv6 deployment in 3GPP mobile networks is the only perennial IPv6 deployment in 3GPP mobile networks is the only perennial
solution to the exhaustion of IPv4 addresses in those networks. solution to the exhaustion of IPv4 addresses in those networks.
Several mobile operators have already deployed IPv6 [RFC2460] or are Several mobile operators have already deployed IPv6 [RFC2460] or are
in the pre-deployment phase. One of the major hurdles encountered by in the pre-deployment phase. One of the major hurdles as perceived
mobile operators is the availability of non-broken IPv6 by some mobile operators is the availability of non-broken IPv6
implementation in mobile devices. implementation in mobile devices.
[RFC7066] lists a set of features to be supported by cellular hosts [RFC7066] lists a set of features to be supported by cellular hosts
to connect to 3GPP mobile networks. In the light of recent IPv6 to connect to 3GPP mobile networks. In the light of recent IPv6
production deployments, additional features to facilitate IPv6-only production deployments, additional features to facilitate IPv6-only
deployments while accessing IPv4-only service are to be considered. deployments while accessing IPv4-only service are to be considered.
This document defines an IPv6 profile for mobile devices listing This document defines an IPv6 profile for mobile devices listing
specifications produced by various Standards Developing Organizations specifications produced by various Standards Developing Organizations
(in particular 3GPP and IETF). The objectives of this effort are: (in particular 3GPP and IETF). The objectives of this effort are:
skipping to change at page 5, line 16 skipping to change at page 5, line 16
Delegation compared to [RFC7066]. The main motivation is that Delegation compared to [RFC7066]. The main motivation is that
cellular networks are more and more perceived as an alternative to cellular networks are more and more perceived as an alternative to
fixed networks for home IP-based services delivery; especially with fixed networks for home IP-based services delivery; especially with
the advent of smartphones and 3GPP data dongles. There is a need for the advent of smartphones and 3GPP data dongles. There is a need for
an efficient mechanism to assign shorter prefix than /64 to cellular an efficient mechanism to assign shorter prefix than /64 to cellular
hosts so that each LAN segment can get its own /64 prefix and multi- hosts so that each LAN segment can get its own /64 prefix and multi-
link subnet issues to be avoided. The support of this functionality link subnet issues to be avoided. The support of this functionality
in both cellular and fixed networks is key for fixed-mobile in both cellular and fixed networks is key for fixed-mobile
convergence. convergence.
This document is not a standard, and conformance with it is not
required in order to claim conformance with IETF standards for IPv6.
The support of the full set of features may not be required in some
deployment contexts. The authors believe that the support of a
subset of the features included in this protocol may lead to degraded
level of service in some deployment contexts.
2. Connectivity Recommendations 2. Connectivity Recommendations
This section identifies the main connectivity recommendations to be This section identifies the main connectivity recommendations to be
followed by a cellular host to attach to a network using IPv6. Both followed by a cellular host to attach to a network using IPv6. Both
dual-stack and IPv6-only deployment models are considered. IPv4 dual-stack and IPv6-only deployment models are considered. IPv4
service continuity features are listed in this section because these service continuity features are listed in this section because these
are critical for Operators with an IPv6-only deployment model. are critical for Operators with an IPv6-only deployment model.
C_REC#1: In order to allow each operator to select their own C_REC#1: In order to allow each operator to select their own
strategy regarding IPv6 introduction, the cellular host strategy regarding IPv6 introduction, the cellular host
skipping to change at page 11, line 16 skipping to change at page 11, line 23
(GGSN/PGW) will have to ensure [RFC3633] compliancy (GGSN/PGW) will have to ensure [RFC3633] compliancy
(e.g., halving the delegated prefix and assigning the (e.g., halving the delegated prefix and assigning the
WAN prefix out of the 1st half and the prefix to be WAN prefix out of the 1st half and the prefix to be
delegated to the terminal from the 2nd half). delegated to the terminal from the 2nd half).
Because Prefix Delegation capabilities may not be Because Prefix Delegation capabilities may not be
available in some attached networks, L_REC#3 is strongly available in some attached networks, L_REC#3 is strongly
recommended to accommodate early deployments. recommended to accommodate early deployments.
L_REC#2: The cellular CPE must be compliant with the requirements L_REC#2: The cellular CPE must be compliant with the requirements
specified in [RFC6204]. specified in [RFC7084].
There are several deployments, particularly in emerging There are several deployments, particularly in emerging
countries, that relies on mobile networks to provide countries, that relies on mobile networks to provide
broadband services (e.g., customers are provided with broadband services (e.g., customers are provided with
mobile CPEs). mobile CPEs).
Note, even if RFC7084 obsoletes [RFC6204], this profile Note, this profile does not require IPv4 service
does not require RFC7084 because IPv4 service continuity continuity techniques listed in [RFC7084] because those
techniques used in mobile networks are not the same as are specific to fixed networks. IPv4 service continuity
in fixed networks. techniques specific to the mobile networks are included
in this profile.
L_REC#3: For deployments requiring to share the same /64 prefix, the L_REC#3: For deployments requiring to share the same /64 prefix, the
cellular device should support [RFC7278] to enable sharing cellular device should support [RFC7278] to enable sharing
a /64 prefix between the 3GPP interface towards the GGSN/ a /64 prefix between the 3GPP interface towards the GGSN/
PGW (WAN interface) and the LAN interfaces. PGW (WAN interface) and the LAN interfaces.
Prefix Delegation (refer to L_REC#1) is the target Prefix Delegation (refer to L_REC#1) is the target
solution for distributing prefixes in the LAN side but, solution for distributing prefixes in the LAN side but,
because the device may attach to earlier 3GPP release because the device may attach to earlier 3GPP release
networks, a mean to share a /64 prefix is also networks, a mean to share a /64 prefix is also
skipping to change at page 12, line 50 skipping to change at page 13, line 12
In particular, the cellular host must support In particular, the cellular host must support
[RFC3596]. [RFC3596].
APP_REC#2: Applications provided by the mobile device vendor must be APP_REC#2: Applications provided by the mobile device vendor must be
independent of the underlying IP address family. independent of the underlying IP address family.
This means applications must be IP version agnostic. This means applications must be IP version agnostic.
APP_REC#3: Applications provided by the mobile device vendor that APP_REC#3: Applications provided by the mobile device vendor that
use Uniform Resource Identifiers (URIs) must follow use Uniform Resource Identifiers (URIs) must follow
[RFC3986]. For example, SIP applications must follow the [RFC3986] and its updates. For example, SIP applications
correction defined in [RFC5954]. must follow the correction defined in [RFC5954].
6. Security Considerations 6. Security Considerations
The security considerations identified in [RFC7066] and [RFC6459] are The security considerations identified in [RFC7066] and [RFC6459] are
to be taken into account. to be taken into account.
Security-related considerations that apply when the cellular device In the case of cellular devices that provide LAN features, compliance
provides LAN features are specified in [RFC6092]. with L_REC#2 entails compliance with [RFC7084], which in turn
recommends compliance with Recommended Simple Security Capabilities
in Customer Premises Equipment (CPE) for Providing Residential IPv6
Internet Service [RFC6092]. Therefore, the security considerations
in Section 6 of [RFC6092] are relevant. In particular, it bears
repeating here that the true impact of stateful filtering may be a
reduction in security, and that IETF make no statement, expressed or
implied, as to whether using the capabilities described in any of
these documents ultimately improves security for any individual users
or for the Internet community as a whole.
The cellular host must be able to generate IPv6 addresses which The cellular host must be able to generate IPv6 addresses which
preserve privacy. The activation of privacy extension (e.g., using preserve privacy. The activation of privacy extension (e.g., using
[RFC7217]) makes it more difficult to track a host over time when [RFC7217]) makes it more difficult to track a host over time when
compared to using a permanent Interface Identifier. Tracking a host compared to using a permanent Interface Identifier. Tracking a host
is still possible based on the first 64 bits of the IPv6 address. is still possible based on the first 64 bits of the IPv6 address.
Means to prevent against such tracking issues may be enabled in the Means to prevent against such tracking issues may be enabled in the
network side. Note, privacy extensions are required by regulatory network side. Note, privacy extensions are required by regulatory
bodies in some countries. bodies in some countries.
skipping to change at page 13, line 33 skipping to change at page 14, line 4
Section 3). Section 3).
7. IANA Considerations 7. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
8. Acknowledgements 8. Acknowledgements
Many thanks to C. Byrne, H. Soliman, H. Singh, L. Colliti, T. Many thanks to C. Byrne, H. Soliman, H. Singh, L. Colliti, T.
Lemon, B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Lemon, B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V.
Kuarsingh, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, and T.
Kossut for the discussion in the v6ops mailing list. Kuarsingh, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, T.
Kossut, and B. Stark for the discussion in the v6ops mailing list.
Thanks to A. Farrel, B. Haberman and K. Moriarty for the comments Thanks to A. Farrel, B. Haberman and K. Moriarty for the comments
during the IESG review. during the IESG review.
Special thanks to T. Savolainen, J. Korhonen, J. Jaeggli, and F. Special thanks to T. Savolainen, J. Korhonen, J. Jaeggli, and F.
Baker for their detailed reviews and comments. Baker for their detailed reviews and comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 15, line 50 skipping to change at page 16, line 22
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012. RFC 6459, January 2012.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
skipping to change at page 16, line 36 skipping to change at page 17, line 5
2013. 2013.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
7050, November 2013. 7050, November 2013.
[RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution
Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, Proposals for Hosts to Learn NAT64 Prefix", RFC 7051,
November 2013. November 2013.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014. Autoconfiguration (SLAAC)", RFC 7217, April 2014.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225, May 2014. Port Control Protocol (PCP)", RFC 7225, May 2014.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project /64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278, June (3GPP) Mobile Interface to a LAN Link", RFC 7278, June
 End of changes. 16 change blocks. 
28 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/