Converting an IP address to a number:

Question: When I convert the IP address 192.168.115.67 to a number, is it done like this:

192*256³ + 168*256²+115*256¹+67*2开发者_C百科56⁰ = 3232265027

or like this:

192*256⁰ + 168*256¹+115*256²+67*256³ = 1131653312

I find both variants online, and frankly it doesn't matter as long as I do all the internal IP-range comparison using the same conversion process variant. But I want to calculate the IP V6 from the IPv4 address, and it seems both variants are on the web... resulting in different IPv6 addresses, and only one can be correct...

I use the 1131653312 variant, as 1131653312 is the variant I saw .NET giving me, but 3232265027 is the variant I used when I did it in C++, and that is also the variant I find on the web for IPv4 to IPv6 conversion, and which I used before I saw that .NET uses variant 1131653312 ...

It is definitely first one. You can ping and see how ping utility convert it to a.b.c.d notation. If you going to do this conversion I recommend expression: (a << 24) | (b << 16) | (c << 8) | d

The method resulting in 3232265027 should be correct, as the first number is stored in the highest bits of the IPv4 compatibility part of IPv6:

0000:0000:0000:0000:0000:ffff:AABB:CCDD

where

AA = 192
BB = 168
CC = 0
DD = 1

etc.

https://wikipedia.org/wiki/IPv6

Also, you can't have a 256 in an IP address. The values are 0 - 255 each.

Numbers are sent in big-endian order over the wire, which is the same as the way they are written (192 is the most significant byte). Thus the first number is the "correct" one. The other variant is how the same bytes will be interpreted on a little-endian architecture, hence the .Net behaviour.

Having said all that, I'm really not sure what the question is, so I can only hope that this exposition constitutes an answer of sorts.

The difference has to do with endianness. You are storing it in an integer, but different processors have different byte orderings for their integers (big or little end first). However, that number has to go out over the line, so IP has a specific order it needs the bytes transferred in. That order looks different to bigendian and littleendian machines.