I can see that, but surely there wouldn’t be much difference matching the first 4bits (0x2XXX, 0xfXXX) vs the first 16 (0x0001)?
0:: is presumably all for loopback-type stuff, but I don’t see a reason not to use 1:: through 1fff:: and they would be much easier to type/remember/validate for public DNS servers which are needed before name resolution is available.
IPv6 is big enough to give 10 billion unique addresses for every grain of sand on earth and still have some left over. Just in case we need to, I guess.
It’s great that the address space is so large. When designing a new system, you want to make sure it’ll hopefully never encounter the same issue as the old system, to ensure you don’t have to migrate yet again.
Sure. But the IPv6 implementation is a bit like if we went “you know the y2038 problem of 32 bit numbers, and how goin under 1970 is sometimes hard? Lets solve it by making it start from the big bang and store time as a 256 bit integer so we don’t run out until year 3.1 x 10^69”.
IPv6 is big enough for 340,282,366,920,938,463,463,374,607,431,768,211,456 unique addresses. Are we expecting to create an universe consuming army of exponentially replicating paper clip converting robots that each need an IPv6 address or something?
Having a large range has a number of benefits though. Companies that have dozens of IPv4 ranges may be fine with a single IPv6 range, which simplifies routing rules.
A lot of features in IPv6 take advantage of the fact that networks have at least a /64 range (at least if they’re built correctly according to RFC4291 and newer specs). SLAAC is a major one: Devices can auto-configure IP addresses without having to use something like a stateful DHCP server.
Address space is so huge that iirc the only global addresses in use are 2xxx::
Its so huge that it’s not needed to use anything else is the goal as far as I see. If it starts with 2, it’s global.
Also for routing table reasons. Ipv6 needs to use prefixes to do link aggregation or it just gets too bjg
I can see that, but surely there wouldn’t be much difference matching the first 4bits (0x2XXX, 0xfXXX) vs the first 16 (0x0001)?
0:: is presumably all for loopback-type stuff, but I don’t see a reason not to use 1:: through 1fff:: and they would be much easier to type/remember/validate for public DNS servers which are needed before name resolution is available.
Not sure on the history of that. It would make things like that easier
IPv6 is big enough to give 10 billion unique addresses for every grain of sand on earth and still have some left over. Just in case we need to, I guess.
It’s great that the address space is so large. When designing a new system, you want to make sure it’ll hopefully never encounter the same issue as the old system, to ensure you don’t have to migrate yet again.
Sure. But the IPv6 implementation is a bit like if we went “you know the y2038 problem of 32 bit numbers, and how goin under 1970 is sometimes hard? Lets solve it by making it start from the big bang and store time as a 256 bit integer so we don’t run out until year 3.1 x 10^69”.
IPv6 is big enough for 340,282,366,920,938,463,463,374,607,431,768,211,456 unique addresses. Are we expecting to create an universe consuming army of exponentially replicating paper clip converting robots that each need an IPv6 address or something?
Having a large range has a number of benefits though. Companies that have dozens of IPv4 ranges may be fine with a single IPv6 range, which simplifies routing rules.
A lot of features in IPv6 take advantage of the fact that networks have at least a /64 range (at least if they’re built correctly according to RFC4291 and newer specs). SLAAC is a major one: Devices can auto-configure IP addresses without having to use something like a stateful DHCP server.
Why start at 0x2001 though? Why not 0x0001? Then we could have addresses like 1:1:1::1 or 1:2:3::4.