![]() MSG SIZE rcvd: ping6 2603:400a:ffff:804:801e:34:0:15Ĭonnect: Cannot assign requested ping6 jigsaw.w3.orgĬonnect: Cannot assign requested ping jigsaw.w3.org flags: qr rd ra QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >HEADER<<- opcode: QUERY, status: NOERROR, id: 11283 > DiG 9.10.3-P4-Ubuntu > jigsaw.w3.org -t aaaa First, a little bit of poking with redbug reveals that we're using the inet6 option for dig jigsaw.w3.org -t aaaa Here's the debugging to support my theory of what's going on. provide a connection option to coerce to IPv4.Among other things it can be slow depending on how long it takes IPv6 to fail. Many browsers do this, but not everyone is a fan of that strategy. Somewhat messy to plumb in, but the result 'just works'. we could retry back to IPv4 after trying IPv6.I'm willing to take a shot at it, and a couple of options occur to me. Reverting the PR isn't appealing I don't want to break IPv6 only environments either. So that change breaks things for people with IPv4 only connectivity connections fail and AFAIK there's not a great workaround for it. A host being resolvable as IPv6 doesn't guarantee it being routable. I think PR #155 is incomplete, in that it uses the availability of an IPv6 address to decide what to do. After updating to 4.4.1 we started seeing connection failures of the form when using a hostname to connect from an IPv4 only system. I'm also seeing something somewhat similar.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |