This is a side issue, but I'm surprised ARIN is still advertising incorrect 
information in the table. A small ISP client of mine had just received their 
first /23 earlier this year, and I convinced them they should deploy IPv6 along 
with IPv4 in their new PoP. It would cost nothing, I argued, as they could 
request a /40 and would be in the same xx-small fee category. Money is an issue 
with small companies, and I was glad to see them agree. However, ARIN refused 
the request. Here's the dialog:

ISP Requests a /40 IPv6 allocation to go along with xx-small /23 IPv4 
allocation already issued.
ARIN: The minimum size ARIN may allocate to an ISP is a /36, as stated by 
policy. https://www.arin.net/policy/nrpm.html#six52 Would you like us to 
proceed reviewing your request for a /36?
ISP: From the Annual Fees table I read this:
 XX-Small $500 ipv6 /40 or smaller.
Are you saying that there is no way to get an IPv6 allocation in the xx-small 
category?
ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocate to 
ISPs according to community-created policy. 
https://www.arin.net/policy/nrpm.html#six52
ISP: OK thanks for the info. We are going to revisit deployment plans for IPV6 
in the near future so can you cancel this IPV6 request for now?
Also, ARIN might want to update its fee schedule labeled "ISP / ALLOCATIONS 
INITIAL REGISTRATION OR ANNUAL FEES", which specifically mentions a /40 
allocation to ISPs. That's the source of our confusion on the matter.

ARIN: Thank you for your response. I am closing this ticket, per your request. 
I have seen your feedback about the fee page, and will request it be updated to 
clarify the smallest block that can be allocated to an ISP.
But ARIN still is advertising the /40 option months later! As a result we as a 
community lost the opportunity to get a new ISP off on the right foot by going 
dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN reads this and 
addresses the issue - either correct the table or honor xx-small requests for a 
/40.

 -mel beckman

On Jul 10, 2015, at 9:53 AM, Owen DeLong 
<o...@delong.com<mailto:o...@delong.com>> wrote:


On Jul 10, 2015, at 03:57 , Matthew Kaufman 
<matt...@matthew.at<mailto:matt...@matthew.at>> wrote:



On Jul 9, 2015, at 11:53 PM, 
valdis.kletni...@vt.edu<mailto:valdis.kletni...@vt.edu> wrote:

On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said:

One of the hopeful outcomes of IPv6 adoption was that an ISP could get
enough to last "forever" in a single transaction. But "forever" isn't
very long at one /48 (or more) per customer.

How long does it take to blow through a /20 at /48 a customer?

A while. But the more likely case is that the guy before you asked for and got 
a /32, because that's the minimum (and already two steps up the fee scale, I 
might add)

You want ISPs to start with /20s? I'll support that over on PPML if you propose 
it. But I'll also ask for /20 to have a fee category of "small".

Matthew Kaufman

(Sent from my iPhone)

According to https://www.arin.net/fees/fee_schedule.html

ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES
Service Category    Initial Registration or Annual Fee
(US Dollars)    IPv4 Block Size    IPv6 Block Size
XX-Small    $500    /22 or smaller    /40 or smaller
X-Small    $1,000    Larger than /22, up to and including /20    Larger than 
/40, up to and including /36
Small    $2,000    Larger than /20, up to and including /18    Larger than /36, 
up to and including /32
Medium    $4,000    Larger than /18, up to and including /16    Larger than 
/32, up to and including /28
Large    $8,000    Larger than /16, up to and including /14    Larger than /28, 
up to and including /24
X-Large    $16,000    Larger than /14, up to and including /12    Larger than 
/24, up to and including /20
XX-Large    $32,000    Larger than /12    Larger than /20


If your IPv4 ISP fits in a /22 or smaller, you can hand out /48s from a /32 for 
a very long time.
   (maximum 1024 customer end-sites with no addresses reserved for your own 
infrastructure, /32 = 65535 customer
       end sites after reserving a /48 for your infrastructure)
If your IPv4 ISP fits in a /20 or smaller, you can hand out /48s from a /32 for 
a pretty long time.
   (maximum 4096 customer end-sites with no addresses reserved for your own 
infrastructure, /32 = 65535 customer
       end sites after reserving a /48 for your infrastructure)
If your IPv4 ISP fits in a /18 or smaller, you can hand out /48s from a /32 for 
quite a while.
   (maximum 16,384 customer end-sites with no addresses reserved for your own 
infrastructure, /32 = 65535 customer
       end sites after reserving a /48 for your infrastructure).

At IPv6 /18 or smaller, you're in the same fee category as an IPv6 /32.

As you go up, the situation only gets better...

If your ISP uses an IPv4 /16, then you have a maximum of 65,536 customers with 
no allowance for infrastructure.
For free, you can get an IPv6 /28. This allows you 16,777,215 /48 end sites 
with a /48 reserved for your infrastructure.

If your ISP uses an IPv4 /14, then you have a maximum of 262,144 customers with 
no allowance for infrastructure.
For free, you can get an IPv6 /24 to support up to 268,435,455 /48 end sites 
after reserving a /48 for infrastructure.

Sure, Matthew is going to point out that my maximum IPv4 customer numbers 
assume you aren't doing CGN. That's true.
Let's assume you get a ratio of 64 customers per address using CGN (the real 
numbers are more like 8-16 customers
per address before stuff starts to degrade badly).

64 * 1024 = 65536 subscribers on a /22, assuming you have no infrastructure, no 
servers, and no customers that
   refuse to accept densely packed CGN. At this point, you can still hand out a 
/48 to every customer for all
   practical purposes if you have a /32 of IPv6.

Yes, the ultra-tiniest of ISPs will have to pay an extra $1,500 per year for 
their address space. Everybody else will
actually probably be able to pay less per year for address space once they can 
abandon IPv4, even if they give a /48
to every single end-site.

Owen

Reply via email to