Re: [v6ops] IPREF as a transitioning tool

In fairness, what mobile operators have demonstrated is a relatively limited
set of clients being not significantly worse off with iPv6 only and an IPv4AAS
capability on the client side to reach IPv4-only services.

That’s not so much the case with IPv6-only on the server side and some form
of IPv4AAS to handle IPv4-only clients.

Owen

> On Nov 12, 2023, at 02:10, Gert Doering <gert@space.net> wrote:
> 
> Hi,
> 
> On Sat, Nov 11, 2023 at 03:57:08AM -0800, waldemar wrote:
>> That's correct, but
>> no site would ever employ dual stacks inside their network. That alone is a
>> gain, and indeed that is the way to do away with existing internal dual
>> stacks.
> 
> That would be a great result (sites being able to run ipv6-only today) -
> but we do not need IPERF for that, NAT64/DNS64 (and possibly 464XLAT)
> would enable that just fine.
> 
> Why is it not happening?  Because applications still hard-code IPv4 sockets,
> and IPv4 addresses, so require an IPv4 path in the local network (or a
> local CLAT).
> 
> When we have these all fixed, we can go ipv6-only in the local network
> and use NAT64/DNS64 to reach those last bastions of IPv4.  Mobile operators
> have demonstrated that this works nicely - 10 years ago already.
> 
> 
> So, what extra advantage would this new mechanism which would need to
> be deployed everywhere (your words) bring?
> 
> (And why did LISP not succeed?)
> 
> Gert Doering
>        -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops