Sort of, and sort of not right? Fiat allocation of a fixed resource, sure, but ISO does fiat allocation of OID space and it works because folks are free to grow as much as they want below it. As I recall one of the original 'next gen' IP proposals was like a huge address translation cloud, IPs were encapsulated in yet another layer which provided 'context' for the IP address inside. Basically every entity got their own 32 bit address space and ingress/egress to the Internet resulted in encapsulation and some additional router magic. One of the arguments against was the huge additional bandwidth cost. Of course we didn't realize at the time that few protocol changes could waste as much bandwidth as SPAM does.
The other challenge is that a functioning liquid market for IP addresses would most likely lead to speculation in IP address blocks. Worse is buying an address block from someone in Germany so that packets have to go to Germany first (top level static routing) to the router where they are re-allocated and then to their 'real' destination router. All very inefficient.
I, like other folks at Sun, was a big fan of a more modest 64 bit address proposal for V6, but alas it was not to be. That the conversion has taken as long as it has (and still isn't "here" nearly enough for a lot of users) really illustrates the dangers of the argument to 'permanently' fix things[1]. But innumeracy aside, the confounding issue is that IP addresses are 'structural' like telephone numbers and managing mobility of structural identifiers is always challenging (the cellular market deals with this all the time) so creating a truly liquid marketplace for these identifiers would ideally include fixing the structural issues which would allow the constraints to be fixed and thus eliminate the market.
Bottom line, it would have been great if folks had thought of that first, but they didn't and while future protocol developers can (and should) benefit from that experience, we're stuck with V4 address blocks that are stuck in various regions of the world.
[1] The most persuasive argument against 64 bit addresses was that this would only push the problem down the road, whereas 128 bit addresses fixed things once and for all.
If we're talking about advertisable blocks, the Germany scenario doesn't happen. For the time being, there can't be a liquid market for /32's, at least not one that works acros multiple ISPs.
I agree with you strongly that the 128 bit IP address is a huge design mistake, one that has unnecessarily retarded the deployment of IPv6 (I personally believe fatally so). Even in the '90s, a 64 bit number was still a scalar on most platforms you'd care about. And even in 2012, 128 bit numbers aren't. I think people drastically underestimate the amount of work it's going to take to upgrade the huge amount of software built on the assumption that you can store an IP address in a scalar.
> huge amount of software built on the assumption that you can store an IP address in a scalar
The truly huge universe of code is at the application level. Sane applications use strings for remote hosts, or work with URL's, and let library- or OS-level code deal with the details of turning that into an address.
OS'es -- even Windows -- have supported IPv6 for nearly a decade. Most networking libraries I've come across also have IPv6 support.
The main problem isn't software, it's configuration. Namely the configuration of the interface between the customer network and the ISP. The ISP doesn't want to turn on IPv6 because it might break some customers, and the customer can't test IPv6 functionality since their ISP doesn't support it.
These problems are compounded for residential ISP's, since most of their customers can't be bothered to learn anything technical.
That is nice to hear. My biggest problem with IPv6 has always been the size of the addresses, which I think is too big, but I always thought I was just being old-fashioned. It's interesting to see other people think the same, although probably for different or more justified reasons.
At the time it was really frustrating to hear people say "64 bits is just twice as big as it is now, that will never last" and I would say emphatically "No, that is FOUR BILLION times bigger!" and get hit with "Well what if every light switch in the world had its own IP address huh? huh?" and I would say "Yup, if that happened we MIGHT use up may 10 or 16 BILLIONTHS of the address space just for lights, the equivalent impact of dedicating a class B in the current address space to lights, which nobody would really think twice about."
Sort of, and sort of not right? Fiat allocation of a fixed resource, sure, but ISO does fiat allocation of OID space and it works because folks are free to grow as much as they want below it. As I recall one of the original 'next gen' IP proposals was like a huge address translation cloud, IPs were encapsulated in yet another layer which provided 'context' for the IP address inside. Basically every entity got their own 32 bit address space and ingress/egress to the Internet resulted in encapsulation and some additional router magic. One of the arguments against was the huge additional bandwidth cost. Of course we didn't realize at the time that few protocol changes could waste as much bandwidth as SPAM does.
The other challenge is that a functioning liquid market for IP addresses would most likely lead to speculation in IP address blocks. Worse is buying an address block from someone in Germany so that packets have to go to Germany first (top level static routing) to the router where they are re-allocated and then to their 'real' destination router. All very inefficient.
I, like other folks at Sun, was a big fan of a more modest 64 bit address proposal for V6, but alas it was not to be. That the conversion has taken as long as it has (and still isn't "here" nearly enough for a lot of users) really illustrates the dangers of the argument to 'permanently' fix things[1]. But innumeracy aside, the confounding issue is that IP addresses are 'structural' like telephone numbers and managing mobility of structural identifiers is always challenging (the cellular market deals with this all the time) so creating a truly liquid marketplace for these identifiers would ideally include fixing the structural issues which would allow the constraints to be fixed and thus eliminate the market.
Bottom line, it would have been great if folks had thought of that first, but they didn't and while future protocol developers can (and should) benefit from that experience, we're stuck with V4 address blocks that are stuck in various regions of the world.
[1] The most persuasive argument against 64 bit addresses was that this would only push the problem down the road, whereas 128 bit addresses fixed things once and for all.