v6ops Working Group C. Ma
Internet-Draft C. Xie
Intended status: Informational China Telecom
Expires: 29 August 2025 25 February 2025
Considerations of Gradual IPv6-only Deployment in 5G Mobile Networks
draft-ma-v6ops-5g-ipv6only-00
Abstract
This document describes the approach of gradually deploying 464XLAT
based IPv6-only technology on user plane in 3GPP 5G networks. It
also discusses the challenges and potential solutions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 August 2025.
Copyright Notice
Copyright (c) 2025 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 (https://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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Ma & Xie Expires 29 August 2025 [Page 1]
Internet-Draft 5G IPv6-only Deployment Considerations February 2025
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terms and abbreviation . . . . . . . . . . . . . . . . . . . 3
3. 5GS IPv6-only Architecture on User Plane . . . . . . . . . . 4
3.1. Non-roaming Network Scenario . . . . . . . . . . . . . . 4
3.2. Roaming Network Scenario with Home Routed . . . . . . . . 4
3.3. Roaming Network Scenario with Local Break Out . . . . . . 5
4. Deployment Challenges . . . . . . . . . . . . . . . . . . . . 5
4.1. Roaming Challenge . . . . . . . . . . . . . . . . . . . . 5
4.2. UE Challenge . . . . . . . . . . . . . . . . . . . . . . 5
4.3. UP Layer Challenge . . . . . . . . . . . . . . . . . . . 6
4.4. DNS64 Configuration Challenge . . . . . . . . . . . . . . 6
5. Deployment Solution . . . . . . . . . . . . . . . . . . . . . 6
5.1. IMEI Configuration at Network Side . . . . . . . . . . . 6
5.2. Option 108 . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Currently, IPv6 has been widely in mobile networks of operators
worldwide, and it has even gained the dominant position from the
perspective of traffic. However, IPv4 applications still exist in
the network, and the support for IPv4 services must still be
considered to guarantee the users’ experience. Furthermore,
operators have begun experimenting with deploying IPv6-only approach
in their mobile networks.
The 5G system is defined in the 3GPP standards organization. In the
5G system architecture, the session related to the endpoint's access
to the internet is called the Packet Data Unit (PDU) session, and its
type determines the IP protocol used for user access. In the 5G
standards, the PDU session supports both IPv6 and IPv4 protocols, and
it also provides policies to ensure that user equipment (UE) can
access the internet. When a UE only supports the IPv4 protocol while
the network supports dual-stack (IPv4 and IPv6), the network will
provide an IPv4 protocol stack configuration for the UE.
Accordingly, for UE only supporting IPv6,the network will provide an
IPv6 protocol stack configuration for the UE. Additionally, there
are policy configuration schemes related to static addresses and
other aspects, but It does not specify the requirements related to
IPv6-only technology.
Ma & Xie Expires 29 August 2025 [Page 2]
Internet-Draft 5G IPv6-only Deployment Considerations February 2025
There are several IPv6-only transition technologies described in
[RFC9313] . Most existing deployments utilize 464XLAT technology in
cellular network. This document describes the architecture for
deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G
system. Based on the field trail, this document also discusses the
major issues encountered and potential solutions to address them.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terms and abbreviation
The following terms are defined in this document:
* 464XLAT: IPv6-Only Transition Mechanism (IPv6-to-IPv4 Translation)
* 5GC: 5G Core
* 5GS: 5G System
* AMF: Access and Mobility Management Function
* CLAT: CLAT is customer-side translator (XLAT) that compiles with
[RFC6146]
* PLAT: PLAT is provider-side translator (XLAT) that compiles with
[RFC7915]
* PDU：Protocol Data Unit
* IMEI: International Mobile Equipment Identity
* SMF：Session Management Function
* UE: User Equipment, e.g., mobile phone.
* LBO：Local Break Out
Ma & Xie Expires 29 August 2025 [Page 3]
Internet-Draft 5G IPv6-only Deployment Considerations February 2025
3. 5GS IPv6-only Architecture on User Plane
Examples of 5GS IPv6-only architectures on user plane are shown in
the figures in the following sections. In production 5GS network,
there is roaming behavior which specifies where the PDU session
anchor and its controlling SMF are located in. That decides whether
UE’s PDU sessions get IP configuration and access the Internet from
home 5GS network or visited 5GS network. Regarding roaming, 5GS
contains three scenarios including non-roaming, roaming with home
routed, and roaming with local break out.
3.1. Non-roaming Network Scenario
Based on wireless 3GPP network architecture defined in [RFC6877], the
non-roaming network architecture is depicted as figure 1. When a
mobile network operator run only a 5GC, there is just non-roaming
network scenario. In this csae, the CLAT function is deployed on the
UE, while the PLAT/stateful NAT64 function and DNS64 function are
deployed on the network side.
+-------+ +------------+ _________
|UE | |5GC | / \
|+----+ | | +-----+ | / \
||CLAT| +--+--+UPF +---+---+ Internet |
|+----+ | | +-----+ | \ /
+-------+ +---/-----\--+ +--------+
/ \
+------+ +------+
|NAT64 | |DNS64 |
+------+ +------+
3.2. Roaming Network Scenario with Home Routed
Generally, large mobile operators run multiple 5GCs divided by
administrative divisions or other geographical methods. The roaming
network scenario with home routed is shown in figure 2. In this
case, UEs acquire IP network configuration and access the Internet in
their home 5GS network. The IP address allocation strategy and
traffic exit interface are decided by their home 5GC. The CLAT
function is deployed on the UE, while the PLAT/stateful NAT64
function and DNS64 function are deployed on the home network.
Ma & Xie Expires 29 August 2025 [Page 4]
Internet-Draft 5G IPv6-only Deployment Considerations February 2025
3.3. Roaming Network Scenario with Local Break Out
The roaming network scenario with LBO is shown in figure 3. In this
case, UEs get IP network configuration and access the Internet in the
visited network. The CLAT function is deployed on the UE, while the
PLAT/stateful NAT64 function and DNS64 function are deployed on the
visited network. Home network also need to support NAT64 and DNS64
when UE is in the non-roaming case.
The following table 1 summarizes 5GC's network capabilities where the
mobile network shall have to provide IPv6-only connectivity service.
+------------------+-----+-------------+---------------+
|Scenario |UE |Home Network |Visited Network|
+------------------+-----+-------------+---------------+
|Non-roaming |CLAT |NAT64 DNS64 | |
+------------------+-----+-------------+---------------+
|Roaming with Local|CLAT |NAT64 DNS64 |NAT64 DNS64 |
|Breakout | | | |
+------------------+-----+-------------+---------------+
|Roaming with Home |CLAT |NAT64 DNS64 | |
|Routed | | | |
+------------------+-----+-------------+---------------+
Table 1. Network Capabilities for IPv6-only 5G Scenarios
4. Deployment Challenges
Based on our practices, for large-size mobile network operators, it’s
very difficult for operators to deploy IPv6-only capabilities across
the whole network at once. There is a transition period that the
IPv6-only capability is deployed gradually. This section identifies
the major challenges when applying 464XLAT in a production network.
4.1. Roaming Challenge
In the scenario where 5GC A supports IPv6-only capability while 5GC B
doesn’t. When UE A from 5GC A roams to 5GC B, it only obtains IPv6
configuration and accesses Internet according to the local breakout
roaming policy. In this case, the access to IPv4 Internet may fail
due to 5GC B lacks NAT64 and DNS64 capabilities.
4.2. UE Challenge
Regarding UE challenge, a significant number of terminals have not
enabled CLAT functionality. The vast majority of Android terminals
support and have enabled the CLAT functionality. Most new terminals
like smart watch do not support this feature. Moreover, Apple's iOS
in China does not enable CLAT functionality.
Ma & Xie Expires 29 August 2025 [Page 5]
Internet-Draft 5G IPv6-only Deployment Considerations February 2025
4.3. UP Layer Challenge
When IPv6-only users access IPv4 sites, the actual address they reach
is generated by the DNS64 server, which combines a special IPv6
prefix with the IPv4 site address to form an IPv6 address. Existing
layer 3&layer 4 content billing rules based on IPv4 addresses will no
longer be effective and will need to be adjusted to accommodate the
IPv6 addresses formed by DNS64.
4.4. DNS64 Configuration Challenge
After enabling the DNS64 functionality, there is an increase in the
processing load due to the additional handling of IPv6 queries and
the DNS64 conversion, which consumes some device performance. The
extent of this performance demand increase depends on the scale of
IPv6 queries. In a 5G network, once the DNS64 functionality is
enabled, DNS resolution requests from both IPv6-only and dual-stack
users will be processed by the DNS64 server. Even IPv4 resolution
requests from dual-stack users will be treated as if they were from
IPv6-only users, which place a significant load pressure on the DNS
server. This may futher impact the service logic of the existing
dual-stack users.
5. Deployment Solution
5.1. IMEI Configuration at Network Side
One solution is to enhance the core network's capability to configure
IP addresses and DNS server addresses based on IMEI number ranges.
The IMEI is a unique sequence of 14 to 15 digits assigned to each
mobile phone. It serves as a device identification number, enabling
service providers to recognize the phone within the network. The
primary purpose of the IMEI is to uniquely identify each device,
allowing the network to determine whether the UE supports CLAT
functionality. By configuring a whitelist of IMEIs that support CLAT
functionality in the network, the network can assign an IPv6-only
environment to UEs listed in the whitelist.
5.2. Option 108
One possible solution is to use the option108 [RFC 8925] method,
allowing UE to choose whether to join the IPv6-only environment.
Additionally, a method for configuring DNS64 server addresses needs
to be considered. However, in practical deployments, core network
support for DHCPv4 functionality is optional and may not be
applicable to all networks.
Ma & Xie Expires 29 August 2025 [Page 6]
Internet-Draft 5G IPv6-only Deployment Considerations February 2025
Another possible solution is to transmit Pref64 and DNS64 address
information through the RA option. In 5G systems, RA is used to
advertise IPv6 prefixes in the SLAAC, which is a mandatory
functionality. Transmitting this information through RA is also a
favorable option. Currently, the IETF has produced two RFCs, namely
[RFC 8106] and [RFC 8781]. In practical implementations, the mobile
core network supporting IPv6-only environments (IPv6-only mode)
should include these two options in the RA messages. Upon receiving
this message, the UE can abandon the IPv4 interface and operate in
IPv6-only mode. In this solution, the core network does not need to
be aware of the protocol stack ultimately used by UE.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. Acknowledgements
The comments and suggestions of the following are gratefully
acknowledged:
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[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, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
Ma & Xie Expires 29 August 2025 [Page 7]
Internet-Draft 5G IPv6-only Deployment Considerations February 2025
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
2020, <https://www.rfc-editor.org/info/rfc8781>.
[RFC8925] Colitti, L., Linkova, J., Richardson, M., and T.
Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
RFC 8925, DOI 10.17487/RFC8925, October 2020,
<https://www.rfc-editor.org/info/rfc8925>.
[RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R.,
and I. Farrer, "Pros and Cons of IPv6 Transition
Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313,
DOI 10.17487/RFC9313, October 2022,
<https://www.rfc-editor.org/info/rfc9313>.
Authors' Addresses
Chenhao Ma
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: machh@chinatelecom.cn
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: xiechf@chinatelecom.cn
Ma & Xie Expires 29 August 2025 [Page 8]