On Tue, Dec 18, 2007 at 01:32:00PM -0500, John C Klensin wrote: > (1) The only thing this exercise, as described, is going to > prove is that we are skilled at shooting ourselves in the foot. > We already know that, at least in the US, IPv6 is insufficiently > deployed to provide a good base for communication and smooth > interoperability fabric. We know that there are no IPv6 records > in the root servers and that many of the root servers aren't > widely connected to IPv6 networks. We know that most IPv6 use > today involves tunnels between hosts or between network islands. > > Now we also know that skilled engineers and network operators > are capable of configuring their way around those problems. But > those who know how to do it know how to do it (and probably are > doing it already). Inviting the rest of the community to try to > sort things out in real-time in the plenary is silly at best. > It will make the plenary useless and deprive us of the > considerable advantages of being able to work together to > resolve issues. Let me suggest another approach. Don't do this at the next IETF meeting, but make an announcement that at some near-term IETF meeting, the only internet services provided at the IETF meeting will be IPv6. Note just for an hour. Not just for the plenery. Not just for the social; but FOR THE WHOLE WEEK. In other words, let people who are using the IETF wireless network experience what it might be like in some future world where the ISP's are only providing IPv6 connectivity and IPv6 addresses to new customers. Yes, right now IPv6 deployment isn't good enough that we can't do this without using all sorts of workarounds. OK, let's document those workarounds and make them available to the attendees. If it means that the IETF network provider has to hijack the root, then let them hijack the root on the IETF network, and document that fact. If there needs to be NAT-PT bridges to allow IETF'res to get back to their home networks connected to ISP's that don't yet offer IPv6 connectivty, then let there be NAT-PT bridges --- and document them. If various Windows, Macintosh, and Linux laptops need special configuration so to work around other problems, then document what the workarounds should be, and give people early warning and access to them. The first time this gets done, it will be painful. Maybe the first and second time there should be a wired terminal room for people who weren't able to configure their laptops in advance. (Or maybe the IPv4 network can be made available over the wireless on a separate SSID with a fee attached, with the excess monies going towards making funding technical work to make the IPv6 workarounds better documented and easier to deploy for future IETF meetings, and with the IPv4 fee gradually getting raised at each subsequent meeting.) Hopefully, with each subsequent IETF meeting, it will get easier, with the number of ugly kludges and workarounds needed gradually decreasing. And maybe it shouldn't be the IETF who does this first, but some other organization which is more focused on the network providers, such as RIPE. But the point is, if a conferenceful of network engineers can't provide IPv6 to a collection of its attendees, even if ugly hacks and workarouds are needed, what hope is there for everyone else? And if we put this off because "we're not ready yet", and hence fear the negative PR of failure, when will IPv6 be ready? And the press already knows that IPv6 isn't ready --- everyone knows that; so it's not a story. Now, if the entire IETF community could actually *use* IPv6 in an IPv6-only world, now *that* would be a story. And if it could use it without a huge number of hacks, that would be a stop-the-presses situation! Without a forcing function, alas, we may never be ready.... better that we provide a forcing function with relatively soft consequences, rather than a hard forcing function when the IPv4 address space is finally exhausted. - Ted _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf