Question about how I handle web sites in my IPv6 survey
Hi there, I'm seeking some views on how I should report some web failures on my IPv6 survey page <https://www.mrp.net/ipv6_survey/>. If a site has both A and AAAA records for a web site I will try to connect to the IPv6 address and see if there is a web site listening there. It will start at tcp port 80 and then follow any redirects until hopefully it finds a 200 response. 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. In all these cases I see a site with A and AAAA records so I connect on port 80 of the IPv6 address(es). 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. 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). 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? The difference is in how they are reported on the main survey page. If there is a problem then the cell will be blue but if I stop at the error then some indication of the error will appear in the cell. If after the failure I check if IPv4 works then the cell will still be blue but the indication in the cell will be the IPv4 status (more often than not this is success and so the indicator is type of connection (HTTP, HTTPS, HSTS, H2, etc) with a link to the web page. At the moment I'm not consistent and I probably should be :-) but what type of indication is more helpful? 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? Thanks, Mark.
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. > 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? > 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. > 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. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
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 :-)
> 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.
> 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".
> 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, Mark.
Hi, 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 :) Tim Mark.
On 2/1/2024 22:50, Tim Chown wrote:
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/ <https://www.ssllabs.com/ssltest/>) and rather highlight differences in v4 and v6 behaviour that the sites may be unaware of.
I believe (and so does my script :-) that port 80 is the starting point so it should be open but it should have a 301 (Moved Permanently) redirect to port 443, where TLS is correctly implemented.
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.
The typical problem child is that www.$domain has A and AAAA records and there is a "web service" listening on those addresses which has some sort of redirect to just $domain. Sadly it only has a A record and this results in my script being sad, and you get the forementioned diagnostic.
And thanks for the tools :)
You're welcome, and good luck herding the cats. Mark.
participants (3)
-
Mark Prior -
Michael Richardson -
Tim Chown