...

Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications.

ULAs are clearly routable over whatever scope people decide to. This was also true of the SiteLocal prefix that ULAs are replacing. The only difference is that ULAs have explicit text to avoid routing ambiguity where SL didn't. I argued against deprecating SL partly on the basis that it had the potential for ambiguity which would be a disincentive for grey-market PI use. I understand and agree with your point about them being a potential problem, but that potential is easily mitigated by providing an economically viable alternative.

I was also opposed to deprecating SL on the same basis. However, just because SL was deprecated doesn't make me think ULA is a good idea. If we're going to have PI space, we should have PI space. Dividing it up into multiple classes based on how much you paid to register it doesn't make sense to me.

None of the organizations that are getting long IPv4 allocations will qualify for an IPv6 prefix. There is an implicit concession that it is too late to close the barn door for IPv4, but for IPv6 it is currently locked tight by those that want to maintain control.

I don't believe that to be true. I think that a reasonable allocation policy for PI space in v6 would move forward in ARIN. I think that the recent adoption of 2002-3 and 2003-15 is evidence that the makeup and participation in ARIN has shifted. I also think that you underestimate the number of people who believe that PI space should be the norm, not the exception, and, that failure of v6 WG to address this in a meaningful way is not a good thing for v6 future.

Multi-homing is only one reason for PI space, and people get so hung up on that one that they forget that the simple ability to change providers without massive effort is just as important.

Changing providers without massive effort can be accomplished through a number of other methods. Multihoming is the more generic case.

Failure is too strong a term, but it is true that work is not complete. The issue is many assumptions have been made at all layers of the system about the alignment of all those characteristics, so just ripping them out doesn't really solve anything more than the routing problem. Even if the multi6 follow-on groups come up with a technical approach that splits the functions, all the rest of the infrastructure will need to adapt and that will take much longer than rolling out IPv6.

I do not believe that the v6 protocol will ever actually address those issues. Most of the necessary foundation for addressing them has been removed (A6, DNAME, mandatory autoconf). Agreed on the latter half, that's why I think that IPv6 should have addressed these early on and built those capabilities into the migration process. Adding them as hacks later has most of the disadvantages and reasons that they haven't been added to v4. That is why I chose the term failure.

Making a change that intentionally breaks fundamental assumptions will meet much greater deployment resistance than something that intentionally minimized such changes. Call the intentional minimization a failure if you must, but from my perspective the only real failure will be to let the Internet collapse into something less capable of delivering end user services than X.25 was.

Here, we probably end up agreeing to disagree. I think that we could have built v6 to break the fundamental assumptions in such a way that the impact of those breaks was minimized. Yes, there would be deployment resistance, but, I don't think significantly more than exists for current v6. Owen