On 27 Dec 2023, at 03:08, Mark Prior <wg-ipv6@internet2.edu> wrote:

On 27/12/2023 09:15, Michael Richardson wrote:

Mark Prior via ipv6-wg <ipv6-wg@ripe.net> wrote:
    > The cases where it gets to a 200 are fine as that's "success" but there are
    > some failure modes that I can't really make my mind up on so having some
    > feedback would be potentially useful.
What percentage are these failures? Maybe it's just noise.

About 10% of the web capable domains are reporting something other than 200 but even if it was "noise" it is still reporting things to fix. My question relates to what is the most useful way to report those failures, with the hope that someone will notice and fix it :-)

I think that’s a fine philosophy :)

> In all these cases I see a site with A and AAAA records so I connect on port
> 80 of the IPv6 address(es).
What if they have only AAAA?

I don't have any active domains like that but assuming there is one and it has an IPv6 error then it should report that error as there is no potential IPv4 "success" to get in the way.

I suppose 80 being open these days is a ‘fail’ of sorts… but probably best not to rathole into non IP-specific issues (we tend to use https://www.ssllabs.com/ssltest/) and rather highlight differences in v4 and v6 behaviour that the sites may be unaware of.

    > 1. If the connection fails should I just report that or should I do anything
    > more? For example see if the site responds via IPv4.
The site could just be down/broken.   So checking with v4 kinda makes sense.
    > 2. If the connection succeeds (so I assume there should be a working IPv6
    > based web server) but after querying it with a HTTP/1.1 message sees the site
    > resets the connection (or fails in some other manner).
That sounds like it's behind a v6-capable/enthusiastic CDN, and the origin web site is broken.
    > 3. The connection succeeds as does the query and I get a 301 redirect to a
    > location that fails to connect (typically it's the https port but could be
    > another domain name). Again is this enough or should it do something
    > else?
I think that this is the biggest question.
I'd mark it as down for now.

It would be marked as down but the question is would it be useful to check if IPv4 does the same thing and if it didn't how to report it in the cell in the summary. If you looked at the linked "diagnostics" file you could find evidence of the problem but that's more work.

In the slightly different case where the redirect points to a location that doesn't have a AAAA the script will mark this as a failure with "redirect lacks AAAA".

We have some unusual behaviour for jisc.ac.uk, that varies for v4/v6 and whether the www is prepended. I think this is being worked on.

    > Finally in some cases I'll get a HTTP status code such as 403, 429 or 503
    > rather than 200 and these are reported with a background of either light
    > green or light red depending on whether it occurred on an IPv6 or IPv4
    > connection. Should these be blue rather than a different green/red?
Keep them green/red.

Thanks for the input,

And thanks for the tools :)