Important IPv6 Policy Issue -- Your Input Requested

Tue Nov 9 23:04:27 UTC 2004

On 9-nov-04, at 17:27, Leo Bicknell wrote:

> 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.

Why would a company need 1000 /48s, when a single /48 allows for 65536 
subnets?

> I believe even with that relatively small number of networks (2000
> total) the probability of collision is well more than 50%.

Ok, let's assume there are already 2k networks connected. So a new one 
would have a one in 2^(40-9) chance of colliding. Do this 2k times and 
you're at one in 2^22. (Actually less because I'm overlooking the 
chance of successive collisions.)

> 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.

But if birthdays are only celebrated once every 3 million millennia 
(2^40 days) the number goes down again ever so slightly.  :-)

>> 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.

We'll have to agree to disagree on this one, as I firmly believe very 
few people are going to use DHCP in IPv6.

> 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.

That's why your favorite C (and presumably other) boxes have the MAC 
addresses burned in the chassis rather than the NIC.

> They enter IP's in DNS and other systems where having them be static 
> is key.

Yes, renumbering the DNS still sux.  :-)

> 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.

Not so much. Autoconfiguration and some DNS resolvers is all I need.

> So, for both groups to "renumber" it's no different than today.

There is still a big difference: you get to use the old and new 
addresses side by side for a while.

> 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.

Renumbering is always bad, but there are degrees of badness. Fixed 
subnet masks, ample address space within subnets, multiple addresses 
all help, even if you discount autoconfiguration (which I don't) and 
all the filtering and DNS issues are of course the same.

>> 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.

Well, someone should, if not the draft.