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.