4 ms·

Parsing IPv6 also requires some thought! Consider 0000:0000:0001:0002:0000:0000:dead:beef - 0000:0000:1:2::dead:beef - ::1:2:0000:0000:dead:beef - ::1:2:0:0:

• majke 7y ago
  Digging more about IPv6 representation: - It's possible to stick "::" in many places - It's possible to have :0000: before or after "::" - leading zeros (:0001: is the same as :1:) - "Text Representation of Special Addresses", so the ::192.168.0.1 representation - hex uppercase vs hex lowercase see https://tools.ietf.org/html/rfc5952 https://tools.ietf.org/html/rfc5952
  • Already__Taken 7y ago
    that rfc says upper/lower doesn't matter? Am I wrong?
    • deathanatos 7y ago
      That's the point: because it doesn't matter it provides two representations for the same semantic thing.
      • jolmg 7y ago
        Well, that's just like IPv4, then. They can still be canonicalized, if you need to compare them.
  • kbirkeland 7y ago
    Also due to the ambiguity of ports also using a colon delimiter, the IPv6 address may be in brackets: [::1:2:0:0:dead:beef]:443 And link-local addresses are mandatory and scoped per interface, so they need a zone id supplied as either an integer or interface name: fe80::1:2:0:0:dead:beef%eth0
• thwarted 7y ago
  That's why there are library routines for this, inet_pton and inet_ntop. No one should need to parse these addresses themselves.