> 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
~So that's a maximum average 17.8 IPs per person? Seems awfully low, considering people these days have multiple devices connected to the Internet at any given time: phone, watch, tablet, laptop(s), perhaps desktop(s), security cameras, IP phones, refrigerators, washing machines, TVs, video game consoles, I could go on...~
Edit: oh, wow I misread that completely. It's 17.8 /48 ranges per person on average. Yep, that should be enough for quite a while.
> 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).
> A /48 is considered one "site" in current thinking.
This is the really important part. As they continue to hand out IPv6 like candy, the minimum prefix length will get shorter.
No ISP wants a hundred million+ routes in their routing table, so people will start to drop anything shorter than a /42, /40, /38, etc. until the table gets small enough and shunt everyone elses traffic off to Hurricane Electric or the like as a default route.
People have this mindset of "we added a bunch of zeros, its an infinite resource now!" which is how we ended up in this mess to start with.
What is your basis for this opinion? Network operators are already talking about it.
> Too late. IPv4 are set to hit 1024K (2^20) in January 2024 at current trends
Allow me to expand that number for you: 1,048,576
One million. A reasonable upper bound for max announced v4 prefixes is somewhere around two million. You can handle that in a few GB of RAM. IPv6 could see 100x or 1000x that number based on how we are handling allocations, at which point prefix trimming will happen.
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.
This was key to me understanding IPv6 - you don't really do variable length subnets. You just get a /48 and break that up into /64's. Because the space is so vast, you can do inefficient things with no chance of running into allocation issues like v4 and you don't have to mentally try and subnet a 128 bit address which maybe some can handle but hurts my head.
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.
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.
