[arin-ppml] IPv6 Non-connected networks

[David Farmer]

David Farmer wrote:
> michael.dillon at bt.com wrote:
>>> I have always liked 6to4 addressing.  If you have some IPv4, you have 
>>> plentiful amount of IPv6.  But there was no reverse DNS... Well, it 
>>> seems that http://6to4.nro.net now lets you populate it...
>>
>> Bingo!
>>
>> There is the model for doing reverse DNS for ULA-C. And also
>> for the directory of ULA-C registrations which would be at
>> http://ula.nro.net. That page would explain what ULA is,
>> provide a calculator for generating a ULA-RANDOM address,
>> direct people to the 5 RIR web pages for registering ULA-C
>> addresses, provide a ULA-C directory lookup button, and
>> provide a link for enabling reverse DNS for your ULA-C block.
>> People would then have a choice of whether or not to have
>> reverse DNS or to have it delegated to the same phantom IANA
>> server that handles RFC 1918 reverse DNS.
> 
> No way, go read RFC 5158, that defines this.  It requires you to connect 
> to that web site from the 6to4 address range you want to register, this 
> is what I call implied authorization.  How would this kind of implied 
> authorization for an address range that is NOT suppose to be globally 
> routed?
> 
> Also, if you read the RFC this implied authorization solution has a 
> number of pitfalls that would make it undesirable for enterprise use. It 
> is only acceptable for 6to4 because 6to4 itself is considered a 
> transition mechanism.  In other words the problem goes away when you 
> implement native IPv6.
> 
> But if you can find a way to make it work, I'm happy to reconsider.  I 
> just do see how it would work and provide an enterprise class solution.

WAIT!!! I got hung up on the implied authorization thing.  But, now I 
realize that is not what you were thinking about.

Your right BINGO!

A ula.nro.net type mechanism is the way to coordinate the creation of 
the random prefixes.  How about something like this.

1. Registrant generates a prefix on ula.nro.net, the tool can generate 
regular ULA or registered ULA.  For registered ULA the tool puts the 
prefix into a "pending" state in a database, and creates a ticket that 
can be registered with an RIR.  If the state isn't progressed in some 
timeout say a week then the prefix is returned to the pool.

2. The Registrant contacts the appropriate RIR, the RIR takes the ticket 
generated in step 1 and moves the state to "Pending-RIR". The RIR 
processes and validates the registration.  If the RIR refuses the 
registration or it is dropped, the RIR returns the prefix to the pool.

3. Once the registration is completed, the state is changed to 
"Registered", and the database points at the RIR for Whois and reverse 
DNS so that maybe managed via the RIR's tools from this point on.

4. The RIR follows its policies and procedures for the life of the 
registration.

5. Once the RIR determines the registration is no longer valid 
(including any hold time) the RIR returns the prefix to the pool.

Other than a few worries related to sparse database problems I think it 
could work.



-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================