Hi,
(I didn't find any previous discussion on this topic, my apologies if
it's already been discussed and concluded.)
I'm of the opinion that IPv6 Neighbor Discovery packets are important to
keep the network functioning and perhaps should be classified as network
or internetwork control packets and be prioritized accordingly.
Currently many implementations send Neighbor Discovery traffic using the
default (Best Effort, i.e. zero) DSCP value, and e.g. if other higher
priority traffic (lets say a lot of voice traffic) is competing for
bandwidth then ND may cease to function correctly potentially leading to
all sorts of havoc. Hosts can't get addresses, can't detect if they're
duplicate, can't find default routers, etc. Even if the outage is
temporary, the user experience may already have suffered.
Yes, ND is only used on the link, and no routers would look at the DSCP
in ND messages when forwarding. However, the network stack using
internal QoS mechanisms may experience congestions locally, and link
level devices may experience congestion too and the DSCP is often mapped
into link layer QoS mechanisms.
I initially thought all ND messages (RA, RS, NA, NS, Redirect) could use
the same DSCP. It was suggested to me that maybe the DSCP of ND packets
should perhaps be copied from the packet which "invoked" the ND message,
e.g. from the NS that invoked the NA, or from the data packet which
triggered an NS. And in other cases where there is no direct invokation
it may be a fixed value depending on what the message is trying to
achieve, e.g. periodic RAs, or reachability confirmations could carry
the highest DSCP of all traffic using the cache entry.
What are your thoughts? Can you shed some light on this topic? Does this
fall into implementation defined behaviour?
PS. I discussed this topic briefly on the NetBSD tech-net list, but
quickly realized the specs are open for interpretations and I'm hoping
to clarify that here.
http://mail-index.netbsd.org/tech-net/2010/07/07/msg002209.html
Cheers!
/P
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
