Now that everyone is usingIPv6 () it might be time to start playing with it. Postgres has had full IPv6 support for years, so Postgres is a good place to start, particularly with IPv6-aware data types.
SinceIPv6 addressesare 128-bits instead of IPv4's 32-bits, they can be quite long, e.g.2001:0db8:85a3:0000:0000:8a2e:0000:7334.As you can see, it is made up of eight quad-hex segments, separated by colons. To shorten the text representation, leading zeros in any quad-hex segment can be removed, though an all-zero quad still requires a zero. In addition, the longest string of all-zero quads can be abbreviated with double colons. This can be illustrated in Postgres:
In the output,0db8becamedb8, and:0000:0000:became::,and the final0000became0.An address with many leading zeros, e.g.localhost (0000:0000:0000:0000:0000:0000:0000:0001),gets dramatically shortened using these rules:
This highlights perhaps the most confusing aspect of IPv6 addresses — you can't just visually compare two IPv6 addresses to check for equality, like you can for IPv4. You must use the IPv6 rules for comparisons.
Use of colons is strictly for IPv6 addresses, i.e.,1::127represents a 128-bit IPv6 value, not a 32-bit IPv4 one, as illustrated by the IPfamily()function:
SELECT '1::127'::inet = '18.104.22.168'::inet;
Postgres is a fun, interactive way to play with the IPv6 address rules, because we are all going to have to learn them eventually.