Subject: RE: Comments on draft-ietf-ipv6-unique-local-addr-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Fri, 29 Aug 2003 09:55:00 -0700

Geoff's initial comment included the classic birthday paradox formula,
which would indeed apply if we were to use the randomly generated
addresses as global site identifiers valid across the Internet. The
practical consequence is that we should be extremely clear about the
usage limitation: randomly assigned addresses should in no way be used
as site identifiers. This should not even be left for further study, it
is just wrong.

The usage that is actually envisaged is more limited: an identifier that
provides disambiguation in a limited environment, normally a single
site, possibly a small number of sites directly linked by VPN-like
relations. In that scenario, the collisions that matter are those that
occur within this "working set" of connected sites. The probability of
such a collision is determined by the probability of collision "x"
between two identifiers (x = 2^-40 in our example) and by the size "W"
of the working set. The probability that single site does not collide
with any member of a working set is:

	P(collision in a set of size W) = 1 - (1-x)^(W-1)

There will be a large number of these working sets, probably as many as
there are sites -- each site will participate in average to W sets. The
probability that a given site observes a collision in one of its working
sets will be:

	P(collision in one of W sets) = 1 - (1-x)^(W*(W-1))

If we have N sites, the probability of observing one collision on the
Internet will be:

	P(collision in N sites with W sets) = 1 - (1-x)^(N*W*(W-1))

Given x=2^-40, the number N for which this probability equals .5 varies
with W as:

W	N
50	311070769
100	76982160
200	19148829
500	3054603
1000	762886
2000	190626
5000	30491
10000	7622 

Bottom line: using the random allocation in large working sets is a bad
idea. If people want to do that, they should register a unique
allocation instead.

One possible way to improve the situation is to have a provision for
small sites, in which we use a 56 bits random number to identify a link,
rather than a 40 bits random number identifying a site.

-- Christian Huitema 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Dan Lanciani <[email-masked]>
Date: Sat, 30 Aug 2003 00:01:34 -0400 (EDT)

"Alan E. Beard" <[email-masked]> wrote:

|As I understand the above text, routers are intended to discard traffic
|(as distinguished from routing protocol prefix propagation) with
|destination addresses in the range of FC00::/7 unless there exists in the
|routing table a prefix of the form FC00:*:*/48 or FD00:*:*/48 where the
|entire prefix matches the destination address of the subject packets.

That seems to be what you are suggesting, and it is totally unacceptable.

|This would imply that forwarding would be based on routing table longest
|match, with any packet matching FC00::/8 or FD00::/8 discarded, but, for
|example, traffic matching routing table entry FC00:DEAD:BEEF/48 forwarded.
|
|If my interpretation thus far is accurate, the issue postulated by Dan
|does not exist: as long as a specific route to the destination (perhaps,
|to any matching prefix with a length greater than /8) exists in the
|routing table, matching traffic will be forwarded.

There is a huge difference between requiring a /48 and allowing anything
greater than /8.  The former cripples the address space for many purposes
while the latter means that you can bypass the black hole with 2 or 4
route additions.  You can't have it both ways.

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Sat, 30 Aug 2003 02:31:22 -0400 (EDT)

|> |in the case you propose above, even if the black hole is
|> |universally implemented, two 'permit' statements, each for a /8 block
|> |(assuming we use the Hinden proposed address space block) would solve this
|> |problem.
|>
|> This is inconsistent with your requirement that ``Router manufacturers
|> MUST ensure that said black hole cannot be deconfigured, turned off, or
|> otherwise overridden in toto;''  You are now saying that all it takes to
|> override the black hole in toto is two more specific routes for the two
|> halves of the address space.  As soon as this is pointed out someone will
|> insist that the overriding routes must have some absurdly large prefix length,
|> e.g., /48.
|>
|
|The language concerning what may be required to configure partial override
|for the black hole was quite deliberately crafted so that several
|interpretations are possible;

We aren't talking about a partial override.  We are talking about a complete
override which your wording clearly prohibits.  If that isn't what you mean
then change the wording.

				Dan Lanciani
				ddl@danlan.*com