On Wed, Dec 19, 2007 at 11:01:28AM -0800, Hallam-Baker, Phillip wrote:
The oldie perspective of 'take it or leave it' is not going to work
here. I have gamed the dynamics of IPv4 exhaustion quite extensively
and the mere fact that there are no more IPv4 addresses left to be
allocated does not provide the forcing function people imagine.
Hallam,
I think the IETF oldie perspective is the amazement that
people are pushing back so hard about using the IETF conference
network as an early deployment/proving ground for IPv6. I remember
when IP addresses were handed out on pieces of paper, and when DHCP
was first deployed, and not quite reliable. Then I remember it not
getting reliable again as IETF host after IETF host had to learn the
hard way that Microsoft's DHCP server was cr*p (at least back then)
and blew up at the scale of IETF meetings (which were much smaller
back then).
I suspect the real problem is the mix of IETF attendees have
changed, and there are fewer people who are willing to experiment with
bleeding edge technology at the network layer. I suspect these are
the sort of people who are arguing that IPv4 is a production service
that can't be interrupted come hell or high water, and they aren't
willing to pay the pain of helping to make IPv6 work.
There are also some IETF'ers who have argued that IPv6 is not
the only game in town, but that NAT boxes will also work; there are
other IETF'ers who have argued that IPv6 is a superior solution to NAT
boxes, and that NAT boxes will either not work, or are an abomination
(at least from an architectural point of view.)
I'll argue that the real problem is that we haven't been
serious about IPv6. If we had, people who have been pushing ICANN to
solve the DNS root problem a long time ago. If we had, we would have
been trying deploy an IPv6-only conference network, to make sure that
technical requirements make an IPv6-only network be able to play well
with the wider network (an absolute necesity from a transition point
of view) either had permanent fixes, or at least had documented
workarounds that work at least as well as IPv4 NAT boxes.
I'm not sure whether or not the lack of workarounds are
because some of the people using the IPv6 networks were too much of a
network purist to use whatever workarounds would be necessary to make
IPv6 work in the real world --- whether they be NAT-PT/NAT64 boxes, or
DNS root hijacking, or whatever else is necessary. 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.
The fact that ICANN was allowed to dither until early 2008
before getting root zone records is a sign that IPv6 was not ready for
the real-world for the last ten years. The question is what other
real-world deployment problems are hiding that haven't been addressed
yet.
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. And other groups
and venues have had the last ten years to try to work out these
solutions, and clear they need more help and more effort --- and I
would hope the IETF collectively feels some responsibility to help out
this protocol that we launched NINE YEARS AGO.
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. If after a ten years --- a decade --- we can't somehow
make IPv6 to be a useful production network on something on the scale
of the IETF wireless network, I would argue that IPv6 really is
useless and hopeless and doomed, with no way to transition to real
world Internet production usage. Or maybe it would be saying
something about the state of the IETF organization. I don't know....
- Ted
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf