211–220 of 316 posts
One major weirdness with ipv6 is that it occasionally works with ipv4 and it's unclear why. Example: we run a bunch of endpoints on ipv4, but get ipv6 IPs in our logs. How? Are there 6-to-4 translators out there at ISP edges? Unknowns in networking are bad.
Proxies. Your logs are too trusting of X-Forwarded-For headers.
Earlier quoted context omitted.
Why? What's the (supposed) fear?
Because there's a lot of shit that still doesn't work well with IPv4. Logging is one good example - a lot of software that uses its database for event logs has the database column for remote_ip defined as VARCHAR(15), you can guess the rest of what happens when deploying that with IPv6 enabled.
Earlier quoted context omitted.
Sure, everything supports IPv6 -- until you turn it on and rediscover the tickets that have been sitting at the bottom of the JIRA for the last decade.
As a matter of fact Ron Broersma who affiliated with Space and Naval Warfare Systems Command (SPAWAR) has a list of equipment that should be fully IPv6-only compliant including various management interfaces and more. The US Navy supposedly tests this in house in a IPv6-only network. 4 years later I imagine the situation only got better https://www.youtube.com/watch?v=9kQje5gSWw8 Also, AWS now have the majority of NIC…
As for AWS, I tend to agree with the sibling post and your supposition about IPv4. Everything out of the Amazon organization is aggressively, err, "minimal."
Earlier quoted context omitted.
A lot of IT folks are still fearful of IPv6. I've been on calls where people disable IPv6 as a matter of "best practice." It's sad. People will gladly learn the latest flavor of the month web framework but won't take time to gain experience with a fundamental protocol.
Why? What's the (supposed) fear?
People see a 10.x and instantly know it can't be reached from the public internet. IPv6 is much harder. For internal-only stuff there is the fd00::/8 block, which AWS actually does use, but there is no equivalent range for outgoing-only connections.
There needs to be a body of law relating to technical matters like this (and interoperability etc) that is adjacent to competition law. Some things we just need everyone to be on the same page about. It is manifestly the case that ipv6 is never going to be that, because the incentives to invest simply don't exist for companies like AWS. This distorts the market in eyeball networks and hosting - the former are under l…
The EU did have a mandate for government services to use IPv6, but the programme it was part of got replaced by another that didn't include IPv6. The European Commission did advocate for IPv6 use, but, the EU being the EU, motivated their recommendation by complaining that law enforcement had issues tracking down people behind CGNAT, and made clear that they wanted every IP address to point to a specific person for l…
The problem is customers don't like CGNAT. You can't run Animal Crossing on Nintendo Switch in network mode as a host if you don't place the Switch as a catch-all in the DMZ.
Wish I were joking here - especially due to the security risk involved in running something in all-ports-open on the Internet - but Nintendo doesn't seem to (want to) run STUN/TURN servers.
> almost no AWS API can be used from a VPC without public IPv4 addresses Virtually every single application at the company I work at deploys into VPCs without public IPv4 addresses - this seems like a ridiculous claim.
Do they use NAT gateways? These require public IPs.
Earlier quoted context omitted.
Why? What's the (supposed) fear?
I have a reason: we do per IP rate limiting. It's easy enough for IPv4 when the number of IPs is necessarily not too big to fit in a small redis for example, but for IPv6 everyone have at least a /64. I'm curious how people do it btw, if you have tips to share, I'm all hear. Do you simply rate limit IP ranges? Even limiting per /64, it's still potentially quite a lot of /64 to track.
Earlier quoted context omitted.
Even cheap consumer hardware supports ipv6. There are significant financial incentives to continue the capitalism of ipv4 addresses. Like NFT's - an artificially limited capital. To create more addresses means more competition, loss of capital. Therefore they will spend billions on continually reworking internal IPV4 than going for the proper solution.
You obviously have never been on the backend of a big enterprise deployment. The world is bigger than your apartment.
Often IPv6 and IPv4 paths were entirely different and latency on IPv6 was much bigger, so we had to measure latency between nodes on both. Also, sometimes IPv4 was a symmetrical, but IPv6 wasn't. As a result, we had to buy tons of IPv4 addresses.
Our control plane was on IPv6, but data-plane had to be on both.
Earlier quoted context omitted.
Why? What's the (supposed) fear?
I have a reason: we do per IP rate limiting. It's easy enough for IPv4 when the number of IPs is necessarily not too big to fit in a small redis for example, but for IPv6 everyone have at least a /64. I'm curious how people do it btw, if you have tips to share, I'm all hear. Do you simply rate limit IP ranges? Even limiting per /64, it's still potentially quite a lot of /64 to track.