5

I have traffic shaping with tc and htb in place and everything works fine for IPv4. Now I want to limit the bandwidth for incoming IPv6 ssh/sftp traffic to some reasonable amount, so it doesn't interfere with more critical traffic. In short, nothing worked:

tc class add dev eth0 parent 1:0 classid 1:14 htb rate 3000kbit ceil 3000kbit prio 3

ip6tables -A POSTROUTING -t mangle -o eth0 -p tcp --dport 22 -j MARK --set-mark 14
tc filter add dev eth0 parent 1:0 protocol ip handle 14 fw flowid 1:14
# or
tc filter add dev eth0 parent 1:0 protocol ipv6 u32 match ip6 protocol 6 0xff match ip6 dport 22 0xffff flowid 1:14
# or variations of these...

How does one traffic-shape IPv6 data with tc?

2
  • Define "nothing worked". Dec 20, 2012 at 0:52
  • other than my IPv4 filters (for example IPv4 sftp traffic rules) the IPv6 traffic shaping rules do not reduce the speed of my IPv6 sftp transfers.
    – Thomas
    Dec 20, 2012 at 11:23

2 Answers 2

2

At least on my modem/router (Actiontec C1000A, BusyBox v1.17.2, kernel version 2.6.30), I was able to match directly on the destination IPv6 address using tc (i.e. no need for ip6tables to mark the packets):

tc class add dev eth0 parent 1:0 classid 1:14 htb rate 3000kbit ceil 3000kbit prio 3
tc filter add dev eth0 parent 1:0 protocol ipv6 prio 16 \
    u32 match ip6 dst $IPV6_ADDR flowid 1:14

So, it's a guess, but I should think the following would work:

tc filter add dev eth0 parent 1:0 protocol ipv6 prio 16 u32 match ip6 dport 80 flowid 1:14

Or, using your ip6tables mangling:

tc filter add dev eth0 parent 1:0 protocol ipv6 handle 14 fw flowid 1:14
1
  • The IPv6 header size is much more dynamic than IPv4, with many optional packet structures that can be appended to the header. The IPv6 source and destination addresses are pretty static, but anything in the layers below must be matched by "peeling off" each precedent layer. Your dport example even lacks the protocol (which would be significant, you can't just assume it will match both TCP and UDP like how iptables do). To be able to understand that the u32 classifier would have to learn how to read all optional IPv6 packets even eventually find the offset for the start if the TCP header. Dec 12, 2021 at 15:31
1

Unfortunately tc does not work yet for IPv6.

Quote:

The Routing Policy Database (RPDB) replaced the IPv4 routing and addressing structure within the Linux Kernel which lead to all the wonderful features this HOWTO describes. Unfortunately, the IPv6 structure within Linux was implemented outside of this core structure. Although they do share some facilities, the essential RPDB structure does not particpate in or with the IPv6 addressing and routing structures.

This will change for sure, we just have to wait a little longer.

Source: http://lartc.org/lartc.html#AEN1446

If anyone knows if this is fixed from a certain kernel version on, or if there is a plan to fix this in a future version, feel free to update!

Possible workaround (not tested by myself so far) is to tunnel the IPv6 traffic (SIT tunnel) and filter on the IPv4 packets that contain the IPv6 packets.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .