Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: fee schedule (Matthew Kaufman)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Paul Vixie)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
5. The case against need based justification (cb.list6)
----------------------------------------------------------------------
Message: 1
Date: Sun, 07 Apr 2013 22:09:27 -0700
From: Matthew Kaufman <[email protected]>
To: John Curran <[email protected]>
Cc: "[email protected] PPML" <[email protected]>
Subject: Re: [arin-ppml] fee schedule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 4/7/2013 8:57 PM, John Curran wrote:
> On Apr 7, 2013, at 1:35 PM, Matthew Kaufman <[email protected]> wrote:
>
>> It is just ARIN trying to figure out how to maximize its own revenue.
> To be clear, the change in the Revised Fee schedule is revenue neutral;
> please review the slides referenced earlier for additional information.
> <https://www.arin.net/participate/meetings/reports/ARIN_XXX/PDF/thursday/curran_fee_schedule.pdf>
I wasn't trying to claim that the revised fees aren't revenue neutral.
All I was trying to claim is that ARIN gets more with the current fee
schedule than they would with everyone paying $500. And they can do that
because some organizations are more than willing to pay a lot more than
$500.
>> It knows that if it charged everyone the same amount, there would be some
>> large organizations who could easily afford to pay more but from whom they
>> aren't extracting any extra revenue.
> Actually, we could easily go to a single fee for all ISP regardless of
> size. This would result in significantly higher fees for smaller ISPs
> (as the per-ISP fee would approximately $2800 per year.) This does not
> seem to be the right direction if we're trying not to burden smaller ISPs.
I believe this just proved my point above. Not finding the few who are
willing to pay more and charging them more would result in $2800/year
across the board fees. Which would then result in a bunch of small ISPs
not bothering to pay that at all, which *wouldn't* be revenue neutral.
(And then I suppose it would be even more than $2800/year, wouldn't it?)
I'm not saying ARIN is evil... far from it, ARIN is doing *exactly* what
I would expect an entity setting prices to do. It has segmented its
pricing such that some can pay more and others can pay less and the
number of customers is high. Making the price $2800/year for the
smallest ISPs would result in fewer of them being able to afford the
service, and yet the ones paying $32,000/year under the new schedule are
clearly ok with paying that much so that there's a $500 price point
available for others.
The problem is that the current set of steps is based on something we
shouldn't be messing with. There shouldn't be a /48 or smaller step and
there shouldn't be a /36 to /48 step, because the existence of both of
those has pressured the numbering policy into once offering /36 as an
option instead of /32, and now trying to find something even smaller to
offer... only because to have all of the small ones at the /32 step
would (in order to be revenue neutral) require all of them to pay
~$1500/year.
Find something else to base the fee steps on before we do something else
stupid, please.
Matthew Kaufman
------------------------------
Message: 2
Date: Sun, 7 Apr 2013 22:09:08 -0700
From: Owen DeLong <[email protected]>
To: Matthew Kaufman <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Apr 7, 2013, at 15:32 , Matthew Kaufman <[email protected]> wrote:
> On 4/7/2013 2:14 PM, Owen DeLong wrote:
>>>> One possible way to distinguish ISP size for IPv6 would be to use
>>>> annual gross revenue instead of total address holdings. I don't know
>>>> if that would be an improvement or not. I realize it would be more
>>>> complex to calculate and enforce. I think it would likely be more fair.
>>> More fair would be everyone pays the same. Or everyone pays based on the
>>> amount of service they actually require from ARIN.
>> I disagree completely here. An end-user with a single /48 is not in any way
>> reasonably expected to pay the same as an ISP with multiple ASNs, a /20 of
>> IPv6 and an aggregate /6 of IPv4 space.
>>
>> I can't imagine in what possible universe anyone could imagine that to be
>> fair.
>
> Why not? As long as the price is reasonable I don't see who could possibly be
> opposed to a model where the only added costs are for those who actually cost
> ARIN more to service, not some arbitrary scaled scheme where well-run large
> orgs pay more than the tiny ones that need lots of handholding. Or, even
> better, a flat price for all. But of course there *would* be some opposed,
> because for every choice it isn't "fair" to someone.
>
I noted the reasons below. It puts strong incentives in bad directions.
> This is just like the US tax system... nobody thinks that any of the models
> are "fair". Flat tax? Unfair to the poor. Higher taxes for the rich?
> Disincentive to working harder and unfair to the rich. You can't win.
>
Actually, I think that a flat consumption tax that excludes food and clothing
items and written word matter (regardless of media) under $100 would be quite
fair. It isn't unfair to the rich because it's based on consumption, not
earning. However, this is far afield from PPML's purpose.
> And that's why we shouldn't be discussing the fee structure here at all. We
> should be discussing what numbering policy results in the best addressing
> plan for the Internet. And I believe that handing out /36 and /40 to ISPs
> doesn't do that.
>
I agree with you, but the fee structure, like it or not, is going to drive
consideration of those policies, or, we're going to need a discussion somewhere
that drives a better fee structure.
>>> Basing it on amount of space *or* gross revenue isn't "fair"... it is just
>>> a way to extract extra revenue from those who (in theory) have more to send
>>> to ARIN, which gives ARIN the opportunity to lower prices at the other end
>>> to keep the masses happy, or to just increase its overhead to ensure the
>>> money gets spent.
>> We can agree to disagree on what constitutes "fair" here. I believe it is
>> "fair" for those that are extracting a greater amount of revenue from the
>> community resources they hold to contribute a greater share to the costs of
>> maintaining said community resources.
>
> So we should be charging mobile operators more than we charge dialup
> providers because the ARPU is higher?
>
I'm not necessarily opposed, but I'm also not convinced that's true, either.
>>
>> I don't see it so much as extracting extra revenue so much as
>> differentiating the allocation of the total costs.
>
> Those are exactly the same thing. One just sounds better than the other.
>
> The idea is that you find the people who are willing to pay more, you figure
> out how to charge them more. In this case, you take some of that "extra"
> revenue and use it to drop the prices for the people who aren't willing to
> pay as much. Classic pricing theory covers this, and I would expect no less
> from any organization. But it doesn't make it "fair" either.
Another way of considering it, however, is you try to find ways to serve those
that couldn't pay as much as it would take for everyone to pay the same amount.
Over the time I've been involved in ARIN, combinations of better policy and fee
reductions over time have created a better ability to serve a wider range of
organizations. I think this is a good thing. Many organizations would simply be
excluded from obtaining direct allocations/assignments if ARIN were to go to a
flat-rate structure. I do not see that as being overall beneficial to the
community.
>
>> I don't believe for a second that ARIN is increasing its overhead just to
>> ensure the money gets spent. I have reviewed the ARIN public financials
>> several years in a row and I believe that ARIN does a great deal for the
>> community at a very reasonable cost to said community.
>
> We've had offers to do it for less.
>
No, we've had offers to do part of what ARIN does for less. I am not convinced
that those offers represented a sustainable way to do it, either.
>>> But we see this all over the world these days, so it isn't like I'm
>>> surprised that they would behave this way. At least they're not creating
>>> additional address registries and then telling people they need to register
>>> their addresses there too in order to protect their trademarks, like some
>>> other winners of the how-can-we-charge-for-things-that-were-free game that
>>> the Internet played some years ago.
>> This really isn't a fair characterization of either structure. First, I
>> agree that what has happened in the DNS realm has been badly mismanaged and
>> that most of the mismanagement has come about as a result of various profit
>> motives.
>
> Ok, then we agree on that front.
>
>> However, to claim this was strictly a matter of "how can we charge for what
>> was free?" is not at all accurate. The original switch to "charging for what
>> was free" was an effort to sustain the existing infrastructure from a new
>> funding source since the previous government contracts were about to become
>> unfunded.
>
> I was there. It was a little of each. Lots of people volunteered to do things
> for free, but instead we had to play by the rules that were set up to make
> sure that a small number of people were able to sit at this newly-created
> trough. And here we are. Yes, numbering has worked out a lot better for the
> public interest than names did, but it still isn't great.
>
Doing it for free sounds great, but in reality, anyone doing it for free isn't
obliged to keep doing it. If you're not taking money, there's no "exchange of
value" and legally that means there's no contract. Volunteers can quit any time
they want.
I would argue that these functions are too important and must be sustained as
continual operations. Therefore, placing it in the hands of an organization
offering to do it for free isn't exactly ideal.
I actually think that the numbering situation is pretty good.
>> I think that the number registries have done a vastly better job of the
>> transition and keeping things cost-recovery based while providing the
>> services the community has said it is valuable for them to provide at a very
>> reasonable cost to the community.
>
> Agreed.
>
Then what, exactly, are you criticizing about ARIN spending? What money do you
think is being wasted or spent improperly? Where do you think this alleged
reduction in revenue is feasible?
>>
>> As much as I think that the new fee structure contains some really poor
>> decisions that will drive poor number resource policy as a consequence, I do
>> think that the board is trying to balance a number of tradeoffs and has made
>> a reasonable attempt at doing so in a fair and consistent manner.
>
> Yes. But one of those tradeoffs is that they apparently can't figure out how
> to run ARIN in a world where everyone with a /32 pays the kind of fees that
> these "extra small" ISPs claim they can afford. That's not a numbering policy
> problem.
True, but it is a fee structure problem. Unfortunately, if we can't solve the
fee structure problem, we're probably faced with the reality of contorting
number policy in order to address the reality of the situation. It's not ideal,
but it's also not unusual.
For example, it's hard to prove someone was impaired while they were driving.
Instead, we substitute characteristic amounts of alcohol in their blood stream
as evidence that they must have been impaired.
>>>> I would like to hear about other creative ideas on ways to measure
>>>> size and/or appropriate metrics to be used for fee determination.
>>> Each email or call requires a fee payment above and beyond a tiny fee which
>>> everyone pays and which is equal for all. Or, worst case, a tiny fee per
>>> database row.
>> The problem with this is that it would again create negative incentives. It
>> will financially incentivize the following negative behaviors:
>>
>> 1. Avoid updating records to reflect changes.
>> 2. Downsize customer assignments to avoid having to request
>> additional space.
>> 3. Avoid interacting with ARIN until it's absolutely necessary and
>> cannot be avoided
>> through other contortions of ones own address space.
>>
>> I don't thin that's a desirable outcome any more than what is proposed in
>> the adopted fee structure combined with what is proposed in 2013-3.
>
> Of course not. But "charge the new extra small fee for everyone with a /32,
> and don't allocate anything smaller than /32" (which would provide enough of
> a fix for enough of the people right away) we are told isn't compatible with
> "don't drastically reduce ARIN's expenses", which is also not something we
> can impact with the numbering policy process.
Right, so we agree that neither of those solutions is viable, now let's look
elsewhere for one that is.
Owen
------------------------------
Message: 3
Date: Sun, 07 Apr 2013 22:13:32 -0700
From: Paul Vixie <[email protected]>
To: Matthew Kaufman <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
...
Matthew Kaufman wrote:
> On 4/7/2013 6:41 PM, Paul Vixie wrote:
>
> ...
>> ... the ARIN fee schedule is based in no way on willingness to pay more.
> Willingness, ability, same thing. Since I started writing this reply,
> John has chimed in to note that if everyone paid the same it would
> need to be $2800/year. So ARIN has happily found a few ISPs that are
> willing to pay so much more than some others can pay as little as $500.
willingness and ability aren't the same thing, but that doesn't matter,
because the fee schedule isn't based on either one.
paul
------------------------------
Message: 4
Date: Sun, 7 Apr 2013 22:11:10 -0700
From: Owen DeLong <[email protected]>
To: Paul Vixie <[email protected]>
Cc: John Curran <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Apr 7, 2013, at 18:10 , Paul Vixie <[email protected]> wrote:
> ...
>
> Michael Sinatra wrote:
>> ...
>>
>> I don't like discussing the fee schedule on PPML any more than anyone
>> else, but as an operator, I am being asked to support an
>> operationally-suboptimal policy as a band-aid for this one issue in the
>> fee schedule, and that's what's giving me heartburn right now.
>
> are you aware of the other arin mailing list, limited to members unlike
> this public policy mailing list (PPML), where discussions of fees paid
> would be somewhat more targeted since it would be a discussion of
> fee-payers? this mailing list is documented here:
>
> http://lists.arin.net/mailman/listinfo/arin-discuss
Unfortunately, that's not an entirely accurate characterization.
arin-discuss is only open to members to the best of my knowledge.
Many (if not most) of the entities paying fees to ARIN are not members.
In fact, I could not be on that list by virtue of my own resources. I happen
to be on there because I am a consultant to several members and an
employee of one.
Owen
------------------------------
Message: 5
Date: Sun, 7 Apr 2013 22:13:07 -0700
From: "cb.list6" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [arin-ppml] The case against need based justification
Message-ID:
<cad6ajgra39ird_gu8nxea+bpnv-mxxxmr+uougvchg5dj3u...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Need-based justification is being reviewed in RIPE [1]
That spurred me to review need based justification in ARIN for both
IPv4 and IPv6.
I would like to present some facts for review so that the ARIN
community can judge the success of need-based justification and
consider the role it will have in future policy.
First, as of this writing, ARIN still has 2.47 /8s free [2].
Excluding the last /8 which is locked in a way by policy, that leaves
approximately 24 Million addresses in the free pool. Assuming a free
market cost of $10 per IPv4 address, that is $240 million worth of
IPv4 cost off-set from which one would have to pay the free ipv4
market for those addresses. This is a relevant sum on nearly any
balance sheet. So, it is not acceptable to say folks are turning away
from it because ARIN is offering that space in a fair way. The free
pool is relevant.
There is a case that the need-based policy has done well, and it has
done well for some. Comcast, for example, has 18 million subscribers
and 70 Million IPv4 addresses [3]. For simple math, we can call that
3.8 addresses for every 1 customer. Then, you have a network like
Metro PCS who has 9 million subscribers (2.2 million of which are LTE)
[4] on what i can tell is 1,024 IPv4 addresses. Which is a
0.000113778 IPv4 addresses per subscriber from ARIN. I do not speak
for Metro PCS, i just found their case interesting.
So, there are winners and losers in need-based. Winners puts more
time and money into the process, losers are busy optimizing other
parts of their business instead of working the ARIN system. Looking
back at [3], winners are also big companies with a lot of resource
and ... they probably send people to ARIN meetings and ... maybe they
even send lawyers to ARIN meetings. I don't know, i have never been
to an ARIN meeting myself.
So far, i hope we have seen that the free pool as of today is relevant
and that need-based is not strictly "fair" in how the distribution
happens, and that there are winners and losers. Winners invest more
time and effort, and sometimes time and effort is from lawyers not
engineers.
Now, there is more. Many organizations have found ARIN unsuitable for
their address needs. We know that in 2011 when the free pool was much
larger than it is now (4+ /8s?), Microsoft bought IPv4 space from a
bankruptcy court [6]. Amazon among others has also made substantial
market buys. These companies are obviously not getting what they want
from a need-based policy, and i assume they made cogent business case
to close these deals. The difference is they have the money to work
the policy like Comcast, but instead they worked a different angle
also applying money. But, need-based is not a about money. Is it?
It is about justified need, or the appearance of such. It would
appear that Amazon and Microsoft could justify need, but the
need-based policy does not appear to work for them. I am aware of the
transfer policy and how need is, for some reason, a different standard
there.
So, that is open market end of things, organizations pay millions of
dollars instead of thousands of dollars to not use a need-based policy
of the ARIN free pool. Seems like the symptom of something broken.
Here is another symptom of something broken. The largest internet
growth engine is mobile. Mobile contributes a huge amount of traffic,
growth, and "stuff" on the Internet. If Zuck does not mention mobile
20 times in an earnings call, FB stock dives. AT&T wireless and
Verizon Wireless both have close to a 100 million subscribers each.
And, just about every one of those subscribers uses RFC 1918 space.
What about those 2 smaller players, Sprint and T-Mobile. Both of them
use squat space. Despite spending time and money on outreach, this
HUGE part of the internet is not part of the ARIN numbering system
(unless you count the ARIN addresses on the CGN). At least, not part
of ARIN's need-based policy. Mobile uses CGN because ARIN's policies
have not and will not fit with the growth of these networks and their
architectures. Not today, but also not in 2003. I would like that
that to change [7]. Speaking for myself, what i saw was a network was
designed to best fit the business needs. That network design did not
fit ARIN policies for efficiency, and so ARIN would not provide
addresses and CGNs were rolled in to close the gap between the best
network design and the ARIN policies.
Speaking more for myself, in 2000 i worked for an ISP, and one of my
job roles was assigning addresses to T1 and T3 customers of the ISP.
It was a painful process for me and my customers. We lived in world
where people just wanted a /24 to turn up their LAN, but i could not
just give it to them. It was a world of scarcity of addresses, emails
full of made up justifications, and that persist today.
In fact, last year i tried to get a /48 of address space for a lab
network attached to a T3 from TWT. They would not give me more than a
/56. I heard from another guy that Internap would only give him a
/64. Need-based is a trickled down disease on network design.
It is not just mobile doing CGN. AT&T has deployed CGN to landline
DSL [8], and now Verizon DSL too [9]
As previously noted, the ARIN free pool is a non-trivial sum of 24
million IPv4 addresses. Yet, companies continue to buy addresses and
/ or deploy CGN. And they do it at massive scale. We are talking
about the biggest cloud and access network providers can't seem to get
what they need from ARIN whether it be IPv4 addresses or effective
IPv6 deployment advocacy.
My conclusion from all this is that need-based policy did not help
IPv4 and is actively hurting IPv6.
NRPM and ARIN should get out of the business of telling people how to
number their networks, it has not helped the businesses or the
internet. I say this because "we" did not transition to IPv6 and the
market for IPv4 and the technology known as CGN is seen as more
effective solution than ARIN or IPv6
That brings me to policy changes that i would like feedback on.
1. Should ARIN continue to administer need-based policy now and after
run-out? Please note the discussion of winners and loser with data
points [3] and [5]. Who is ARIN serving with the need-based policy?
2. I have made the claim that ARIN's need-based policy has negatively
impacted system design, the specific system being the internet. The
squat / CGN internet that is on your phone [7] and coming to your DSL
[8],[9].
3. By moving away from need based policy from ipv4, we accept reality
that the market rules [6]. IPv4 addresses are part of the means of
production in a capitalist society. IPv4 addresses should not be
acquired by playing some logic game with people via ARIN tickets or
intellectual thumb-wrestling and posturing on PPML.
4. IPv6 is designed without need in mind, there is no reason for ARIN
to import the notion that need is factor when each LAN is given 2^64
addresses. Organizations that want PI should get an ASN (existing
policy) and a minimum /32 and be done. End of story. There is no
logic for conservation of a limitless resource (in this case, it is
bounded by ASN). Growth beyond a /32 should just be a simple written
justification, not gear and subscriber logs showing 80% use.
5. These simplifications can be reflected in a rate structure that
results from such simplification.
[1] https://www.ripe.net/ripe/policies/proposals/2013-03/
[2] https://www.arin.net/resources/request/ipv4_countdown.html
[3]
http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf
[4]
http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight=
[5] http://whois.arin.net/rest/net/NET-65-91-116-0-1.html
[6] http://www.bbc.co.uk/news/technology-12859585
[7] https://www.arin.net/policy/proposals/2013_2.html
[8]
http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address-
[9]
https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 24
*****************************************
