Yes, I saw you posted this in another thread, checked it, and found that it's just taking the last 4 bytes of the IPv6 address, and turning it into IPv4. That's not correct. Not all IPv6 addresses can be turned into IPv4.
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.
Yes, I saw you posted this in another thread, checked it, and found that it's just taking the last 4 bytes of the IPv6 address, and turning it into IPv4. That's not correct. Not all IPv6 addresses can be turned into IPv4.
In fact, if you read the code, you see the comment at the top sends you to this Stackoverflow answer: https://stackoverflow.com/a/23147817/11404332
The explanation is there as well.
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.