IPv4 to integer
An IPv4 address is genuinely a 32-bit integer; the dots are a display convention. Storing it as an integer makes range queries trivial; a subnet is a contiguous span of integers, so "is this address in this network" becomes a simple comparison rather than string parsing. It is why databases handling IP data almost always store the integer form.
An IPv4 address is four bytes packed into a 32-bit integer. 192.168.1.1 becomes 3232235777, that is 192×2²⁴ + 168×2¹⁶ + 1×2⁸ + 1. The dots are presentation, not structure.
How to convert an IP to an integer
The integer form makes subnet arithmetic straightforward. A /24 network is 256 consecutive integers, so checking membership is a range comparison rather than mask manipulation on strings. It also sorts correctly, which dotted-quad strings emphatically do not. Sorted as text, 10.0.0.9 comes after 10.0.0.10.
The thing that bites is the sign. Every address from 128.0.0.0 upwards is larger than 2147483647, so it does not fit a signed 32-bit integer. 192.168.1.1 is 3232235777; put that in a signed INT column and it reads back as −1062731519. Store it in an unsigned 32-bit column, or a 64-bit one, or use the type the database already has: Postgres has inet, and MySQL pairs INET_ATON with INT UNSIGNED.
One parsing difference worth knowing before you convert in two places and compare. Each octet is read here as decimal, so 010.0.0.1 is 10.0.0.1. The classic C inet_aton reads a leading zero as octal and makes the same string 8.0.0.1, and it accepts short forms such as 127.1 that this refuses outright. Parsers disagreeing about the same address string has been the basis of real access-control bugs, so never let two of them decide the same question.
Questions
3232235777.
Because ranges and sorting work properly on integers and not at all on dotted-quad strings.
It went into a signed 32-bit column, which cannot hold anything from 128.0.0.0 up. Add 4294967296 to recover it, and use an unsigned or 64-bit column instead.
Here, yes — every octet is read as decimal. inet_aton reads the leading zero as octal and gives 8.0.0.1, which is why mixed parsers cause security bugs.
4294967295, which is 255.255.255.255.
No. IPv6 is 128 bits and needs a big integer rather than a 32-bit one.
Because "10" sorts before "9" as a string. Numerically it does not.