[ppml] Proposed Policy: PI assignments for V6 (and v6 fees)

Howard, W. Lee L.Howard at stanleyassociates.com
Mon Dec 6 14:01:09 EST 2004



> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Monday, December 06, 2004 1:01 PM
> To: Howard, W. Lee; ARIN Policy
> Subject: Re: [ppml] Proposed Policy: PI assignments for V6 
> (and v6 fees)
> 
> 
> Thus spake "Howard, W. Lee" <L.Howard at stanleyassociates.com>
> >> Should we include any way for disconnected sites (which 
> many not have 
> >> an
> >> ASN) to get PI space?  The IPv4 policy directs such sites 
> to use RFC 
> >> 1918 space, but there is no equivalent (yet) in IPv6.
> >
> > If a site isn't connected, why would PI space be necessary? RFC1918 
> > made it so that private organizations who interconnected 
> would always 
> > have overlapping assignments.  Maybe there's a Better Practice 
> > available for IPv6, to reduce the likelihood of conflict (by 
> > increasing randomization).
> 
> IPv6 Site-Local Addresses, the analog of RFC 1918, were 
> deprecated because 
> ambiguous addresses were considered technically flawed.  The 
> IPv6 WG has 
> proposed Unique Local Addresses which use a 40-bit random 
> field in the 
> prefix to reduce or eliminate (depending on the class) the chance of 
> ambiguity.
> 
> ULAs are intended to be used for internal-only communication 
> (possibly 
> layered on top of PA addresses), private connections between 
> companies, and 
> any other purpose that needs uniqueness but not global 
> routability.  While 
> ULAs appear to have consensus, a few vocal objectors wanted 

When discussed at ARIN fora, there seemed to be consensus against.

> to see if the 
> RIRs would change their policies to provide PI space for 
> these needs before 
> letting us proceed with ULAs.

Can you describe the difference between uniqueness and routability?
If it is unique, it could be routed.  It might not be routed, but
it is route-able.

> 
> > It was the consensus of the public when creating IPv6
> > policy to enforce provider-based aggregation.  As I recall, 
> this was 
> > the proposal that came from the IETF, and was ratified by 
> all of the 
> > RIRs through their policy processes.
> >
> > The primary obstacle to deploying IPv6, therefore, would
> > be a dearth of IPv6 ISPs who can make assignments.  The
> > root cause, which can be inferred from your statement, is 
> that there's 
> > no demand for the next generation service, since the current 
> > generation will last for the forseeable future.
> 
> OTOH, it's been asserted by many folks, including myself, that even 
> end-sites that wish to deploy IPv6 will not do so if they are 
> locked into 
> provider-based addresses for their internal communications.

Bummer.

 
> Multihoming in particular is not feasible with the existing 
> scheme, and some 

Multihoming is not feasible because address space is aggregated?
In IPv4, BGP4 speakers can announce more-specifics of PA space
and be multihomed.  This isn't possible with IPv6?

> believe that this will lead to organizations using ULAs 
> internally and 
> NATing at their borders into PA space.  

I can't figure out why NAT would even be required if a site has
a globally unique prefix.

> Since NAT is 
> generally considered evil 

I've heard that, but never completely understood why it is evil.
>From what I can tell, the most insidious thing about NAT is that
it makes IPv6 far far less urgent.

> and was supposed to be unnecessary in IPv6, the only 
> solution is to 
> create allow IPv6 PI assignments.

I am not convinced that there is consensus around these
assumptions:
- ULA is desirable
- NAT is evil
- multihoming in PA space is impossible
- renumbering is hard (is this an assumption of yours?)
 
> I'll note that this proposal was solicited by an active AC 
> member, and 
> several other ARIN-related folks seem to agree -- at least 
> until the Multi6 
> WG comes up with something better (years if not decades away).

Don't take this personally.  Although it may seem like it, I'm
not actually taking a position, I'm trying to clarify several
points about this proposal, the need for it, and the ramifications.


> >> In another forum it was claimed that ARIN charged ISPs
> >
> > What forum?  I should join.
> 
> NANOG

Yes, I've been away too long.

 
> > There has been constant fee-tweakage by the Board.  The current 
> > combination of fees and waivers is such that an IPv4 
> subscriber pays 
> > only maintenance fees on their IPv6 allocation. You have to 
> read the 
> > Board minutes to keep up, since the Fee Schedule page is 
> out of date.
> 
> Argh.  These kinds of things really need to be kept current.

It turns out that the meeting minutes were posted mere moments before
I went looking for them, so the web site was less than an hour out of
date.  Sorry for tweaking the staff on that.

> 
> > Start with:  
> http://www.arin.net/library/minutes/bot/bot2004_1020.html
> > "The ARIN Board of Trustees sets the fees for IPv6 allocations as 
> > follows:
> >
> > XS/Micro /48 $1,250
> ...
> > This fee structure is effective January 1, 2005."
> 
> Okay, that's what I'd have expected anyways.
> 
> > See also http://www.arin.net/library/minutes/bot/bot2004_1109.html
> > "The ARIN Board of Trustees extends the current waiver of all IPv6 
> > fees to all members in good standing for the period of 
> January 1, 2005 
> > until December 31, 2006. This waiver is not extended to any 
> > outstanding IPv6 related fees that were regularly invoiced in 2004."
> >
> > Thus, if you are a subscriber member (already pay for 
> allocations) or 
> > an individual member ($500, see 
> > http://www.arin.net/registration/fee_schedule_new.html#annual ) you 
> > will have two years of fees waived.  This seemed like a good 
> > compromise based on feedback during the public policy and members 
> > meetings.
> 
> Glad to hear it.
> 
> >> ARIN's "usual and customary way" has already set the fees for 
> >> end-user direct assignments to be the same as for ISP allocations, 
> >> per section 12(D) of the 3 Aug 04 BoT meeting.
> >>
> >> At these fee levels, I must question the viability of direct PI 
> >> assignments as a replacement for many or even most potential ULA 
> >> uses, which I understand to be a central motivation for 
> this policy 
> >> proposal.  Of course, this policy is still warranted for "normal" 
> >> uses of PI space in IPv6.
> >
> > Arguably, you could put this proposal together with the 
> newly adopted 
> > fee schedule and waiver and say that there's a two-year 
> trial period; 
> > after two years, end-user sites will have to decide whether to pay 
> > $2,250 annually, or return their space and renumber into 
> > provider-assigned space.
> 
> $1,250/yr since the expected assignment would be /48 for 
> nearly all sites.

The proposal says:
"[If it can get an ASN, an organization] shall also qualify for one 
IPv6 prefix assignment or allocation of the minimum size justified by 
them under the ARIN guidelines for LIR assignment to such an 
organization. "
http://www.arin.net/mailing_lists/ppml/3007.html

That means a /32.  The micro-allocation policy (/48) is for "critical 
infrastructure providers." 
http://www.arin.net/policy/index.html#six10


Lee
 
> 
> 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 ARIN-PPML mailing list