3 ms·
Man, that is it exactly, they threw everything and the kitchen sink into it AND made it unnecessarily difficult to update systems / be compatible with IPv4. Th
by random5634 6y ago
Man, that is it exactly, they threw everything and the kitchen sink into it AND made it unnecessarily difficult to update systems / be compatible with IPv4.
They should have had IPv6 with a header or config for IPv4 gateway(s) configured at the IPv6 boundary of your current network (could even be local / on device if needed). Want to talk to IPv6 - you go native. Want to talk to IPv4, connect using known prefix to IPv4 boundary gateway and it NATs you out.
The implementation / firewall changes needed for this are crazy, the config stuff also crazy, the number of layers of encryption I'm hitting (I'm IPv6 on a VPN using wireguard tunnels and browsing in SSL on my remote machine) seems nuts.
- Dagger2 6y agoYou mean like... NAT64? For me, the necessary firewall changes consisted of using "domain (ip ip6)" in ferm instead of "domain ip"; the general config is a few lines in radvd.conf plus a static IP on the LAN interface (and v4 requires that one too). None of that seems very crazy. > the number of layers of encryption I'm hitting (I'm IPv6 on a VPN using wireguard tunnels and browsing in SSL on my remote machine) seems nuts. This is two layers, one of which you introduced yourself and neither of which have anything to do with v6.
- random5634 6y agoNo disrespect, but you have probably not implemented or tried to transition a network running on IPv4 to either dual stack or IPv6 native internally. Even the big players like AWS / GCP etc struggled with this.
- Dagger2 6y agoI have. Not on the scale of AWS or GCP, admittedly. Those networks are Special because they run on custom hardware and can't take advantage of the work other people have done. But that's kinda their fault for not just doing their custom stuff on v6 in the first place; it's not like they didn't know it was going to be needed.