draft-ietf-v6ops-mobile-device-profile-08.txt   draft-ietf-v6ops-mobile-device-profile-09.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: February 12, 2015 A. Vizdal Expires: February 14, 2015 A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
C. Byrne C. Byrne
T-Mobile T-Mobile
G. Chen G. Chen
China Mobile China Mobile
August 11, 2014 August 13, 2014
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-08 draft-ietf-v6ops-mobile-device-profile-09
Abstract Abstract
This document defines an IPv6 profile that a number of operators This document defines an IPv6 profile that a number of operators
recommend in order to connect 3GPP mobile devices to an IPv6-only or recommend in order to connect 3GPP mobile devices to an IPv6-only or
dual-stack wireless network (including 3GPP cellular network and IEEE dual-stack wireless network (including 3GPP cellular network and IEEE
802.11 network). 802.11 network).
This document defines a different profile than the one for general This document defines a different profile than the one for general
connection to IPv6 cellular networks defined in the IPv6 for Third connection to IPv6 cellular networks defined in the IPv6 for Third
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 February 12, 2015. This Internet-Draft will expire on February 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Language Considerations . . . . . . . . . . . . . . . . . 4 1.3. Language Considerations . . . . . . . . . . . . . . . . . 4
2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5
2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 9 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 9
3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 10 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 10
4. Recommendations for Cellular Devices with LAN Capabilities . 11 4. Recommendations for Cellular Devices with LAN Capabilities . 11
5. APIs & Applications Recommendations . . . . . . . . . . . . . 13 5. APIs & Applications Recommendations . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 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 encountered by
skipping to change at page 7, line 45 skipping to change at page 7, line 45
C_REC#11: If the cellular host receives the DNS information in C_REC#11: If the cellular host receives the DNS information in
several channels for the same interface, the following several channels for the same interface, the following
preference order must be followed: preference order must be followed:
1. PCO 1. PCO
2. RA 2. RA
3. DHCPv6 3. DHCPv6
C_REC#12: Because of potential operational deficiencies to be C_REC#12: The cellular host must be able to be configured to limit
PDP type(s) for a given APN. The default mode is to allow
all supported PDP types. Note, C_REC#3 discusses the
default behavior for requesting PDP-Context type(s).
This feature is useful to drive the behavior of the UE
to be aligned with: (1) service-specific constraints
such as the use of IPv6-only for VoLTE (Voice over
LTE), (2) network conditions with regards to the
support of specific PDP types (e.g., IPv4v6 PDP-Context
is not supported), (3) IPv4 sunset objectives, (4)
subscription data, etc.
C_REC#13: Because of potential operational deficiencies to be
experienced in some roaming situations, the cellular host experienced in some roaming situations, the cellular host
must be able to be configured with a home IP profile and a must be able to be configured with a home IP profile and a
roaming IP profile. The aim of the roaming profile is to roaming IP profile. The aim of the roaming profile is to
limit the PDP type(s) requested by the cellular host when limit the PDP type(s) requested by the cellular host when
out of the home network. Note, distinct PDP type(s) can out of the home network. Note, distinct PDP type(s) can
be configured for home and roaming cases. be configured for home and roaming cases.
C_REC#13: In order to ensure IPv4 service continuity in an IPv6-only C_REC#14: In order to ensure IPv4 service continuity in an IPv6-only
deployment context, the cellular host should support a deployment context, the cellular host should support a
method to locally construct IPv4-embedded IPv6 addresses method to locally construct IPv4-embedded IPv6 addresses
[RFC6052]. A method to learn PREFIX64 should be supported [RFC6052]. A method to learn PREFIX64 should be supported
by the cellular host. by the cellular host.
This solves the issue when applications use IPv4 This solves the issue when applications use IPv4
referrals on IPv6-only access networks. referrals on IPv6-only access networks.
In PCP-based environments, cellular hosts should follow In PCP-based environments, cellular hosts should follow
[RFC7225] to learn the IPv6 Prefix used by an upstream [RFC7225] to learn the IPv6 Prefix used by an upstream
PCP-controlled NAT64 device. If PCP is not enabled, PCP-controlled NAT64 device. If PCP is not enabled,
the cellular host should implement the method specified the cellular host should implement the method specified
in [RFC7050] to retrieve the PREFIX64. in [RFC7050] to retrieve the PREFIX64.
C_REC#14: In order to ensure IPv4 service continuity in an IPv6-only C_REC#15: In order to ensure IPv4 service continuity in an IPv6-only
deployment context, the cellular host should implement the deployment context, the cellular host should implement the
Customer Side Translator (CLAT, [RFC6877]) function which Customer Side Translator (CLAT, [RFC6877]) function which
is compliant with [RFC6052][RFC6145][RFC6146]. is compliant with [RFC6052][RFC6145][RFC6146].
CLAT function in the cellular host allows for IPv4-only CLAT function in the cellular host allows for IPv4-only
application and IPv4-referals to work on an IPv6-only application and IPv4-referals to work on an IPv6-only
connectivity. CLAT function requires a NAT64 connectivity. CLAT function requires a NAT64
capability [RFC6146] in the core network. capability [RFC6146] in the core network.
C_REC#15: In order to ensure IPv4 service continuity in an IPv6-only C_REC#16: In order to ensure IPv4 service continuity in an IPv6-only
deployment context, the cellular host should embed a DNS64 deployment context, the cellular host should embed a DNS64
function [RFC6147]. function [RFC6147].
Local DNS64 functionality allows for compatibility with Local DNS64 functionality allows for compatibility with
DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034], DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034],
[RFC4035]). Means to configure or discover a PREFIX64 [RFC4035]). Means to configure or discover a PREFIX64
is also required on the cellular device as discussed in is also required on the cellular device as discussed in
C_REC#13. C_REC#14.
C_REC#16: The cellular host should support PCP [RFC6887]. C_REC#17: The cellular host should support PCP [RFC6887].
The support of PCP is seen as a driver to save battery The support of PCP is seen as a driver to save battery
consumption exacerbated by keepalive messages. PCP consumption exacerbated by keepalive messages. PCP
also gives the possibility of enabling incoming also gives the possibility of enabling incoming
connections to the cellular device. Indeed, because connections to the cellular device. Indeed, because
several stateful devices may be deployed in wireless several stateful devices may be deployed in wireless
networks (e.g., NAT and/or Firewalls), PCP can be used networks (e.g., NAT and/or Firewalls), PCP can be used
by the cellular host to control network-based NAT and by the cellular host to control network-based NAT and
Firewall functions which will reduce per-application Firewall functions which will reduce per-application
signaling and save battery consumption. signaling and save battery consumption.
C_REC#17: When the cellular host is dual-stack connected (i.e., C_REC#18: When the cellular host is dual-stack connected (i.e.,
configured with an IPv4 address and IPv6 prefix), it configured with an IPv4 address and IPv6 prefix), it
should support means to prefer native IPv6 connection over should support means to prefer native IPv6 connection over
connection established through translation devices (e.g., connection established through translation devices (e.g.,
NAT44 and NAT64). NAT44 and NAT64).
When both IPv4 and IPv6 DNS servers are configured, a When both IPv4 and IPv6 DNS servers are configured, a
dual-stack host must contact first its IPv6 DNS server. dual-stack host must contact first its IPv6 DNS server.
Cellular hosts should follow the procedure specified in Cellular hosts should follow the procedure specified in
[RFC6724] for source address selection. [RFC6724] for source address selection.
C_REC#18: The cellular host should support Happy Eyeballs procedure C_REC#19: The cellular host should support Happy Eyeballs procedure
defined in [RFC6555]. defined in [RFC6555].
2.1. WLAN Connectivity Recommendations 2.1. WLAN Connectivity Recommendations
It is increasingly common for cellular hosts have a WLAN interface in It is increasingly common for cellular hosts have a WLAN interface in
addition to their cellular interface. These hosts are likely to be addition to their cellular interface. These hosts are likely to be
connected to private or public hotspots. Below are listed some connected to private or public hotspots. Below are listed some
generic recommendations: generic recommendations:
W_REC#1: IPv6 must be supported on the WLAN interface. In W_REC#1: IPv6 must be supported on the WLAN interface. In
skipping to change at page 10, line 17 skipping to change at page 10, line 29
order must be followed: order must be followed:
1. RA 1. RA
2. DHCPv6 2. DHCPv6
3. Advanced Recommendations 3. Advanced Recommendations
This section identifies a set of advanced recommendations to meet This section identifies a set of advanced recommendations to meet
regulatory constraints in some countries, fulfill requirements of regulatory constraints in some countries, fulfill requirements of
critical services such as VoLTE (Voice over LTE), or enforce policies critical services such as VoLTE, or enforce policies such as traffic
such as traffic offload. offload.
A_REC#1: The cellular host must be able to generate IPv6 addresses A_REC#1: The cellular host must be able to generate IPv6 addresses
which preserve privacy. which preserve privacy.
The activation of privacy extension (e.g., using The activation of privacy extension (e.g., using
[RFC4941] or [RFC7217]) makes it more difficult to track [RFC4941] or [RFC7217]) makes it more difficult to track
a host over time when compared to using a permanent a host over time when compared to using a permanent
Interface Identifier. Note, [RFC4941] does not require Interface Identifier. Note, [RFC4941] does not require
any DAD mechanism to be activated as the GGSN/PGW must any DAD mechanism to be activated as the GGSN/PGW must
not configure any global address based on the prefix not configure any global address based on the prefix
skipping to change at page 13, line 49 skipping to change at page 14, line 18
Address privacy considerations are discussed in [RFC4941] [RFC7217]. Address privacy considerations are discussed in [RFC4941] [RFC7217].
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 H. Soliman, H. Singh, L. Colliti, T. Lemon, B. Many thanks to H. Soliman, H. Singh, L. Colliti, T. Lemon, B.
Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh,
N. Heatley, E. Kline, S. Josefsson, A. Baryun, and J. Woodyatt N. Heatley, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, and
for the discussion in the v6ops mailing list. R. Chandler for the discussion in the v6ops mailing list.
Special thanks to T. Savolainen, J. Korhonen, and J. Jaeggli for Special thanks to T. Savolainen, J. Korhonen, and J. Jaeggli for
their detailed reviews and comments. their detailed reviews and comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March [IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March
2011, <http://www.gsma.com/newsroom/ 2011, <http://www.gsma.com/newsroom/
 End of changes. 15 change blocks. 
18 lines changed or deleted 31 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/