Earlier quoted context omitted.
For every problem there is a solution which is simple, easy and wrong.
Also a complex, difficult and wrong.
And "just add a byte(s) to address field" manages to be all of those at the same time
The mistakes and missed opportunities in the design of IPv6
31–40 of 73 posts
Re: The mistakes and missed opportunities in the design of IPv6
#32Earlier quoted context omitted.
Having several IPv4 addresses per physical interface is a bit of an extension. It is called IP aliasing in Linux and it wasn't always there.
Since when is it there? Because i had interfaces with both v4 link-local and DHCPv4 addresses since i can remember.
The early 90s. I remember a time when you got one address, and found out they could have multiple. It was like black magic.
Re: The mistakes and missed opportunities in the design of IPv6
#33Earlier quoted context omitted.
You could add 12 bytes to the address, such an protocol already exists and is in widespread use.
I just don't think IPv6 addresses are human readable compared to IPv4 addresses. I know DNS makes that a non issue for the majority of users but I still think it's an important quality for people in charge of maintaining networks and stuff.
> I just don't think IPv6 addresses are human readable compared to IPv4 addresses
Then you just didn't read enough into IPv6 documentation yet. IPv6 addresses can be short if you want because of the `::` operator.
Example: Instead of IPv4 where you'd have the addresses `10.0.0.2` - `10.0.0.100` for clients on your LAN + a single global IPv4 address, you just have `2001:db8::2` - `2001:db8::100` (where `2001:db8` is the "house address" part of your LAN and `2-100` is the specific device address)
Re: The mistakes and missed opportunities in the design of IPv6
#34Why couldn't we have just added another byte to IPv4 addresses and called it a day? Hell add two bytes.
Because that would have been just as a breaking change as IPv6, but fixes a lot fewer problems than IPv6 does.
I'm not an expert in networking but every time I've had to deal with dual stack it feels like IPv6 introduced a bunch of problems.
Re: The mistakes and missed opportunities in the design of IPv6
#35IPv6 has not "failed". I use it daily to do my networking, both at home and on the public Internet. The author's take is weird at best.
would you say it's been a success then?
Re: The mistakes and missed opportunities in the design of IPv6
#36I was at the Toronto IETF meeting in 1994(?) when they voted on 8-byte vs 16-byte addresses.
I share the author's suspicion that 8-byte addresses would have made a world of difference in IPv6 adoption. It's hard to understand nowadays just how slow many networks were back then - 28.8kb/s dialup modems were introduced in 1994, and 56k wasn't available until 1997 or 1998. Two 16-byte addresses take 9ms to transmit at that speed.
Re: The mistakes and missed opportunities in the design of IPv6
#37I kinda agree with the arcticle. Here is my ideal IPv6: http://borg.uu3.net/~borg/?ipv6 It basically means, you grab IPv4 implementation, extend address space to 64bit, call it IPv6, vioala. Problem solved. IPv4 was battle proven for years. It mistakes were sorted out (CIDR addressing, ARP poisoning, DHCP/BOOTP, etc). It was widely understood. NAT is okey, CGNAT is not. The only problem was the address space. And the…
Yeah, Dan Bernstein explained a long time ago how they were doing it wrong.[1] That's not dated, but it must have been 20 years ago that I first read it. In short, by making it a separate, incompatible protocol, they created a situation where no one had an incentive (other than curiosity) to implement it on clients, servers, or in between, until everyone else did. There were better options.
Re: The mistakes and missed opportunities in the design of IPv6
#38>Stuck with 64-bit addresses
Nail on head. This is obvious not only in retrospect, but also to anyone just learning networking. We somehow expected the entire planet to become the death star with every blinking LED having a unique address.
Re: The mistakes and missed opportunities in the design of IPv6
#39Earlier quoted context omitted.
The syntax of the address? MAC addresses seem to thrive, both in Ethernet and Bluetooth. Sure, it's only 48 bits, but it's a bunch of hexadecimal digits with colons. IPv6 failed because (1) it demanded too much of the networking hardware, (2) was a stupidly complex beast compared to IPv4 and (3) had the catch-22 of requiring both producers and consumers to upgrade at the same time to even make it usable, let alone wi…
I don't think that it can be argued that IPv6 was complex and demanded more from the networking hardware. On the contrary, the IPv6 headers have been explicitly simplified a lot in comparison with IPv4. The increased complexity for the networking hardware has come only from the requirement of supporting both IPv4 and IPv6, instead of only one of them. In my opinion, the most significant mistake of IPv6 has been that…
> In my opinion, the most significant mistake of IPv6 has been that the IPv4 address space has not been considered a subset of the IPv6 address space.
This suggestion has gotten brought up often over the past few decades.
Remember that every IP packet has a destination and source address. There is no physical way for a v4-only host to directly communicate with another host which has an address from a larger address space. Doing so requires NAT. Which can be and is used today for v4-v6 connectivity.
Re: The mistakes and missed opportunities in the design of IPv6
#40> IPv6 chose to have addresses on the interface connecting to the network instead of having addresses on the node. In contrast to IPv4, IPv6 supports multiple addresses on an interface, where each of the address has different properties. IP Addresses were always interface-bound. And you always could have multiple addresse on the same interface. Your IPv4 loopback device has 2^24 addresses bound to it right in this mo…
PING 127.12.34.56 (127.12.34.56): 56 data bytes
Request timeout for icmp_seq 0
There's also ip unnumbered where an interface can reuse ip from one interface (typically from loopback) on other interfaces.