who gets a /32 [Re: IPV6 renumbering painless?]

Fri Nov 19 18:23:05 UTC 2004

> I do think, at a high level, that having a registry for non-routable
> addresses makes sense iff those addresses could be kept that way.  There
> is no reason for RIRs to allocate addresses which would never be used on
> public networks.
>
If the addresses are suppose to be unique, then, what is the reason NOT to
have the RIRs allocate them?  Why set up a separate registry system for
these addresses instead of making minor changes to the existing one to
accommodate this need?  There is no reason to invent the square wheel
manufacturing plant when we have a perfectly good round-wheel plant which
can be easily retooled for a fraction of the cost.

>> Yes... Undermining the policy process of the RIRs.  Other than that, they
>> have no purpose.
>
> As an argument against centrally-assigned ULAs, they certainly do
> undermine the RIRs.  If the various RIRs provided a viable PI allocation
> model, then that half of the proposal would largely be moot.  However,
> undermining the RIRs was not the purpose, just the most expedient method
> of meeting the stated needs.
>
Well... Expediency often has long-term costs associated with it which are
much higher than the short term costs of addressing the issue directly.
I believe this is one of those situations.

> Locally-generated ULAs meet a need, like RFC 1918, that the RIRs will
> never (and probably should never) meet -- cost-free and paperwork-free
> addresses. Local ULAs also have the benefit that it's easy to explain to
> customers why ISPs won't route them, which has been cited as a problem
> with central ULAs.
>
But locally-generated ULAs aren't ULAs, they're NLAs, so, what's the point
of creating this giant address space for people to allocate from
willy-nilly.  If you want to define an RFC-1918 style /32 everyone can
play in, go for it.  You'll have all the same problems and solutions
of RFC-1918.  If you want to avoid such collisions as have been the problem
with RFC-1918, then, you need an address registry, and, let's just accept
that this isn't a bad thing any more in IPv6 and get the RIRs allocating
such space in a reasonable fashion.  I'm perfectly willing to have the
RIRs delegate this space from a separate IPv6 block for that purpose, and,
the RIRs are capable of doing this.  They're already doing it for IPv4
based on 2002-3 and 2003-15.

> Are there objections to local ULAs as proposed, or is all this debate
> focused only on central ULAs?
>
Yes.  They simply don't make sense as stated above.  They are an attempt
to pretend we are solving the problems with RFC-1918 while still preserving
most of the problems of RFC-1918 in order to get exactly the same benefit,
but, use a much bigger chunk of address space in the process.

> Thanks for the reminder on how ARIN works; since I'm not a member, I
> haven't looked at the process details since ARIN was first formed.
>
I'm not an ARIN member either, but, I am an active participant.

>> Decisions are made by those who participate.  If you want input into
>> the ARIN policies, then, participate in the policy process.  If you thing
>> it's someone elses job to make ARIN policy, then, accept the job they
>> are doing, or, contribute.
>
> Or simply route around the failure via the IETF/IANA, which is what the
> drafts' authors did.  That method has the advantage of not needing to be
> redone for each of the RIRs, but obviously has other disadvantages.
>
Hmmm... Then perhaps I should solicit the other people I know who don't
like the recent actions of our government and we should route around the
damage of the united States Congress?  Yes, I'd say it has other rather
obvious disadvantages.

> At the personal request of an AC member, I will be requesting suggestions
> on PPML for IPv6 PI space requirements and then submitting a policy
> proposal. We will see what happens after that.
>
Good... Welcome to the process.  Pitchforks and Torches are not required.
I think you will find that the ARIN staff is helpful and the AC is very
interested in developing policies that meet the needs of the community.
I can honestly say that while I don't always agree with everyone on the
ARIN BOT or AC, I do believe that each and every one of them is a good
person with their heart in the right place and the best of intentions.

FWIW, I will strongly support any proposal to make it easier for 
organizations
to get rational IPv6 allocations of PI space.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- 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/20041119/a316dde4/attachment.sig>