Is anyone else shocked at the low level of adoption of IPv6? I remember how in the late 90s people were saying we were going to run out of addresses and everyone need to migrate to IPv6 ASAP. Now, it seems that IPv4 is going to be around for a long while.
The world in which IPv6 was a good design
131–140 of 199 posts
Re: The world in which IPv6 was a good design
#132>In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:44:55:66, and finally generate a packet with destination ethernet address 11:22:33:44:55:66 and destination IP address 10.1.1.1. 192.168.1.1 is just a pointless intermediate step. This is completely wrong, it's not pointless. First, this can be used to easily s…
> This is completely wrong, it's not pointless. Pretty reliable rule of software is: if you think it's pointless you probably don't understand it well enough.
I disagree. Over-engineering is epidemic in modern software.
That being said: in this specific case you're right.
Re: The world in which IPv6 was a good design
#133>They have to be special, because an IP node has to be able to transmit them before it has an IP address, which is of course impossible, so it just fills the IP headers with essentially nonsense Not nonsense! The global IP broadcast is specified as 255.255.255.255 and is used by other protocols. The source IP address for the initial discovery is indeed 0.0.0.0, which is not intuitive, but the rest of the DHCP exchang…
I think the author did a great job of explaining why DHCP feels like a gross hack, because it crosses that boundary.
You say
> No, it's not an ethernet protocol
I mean, obviously it's not, by definition, but let me ask -- why does it have a hardware address in the protocol? Is it maybe because this protocol, like ARP, is a bridge between the layers, and thus this protocol shares more in common with ARP than with IP?
RARP did not allow a lot of the things that DHCP did, but DHCP can be done in an address-aware mode as well (and BOOTP was much more bare-bones than DHCP, and that's closer to contemporaneous with RARP. All you have with BOOTP is the ability to cross broadcast domains, which are themselves a fiction anyway, as the author points out). If we let RARP do the IP assignment, then DHCP can be used to transmit configuration information to the newly assigned host very easily, and it would allow us to cut out the hardware-addressing aspect of DHCP.
Re: The world in which IPv6 was a good design
#134Earlier quoted context omitted.
Drop the idea of ports too. Every program gets its own IP Mentioning ideas like that at work get queer looks about how it'd be impossible to configure a firewall at that point But keep going further. End up with 128 bit CPU where every byte is IP addressable. Necessary security to block random outsiders from reading your memory, but capable of potentially running various parts remotely transparently
With NAT, this has essentially already happened. You could say IPv4 is actually 48-bit addressing, at least on the client side. For all useful purposes, NAT expanded every /24 or even /32 subnet by an extra 16 bits, which is the real reason we still haven't run out of IPv4 addresses. That could be extended to the server side if we used something like SRV records instead of defaulting to port 80/443.
Maybe it's early and I've not drank enough coffee yet, but what benefit would this provide? You'll be in effect doubling the DNS lookups needed to connect to a website adding latency to time to first byte, with seemingly zero benefit.
Re: The world in which IPv6 was a good design
#135One big UX mistake of IPv6: it was not made backward compatible with IPv4. (v6)0.0.192.168.1.10 == 192.168.1.10(v4). This simple design when planning and rolling it out would have meant incrementally updating the networking stack to also support v6. Now it turns out v4 and v6 are completely different, and no one has a big enough reason to make the change until everyone else makes the change. Hard chicken-egg problem.
> One big UX mistake of IPv6: it was not made backward compatible with IPv4.
The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space -- it is not IPv6's fault.
Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't drop IP options, adding "v6" address space via IP option in a packet that old/v4-only devices would nevertheless attempt to parse would have been hell operationally.
granted, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.) that mostly only look good through the rose-tinted glasses of the 90s and significantly slowed down deployment -- and in the end mostly ended up as "difference for difference's sake", but that the transition is difficult is also IPv4's fault for not having a robust address space expansion mechanism.
Re: The world in which IPv6 was a good design
#136> In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:44:55:66, and finally generate a packet with destination ethernet address 11:22:33:44:55:66 and destination IP address 10.1.1.1. 192.168.1.1 is just a pointless intermediate step.
Bollocks. The abstraction allowed by using an IP address instead of a MAC address is essential, considering that IP addresses are dynamic (even when statically configures, devices can and do get replaced) and MAC adresses are set at the factory. Can you imagine updating the routing table of every device in your network because you had to replace a core router and the MAC address was different? It’s the equivalent of publishing your website on an IP address instead of a DNS hostname...
* yes, I know MAC addresses can be configured by software in many devices, but that’s even more of a hack than using arp to determine a MAC address.
Re: The world in which IPv6 was a good design
#137One big UX mistake of IPv6: it was not made backward compatible with IPv4. (v6)0.0.192.168.1.10 == 192.168.1.10(v4). This simple design when planning and rolling it out would have meant incrementally updating the networking stack to also support v6. Now it turns out v4 and v6 are completely different, and no one has a big enough reason to make the change until everyone else makes the change. Hard chicken-egg problem.
Backwards compatibility can not work. You can not answer an IPv6 packet with IPv4. There is no room in the header for the much bigger source/return address. You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol). The IPv6 version is called DNS64/NAT64, and it breaks even more things, e.g. DNSSEC. Because it not only requires network address trans…
> You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol).
That’s demonstrably untrue. Sure p2p protocols and NAT devices need to account for NAT, but to imply that they’re impossible to use with NAT is just silly. Many p2p protocols work via NAT all the time...
Re: The world in which IPv6 was a good design
#138This was a very informative article for me, but there was one thing I didn't understand. At the end he made the case that mobile routing needed essentially two layers: a fixed per-device (or per session) identifier, and then a separate routing-layer address that could change as a device moved. QUIC has session identifiers, and that's great and could solve the problem.
But earlier in that very article, he already pointed out that every device already has a globally unique identifier used in layer 2 routing ... the ethernet MAC address.
Would someone please explain to me why we can't use MAC addresses as globally unique device IDs?
(Is MAC spoofing the issue?)
Re: The world in which IPv6 was a good design
#139> Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that. Actually, no. You can only set an IP address with RARP, not even a netmask (RARP comes from pre-CIDR age) or other important stuff like default gateway, DNS server, etc like you can with DHCP.
Right, but those are all things we are not talking about here, so RARP worked just fine.
Re: The world in which IPv6 was a good design
#140Earlier quoted context omitted.
Backwards compatibility can not work. You can not answer an IPv6 packet with IPv4. There is no room in the header for the much bigger source/return address. You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol). The IPv6 version is called DNS64/NAT64, and it breaks even more things, e.g. DNSSEC. Because it not only requires network address trans…
> You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol). That’s demonstrably untrue. Sure p2p protocols and NAT devices need to account for NAT, but to imply that they’re impossible to use with NAT is just silly. Many p2p protocols work via NAT all the time...
Sure, you can add another layer of hacks like UPnP or NAT-PMP to work around the breakage a bit. Or try to use side effects like NAT boxes waiting UDP responses when they forward such a packet. And you can spend the rest of day telling yourself this is totally fine, because it works most of the times.
Or could step back and see that this a terminally ill protocol on life support.