Posted by jmillikin 2 days ago
For comparison, the internet mostly transitioned off of TLS 1.0 just fine, why can't we do the same for transitioning off ipv4? Maybe AI powered proxies for legacy code perhaps?
This is a great demonstration of the advantages of the end-to-end principle. The reason the transition off TLS 1.0 (and earlier SSL 3.0) could happen so quickly is that only the endpoints (the server and the client) needed to be updated to understand the new protocol; nodes in the middle of the path (routers, switches, and so on) only needed to care about the IPv4 (or IPv6) layer, which didn't change with new TLS versions.
But that only works for layers above the network protocol; when updating the network protocol itself, every node is affected.
(And the TLS transition also took longer than it should, in large part because a lot of "middleboxes" violated the end-to-end principle by inspecting or even modifying the TLS connection, without taking part in the protocol negotiation. TLS 1.3 had to be modified to pretend to be a resumed TLS 1.2 connection to trick these middleboxes into not incorrectly rejecting the newer version of the protocol.)
I think what was needed was organization that could push IPv6. Boring technology needs someone promoting or grows slowly. They could have logo for IPv6 ready devices, and list of ISPs with IPv6. They could write network engineering training for the IPv6 way.
We missed opportunities for cloud computing, Kubernetes, and new companies to be primarily IPv6.
The difference is only the end client and server need to support TLS, all the middleware and networks between just see TCP packets and do not have to be privy to what TLS version is being used.
IPv6 on the other hand has to be supported by every middleware box between the client and the server and therefore its functionality is limited by the lowest common denominator.
Additionally TLS upgrades were largely drop in, whereas IPv6 changed too many things at once to be easily adopted.
Hindsight is 20/20, but I firmly believe that IPv6 should have only changed source and destination addresses to be 64 bits and that was the entire RFC.
V6 was designed by the engineers who realized what they got wrong in V4.
> your networks isn't so simple that you can just auto-negotiate some address
I don’t understand what you mean by this…v6 afaik has every tool that v4 does for assignment. If automated assignment through SLAAC or either kind of DHCP doesn’t meet your needs, then there’s manual assignment, just like with v4.
> You still need a stateful server to assign IPv6 addresses for most use cases, through DHCPv6. SLAAC doesn't even give you a DNS server yet.
DNS now comes in Router Advertisement per RFC 8106. No need for DHCPv6 anymore.
> And even if it did, many ISPs assign too small address spaces for SLAAC, or your networks isn't so simple that you can just auto-negotiate some address.
Most residential ISPs allocate in /48, /52, /56, or /60. Even if they allocate in the smallest /64, it's still perfectly fine for SLAAC for most home users utilizing a single subnet.
int fd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in addr = { .sin_family = AF_INET, .sin_port = htons(1234) };
addr.sin_addr.s_addr = htonl(INADDR_ANY);
bind(fd, (struct sockaddr*)&addr, sizeof(addr));
listen(fd, 128);
int client;
while (client = accept(fd, 0, 0)) {
// ...
}I have to use this wifi dongle, but using IWD to connect somehow only gave me an ipv6 IP.
Most of the big sites worked, but trying to click links from a search engine was a 50/50 chance.
Thankfully, the Arch wiki was accessible, so I got it sorted out pretty quickly.
I use this often because IPv6 on phone networks is invariably the same as the author's - native IPv6 plus carrier grade NAT IPv4, and most NAT implementations suck (they time out, for instance).
I haven't tried with WireGuard(r) yet, but I will soon (using NetBSD's clean reimplentation). With tinc [1] though, it's a piece of cake.
I can’t guarantee five nines but my power almost never goes out, and that’s plenty for a blog and even many online stores
Having a stateful mapping device inline in the network sucks for reliability in general. Native IPv6 removes the requirement.