diff options
Diffstat (limited to 'doc/rfc/rfc7849.txt')
| -rw-r--r-- | doc/rfc/rfc7849.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7849.txt b/doc/rfc/rfc7849.txt new file mode 100644 index 0000000..2848e42 --- /dev/null +++ b/doc/rfc/rfc7849.txt @@ -0,0 +1,1235 @@ + + + + + + +Independent Submission D. Binet +Request for Comments: 7849 M. Boucadair +Category: Informational Orange +ISSN: 2070-1721 A. Vizdal + Deutsche Telekom AG + G. Chen + China Mobile + N. Heatley + EE + R. Chandler + eircom | meteor + D. Michaud + Rogers Communications + D. Lopez + Telefonica I+D + W. Haeffner + Vodafone + May 2016 + + + An IPv6 Profile for 3GPP Mobile Devices + +Abstract + + This document defines a profile that is a superset of the connection + to IPv6 cellular networks defined in the IPv6 for Third Generation + Partnership Project (3GPP) Cellular Hosts document. This document + defines a profile that is a superset of the connections to IPv6 + cellular networks defined in "IPv6 for Third Generation Partnership + Project (3GPP) Cellular Hosts" (RFC 7066). + + Both mobile hosts and mobile devices with the capability to share + their 3GPP mobile connectivity are in scope. + +IESG Note + + The consensus-based IETF description of IPv6 functionality for + cellular hosts is described in RFC 7066. + + + + + + + + + + + + + +Binet, et al. Informational [Page 1] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7849. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 6 + 3. Recommendations for Cellular Devices with LAN Capabilities . 11 + 4. Advanced Recommendations . . . . . . . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 6.2. Informative References . . . . . . . . . . . . . . . . . 17 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + + + + + + + + + +Binet, et al. Informational [Page 2] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + +1. Introduction + + IPv6 deployment in 3GPP mobile networks is the only viable solution + to the exhaustion of IPv4 addresses in those networks. Several + mobile operators have already deployed IPv6 [RFC2460] or are in the + pre-deployment phase. One of the major hurdles as perceived by some + mobile operators is the lack of availability of working IPv6 + implementation in mobile devices (e.g., Section 3.3 of [OECD]). + + [RFC7066] lists a set of features to be supported by cellular hosts + to connect to 3GPP mobile networks. In the light of recent IPv6 + production deployments, additional features to facilitate IPv6-only + deployments while accessing IPv4-only services should be considered. + + This document fills this void. Concretely, this document lists means + to ensure IPv4 service over an IPv6-only connectivity given the + adoption rate of this model by mobile operators. Those operators + require that no service degradation is experienced by customers + serviced with an IPv6-only model compared to the level of service of + customers with legacy IPv4-only devices. + + This document defines an IPv6 profile for mobile devices listing + specifications produced by various Standards Developing Organizations + (including 3GPP, IETF, and the Global System for Mobile + Communications Association (GSMA)). The objectives of this effort + are as follows: + + 1. List in one single document a comprehensive list of IPv6 features + for a mobile device, including both IPv6-only and dual-stack + mobile deployment contexts. These features cover various packet + core architectures such as General Packet Radio Service (GPRS) or + Evolved Packet Core (EPC). + + 2. Help operators with the detailed device requirement list + preparation (to be exchanged with device suppliers). This is + also a contribution to harmonize operators' requirements towards + device vendors. + + 3. Inform vendors of a set of features to allow for IPv6 + connectivity and IPv4 service continuity (over an IPv6-only + transport). + + The recommendations do not include 3GPP release details. For more + information on the 3GPP release details, the reader may refer to + Section 6.2 of [RFC6459]. More details can be found at [R3GPP]. + + + + + + +Binet, et al. Informational [Page 3] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + Some of the features listed in this profile document could require + that dedicated functions be activated at the network side. It is out + of scope of this document to list these network-side functions. + + A detailed overview of IPv6 support in 3GPP architectures is provided + in [RFC6459]. IPv6-only considerations in mobile networks are + further discussed in [RFC6342]. + + This document is organized as follows: + + o Section 2 lists generic recommendations, including functionalities + to provide IPv4 service over an IPv6-only connectivity. + + o Section 3 enumerates a set of recommendations for cellular devices + with Local Area Network (LAN) capabilities (e.g., Customer Edge + (CE) routers with cellular access link, dongles with tethering + features). + + o Section 4 identifies a set of advanced recommendations to fulfill + requirements of critical services such as VoLTE (Voice over LTE). + +1.1. Terminology + + This document makes use of the terms defined in [RFC6459]. In + addition, the following terms are used: + + o 3GPP cellular host (or "cellular host" for short): denotes a 3GPP + device that can be connected to 3GPP mobile networks. + + o 3GPP cellular device (or "cellular device" for short): refers to a + cellular host that supports the capability to share its 3GPP + mobile connectivity. + + o IPv4 service continuity: denotes the features used to provide + access to IPv4-only services to customers serviced with an + IPv6-only connectivity. A typical example of IPv4 service + continuity technique is Network Address and Protocol Translation + from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146]. + + PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 + addresses [RFC6052]. + + + + + + + + + + +Binet, et al. Informational [Page 4] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + +1.2. Scope + + A 3GPP mobile network can be used to connect various User Equipment + (UE) such as a mobile telephone or a CE router. Because of this + diversity of terminals, it is necessary to define a set of IPv6 + functionalities valid for any node directly connecting to a 3GPP + mobile network. This document describes these functionalities. + + The machine-to-machine (M2M) devices profile is out of scope. + + This document is structured to provide the generic IPv6 + recommendations that are valid for all nodes, whatever their function + (e.g., host or CE router) or service (e.g., Session Initiation + Protocol (SIP) [RFC3261]) capability. The document also contains + sections covering specific functionalities for devices providing some + LAN functions (e.g., mobile CE router or broadband dongles). + + The recommendations listed below are valid for both 3GPP GPRS and + 3GPP Evolved Packet System (EPS). For EPS, the term "PDN-Connection" + is used instead of PDP-Context. Other non-3GPP accesses [TS.23402] + are out of scope of this document. + + This profile is a superset of that of the IPv6 profile for 3GPP + Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node + Requirements [RFC6434]. It targets cellular nodes, including GPRS + and EPC, that require features to ensure IPv4 service delivery over + an IPv6-only transport in addition to the base IPv6 service. + Moreover, this profile also covers cellular CE routers that are used + in various mobile broadband deployments. Recommendations inspired + from real deployment experiences (e.g., roaming) are included in this + profile. Also, this profile sketches recommendations for the sake of + deterministic behaviors of cellular devices when the same + configuration information is received over several channels. + + For conflicting recommendations in [RFC7066] and [RFC6434] (e.g., + Neighbor Discovery Protocol), this profile adheres to [RFC7066]. + Indeed, the support of Neighbor Discovery Protocol is mandatory in + 3GPP cellular environment as it is the only way to convey an IPv6 + prefix towards the 3GPP cellular device. In particular, Maximum + Transmission Unit (MTU) communication via Router Advertisement (RA) + must be supported since many 3GPP networks do not have a standard MTU + setting. + + This profile uses a stronger language for the support of Prefix + Delegation compared to [RFC7066]. The main motivation is that + cellular networks are more and more perceived as an alternative to + fixed networks for home IP-based services delivery; especially with + the advent of smartphones and 3GPP data dongles. There is a need for + + + +Binet, et al. Informational [Page 5] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + an efficient mechanism to assign larger prefixes to cellular 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 in + both cellular and fixed networks is key for fixed-mobile convergence. + + The use of address-family-dependent Application Programming + Interfaces (APIs) or hard-coded IPv4 address literals may lead to + broken applications when IPv6 connectivity is in use. As such, means + to minimize broken applications when the cellular host is attached to + an IPv6-only network should be encouraged. Particularly, (1) name + resolution libraries (e.g., [RFC3596]) must support both IPv4 and + IPv6; (2) applications must be independent of the underlying IP + address family; and (3) applications relying upon Uniform Resource + Identifiers (URIs) must follow [RFC3986] and its updates. Note, some + IETF specifications (e.g., SIP [RFC3261]) contains broken IPv6 + Augmented Backus-Naur Form (ABNF) and rules to compare URIs with + embedded IPv6 addresses; fixes (e.g., [RFC5954]) must be used + instead. + + The recommendations included in each section are listed in a priority + order. + + This document is not a standard, and conformance with it is not + required in order to claim conformance with IETF standards for IPv6. + Compliance with this profile does not require the support of all + enclosed items. Obviously, the support of the full set of features + may not be required in some deployment contexts. However, the + authors believe that not supporting relevant features included in + this profile (e.g., Customer-Side Translator (CLAT) [RFC6877]) may + lead to a degraded level of service. + +2. Connectivity Recommendations + + This section identifies the main connectivity recommendations to be + followed by a cellular host to attach to a network using IPv6 in + addition to what is defined in [RFC6434] and [RFC7066]. Both dual- + stack and IPv6-only deployment models are considered. IPv4 service + continuity features are listed in this section because these are + critical for operators with an IPv6-only deployment model. These + recommendations apply also for cellular devices (see Section 3). + + C_REC#1: In order to allow each operator to select their own + strategy regarding IPv6 introduction, the cellular host + must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. + + IPv4, IPv6, or IPv4v6 PDP-Context request acceptance + depends on the cellular network configuration. + + + + +Binet, et al. Informational [Page 6] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + C_REC#2: The cellular host must comply with the behavior defined in + [TS.23060], [TS.23401], and [TS.24008] for requesting a + PDP-Context type. + + In particular, the cellular host must request by default an + IPv6 PDP-Context if the cellular host is IPv6-only and + request an IPv4v6 PDP-Context if the cellular host is dual- + stack or when the cellular host is not aware of + connectivity types requested by devices connected to it + (e.g., a cellular host with LAN capabilities as discussed + in Section 3): + + * If the requested IPv4v6 PDP-Context is not supported by + the network but IPv4 and IPv6 PDP types are allowed, + then the cellular host will be configured with an IPv4 + address or an IPv6 prefix by the network. It must + initiate another PDP-Context activation of the other + address family in addition to the one already activated + for a given Access Point Name (APN). The purpose of + initiating a second PDP-Context is to achieve dual-stack + connectivity by means of two PDP-Contexts. + + * If the subscription data or network configuration allows + only one IP address family (IPv4 or IPv6), the cellular + host must not request a second PDP-Context to the same + APN for the other IP address family. + + The network informs the cellular host about allowed Packet + Data Protocol (PDP) types by means of Session Management + (SM) cause codes. In particular, the following cause codes + can be returned: + + * cause #50 "PDP type IPv4 only allowed" - This cause code + is used by the network to indicate that only PDP type + IPv4 is allowed for the requested Public Data Network + (PDN) connectivity. + + * cause #51 "PDP type IPv6 only allowed" - This cause code + is used by the network to indicate that only PDP type + IPv6 is allowed for the requested PDN connectivity. + + * cause #52 "single address bearers only allowed" - This + cause code is used by the network to indicate that the + requested PDN connectivity is accepted with the + restriction that only single IP version bearers are + allowed. + + + + + +Binet, et al. Informational [Page 7] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + The text above focuses on the specification (an excerpt + from [TS.23060], [TS.23401], and [TS.24008]) that explains + the behavior for requesting IPv6-related PDP-Context(s). + + C_REC#3: The cellular host must support the Protocol Configuration + Options (PCOs) [TS.24008] to retrieve the IPv6 address(es) + of the Recursive DNS server(s). + + The 3GPP network communicates parameters by means of the + protocol configuration options information element when + activating, modifying, or deactivating a PDP-Context. + PCO is a convenient method to inform the cellular host + about various services, including DNS server + information. It does not require additional protocol to + be supported by the cellular host and it is already + deployed in IPv4 cellular networks to convey such DNS + information. + + C_REC#4: The cellular host must support IPv6-aware Traffic Flow + Templates (TFTs) [TS.24008]. + + Traffic Flow Templates are employing a packet filter to + couple an IP traffic with a PDP-Context. Thus, a + dedicated PDP-Context and radio resources can be + provided by the cellular network for certain IP traffic. + + C_REC#5: If the cellular host receives the DNS information in + several channels for the same interface, the following + preference order must be followed: + + 1. PCO + + 2. RA + + 3. DHCPv6 + + The purpose of this recommendation is to guarantee for a + deterministic behavior to be followed by all cellular hosts + when the DNS information is received in various channels. + + C_REC#6: Because of potential operational deficiencies to be + experienced in some roaming situations, the cellular host + must be able to be configured with a home PDP-Context + type(s) and a roaming PDP-Context type(s). The purpose of + the roaming profile is to limit the PDP type(s) requested + by the cellular host when out of the home network. Note + that distinct PDP type(s) and APN(s) can be configured for + home and roaming cases. + + + +Binet, et al. Informational [Page 8] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + A detailed analysis of roaming failure cases is included + in [RFC7445]. + + The configuration can be either local to the device or + be managed dynamically using, for example, Open Mobile + Alliance (OMA) management. The support of dynamic means + is encouraged. + + C_REC#7: In order to ensure IPv4 service continuity in an IPv6-only + deployment context, the cellular host should support a + method to learn PREFIX64(s). + + In the context of NAT64, IPv6-enabled applications + relying on address referrals will fail because an + IPv6-only client will not be able to make use of an IPv4 + address received in a referral. This feature allows for + solving the referral problem (because an IPv6-enabled + application can construct IPv4-embedded IPv6 addresses + [RFC6052]) and, also, for distinguishing between + IPv4-converted IPv6 addresses and native IPv6 addresses. + + In other words, this feature contributes to offload both + the CLAT module and NAT64 devices. Refer to Section 3 + of [RFC7051] for an inventory of the issues related to + the discovery of PREFIX64(s). + + In environments based on the Port Control Protocol + (PCP), cellular hosts should follow [RFC7225] to learn + the IPv6 Prefix used by an upstream PCP-controlled NAT64 + device. If PCP is not enabled, the cellular host should + implement the method specified in [RFC7050] to retrieve + the PREFIX64. + + C_REC#8: In order to ensure IPv4 service continuity in an IPv6-only + deployment context, the cellular host should implement the + CLAT [RFC6877] function in compliance with [RFC6052], + [RFC6145], and [RFC6146]. + + The CLAT function in the cellular host allows for + IPv4-only application and IPv4 referrals to work on an + IPv6-only connectivity. The more applications are + address family independent, the less the CLAT function + is solicited. The CLAT function requires a NAT64 + capability [RFC6146] in the network. + + The cellular host should only invoke CLAT in the absence + of IPv4 connectivity on the cellular side, i.e., when + the network does not assign an IPv4 address on the + + + +Binet, et al. Informational [Page 9] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + cellular interface. Note, NAT64 assumes an IPv6-only + mode [RFC6146]. + + The IPv4 Service Continuity Prefix used by CLAT is + defined in [RFC7335]. + + CLAT and/or NAT64 do not interfere with native IPv6 + communications. + + CLAT may not be required in some contexts, e.g., if + other solutions such as Bump-in-the-Host (BIH) [RFC6535] + are supported. + + The cellular device can act as a CE router connecting + various IP hosts on a LAN segment; this is also the case + with using WLAN (Wireless LAN) tethering or a WLAN + hotspot from the cellular device. Some of these IP + hosts can be dual-stack, others are IPv6-only or + IPv4-only. IPv6-only connectivity on the cellular + device does not allow IPv4-only sessions to be + established for hosts connected on the LAN segment of + the cellular device. IPv4 session establishment + initiated from hosts located on the LAN segment side and + destined for IPv4 nodes must be maintained. A solution + is to integrate the CLAT function to the LAN segment in + the cellular device. + + C_REC#9: The cellular host may 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#2 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, (2) network + conditions with regard to the support of specific PDP + types (e.g., IPv4v6 PDP-Context is not supported), (3) + IPv4 sunset objectives, (4) subscription data, etc. + + Note, a cellular host changing its connection between an + IPv6-specific APN and an IPv4-specific APN will + interrupt related network connections. This may be + considered as a brokenness situation by some + applications. + + The configuration can be either local to the device or + be managed dynamically using, for example, OMA + management. The support of dynamic means is encouraged. + + + +Binet, et al. Informational [Page 10] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + +3. Recommendations for Cellular Devices with LAN Capabilities + + This section focuses on cellular devices (e.g., CE routers, + smartphones, or dongles with tethering features) that provide IP + connectivity to other devices connected to them. In this case, all + connected devices are sharing the same 2G, 3G, or LTE connection. In + addition to the generic recommendations listed in Section 2, these + cellular devices have to meet the recommendations listed below. + + L_REC#1: For deployments that require that the same /64 prefix be + shared, the cellular device should support [RFC7278] to + enable sharing a /64 prefix between the LAN and the WAN + interfaces. The WAN interface is the one towards the + Gateway GPRS Support Node (GGSN) / Packet Data Network + Gateway (PGW). + + Prefix Delegation (refer to L_REC#2) is the target + solution for distributing prefixes in the LAN side but, + because the device may attach to earlier 3GPP release + networks, a means to share a /64 prefix is also + recommended [RFC7278]. + + [RFC7278] must be invoked only if Prefix Delegation is + not in use. + + L_REC#2: The cellular device must support Prefix Delegation + capabilities [RFC3633] and must support the Prefix Exclude + Option for DHCPv6-based Prefix Delegation as defined in + [RFC6603]. Particularly, it must behave as a Requesting + Router. + + Cellular networks are more and more perceived as an + alternative to fixed broadband networks for home IP- + based services delivery; especially with the advent of + smartphones and 3GPP data dongles. There is a need for + an efficient mechanism to assign larger prefixes (other + than /64s) to cellular hosts so that each LAN segment + can get its own /64 prefix and multi-link subnet issues + to be avoided. + + In case a prefix is delegated to a cellular host using + DHCPv6, the cellular device will be configured with two + prefixes: + + (1) one for the 3GPP link allocated using the Stateless + Address Autoconfiguration (SLAAC) mechanism and + + + + + +Binet, et al. Informational [Page 11] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + (2) another one delegated for LANs acquired during the + Prefix Delegation operation. + + Note that the 3GPP network architecture requires both + the WAN and the delegated prefix to be aggregatable so + the subscriber can be identified using a single prefix. + + Without the Prefix Exclude Option, the delegating router + (GGSN/PGW) will have to ensure compliance with [RFC3633] + (e.g., halving the delegated prefix and assigning the + WAN prefix out of the first half and the prefix to be + delegated to the terminal from the second half). + + Because Prefix Delegation capabilities may not be + available in some attached networks, L_REC#1 is strongly + recommended to accommodate early deployments. + + L_REC#3: The cellular CE router must be compliant with the + requirements specified in [RFC7084]. + + There are several deployments, particularly in emerging + countries, that rely on mobile networks to provide + broadband services (e.g., customers are provided with + mobile CE routers). + + Note, this profile does not require IPv4 service + continuity techniques listed in Section 4.4 of [RFC7084] + because those are specific to fixed networks. IPv4 + service continuity techniques specific to the mobile + networks are included in this profile. + + This recommendation does not apply to handsets with + tethering capabilities; it is specific to cellular CE + routers in order to ensure the same IPv6 functional + parity for both fixed and cellular CE routers. Note, + modern CE routers are designed with advanced functions + such as link aggregation that consists in optimizing the + network usage by aggregating the connectivity resources + offered via various interfaces (e.g., Digital Subscriber + Line (DSL), LTE, WLAN, etc.) or offloading the traffic + via a subset of interfaces. Ensuring IPv6 feature + parity among these interface types is important for the + sake of specification efficiency, service design + simplification, and validation effort optimization. + + + + + + + +Binet, et al. Informational [Page 12] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + L_REC#4: If an RA MTU is advertised from the 3GPP network, the + cellular device should send RAs to the downstream attached + LAN devices with the same MTU as seen on the mobile + interface. + + Receiving and relaying RA MTU values facilitates a more + harmonious functioning of the mobile core network where + end nodes transmit packets that do not exceed the MTU + size of the mobile network's tunnels that use the GPRS + Tunneling Protocol (GTP). + + [TS.23060] indicates providing a link MTU value of 1358 + octets to the 3GPP cellular device will prevent the IP + layer fragmentation within the transport network between + the cellular device and the GGSN/PGW. More details + about link MTU considerations can be found in Annex C of + [TS.23060]. + +4. Advanced Recommendations + + This section identifies a set of advanced recommendations to fulfill + requirements of critical services such as VoLTE. These + recommendations apply for mobile hosts, including mobile devices. + + A_REC#1: The cellular host must support the RObust Header + Compression (ROHC) RTP Profile (0x0001) and the ROHC UDP + Profile (0x0002) for IPv6 [RFC5795]. Other ROHC profiles + may be supported. + + Bandwidth in cellular networks must be optimized as much + as possible. ROHC provides a solution to reduce + bandwidth consumption and to reduce the impact of having + bigger packet headers in IPv6 compared to IPv4. + + The "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP + packets and the "UDP/IP" ROHC profile (0x0002) to + compress Real-time Transport Control Protocol (RTCP) + packets are required for VoLTE by Section 4.1 of + IR.92.7.0 [IR92]. Note, [IR92] indicates that the host + must be able to apply the compression to packets that + are carried over the voice-media-dedicated radio bearer. + + A_REC#2: The cellular host should support PCP [RFC6887]. + + The support of PCP is seen as a driver to save battery + consumption exacerbated by keep-alive messages. PCP + also gives the possibility of enabling incoming + connections to the cellular device. Indeed, because + + + +Binet, et al. Informational [Page 13] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + several stateful devices may be deployed in wireless + networks (e.g., NAT64 and/or IPv6 Firewalls), PCP can be + used by the cellular host to control network-based NAT64 + and IPv6 Firewall functions that 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 + (which is the default value in [RFC3948], for example) + is 29 mA (2G) / 34 mA (3G). This consumption is reduced + to 16 mA (2G) / 24 mA (3G) when the interval is + increased to 40 seconds, to 9.1 mA (2G) / 16 mA (3G) if + the interval is equal to 150 seconds, and to 7.3 mA (2G) + / 14 mA (3G) if the interval is equal to 180 seconds. + When no keep-alive is issued, the consumption would be + 5.2 mA (2G) / 6.1 mA (3G). The impact of keepalive + messages would be more severe if multiple applications + are issuing those messages (e.g., SIP, IPsec, etc.). + + Deploying PCP allows cellular hosts to manage protocols + that convey IP addresses and/or port numbers (see + Section 2.2 of [RFC6889]) without requiring Application + Level Gateways (ALGs) to be enabled at the network side + (e.g., NAT64). Avoiding soliciting ALGs makes it easier + to develop a service without any adherence with the + underlying transport network. + + A_REC#3: In order for host-based validation of DNS Security + Extensions (DNSSEC) to continue to function in an IPv6-only + connectivity 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#7. + + + + + + +Binet, et al. Informational [Page 14] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + [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#4: When the cellular host is dual-stack connected (i.e., + configured with an IPv4 address and IPv6 prefix), it should + support means to prefer a native IPv6 connection over a + connection established through translation devices (e.g., + NAT44 and NAT64). + + When both IPv4 and IPv6 DNS servers are configured, a + dual-stack host must first contact its IPv6 DNS server. + This preference allows it to offload IPv4-only DNS + servers. + + Cellular hosts should follow the procedure specified in + [RFC6724] for source address selection. + +5. Security Considerations + + The security considerations identified in [RFC7066] and [RFC6459] are + to be taken into account. + + In the case of cellular CE routers, compliance with L_REC#3 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 the IETF makes 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 that + preserve privacy. The activation of the privacy extension (e.g., + using [RFC7217]) makes it more difficult to track a host over time + when compared to using a permanent Interface Identifier. Tracking a + host 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 network side. Note, privacy extensions are required + by regulatory bodies in some countries. + + Host-based validation of DNSSEC is discussed in A_REC#3 (see + Section 4). + + + + + +Binet, et al. Informational [Page 15] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + +6. References + +6.1. Normative References + + [IR92] GSMA, "IMS Profile for Voice and SMS", Official Document + IR.92 - IMS Profile for Voice and SMS, V7.0, March 2013, + <http://www.gsma.com/newsroom/wp-content/uploads/2013/04/ + IR.92-v7.0.pdf>. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, <http://www.rfc-editor.org/info/rfc2460>. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + DOI 10.17487/RFC3596, October 2003, + <http://www.rfc-editor.org/info/rfc3596>. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + DOI 10.17487/RFC3633, December 2003, + <http://www.rfc-editor.org/info/rfc3633>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust + Header Compression (ROHC) Framework", RFC 5795, + DOI 10.17487/RFC5795, March 2010, + <http://www.rfc-editor.org/info/rfc5795>. + + [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., + "Essential Correction for IPv6 ABNF and URI Comparison in + RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, + <http://www.rfc-editor.org/info/rfc5954>. + + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. + Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, + DOI 10.17487/RFC6052, October 2010, + <http://www.rfc-editor.org/info/rfc6052>. + + [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. + Troan, "Prefix Exclude Option for DHCPv6-based Prefix + Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, + <http://www.rfc-editor.org/info/rfc6603>. + + + + +Binet, et al. Informational [Page 16] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. + Krishnan, "IPv6 for Third Generation Partnership Project + (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, + November 2013, <http://www.rfc-editor.org/info/rfc7066>. + + [TS.23060] + 3GPP, "General Packet Radio Service (GPRS); Service + description; Stage 2", 3GPP TS 23.060 13.6.0, March 2016, + <http://www.3gpp.org/DynaReport/23060.htm>. + + [TS.23401] + 3GPP, "General Packet Radio Service (GPRS) enhancements + for Evolved Universal Terrestrial Radio Access Network + (E-UTRAN) access", 3GPP TS 23.401 13.6.1, March 2016, + <http://www.3gpp.org/DynaReport/23401.htm>. + + [TS.24008] + 3GPP, "Mobile radio interface Layer 3 specification; Core + network protocols; Stage 3", 3GPP TS 24.008 13.5.0, March + 2016, <http://www.3gpp.org/DynaReport/24008.htm>. + +6.2. Informative References + + [OECD] Organisation for Economic Co-operation and Development + (OECD), "The Economics of the Transition to Internet + Protocol version 6 (IPv6)", DOI 10.1787/5jxt46d07bhc-en, + November 2014, <http://www.oecd.org/officialdocuments/publ + icdisplaydocumentpdf/?cote=DSTI/ICCP/CISP%282014%293/ + FINAL&docLanguage=En>. + + [Power] Haverinen, H., Siren, J., and P. Eronen, "Energy + Consumption of Always-On Applications in WCDMA Networks", + Proceedings of IEEE 65: Vehicular Technology + Conference, VTC2007-Spring, pp 964-968, + DOI 10.1109/VETECS.2007.207, April 2007, + <http://ieeexplore.ieee.org/xpl/ + articleDetails.jsp?arnumber=4212635>. + + [R3GPP] 3GPP, "The Mobile Broadband Standard: Releases", 2016, + <http://www.3gpp.org/specifications/67-releases>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <http://www.rfc-editor.org/info/rfc3261>. + + + + + +Binet, et al. Informational [Page 17] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. + Stenberg, "UDP Encapsulation of IPsec ESP Packets", + RFC 3948, DOI 10.17487/RFC3948, January 2005, + <http://www.rfc-editor.org/info/rfc3948>. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + <http://www.rfc-editor.org/info/rfc4033>. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, DOI 10.17487/RFC4034, March 2005, + <http://www.rfc-editor.org/info/rfc4034>. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + <http://www.rfc-editor.org/info/rfc4035>. + + [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security + Capabilities in Customer Premises Equipment (CPE) for + Providing Residential IPv6 Internet Service", RFC 6092, + DOI 10.17487/RFC6092, January 2011, + <http://www.rfc-editor.org/info/rfc6092>. + + [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation + Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, + <http://www.rfc-editor.org/info/rfc6145>. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, + April 2011, <http://www.rfc-editor.org/info/rfc6146>. + + [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van + Beijnum, "DNS64: DNS Extensions for Network Address + Translation from IPv6 Clients to IPv4 Servers", RFC 6147, + DOI 10.17487/RFC6147, April 2011, + <http://www.rfc-editor.org/info/rfc6147>. + + [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 + Deployment", RFC 6342, DOI 10.17487/RFC6342, August 2011, + <http://www.rfc-editor.org/info/rfc6342>. + + [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node + Requirements", RFC 6434, DOI 10.17487/RFC6434, December + 2011, <http://www.rfc-editor.org/info/rfc6434>. + + + +Binet, et al. Informational [Page 18] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, + T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation + Partnership Project (3GPP) Evolved Packet System (EPS)", + RFC 6459, DOI 10.17487/RFC6459, January 2012, + <http://www.rfc-editor.org/info/rfc6459>. + + [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts + Using "Bump-in-the-Host" (BIH)", RFC 6535, + DOI 10.17487/RFC6535, February 2012, + <http://www.rfc-editor.org/info/rfc6535>. + + [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, + "Default Address Selection for Internet Protocol Version 6 + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + <http://www.rfc-editor.org/info/rfc6724>. + + [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: + Combination of Stateful and Stateless Translation", + RFC 6877, DOI 10.17487/RFC6877, April 2013, + <http://www.rfc-editor.org/info/rfc6877>. + + [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and + P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, + DOI 10.17487/RFC6887, April 2013, + <http://www.rfc-editor.org/info/rfc6887>. + + [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, + "Analysis of Stateful 64 Translation", RFC 6889, + DOI 10.17487/RFC6889, April 2013, + <http://www.rfc-editor.org/info/rfc6889>. + + [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of + the IPv6 Prefix Used for IPv6 Address Synthesis", + RFC 7050, DOI 10.17487/RFC7050, November 2013, + <http://www.rfc-editor.org/info/rfc7050>. + + [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of + Solution Proposals for Hosts to Learn NAT64 Prefix", + RFC 7051, DOI 10.17487/RFC7051, November 2013, + <http://www.rfc-editor.org/info/rfc7051>. + + [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + DOI 10.17487/RFC7084, November 2013, + <http://www.rfc-editor.org/info/rfc7084>. + + + + + + +Binet, et al. Informational [Page 19] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + <http://www.rfc-editor.org/info/rfc7217>. + + [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the + Port Control Protocol (PCP)", RFC 7225, + DOI 10.17487/RFC7225, May 2014, + <http://www.rfc-editor.org/info/rfc7225>. + + [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 + /64 Prefix from a Third Generation Partnership Project + (3GPP) Mobile Interface to a LAN Link", RFC 7278, + DOI 10.17487/RFC7278, June 2014, + <http://www.rfc-editor.org/info/rfc7278>. + + [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, + DOI 10.17487/RFC7335, August 2014, + <http://www.rfc-editor.org/info/rfc7335>. + + [RFC7445] Chen, G., Deng, H., Michaud, D., Korhonen, J., and M. + Boucadair, "Analysis of Failure Cases in IPv6 Roaming + Scenarios", RFC 7445, DOI 10.17487/RFC7445, March 2015, + <http://www.rfc-editor.org/info/rfc7445>. + + [TS.23402] + 3GPP, "Architecture enhancements for non-3GPP accesses", + 3GPP TS 23.401 13.5.0, March 2016, + <http://www.3gpp.org/DynaReport/23402.htm>. + +Acknowledgements + + Many thanks to C. Byrne, H. Soliman, H. Singh, L. Colliti, T. Lemon, + B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, + E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, T. Kossut, B. Stark, + and A. Petrescu for the discussion in the v6ops mailing list and for + the comments. + + Thanks to A. Farrel, B. Haberman, and K. Moriarty for the comments + during the IESG review. + + Special thanks to T. Savolainen, J. Korhonen, J. Jaeggli, F. Baker, + L.M. Contreras Murillo, and M. Abrahamsson for their detailed reviews + and comments. + + + + + + +Binet, et al. Informational [Page 20] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + +Authors' Addresses + + David Binet + Orange + Rennes + France + + Email: david.binet@orange.com + + + Mohamed Boucadair + Orange + Rennes 35000 + France + + Email: mohamed.boucadair@orange.com + + + Ales Vizdal + Deutsche Telekom AG + Tomickova 2144/1 + Prague, 148 00 + Czech Republic + + Email: Ales.Vizdal@T-Mobile.cz + + + Gang Chen + China Mobile + 29, Jinrong Avenue + Xicheng District, Beijing 100033 + China + + Email: phdgang@gmail.com, chengang@chinamobile.com + + + Nick Heatley + EE + The Point, 37 North Wharf Road, + London W2 1AG + United Kingdom + + Email: nick.heatley@ee.co.uk + + + + + + + + +Binet, et al. Informational [Page 21] + +RFC 7849 IPv6 Profile for Cellular Devices May 2016 + + + Ross Chandler + eircom | meteor + 1HSQ + St. John's Road + Dublin 8 + Ireland + + Email: ross@eircom.net + + + Dave Michaud + Rogers Communications + 8200 Dixie Rd. + Brampton, ON L6T 0C1 + Canada + + Email: dave.michaud@rci.rogers.com + + + Diego R. Lopez + Telefonica I+D + Don Ramon de la Cruz, 82 + Madrid 28006 + Spain + + Phone: +34 913 129 041 + Email: diego.r.lopez@telefonica.com + + + Walter Haeffner + Vodafone D2 GmbH + Ferdinand-Braun-Platz 1 + Duesseldorf 40549 + Germany + + Email: walter.haeffner@vodafone.com + + + + + + + + + + + + + + + +Binet, et al. Informational [Page 22] + |