411–420 of 519 posts
Earlier quoted context omitted.
IT and telecom tend to have an ultra conservative if it’s not broke don’t fix it attitude. It won’t get deployed until enough customers ask for it or it’s required for something important.
That's because they actually get paid for providing a reliable service, not for ipv6.
Earlier quoted context omitted.
You can add bits to your own systems fine. When you want your packets to work on other people's routers, it stops being fine.
If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.
Short answer: Too many cooks in the kitchen, and too many of 'em motivated to make it more complicated. A computer standard that is still widely avoided almost 30 years after it became official is a computer standard that should have been tossed in the bin before the ink was dry.
Earlier quoted context omitted.
ARP and DHCP really look really dirty whenever I look at them. Like pretty bad designs overall. From more neutral viewpoint it feels that whole stack would be better with something else than these clear hacks.
arp simply breaks down in very large networks aswell. Think about things like the following: you are a datacenter and are providing connectivity to the internet for your customers. Each customer get a vlan with a specific ip prefix attached to it. You prove the gateway for each customers subnet. ARP crosses the L2 vs L3 boundary to do succesful address resolution. The problem this creates in large (mainly datacenter)…
It’s not. It’s IPv4 with more bits and some changes to Ethernet level lookup. The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.
The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc. I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily p…
Earlier quoted context omitted.
I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Neither NAT64 or NAT46 do this really, and they're presented as alternatives rather than the native way. The closest was 6to4. rfc6343 goes into why that got deprecated. You'd either have "router 6to4" which required additional se…
You can do this quite easily on all the major OSes by opening a single dual-stack socket. On most Linux distributions that is the default, and then mapped addresses will work fine if the machine has a v4 address or a 464XLAT configuration. This has been the case for about 20 years.
It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity.
6to4 was an attempt at that kind of embedding and I do not think it succeeded?
The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.
It’s not. It’s IPv4 with more bits and some changes to Ethernet level lookup. The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.
If it actually was v4 with more bits and different ARP it wouldn't take 30+ years to be deployed.
> Any address length greater than 32 would create all the coexistence and transition problems we have experienced since 1994 This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?
There are some designers who knew their system would be incompatible but thought it was interesting enough to design anyway, like RINA. There are other designers who just didn't realize why this was a problem, like ipv8. The ipv8 designer is currently berating the NANOG (north america network operators group) mailing list for not already supporting ipv8 on all networks. If it's compatible then why do they need to do anything to add support, eh?
People get emotionally attached to the name "IPv6" being bad, and don't realize how putting the same stuff in a different protocol makes that one just as bad, but without the 30 year head start. If a new proposal is about the same as IPv6 but isn't already supported by most equipment, then wouldn't it be better to use IPv6 instead?
This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain. All of them seem to have gone to some secret seminar somewhere where they receive their talking points: - Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall. - There's absolutely no downside whatsoever to being…