[deleted]
Tell HN: IPv6-only still pretty much unusable
471–480 of 649 posts
Re: Tell HN: IPv6-only still pretty much unusable
#472Maybe IPv6 should have had a stronger backwards compatibility story. Maybe not IPv4+ as described in a sibling comment, but something that lets me easily be compatible with IPv4 without having to do the whole setup again.
Having to actively manage 2 totally separate systems isn't economical at all, so it's no surprise that so few bother, myself included. I totally want to "switch to" (-> add) IPv6, but just can't justify the cost. There's nothing in it for me here, I would only lose.
Re: Tell HN: IPv6-only still pretty much unusable
#473Earlier quoted context omitted.
If you want failover-independent IPs you can keep using NAT, ie NPTv6, at the gateway level and not bother with giving public IPs to your LAN machines.
That's possible, but my understanding is that NPTv6 is strongly discouraged. Part of the point of IPv6 is do away with NAT and the problems caused by it. I was hoping there was a better way.
Yes, that is correct. But not having NAT is the same as having addresses that depend on the subnet prefix.
Re: Tell HN: IPv6-only still pretty much unusable
#474IPv6 has been one of the biggest failures in the last couple of decades. And I don't mean adoption, I mean the standard itself. If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. Yes, I understand it would still require some breaking changes, but it would have been a million times easier to upgrade, as it would be a kind of superset of IPv4 (1.2.3.4 can be referred as 0.0.0.0.…
I am not a network engineer, but for about 20 years I have wondered why we didn't 'just' do something like:
1. Include an extra 32-bits of address information as an IP options header. Call it an IP4.4 packet.
2. (I think?) IP4.4 packets would therefore happily travel over existing IP4 infrastructure.
3. Each existing IP4 address becomes a potential IP4.4 network with 32-bits of address space behind it.
IP4.4 aware routers at the network border could swap inbound IP4 destination with the .4 address before forwarding on to the internal network. Basically like NAT, but you can allow inbound connections without maintaining state.
EDIT: formatting
Re: Tell HN: IPv6-only still pretty much unusable
#475Earlier quoted context omitted.
One of the ideas of ipv6 was to reduce routing tables, those tables that backbone providers have to keep in memory and look up for incoming traffic. With ipv4's fragmented allocation scheme, these routing tables are huge. With ipv6, even huge companies like amazon only have a couple of global allocations. A "ipv4 with more octets" scheme would have kept that fragmentation around. That being said, Amazon currently has…
> where your local address is horribly long, for the sake of global uniqueness, which is something that most people don't really need Apart from debugging where you can copy-paste anyway, does it matter? I've got a few services on the local network and over zerotier that all talk IPv6. In the last 3 years or so I've never used an ipv6 address directly. There's enough DNS and discovery protocols that I never needed to…
Any sysadmin for a medium sized company with their own servers are likely to end up having to type in IP address or get them off shitty management consoles that don't support copy paste in any way.
Re: Tell HN: IPv6-only still pretty much unusable
#476And this is where government regulation would have helped. It's a shame nobody listened to me back in the 90's: (it's a joke. I'm a nobody, there is nobody listening.) All cell-phones should have been ipv6 from the get-go. Now if we could just go back in time and warn everybody about IPv4 address space being exhausted. And maybe the climate too while we are at it. Seriously though, cell-phone adoption would make that…
It’s not that ipv4 space is exhausted, there’s plenty of it available. It’s that early on it was mismanaged to the point that people / companies were able to buy entire /8’s for basically nothing and hold them forever.
And Chinese companies have bought all of the free space in places like Africa and are leasing them out.
Re: Tell HN: IPv6-only still pretty much unusable
#477Can you attach floating ip4 to your ip6only hetzner machines?
Re: Tell HN: IPv6-only still pretty much unusable
#478Earlier quoted context omitted.
You just need to do what the world did - NAT. IPv6 is more than just address space extension. There’s all sorts of stuff packed in there that complicates the process. All mobile clients are behind CG-NAT. We should have built standards around that instead of worrying about extending IP space to Mars or whatever.
> All mobile clients are behind CG-NAT. Demonstrably false. T-Mobile US mobile clients are IPv6-only and connect via IPv6 to IPv6 sites: * https://www.youtube.com/watch?v=d6oBCYHzrTA * https://www.youtube.com/watch?v=nNMNglk_CvE NAT is only used to connect to IPv4-only hosts via DNS64 (with or without 464XLAT). As of 2022Q2, T-Mobile US has 110 million customers: * https://www.statista.com/statistics/219577/total-cus…
Even my smalltime telco in Australia uses ipv6.
Re: Tell HN: IPv6-only still pretty much unusable
#479Earlier quoted context omitted.
OK: Let's use "IPv4+" scheme as described by redox99: we still have dotted-decimal, and IPv4 addresses are guaranteed to be accessible via IPv4+ interface. Right now, most application software need non-trivial rewrite to add ipv6 support: it has to support 2 sockets instead of 1, and ":" in address breaks basically every address parsing function out there. With IPv4+, you do search/replace "sockaddr_in"->"sockaddr_in…
> I should be able to write "-m tcp --dport 80 -j ACCEPT" once and have it work with both. Kind of like how PF does it? tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" udp_services = "{ domain }" block all pass out proto tcp to any port $tcp_services keep state pass proto udp to any port $udp_services keep state * https://docs.freebsd.org/en/books/handbook/firewalls/#pf-tut... If an address family ("af…
Similar functionality is provided in nftables for linux ('inet' filter applies to both ipv4 and ipv6). But, outside of the most trivial use cases of just block/allow a port, it doesn't really work out to be that useful because of other restrictions. E.g., if you are collecting IPs that have e.g., created new connections to some set of ports greater than n times within a time period to rate limit them, you are out of luck and will need separate rules for ipv4 and ipv6 since you cannot save a mix of ipv4 and ipv6 addresses to the same list.
Re: Tell HN: IPv6-only still pretty much unusable
#480Earlier quoted context omitted.
OK: Let's use "IPv4+" scheme as described by redox99: we still have dotted-decimal, and IPv4 addresses are guaranteed to be accessible via IPv4+ interface. Right now, most application software need non-trivial rewrite to add ipv6 support: it has to support 2 sockets instead of 1, and ":" in address breaks basically every address parsing function out there. With IPv4+, you do search/replace "sockaddr_in"->"sockaddr_in…
> Right now, most application software need non-trivial rewrite to add ipv6 support: That's not right. If you've been using the platform network libraries for things then IPv6 will just work with anything more recent than Windows XP. Unless you've been hardcoding IP length expectations then there is basically nothing to do. Seriously, use the platform libraries. They handle all the edge cases and stop storing IP addr…
Unless you are doing something super trivial, like making http/https requests to pre-defined URLs, your platform libraries will not help you.
Your network servers need two explicit bind() calls for two different protocols, and some logic to select which ones to call, and your main accept() code needs to be able to handle two listening sockets... Theoretically you could create IPv6 socket only and accept both addresses but.. (1) apparently it is disabled on many BSD's by default and (2) even on Linux bind() will fail if you have no IPv6 addresses assigned at all.
Your network client would be better, as there are some libraries which let you connect to ipv4 or ipv6 address, but then IPv6 colon-separated format will trip you. How many clients split on ":" to get port number? Or concatenate (IP, ":", PORT) in the logs / settings? All of those would break.
The really annoying part is that all of these problems were 100% predictable from day 1, and yet someone decided to go ahead with this implementation.