[ppml] Suggestion for ARIN to deligate smaller IP blocks

[Paul_Vixie at isc.org]

> > > They need non-colliding addresses.
> > 
> > all RIR allocations (PI or PA) are non-colliding ("unique"), so this part
> > is already handled.
> 
> Yes, but if my network is too small to qualify for a PI or PA under current
> policy???

i'd previously written about part of that:

> > ...  your argument supports a policy for smaller-size PI allocations which
> > may be cheaper and may be easier to qualify for and may be allocated out
> > of a well known /10 to make them safe from static TE-resistant route
> > filters, but no argument i've seen here supports a policy for "unique
> > local addresses".

it's worth noting that networks might not have a provider and so PA might not
be a sensible way to number such networks.  i do wonder if a tunnel provider
acting as a LIR for the administrative purpose of keeping whois and in-addr
up to date could be a business somebody might want to be in.

> Well, I agree with that, but that wasn't my point.  My point was I need (in
> the sense of "would really really really like to have") unique addresses,
> and whether they are ULA-C or PI or whatever doesn't matter to *me*.  If one
> of these solutions is better than the others from someone else's standpoint,
> then that's fine with me, as long as I get my unique addresses.

to me, this is the best and clearest statement so far of the reason ULA has
been proposed.  everybody needs unique addresses, even if they're unconnected
at present, or if their only connections aren't to the DFZ at present.  back
in the day, i made decent money as a contractor, building 192.9.200 and/or
192.9.201 (sun's networks, used in sun's documentation) everywhere, and then
later i made indecent money renumbering these networks as they got connected.
we ought, if possible, to avoid making *another* market for those services.

> Here is my wish-list of what I want/need out of an address policy for ipv6:
> 
> 1) Globally unique addresses
> 2) Relatively small number of them
>    (for ipv4, a /24 is plenty.  I don't know for ipv6; I haven't messed
>    around with it yet, one of the obstacles is knowing what addresses to
>    use. :-)
> 3) Relatively cheap
> 4) Permanent

see below.  you're doing great though.

> 5) Low-maintenance
>    (I would be making few if any changes, seldom if ever requesting
>    more space, etc., so registry overhead should be very low.)
> 6) Global routing is not needed.
>    (I would be using these addresses locally or over private networks
>    where the manual one-time effort of setting up routes, firewall
>    filters, etc. would be fine.)

regarding (4), nothing is permanent.  the pre-RIR legacy allocations for
which no contracts exist and many contact information is lost or stale, are
an extraordinary and untenable burden on the internet system, for a lot of
different reasons.  all new allocations are governed and essentially
ephemeral -- and one of the reasons for this is so that if a company goes
out of existence and stops paying its annual nuisance fee to the RIR, then
the address space they were using automatically goes back into the pool.  no
policy for allocation can afford to leave out this essential element, even
if we somehow approve a policy for special allocations for unconnected or
not-part-of-DFZ networks.

as for (5), there is no basis for suggesting that address space allocated
under an "unconnected" policy would need less maintainance than address
space allocated otherwise.  whois and in-addr are either up to date or not;
companies change their addresses or hire new personnel or are merge/acquired
or not; etc.

but as for (6), it's "the rub".  you don't know at the time you create a
network what it might eventually want to be connected to.  perhaps you'll
connect it to your local community wireless network through an IXP or through
kc's COMMONS.  it still wouldn't have a default route and it still would not
be part of the DFZ, but it would no longer be "unconnected".  there just isn't
a workable definition of "global" or "global routing" that will sit still long
enough for us to write policy about it -- and if there were, we'd merely have
earned the opportunity to renumber our "partially connected" networks on the
day when they finally do connect to the DFZ.

> The way I see it, ULA-C has been proposed as a solution to most of
> these items.  To summarize the arguments for and against it,
> 
> F1) It would be cheaper/easier to administer than PI.
> (Some dispute this, saying it would be just as much work for ARIN.)
> 
> F2) It would be easy to filter at the edge routers, since it would
> all be in a single address block.  (But you would have to be able
> to turn this off if you wanted to use said router within a ULA-C
> network instead of at the edge of one.)
> 
> F3) It could be distributed in smaller chunks than PI.  (But PI
> could also be distributed in smaller chunks, too.  This is just a
> matter of Policy.  But then backbone people don't want to route the
> smaller chunks since too many of them would swamp their routers' 
> routing tables, but then again, there is no intention of globally
> routing ULA-C packets, so the addresses shouldn't end up in the
> routing tables in the first place.)
> 
> The arguments against seem to be:
> 
> A1) It doesn't do anything PI doesn't already do.
>    (See arguments for...)
> 
> A2) Someday you might want to route the ULA-C addresses, so you'll
>    either have to renumber to PI or convince the world to disable
>    the ULA-C filters mentioned in argument F2.  Might just as well
>    start with PI and avoid all this.
> 
> Did I miss anything?

yes, two things.  in (F2) you're presuming that everyone connected to the
DFZ will want to filter this stuff.  some networks have a promiscuous
peering policy and would be happy to hear these routes.  you're also
assuming that the intent of the network owners will be "unconnection",
whereas i believe that through confusion or malice, many network owners
could end up trying very hard to connect these allocated-as-"local"
networks.  the combination of these two factors spells doom for (F2).

and i think you're missing (A3) which is that IPv6 transforms a balanced
shortage, where we run out of DVRP capacity and address space at roughly
the same time and we just have to argue "minimum allocation size" in order
to ensure that we run out of both at the same time, into an unbalanced
shortage where we'll hit and remain at the DVRP wall for the lifetime of
the system even though vast tracts of address space remain unallocated.
so there isn't a digital-economy basis for smaller/cheaper allocations
meant for "unconnected" networks.  (but there does seem to be one for
small-PI, which many DFZ operators would just filter from day 1, if we
allocate them with a consistent enough prefix.)