LARTC - Dec 2005 - IPv6 priority in tc filter

Hi,
I have recently started to use ''tc'' on ipv6 traffic and have
come across
an issue with tc filter. As per tc_filter.c in iproute2-050816, to match 
''priority'' of an ipv6 packet, the u32 filter matches against
the first 8
bits of the packet.

 From f_u32.c:

        if (strcmp(*argv, "priority") == 0) {
                NEXT_ARG();
                res = parse_u8(&argc, &argv, sel, 0, 0);
                goto done;
        }

According to RFC2460 for IPv6 (http://www.ietf.org/rfc/rfc2460.txt), the 
first 4 bits of the packet are the version number and the subsequent 8 
bits are the traffic class. Shouldn''t the u32 filter be matching
against
the 8 bits of the traffic class, not the 4bit version+first 4bits of 
traffic class?

The reason this is relevant is because I am trying to match EF traffic 
with a tc filter command:
tc filter add dev eth2.1070 parent 10: protocol ipv6 prio 1 u32 match 
ip6 priority 0xb8 0xff flowid 10:1

i.e. 0xb8 for EF. This, however, does not match my EF packets. If I send 
the following command:
tc filter add dev eth2.1070 parent 10: protocol ipv6 prio 1 u32 match 
ip6 priority 0x6b 0xff flowid 10:1

then it actually does match EF packets. That is, it matches the 4 bits 
of the version (IP v6) and the first 4 bits of the traffic class. I 
believe, the code above should actually read:

        if (strcmp(*argv, "priority") == 0) {
                NEXT_ARG();
                res = parse_u8(&argc, &argv, sel, 4, 0);
                goto done;
        }

though I may be mistaken as to the actual syntax of parse_u8().

-- 
Devanshu Mehta
Advanced Networks and Applications Group
MIT Lincoln Laboratory
(781) 981-1233

As a follow-up to my previous email- it seems the current implementation 
of ipv6 tc filters in iproute2 is based on the obsolete RFC 1883 in 
which bits 4-7 of the IPv6 header were the ''priority''.

If this is the case, I would recommend the change suggested below or a 
new filter for trafficclass that took the bits 4-11 into account for 
matching against traffic class of the packet.

Devanshu
>
> ------------------------------------------------------------------------
>
> Subject:
> [LARTC] IPv6 priority in tc filter
> From:
> Devanshu Mehta <mehta@ll.mit.edu>
> Date:
> Tue, 20 Dec 2005 16:26:46 -0500
> To:
> lartc@mailman.ds9a.nl
>
> To:
> lartc@mailman.ds9a.nl
>
>
> Hi,
> I have recently started to use ''tc'' on ipv6 traffic and
have come
> across an issue with tc filter. As per tc_filter.c in iproute2-050816, 
> to match ''priority'' of an ipv6 packet, the u32 filter
matches against
> the first 8 bits of the packet.
>
> From f_u32.c:
>
>        if (strcmp(*argv, "priority") == 0) {
>                NEXT_ARG();
>                res = parse_u8(&argc, &argv, sel, 0, 0);
>                goto done;
>        }
>
> According to RFC2460 for IPv6 (http://www.ietf.org/rfc/rfc2460.txt), 
> the first 4 bits of the packet are the version number and the 
> subsequent 8 bits are the traffic class. Shouldn''t the u32 filter
be
> matching against the 8 bits of the traffic class, not the 4bit 
> version+first 4bits of traffic class?
>
> The reason this is relevant is because I am trying to match EF traffic 
> with a tc filter command:
> tc filter add dev eth2.1070 parent 10: protocol ipv6 prio 1 u32 match 
> ip6 priority 0xb8 0xff flowid 10:1
>
> i.e. 0xb8 for EF. This, however, does not match my EF packets. If I 
> send the following command:
> tc filter add dev eth2.1070 parent 10: protocol ipv6 prio 1 u32 match 
> ip6 priority 0x6b 0xff flowid 10:1
>
> then it actually does match EF packets. That is, it matches the 4 bits 
> of the version (IP v6) and the first 4 bits of the traffic class. I 
> believe, the code above should actually read:
>
>        if (strcmp(*argv, "priority") == 0) {
>                NEXT_ARG();
>                res = parse_u8(&argc, &argv, sel, 4, 0);
>                goto done;
>        }
>
> though I may be mistaken as to the actual syntax of parse_u8().
>
>------------------------------------------------------------------------
>