Iljitsch van Beijnum writes: > So how big would you like addresses to be, then? It's not how big they are, it's how they are allocated. And they are allocated very poorly, even recklessly, which is why they run out so quickly. It's true that engineers always underestimate required capacity, but 128-bit addresses would be enough for anything ... IF they were fully allocated. But I know they won't be, and so the address space will be exhausted soon enough. > We currently have 1/8th of the IPv6 address space set aside for > global unicast purposes ... Do you know how many addresses that is? One eighth of 128 bits is a 125-bit address space, or 42,535,295,865,117,307,932,921,825,928,971,026,432 addresses. That's enough to assign 735 IP addresses to every cubic centimetre in the currently observable universe (yes, I calculated it). Am I the only person who sees the absurdity of wasting addresses this way? It doesn't matter how many bits you put in an address, if you assign them this carelessly. > ... with the idea that ISPs give their customers /48 blocks. Thank you for illustrating the classic engineer's mistake. Stop thinking in terms of _bits_, and think in terms of the _actual number of addresses_ available. Of better still, start thinking in terms of the _number of addresses you throw away_ each time you set aside entire bit spans in the address for any predetermined purpose. Remember, trying to encode information in the address (which is what you are doing when you reserve bit spans) results in exponential (read incomprehensibly huge) reductions in the number of available addresses. It's trivially easy to exhaust the entire address space this way. If you want exponential capacity from an address space, you have to assign the addresses consecutively and serially out of that address space. You cannot encode information in the address. You cannot divided the address in a linear way based on the bits it contains and still claim to have the benefits of the exponential number of addresses for which it supposedly provides. Why is this so difficult for people to understand? > That gives us 45 bits worth of address space to use up. You're doing it again. It's not 45 bits; it's a factor of 35,184,372,088,832. But rest assured, they'll be gone in the blink of an eye if the address space continues to be mismanaged in this way. > It's generally accepted that an HD ratio of 80% should be reachable > without trouble, which means we get to waste 20% of those bits in > aggregation hierarchies. No. It's not 20% of the bits, it's 99.9756% of your address space that you are wasting. Do engineers really study math? > This gives us 36 bits = 68 billion /48s. That's several per person > inhabiting the earth, and each of those / 48s provides 65536 subnets > that have room to address every MAC address ever assigned without > breaking a sweat. What happens when MAC addresses go away? How are you providing for the future when you allocate address space based on the past? Why not just leave the address space alone, and allocate only the minimum slice required to handle current requirements? That's another problem of engineers: they think they can predict the future, and they are almost always wrong. > What was the problem again? And that's the third problem. Remember also: any encoding of information into the address field (including anything that facilitates routing) exponentially reduces the total number of available addresses. So it might look like 2^128 addresses, but in reality it may be 2^40, or some other very small number, depending on how much information you try to encode into the address. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf