Hey Michael,

Given the fact that the TCP 3-way handshake is established, sounds like some Path MTU blackholing happening. Due to it happening during TLS handshake it's likely from the server towards you.

2a04:4e42::272 and 2a04:4e42:2f::272 belong to Fastly (AS54113) as they host a share of images-na.ssl-images-amazon.com. Looking at a tcpdump, the first large packet in the flow is from the server. I have a full-sized native ipv6 connection so large packets are received:

00:10:28.921224 IP6 (flowlabel 0x4901f, hlim 54, next-header TCP (6) payload length: 1460) 2a04:4e42:2f::272.443 > 2600:1f18:2fe:904:4341:3edf:79e3:de1d.42114: Flags [.], cksum 0xc122 (correct), seq 1:1429, ack 518, win 131, options [nop,nop,TS val 3517605680 ecr 572934936], length 1428

Using https://github.com/falling-sky/mtu1280d to emulate a smaller MTU, in response to the large packet (#1) we send back an icmpv6 packet too big response (#2), triggering Fastly to send smaller packets (#3):

00:11:22.179423 IP6 (flowlabel 0xa9776, hlim 53, next-header TCP (6) payload length: 1460) 2a04:4e42:2f::272.443 > 2600:1f18:2fe:904:4341:3edf:79e3:de1d.42116: Flags [.], cksum 0xc7f0 (correct), seq 1:1429, ack 518, win 131, options [nop,nop,TS val 3934482883 ecr 572988194], length 1428
00:11:22.179527 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 1240) 2600:1f18:2fe:904:4341:3edf:79e3:de1d > 2a04:4e42:2f::272: [icmp6 sum ok] ICMP6, packet too big, mtu 1280
00:11:22.180175 IP6 (flowlabel 0xa9776, hlim 53, next-header TCP (6) payload length: 1236) 2a04:4e42:2f::272.443 > 2600:1f18:2fe:904:4341:3edf:79e3:de1d.42116: Flags [.], cksum 0x8c51 (correct), seq 1:1205, ack 518, win 131, options [nop,nop,TS val 3934482884 ecr 572988196], length 1204

Either your system does not send back an ICMPv6 packet too big reply, or something drops it on the way and it never reaches Fastly. You should check your firewall settings in the path to ensure you don't block ICMP and ICMPv6 packets.

Regards,

Andras

On Sat, Feb 20, 2021 at 7:11 AM Michael Crapse <michael@wi-fiber.io> wrote:

I would like to know as well who best to reach out to. We are experiencing ipv6 related issues with AWS, unable to load even amazon.com completely when any of our customers have ipv6 connectivity

curl -vvv https://images-na.ssl-images-amazon.com/images/I/11EIQ5IGqaL._RC%7C01ZTHTZObnL.css
* Trying 2a04:4e42::272...
* TCP_NODELAY set
* Connected to images-na.ssl-images-amazon.com (2a04:4e42::272) port 443 (#0)
* schannel: SSL/TLS connection with images-na.ssl-images-amazon.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 202 bytes...
* schannel: sent initial handshake data: sent 202 bytes
* schannel: SSL/TLS connection with images-na.ssl-images-amazon.com port 443 (step 2/3)
* schannel: failed to receive handshake, SSL/TLS connection failed
* Closing connection 0
* schannel: shutting down SSL/TLS connection with images-na.ssl-images-amazon.com port 443
* Send failure: Connection was reset
* schannel: failed to send close msg: Failed sending data to the peer (bytes written: -1)
* schannel: clear security context handle
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

On Tue, 26 Jan 2021 at 11:00, Josh Baird <joshbaird@gmail.com> wrote:
Are you sure it's not due to the Verizon outage? As a non-customer, your options for contacting support are limited.

On Tue, Jan 26, 2021 at 12:55 PM Justin Wilson (Lists) <lists@mtin.net> wrote:
What is the best avenue for contacting support for AWS? I have several ISPs experiencing reachability issues with AWS hosted sites. These are from different backbones, different gear, etc. The common denominator is AWS.

Been googling around and can’t seem to find a contact.

Justin Wilson
j2sw@mtin.net

—
https://j2sw.com - All things jsw (AS209109)
https://blog.j2sw.com - Podcast and Blog