In your letter dated Sat, 17 May 2014 12:17:18 +0200 you wrote:
True. However, keep in mind that this was true for the main ESSID "ripemtg" this year too: People with devices that didn't support 5GHz had to connect to the secondary ESSID.
We wouldn't be the first conference to do so, either: https://fosdem.org/2014/news/2014-02-01-pushing-ipv6/
Did a smiley get dropped? I know that IPv6 is boring enough that we need to come up with a new tunneling protocol every year to keep things interesting. But really? Af far as I can tell, the meeting network was perfect this year. When I opened my laptop, it just worked, both IPv4 and IPv6. So this proposal: - Introduces NAT when we now have real IPv4 connectivity. - The DNSSEC community is moving toward local validation. In the context of DNS64 this means no IPv4 connectivity for hosts that do local validation (can be fixed with NAT464) - Many people use third party DNS resolvers, like Google's. In the context of NAT64, this means no IPv4 connectivity (unless NAT464) - IPv4 literals also require NAT464. So the problems caused by NAT64 can be fixed by doing NAT464. Great. Then I need to ran NAT on my host and I get double NAT. Good luck trying to debug networking problems in that setup. So where we now have native IPv4 and dual stack that is supported by all devices (legacy devices that don't do IPv6 just work as before) the prosoal is to add a huge amount of protocol complexity, needlessly kill support for legacy devices. And complain about dual stack devices (like Android) that just don't support the tunneling protocol of the day. Maybe we can just leave it to the NCC ops to provide good IPv4 and IPv6 connectivity on the default network?