Re: IPv4 Outage Planned for IETF 71 Plenary

[Theodore Tso <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf