Patrik Lahti <plahti%qnx.com@localhost> writes: > I'm of the opinion that IPv6 Neighbor Discovery packets are network > control packets and hence they should be prioritized accordingly. In > fact, network control should probably be the highest priority. At most they are internetwork control (old tos 6); network control is about the layer used by the internetworking layer. > Currently Neighbor Discovery traffic is sent using the default (Best > Effort, i.e. zero) DSCP value, and e.g. if other higher traffic (lets > say a lot of voice traffic) is competing for bandwidth then it may > cease to function correctly potentially leading to all sorts of havoc. What do the standards say? What do other operating systems do? > Yes, ND is only used on the link, and no routers would look at the > DSCP in ND messages. However, the network stack, e.g. using ALTQ may > experience congestions locally, and link level devices (e.g. switches) > may experience congestion too and the DSCP is often mapped into link > layer QoS mechanisms. That's fair. > What are your thoughts? Shouldn't be too hard to change right? I'm > thinking it's simply a matter of a one line change in the various > nd6_*_output() routines and setting IPV6_TCLASS in rtadvd/rtsold. > > Should it be sysctl'able or hard coded to a particular value? What > default? I'd lean towards 0xe0 at the moment, as it's compatible with > IP Precedence usage and IIRC I think I've seen packet traces where it > was used as well. Unless the standards say "do it this way" and we comply, anything like this should be optional/sysctlable.
Attachment:
pgpNYJEQNkQc1.pgp
Description: PGP signature