Important IPv6 Policy Issue -- Your Input Requested

Tue Nov 9 16:27:43 UTC 2004

In a message written on Tue, Nov 09, 2004 at 09:17:30AM +0100, Iljitsch van Beijnum wrote:
> If both companies use either registered globally unique space (which  
> also has the important property you get to know who the packets come  
> from when they show up in the wrong places) or use the unregistered  
> variant with proper hashing, the chance of collisions is negligible.

My comment here was directed at the unregistered variant.  You'll
notice the math in the paper assumes each company coming to the
table has a single IPv6 unregistered prefix.

My statement is that math does not reflect reality.  Consider when
Cisco wants to do a interconnect with AOL Time Warner, which due
to the way they grow both bring 1,000 prefixes to the table.  The
chance of collision is actually quite high.

Almost more interesting is consider the "financial interchange
network" where 100 companies come together each with 20 networks.
I believe even with that relatively small number of networks (2000
total) the probability of collision is well more than 50%.

This is very similar to the birthday problem.
http://mathforum.org/dr.math/faq/faq.birthdayprob.html  It only
takes 23 people (6% of the 365 available birthdays) to generate a
50% chance of collision, with them only bringing one birthday to
the table.  Bring 20 "birthdays" to the table for each one and that
number drops by orders of magnitude.

> And unlike IPv4, it's easy to give all hosts more than one address and  
> renumbering the hosts themselves is fairly straightforward.

Another incorrect assumption.  First, I want to dispel the notion right
now that anyone is going to use IPv6 autoconfiguration.  That's another
head in the sand idea.  We have two groups here.  People who run "fixed
infrastructure", which include network operators and server operators,
and the second group is "end user workstations".

The first group has always, and will always statically assign addresses.
This will be true with IPv6.  They want to know when they swap out a NIC
the address doesn't change.  They enter IP's in DNS and other systems
where having them be static is key.

The second group could use autoconfiguration, except it provides none
of what they need.  Look at the people using DHCP today.  They need
to get nameserver IP's, WINS server IP's, NTP server IP's, configuration
file names and all sorts of other information.  They will continue to
require DHCP for those tasks.  Indeed, just to do DNS mapping again
DHCP is required.

So, for both groups to "renumber" it's no different than today.  One
group will still have to manually add/subtract IP's.  The other will
have to update DHCP scopes, force renewals, and the like.

Best I can tell renumbering will be NO LESS expensive in IPv6, and
actually will be more expensive, since the IPv6 proponents seem bent
on requiring everyone to have 6 addresses to do anything useful, so
it will be address management effort x6.

> Disagree. You know the hashing space isn't 100% unique. And it doesn't  
> need to be: it only needs to be unique between the people who use the  
> new type of site local addresses to communicate between them. IIRC  
> there are 40 bits so when a million or so of these prefixes are used  
> you're going to start seeing some collisions - if you look globally.  
> But the chance of two networks colliding is still one in a trillion  
> (with good hashing) and the chance of a thousand networks colliding is  
> almost zero. This is actually smaller than the chance that two ethernet  
> cards have the same MAC address. (Once in a blue moon batches of NICs  
> with the same MAC address are built, but the chance of finding two that  
> clash is relatively large if you buy several because they are likely  
> manufactured right after each other.)

Again, see the birthday problem and do the math.  I don't think the
probability is nearly as remote as you think it is, or as the document
would lead you to believe.

> And there's still the registered variant.

Which brings us back to why are there two proposals.  If there is any
chance the randomly assigned ones will fail, then we should do globals.
If they aren't going to fail, we should only do random.  I have to
believe the existence of the second proposal is an indication the first
one won't meet it's goals.

> With registered space you have the additional benefit that when packets  
> leak, they can be traced back to the originator, and it's possible to  
> delegate name service.

Except the draft doesn't allow for that.  I quote:

   The ownership of the allocations is not needed to be public since the
   resulting addresses are intended to be used for local communication.

The draft does not make that information public.

> I think all of this can be done in very similar vain to registering  
> domains. Since there is plenty of competition there, this will probably  
> be sufficiently cheap that even organizations in less developed  
> countries can afford it.

The draft also states, and I quote:

      - Permanent with no periodic fees.

So yes, everyone will be able to afford it.  There is not a competition
angle here.  There is a huge question of how you're going to run a
registry with no funding though.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org