[arin-ppml] IPv6 policy: ISP process?

[hostmaster at uneedus.com]

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 (ARIN-PPML at arin.net).
>> 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 info at arin.net if you experience any issues.
>
>