> However, I would gently suggest that if people want IPv6 to > be successful, we need to start using it, and we need to > start creating the engineering solutions that allow IPv6 to > be useful in the real-world. Yes. And that includes figuring out what is needed to make an IETF meeting function with only IPv6 transit connections to the outside world including full support for IPv4 users at the meeting. "Full Support" in this context means making it possible for IPv4 users to seemlessly access IPv6-only services. If there is to be any kind of "IPv4 outage", it should be on some of the IETF servers that currently function on both IPv4 and IPv6 to prove that it is possible to make a transition to IPv6 that is relatively seamless to the end users of the Internet. > The > question is what other real-world deployment problems are > hiding that haven't been addressed yet. A mandate to make an IETF meeting function as described above would be a good way to get people to work on figuring out these problems. > There are some who seem to be arguing that the IETF is > not the place to work out these problems. Well, last I > checked, the word > *ENGINEERING* is in the name of our organization. I think there is a multileveled understanding of what engineering means that has led to some of the outraged comments. By some standards, many of the IETF participants, especially old-timers, are FORMER engineers because they don't get their hands dirty any more. By other standards they are EXPERIENCED engineers who don't need to get their hands dirty and can spend all their time planning, designing and vetting other people's work. The EXPERIENCED engineers are right that technology experiments which amount to a service outage should not be dumped on an IETF meeting. But the hands-on folks are also right that the IETF has an important role to play as the IP4 exhaustion crisis ramps up. It is because the pool of experienced engineers is avaliable as a resource, that it makes sense for a working group to plan, implement, TEST, and deploy whatever is needed to make it possible for an ENTIRE IETF meeting to function with no IPv4 Internet connectivity other than via automatic tunnels, proxies, and NATs. The IPv4 packet transport may be turned off at the lower layer but that doesn't mean that IPv4 users would get no service or even degraded service. Of course, such a demonstration could be done without involving the IETF at all, but then it loses a lot of the PR impact. For instance if the IETF meeting needs AAAA records in the root to avoid deploying root hijacking, then ICANN will act. If the IETF requests major service providers to participate in such a demonstration by turning on some type of IPv6 services in trial mode, then I suspect we will see Google and Microsoft and CNN and Verizon all join in the effort. > Let me give a challenge. It's been nine years. In the > next year, let's try to do whatever ENGINEERING work is > necessary so that the IETF conference network can offer > IPv6-only services to all of its laptop clients, and that > this be sufficient for people to get real work done. This means that it has to include transition technologies so that a pure IPv6 users can still get to all the IPv4 services that they need, and so that an IPv4 user can do the same. If you push this one step further and show that an IPv4 user on the IETF network can make use of IPv6-only services, then you will really make a splash in showing that IPv6 is ready for primetime. --Michael Dillon And once this has been proved at an IETF meeting, the next step is to do it at an event like Davos. <http://en.wikipedia.org/wiki/World_Economic_Forum> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf