[arin-ppml] IPv6 policy: ISP process?

[hostmaster at uneedus.com]

Sorry, not /32 but /56 max draw

Call it a brain fart.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Fri, 26 Jun 2026, hostmaster at uneedus.com wrote:

> 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.
>> 
>> 
> _______________________________________________
> 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://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>