[arin-ppml] ULA-C

[Eliot Lear]

  David,

Thank you for that summary.  This has been an interesting discussion.

My own reading of the "room" is that people have come to understand that 
if you assign a price of 0 to something that has value without any 
bounds on acquisition of that resource, someone somewhere will arbitrage 
the difference.  The way the community has attempted to prevent that is 
through restrictions on "ownership", including a needs assessment and a 
limitation on transfers.  It would seem prudent to maintain the same 
sorts of restrictions for ULA-C that we have for any other IP address as 
you wrote, particularly if reverse DNS is offered.  At that point, even 
more so than you wrote, the difference between PI and ULA-C is strictly 
a matter of service provider policy, and nothing more, with even fewer 
externalities than that of RFC 1918 addresses .  Indeed under those 
circumstances, a single service provider could offer VPN services using 
ULA-C without MPLS, although let us agree that the edge configuration 
might be a bit more "interesting".

This leads to my own ultimate question: why doesn't Section 6.5.8 cover 
interior needs sufficiently?  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.  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.  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.

Regards,

Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100412/774bf895/attachment.htm>