[arin-ppml] ULA-C

[Eliot Lear]

  David,

> Further, until we can develop a consensus for how ULA-C should work, 
> who should provide the registry services for it, and under what kind 
> of terms, coming up with an ARIN policy for making ULA-C assignments, 
> through 6.5.8 or what ever final process seems premature.

My point was that absent additional information (see below), ARIN is 
already there for PI.

>
>> And this goes to your point (4), which I quote:
>>
>>> 4. The availability of ULA-C for internal addressing will likely 
>>> make PA addressing facing the Internet more palatable at least for 
>>> some classes of enterprise users.  This might be implemented with 
>>> NAT66, multiple RAs, or any number of possible future solutions.  
>>> Like maybe some variation of LISP, or some other GSE type 
>>> solutions.  But, the details are irrelevant that is an operational 
>>> issue not a policy one. 
>>
>> Of the arguments in your message, it would seem to me that this one, 
>> combined with whatever security argument one would be the ones that 
>> should be further developed. 
>
> Do you have suggestion how to further develop this argument?

I wrote the above because I don't understand how (4) is a driver, and so 
I presume others don't either.

>
>> In addition, given that ARIN and the RIRs have demonstrated 
>> reasonable flexibility in terms of making changes to policies, one 
>> could reasonably ask the question as to whether this proposal is well 
>> timed. 
>
> Could you clarify what you mean here, are you suggesting this should 
> wait?  If so, to an extent I agree, we realistically can't take this 
> up until the Fall ARIN meeting, is that still to soon? However, as I 
> discuss in my response to Chris, this issue is at least partially 
> entwined in a couple policies that will be discussed next week in 
> Toronto.

I'll put it another way: is there substantial customer demand for a 
service such as ULA-C?  I don't see it.  Until such time as others see 
it, why would we execute so soon?  With regard to NCNs, I can see them 
being related; but again, the policy process is pretty flexible.  In as 
much as demand is there, I would let that be the determining factor for 
timing, so long as we don't make decisions that would foreclose options 
or do not properly steward the space.  Do you see that happening here?
>
>> The introduction of NAT66 into the discussion is one that would need 
>> to be carefully considered, and LISP and ILNP (GSE's successor) are 
>> still nascent technologies.
>
> Are the considerations with regard to NAT66 and ILNP different for 
> ULA-C than for ULA-L (RFC 4193)?

Only modestly so.  Were I an SP, I probably would probably be more 
reticent to route RFC 4193 addresses, given the eventuality that a 
collision will occur in those cases.  That means that NAT66 is actually 
more of an interest for ULA-L.  If I'm an enterprise, once I'm spending 
money for addresses, I might as well get something that offers me the 
most flexibility from a routing perspective.  That might as well be PI.  
The same argument applies to ILNP/LISP.

Eliot