So, looks like I’m not alone believing that instead of just NAT64+DNS64 what we actually need is what will solve the problem in the *real world*, which is CLAT in the LAN networks:
1) Having the IETF SSID with CLAT (as I’m suggesting that the “IPv6-only” CPEs – in the sense of IPv6-only-WAN, must support CLAT)
2) Having the hosts supporting CLAT as well, because bump-in-the-API doesn’t work for many apps that uses literals and don’t use the APIs. This is needed for tablets, laptops and cellular, because they can be used in a network behind a device offering tethering, otherwise 1 above will be enough.
And yes, in an ideal world, app developers/vendors will make sure to avoid using literals, and we don’t need to be the police+baby sitters, not counting the problem of old devices/apps that are no longer in the market and nobody will be able to take care of those. So again, best solution is 1+2.
Human nature has proven that we only reported 5-6 tickets, because human nature, when time is previous, during the meeting, will make that folks (including myself as my email wat not working on the NAT64 network), which detect a single “critical” failure (for them), move back to the dual-stack SSID (and only maybe report it).
I suggested having a small development to detect those apps automatically if we have a CLAT in the default SSID with the NAT64-DNS64. Yes, we will have no public IPv4 addresses, but at least we don’t break apps, so the people don’t need to move to the regular dual stack network (unless they need a public IP, which I’m not sure if it is common because in real-world you typically don’t have it). The next hackathon may be an opportunity to do that if we don’t find somebody before in the open source community to work on that. We may start with a simple VM with Jool, which is a powerful open source implementation for NAT64, SIIT, CLAT, etc. and have something that “increase” the log level to what we need. Even if it is not perfect, even if we only detect 20-30% of the broken apps (which will be all those using the CLAT, and I think will be more than this %, just being pessimistic), it will be much more than what we detect AND report “manually”.
We still have the issue of who takes the responsibility to inform the broken apps developers/vendors and track them to make sure it gets corrected …
Regards,
Jordi
-----Mensaje original-----
De: ietf <ietf-bounces@xxxxxxxx> en nombre de Mikael Abrahamsson <swmike@xxxxxxxxx>
Organización: People's Front Against WWW
Responder a: <swmike@xxxxxxxxx>
Fecha: domingo, 30 de julio de 2017, 7:36
Para: Randy Bush <randy@xxxxxxx>
CC: IETF Rinse Repeat <ietf@xxxxxxxx>
Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings
On Sun, 30 Jul 2017, Randy Bush wrote:
>> The point is that we claim that we have produced something that will
>> Just Work for the average user. If you really think you can't "get
>> work done" on an IPv6-only network with working and functional
>> transition tech, we have a problem.
>
> bingo! you are right. we have a problem. nat64/dns64 breaks things
> people use. this is known, documented, and extremely annoying this many
> years out [0].
>
> the question is how to progress fixing nat64/dns64, given that a lot of
> folk come to ietf meetings to simply get work done and not debug a semi-
> working transport. how about a bug bounty? and maybe a fix bounty a
> few times larger!
There is nothing inherently broken with NAT64+DNS64+CLAT (or something
like iOS has with bump-in-the-API).
Android has CLAT. iOS has its bump-in-the-API.
Win10 doesn't have any of this (the adviced CLAT is on WWAN only and
mobile only). MacOS has bump-in-the-API for devices that use those APIs,
which a lot doesn't. Anything uses the socket API doesn't get this. Linux
doesn't have this out of the box afaik.
So there is nothing to be fixed for NAT64+DNS64, what needs to be fixed is
that these operating systems need to support v4 literals through NAT64 by
some kind of mechanism. Android does. iOS does. Nothing else does.
This is already well known. This "experiment" being proposed is in my mind
useless because the outcome is already known. I connected a Win10 box to
my NAT64+DNS64 experimental network two days ago to re-verify, and there
were plenty of things that didn't work. Windows update doesn't think it's
connected to the Internet. Steam won't even start.
Or is the objective of the experiment to have people from the operating
system vendors discover that their operating systems has problems and that
this discovery would make them fix these problems?
I emailed people at Microsoft about my 464XLAT findings. That resulted in
me being told that the blog post would be updated and that a discussion
would be had regarding that 464XLAT functionality perhaps coming to more
generic use cases. I have already told people from Apples networking stack
development team about my problems with NAT64+DNS64 and my VMs and also
things using the socket API.
It seems a lot easier to just reach out to the OS vendors and tell them,
than to try to use the painful detour of showing already known breakage on
the IETF wifi for everybody to discover, most of who can do nothing about
it.
--
Mikael Abrahamsson email: swmike@xxxxxxxxx
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.