This is a static archive of our old Q&A Site. Please post any new questions and answers at

ip.addr is Ipv4. ipv6.addr is ipv6. a case for ipv4.addr and ip.addr is either?


ip.addr is the IPv4 address. ipv6.addr is the IPv6 address.

I think, it would make sense for ip.addr to be neutral and be the inet_ntop() of whichever IP protocol type it is, and ipv4.addr and ipv6.addr to remain proto specific.

is there eg a way to say 'if its ipv6, put ipv6.addr in this field, otherwise put ip.addr in this field' as a compact conditional test?

asked 14 Jul '15, 11:12

geeohgeegeeoh's gravatar image

accept rate: 0%

One Answer:


In hindsight this would be great. The one challenge I see is that one needs to create a new ftype 'FT_IP' which fans out to IPv4 or IPv6 based on.... heuristics? There are aggregate fields (like ip.addr), but not types (like the proposed FT_IP).

answered 14 Jul '15, 22:35

Jaap's gravatar image

Jaap ♦
accept rate: 14%

I'm a realist and I understand ip.addr is glued to ipv4 forever unless a significant change in behaviour is accepted by somebody in code, and documented to users.

but inet_pton() and inet_ntop() exist for a reason. ip.type would signal which ip.addr it was, but the stringprep is dealt with by libc functions already!

the second part of my question stands: is there a syntax for (if ip then ip.addr else ipv6.addr) in a -e field?

(14 Jul '15, 23:15) geeohgeegeeoh