I sit back and look at the allocation policies of some of the largest
cable ISPs, and see them drawing v6 amounts based upon giving each
customer a /48, but actually limiting the customer draw from their servers
to a /32 max, and in actual reality 90% or more of the customers that draw
a v6 network are actually only using a /64 of space. Those customers with
older equipment or not using the ISP provided devices generally are not
getting or using any IPv6 space at all. Thus, it should be a long time
before these large networks come back for more space.
If the current allocation method is outgrown, rather than giving them 2
blocks, we instead should give them a larger block to move into, and with
a bit of expansion built in, and a period of time (say one year) to move
out of their original smaller block. In v6, it should be rare for an
operator to have more than one v6 block. Of course, giving most
requesters a block sise that is big enough and never requires any
expansion would be the best policy.
I think that a automatic /32 for those ISP's allocating space to
customers, and a /48 for those running their own networks should be the
default, and they should not have to provide data unless they feel they
need to exceed these levels during their expansion plans.
I would also like to see the original IPv6 automatic multihome issue
solved in standard industry routers and hosts as well, as this would
reduce the need for smaller networks to have to come to ARIN simply
because they want to be able to have more than one IPv6 provider for
redundancy.
The original idea was that I could subscribe to 2 or more providers to
obtain the desired amount of bandwidth. Each device on my network would
have a v6 address from each available network, and could decide routing
based on the speed of each available network. Both SLAAC and V6DHCP
support having more than one network address on a host, but the failure
modes when one or more of these networks have a failure have never been
properly addressed. This idea was supposed to be an advantage of v6, but
it never really worked in actual practice. Also, because of the greater
number of addresses, use of hacks like NAT should no longer need to be
used at all, bringing the internet back to its original peer to peer
model.
If this routing problem could be solved, it would reduce the need for a
lot of networks to even come to ARIN for space for multihome IPv6, often
using private LAN addresses like in IPv4. Instead, the hosts would simply
use the public v6 space of each of their upstreams on each of their hosts,
even if they use more than one provider. Kinda like automatic multihome
for all with more than one v6 network available.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Thu, 25 Jun 2026, John W. O'Brien wrote:
There should be a quantity of IPv6 address space that a small and/or new
operator can obtain with as little paperwork as possible (automatic grant =
good, network plan + technical justification = bad). We want operators to
deploy IPv6, so we want it to be simple to obtain the address space necessary
to do that. The abundance of address space makes this possible and
reasonable.
Since the the size and sophistication of organizations requesting an initial
allocation probably approximates a power law---because of course it
would---what prefix length would be appropriate to meet the 80% level?
The world has already agreed on a lower bound of /48. The status quo is /32.
I'll go out on a limb and say that A) those are the best options, and B) a
/48 is too small. The next best alternatives in descending order of
preference are /40, /36, and /44.
The status quo seems pretty reasonable to me.
On 2026-06-25 16:51, William Herrin wrote:
Howdy,
I didn't see any feedback on the draft policy rewriting section 6.5,
so I want to step back and solicit your opinions on what ARIN's IPv6
policies should become. I'm going to ask some questions and break them
into separate message threads so that they can be followed separately
according to your interest.
The question for this thread is: Do you like ARIN's current IPv6
allocation _process_ for ISPs or would you prefer to see it change? I
specifically mean the process ARIN has implemented, not the policy
text which is a mess.
Roughly speaking, ARIN's current process for granting IPv6 addresses
to ISPs works like this:
/32? Granted.
More than a /32? Count your customers and sites, then consult the
charts on page 3 of
https://urldefense.com/v3/__https://www.arin.net/reference/training/resources/ipv6_networkplan.pdf__;!!IBzWLUs!Va175o4FFdcX9FiwJ7TBdDpWdR1YG12q-gDp48rUT7HSKTnBV158n5lshMROOlEJ-bqdAQqxvNOAong$
. Same or longer CIDR netmask? Granted.
Still more? Write a network plan and offer a technical justification
why you need so much IPv6 space.
Draft 2026-2 changes the above so that every ISP writes a network plan
with a technical justification for the number of IPv6 addresses
requested, including a /32. No automatic /32 grant. No "count your
customers and sites" grant.
Do you like either approach? Can you describe a third approach you'd
like better? Your views are respectfully requested.
Regards,
Bill Herrin
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://urldefense.com/v3/__https://lists.arin.net/mailman/listinfo/arin-ppml__;!!IBzWLUs!Va175o4FFdcX9FiwJ7TBdDpWdR1YG12q-gDp48rUT7HSKTnBV158n5lshMROOlEJ-bqdAQqxFXYKmJA$
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
