[ppml] Draft ARIN Recomendation

[Leo Bicknell]

I will attempt to articulate all of the objections to both proposals.  I
believe these are critical issues that need to be considered by a wider
audience.

Who makes these objections is an interesting point.  I believe most
of these are personal objections; engineers saying "that's not the
way we want it done."  There are also objections from ARIN's point
of view as an organization, and I think these may not have been
clearly articulated before.

I'm going to start with the implications to ARIN, as I believe all
of the other points are in support of the meta-issue of how these
proposals affect RIR's.  We need to start with ARIN's mission
statement and purpose:

   Mission Statement (from http://www.arin.net/about_us/index.html)

   Applying the principles of stewardship, ARIN, a nonprofit
   corporation, allocates Internet Protocol resources, develops
   consensus based policies; and facilitates the advancement of the
   Internet through information and education outreach.

Indeed, on that same page, we begin to see the mission statement
applied:

   We at the American Registry for Internet Numbers manage the
   Internet numbering resources for North America, a portion of the
   Caribbean, and sub-equatorial Africa.

Using this information, I'm going to put forth an alternative
statement which I think many network engineers (eg, "the Nanog
crowd") would agree, and most ARIN members would not disagree with:

   ARIN Manages globally unique address identifiers for the ARIN Region.

I believe it is now obvious why the ARIN Membership should be
concerned with these proposals.  Both proposals in attempting to
create globally unique identifiers that could be used in the ARIN
region create confusion and competition.  I don't think I can say
much more on the confusion issue, however I do want to speak to the
competition issue.

ARIN continues to operate because it collects fees from its members.
Members continue to pay ARIN because they realize there is a need
for a globally unique identifier management system, that it costs
money, and that ARIN does a good job.

If there existed a system where people could get globally unique
identifiers for free, I believe they would.  We have already seen
objections from some parts of the world that fees are too high, and
a barrier to entry.  Also, in this day of cost conscious operating
I believe many engineers would wonder why they don't abandon the
globally unique numbers provided by ARIN for a fee, for the globally
unique identifiers that are free.  Put simply, these proposals create
a direct financial incentive for people NOT to use ARIN's services.

Aside from the direct financial threat, I believe ARIN has an
interest in the second proposal for two additional reasons.  ARIN
has been integral in the creation of LANIC and AfriNIC, and indeed
has helped develop the process for creating a new registry.  The
second proposal wants to create a new registry with no acknowledgment
of this existing system for creating a new registry.  I think it
would be bad precedent for ARIN to allow an IETF draft to "create"
a new registry function without going through the processes that
are already in place.

Similarly, ARIN takes a strong view in its own policy process that
the issue of fees is not appropriate for the policy process.  I
think ARIN has strong reasons to not let the IETF dictate fees for
all the same reasons.  The second proposal talks about "Permanent
with no periodic fees", and on that basis alone is a bad proposal.

Now that I have outlined why I think ARIN has a group needs to be
involved, I will also outline why I personally think these proposals
will not be successful in the way the authors intend.

We start with draft-ietf-ipv6-unique-local-addr-06.txt

When looking at this proposal I think it's important to consider all
the ways someone may attempt to use this address space.  Section
3.1 is where we start to go wrong.  We have to years of history of 
CIDR.  For some reason the IPv6 community wants to throw that out,
and more particularly thinks they can change peoples thinking back
to fixed boundaries.  Well, that's not the way people think today,
and I think most people consider that a step backwards.

The reality here is that this proposal creates "FC00::/7" that is
equivalent to 10/8 in IPv4.  It's a novel idea to set aside 41 bits
for "global ID", but I don't think anyone will use it that way.  
Think of the two most obvious uses of 10/8, and directly map them
to how those organizations will use FC00::/7:

  * Small, non-distributed group:

    Uses 10/8 in sequence (10.0.0/24, 10.0.1/24, 10.0.2/24, etc).
    Often has no consideration of global issues, often poorly
    allocates space (eg, gives whole /16's to individual ethernets
    because they can).

    These people are going to use FC00::/7 in a similar way.  I
    predict you will see FC00:0000:0000:0000, FC00:0000:0000:0001,
    etc.

  * Large, distributed group:

    Has an internal central function that manages 10/8 and subdelegates
    various bits (10.0/16, 10.1/16, 10.2/16 etc) to various subgroups
    inside the company for local management.

    Many in this group will actually love having the larger address
    space.  They aren't going to manage "randomly assigned" addresses,
    they are going to use the space to delegate control.  Given the
    way DNS works, I suspect they will choose to do the delegation on
    a nibble boundary.  What that really means is of the 41 bits, there
    is the ability to tree 10 delegations deep.

    So, here you'll see FC00:0/12 to subdivision #1, FC00:1/12 to
    subdivision #2 and so on.  They will then redelegate FC00:00/16,
    FC00:01/16, and so on.

Moving on to the issue of collisions, I believe the analysis in
section 3.2.3 is incomplete.  Most importantly, it operates only
on a single variable, the number of connections, not on the two
values in use, the number of connections and the number of addresses
in use by each entity.  What the text has done is assume the second
variable is always one (that an entity only brings one network to
the table).  This is convenient, but majorly underestimates the
problem.

Since these numbers can be randomly picked, a large organization
is likely to end up with multiple subgroups picking networks, and
later having them all connected together.  I'll be conservative,
and say that a group might bring on the order of 10 networks to the
interconnection system given this allocation scheme.  That dramatically
increases the probability of collision.

I think any group of size who used these prefixes could never count
on using them to interconnect with another group.  To that end, I
would like to rewrite this entire draft:

   "FC00::/7 has been set aside for private network use, and should
   not ever appear on the global network.  Service providers should
   filter FC00::/7 at all boarders."

The rest of the text is wishful thinking, and not good engineering.
Rewritten that way, I think it's good.  We need private (think 1918)
IPv6 space set aside, and I think a /7 is more than enough.  No mention
should be made of it being used for any connectivity outside an
organization, it just won't work.

Now, looking at draft-ietf-ipv6-ula-central-00.txt we have much more
serious issues.  Fundamentally it creates globally unique prefixes,
but somehow wants to prevent them from being used on the global
Internet.  What I find curious is it offers no reason why this should
be the case.  Indeed, text in the draft repeatedly suggests this space
is compatible with the global routing table:

   "- If accidentally leaked outside of a site via routing or DNS,
      there is no conflict with any other addresses."

   "- In practice, applications may treat these addresses like global
      scoped addresses."

   "It is recommended that sites planning to use Local IPv6
    addresses for extensive inter-site communication, initially or as a
    future possibility, use a centrally assigned prefix as there is no
    possibility of assignment conflicts."

Indeed, if anything this creates an Internet without ISP's.  Businesses
can use these and interconnect to each other as much as they want
with no issues, but an ISP shouldn't route them in the global table.
As a provider I don't see how that can make any sense.

Section 3.2.1 describes a lot of requirements.  I'm going to pick these
off one by one:

  - Available to anyone in an unbiased manner.

    RIR's already deal with the problems of languages in their regions,
    and spend huge amounts of dollars on translations and other 
    activities to reach all groups.

  - Allocation on a permanent basis, without any need for renewal
    and without any procedure for de-allocation.

    The system is guaranteed to run out of addresses.  I will agree
    that it will be a long time before this happens, but with them
    being "throw away" I suspect it's likely that will be exactly
    what happens to them.  People who have trashed their existing
    allocation (eg, gotten it black listed) will just get a new one.
    Companies who spin up a new product/division/group will get a 
    new one.  The run rate will be far higher than anyone has predicted
    here.  This still gives us a long time before running out, but
    since the lifetime of this protocol is unknown, building in a
    method to burn through all the addresses does not fit with the
    stewardship role we all consider so important.

  - Provide mechanisms that prevent hoarding of these allocations.

    This has huge implications for verifying who a requester is, and
    cross referencing that information.  This will require large
    databases and high levels of computation.

  - The ownership of each individual allocation should be private,
    but should be escrowed.

    If it's private, how can anyone verify the ownership of a particular
    block when there is a dispute?  What group will handle dispute
    resolution?

  - Permanent with no periodic fees.

    Fundamentally the issue is all of the previous requirements incur
    cost.  ARIN doesn't sit around throwing money in the fire because
    there is nothing to do.  All the RIR's expend a lot of funds doing
    these functions today.  How the author thinks this can be done with
    no periodic fees is beyond me.  I think fees will be required to
    implement all of these requirements, and that discussion of the
    fees is inappropriate for a technical draft.

In summary, even if I ignore the issue of how you do this without
charging fees, I think this proposal has the business possibility
of seriously impacting the RIR's viability.  By allowing people to
get globally unique identifiers for free there will be great pressure
by underfunded segments of society (from poor countries to poor
business to poor individuals) to use their limited resources to
push others to accept these prefixes, rather than use them to
support the existing registries.

There is a long history that "connectivity is its own reward".  The
Internet exists in part because people take an extremely flexible
approach to building the network.  Run IP over anything.  Gateway
to any and all networks for any and all protocols and services
possible.  If companies and countries are given economic incentive
to globally route these prefixes that is exactly what will happen.

Sadly, this proposal creates not one, but two tiers to encourage 
global routing of these prefixes.  First, it is directly cheaper
(no fees) to use these prefixes.  Second, and far more important,
if someone has already globally uniquely numbered their whole network
they are not going to want to renumber it, due to the huge cost in
staff time, to connect to the Internet, and will offer money to
ISP's to simply route the prefixes.

Now, many in the IPv6 world point out one of the design goals was
to allow hosts to be on multiple networks.  The thought was someone
might use one of these local addressing schemes, along with addresses
from one or more providers.  While I think the designers did a good
job of making the protocol make that happen, I think the practical
aspects of that were completely forgotten.

The deployment of a network, even if the hosts allow it, has
significant costs.  Addresses must be obtained.  Network services
(dhcp servers, routers, etc) need to be updated.  Firewalls and
other security devices need to be updated.  Indeed, in many cases
applications themselves need much more sophistication to know which
address to use for which sort of access.

I can't see any sane network admin administering a network of any
size with multiple full overlay networks.  At best, they will do
NAT, at worst they will refuse to use more than a single network.
It is simply not practical to expend resources on managing multiple
networks.

I do think both proposals are bad for the Internet, and in the case
of the second in particular bad for ARIN.  I have seen no argument
in any forum to do more than allocate a single /mumble for "private
networks".  All of the other grand ideas are nothing but wishful
thinking, and do not account for any of the other motivations
(financial, black-hat, etc) that users might operate under.  Those
of us who feel the financial pressures on a daily basis, and who
see people abusing the existing system on a daily basis realize
this makes it far easier for abuse to happen, and that's never a
good thing.

-- 
       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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20041022/6c5fe230/attachment.sig>