NAT64/DNS64 shows up as IPv6

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set up network with IPv6 only and NAT64/DNS64 for reaching IPv4 internets
2. Load some sites with just A records
3. Profit!

It would be nice if the plugin would de-synthesize NAT64 and show it as IPv4 
connections. Now EVERYTHING shows up as IPv6 here. Sort of but not really 
misleading, though very annoying ;-)

Application/OS level NAT64 detection is kinda up in the air at the IETF still I 
think, but desynthesizing the "well known" NAT64 prefix 64:ff9b::/96 back into 
displaying as IPv4 would help a lot, even if its just changing the icons back.

Original issue reported on code.google.com by trippehh on 6 Oct 2012 at 10:18

[GoogleCodeExporter]

Does your NAT64 actually use the 64:ff9b::/96 prefix?  I could tag that as IPv4 
trivially, but allowing arbitrary prefixes would require a configuration page, 
and an address/subnet parser.

Original comment by sparkm...@gmail.com on 6 Oct 2012 at 10:34

[GoogleCodeExporter]

1.0.17 now labels the "64:ff9b::" prefix as IPv4.

Original comment by sparkm...@gmail.com on 6 Oct 2012 at 11:16

[GoogleCodeExporter]

Another alternative is to do detect the prefix by looking up a known A only DNS 
record and derive the prefix from the generated AAAA. This too adds quite a bit 
of complexity for an small simple addon I guess. Then again just flagging 
64:ff9b::/96 should take care of the majority of cases.

The new release seems to work fine here, now IPv4 sites gets flagged red/4. 
Thanks!

Original comment by trippehh on 7 Oct 2012 at 10:42

[nivex]

There is now a known host in DNS for this purpose: ipv4only.arpa. If you get an AAAA back from this, you know you're behind NAT64.

IPvFox had this functionality before it went unmaintained: https://github.com/Dagger0/IPvFox/commit/4dd97947e0e6ef8296c5321354ea2e9ea41bffb1 Dunno if any of that code can be repurposed into a WebExtension.

[pmarks-net]

I don't think it's possible for a Chrome extension to use ipv4only.arpa; there is no DNS API.

Though it would be possible to have a button on the Options page send a query to https://ipv4.google.com/some_dummy_page, and extract the IP address.

[treysis]

Does your NAT64 actually use the 64:ff9b::/96 prefix?  I could tag that as IPv4 
trivially, but allowing arbitrary prefixes would require a configuration page, 
and an address/subnet parser.

Actually it would be nice if there was an option to define arbitrary prefixes. Some people use public accessible NAT64 gateways, which obviously have to use a publicly routed prefix.

[telmich]

To chime in here: while technically being in an IPv6 only network means that you always connect via IPv6 (!), I understand the original motivation. However, I also argue that it should not be displayed as IPv4, but there should be an indication of NAT6, f.i. a "6+4" or "64" or whatever icon fits best to indicate that you are actually using both at the same time.

Besides that: even without a DNS API, does the HTTP (?) API not contain the source IP address of an answer? If that was the case, you can just access ipv4only.arpa or/and ipv4.google.com and check whether the protocol is IPv6.

[treysis]

How about "(4)" (4 in brackets)? Or a green 4, or a red 6?

[telmich]

How about "(4)" (4 in brackets)? Or a green 4, or a red 6?

All three of them sound sensible to me

[Leseratte10]

If it's not too much work, maybe there can be a config option to how it should be displayed.

Someone testing a NAT64 implementation or trying to set up an IPv6-only network might prefer displaying these as "6" since that's the protocol the browser uses (to talk to the gateway), while someone testing if websites fully support IPv6 might prefer displaying these as "4" since that's how the connection ends up on the website.

What would also be cool is if NAT64 IPs wouldn't be displayed as 64:ff9b::c633:6417 (as it is now) but instead like 64:ff9b::198.51.100.23, that'd make it way easier to copy-paste just the IPv4 address part.

[treysis]

Maybe show "6" but make it purple?