Important IPv6 Policy Issue -- Your Input Requested

Mon Nov 8 19:25:00 UTC 2004

I would like to bring to the attention of Nanog an IPv6 policy issue
that I think is slipping under the radar right now.

The IETF IPv6 working group is considering two proposals right now
for IPv6 "private networks".  Think RFC-1918 type space, but redefined
for the IPv6 world.  Those two drafts can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt

These drafts came up in the ARIN meeting, and I posted my analysis of
the problems with both at:

http://www.arin.net/mailing_lists/ppml/2849.html

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.

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

The second proposal (ula-central) is much more dangerous.

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

   - The IETF should not be creating a new worldwide RIR.

   - The IETF should not be dictating fees (free).

     (more to the point, a worldwide RIR, with the language and other
     issues will be expensive, yet it has no method of income)

   - 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.  We already have situations
     where parts of Africa and Asia claim the fees for IP space are too
     high.  If they had access to "free" "global" space they would jump
     on it, and later if the rest of the world wanted to contact that
     region they would almost certainly have to route it as well.

   - The "ownership should be private", yet the reason for a registry
     is to verify ownership and prevent hoarding.  I'm not sure how those are
     combatable.

   - I think the IPv6 groups continue in their fantasy that people will
     manage multiple, complete overlay networks to fix numbering issues.

More to the point, it seems to me the working group is highly
enterprise focused, and seems to want to give enterprises what
they (think) they want with little concern for how it impacts the
global Internet.

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.

-- 
       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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041108/935bda50/attachment.sig>