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

Mury mury at goldengate.net
Wed Apr 9 17:58:00 EDT 2003


Hi,

Thanks for your feedback.  I want to address a few of your points.

You mention that allowing micro-allocations will open the floodgates.
Would this be such a bad thing?  As it stands now IPv6 is basically unused
by almost any definition.  Shouldn't we be promoting the allocation of
IPv6 by whatever means we can, as long as it does not jepordize the
future?  As my policy states there is an end date to micro-allocations
that do not come from a LIR.  There should not be a swamp space problem as
there is with IPv4.

If the RIR's do not really intend to enforce the 200 allocation
requirement, then why is it policy?  That makes no sense to me.  Is it
policy or not?  I'm certainly not going to base decisions against what the
policy states.  What percentage of traditional LIR customers are going to
have a need or a desire for IPv6 in the next two years?  1%?  10%?  I'd
guess the number is less than 1%.  That means that a LIR needs at least
20,000 customers before even thinking about going down that road.  On the
flip side the large carriers have made it pretty clear they are not going
to deploy IPv6 until they have to.  So that leaves a pretty small group of
LIRs that will clearly meet the 200 minimum and care enough to do it.

You mention opposition to allowing early adopters to be free of
restrictions due to new policy changes.  I understand your point.  But on
the flip side if someone is going to invest the time and money to
implement IPv6, why should they have to worry if the rules are going to
change in the middle of that process?  I have provided a time-frame for
that exemption.  If the system needs to be fixed, it can be at a resonable
later date.

The fact is IPv6 is not being implemented.  Members on this list have
explained why.  If my policy revisions are not the answer, I encourage
someone else to come up with a better answer.

As it stands now IPv6 is dry seed with no water in the forecast, at least
in ARIN country.

Regards,

Mury


On Mon, 7 Apr 2003, Thomas Narten wrote:

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




More information about the ARIN-PPML mailing list