Harald,
While I agree with most of your analysis, I think there is a
different view of address space exhaustion that might be more
helpful and that there are several things the IETF can do to
impede the spread of IPv6. The other side of the "why bother
deploying it" argument is "ok, we've decided we need to deploy
it sooner or later because <pick your reason>, what are the
impediments to doing it now versus incentives to delay".
You wrote...
--On Saturday, 06 November, 2004 09:53 +0100 Harald Tveit
Alvestrand <harald@xxxxxxxxxxxxx> wrote:
>...
> .... and as I see
> it, we're never going to run out; the market will just raise
> the price of IPv4 addresses until the market balks. Just like
> crude oil, but quite a few years sooner. Luckily, unlike oil,
> alternates exist!
> So the death of IPv4 isn't going to happen with a bang. More
> like a protracted series of whimpers - from the accountants
> paying for those pesky numbers.
Yes, although there will also be bangs. For example, prying
legacy Class As (/8s) out of the hands of some of the holders
who don't have them utilized optimally (whatever that means at
the time) is likely to require either levels of money that are
well above the pay grade of accountants or drama in
international relations. But I believe that a better measure of
"when do we run out" is when technically or administratively
bizarre things start happening because of the perception that
addresses are too scarce or expensive or hard to obtain. Every
time someone is told "the third or fourth public address for
your SOHO network is going to involve an astronomical charge",
it should be taken as a sign that we are already out of IPv4
space. Every time someone wants to multihome, or even create a
dial backup for, a small network and discovers that there are no
options that avoid NATs, it is a signal that we have run out of
IPv4 address space. Every time a vendor ships a relatively high
end, "professional", small enterprise router or firewall that
forces the LAN to be NAT-only because they can't figure out how
to support public addresses on that LAN, it is a sign that we
have already run out of address space or worse. And every time
a protocol design becomes vastly more complicated because of the
need to deal with private address spaces (especially cascaded
ones), it is a sign that we are already out of IPv4 space.
The point isn't how restrictive RIR policies might get as the
wolf is seem approaching the door, or how expensive the
next-to-last available block might be, but when the design of
the network and its protocols and applications start being
distorted by the perceived space shortage. I suggest we crossed
that line some time ago.
However,
> In IPv6, I see our job as standardizers to make sure the thing
> we have defined is well-defined enough to let it work, and
> then get the hell out of the way.
> At this time, it's the users and the network builders who will
> decide whether we've succeeded or failed. Not us standardizers.
> We can do minor maintenance and "hey, we didn't mean it that
> way", but the best we can do for IPv6 is to point out all the
> stuff that is done, stable, and is NOT going to change any
> time soon.
Even if we ignore the address space issues entirely, we will
slide smoothly from "NATs in IPv4" to "NATs in IPv6" or, more
likely, "ever more clever NATs and NAT technologies in IPv4"
unless we are successful in nailing down the mechanisms to
accomplish the sorts of configuration and goals in IPv6 that are
causing NATs in IPv4. My sense is that we haven't done that
yet. We may even be a bit behind where we thought we were 18
months ago.
Conversely, I keep running into organizations who look at IETF
activities relative to IPv6 and say things like "if they are
still developing/ designing IPv6 in the standards bodies, it
isn't ready to deploy yet; maybe part of the Internet's success
is that they haven't felt a need to mess with IPv4 in a very
long time". I think the IETF hasn't been nearly sensitive
enough to that issue, which falls in the "shoot selfs in foot"
range.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf