farmer at umn.edu
Wed Apr 7 00:43:09 EDT 2010
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
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
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
So, is some kind of compromise between the opposing camps possible?
Otherwise, I fear this is going to continue to be a pointless shouting
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
More information about the ARIN-PPML