tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Setting DSCP for IPv6 Neighbor Discovery packets

Patrik Lahti <> 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

Home | Main Index | Thread Index | Old Index