RE: ULA and RIR cost-recovery

Well... I'm saying, at least, that I'd rather change the RIR policy and
in an open and consistent manner based on input from the operational
community and other stakeholders than have the IETF start setting
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.
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

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.