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, [email protected] 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 ([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.
_______________________________________________
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.
