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/ |