[arin-ppml] Policy Proposal 110: Preservation of minimal IPv4 Resources for New and Small Organizations and for IPv6 Transition

Owen DeLong owen at delong.com
Sun Apr 25 11:46:12 EDT 2010


On Apr 25, 2010, at 7:40 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> On Apr 23, 2010, at 2:53 PM, Joe Maimon wrote:
>>> Michael, George,
>>> 
>>> 4.10 does not provide space to be used for addressing your customers if the reality happens to be that you cannot get or keep any customers without giving them some IPv4 addresses.
>> Thanks for that clarification Joe.
>> 
>> Nor was it intended to.  I now oppose this proposal.
>> 
>> If we're going to give IPv4 out to people just to give it to their customers, it should be given based on current allocation/assignment rules.  The purpose of reserving the /10 was so that ANYONE who was implementing
>> new transitional services (such as new NAT-PT infrastructure, etc.) would be able to get small pieces of
>> IPv4 to make deployment of those transitional technologies possible.
> This is preserved, but halved into two /12's with slightly different requirements and purposes.
> 
Yeah, I understand that.  My point is that it should not be reduced to a /11. I wanted to reserve the entire /8. The community found compromise and consensus around /10. IMHO we should be considering expanding this reservation, not reducing it or carving it up into multiple purposes.

I agree that the requirements need to be improved upon for this block. However, this policy contains so many other changes which I believe are not beneficial that I cannot support it as written.

>> It _IS_ not intended to extend the
>> useful life of IPv4 for anyone.
> No matter what is done with the last /8, it wont be a significant contributor towards extension of the useful life of IPv4. IPv4 as a continuing real world requirement will live or die on its own schedule regardless of what is done to the last /8. The fact of the matter is that there is enough inefficiently used IPv4 already out there (anywhere from 25% - 75% depending on how you look at it) that with sufficiently bad conditions, contortions and extortions, it can continue to be used and reused for much longer than most of us would want.
> 
True.

> Allowing the /8 drain into the same inefficiencies as all the prior /8's gains nothing.
> 
Which is why we reserved the /10.

> The best case scenario is that mass IPv6 adoptions occur quickly and seamlessly. While we have seen upticks and many successful technical proof of concepts, it has not happened yet. If the chances of it happening by depletion are so fragile that proposals such as this one threaten it, things are already slated to go badly.
> 
I don't think this proposal will make much difference to IPv6 adoption. I do think that as you have stated, there's little to no benefit to this proposal.

> For the not best case scenario, if practical reality dictates that IPv4 continues to be required to turn up new customers and services, those who have been around for a while, who have consumed the bulk of the ~40 arin /8 and ~70 legacy /8, will have options. New and small orgs will not have the quite the same.

IPv4 won't be available regardless of this policy.  Your previous paragraph states this. I do not believe it is appropriate for ARIN to discriminate against one class of organizations in favor of another. Frankly, large and extra large subscribers are going to be the first ones denied anyway. Smaller blocks will be available longer and run out slower than larger blocks just by the nature of the allocation process. One could argue that this fact already gives an advantage to small organizations.

>> 
>> In my opinion, this space absolutely should not be used to simply add more IPv4 customers to any provider.
> 
> What do you think will happen to the other three /10 in the /8 absent this proposal?
> 
It will, unfortunately, be used to add more IPv4 customers to the providers that get pieces of this space.

However, it will be distributed on the same fair basis as all previous IPv4 blocks. The community was offered the opportunity to reserve the entire /8 and rejected it.

>>> 
>>> The possibility exists that it may still be impractical to build a small business or start a new one with ipv6 even when no ipv4 is available except from preexisting holders who may be viewed unfavorably as monopolistic cartels and may even behave in such a manner.
>>> 
>> If that is the case, it will be a bad time to start an ISP. There are lots of factors that can make it a bad time to start an ISP. We've been through that before and we'll go through that again.
>> 
> In this instance it might be demonstrable that the community contributed to those factors and failed to attempt to mitigate them. That carries its own set of risks.
> 
I'm less concerned about those risks than the risks I see in passing this policy. Unfortunately I think it would be ill advised for me to enumerate those risks on a public list, lest they become a self-fulfilling prophecy.

>>> I believe failing to prepare adequately for that scenario is not only irresponsible but that it can be widely viewed and seized upon as evidence that we have acted irresponsibly.
>>> 
>> I believe that locking up usable addresses for theoretical businesses that may not ever exist at a time when actual running businesses have a demonstrated need is a bigger example of acting irresponsibly.
> 
> The grasshopper and the ant. Years of plenty, years of famine.
> 
> (strangely enough both apply at the same time with ipv6 and ipv4 and to the same entities)
> 
Yep.

> I consider socking away addresses during time of plenty in the face of potential oncoming famine, when the alternative is their near immediate consumption at the same rate as the last 95% the bare minimum of responsibility.
> 
Then you should study survival texts. Turns out that if you are stuck in a wilderness situation with minimal food, you do not actually prolong your life by self-rationing. Your chances of survival actually increase if you continue to eat normally until the food is gone.

> In fact, I would support the entire /8  held in reserve for specific purposes to be dictated by policy.
> 
The time to do that was 2 years ago when we were debating that issue.

> IPv6 will either be where the action is at or not. Three months of /8 at CBR wont make or break.
> 
True, but, that didn't gain community consensus.

> If it has mass adoption, than nobody should miss it. If it does not has mass adoption, we may greatly miss squandering that last rir /8.
> 
I think we're too late. No matter what we do it's going to be a bumpy ride. It will be bumpier for some than others.

>>> I do not consider the existence of transfers, waiting lists and the current 4.10 to go far enough as to be adequate.
>>> 
>>> The existence of minimal resources could do much to temper negative tendencies inherent in markets for limited resources.
>>> 
>> As I now understand the intent of your policy, it would not accomplish what you intend.  It would, instead, either create a situation where various existing organizations found ways to get in under the policy and get the space, or, it would get ARIN sued for squatting on address space that should be otherwise issued to organizations with demonstrated need.
>> 
>> Also, what you call "negative tendencies of a market", I am starting to call "incentive to move to IPv6."
> I believe the proposal adequately prevents abuse - ARIN staff may even object to the extra work it imposes on them to prevent abuse.
> 
How did abuse come into your interpretation of my statement? I'm not talking about abuse, I'm talking about creative solutions to policy compliance.

One example:
	LargeOrg A decides they need some of this address space.
	They hire contractor B to create Entity C -- A new startup.
	Entity C is funded and purchases enough infrastructure to justify an allocation or assignment under this policy.
	Entity C gets their address space.
	Entity C is then purchased by LargeOrg A who invokes section 8.2 of the NRPM and voila. Instant resources.

That's not abuse, that's a legitimate startup being purchased legitimately by a larger organization.

Now, consider how much easier this could become under 8.3.

> If conditions are such that only the small and new orgs are punished by market conditions, it can actually create an incentive for the established larger players to drag their feet towards enabling everyone to be on equal footing again with ipv6 as the predominant opportunity model. On the other hand, if  the new and small can turn up handfuls each of customers demanding/requiring ipv4, its quite the incentive for all the rest to convert customer ipv4 needs into ipv6. And they have the clout to do it.
> 
I don't think that will be the case.  In fact, the large existing orgs will be the first ones to suffer and will, actually, probably have the greatest suffering.

I don't thin the incentives will work the way you think they do. If they did, you wouldn't have public IPv6 commitments already expressed by the largest eye-ball and content providers.

> Everyone wins.
> 
I don't think so.

> If ARIN is going to get sued, this proposal is not likely to add to the set of risks, even as it may alter them, trading one for the other. Legal counsel would probably interject their opinion on that at some point.
> 
If this proposal becomes a draft policy, it will get a staff and legal review.

>>> If IPv6 is not completely satisfactory in the common case for new or small growing entities that would be our failure.
>>> 
>> I disagree.
> 
> Whose then?
> 
The list is long and irrelevant. Point is that ARIN does not design protocols or build routers. We have little or nothing to do with the level of satisfaction that can be gained from use of IPv6 vs. IPv4. There is little we can do to make it more satisfactory.

>>> It certainly would not be their fault. They werent even around.
>>> 
>> Then it is a risk they should consider prior to launching a business that is dependent on IPv4.
> 
> If IPv4 is what customers continue to want or require than you arent going to be very successful launching IPv6 businesses either.
> 
Yes, this might be one of those time periods where it's a bad idea to launch an internet business.
If you think this is news, you haven't been paying attention.

> Attitudes that are variations of "Tough, sucks to be you" are not going to go far towards helping to win friends and influence people.
> 
I'm just saying ARIN shouldn't be making it tougher on one class of organization than another, which is all this proposal really does.  It's like believing that QoS makes your network better.  QoS does nothing of the sort. It just helps you decide which customers to screw when your network becomes inadequate.

>> 
>>> The goals of (the existing) 4.10 are specifically aimed towards those who have acute need of IPv4 even when there is none normally available from Arin. That is what this entire proposal is about, clarifying some needs and adding others.
>>> 
>> The goals of 4.10 are, actually, not that.
>> 
>> The goals of 4.10 were to ensure we didn't create a "can't get there from here" problem where all IPv4 addresses were consumed for business as usual and the sudden need to deploy something like NAT-PT to provide for IPv4 services access by IPv6 clients would not be rendered impossible to deploy for want of IPv4 addresses with which to deploy it.
> 
> That is an acute need. It is also one unlikely to be actually experienced by the organizations who have consumed the bulk of the resources in the time of plenty - do you really think they cant scare up a /24 from their existing holdings, let alone a /28?
> 
Yes, I think that will happen in some cases.

> Ergo, 4.10 is actually targeted towards those who wont have that ability.
> 
Regardless of their size or history, yes.

>> We actually started out trying to set aside the full /8. We tried compromising to the /9. The community was actually pretty clear in their desire to limit this reservation to a /10.
> I think that is short sighted, considering:
>>> That changes ARIN exhaustion dates by about a month, give or take a week, at current burn rates.
>>> 
>> Yeah, that sounds like an accurate estimate.  Sorry I missed that in my first read-through.

Short sighted or not, it was the pretty clear consensus of the community.

Owen





More information about the ARIN-PPML mailing list