[ppml] [address-policy-wg] Those pesky ULAs again

[Paul Vixie]

> > Should ULA-C be published in the Whois database? what about reverse DNS
> > for them, should they be delegated or just reply a NXDOMAIN?
> 
> let's see.  ula-c should be assigned and tracked by rirs.  they should
> have whois and in-addr.arpa.  do remind me how they differ from pi
> space.  i keep forgetting.

while i'm uncomfortable with randy's tone here, i agree with his concern.
the difference between pi and ula has been given as "not intended to be
routed in the DFZ".  this means a pi prefix can be routed privately, as
for example among cooperating BGP peers at an IX, or between companies
involved in private relationships such as banking or manufacturing, and
of course, it will mean that "merge/acquire" no longer implies "renumber
the RFC1918's on one or both sides".

but since we could never possibly fit all of ipv6 into the DFZ, and since
the cost and availability of pi is theoretically manageable by us (the RIR
system) to make sure everybody who needs it can get and can afford it, i
fail to see the virtue of making some of it cheaper and worth less.

this whole argument has helped me understand that there is a policy hole
but that "unroutable" isn't it.  if the RIR system had multiple high order
prefixes (IPv6 /10's or whatever) to allocate from, with a minimum length
policy that varied, then global static route-ingress filters could be set
that would outlaw TE routes, which are the major source of DFZ bloat, way
over the top compared to SMB PI routes.

i think i oppose ula simply because there's no way to define "local" in a
way that will serve a network's needs throughout its probable life cycle,
except in the case where RFC1918 (or IPv6 "site local") would have served.