[ARIN-consult] Fee Schedule Change Consultation

[Owen DeLong]

On Oct 25, 2012, at 8:59 PM, Jesse D. Geddis <jesse at la-broadband.com> wrote:

> Jimmy,
> 
> I think william is speaking to a more fundamental issue that I'll try to
> paint more broadly. Getting PO's etc are practical issues and are
> certainly significant hurdles in organizations where you have over 100,000
> employees let alone 10,000.
> 
> I think William's observations are of interest because he is illustrating
> a progressive scheme that appears almost punitive to small business while
> rewarding the larger organizations and their vast waste of resources. I
> would argue it even encourages that waste.
> 
> 	Looking at this from a broader view I think it's important to take a look
> at how were things handled in the past as well as the result. In the past
> this same progressive scheme was used and one has to ask what have we
> achieved in using it? You have organizations like Sony with a /8 that are
> using it _entirely_ for internal addressing. I wish I could say this was
> uncommon having worked at Sprint, WorldCom, Sony, and EarthLink I know
> it's the norm. I think when you have a sliding scale like this it has an
> inadvertent effect of favoring large allocations to organizations who are
> extremely wasteful.

You say this like it is somehow a bad thing. It is perfectly legitimate for Sony
to choose not to deploy NAT and suffer the degraded internet access that implies.
Any company that wants to can still apply for and obtain IPv4 addresses for
internal addressing so long as the supply lasts. Yes, they are encouraged to
help the community out by deploying NAT, but there is no such requirement
even in current policy. (nor should there be, IMHO).

> 
> 	What would happen if this progressive scale were turned upside down this
> time around? I think the following would happen:
> 
> 1. Organizations would be encouraged to use address space more efficiently
> 2. I think ARIN's revenues would be greatly increased
> 

It is impossible to evaluate these two claims absent some more detailed description
of exactly how you would turn this scheme upside down and what the fees would look
like.

The current proposal actually does nothing of the sort in the end-user case. In fact,
it encourages wastage from organizations of all sizes in that if you have disparate
blocks of space, you would now be monetarily incentivized to turn them in in trade
for an even larger block (essentially take the sum of what you have and trade it
in for an aggregate block which rounds up your current size to a bit boundary). In this
way, you could consolidate your multiple IPv4 blocks into a single block and reduce
your fees by n where n=(total blocks currently held - 1) * 100 per year.

> 3. The one drawback is ARIN may possibly have to deal with more people
> (i.e. greater ticket volume) but I think this would pay for itself

I also don't see how you draw this conclusion (either half of it).

> 
> 	Maybe I'm being overly skeptical but I was around when IPv4 was first
> being issued and I remember the feeling that there was a limitless supply
> of address space. As a result you have organizations like Apple 17/8, HP
> 15/8, Ford 19/8, Merck 54/8, halliburton 34/8, ely lilly 40/8. The list
> goes on and on. Do we want this situation again? I just listed off
> 100,000,000 IP addresses allocated. Does anyone believe Ely Lilly needs
> 441.5 public IP addresses per employee to make Cialis?
> 

All of the organizations you list are large enough that they very likely have
reasonably efficient utilization of their /8s.At max utilization as a flat /8,
you only get about 16.7 million addresses per /8. Is there any reason to believe
that any of those companies are unlikely to have at least 10 million nodes on
their networks?

> 	I would hate to see us start down the same path expecting a different
> result. Are there a lot of IPv6 addresses? Sure, but what good does 4.8x10
> to the 28th power do if the underlying allocation policy doesn't trickle
> down to end users that way?

Where did 4.8E28 come from? Total IPv6 is 3.4E38 and the current /3 being used
for unicast is 4.25E37. A /32 is 7.9E26 and a /48 is 1.2E23. (all numbers
rounded to 3 significant digits).

The current allocation policy does make it pretty easy to get PI /48s for each
of your end sites from ARIN. I don't, however, believe that it is so liberal
as to create any risk of runout. If, somehow, we manage to burn through the
current /3 while I am still alive, I will be the first to support using a
more restrictive policy for issuing the next chunk and suggest even moving
the total chunk size down to /4.


> Jimmy, I think you and I may see things somewhat differently as to why
> things are where they are with IPv4. To me, getting where we are today,
> after only about 10 years is an issue of policy. I think at some point we
> would have arrived here anyway but I think a large part of the reasons
> we've arrived here with IPv4 so soon is because:
> 

IPv4 has been issued since the early 1980s, so, 10 years is not exactly an
accurate statement. (Try 30+). ARIN has been around for 15 years. (currently
ARIN XXX meeting and 2 meetings per year).

> 1. What I cited above regarding inappropriate allocations and the
> assumption that it would never run out (seem familiar?)

This assumes that everyone buys into your premise that those assignments
were, in fact, inappropriate. I, for one, don't agree.

> 2. The larger your allocation the easier it is to acquire additional (and
> massive) space (this is backwards imho)

I also do not accept this premise entirely. Having done several large ARIN
applications, I can assure you that it is MUCH easier to get an additional
IPv4 /24 or IPv6 /48 than to get an IPv4 /16 or an IPv6 /24. Much easier to
get an IPv4 /16 than an IPv4 /12. Virtually impossible to get something larger
than a /12 unless you have massive amounts of documentation and got in under
the wire before things moved to three-months.

> 	I think it's easy to be tempted to look at this as a $$ issue and say
> well these fees are small compared to enormous company X. That may be true
> but I don't think it's the point. I think as organizations start getting
> larger and larger allocations we should start taking a much closer look at
> "what are you doing" and "why". I think when you have a fee structure that
> reflects that rather that a fee structure that reflects the exact opposite
> you may get a different result.
> 

Your assertion that it doesn't already work that way does not line up with
my experience or my observations of the ARIN process.

As a general rule, ARIN has taken the tact that Fees are not a mechanism
for incentivizing behavior and are instead intended as a cost-recovery
technique.

I certainly think within the realm of cost-recovery, we should seek to make
sure that the fees don't incentivize behavior contrary to the good of the
internet or the organization or the community to the extent possible, but,
I'm not so convinced that we should be looking to make fees punitive for
behaviors some subset of the community perceives to be inappropriate.

Owen

> -- 
> Jesse D. Geddis
> 
> LA Broadband LLC
> AS 16602
> 
> 
> 
> 
> On 10/25/12 8:43 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
> 
> On 10/25/12, William Herrin <bill at herrin.us> wrote:
> 
>> question I'm asked: can it wait. The second question I'm asked: do we
>> lose anything by waiting. The honest answers: it can and directly
>> speaking, we don't.
> 
> Well, you could cite RFC6540, and remind that the internet standards
> say you can't wait.
> 
> A $20 reg fee is ridiculously small,  compared to the human cost of
> planning and deploying, in terms of  person hours,  and new training
> for technical staff that need to understand the network.  But
> 'waiting' or trying to not spend the cash, does not make the IPv6
> future go away.
> 
> By  waiting  and not at least pre planning IPv6  you have a risk of
> increased amount of work that will have to be done in the future;
> reexamination  and reconfigurations of hosts and networks deployed
> without IPv6,  possible requirements to replace equipment,  unless
> your  IPv4 network will stay the same size the whole time you wait.
> 
> So yeah, there is something quantifiable lost,  and  some significant
> risks created
> by  just choosing to wait.
> 
> 
> 
>> 
> 
> Rather than try to balance them out at this point;  I do say,  I
> believe  the IPv6 initial allocation, transfer fees and maintenance
> should be much lower than IPv4 fees, rather than unified.
> 
> A zero-cost for the end user option should be offered to receive an
> initial allocation of IPv6 resources any time IPv4 resources are being
> transferred, requested, by an org with no IPv6 block,  and a  low-cost
> option to  pay for an IPv6 allocation at the same time as IPv4
> resource renewal.
> 
> The work required for ARIN to manage each block of IPv6 resources
> should be much lower,  especially with  ARIN's  "ipv4 countdown plan"
> and   requirement  for  increased amounts of  review during initial
> allocations.
> 
> Not to mention the many services which are really only of interest for
> IPv4 resource holders: such as the  ARIN STLS.
> 
> And of course the opportunity  to  promote using one large block of
> IPv6  for new initiatives when possible,  over   multiple disparate
> IPv4 blocks which will have to be requested or obtained at separate
> times, as the usage need increases.
> 
> 
>> Bill Herrin
> --
> -JH
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN
> Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the
> ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.