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

Stephen Sprunk stephen at sprunk.org
Fri Nov 19 16:38:36 UTC 2004


Thus spake "Owen DeLong" <owen at delong.com>
> > It appears Iljitsch would have been correct to say "there is no _new_ PI
> > in IPv6 unless you're an internet exchange or a root server."  As long 
> > as
> > this remains true, there are nearly a dozen identified reasons why 
> > people
> > would want/need ULAs, which was the original point of this subthread.
>
> The point of the thread, in my opinion, is that changing the RIR policy
> to support the needs met by ULA makes more sense than creating a
> separate registry system and defining multiple address classes which
> are theoretically routable and unroutable.  Especially when we consider
> that the definition of unroutable is very fuzzy at best.

Having every BGP peer require manual configuration to allow propogation each 
ULA prefix makes global routability darn near impossible.  Unfortunately the 
wording on preventing global use was weakened significantly when "restraint 
of trade" fears came up.

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.

> > The RIRs, of course, are free to make IPv6 PI space available, and most
> > of the justification for ULAs would disappear if that were to occur.
> > However, there is no indication that this is coming, so absent any other
> > ways to meet those needs, ULAs have a purpose.
>
> 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.

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.

Are there objections to local ULAs as proposed, or is all this debate 
focused only on central ULAs?

> ARINs members do _NOT_ approve policy.  The BOT approves policy.  The
> BOT only approves policy after it is recommended by the AC.  The AC is
> not made up of ARIN members, and, is not elected by ARIN members.  They
> are elected by the ARIN community at large.  Basically, ANYONE can vote.
> The AC recommends policy to the BOT based on consensus and discussion
> on the PPML and at the ARIN Public Policy meetings (twice a year).  While
> it is true that a majority of the people who show up are ISPs, there is no
> price of admission for joining and participating in the PPML, and, the
> registration fee for the meetings is quite nominal.

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.

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

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.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




More information about the NANOG mailing list