Open joelwhitehouse opened 7 years ago
I like this idea and will see if it's possible to implement for v.3.4.
Thanks for the consideration!
Since I filed this issue, I've learned that some NAT64 implementations (tayga?) specifically prohibit configuration of the well known prefix 64:ff9b::/96, instead requiring a prefix in which the NAT64 router interface is homed. Because of this, resolving 'ipv4only.arpa' to determine the presence (and prefix) of a NAT64/DNS64 implementation would be much more robust than a simple hard coded check flagging of the well known prefix.
I've learned that some NAT64 implementations (tayga?) specifically prohibit configuration of the well known prefix 64:ff9b::/96,
As I have setup tayga with this well-known prefix, I can say it is definitly possible. But I agree, that resolving ipv4only.arpa would be a much more clean and robust way to detect NAT64.
I'd suggest to treat NAT64-ipv6 addresses just like ipv4 addresses when it comes to how to display it in the url bar icon-wise.
Steps to reproduce
I used SixOrNot on an ipv6-only network that uses DNS64/NAT64 to make ipv4 websites available to clients.
Expected
SixOrNot should show native ipv6 web pages in green and show the NAT64-reachable hosts in red (because the remote host is ipv4 only.)
Observed
SixOrNot correctly shows green for native ipv6 websites but also shows green for ipv4-only servers.
Possible solution
To detect NAT64, SixOrNot could occasionally resolve 'ipv4only.arpa'; to see if an A record is returned (normal DNS) or if an AAAA record is returned (DNS64). This is the strategy google uses to allow Android to detect NAT64.
If a AAAA record is returned, then the first 96 bits of the AAAA record is the local NAT64 prefix, which is conventionally 64:ff9b::/96. Any addresses shown with that prefix should be shown in red until such time as 'ipv4only.arpa' resolves to only A records.
Alternately, SixOrNot could simply show red for any IP addresses that begin with the well known prefix 64:ff9b::/96.