For quite some time, an idea has been hatching at the IETF to make more explicit moves to use IPv6-only networks at its meetings.
During the past few meetings, we’ve experimented with going IPv6-only in select plenary sessions – alternating IPv6 SSID on wireless and exploring different forms of transition technologies.
New Draft: “Incremental Deployment of #IPv6-only Wi-Fi for #IETF Meetings” https://t.co/RcQDMDwWly
— RFC Bot (@rfcbot) July 1, 2017
At IETF 100, this experimentation became more solid, as a number of working groups (not just plenaries) stopped the IPv4 classic WiFi and put people behind IPv6-only or IPv6 with DNS64 or NAT64 methods of accessing the IPv4 network – they tried to restrict this to specific base stations in radio view.
This was interesting on several fronts.
First, because it’s a volume ‘in the wild’ test to see all the things which geeks do when they are on a network: they go back to work; they connect over secure nets; they read the web and do banking like normal people; and, they are vocal when it doesn’t work. So as a feedback mechanism, it’s pretty good, loud, and immediate.
Secondly, it allows the network folk to work the problem in almost real-time; although this can be a dual-edged sword — they may misdiagnose what is going on. However, if you ever want to discover a bug in some part of the IPv6 standards, and then get the affected software or hardware party to the table, you can’t ask for a better place for this to occour than at an IETF meeting.
In fact, we had instances of this happening this week in Singapore. Some corner case behaviour in Android, which tries to ‘taste’ if a network is Internet-connected and stops you using public WiFi bindings, misbehaved in some critical aspects. It turned out to be part of the Duplicate Address Detection logic—a bug— which was fixed at the IETF meeting by Android developers attending and the Network Operations Centre.
Instances like this aren’t actually entirely new. I am told that a long time ago, (back in the 80s when real programmers not only ate quiche, they wore Birkenstock sandals and had hair) Van Jacobsen hacked on TCP to fix a bug which caused synchronized ‘pulsing’ across the entire Internet at a conference. Perhaps our current bugs are a little less spectacular, but none the less they are real, and it’s nice to see them fixed, as we find them.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Were any results of the testing published? How many people used it? How happy were they? Any particular clients or applications had problems that aren’t fixed?
There will be results published – we are still working on processing the data. Stay tuned.