311–316 of 316 posts
This means that everything else in your VPC has to be dual stack if the lambdas talk to them.
AWS Lambdas don't actually run in your VPC, there is an ENI that is exposed to your VPC that belongs to the VPC-equivalent in the Lambda space.
If you have to run dual-stack just to accomodate lambdas, then you may as well run IPv4 anyway.
Earlier quoted context omitted.
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.
Given that the only routable IPv6 address space is in the 2002::/16 range (is 2003:: in use yet?), and the standing recommendation for ISP CPE endpoints is to allocate a /48 per customer (a customer can't do any local subnetting if only allocated a /64), the effective address space for rate-limiting is the exact same size as the current IPv4 address space: you only need to track bits 16-47. It's possible that cloud p…
Cox & Spectrum only hand out /56. I'd hate to be banned because my neighbor did something bad and we happen to be in the same /48.
Earlier quoted context omitted.
Why? What's the (supposed) fear?
It’s a big scary number and the letters just break understanding. There are some annoying operational issues around it as well, common one: DNS hostnames for devices that only do SLAAC
If your network card breaks you switch it out, and you make sure your IPv4 settings apply to the new card.
If you fully rely on IPv6 you'll get a new address.
And if your devices self-update DNS then you have to make sure they pick the right address, as there can be many due to privacy extensions.
Lastly, combining privacy extensions plus hosting stuff is hard, as you don't know on which address a certain port is bound.
IPv6 is such a massive headache it’s kind of mind boggling. I used to be super enthused - but it is absolutely less useful and more annoying than it’s worth.
This is one example where it's clear IPv6 isn't the problem, actually. A lot of problems with AWS would disappear if they would just support IPv6 like your average budget ISP does. IPv6 just works. Amazon, Github, and Azure don't. That's not really a problem in most cases (very few people go IPv6 only because it's just not necessary with CGNAT, and even then network translation tricks can put up IPv6 IPv4 bridges eas…
There is a reason well resourced companies like google cloud have been slow w IPv6 - and it can be even more hair pulling in smaller settings.
Earlier quoted context omitted.
This is one example where it's clear IPv6 isn't the problem, actually. A lot of problems with AWS would disappear if they would just support IPv6 like your average budget ISP does. IPv6 just works. Amazon, Github, and Azure don't. That's not really a problem in most cases (very few people go IPv6 only because it's just not necessary with CGNAT, and even then network translation tricks can put up IPv6 IPv4 bridges eas…
WAN failover is not fun with ipv6 - npt doesn’t solve things because prefix lengths are variable. You end up back with NAT with basic networks again but with ridiculously large address space. Firewall rules a trickier- you need to both let ICMP through but be careful because some can drive network reconfig. DHCP is second class, and the network can do weird things when port isolations are on. The number of (rotating)…
Then you pick your shortest prefix length and use that for your network configuration, no? Nothing in NPT is forcing you to use a /48 or a /56, if your failover uplink only provides you with a /80 for some stupid reason you'll still be able to do translation.
DHCPv6 is supported just fine by everything but Android (for some annoying reason). Even with SLAAC, IP addresses shouldn't rotate, unless you enable Privacy Extensions on your server.
If this were the bakery just around the corner we're talking about, I would've accepted these problems as illogical to even try to overcome, but these are billion dollar companies selling network access. When networking is one of your major streams of revenue, I expect better.
Honestly IPv6 is a clusterfuck. From the horrible addresses (why are they impossible to memorize? Who thought that was a smart idea? At least I can wrap my brain around IPv4) to the need for specific support in literally every layer of the network stack. If you are going to mention gateways or other methods make it work please just stop. No end-user is going to do that, or rather no appreciable amount of end users ar…
Every time someone brings up this point, I have to assume that they know nothing about IPv6 but the superficial things.
If you work with IPv6 long enough you will remember the addresses, we all remember 192.168.0.* through years of typing it repeatedly and looking at it. Not because it is easily to remember. I can already recall 2606:4700:4700::1111 or 64:ff9b::101:101 from memory.
>My ISP, literally the best available in my area and fairly cutting edge in every other aspect, has zero IPv6 support.
This is almost exclusively an Euro-American phenomenon. I am not sure why you are lashing out on IPv6 when it's the ISPs' fault. In most East or Southeast Asian countries we are looking at double-digit % of IPv6 deployment, the moment you click on the IPv6 checkbox you get IPv6 connectivity here.
>The privacy/security aspects alone are staggering and you rarely want your device to be publicly available by default.
Another one who mistakes "having a globally unique address" with "public accessibility". Boo.
>“let’s try disabling IPv6, oh it’s working now?” (on my end or theirs) that I’m done
Just say that you are lazy in fixing IPv6 problems. I have found that lots of old networking guys would say "it's defo my fault somewhere" when IPv4 fails but when it comes to IPv6 it's always IPv6's fault somehow. Protip: most of time it isn't.