And v6 without PI for will not get widespread adoption.
Further, ULA will become de facto PI without aggregation. Hence my believe that ULA is a bad idea, and, my recommendation that we face the reality that PI is an important thing (unless we want to replicate the v4 NAT mess). As such, I'd much rather see us develop sane PI policy than continue down the present road.
So what would be a sane PI policy? Apparently you don't want ULAs becoming de facto PI without aggregation, so do you agree that we need aggregation for PI?
I agree that under current technology, if we are to use those addresses as both the endpoint identifier _AND_ the routing destination, there is some need for aggregation as a basic practicality of router memory and ASIC limitations. I think the mistake was in not recognizing (and doing something about) the need to address the need to separate end-point identifier from routing information early on in the IPNG process. I don't have a solid answer on how to cope with providing what is needed in terms of portable end-point identifiers. I think at least having some way of assigning/allocating them on a renewable (and, thus, reclaimable) basis is important. I think considering geographic allocation and hoping that line up well enough with topological aggregation may be desirable. Unfortunately, in today's cooperative/competitive internet, we can't expect are even really ask that provider A and provider B both accept packets for each other across certain links and forward them. Perhaps some form of mandatory settlement transit is what is needed to make this feasible (much like the current telephone system). I don't pretend to have all the answers. However, that does not change the fact that I think the IETF lost sight of the problem in this instance. ULA is an end-run on v6 registration by the RIRs and creates virtually uncontrolled PI space. I agree that PI space is needed by a variety of organizations for a variety of reasons and should not be limited to ISPs and very large organizations. Again, I think the key to being able to really implement this is that what is needed is portable end-point identifiers which can be used at least as reliably as current IP addresses for ACLs, Tunnel End-Point identifiers, etc. I think there needs to be a separation between the End-Point identifier and the routing so that routing can be aggregated. I think v6 has no provision to address this. Owen -- If it wasn't crypto-signed, it probably didn't come from me.