use IANA family numbers?

[Habbie]

We use '4' and '6' to indicate v4 and v6. These numbers do not appear like that in any registry. edns-client-subnet and clientid use https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml. @arjenz noticed during wireshark implementation that our deviation makes his code longer as he cannot rely on the already present IANA list.

[Habbie]

IANA family numbers are 16 bits, this costs us our 4 bits of extensibility but we could use 65535 to signal some future extension perhaps.

[Habbie]

These numbers do not appear like that in any registry

I lied - https://www.iana.org/assignments/version-numbers/version-numbers.xhtml

[Habbie]

So, the argument is somewhat weak but I'd still like to make a conscious decision here.

[raybellis]

The 4 bit field in XPF indicates the L3 transport protocol version, but we only support IP anyway.

[Habbie]

Moved the QUIC stuff to #10

[arjenz]

Implemented lookup for RFC2780 / https://www.iana.org/assignments/version-numbers/version-numbers.xhtml in the Wireshark dissector, https://code.wireshark.org/review/#/c/22803/ So the only argument left now is being in sync with edns-client-subnet and clientid :)

[raybellis]

On 26/07/2017 14:19, Arjen Zonneveld wrote:

So the only argument left now is being in sync with edns-client-subnet and clientid :)

There's no argument - EDNS Client Subnet used the wrong one ;-)

Since clients only access DNS over IP, and prefix lengths have no semantic meaning in some of the non-IP family AF_XXX protocols, why use a registry with illegal values when the only sane ones are AF_INET and AF_INET6.

[Habbie]

Alright, settled!

[raybellis]

BTW, the IANA Address Family Registry and the BSD socket AF_INET and AF_INET6 macros don't even use the same values.

[Habbie]

BTW, the IANA Address Family Registry and the BSD socket AF_INET and AF_INET6 macros don't even use the same values.

I noticed that when getnameinfo refused to convert an IP in AF 4 ;)