Dual stack IPv6 for IPv4 depletion

Mel Beckman mel at beckman.org
Fri Jul 10 17:35:42 UTC 2015


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 <owen at delong.com<mailto:owen at delong.com>> wrote:


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



On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks at vt.edu<mailto:Valdis.Kletnieks at 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




More information about the NANOG mailing list