Comment Re:Fuck IPv6 (Score 1) 305
To not make the IP addresses overly lengthy.
The size of the IPv6 address was chosen carefully. But you can never predict everything, and a few use-cases has shown up for more than 128 bits. But we'll just have to make do with the 128 bits we got, because nobody want to go through this entire upgrade process one more time.
So, why was it set at 128 bits in the first place? First of all, the address just like the IPv4 address consist of a network part and a host part. Due to the too short IPv4 address, the boundary between the two parts was first made variable at byte boundaries, and when that turned out to not be enough to avoid running out, the boundary was permitted to be at any bit. Even that was not enough to avoid running out. With IPv6 this mistake was not to be repeated. Hence each of the two parts had to be made large enough.
From IPv4 deployments we learned that 32 bits was not enough. In fact we have more or less removed the host part of the address (with lots of complications) and we have forced utilization way beyond the reasonable, and 32 bits is still not enough. 36 bits for the network part might be enough, if utilization was at 100%. However research has lead to the concept of an HD-ratio which indicate what percentage of the bits in an address can be effectively used when it need to have a hierarchical structure that can be utilized in routing. Research show that a reasonable HD ratio is in the range 80% to 90%. If we have 45 bits and 80% HD ratio, we have 36 bits effectively.
Instead of making the network part be 45 bits, which is an awful size for a computer to work with, it was rounded up to 64 bits. Those additional bits were put to reasonable use. In front of the 45 bits were put 3 bits which splits up the addresses in 8 blocks of which the first and last are used for addresses that need special handling in the protocols. The other 6 blocks are there such that we have 6 chances for getting the address allocation right in order to avoid running out again. After the 45 bits were put a group of 16 bits that can be used for subnetting within a site.
Some ISPs are so scared about those 45 bits running out that they have already now commandeered some or all of the 16 bits intended for subnetting within a site. This is most likely a reflex reaction caused by too many years of being forced to be extremely careful with allocation of IPv4 addresses. It is not like those 45 bits are going to be running out.
For the host part there was a desire to introduce auto configuration, which could generate the network part from a MAC address. If you also wanted to have room for addresses not generated from a MAC address, that mean the host part had to be at least 49 bits. This too was rounded up to 64 bits. Is it wasteful to round up from the 94 bits of documented need to 128 bits of actual address size? I'd say it would have been wasteful to require CPU time being spent on the bit operations needed to save a mere 34 bits on the size of the address.
Saving CPU time by rounding up the size of the addresses makes sense to me. Saving CPU time by eliminating needless fields from the header also makes sense to me. In fact three different 16 bit fields that routers would need to process when forwarding an IPv4 packet got removed such that routers no longer need to waste processing time on those on IPv6.
Why did it suddenly turn out that 128 bits was not quite enough? Once we got the chance to work with the much larger size of addresses, people suddenly realized, that it is possible to apply cryptographic operations to part of the IP address. With IPv4 that was unthinkable due to only having a total of 32 bits. But with the 128 bits cryptography suddenly came within reach. However cryptographic primitives with only 128 bits are considered to be on the weak side by now, and we can't even use the entire IPv6 address for cryptographic operations. So where cryptographic data in the IP address makes sense, we have to compromise on the security, but it still provides some benefit compared to not being able to do that cryptography in the first place.
This is not the only reason 128 bits is not quite enough. RFC 4193 defines a way to generate local prefixes with low risk of collisions, this is to replace RFC 1918 where collisions is a real problem. RFC 4193 leaves 16 bits for subnetting. But with RFC 1918 you could use 10.0.0.0/8 in which you had 24 bits and could realistically use up to 21 bits of that for subnetting. This is not to say RFC 4193 put you in a worse position than RFC 1918 did, but we are just 5 bits short of saying that it is unconditionally better.
Then you can look at protocols such as 6to4 and Teredo. 6to4 needed to embed an IPv4 address inside the network portion of the IPv6 address. That fits just fine. But due to deployments of NAT on IPv4, 6to4 is not usable on all IPv4 networks. Along came Teredo to solve that problem. Teredo however uses UDP and need to embed both IPv4 address and port number, and it need both client and server addresses to be embedded along with a few flag bits. In total that's 112 bits that you would want to embed inside the network part preferably with bits to spare for subnetting. So on top of the 112 bits you need a prefix on the order of 16 to 32 bits and 16 bits for subnetting, that's about 144 bits that need to fit inside the network portion of the IPv6 address.
That was obviously not possible. So first of all, Teredo used not just the network part of the address but also the host part. That means Teredo would not be suitable for connecting an entire network but only for single hosts. That means the bits for sunetting would also not be used. This was not quite enough to make all the embedded data fit inside the IPv6 address, so the server port number was hardcoded in the protocol such that it would not have to be embedded in the IPv6 address.
If only ISPs had deployed IPv6 in time, there wouldn't have been any need for contraptions like Teredo.