[arin-ppml] ULA-C

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


David, I want to thank you for the summary.
I have waited a few days to see the responses, before contributing.

You make 7 points.  It seems that the thread has gone astray again.
Your first 4 points address the issue of leakage, and why a unique
prefix is better than having NCN randomly in the PI space, yet there is
a long thread that misses those points completely.

I believe that point #4 is very important, so I repeat it:
  > 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. 

I think it's important to remember how IPv4 came to occur.  FIRST,
Enterprises deployed it.  They did it because having IP services were
useful.  They did so without any expectation that they would "connect"
to the Internet --- they were already connected to themselves.
(Who remembers when Apple had to renumber?)

Responders to your email have not clearly said, "I disagree with point
1", yet they continue to argue it.  

I am glad that you understand point #5 -- about DNS and VPNs.
(Those who know what IETF work I've done, realize that most of my work
in the 2000s has been at intersection of DNS and IPsec...)

Contraversal points you list are #6 and #7. 

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

I completely agree.   I want the RIRs to do this. 


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

I put no value on the randomness, but I do not object to it, but that's
not the crux of your point. (Scanning the lower /64 bits is sufficient
randomness for me)

RPKI) I don't see why RPKI certificates would be issued for ULA-C space.
      If they were, it would be for completeness, and would specify a
      non-existant/reserved/invalid ASN.  This itself would provide an
      additional hurdle against leakage.
      
      If RPKI was legitimately issued, it would be issued, in my
      opinion, from a different CA. Most likely anyone that needed RPKI
      for their ULA-C would be running their own CA.  My opinion (as a
      security geek), is that running your own CA exceeds the cost of
      getting PI space!!


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

I agree --- there could be abuse.
Rather than overconstrain ourselves in advance, is there nothing we can
do on a complaint basis?

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

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

I can deal with these statements. They *do* represent a compromise to
me.

Michael Dillon?
Bill Herrin?

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8MVMoCLcPvd0N1lAQIjrwgAkUXbUxipqkSeKumCoRmF0tM94La4RJfB
Qdjj8nnuIaSxeAU9CHQBUobX6HB6nHTzpXjqrgPIuT9vd6LUbF2MEHn8ZfJDlceu
5+Cv89FEn9khtAKpQKnPrwA67nhAM/ukY/3XWTwlCJ052vK74dtTTsMk5RhT/5G2
oE1Zgvi6PG7snL2aAWlMZ5dgP2zcG7WEbqy+F2toVlRwIRxbid8eIj02VXKWNwZw
GVew5t3rPfbqdUM2Othf3XDdfik8z/2GajnQnSoz+WCwFzENvSPiT0HIpoVq4Kmo
UHwn1WG04n22ur4NVRBinRQv9PBQorrIN5nWdR1SXnImYPVQ6Psntw==
=fsXT
-----END PGP SIGNATURE-----