I read at several places that ISPs should allocate a /48 (or /56) IPv6 addresses blocks to end users

Wikipedia for instance

The RIRs assign smaller blocks to local Internet registries that distributes them to users. These are typically in sizes from /19 to /32.
The addresses are typically distributed in /48 to /56 sized blocks to the end users.

But I don't see how that could work for, say, an ISP having a /32 block. Allocating /48 blocks to end users would limit them to 64k customers...

But even with a /19, why would an ISP allocate /48s to all end users ; will the grand mother browsing her slow Windows XP really create 65000 networks?

There are a lot of IPs, but why waste them?

4 Answers 4


Basically, because we don't want to make the same mistakes we made with IPv4. Just because we don't know why would need more IP addresses at this moment, doesn't mean there won't be a use case in the future.

Providing every connection with more than enough publicly reachable IP addresses can be an enabler for new services and devices.

  • 1
    Oh, we're repeating many of the mistakes of IPv4, but v6 is large enough we're not going to run out of Pez for at least a generation. (low v6 adoption rate helps.) And it's not like ISPs can't change the allocation size overnight. In general, only enterprise connections get static allocations. All my "business class" (consumer) connections are DHCPv6-PD -- as long as my DUID doesn't change, my block doesn't change. (none of my true $$$$ enterprise connections even support v6 -- lame ISPs)
    – Ricky
    Commented Aug 3, 2021 at 15:35

There are a lot of IPs, but why waste them?

Because that's "IPv4 thinking". IPv6 is "infinite". (it isn't, and we're mismanaging 2000::/3 just as badly as we did the initial classful IPv4 internet. But I digress...)

ISP's can get more address blocks when their initial /32 is full. Most ISP's hand out /56's to home users. (some even /60's, or a single /64 if you don't ask for anything larger) /48 is usually reserved to business customers with larger operations.

(My favorite dead horse is Earthlink. They have dozens of IPv6 blocks. Yet they're not announcing a single one of them. Never have.)

  • IPv6 is a vastly larger address space. It's (currently?) hard to fathom on a human scale, so inefficient use is to be expected. At the current rate we're carving up 2000::/3, it will be a decade or more before a different mindset will be needed. The common rhetoric is that we have plenty more /3's for do-overs. (that's another lesson for IPv4 not learned.)
    – Ricky
    Commented Aug 3, 2021 at 15:30
  • The only reason I'm not terribly worried about this is that if we run out of 2000::/3 there are still 7 other /3's and if needed we could also split them up into a /4 or /5... we could even take a /32 for the whole internet and still have 18 quadrillion IPv4 internets left (but without SLAAC support) and if we screw that one up we'd have 4 billion of the 18-quadrillion-internet-sized blocks left over... etc Commented Aug 5, 2021 at 9:44

In the RIPE region you get a /29 by default (and if you have a /32 allocation from RIPE just ask RIPE to extend that, no need to renumber, reservations where made with room to grow in mind). This brings you to about 500k users.

Regarding your prefix size: The /29 is the default. If you can justify the need for a larger prefix you will get a larger prefix. And as there is a a BCOP (Best Current Operational Practice) guide, written by some people of the RIPE community, about which prefix size you should hand out to your customer (https://www.ripe.net/publications/docs/ripe-690) "I want to assign /48 to end users" should be a valid justification.

This will all be different outside of the RIPE region so please check you RIRs assignment policy. And if your not happy with your RIRs policy get involved.

And BTW: At least in Germany most end user provides will give you a dynamic /56 (via DHCP-PD), at least one cable ISP is giving you a /64 or /62 and some will give you no IPv6 at all.


say, an ISP having a /32 block. Allocating /48 blocks to end users would limit them to 64k customers...

64K business customers - which is a lot. If they'd use two blocks - one for businesses with /48, one for individuals with /56 - they could have 16 million of the latter.

But even with a /19, why would an ISP allocate /48s to all end users

Individual end users are usually allocated /56, so that would be 2^(56-19)≈137 billion allocations/end users. 32 times the entire v4 address space. (Or 537 million /48 businesses.)

will the grand mother browsing her slow Windows XP really create 65000 networks

She'd likely get a /56 with 'just' 4.7 sextillion individual addresses.

Note that IPv6 does not allow NAT, so any network/device you connect to the Internet must use an address from your allocation.

  • IPv6 was designed to not have NAT. But idiots later bolted on a few forms of NAT. (It hasn't reached the level of insanity of IPv4 NATP. Yet.)
    – Ricky
    Commented Aug 3, 2021 at 17:13
  • "Note that IPv6 does not allow NAT" so you mean the grandmother will run out of addresses? :)
    – Déjà vu
    Commented Aug 3, 2021 at 17:26
  • @Ricky some ISPs allocate /128s ... sad, but true. At least they can "NAT" it...
    – Déjà vu
    Commented Aug 3, 2021 at 17:53
  • /128's would be for p-t-p interfaces (PPP) or single end devices (cellphone). Routers with networks behind them rarely will be given a /128, but yes, a few ISPs will set the ISP-network side to a /128, and wait for the CPE to ask for a PD for any LAN(s). (efficient, but unnecessary.)
    – Ricky
    Commented Aug 3, 2021 at 20:28
  • @Breakingnotsobad The great thing about SLAAC is that it forces them to give you at least a /64, the annoying thing is it forces you to use up a /64 from that /64 you were given, unless you like setting up a lot more stuff. Commented Aug 5, 2021 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.