[ARIN-consult] Fee Schedule Change Consultation

Fri Oct 26 17:14:46 EDT 2012

Owen,

	If you believe how things have been handled in the past have served us
well I guess none of us would be having this conversation about rolling
out IPv6 right now at all, right? Thank you for your reply but lets try to
keep things constructive. A couple people have since suggested a sort of
flat fee but this takes it a step further. Below is my response to a
couple of John's questions:

John,

Thanks for your note. You're right about the policy part, however, it was
purely a fee conversation and I didn't want to steer things off topic ;)
Further, I think there is a mindset that comes with the existing
progressively cheaper fee structure that encourages the kind of waste
we've seen with IPv4. However, the issue of policy is of greater
importance.

I think there are a couple of ways to address it:

1. The current practice is to award larger and larger blocks to orgs. I
think this has proven troublesome.
	1. The point of this was to keep the table small but I think since newer
hardware is required to support ipv6 in the first place this is no longer
relevant. Besides ARIN can't really dictate how an org advertises their
space <http://www.cidr-report.org/cgi-bin/as-report?as=AS35908&view=2.0>.
	2. It creates waste because an org who has run out of their /16 would be
foolish to request a /22 even if that's all they require. They are
incentivized by allocation practice to request the largest they can and
hoard it. VPLS is a prime example of that
<http://whois.arin.net/rest/org/VPLSI/pft>. They have only 20 cabinets of
dedicated servers but over half a million IP's. 98% of which they aren't
using because they have abused ARINs progressive allocation practice in an
effort to later sell those resources on ARIN's market at vastly inflated
prices.

2. A linear fee might be worth looking into rather than a progressive one
(i.e. A flat tax). One for IPv4 and one for IPv6.
	1. It may help encourage more efficient usage
	2. It wouldn't penalize smaller organizations as severely and be fair
across the board.
	3. Much simpler billing structure. Say you were to bill $x per /64
starting with allocations made in 2013. For orgs that predate that move
(because /32's used to be all that were issued) them to the new fee
structure once they request more resources. For v4 you could do $x per /24
or per IP.

3. I think ARIN could more aggressively enforce existing policies
	1. During a transfer request ARIN affords itself the opportunity to
revisit the allocation and reclaim it altogether. I haven't seen this
happen in cases where it should have based on policy.
	2. For IPv4 requests or transfers the question needs to be asked "why
aren't you natting"? AT&T is a fabulous example of this. I have tens of
thousands of residential users IPv4 NAT'd with no loss of functionality. I
dual stack them with IPv6. If I can do it why can't AT&T? Why do they need
tens of millions of IP's? There is simply no technical requirement for
every end user on dsl and uverse to have a public IP.

Anyway, these are a couple things off the top of my head but I think a
much more in depth discussion should be had about resource allocation
policy and enforcement.

-- 
Jesse D. Geddis
LA Broadband LLC

On 10/26/12 3:05 AM, "John Curran" <jcurran at arin.net> wrote:

On Oct 25, 2012, at 10:59 PM, Jesse D. Geddis <jesse at la-broadband.com>
wrote:
>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".

The statement above appears to be suggesting an approach for number
resource
policy, not fees.

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

You'll should explain how a fee structure can "take a much closer look"
at the "what you are doing & why" aspects of larger allocations if folks
are to understand your input into this fee consultation.

Thanks!
/John

John Curran
President and CEO
ARIN

-- 
Jesse D. Geddis
LA Broadband LLC

On 10/26/12 4:42 AM, "Owen DeLong" <owen at delong.com> wrote:

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.