[182121] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Mel Beckman)
Fri Jul 10 13:35:47 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Owen DeLong <owen@delong.com>
Date: Fri, 10 Jul 2015 17:35:42 +0000
In-Reply-To: <54BB131F-1B64-41A9-B300-F464838EA710@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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 the=
ir first /23 earlier this year, and I convinced them they should deploy IPv=
6 along with IPv4 in their new PoP. It would cost nothing, I argued, as the=
y 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. Howeve=
r, ARIN refused the request. Here's the dialog:
ISP Requests a /40 IPv6 allocation to go along with xx-small /23 IPv4 alloc=
ation already issued.
ARIN: The minimum size ARIN may allocate to an ISP is a /36, as stated by p=
olicy. https://www.arin.net/policy/nrpm.html#six52 Would you like us to pro=
ceed 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-sma=
ll category?
ARIN: Yes. The /36 prefix is the smallest size ARIN is permitted to allocat=
e to ISPs according to community-created policy. https://www.arin.net/polic=
y/nrpm.html#six52
ISP: OK thanks for the info. We are going to revisit deployment plans for I=
PV6 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 al=
location 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 reque=
st. I have seen your feedback about the fee page, and will request it be up=
dated 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 a=
s a community lost the opportunity to get a new ISP off on the right foot b=
y going dual-stacked. This is not good for IPv6 adoption. Hopefully ARIN re=
ads this and addresses the issue - either correct the table or honor xx-sma=
ll requests for a /40.
-mel beckman
On Jul 10, 2015, at 9:53 AM, Owen DeLong <owen@delong.com<mailto:owen@delon=
g.com>> wrote:
On Jul 10, 2015, at 03:57 , Matthew Kaufman <matthew@matthew.at<mailto:matt=
hew@matthew.at>> wrote:
On Jul 9, 2015, at 11:53 PM, Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletniek=
s@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 sca=
le, I might add)
You want ISPs to start with /20s? I'll support that over on PPML if you pro=
pose 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 tha=
n /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 th=
an /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 =3D 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 =3D 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 o=
wn infrastructure, /32 =3D 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 w=
ith 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 site=
s after reserving a /48 for infrastructure.
Sure, Matthew is going to point out that my maximum IPv4 customer numbers a=
ssume you aren't doing CGN. That's true.
Let's assume you get a ratio of 64 customers per address using CGN (the rea=
l numbers are more like 8-16 customers
per address before stuff starts to degrade badly).
64 * 1024 =3D 65536 subscribers on a /22, assuming you have no infrastructu=
re, no servers, and no customers that
refuse to accept densely packed CGN. At this point, you can still hand o=
ut 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 fo=
r 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
