[arin-ppml] IPv6 Non-connected networks

[michael.dillon at bt.com]

> If we assume the RIRs would be handling ULA-C, then I have a 
> question about the third paragraph in section 3.2. Global ID. 
> It states;
> 
>     The allocation and registration authority should permit 
> allocations
>     to be obtained without having any sort of Internet 
> connectivity and
>     must include the ability to make an allocation on a 
> permanent basis,
>     without any need for renewal.  The registration authority 
> may covers
>     its costs through registration fees and may also use registration
>     agreements to clearly set forth the terms conditions and 
> liabilities
>     associated with registration of such allocations.  The 
> payments and
>     conditions associated with this function should not be 
> unreasonably
>     onerous to the extent that the availability of allocations is
>     impaired.
> 
> Do you believe it would be consistent with this paragraph, if 
> ARIN were to follow business practices for ULA-C similar to 
> those used currently for an end-user assignments, charging a 
> one-time fee covering its cost for the assignment activity 
> and then an annual fee for maintaining a Organizational ID?

I think that we should go ahead with allocating a /8 for ULA-C 
addresses without any significant technical changes to this
Internet draft
<http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-02>

However, there could be some changes to clarify who does what,
etc.

I believe that the ULA-C registry should be based around a 
tool similar to the one operated by SIXXS for the regular
ULA addresses. This tool should be hosted by more than 
one RIR, perhaps since RIPE and ARIN are the senior RIRs
then they should both host the tool. It would have to be
based on a distributed datastore, but with all the recent
developments in the NoSQL field, this should be simply a
matter of picking the right db software and implementing it.

Essentially, the tool just generates a pseudo-random 
/48 block, checks to make sure it is not already in the
database, and if so, tries again until it gets a free one.
The /48 is then registered with the customer and RIR info
that was entered.

Procedurally, each RIR would have a login to this allocation
tool, and after signing a customer agreement and collecting
payment for the service, they would enter all the info into
the tool, a /48 would pop out, and they would record that
number and pass it on to the customer. A customer can ask
for as many /48s as they want, but they pay each time and
NO DISCOUNTING IS ALLOWED. Full price only except for the
very first allocation to customers in an RIR that has implemented
a special price category. This allows RIRs to service customers
in economically depressed areas in a reasonable way.

As for whois, none of these numbers would be recorded in
the RIR whois directories. However, each RIR should operate
an instance of the ULA-C directory lookup tool which will
query single /48 blocks from the allocation tool's database.
This should not pose any serious problems to anyone, since the
entire ULA-C block will be listed in bogon lists. The only
time you should see someone else's ULA-C block on your network
is when you have a direct business partnership and a direct
connection to the other organization.

Potentially, ULA-C blocks could seem useful to COIN (Community
Of INterest) internetworks, but in practice the costs would
be higher than necessary, and the impossiblility of prefix
aggregation only causes operational problems. I expect that
a COIN will simply register a /32 and assign from that much
like any other ISP. However, it is quite possible that a small
scale COIN will simply require all members to use a ULA-C block
because a small COIN is pretty much the same scale as a two-party
private extranet connection. And a two-party private extranet
is identical, from a technology viewpoint, to an M&A scenario
where two organizations begin to merge their networks.

I would encourage ARIN and RIPE folks to work on a global policy
for ULA-C that assumes IETF approval of a ULA-C RFC. Then, 
once we have the global policy, I believe that the IETF will
approve a ULA-C RFC that creates ULA-C addresses.

--Michael Dillon