[ppml] Policy Proposal 2003-4: IPv6 Policy Changes

[John M. Brown]

lots of stuff, not going to comment on all of it.

from my perspective the current policy restricts ISP's from
even making the request for space.

1. If the policy says 2 years and 200 allocs.  The policy
does not say "we will look the other way if you are nice,
and if you arn't we will come at you".

   To quote John Curan.  Policy needs tobe "Crisp and Clear"

   To imply that the RIR's would look the other way in some
cases and not in others, is NOT crisp and clear.

   My attorney would advise me NOT to sign any agreement that
didn't specifically spell everything out.


2.  you use the term, "as IPv6 gets significant deployment"
    allow me to edit
    "if IPv6 gets significant deployment"

    As long as we restrict the allocation of IPv6 to the point
    where people who have reasonable likelihood of doing something
    can't get the space, we won't see significant deployment.

3.  The more I read about v6 alloc policies, the historical docs,
    etc, the more I get the gut feeling that we are having a 
    gut reaction to the problems that IPv4 almost faced a decade
    ago.

    The sky is falling, We are out of space, Route tables are 
    to big.

    Hmmm,  We have enought v4 space until when ?? 2030 ??
           The sky didn't fall
           Routers got bigger, more memory, smarter routines

    When the likes of <insert favorite big ISP> figures out how to
    aggregate their prefixes the routing table will get smaller.
    (My BGP table is around 75K routes per peer, seems happy)


4.   There are orgs that have the ability to do real live v6 work
     but can't get space.  not even from their transit providers.
     Costs are an issue today.  Every penny counts.

     No garage shop research, ignoring inovation from places that
     have inovated before.  Or should we only have MS, IBM, et al
     doing the research ??




> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Thomas Narten
> Sent: Monday, April 07, 2003 9:07 AM
> To: Member Services
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2003-4: IPv6 Policy Changes 
> 
> 
> I have some comments on this proposal.
> 
> > 5.1.1
> > 	[under d) add:
> 
> > 	Other organizations are defined as any customer of the LIR.
> 
> I have no issue with this. The intent of the orignal wording 
> was to make it clear that the LIR is assigning address space 
> to someone else, not themselves internally. Clearly, a 
> customer of the ISP is such an example.
> 
> > 	No distinction will be made in terms of number of IP addresses
> > 	required, even if that number is one.
> 
> Not sure why this is needed or what problem this is intended 
> to fix. Specifically, the intent of the LIR requirement is 
> that the LIR be assigning address space in such a way that it 
> will use up that address space at some point in the future as 
> IPv6 gets significant deployment. If ISPs are giving out /48s 
> and /64s, this will presumably happen. But if the ISP is 
> giving each customer a /128 (i.e, one address), it is much 
> less clear how quickly address space is being consumed.
> 
> Looking it another way, if an ISP is planning on giving its 
> customers /128s, why does it /32 worth of address space?
> 
> > 5.8 Allocation for Early Adopters
> 
> > 5.8.1 Waiver of criteria listed in 5.1.1 (d)
> 
> > 	To promote the allocation of IPv6 space the requirement 
> to make 200
> > 	/48 assignments within two years shall be waived for anyone
> > 	requesting IPv6 space before Dec 31, 2004 or until this policy
> > 	is amended.  In the event that this policy is amended the
> > 	existing IPv6 space holders shall not be subject to new or
> > 	waived criteria for a period of 10 years from their initial
> > 	allocation date.
> 
> The intention of 5.1.1 is to give allocations to 
> organizations that are assigning address space to end sites. 
> As we don't really know in what time IPv6 will really take 
> off, it is hard to come up with a hard rule that says at what 
> point an orgnization is making a Bad Faith effort at assign 
> space to customers. The "plan" for "200 sites", over "2 
> years" was an attempt to capture the notion that allocations 
> go to organizations who are serious about assigning space to 
> end sites, as opposed to those that just want a "permanent" 
> allocation that is "PI", but can't otherwise meet the 
> intention that they (eventually) assign to significant 
> numbers of end sites.
> 
> At the time this text was originally discussed, I think the 
> individual RIRs made it fairly clear that they did not intend 
> to immediately go after LIRs after 2 years to see if they 
> really had 200 customers. What they wanted was a tool to push 
> back if a particular LIR clearly wasn't doing anything with 
> IPv6, had no real intentions too, and meanwhile, looking at 
> what other LIRs were doing, IPv6 was actually taking off and 
> compared to other LIRs, a particular LIR was really not 
> making a Good Faith attempt at meeting its obligations. Those 
> LIRs would be targets.
> 
> So, I'd certainly be willing to consider changes that made 
> the above more clear, or made potential LIRs feel better 
> about applying (when they should). But I'd be opposed to 
> policy changes that undermines the basic intent.
> 
> Having said that, I'm opposed to the above wording changes 
> for 3 different reasons:
> 
> 1) it goes against the spirit of being an LIR and seems to allow folks
>    to get an IPv6 allocation when they have no plans to deploy
>    IPv6. We should not be giving /32s to organizations that have not
>    intention of assigning address space to end sites.
> 
> 2) I'm also opposed to a 10 year waiver on fees. That is way too
>    long. I think it is fine to have a fee waiver for a year or two,
>    subject to extension as needed (which is more-or-less already the
>    current situation, I believe). But I see no reason to lock in a ten
>    year time period. That is excessive.
> 
> 3) As a general rule, it seems bad policy to say that for any policy
>    we put into place today, it is exempt from future policies or
>    future policy changes. We always need to reserve the right to
>    correct mistakes. That does not mean that new policies should
>    ignore previous policies. Indeed, it should be required that new
>    policies consider the impact they have to existing allocation
>    holders. But they should retain the option to modifying previous
>    policies.
> 
> > 5.8.2 Waiver of fees
> 
> > 	a) To promote the allocation of IPv6 space all IPv6 related fees
> > 	shall be waived until Dec 31, 2006 for anyone requesting and
> > 	receiving space before Dec 31, 2004.  In the even that this
> > 	policy is amended the existing IPv6 space holders shall
> > 	under no circumstances be subject to waived or new fees until
> > 	Dec 31, 2006.
> 
> Per above, I don't have a big problem with waiving fees, if 
> the fees are considered to be an excessive burden. But I'd 
> like to understand that better. My understanding is that that 
> the fees associated with getting a /32 are relatively low, 
> and are a small fraction of the $$ that would be required to 
> provide a production IPv6 service. I'd like to understand 
> more how the existing fees are barriors to getting IPv6 space 
> and providing IPv6 service.
> 
> > 	b) For billing purposes fees will be due according to normal
> > 	ARIN billing policies on Jan 1, 2007.  All early adopters
> > 	will have the same billing date regardless of the date
> > 	they received their allocation.
> 
> > 5.8.3 Micro Allocations
> 
> > 	a) To promote the allocation and deployment of IPv6 all the
> > 	criteria in 5.1.1 shall be waived to those requesting a /48
> > 	micro allocation before Dec 31, 2004, or until this policy
> > 	is changed.  If this policy is changed, current space holders
> > 	shall not be subject to any new or waived criteria.
> 
> This goes against the intent of the IPv6 policy, namely that 
> only LIRs get address space from the RIRs, and that end sites 
> do not. The above seems to allow end sites to get /48s 
> directly from RIRs. This is a mistake and will open the floodgates.
> 
> > 	b) All fees shall be waived under the same rules listed in
> > 	5.8.2.
> 
> > 	c) Those receiving micro allocations shall not be allowed to
> > 	make further allocations or assignments out of their /48.  It
> > 	is intended for their internal use only.
> 
> > 	d) When possible those receiving micro allocations shall
> > 	return their allocation and receive a new /48 from their
> > 	upstream provider (a LIR).  This is requested in a good faith
> > 	manner until Jan 1, 2007 at which time all micro allocations
> > 	granted under these waived criteria must be returned.
> 
> Thomas
>