31–40 of 318 posts
I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.
(Also there's a DNS option in router advertisements now like subling comment said)
The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.
Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the sa…
35% worldwide by population of users in random samples at APNIC: https://stats.labs.apnic.net/ipv6/XA US on 50%, India on 70% and China just shy of 40% -As China continues to grow (and it will) the likely outcome is > 50% IPv6 Capable. I doubt any new Mobile deployment will be single stack, the most likely is pure IPv6 with CGN for 4. So Africa which is still in growth, the most likely outcome is dualstack preferring…
It doesn't matter if even 98% of "the internet" is "on" IPv6. If public websites don't advertise an IPv6 address, every user is still going to use IPv4 to connect to them. All the cloud providers still prioritize IPv4, and usually don't support IPv6 at all until a few years after a new service comes out.
IPv6 failed because they tried to boil the ocean. It was design by committee, where everyone got their pet feature thrown in to appease and gain consensus. Alternatively IPv4 is a mountain of small hacks, which is its biggest strength. We could have done a lot of good by adopting proposals to extend v4 like 0/8 and class D, but instead the decision was made to collectively drown the babies in the bathwater and insist…
Freeing up more IPv4 space wouldn't have helped. IANA was assigning /8 per month at the end. The extra space would have gone in less than a year. IPv6 would have worked better if they had made minimal changes to the support protocols. But it was have had slow adoption because there was no incentive to switch until addresses ran out.
You are confusing hoarding demand for legitimate need. The Amazon's and Cloudflare's of the world were playing games to get large allocations, speculators were spinning up hundreds of legal entities to get allocations, tons of backroom deals to look the other way.
Pretty much every use case today for IPv6 is environments where CGN would have worked just as well.
I wasn’t there (sounds like Apen was?) so I could be missing context, but I was under the impression that there were loads of layer 2 protocols at the time IP was designed (token ring, frame relay, etc) and so IP needed to be agnostic to the L2 protocol in order to be adopted.
Ugh. This is one of my favorite "what ifs" in the computer engineering. Things I would change: 1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense. 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. 4. Remove SLAAC…
> 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. I don’t even think it’s really ok. ARP was layered correctly: IPv4 runs on Ethernet+ARP. Or it can run on other things that aren’t Ethernet+ARP. IPv6 uses IPv6 messages to make itself work on Ethernet, thus baking knowledge of Ethernet into the IPv6 neighbor discovery logic. If multicast neighbor…
On one hand, V6 addresses are big enough to represent hardware addresses directly. So you don't _need_ a low-level protocol like ARP to resolve V6 addresses to hardware addresses, you can represent it as special messages in IPv6 itself.
It also allows some interesting tricks, like local network applications using interface addresses to communicate normally without setting up global connectivity.
On the other hand, interface addresses in V6 cause no end of confusion ("what the heck fe80::88a:fd34:d1b:2de7%en0 means?!?"). And V6 also has no clear distinction between the local network and the Internet, and the easy ability to use broadcasts (just send a packet to the network address).
And it's not like many applications actually use interface addresses anyway. So this is kinda a moot point.
Ugh. This is one of my favorite "what ifs" in the computer engineering. Things I would change: 1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense. 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. 4. Remove SLAAC…
This statement then implies that we would need to have NAT66. Why? Stateful DHCP then implies the possibility of an endpoint having only a single assigned address. But what if the endpoint needs to have multiple addresses such as tethering or running VMs? With SLAAC the endpoint can just get multiple addresses. Now, just because today stateful DHCPv6 is a possibility, hypervisors need to have NAT66 built in. So the status quo is strictly worse than either only SLAAC or only stateful DHCPv6.
The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.
Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the sa…
But even if that weren’t a thing, even if you did need all the routers to be replaced, “IPv4 with more bits” would still be better. After all, it’s been decades - the hardware has been replaced. If it were a seamless incremental upgrade, just a switch to flip that enabled “more bits support” and didn’t break anything, then ISPs would have enabled it even when there was little short-term benefit. By now, practically all of the Internet would support it. Instead it’s an entirely separate network, with entirely separate configuration, which historically had a high tendency to break things. No surprise that even today, many people just don’t bother with it.
I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.
Earlier quoted context omitted.
Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the sa…
Sure there’s a way. Define a standard way to encapsulate an “IPv4-with-more-bits” packet (let’s call it “IP+”) inside an IPv4 packet. When a router supporting IP+ forwards an IP+ packet to a router that doesn’t support it (assume there’s some way for routers to learn whether their peers support it), it wraps it in an IPv4 packet. When a router receives an IP+ packet wrapped in an IPv4 packet, in unwraps it. In this w…