draft-ietf-v6ops-mobile-device-profile-09.txt   draft-ietf-v6ops-mobile-device-profile-10.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 14, 2015 A. Vizdal Expires: March 2, 2015 A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
C. Byrne
T-Mobile
G. Chen G. Chen
China Mobile China Mobile
August 13, 2014 August 29, 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-09 draft-ietf-v6ops-mobile-device-profile-10
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 46
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 14, 2015. This Internet-Draft will expire on March 2, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 8
3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 10 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 9
4. Recommendations for Cellular Devices with LAN Capabilities . 11 4. Recommendations for Cellular Devices with LAN Capabilities . 12
5. APIs & Applications Recommendations . . . . . . . . . . . . . 13 5. APIs & Applications Recommendations . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16
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
mobile operators is the availability of non-broken IPv6 mobile operators is the availability of non-broken IPv6
implementation in mobile devices. implementation in mobile devices.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
C_REC#15: 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#16: In order to ensure IPv4 service continuity in an IPv6-only The IPv4 Service Continuity Prefix used by CLAT is
deployment context, the cellular host should embed a DNS64 defined in [RFC7335].
function [RFC6147].
Local DNS64 functionality allows for compatibility with
DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034],
[RFC4035]). Means to configure or discover a PREFIX64
is also required on the cellular device as discussed in
C_REC#14.
C_REC#17: The cellular host should support PCP [RFC6887].
The support of PCP is seen as a driver to save battery
consumption exacerbated by keepalive messages. PCP
also gives the possibility of enabling incoming
connections to the cellular device. Indeed, because
several stateful devices may be deployed in wireless
networks (e.g., NAT and/or Firewalls), PCP can be used
by the cellular host to control network-based NAT and
Firewall functions which will reduce per-application
signaling and save battery consumption.
C_REC#18: When the cellular host is dual-stack connected (i.e.,
configured with an IPv4 address and IPv6 prefix), it
should support means to prefer native IPv6 connection over
connection established through translation devices (e.g.,
NAT44 and NAT64).
When both IPv4 and IPv6 DNS servers are configured, a
dual-stack host must contact first its IPv6 DNS server.
Cellular hosts should follow the procedure specified in
[RFC6724] for source address selection.
C_REC#19: The cellular host should support Happy Eyeballs procedure
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
particular, WLAN interface must behave properly when only particular, WLAN interface must behave properly when only
skipping to change at page 11, line 22 skipping to change at page 10, line 32
bigger packet headers in IPv6 compared to IPv4. bigger packet headers in IPv6 compared to IPv4.
"RTP/UDP/IP" ROHC profile (0x0001) to compress RTP "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP
packets [RFC3550] and "UDP/IP" ROHC profile (0x0002) to packets [RFC3550] and "UDP/IP" ROHC profile (0x0002) to
compress RTCP packets [RFC3550] are required for Voice compress RTCP packets [RFC3550] are required for Voice
over LTE (VoLTE) by IR.92.4.0 section 4.1 [IR92]. Note, over LTE (VoLTE) by IR.92.4.0 section 4.1 [IR92]. Note,
[IR92] indicates also the host must be able to apply the [IR92] indicates also the host must be able to apply the
compression to packets that are carried over the radio compression to packets that are carried over the radio
bearer dedicated for the voice media. bearer dedicated for the voice media.
A_REC#3: The cellular host must comply with Section 5.3 of [RFC6434] A_REC#3: The cellular host should support PCP [RFC6887].
The support of PCP is seen as a driver to save battery
consumption exacerbated by keepalive messages. PCP also
gives the possibility of enabling incoming connections
to the cellular device. Indeed, because several
stateful devices may be deployed in wireless networks
(e.g., NAT and/or Firewalls), PCP can be used by the
cellular host to control network-based NAT and Firewall
functions which will reduce per-application signaling
and save battery consumption.
According to [Power], the consumption of a cellular
device with a keep-alive interval equal to 20 seconds
(that is the default value in [RFC3948] for example) is
29mA (2G)/34mA (3G). This consumption is reduced to
16mA (2G)/24mA (3G) when the interval is increased to 40
seconds, to 9.1mA (2G)/16mA (3G) if the interval is
equal to 150s, and to 7.3mA (2G)/14mA (3G) if the
interval is equal to 180s. When no keep-alive is
issued, the consumption would be 5.2mA (2G)/6.1mA (3G).
The impact of keepalive messages would be more severe if
multiple applications are issuing those messages (e.g.,
SIP, IPsec, etc.).
A_REC#4: In order for host-based validation of DNS Security
Extensions (DNSSEC) to continue to function in an IPv6-only
with NAT64 deployment context, the cellular host should
embed a DNS64 function ([RFC6147]).
This is called "DNS64 in stub-resolver mode" in
[RFC6147].
As discussed in Section 5.5 of [RFC6147], a security-
aware and validating host has to perform the DNS64
function locally.
Because synthetic AAAA records cannot be successfully
validated in a host, learning the PREFIX64 used to
construct IPv4-converted IPv6 addresses allows the use
of DNSSEC [RFC4033] [RFC4034], [RFC4035]. Means to
configure or discover a PREFIX64 are required on the
cellular device as discussed in C_REC#14.
[RFC7051] discusses why a security-aware and validating
host has to perform the DNS64 function locally and why
it has to be able to learn the proper PREFIX64(s).
A_REC#5: When the cellular host is dual-stack connected (i.e.,
configured with an IPv4 address and IPv6 prefix), it should
support means to prefer native IPv6 connection over
connection established through translation devices (e.g.,
NAT44 and NAT64).
When both IPv4 and IPv6 DNS servers are configured, a
dual-stack host must contact first its IPv6 DNS server.
Cellular hosts should follow the procedure specified in
[RFC6724] for source address selection.
A_REC#6: The cellular host should support Happy Eyeballs procedure
defined in [RFC6555].
A_REC#7: The cellular host must comply with Section 5.3 of [RFC6434]
and should support Router Advertisement extension for and should support Router Advertisement extension for
communicating default router preferences and more-specific communicating default router preferences and more-specific
routes as described in [RFC4191]. routes as described in [RFC4191].
This function can be used for instance for traffic This function can be used for instance for traffic
offload. offload.
4. Recommendations for Cellular Devices with LAN Capabilities 4. Recommendations for Cellular Devices with LAN Capabilities
This section focuses on cellular devices (e.g., CPE, smartphones, or This section focuses on cellular devices (e.g., CPE, smartphones, or
skipping to change at page 13, line 8 skipping to change at page 13, line 36
allow IPv4-only sessions to be established for hosts allow IPv4-only sessions to be established for hosts
connected on the LAN segment of cellular devices. connected on the LAN segment of cellular devices.
In order to allow IPv4 sessions establishment initiated In order to allow IPv4 sessions establishment initiated
from devices located on LAN segment side and target IPv4 from devices located on LAN segment side and target IPv4
nodes, a solution consists in integrating the CLAT nodes, a solution consists in integrating the CLAT
function in the cellular device. As elaborated in function in the cellular device. As elaborated in
Section 2, the CLAT function allows also IPv4 Section 2, the CLAT function allows also IPv4
applications to continue running over an IPv6-only host. applications to continue running over an IPv6-only host.
The IPv4 Service Continuity Prefix used by CLAT is
defined in [RFC7335].
L_REC#5: If a RA MTU is advertised from the 3GPP network, the L_REC#5: If a RA MTU is advertised from the 3GPP network, the
cellular device should relay that upstream MTU information cellular device should relay that upstream MTU information
to the downstream attached LAN devices in RA. to the downstream attached LAN devices in RA.
Receiving and relaying RA MTU values facilitates a more Receiving and relaying RA MTU values facilitates a more
harmonious functioning of the mobile core network where harmonious functioning of the mobile core network where
end nodes transmit packets that do not exceed the MTU end nodes transmit packets that do not exceed the MTU
size of the mobile network's GTP tunnels. size of the mobile network's GTP tunnels.
[TS.23060] indicates providing a link MTU value of 1358 [TS.23060] indicates providing a link MTU value of 1358
skipping to change at page 14, line 16 skipping to change at page 14, line 45
provides LAN features are specified in [RFC6092]. provides LAN features are specified in [RFC6092].
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 C. Byrne, H. Soliman, H. Singh, L. Colliti, T.
Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, Lemon, B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V.
N. Heatley, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, and Kuarsingh, N. Heatley, E. Kline, S. Josefsson, A. Baryun, J.
R. Chandler for the discussion in the v6ops mailing list. Woodyatt, and 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/
skipping to change at page 15, line 34 skipping to change at page 16, line 15
[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.
[RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, [RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan,
"IPv6 for Third Generation Partnership Project (3GPP) "IPv6 for Third Generation Partnership Project (3GPP)
Cellular Hosts", RFC 7066, November 2013. Cellular Hosts", RFC 7066, November 2013.
[TS.23060] [TS.23060]
3GPP, "General Packet Radio Service (GPRS); Service 3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", September 2011. description; Stage 2", September 2011,
<http://www.3gpp.org/DynaReport/23060.htm>.
[TS.23401] [TS.23401]
3GPP, "General Packet Radio Service (GPRS) enhancements 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", September 2011. (E-UTRAN) access", September 2011,
<http://www.3gpp.org/DynaReport/23401.htm>.
[TS.24008] [TS.24008]
3GPP, "Mobile radio interface Layer 3 specification; Core 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", June 2011. network protocols; Stage 3", June 2011,
<http://www.3gpp.org/DynaReport/24008.htm>.
9.2. Informative References 9.2. Informative References
[Power] Haverinen, H., Siren, J., and P. Eronen, "Energy
Consumption of Always-On Applications in WCDMA Networks",
April 2007, <http://ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=4212635>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 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.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
skipping to change at page 17, line 36 skipping to change at page 18, line 29
6877, April 2013. 6877, April 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
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
Proposals for Hosts to Learn NAT64 Prefix", RFC 7051,
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
2014. 2014.
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
August 2014.
[TS.23402] [TS.23402]
3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP, "Architecture enhancements for non-3GPP accesses",
September 2011. September 2011,
<http://www.3gpp.org/DynaReport/23402.htm>.
Authors' Addresses Authors' Addresses
David Binet David Binet
France Telecom France Telecom
Rennes Rennes
France France
EMail: david.binet@orange.com EMail: david.binet@orange.com
skipping to change at page 18, line 26 skipping to change at page 19, line 26
Rennes 35000 Rennes 35000
France France
EMail: mohamed.boucadair@orange.com EMail: mohamed.boucadair@orange.com
Ales Vizdal Ales Vizdal
Deutsche Telekom AG Deutsche Telekom AG
EMail: ales.vizdal@t-mobile.cz EMail: ales.vizdal@t-mobile.cz
Cameron Byrne
T-Mobile
USA
EMail: Cameron.Byrne@T-Mobile.com
Gang Chen Gang Chen
China Mobile China Mobile
EMail: phdgang@gmail.com EMail: phdgang@gmail.com
 End of changes. 20 change blocks. 
65 lines changed or deleted 110 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/