[v6ops] Re: draft-ma-v6ops-5g-ipv6only-02 inputs

["[e-mail]" <[e-mail]>]

Hi Chenhao,

Very happy to help!

One more comment, I said it in the mic, but forgot to write it down.

I think it will be key for the document to explain in detail the differences in between 4G and 5G and specially how they may be affecting the deployment of IPv6/IPv6-only/464XLAT. This way may be much easier also to understand the issues that you are having and may be similar in other deployments. I’ve not noticed them in my own deployments, but this doesn’t mean they may happen as there are many factors that might behave differently.

Also a query to Apple, not sure if this is the right place to do it, but at least a starting point to wake up some Apple folks that internally may forward this message, as existing IETF contacts have been unable to help for years:

Apple: You’ve been doing a lot of good effort to help on the IPv6 deployment, but at the same time you’re GREATLY HARMING the deployment in mobile networks. IPv6-only with CLAT (for tethering) is not enabled by default, and even users can’t turn it on manually in their cellular devices. This must be FIXED urgently. I understand that you want to keep a very high quality on your products and services, but it doesn’t make any sense that it means that every operator, one by one, is forced to contact to liaisons what don’t have a clue (sorry is my experience and according to many operators is shared) about IPv6-Only+CLAT, and even after signing NDAs, waiting for months, etc., etc., they still need to wait for new versions hoping their specific operator profile will be updated.

Hopefully a very soon future release of iOS fixes this, enabling by default IPv6-only+CLAT (464XLAT), so it just works in any cases. If an operator has done a bad deployment that’s a problem they need to sort it out by themselves, not in the other way around. Take example from Android here please!

Regards,
Jordi

@jordipalet


> El 18 mar 2026, a las 11:17, Chenhao Ma <[e-mail]> escribió:
> 
> Hi Jordi，
> 
> Thank you very much for your reply; it has been very helpful to me. I need some time to review the relevant drafts and rethink the content. Thank you so much!
> 
> Best Regards,
> 
> Chenhao
> 
>>> 发件人: jordi.palet=[e-mail] <mailto:jordi.palet=[e-mail]>
>>> 日期: 2026年3月17日 GMT+8 13:40:38
>>> 收件人: IPv6 Operations <[e-mail]> <mailto:[e-mail]>
>>> 主题: [v6ops] draft-ma-v6ops-5g-ipv6only-02 inputs
>>> 
>>> Hi,
>>> 
>>> I’ve re-read this document and here are some inputs, not just editorial but about my own experience in actual deployments.
>>> 
>>> 1. Intro
>>> 
>>>   Currently, IPv6 has been widely in mobile networks of operators
>>> 
>>>   Currently, IPv6 has been widely deployed in mobile networks of operators
>>> 
>>> 
>>> However, IPv4 applications still exist in
>>> the network, and the support for IPv4 services must still be
>>> 
>>> However, IPv4-only applications still exist in
>>> the networks, and the support for IPv4 services must still be
>>> 
>>> 
>>>   to the internet is called the Packet Data Unit (PDU) session, and its
>>> 
>>>   to the Internet is called the Packet Data Unit (PDU) session, and its
>>> 
>>> (I think most of the “internet” should be replaced with Internet across the document)
>>>   Accordingly, for UE only supporting IPv6,the network will provide an
>>> 
>>>   Accordingly, for UEs supporting only IPv6, the network will provide an
>>> 
>>> 
>>>   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.
>>> 
>>>   There are several IPv6-only transition technologies described in
>>> [RFC9313] . Most existing deployments utilize 464XLAT technology in
>>> cellular networks, as this is the only supported transition mechanism in cellular networks, apart from dual-stack. This document describes the architecture for
>>> deploying 464XLAT based IPv6-only technology on the user plane in 3GPP 5G
>>> systems. Based on the field trails, this document also discusses the
>>> major issues encountered and potential solutions to address them.
>>> 
>>> 
>>> 2. Terms
>>> 
>>> * 464XLAT: IPv6-Only Transition Mechanism (IPv6-to-IPv4 Translation)
>>> * 464XLAT: IPv6-Only Transition Mechanism (IPv6-to-IPv4 and IPv4-IPv6-IPv4 Translation) RFC6877
>>> 
>>>   * CLAT: CLAT is customer-side translator (XLAT) that compiles with
>>> [RFC6146]
>>> 
>>>   * CLAT: CLAT is customer-side translator (XLAT) that compiles with
>>> [RFC7915]
>>> 
>>> * PLAT: PLAT is provider-side translator (XLAT) that compiles with
>>> [RFC7915]
>>> 
>>> * PLAT: PLAT is provider-side translator (XLAT) that compiles with
>>> [RFC6146]
>>> 
>>> 
>>> 3. 5GS IPv6-only Architecture on User Plane
>>> May be you could add a reference to RFC7445 Analysis of Failure Cases in IPv6 Roaming Scenarios
>>> 
>>> 
>>> 3.1. Non-roaming Network Scenario
>>> May be you want to add a reference to RFC8683 Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks, because it is quite possible that the NAT64 and/or DNS64 are in other networks. Also possible that there is no DNS64. Not common scenarios, but perfectly viable.
>>> 
>>> This is also possible in the case of the 3.2 Roaming Network Scenario with Home Routed
>>> 
>>> In all the roaming models that you present the CLAT is in the UE.
>>> 
>>> However, I’ve seen one deployment model where they did a very strange thing. This is not common (I believe), and I will not suggest it: having the CLAT in the packet core itself, so dual-stack was provided to each UE and the CLAT function was virtualized. As said, I don’t think this is a good model, but may be some other participants in the list can say if this is something done in other deployments and in that case you will need to consider some text about that.
>>> 
>>> UE, while the PLAT/stateful NAT64 function and DNS64 function are
>>> 
>>> UE, while the PLAT function and DNS64 function are
>>> (same in other parts of the doc, as you already defined PLAT in terminology section, no need to repeat the rest)
>>> 
>>> 
>>> Table 1 belongs to section 3 not 3.3, right? Also I will suggest in this table the same order as the sub-sections.
>>> 
>>> 
>>> 4. Deployment Challenges
>>> 
>>> Based on our practices, for large-size mobile network operators, it’s
>>> 
>>> Based on our trials?, for large-size mobile network operators, it’s
>>> 
>>> -> Not sure if you’re having this experiences in trials or actual deployments …
>>> 
>>> 
>>> 4.1. Roaming Challenge
>>> In my experience this can be configured when doing the roaming partner agreements setup, so depending on the roaming partner capabilities, the UE may choose a different model (dual-stack or IPv4-only in some cases), automatically.
>>> 
>>> 4.2. UE Challenge
>>> Based in my experience, if you have a single APN correctly configured, depending on the UE firmware, will choose the right setup (IPv6-only, dual-stack, IPv4-only, typically in that order of preference). Older terminals may only support IPv4, or dual-stack, but this is automatic if the APN is properly configured.
>>> 
>>> Apple devices with iOS don’t need CLAT to support IPv6-only. They have support for Happy Eyeballs v2 (RFC8305) with is doing something “similar” to the CLAT function (see section 7.1).
>>> 
>>> This is not done for tethered devices, son then you need the CLAT function. Towards that, Apply has a surprisingly strange policy, and you need to talk to your liaison with Apple, sign NDA, they will “test” your network, and afterwards, update the operator profile in a following release  of the iOS, so it will work as expected.
>>> 
>>> 
>>> 4.3. UP Layer Challenge
>>> You mean upper layer?
>>> 
>>> I don’t think synthesised AAAA records (may be reword using the same terminology as in DNS64 RFC6147, add also a reference to it in the first occurrence of DNS64) are a big challenge. There are many ways for the billing rules to be adapted if the software don’t support IPv6 addresses, such as a hash, or using only part of the IPv6 address, etc.
>>> 
>>> May be you can describe the problem with much more details.
>>> 
>>> 
>>> 4.4. DNS64 Configuration Challenge
>>> Same here, I don’t think this is a so big problem, you could describe it with more details.
>>> 
>>> In fact, even if DNS64 has the inconvenience of chances to break DNSSEC, the alternative model with is not using DNS64, seems to me worst. Take a look into RFC8683, section 3.1.2 DNS load and connection establishment delay optimizations.
>>> 
>>> 
>>> 
>>> 5.1. PDP Context / APN Isolation Method
>>> 
>>> I will say the point after
>>>   When a UE attaches to the network, it requests a PDP context for a
>>> specific APN. The network can:
>>> should be bullets or numbered.
>>> 
>>> I think the key to avoid problems and understanding that the network can dynamically steer users into different setups (different PDP context configuration), depending on the UE capabilities, you avoid the troubles without the need for different APNs. At least this has been my experience. For example, no need to configure DNS64 servers to dual-stack users.
>>> 
>>> However even if you do so (assign DNS64 instead a regular DNS to a dual-stack UE), I don’t see the problem. What will happen then is that the IPv4 traffic of that UE will go tru the PLAT, right? Instead if the IPv4 traffic is using RFC1918 addresses, it means it will be using the CGN, which I think is even worst …
>>> 
>>> You could also setup rules in the DNS64 so dual-stack UEs don’t use the AAAA synthesis. A good DNS server need to have those configurations facilities to map-in/out certain users. You could also use DNS-RPZ, as well, as indicated in RFC8683. 
>>> 
>>> I will not do a trial or rollout with an ipv6-only APN. Instead, I will strongly suggest that the APN supports all the possible PDP contexts, so it si closer to reality (UEs with all the different capabilities). You can then update via OTA or in the packet switch, the profiles to allow more and more users to join not just to the IPv4-only PDP context, but also to the dual-stack and specially the IPv6-only if the UEs have those capabilities.
>>> 
>>> I did that in actual deployments and succeeded to have a very fine granularity of what users/profiles/UE models/firmware versions I want to have using each PDP context type.
>>> 
>>> I’d a single case where this was not feasible because several limitations not an outdated PS and lack of OTA support, and in that case, the easier way was a marketing SMS campaign of the operator, asking the users to switch manually some of the older Android UEs and in exchange, they got some additional bandwidth or “free-something”. Of course, it worked as expected.
>>> 
>>> So definitively I will not use APN isolation in the sense of different APNs for different “allowance” of PDP-types, as this will create the operational complexity that you mention, or at least part of it (not sure to agree with alll those aspects as well).
>>> 
>>> 5.2. IMEI Configuration at Network Side
>>> I don’t think this is a good way. The support can change in an UE (same IMEI), across that time, because OS updates. For example Apple updates with a new operator profile enable CLAT. You don’t know when each UE is actually updated. The OS is able to choose the right PDP type at connection time, right?
>>> 
>>> 
>>> 5.3. Option 108
>>> Agree, PS typically lack of DHCP support, neither RFC7050 is common (not related to this, just a new point to mention perhaps), that’s why PCO is more common, together with SLAAC. Perhaps there should be a strong IETF recommendation for 3GPP to use RFC8781 (something to be added to your 5.4?).
>>> 
>>> 
>>> 5.4. Using RA to deliver PREF64 and DNS64 configuration
>>> I don’t think this is needed:
>>> 
>>> Upon receivinghis 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 final protocol stack configuration used by the UE.
>>> 
>>> As said, the UE is already able to choose the relevant PDP contact in the correct priority. Or you observed UE vendors improperly implementing that, and this is the actual reason for your troubles?
>>> 
>>> Section 6, seems the just describe the correct expected behaviour when using PREF64. Not sure if I’m missing something that is not properly implemente in 3GPP and need to be suggested to them?
>>> 
>>> 
>>> A final point, note than some times the UE is a CE. The issue here is the overall lack of support in 3GPP deployments of DHCPv6-PD … so a broadband user connected via 4G/5G is only getting a single /64. Big trouble.
>>> 
>>> 
>>> Regards,
>>> Jordi
>>> 
>>> @jordipalet
>>> 
>>> 
>>> 
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com <http://www.theipv6company.com/>
>>> The IPv6 Company
>>> 
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list -- [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>_______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.