udp: honor IPV6_TCLASS socket option for UDP/IPv4 packets

[tuexen]

Summary

Honor the IPPROTO_IPV6-level socket option IPV6_TCLASS when sending an UDP/IPv4 packet on an AF_INET6 socket.

[glebius]

P.S. This actually reminds me that many years ago, I tried to unionize IPv6 specific fields of inpcb with IPv4. This utterly failed for 4-in-6 connections, so I quickly reverted without due analysis. Maybe should be looked at again.

sys/netinet/udp_usrreq.c

1176

I don't think that style enforces that much syntactic sugar. if (flags & PRUS_IPV6) { should be just fine. The file actually prefers your form, but without extra pair of parentheses. Please at least remove the extra pair.

1179

This cast raises a question why do we declare ip6po_tclass in struct ip6_pktopts as int? In ip6_output() we use not more than 8 bits of it, too. When we set it via ioctl(IPV6_TCLASS) we do the same validation. Given that we actually care about size of this structure (see 530c2c30b0c75f1a71df637ae1e09b352f8256cb by Drew), shouldn't we make this field 8-bit?

[bz]

sys/netinet/udp_usrreq.c

1176

No it is not.

Do not test without a comparison, or with unary ! (except for booleans).

(style.9)

So what tuexen has is just fine.

1179

And please use uint8_t and not u_char if you do as this is networking and not text. We need 7bit u_char one day again and sooo much stuff will explode expecting octets ;-)

[tuexen]

Remove extra pair of parentheses, which was a leftover...

[tuexen]

sys/netinet/udp_usrreq.c

1176

I don't think that style enforces that much syntactic sugar. if (flags & PRUS_IPV6) { should be just fine. The file actually prefers your form, but without extra pair of parentheses. Please at least remove the extra pair.

I removed the extra pair of parentheses. This was a leftover of finding the variant of the patch to put up for review.
As bz@ mentions, the !=0 comes from style.9. If I should remove it, I will do.

1179

This cast raises a question why do we declare ip6po_tclass in struct ip6_pktopts as int? In ip6_output() we use not more than 8 bits of it, too. When we set it via ioctl(IPV6_TCLASS) we do the same validation. Given that we actually care about size

The size of the value of the cmsg and the size to be used in [gs]etsockopt is specified in RFC 3542, but we can store it differently.

of this structure (see 530c2c30b0c75f1a71df637ae1e09b352f8256cb by Drew), shouldn't we make this field 8-bit?

Can we split this in two things:

1. Let us get the specific problem fixed. It is relevant for using ECN with QUIC.
2. Cleanup the handling of various options in consistent way in a second step. I do see the handling of the TTL/hop limit there, too.

1179

And please use uint8_t and not u_char if you do as this is networking and not text. We need 7bit u_char one day again and sooo much stuff will explode expecting octets ;-)

tos is declared as u_char, other casts in this function use u_char for tos and the type in struct ip uses u_char. I agree, uint8_t is much better, but that should be changed in a consistent way, I think.

[glebius]

I did not mean that changing of size of ip6po_tclass in struct ip6_pktopts should be part of this change, of course. Just noticed this thing and suggested an improvement.