In your letter dated Tue, 3 Nov 2015 09:32:21 +0100 you wrote:
On Tue, Nov 03, 2015 at 11:21:42AM +0900, Shane Kerr wrote:
tl;dr Don't so cautious. Removing the "experimental" tag from IPv6 won't ruin the RIPE meeting.
What Shane said. Short and long form :-)
The world *will* end, obviously, but it won't be due to removing the experimental tag from the IPv6-only SSID.
(Pointing out that even Apple is requiring their developers to handle IPv6 nowadays...)
There is something I don't understand about this discussion. The network at RIPE meetings currently provides a good network experience. The wifi works, there is IPv6 that works, and for those living in the past (which is essentially all of us, because only a small fraction of the internet is actually reachable over IPv6), there is also native IPv4. The surprising thing to me is that there is a request to the ops team at the meeting to provide broken IPv4 by default. I can understand the desire to have experimental networks at a meeting to test what works and what doesn't work. But why should such a broken network be default? There are many broken networks in the world. Wifi often doesn't work, in many places there is no 3G GSM. Do we want to replicate that as well at a RIPE meeting? And even if only a limited number of IPv4 addresses were available such that some form of NAT would be required, it would be weird to require the ops team to deploy one particular solution (NAT64) instead of letting the ops team figure out which is best way to provide a network at the RIPE meeting. (Can't wait for a request for Atlas to support NAT64, that's going to be interesting) Another interesting can of worms is how to do DNSSEC local valication on the context of NAT64.