draft-ietf-v6ops-mobile-device-profile-11.txt   draft-ietf-v6ops-mobile-device-profile-12.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: March 13, 2015 A. Vizdal Expires: March 21, 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
September 9, 2014 September 17, 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-11 draft-ietf-v6ops-mobile-device-profile-12
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 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 March 13, 2015. This Internet-Draft will expire on March 21, 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 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . 8 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 8
3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 9 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 9
4. Recommendations for Cellular Devices with LAN Capabilities . 12 4. Recommendations for Cellular Devices with LAN Capabilities . 12
5. APIs & Applications Recommendations . . . . . . . . . . . . . 14 5. APIs & Applications Recommendations . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16 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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
o "Cellular device" and "mobile device" are used interchangeably. o "Cellular device" and "mobile device" are used interchangeably.
PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6
addresses [RFC6052]. addresses [RFC6052].
1.2. Scope 1.2. Scope
A 3GPP mobile network can be used to connect various user equipments A 3GPP mobile network can be used to connect various user equipments
such as a mobile telephone, a CPE (Customer Premises Equipment) or a such as a mobile telephone, a CPE (Customer Premises Equipment) or a
M2M (machine-to-machine) device. Because of this diversity of machine-to-machine (M2M) device. Because of this diversity of
terminals, it is necessary to define a set of IPv6 functionalities terminals, it is necessary to define a set of IPv6 functionalities
valid for any node directly connecting to a 3GPP mobile network. valid for any node directly connecting to a 3GPP mobile network.
This document describes these functionalities. This document describes these functionalities.
This document is structured to provide the generic IPv6 This document is structured to provide the generic IPv6
recommendations which are valid for all nodes, whatever their recommendations which are valid for all nodes, whatever their
function (e.g., host or CPE) or service (e.g., Session Initiation function (e.g., host or CPE) or service (e.g., Session Initiation
Protocol (SIP, [RFC3261])) capability. The document also contains Protocol (SIP, [RFC3261])) capability. The document also contains
sections covering specific functionalities for devices providing some sections covering specific functionalities for devices providing some
LAN functions (e.g., mobile CPE or broadband dongles). LAN functions (e.g., mobile CPE or broadband dongles).
skipping to change at page 10, line 47 skipping to change at page 10, line 47
to the cellular device. Indeed, because several to the cellular device. Indeed, because several
stateful devices may be deployed in wireless networks stateful devices may be deployed in wireless networks
(e.g., NAT and/or Firewalls), PCP can be used by the (e.g., NAT and/or Firewalls), PCP can be used by the
cellular host to control network-based NAT and Firewall cellular host to control network-based NAT and Firewall
functions which will reduce per-application signaling functions which will reduce per-application signaling
and save battery consumption. and save battery consumption.
According to [Power], the consumption of a cellular According to [Power], the consumption of a cellular
device with a keep-alive interval equal to 20 seconds device with a keep-alive interval equal to 20 seconds
(that is the default value in [RFC3948] for example) is (that is the default value in [RFC3948] for example) is
29mA (2G)/34mA (3G). This consumption is reduced to 29 mA (2G)/34 mA (3G). This consumption is reduced to
16mA (2G)/24mA (3G) when the interval is increased to 40 16 mA (2G)/24 mA (3G) when the interval is increased to
seconds, to 9.1mA (2G)/16mA (3G) if the interval is 40 seconds, to 9.1 mA (2G)/16 mA (3G) if the interval is
equal to 150s, and to 7.3mA (2G)/14mA (3G) if the equal to 150 seconds, and to 7.3 mA (2G)/14 mA (3G) if
interval is equal to 180s. When no keep-alive is the interval is equal to 180 seconds. When no keep-
issued, the consumption would be 5.2mA (2G)/6.1mA (3G). alive is issued, the consumption would be 5.2 mA
The impact of keepalive messages would be more severe if (2G)/6.1 mA (3G). The impact of keepalive messages
multiple applications are issuing those messages (e.g., would be more severe if multiple applications are
SIP, IPsec, etc.). issuing those messages (e.g., SIP, IPsec, etc.).
A_REC#4: In order for host-based validation of DNS Security A_REC#4: In order for host-based validation of DNS Security
Extensions (DNSSEC) to continue to function in an IPv6-only Extensions (DNSSEC) to continue to function in an IPv6-only
with NAT64 deployment context, the cellular host should with NAT64 deployment context, the cellular host should
embed a DNS64 function ([RFC6147]). embed a DNS64 function ([RFC6147]).
This is called "DNS64 in stub-resolver mode" in This is called "DNS64 in stub-resolver mode" in
[RFC6147]. [RFC6147].
As discussed in Section 5.5 of [RFC6147], a security- As discussed in Section 5.5 of [RFC6147], a security-
skipping to change at page 13, line 5 skipping to change at page 13, line 5
the WAN (Wide Area Network) and the delegated prefix to the WAN (Wide Area Network) and the delegated prefix to
be aggregatable, so the subscriber can be identified be aggregatable, so the subscriber can be identified
using a single prefix. using a single prefix.
Without the Prefix Exclude Option, the delegating router Without the Prefix Exclude Option, the delegating router
(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
available in some attached networks, L_REC#3 is strongly
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 [RFC6204].
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).
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
solution for distributing prefixes in the LAN side but,
because the device may attach to earlier 3GPP release
networks, a mean to share a /64 prefix is also
recommended [RFC7278].
[RFC7278] must be invoked only if Prefix Delegation is
not in use.
L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only
deployment context, the cellular device should support the deployment context, the cellular device should support the
Customer Side Translator (CLAT) [RFC6877]. Customer Side Translator (CLAT) [RFC6877].
Various IP devices are likely to be connected to Various IP devices are likely to be connected to
cellular device, acting as a CPE. Some of these devices cellular device, acting as a CPE. Some of these devices
can be dual-stack, others are IPv6-only or IPv4-only. can be dual-stack, others are IPv6-only or IPv4-only.
IPv6-only connectivity for cellular device does not IPv6-only connectivity for cellular device does not
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.
skipping to change at page 14, line 47 skipping to change at page 15, line 13
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 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 R. Kuarsingh, E. Kline, S. Josefsson, A. Baryun, and J. Woodyatt for
Chandler for the discussion in the v6ops mailing list. 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. 10 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/