[arin-ppml] ULA-C

[David Farmer]

First, I want to apologies to everyone, I'm starting to believe I've 
been wasting all of your time on this. I thought we could find a 
consensus allowing the implementation of ULA-C while providing assurance 
to those worried about ULA-C becoming a policy abuse path.  Somehow I 
even convinced myself there was the start of a consensus developing in 
the past couple weeks.

Today it has become clear to me that I was deluding myself, and I'm 
starting to think the whole thing was a futile effort.  There seems to 
be two diametrically opposed camps, neither of which are willing to 
budge out of their entrenched positions.

So, I will make one final appeal for both sides to find a way to 
compromise. Without both groups being willing to compromises, I fear all 
that is going to happen is a continued shouting match.

I believe a globally defined prefix for non-routed addressing, that has 
both registered uniqueness and reverse DNS, A.K.A ULA-C, would be of 
value to both the enterprise and services provider worlds.

1. With a single global well-known prefix, Service providers and other 
globally reachable Internet (DFZ) network operators could easily filter 
this prefix and the associated packets, without an excessive burden on 
their operations.

2. If packets or routes leak inappropriately, then tracking down the 
source, if necessary, becomes much easier.  As the assignment is 
registered to an organization with contact information. This is not 
currently possible with RFC 1918 or RFC 4193.

3. Providing these assignments from a single global well-known prefix 
helps ensure these assignments are not misappropriated or hijacked, this 
helps protect both service providers and enterprise that received the 
assignment. This is not possible with an unannounced PI assignment, 
maybe with RPKI in the future, but not as things stand today.

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.

5. ULA-C with at least an option for authoritative reverse DNS, provides 
other options than just split DNS for enterprise internal naming.  Also, 
  Internet based VPNs can create many DNS challenges.  Leaking forward 
and reverse DNS lookups for RFC 1918 and RFC 4193 addresses are a 
nuisance for both service providers and enterprises alike.

6. ULA-C, currently proposed as FC00::/8, is a much more limited 
resource than GUA 2000::/3, and since resource are being globally 
dedicated to individual organizations, some mechanism to ensure the 
long-term stewardship of those resource is necessary. The RIRs seem well 
suited to provide the necessary stewardship, as they already do this at 
a global scale for many other number resources, why build something new. 


7. ULA-C, even with a global well-known prefix, is just another 128bit 
integer, there is nothing fundamentally different about it, than PA or 
PI.  In fact, with registered uniqueness, reverse DNS, and maybe even 
RPKI in the future, the only practical difference between ULA-C and PI 
is the non-routed property, applied realistically only by convention. 
There is one possible other difference, random prefix selection.  While 
this could help prevent some kinds of abuse, I'm not sure this would 
provide much practical deterrence in using ULA-C as a substitute for PI. 
  Which I believe is the primary abuse path of concern.

Therefore, I believe the concerns about ULA-C becoming a path for policy 
abuse cannot be completely discounted.  However, in reality the risk is 
no where near as large as some are claiming.  Further, I believe this 
risk can be easily managed via the RIRs' number resource policy 
processes, if the RIRs were to be given full policy control of ULA-C 
registrations.

I believe the crux of the issues are these last two points (#6 & #7). 
Some members of the community seem to want ULA-C to bypass the 
stewardship and policy control of the RIRs, to justify a low cost for an 
assignment of ULA-C.  And, some others seem to be over blowing the risk 
of abuse that ULA-C represents and seem to claim there is no way to 
manage that risk.

I believe, the stewardship the RIRs provide is necessary, and the RIRs' 
policy processes can properly manage the risk.  As for cost, while not a 
policy matter, in the shorter-term ULA-C is not going to be as cost 
effective as some would hope.  However, if in the longer-term the risks 
can be managed, then I have to believe that the RIRs will do the right 
thing.

So, is some kind of compromise between the opposing camps possible? 
Otherwise, I fear this is going to continue to be a pointless shouting 
match.

Finally, I want to be clear the opinions I have expressed in this whole 
set of threads have been my personal opinion.  The AC has not reached 
any consensus on these issues.  And, without compromise from both camps 
as noted, I honestly don't see the AC coming to any consensus either.

-- 
===============================================
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
===============================================