[v6ops] Re: Call for Adoption: draft-buraglio-deprecate7050 -3GPP networks

[Brian E Carpenter <[e-mail]>]

Excuse front posting, but as far as I know the IETF doesn't have an agreed definition of "deprecate", and there isn't a well-defined boundary between "deprecate" and "discourage". Since the word "deprecate" doesn't occur in the draft (only in its filename), where's the issue? In any case, deprecate != obsolete.

Also, the relevant entry for "deprecate" in Merriam-Webster is "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative...".

That seems perfect.

Regards
    Brian

On 20-Dec-24 06:47, Nick Buraglio wrote:
> 
> 
> On Thu, Dec 19, 2024 at 9:11 AM <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi Jen, All,____
> 
>     Can I raise a concern please? (Following on our conversation about 3GPP networks in London at the IPv6 Council 😊)____
> 
>     __ __
> 
>     My perspective on 3GPP networks:____
> 
>     AFAIK 3GPP operators mostly* use the NAS signalling method of assigning IPv6 Prefix / Resolver address. This is done when the “bearer session create” is signalled, so prefix assignment is not happening on the link layer supporting IP. I am told as this is done more centrally it can be efficient in IP address pooling and can be a universal function - whether a UE has requested IPv6, IPv4v6 or IPv4 (maybe the UE cannot support anything but IPv4). If IPv4v6 the session create response can be coordinated across IP versions.____
> 
>     The DNS resolver address appear as “Info Elements” assigned as “PCO” (Protocol Config Options) at bearer session creation. This method has a pertinent advantage to this draft – it makes the changing of resolver address hard on cellular UE interfaces (whereas changing resolver on Wi-Fi interfaces is easy), it is hard to do without destroying the radio bearer.____
> 
>     The alternatives to NAS signalling are RA and DHCP methods. RA method is documented in later 3GPP papers, but I don’t know how well it is applied, and whether fields like prefix64 are covered in 3GPP networks. Where prefix delegation is needed then DHCP is required, but not sure of that much use of DHCPv6 in the mass-market 3GPP networks.____
> 
>     __ __
> 
>     With the UE setup via NAS signalling, then RFC7050 is a way for the Operators resolvers to signal the prefix64 “over the top” to the UE, and it works irrespective of generation (2G, 4G, 5G) or whether the handset is in the home access network or roaming in another network. This is how in UK we initially deployed 464xlat for IPv6-only (RFC6877 refers to “discovery-heuristics” which I think became RFC7050.____
> 
>     (*Mostly = I am not personally aware of any 3GPP network using another technology choice here for the mass-market. It is 10 years since we turned on IPv6-only and I haven't done much digging on that recently. However, this month I was talking to another European Operator moving from dualstack to IPv6-only now and they expect RFC7050 remains viable).
> 
> 
> Thank you for this detailed explanation - I appreciate learning the details of how that works in practice.
> 
>     ____
> 
>     __ __
> 
>     My concern is that in this thread, there is interchange of “discouraging” and “deprecating”. Which is it?
> 
> 
> I can't speak for the other authors, but my understanding is that we want to discourage the use of 7050 in favor of 8781 where it makes the most sense. On closed networks where the UE network stack is controlled by the provider, I think there are fewer edge cases, unlike ethernet networks where different applications may, by design, use their own resolvers which can create a troublesome, inconsistent user experience. The term "deprecate" was mine, and the document, if adopted will be renamed to match the current title. It was an unfortunate, ambitious naming choice.
> 
>     ____
> 
>     If the aim is to “deprecate the use of” RFC7050 – and the draft doesn’t say anything as such - **could we have the right features in standards for 3GPP networks before deprecating**, and guidance on what 3GPP networks and UEs should do? Do Operators need to change to another Prefix Assignment technology? Or request that prefix64 is an IE supported in the radio bearer signalling? Operators don’t want to pay for feature development on existing core, they want it delivered as a standards approach. Operators want the solution to work locally and in the roaming case (we don’t want to introduce compatibility risks). Operators don’t want UEs to stop working.
> 
> 
> Understood and agreed.
> 
>     ____
> 
>     I am sure that it is not the intention to marginalise “IPv6-only” in 3GPP networks when deprecating RFC7050, but that could be the perception given its strong association with RFC6877/464xlat in 3GPP networks.
> 
> 
> The goal is to promote easier migration to IPv6-only by minimizing inconsistency of capability discovery.
> 
>     ____
> 
>     __ __
> 
>     If it is “discouraging”, then I suspect this might not be strong enough for networks where RAs are readily available without any development or feature introduction.
> 
> And perhaps that is OK where the network and UE stack is controlled end to end, that's a larger discussion where the (perhaps not so) subtle difference is that network stack control.
> 
>     For IP/ethernet networks I suspect RFC7050 should not be used, and RAs should do the job. And they carry more risk of change of resolver and link layer interceptions.
> 
> 
> Exactly my personal thinking, and I believe that of the co-authors.
> 
>     I don’t want to stand in the way of progress for other network technologies.
> 
> 
> +1
> 
>     ____
> 
>     __ __
> 
>     If RFC7050 can remain as the “backstop” on 3GPP networks then that is vital information to convey to Operators currently embarking on an upgrade to IPv6-only/RFC6877.____
> 
>     It feels like whether it is “deprecate” or “discourage”, this paper should consider a statement on 3GPP networks - as a known technology where RFC7050 has been exploited to migrate many millions of endpoints to IPv6-only.
> 
> 
> Thanks, we will work on including something in the next version. We would also be happy to consider any suggested text you may have in mind.
> 
>     ____
> 
>     Cheers,____
> 
>     Nick____
> 
>     __
> 
> 
> Thank you for this very useful input,
> 
> nb
> 
>     __
> 
>     __ __
> 
>     *From:*Peter Schmitt <Peter.Schmitt=[e-mail] <mailto:[e-mail]>>
>     *Sent:* 13 December 2024 11:56
>     *To:* Charles Eckel (eckelcu) <[e-mail] <mailto:[e-mail]>>; Jen Linkova <[e-mail] <mailto:[e-mail]>>
>     *Cc:* V6Ops Chairs <[e-mail] <mailto:[e-mail]>>; Lorenzo Colitti <lorenzo=[e-mail] <mailto:[e-mail]>>; IPv6 Operations <[e-mail] <mailto:[e-mail]>>
>     *Subject:* [v6ops] Re: Call for Adoption: draft-buraglio-deprecate7050____
> 
>     __ __
> 
>     	
> 
>     You don't often get email from peter.schmitt=[e-mail] <mailto:peter.schmitt=[e-mail]>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>____
> 
>     	
> 
>     Hi Jen; Charles ;____
> 
>     __ __
> 
>     Just checked 23.975 is only referenced by 23.221.____
> 
>     But 23.221 is referenced by several specs in SA2, CT1, CT3, CT4 area. These are also the groups talking about routing____
> 
>     __ __
> 
>     My proposal would be to send an LS to these groups and ask them to take action and add proper reference.____
> 
>     __ __
> 
>     By doing so we cover all different areas.____
> 
>     SA2 is very busy and may not have time to go in the details, but than CT groups should take action than.____
> 
>     For example there is a TS 29.303 <https://www.3gpp.org/ftp/Specs/archive/29_series/29.303/29303-i00.zip>dealing with Domain Name System Procedures____
> 
>     __ __
> 
>     __ __
> 
>     Best regards____
> 
>     Peter Schmitt____
> 
>     3GPP TSG CT Chair____
> 
>     __ __
> 
>     *From:*Charles Eckel (eckelcu) <[e-mail] <mailto:[e-mail]>>
>     *Sent:* Friday, 13 December 2024 12:12
>     *To:* Jen Linkova <[e-mail] <mailto:[e-mail]>>
>     *Cc:* V6Ops Chairs <[e-mail] <mailto:[e-mail]>>; Lorenzo Colitti <lorenzo=[e-mail] <mailto:lorenzo=[e-mail]>>; Nick Buraglio <[e-mail] <mailto:[e-mail]>>; IPv6 Operations <[e-mail] <mailto:[e-mail]>>; Peter Schmitt <[e-mail] <mailto:[e-mail]>>
>     *Subject:* Re: [v6ops] Call for Adoption: draft-buraglio-deprecate7050____
> 
>     __ __
> 
>     [adding Peter, my counterpart in 3GPP]____
> 
>     __ __
> 
>     Hi Jen, ____
> 
>     __ __
> 
>         On Dec 12, 2024, at 1:39 PM, Jen Linkova <[e-mail] <mailto:[e-mail]>> wrote:____
> 
>         __ __
> 
>         On Thu, Dec 12, 2024 at 7:10 PM Charles Eckel (eckelcu)
>         <[e-mail] <mailto:[e-mail]>> wrote:____
> 
>                     One option is to send an LS from v6ops to relevant 3GPP groups informing them of this draft and recommending they update their specs accordingly. Another option is to bring contributions to the relevant 3GPPs groups that update the relevant specs.____
> 
> 
>                 Which option would you recommend? ;)____
> 
> 
>             I was leaning toward doing both; however, digging into this a bit more, I did not find any 3GPP specifications that reference RFC 7050 or RFC 8781. That is not to say that 3GPP deployments do not implement these mechanisms, but it is not clear to me what needs to be updated in terms of 3GPP requirements/specifications.____
> 
> 
>         I'd say that 3GPP has nothing to do with RFC7050 - it's between the
>         endpoint and DNS64 servers: the endpoints discover the NAT64 prefix by
>         resolving "ipv4only.arpa.".
>         It would be nice if the network provides the endpoints with the NAT64
>         prefix by using RFC8781, but mobile networks are not doing it now. So
>         it's expected that 3GPP specifications do not mention RFC8781 *yet* -
>         and that's exactly what we'd like to change.____
> 
>     __ __
> 
>     Thanks for this clarification. In this case, identifying the set of 3GPP specifications to update is more challenging. A good starting point may be proposing updates to TR 23.975 <https://www.3gpp.org/ftp/Specs/archive/23_series/23.975/23975-i00.zip>, IPv6 Migration Guidelines. This document is non-normative, but I suspect that an update to it would facilitate corresponding updates to normative specifications. ____
> 
>     __ __
> 
>     Cheers,____
> 
>     Charles____
> 
>     __ __
> 
>                     I can help with the first,____
> 
> 
>                 Thank you!
> 
>                 ____
> 
>                     although I recommend waiting until an adopted working group draft exists.____
> 
> 
>                 Strictly speaking RFC8781 (published by 6MAN) already says that PREF64
>                 shall be preferred over RFC7050, and section 4.3.3 of
>                 https://datatracker.ietf.org/doc/draft-ietf-v6ops-6mops/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-6mops/>states smth
>                 very similar to this draft, but I guess 2 weeks are not going to
>                 change anything ;)
> 
>                 A question to v6ops chairs: is it going to be another call for
>                 adoption, or was it enough interest expressed on the dnssop thread by
>                 v6ops? It's not really clear from Tim's email..
> 
>                 ____
> 
>                     __ __
> 
>                         On Dec 11, 2024, at 8:27 AM, Jen Linkova <[e-mail] <mailto:[e-mail]>> wrote:
> 
>                         Adding Charles, who is the IETF 3GPP liaison.
> 
>                         Charles, do you think it's feasible to add RFC8781 to the 3GPP
>                         requirements? If yes, what do we need to do?
> 
>                         Thanks!
> 
>                         On Wed, Dec 11, 2024 at 1:06 PM Lorenzo Colitti
>                         <lorenzo=[e-mail] <mailto:lorenzo=[e-mail]>> wrote:____
> 
> 
>                             I support adoption. It's high time for RFC7050 to be deprecated.
> 
>                             We should try to get RFC 8781 into the next revision of the 3GPP requirements, so that mobile networks vendors implement it and mobile network operators can use it. Not sure who can help with that. Do we have a 3GPP liaison function/person, and is that what it/they are supposed to help with?
> 
>                             On Mon, Dec 9, 2024 at 12:15 PM Nick Buraglio <[e-mail] <mailto:[e-mail]>> wrote:____
> 
> 
>                                 FYI, this document had significantly more support within v6ops. As such, we've moved the adoption call here, so please think about it as a v6ops document, and voice any support, concern, advice, or general thoughts on the adoption call here.
> 
>                                 nb
> 
>                                 ---------- Forwarded message ---------
>                                 From: Tim Wicinski <[e-mail] <mailto:[e-mail]>>
>                                 Date: Fri, Dec 6, 2024 at 1:32 PM
>                                 Subject: Re: Call for Adoption: draft-buraglio-deprecate7050
>                                 To: dnsop <[e-mail] <mailto:[e-mail]>>
>                                 Cc: dnsop-chairs <[e-mail] <mailto:[e-mail]>>, list <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>
> 
> 
>                                 All
> 
>                                 The DNSOP chairs have closed the Call for Adoption on this document.  The interest in adopting this is much higher in v6ops, so we talked with the v6ops chairs and Warren, and DNSOP will  NOT adopt this work. However, since there is interest to work on this, v6ops does seem poised to adopt this.  They will make sure dnsop are kept informed.
> 
>                                 Thanks all.
> 
>                                 tim
> 
> 
>                                 On Wed, Dec 4, 2024 at 11:23 AM Tim Wicinski <[e-mail] <mailto:[e-mail]>> wrote:____
> 
> 
>                                     All
> 
>                                     A followup on the Call For Adoption.  We realized we did not include v6ops in this call for adoption, but we are also have not heard from folks in the working group after the talk at the last IETF meeting.
> 
>                                     Once again, this is a call for adoption for  "Deprecation of DNS64 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis"
> 
>                                     The draft is available here: https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/ <https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/>
> 
>                                     The chairs will take the silence as the group is not interested in working on this
> 
>                                     thanks
>                                     tim
> 
> 
> 
>                                     On Wed, Nov 20, 2024 at 11:22 AM Tim Wicinski <[e-mail] <mailto:[e-mail]>> wrote:____
> 
> 
> 
>                                         All
> 
>                                         During IETF121, there seemed to be some consensus to adopt this work in DNSOP.
>                                         Here are the relevant minutes and link to the presentation from the session:
> 
>                                           Deprecation of DNS64 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
>                                         https://datatracker.ietf.org/meeting/121/materials/slides-121-dnsop-sessa-deprecation-of-dns64-for-discovery-of-ipv6-prefix-used-for-ipv6-address-synthesis-00 <https://datatracker.ietf.org/meeting/121/materials/slides-121-dnsop-sessa-deprecation-of-dns64-for-discovery-of-ipv6-prefix-used-for-ipv6-address-synthesis-00>
> 
>                                               Jen Linkova: 7050 won't work in multihoming
>                                                   Would like to see this adopted
>                                               Lorenzo Colitti: Would like to do this
>                                                   Have you asked the mobile operators why they do this?
>                                                   Maybe not realistic
>                                                   Nick: Maybe say "non-mobile environments"
>                                               Tommy: Will not update his earlier draft, this is a better draft
>                                               Èric: Likes this
>                                                   Nick: Not saying remove the old ones
>                                               Lorenzo: Talk to mobile operators, maybe drop the old stuff
> 
> 
>                                         This starts a Call for Adoption for draft-buraglio-deprecate7050
>                                         "Deprecation of DNS64 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis"
> 
>                                         The draft is available here: https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/ <https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/>
> 
>                                         Please review this draft to see if you think it is suitable for adoption
>                                         by DNSOP, and send any comments to the list, clearly stating your view.
> 
>                                         Please also indicate if you are willing to contribute text, review, etc.
> 
>                                         Because of the American holiday next week, we are going to run this adoption call a little bit longer.
> 
>                                         This call for adoption ends: December 11, 2024
> 
>                                         Thanks,
>                                         For DNSOP co-chairs
>                                         tim____
> 
> 
>                                 _______________________________________________
>                                 v6ops mailing list -- [e-mail] <mailto:[e-mail]>
>                                 To unsubscribe send an email to [e-mail] <mailto:[e-mail]>____
> 
> 
>                             _______________________________________________
>                             v6ops mailing list -- [e-mail] <mailto:[e-mail]>
>                             To unsubscribe send an email to [e-mail] <mailto:[e-mail]>____
> 
> 
> 
> 
>                         --
>                         Cheers, Jen Linkova____
> 
>                     __ __
> 
> 
> 
>                 --
>                 Cheers, Jen Linkova____
> 
>             __ __
> 
> 
> 
>         -- 
>         Cheers, Jen Linkova____
> 
>     __ __
> 
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]