Reduce patch to only add the missing voice-admit code point.

In D29069#651242, @rgrimes wrote:

Given the issues I would rather NOT add dscp support at all, until these issues can be addressed from down/upstream? The current situation, both in pfsense and freebsd is poor at best and may actually be one of the sources of issues we are seeing in our ECN data collection work. We know for a fact people are being told to use these ancient and obsolete TOS values by looking for them in blog posts and how-to's. Using the pry bar that is "reduce diffs between" as a reason to add a bad situation is an ever worse situation!

In D29069#651199, @rscheff wrote:

I suggest to rework the parser in such a way, that the named DSCP codepoints can only be used with the DSCP keyword, and the legacy TOS values only with the keyword TOS. And the parser can deal with the necessary left-shift (the DSCP input value should be 0..63).

In D29069#651186, @rgrimes wrote:

I have a concern here, some of which goes beyond just this change, about aliasing DSCP to TOS. We (a small congestion control research group) have found that due to ambigious manual pages, headers and other factors, some present in PF it appears are causing mismarked traffic on the internet. DSCP is shifted left by the 2 ECN bits, the manual pages and any other documentation MUST be made explicity clear about this fact as to if your supplying the values as specified in the RFC"s on DSCP (unshifted) or are you applying TOS bits that may or may not have the ECN bits masked out.

Seems like a fairly obvious thing to fix, yes.

In D29056#650734, @rscheff wrote:

perhaps replace those with
iptos = IPV6_DSCP(ip6) | IPV6_ECN(ipv6);
in this patch too?

Simplify retrieving the DSCP bits

In D29034#650129, @donner wrote:

How common is this requirement?

I think I'd prefer that we didn't do this.

That would be my assumption.

Thanks for the fixes.

It'd be nice to make ng_macfilter_test use atf-sh, but this is progress.