This is based on the recommendations in https://datatracker.ietf.org/doc/html/rfc3177

A relevant snippet:

> This means that we feel comfortable about the prospect of allocating 178 billions /48 prefixes under that scheme before problems start to appear. To understand how big that number is, one has to compare 178 billion to 10 billion, which is the projected population on earth in year 2050

> The Ipv6 pool is quite vast. Yet I am a little surprised that an individual can receive a /48 without much trouble: that a lot of IPs.

A /48 is considered one "site" in current thinking. Since IPv6 subnets are /64, you have 16 bits between the /48 and the /64. This is the equivalent of using 10/8 for your network and using /24 IPv4 subnets: in both cases you can have upto 2^16 subnets.

The main difference being that a /24 can have ~250 hosts, but a /64 IPv6 subnet can hold the equivalent of four billion Internets (2^32 * 2^32).

But one of the selling points of IPv6 is reducing/eliminating the mental math about worrying about if you have "enough" addresses (and then carving things into /26, /30, etc).

IIRC /64s are ideally meant to address to individual subnets (the bottom 64 bits aren't intended for routing) so it's only really 64k addresses in the conventional sense.

/48 is actually a relatively standard allocation even for home connections, although /56 is more common.

Another point to consider is the IPv6 global routing table for internet routers. Suppose you decided to give end users /120s instead and those /120s were all routable on the internet. That means there are 120 bits of addressing just to find the network. There are 2^120 such networks in theory. If you could actually enumerate this, you'd be well on your way to bruteforcing AES128. In other words, this is just infeasible.

By handing out /48s the routing table stays manageable. This is the smallest address block you can announce via BGP for this reason.

Given the utter vastness of IPv6 we are also able to do things like carve out an entire /7, fc00::/7, for unique local addresses, and still tell people they shouldn't actually need these addresses at all.

As to the actual process of getting a PI block, I think it is likely to involve some questions. A similar objection exists to handing out smaller than /48s: more people having their own block implies more routing entries. Much better if an existing provider carves you a /48 out of their allocation and routes you traffic. This is probably balanced against the fact that by requiring you to deal with an existing LIR and set up BGP (and your LIR won't want you to muck that up) the number of people who will actually do this just for fun is limited.

I was surprised about that too. I got 1 static ipv4 Form my ISP and a /48 for IPv6. Not sure what to do with that, but still cool.

The IETF IPv6 allocation scheme was crazy from the start. The standard subnet size for autoconfiguration purposes is /64 = 18 Billion Trillion addresses. Of course reality is that autoconfiguration is only marginally useful and lots of things like servers and infrastructure links are statically assigned or assigned through dhcpv6. Most of the time I assign /112's to server subnets to limit the risk of IPv6 neighbor discovery attacks.

The standard /48 assignment size from ISP's to end-users was targeted mainly at stingy residential ISP's that were only assigning one IP per customer. They wanted any customer to have as many publicly routable subnets as they would ever need or want, but 65k is a lot of subnets. This was later updated to a default of /56 (256 subnets) but you could still get at /48 just for asking.

It got even weirder on RIR to ISP portable allocations. One of the original schemes would have RIR's allocating a "TLA" /16 (!) to only a few mega ISP's. Most ISP's/hosts would have to get their "NLA" address blocks from and be subservient to the 800 pound gorillas in the industry. https://www.rfc-editor.org/rfc/rfc2450.txt, https://www.rfc-editor.org/rfc/rfc2374

This was loosened somewhat in 2000 with RFC2928 which designated a "Sub-TLA" /29 as the initial ISP size. This would open it up to many more potential registrants, at least in theory. https://www.rfc-editor.org/rfc/rfc2928.html

The TLA/Sub-TLA/NLA system was abandoned in 2003 with RFC3587 after panic set in that nobody was deploying IPv6. https://www.rfc-editor.org/rfc/rfc3587.txt. ARIN had only made 30 Sub-TLA assignments by the end of 2002.

While RFC3587 wisely punted allocation policy to the RIR communities, the RIR's still had very restrictive policies inherited from RFC2450. Only around 2004 did they loosen to the point that ordinary networks could start requesting addresses. Google for example got their first IPv6 allocation in 2005. The problem is by then few networks were interested or just assumed they wouldn't qualify. When I got my first /32 in late 2004 there were less than 1000 routes in the global IPv6 table! Today there are ~135,000.

These more permissive rules only applied to ISP's/Hosts. End user orgs of any size were not allowed to start requesting portable /48's directly from RIR's until 2006 after much debate in RIR communities and vocal objections from IETF members and certain large ISP's.

Today router silicon and RIR policies have converged to a reasonably functional state. Too bad it took 20 years to get here or IPv6 might actually be on it's way to replacing IPV4. Instead that is still about 20 years away.

I have a /29, there's a lot of IPv6.