Re: IPv6 only host NAT64 requirements?

[Mark Andrews <[e-mail]>]

> On 19 Nov 2017, at 8:45 pm, Mikael Abrahamsson <[e-mail]> wrote:
> 
> On Sun, 19 Nov 2017, Ole Troan wrote:
> 
>> The challenge we have in front of us is to make IPv6 only work.
> 
> When I speak to vendors about this, I get different answers. Some are saying "nobody will deploy IPv6 only, so why should I make changes in my desktop OS to support it for legacy applications?”

Well as this stage you can say that there are ISP that are deploying IPv6-only on
the access network with DS-Lite to provide IPv4 as a service.  If you want your
host to be able to connect directly to such ISPs you need to add support to detect
that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in IPv6 tunnel to
the ISPs B4 router.

Repeat this for other transition technologies that you are aware is in use.

> And I imagine any access provider will say "I can't deploy IPv6 only, because it'll break a lot of applications that people are using on desktop OSes".
> 
> So this is classic catch 22.

You stop talk ipv6-only and start talking ipv6-only access + ipv4 as a service.

It’s only a “catch 22” because people fail to look at the options available.  ISPs
are going ipv6-only access + ipv4 as a service because it is easier to manage than
dual stack access + 44CGN.   Many ISPs deliver CPE routers that support DS-Lite
so the customer still see IPv4 + IPv6.

The question to host vendors is “do you want your machines to be able to connect
directly to ISP’s that have ipv6-only access networks or not?”  Ipv6-only access
networks are a reality.

> This was fixed on Android by throwing up hands and giving up on IPv6 only, and just installing CLAT on it to make sure most legacy applications just work.
> 
> On iOS it was fixed by doing bump-in-the-API plus mandating Apps work properly, and then waiting, and weeding out apps that didn't work because some mobile operators said "we're going to deploy this on a per-device type basis" after testing that these workarounds were successful.
> 
> MacOS is in-between, because applications that use the Apple APIs get bump-in-the-API help, but the ones that use the socket API doesn't. So here it's a mix of both worlds.
> 
> Windows has none of this. Linux also has none of this out of the box on any flavour of Linux I am aware of. This means lots of applications do not work.
> 
> Long tail of applications, is long.
> 
> Believing that all apps will get fixed on Windows and Linux (and MacOS) is for me a veeeeery long game to play. Also it's a nice idea to start opening tickets and trying to get them fixed, but again. Long tail is long.
> 
> So only practical way forward here I can see that would yield rewards in the next few years is for OSes to implement bump-in-the-API even for legacy socket API using applications, that would automatically turn on NAT64 traversal for legacy IPv4 applications.
> 
> -- 
> Mikael Abrahamsson    email: [e-mail]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]