The subject line on this thread is absolutely correct.
On Dec 5, 2007, at 13:32, Brian Dickson wrote:
Iljitsch van Beijnum wrote:
ULA is LOCAL.
It has nothing to do with PI.
People need address space to number the links between their SQL
and web servers. This is completely orthogonal to address space
used on the internet.
ULA is also UNIQUE.
(Well, for half of ULA, "probably unique").
The phrase you are looking for is "statistically unique."
"Probably," my house will still be standing in another thirty years.
Yet, I'm still paying for fire insurance. "Statistically," there is
no chance I'm going to die by being struck on the head directly by a
newly fallen meteorite. Am I concerned enough about my exposure to
the risk of falling meteorites to worry about whether my life
insurance policy covers it? Not at all.
Which gives me an idea: I should go into the insurance business,
selling ULA prefixes that I *GUARANTEE* (for an UNLIMITED TIME!!!) to
be ABSOLUTELY UNIQUE or I will pay triple the cost of migrating your
network to a new ULA prefix when a documented collision occurs. I
can do this with 5 lines of totally stateless Perl added to some
stupid web server— it's just a random number generator. I'll MAKE
ZILLIONS FAST!
It would be a service, rather than a disservice, to the community
of "network admins" (LAN admins), to educate them on the value of
uniqueness.
And the difference between "probably unique" and *statistically*
unique. Here's Brad DeLong explaining what kinds of tragedy can
befall the poor sod who fails to grasp the importance of statistics:
<http://delong.typepad.com/sdj/2007/12/intellectual-ga.html>
The key sentences...
This is the principal insight of the science of statistics. it is
an important insight. It is a powerful insight. It is also not an
*obvious* insight--that's what makes it powerful and important.
Emphasis mine.
And to point out the existence of a suitable replacement for IPv4's
10.0.0.0/8 et al, if they want a non-registered, non-unique, truly
non-routable address space that maps well to their current RFC
1918 space.
And that would be the IPv4-mapped IPv6 address space for RFC 1918.
I.e. ::ffff:10.0.0.0, ::ffff:172.16.0.0 and ::ffff:192.168.0.0 (as /
104, /108, and /112 respectively.)
And yes, I know it's ugly and rude.
Suresh Krishnan is correct. Please do not suggest anything remotely
close to this. Not V4MAPPED addresses. Not V4COMPAT addresses. Not
6to4-prefix addresses. Not Teredo addresses. Please do not embed
RFC 1918 addresses in IPv6 addresses full-stop. To do so is morally
equivalent to reinventing the functionality of the deprecated site-
local addresses in some other corner of the address space for no good
purpose. That way lies utter madness. Go not that way.
But it makes it easy for the end admin to manage the dual-stack
universe between their SQL and web servers.
If we're going to have another round of this discussion, can all the
participants please make a solemn pledge to read RFC 3879 all the way
through and to ask the authors, who are both regular participants
here, for help with the underlying concepts if any of them are
confusing? Please?
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
