Date: Wed, 17 Nov 2004 06:55:38 -0500 (EST)
From: jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu (Noel Chiappa)
Message-ID:
<20041117115538(_dot_)0140F86AE0(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu>
| Let's assume what many people now seem to concede,
"concede" is a very poor word choice, "predict" perhaps, but more
probably, and more accurately, "hope", or even "pray".
| which is that a large part of the Internet is going
| to continue to be IPv4-only.
It simply cannot be. Either it dies (or atrophies, which is
essentially the same thing), or IPv4 is replaced by something.
No matter what we do, there is not enough IPv4 address space for
the core network to use to reach future end sites. Even if you
take the very best assumptions, assume we switch back to flat routing
(no more addresses lost to hierarchy), and we can cope with that,
and we assume we recover *all* the currently assigned portable
address blocks (the /8's that MIT, Stanford, etc all have), the /16's
that almost everyone who's been around for more than 15 years has,
and even all the /24's that are still being assigned today, and
allocate organisations (including ISPs and everyone else who currently
believes they qualify for more) all /28's, and flat route those, there
still aren't enough /28's available to number everyone who is going to
want to be numbered. Switch to /29 and it doesn't make a difference.
Get to /30 and just maybe, depending on demand into the future from
the currently under-developed countries - but that's not enough for
a site to provide any kind of reasonable service (can't have adequate
backup servers and such).
And, of course, those are absurd assumptions (flat routing /28 indeed!)
The core network, the part that needs to be able to identify end
sites, simply needs more addresses - and there's no way to fake it
via layers of NAT, end nodes from any random point on the net still
need to be able to indicate that it is my site (forget even about host),
and not yours, that they want to contact. That means that we have
to have different addresses (identifiers). IPv4 simply cannot last.
Of course, end user sites could keep using IPv4, and use something
like NAT to translate, to whatever the code network is using. And
for a while, no doubt some will continue. But why would that do
that indefinitely, it makes no sense? The translation is just an
extra cost/management burden that they don't really need - after all,
all (at least if it is IPv6 that the core switches to), all the
end-user equipment that counts already supports IPv6, switching end
sites now is easy (and relatively painless).
Whether what the core switches to is IPv6, or something different
can't be concluded with certainty of course, but the "we don't need
to change from v4, ever" attitude is simply absurd. The timeframe
when a switch will finally be mandatory, rather than simply a
plausible choice, is also not yet certain. But there's no way
to pretend that something isn't coming. We knew that back in 92.
Nothing has altered to change that reality - if anything, back then
the endemic nature of the net wasn't yet certain, so then it was
possible that the net would in reality never grow big enough to
outgrow v4. Now (again, unless the net dies) that's no longer an
option.
So ...
| So, what's the functional difference between:
|
| - A host which has an IPv6 only address, which it cannot use (without
| "borrowing" a global IPv4 address) to comunicate directly with IPv4-only
| hosts out on the global Internet.
|
| - A host which has an IPv4 local-only address, which it cannot use (without
| "borrowing" a global IPv4 address) to comunicate directly with other IPv4
| hosts out on the global Internet.
short term, of course, nothing. But the former has the possibility,
even expectation, of the "borrowing" simply ending, most likely even
in the not too distant future (though certainly beyond the end of the
financial year, and so way out of scope of many people's thoughts...)
kre
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf