[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

Wouldn't it be easier just to have IANA assign /14s or whatever of ULA- 
C to the RIRs?

Owen

On Mar 26, 2010, at 7:39 AM, David Farmer wrote:

> 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
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.