[bombcar]

This is the only way IPv6 will ever finally take off; if there's a cost to IPv4.

[_cenw]

Money is a terrible discriminator unless you want to advantage the rich. This would fuck up connectivity for everyone that relies on affordable hosting long before it'd force a rusted old enterprise to adopt IPv6.

dig github.com AAAA

[mdaniel]

I hear you, and do appreciate your point. But, what other incentive alignment levers are available for corporations than their bottom line?

Also, I'm just saying:

  $ dig gitlab.com. AAAA
  2606:4700:90:0:f22e:fbec:5bed:a9b9

I'd bet that's in no small part due to them hosting on GCP

Interestingly, it seems AWS is the outlier in the "IPv6 control plane is a fad" stance

  $ dig admin.googleapis.com. AAAA  # as one might expect
  2607:f8b0:4005:810::200a
  $ dig management.azure.com. AAAA  # which surprised me
  2603:1030:a0b::10
  $ dig ec2.amazonaws.com. AAAA  # :trollface:
  $ dig ec2.amazonaws.com. A
  209.54.181.135

[colmmacc]

    $ dig AAAA ec2.us-east-1.api.aws
    ...
    2600:1f70:8000:a0:41d7:f53b:34f4:5798

The EC2 API is available over IPv6. AWS services that support IPv6 for their APIs use the .aws TLD and the SDKs and CLIs know how to invoke that when IPv6 is preferred. See https://docs.aws.amazon.com/general/latest/gr/rande.html#dua...

The reason is for backwards compatibility. If IPv6 was simply added to the original names, some clients would instantly shift from using IPv4 to IPv6 and in the process break any customer IAM policy in place that is restricted by IP address. Some day it may be the right call to let that kind of breakage happen, but for now the preference is to ensure that customers are not surprised.

See also: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su...

[mdaniel]

I'm not trying to shoot the messenger, but that is pretty up there in the list of dumbest things, and accompanying reason for dumb things, I've heard in quite a long time

Also, I especially enjoy that control-f "iam" or "sts" on https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su... is all hurp-durp as is $(dig sts.api.aws. AAAA) so I guess one should be sure to email themselves some credentials in any such IPv6-only EC2 setup. I wondered if it was just a documentation oversight but https://docs.aws.amazon.com/general/latest/gr/sts.html seems to agree

Now I'm just deathly curious and will try to remember to boot up one of these allegedly IPv6-only EC2 setups to see what running $(aws --debug sts get-caller-identity) does from one of those Instance Profiles

[colmmacc]

You're not shooting the messenger. I signed off on this strategy. In our case, quite a number of customers lock down their IAM policies with IP address based permissions. They have rules like "This account can be used only from our datacenter", or "These EIPs are the only legitimate source for changes" that help them defend against credential theft. There are other defenses, but for some ... this simple defense makes sense. My understanding is that GitHub have a similar challenge, and you can see in their note at: https://docs.github.com/en/enterprise-cloud@latest/organizat...

If we turned IPv6 on like a light switch and suddenly broke all of those customers whose traffic would flip to IPv6 ... that'd be pretty bad. That's not dumb. So instead we have dedicated endpoints for IPv6 and are working with customers to get their policies updated and tested.

For IAM creds on an EC2 instance it's more common to use EC2 Instance Roles. Those are retrieved locally from the IMDS, which is available over IPv6. We have a number of customers, including some large ones, running IPv6-only on their EC2 setups.