Important IPv6 Policy Issue -- Your Input Requested

Mon Nov 8 21:46:48 UTC 2004

On 8-nov-04, at 20:25, Leo Bicknell wrote:

> I will post a very brief summary of my objections, for the first
> (unique-local):

>    - I believe the math is wrong on the rate of collisions, primarily
>      because it assumes in a large organization there is a central
>      coordination function to pick and distribute these addresses.
>      However, since the whole point of "unique local" addresses is that
>      there need be no coordination, I can easily see a case where a
>      large conglomerate (Ford, GE, whatever) coming together with
>      another will have both sides bringing hundreds, if not thoundsands
>      of prefixes to the table as each division or other subgroup picks
>      their own.

Well, if they can manage to interconnect all those networks a tiny 
amount of coordination isn't too much to ask for. Also, with the proper 
hashing this shouldn't be much of a problem even without coordination. 
Yes, no coordination and bad hashing won't work, but guess what: don't 
do that.

>    - I think the likelyhood people will use the suggested hash methods
>      to pick addresses is extremely low.  People will either pick 
> "human
>      friendly" (1, 2, 3, 4, etc) or treat the space more like CIDR
>      (where there is central delegation), both of which move the
>      likelyhood of collision to near 1.

>    In the end I think we need 1918 style space, and that it should
>    simply be set aside as a large block and expected to never be
>    useful in the context of other organizations, just like 1918
>    space is today.

Your argument is that people are going to be stupid so we should skip 
ahead and give them the result of their stupidity. Now obviously there 
will be people who do it the stupid way, but at least unique site 
locals allow the people who don't do it the stupid way certain 
benefits. I don't see how this can ever be a bad thing.

Also, you can still use the original IPv6 site local space, as I don't 
see it being reused for something else any time soon. But if you do, 
you'll probably discover that there is a reason why the IETF decided to 
deprecate those.

>    - It is not good engineering to give something away for free with no
>      method of recovery, even if that resource is plentiful.

So we should play telco and sell a service that is so cheap that the 
users are basically only paying for the billing? (= metered local 
calls)

>    - Since this is a free method of globally unique space it has a high
>      likelyhood of being routed on portions of the public internet.
>      Indeed, this problem was quickly dismissed by the authors
>      (see 
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg03848.html),
>      who completely missed the boat.  It's not the rich who would 
> demand
>      their prefix be routed, but the poor.

That's nice. But it simply can't be done for any significant number of 
PI prefixes. That's why we're going through so much trouble to create a 
multihoming mechanism that doesn't kill the routing system.

> Since this is a list of providers, I encourage you to read the
> drafts, and submit your comments to the working group.  The information
> for the working group is at
> http://www.ietf.org/html.charters/ipv6-charter.html, and includes
> their mailing list archives and information on how to subscribe
> and/or post.

> Even if you disagree with me, much like voting the important thing is
> that you voice your opinion.

I suggest that everyone who is willing to spend the time, also looks 
into the "site local" debates that have plagued the IETF in recent 
years.