ULA and RIR cost-recovery

Owen DeLong owen at delong.com
Thu Nov 25 00:21:41 UTC 2004


>> 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041124/a227bdbf/attachment.sig>


More information about the NANOG mailing list