I will try to explain IPv6 and IPv4 a bit, I hope you'll try to understand what I'm trying to say.
IPv4 is 32-bits long. This means there can be a total of 2^32 IPv4 addresses in the world. That's 4,294,967,296 total. That's not a lot. And as you can imagine, we ran out after a while.
As a result, IPv6 was created. IPv6 addresses are 128-bits long. That means there can be 2^128 of them. I'm not going to try to write out this number, suffice it to say, it is way, way bigger than the number of IPv4 addresses.
Here's the problem: since there are way more IPv6 addresses than IPv4 addresses, the majority of IPv6 addresses can't be converted to IPv4 addresses.
What the script you used is doing, is it takes the 128-bit IPv6 address, completely ditches the first 96-bits, and uses the last 32-bits to convert to IPv4. That is not valid.
Here's how you can verify that I'm correct. You were converting fe80::792b:3e74:df1b:c565, and the script told you it translates to 223.27.197.101. Now try a totally different address, keeping only the last 32-bits, say, 0000::0000:0000:df1b:c565. See what you get.
You have heard wrong. The first almost half of an ipv6 address is the network/route prefix, then a section for subnet and then the host/interface address. No ipv6 address converts to ipv4. I would guess 6to4 tunnels might assign the interface address as the ipv4 address to simplify things, but that is merely a choice of the tunnel operator. Basically it works through the ipv6 address from left to right to get to the destination. The further right in the address you are the closer you are too the destination interface. The tool you are using to covert addresses is fundamentally flawed. Also fe80 is link local. It's specifically allocated for this function. fe80:: is not owned and cannot be owned by anyone. It is similar to class A,B, and C ipv4 networks, however ipv6 doesn't use NAT, so in practice it is a bit different.
Since these are link-local IPv6 addresses, they were created by the machine itself and not assigned by an ISP, so they contain no information about machine location.
Came here to say the same thing about link local. Might also be worth mentioning how ISP's generally assign subnets for v6, not addresses, though not entirely relevant here.
I have a /56 and /64 assigned to me I've been learning how to use for my own stuff ;p
Thanks for trying your best to break this down truthfully to people here. When I first saw OP try to convert IPv6 to IPv4 I was like "wtf?" because.. that's not how that works, lol. It's like trying to take somebody's name and convert the letters into numbers and then try to say that equals their GPS coordinates or some shit, haha.
But thinking of this further, though, the use of a local address simply suggests to me that the webserver is being accessed by some other local process on the device. Could be a service or something else, but, probably just interacting with that other component on the system by way of the webhost. Just because something runs a webserver doesn't automatically mean it's being accessed externally.
I will try to explain IPv6 and IPv4 a bit, I hope you'll try to understand what I'm trying to say.
IPv4 is 32-bits long. This means there can be a total of 2^32 IPv4 addresses in the world. That's 4,294,967,296 total. That's not a lot. And as you can imagine, we ran out after a while.
As a result, IPv6 was created. IPv6 addresses are 128-bits long. That means there can be 2^128 of them. I'm not going to try to write out this number, suffice it to say, it is way, way bigger than the number of IPv4 addresses.
Here's the problem: since there are way more IPv6 addresses than IPv4 addresses, the majority of IPv6 addresses can't be converted to IPv4 addresses.
What the script you used is doing, is it takes the 128-bit IPv6 address, completely ditches the first 96-bits, and uses the last 32-bits to convert to IPv4. That is not valid.
Here's how you can verify that I'm correct. You were converting fe80::792b:3e74:df1b:c565, and the script told you it translates to 223.27.197.101. Now try a totally different address, keeping only the last 32-bits, say, 0000::0000:0000:df1b:c565. See what you get.
You can't have 0000::0000:0000.
fe80::792b:3e74:df1b:c565
The double colons after "fe80" and before "792b" indicates that all of the numbers in between are just zeroes, hence the double colons.
So with that said, it should be read as:
::df1b:c565 using your example.
In this case, though, the first 96 bits are very important, because it contains the fe80::, which tells you that it's a link-local address.
https://en.wikipedia.org/wiki/Link-local_address
You have heard wrong. The first almost half of an ipv6 address is the network/route prefix, then a section for subnet and then the host/interface address. No ipv6 address converts to ipv4. I would guess 6to4 tunnels might assign the interface address as the ipv4 address to simplify things, but that is merely a choice of the tunnel operator. Basically it works through the ipv6 address from left to right to get to the destination. The further right in the address you are the closer you are too the destination interface. The tool you are using to covert addresses is fundamentally flawed. Also fe80 is link local. It's specifically allocated for this function. fe80:: is not owned and cannot be owned by anyone. It is similar to class A,B, and C ipv4 networks, however ipv6 doesn't use NAT, so in practice it is a bit different.
Thanks for the explanation.
So what would be the proper way to determine a rough location?
Since these are link-local IPv6 addresses, they were created by the machine itself and not assigned by an ISP, so they contain no information about machine location.
Came here to say the same thing about link local. Might also be worth mentioning how ISP's generally assign subnets for v6, not addresses, though not entirely relevant here. I have a /56 and /64 assigned to me I've been learning how to use for my own stuff ;p
Thanks for trying your best to break this down truthfully to people here. When I first saw OP try to convert IPv6 to IPv4 I was like "wtf?" because.. that's not how that works, lol. It's like trying to take somebody's name and convert the letters into numbers and then try to say that equals their GPS coordinates or some shit, haha.
But thinking of this further, though, the use of a local address simply suggests to me that the webserver is being accessed by some other local process on the device. Could be a service or something else, but, probably just interacting with that other component on the system by way of the webhost. Just because something runs a webserver doesn't automatically mean it's being accessed externally.