21–30 of 245 posts
IPv6 and Python3 are case studies in how not to roll out a new version unless you're cool with multi-decade upgrade windows.
Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.
would be interested to see what they do to their lightsail prices if you add these new charges onto the existing prices their offering becomes completely uncompetitive
> Yes, Lightsail is revising instance bundle pricing to accommodate IPv4 and new pricing will be published later this year. We understand the importance of bundled and predictable pricing for Lightsail, so revised pricing will include the IPv4 conservation charge in a monthly bundle cost and not as a separate charge.
[1] https://www.linkedin.com/in/adityasanthanam/
[2] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
IPv6 and Python3 are case studies in how not to roll out a new version unless you're cool with multi-decade upgrade windows.
Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.
Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog.
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
And of course as long as IPv4 works there's little inherent motivation to go to any kind of IPng.
See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
Do the other cloud providers give you IPv4 endpoints for free? I didn't think that was the case. (ie I thought AWS was just falling into line with the others on charging). As for the "critical services not supporting IPv6" in the post I was quite surprised that it's such a short list of things that don't work - I would have expected more. They've obviously made a ton of progress.
Azure and Google Cloud don't, and they didn't have full ipv6 support when making the change either
Earlier quoted context omitted.
Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.
IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). If IPv6 had left out the mandatory added complexity, and just…
SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done.
You also get rid of the complexity of STUN/ICE/etc as you no longer need NAT, so you just need hole punching for SPI firewall (also needed with NAT for port forwarding, so no change there).
One day will come, when network admins will be so happy to finally turn off IPv4 on their stack. When router manufacturers will feel happy to support only IPv6. It is definitely coming within my lifetime. So, these intermediate steps are just cooking the final dish. Peace. ;)
They would need to be forced to move by customers, probably through an ISP being IPv6 only. And that probably won't ever happen as the customers of those ISPs would drop them for one that does support IPv4 because they expect access to the same big businesses mentioned earlier.
I think the whole thing has lots of inertia to not move to IPv6 and there's no incentive to force it.
Not happy that AWS is pushing this and they don’t even fully support it.
Earlier quoted context omitted.
IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). If IPv6 had left out the mandatory added complexity, and just…
> […] and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done. You also get rid of the complexity of STUN/ICE/ etc as you no longer need NAT, so you just need hole punching for…
Earlier quoted context omitted.
Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.
IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). If IPv6 had left out the mandatory added complexity, and just…
And due to the large number of significant changes it's still a work in progress as a standard, with important RFCs coming out "as we speak"[1].
[1]: https://packetpushers.net/podcast/ipv6-buzz-134-revisiting-u...
Perhaps AWS could run these endpoints through Cloudfront in order to get IPv6 reachability.