On 10-07-07 02:38 AM, Robert Elz wrote:
Date: Tue, 06 Jul 2010 20:37:22 -0400
From: Patrik Lahti<plahti%qnx.com@localhost>
Message-ID:<4C33CC42.7040902%qnx.com@localhost>
| I'm of the opinion that IPv6 Neighbor Discovery packets are network
| control packets
I disagree. With the possible exception of RA's (I'm not sure if your
use of the "IPv6 Neighbor Discovery" term includes everything, or just NS/NA
the elements of the part of ND that is ARP like), and just perhaps unsolicited
NA's after an address change, there's nothing about ND that is network control.
Network control is about keeping the network working - which could include
stuff needed for loop detection (were anything of the kind needed), and
certainly, I think, RA's that advertise prefixes.
On the other hand, NS/NA just allow hosts to use the network - how important
that is depends entirely upon how important the communications are, which
will vary from host to host, and with each of its peers, and even from time
to time depending upon why it is sending packets.
The traffic class of an NS should be the same as the highest traffic class
of the packets that are to be communicated - which in practice, means the same
as the packet that triggered the NS, unless ND was already in progress with
a higher traffic class. A reply NA should have the same class as the ND
that requested it. "Refresh ND's" (if we generate such things) can be any
random (fairly low) class. NS used for DAD should be nothing at all.
RS should also be 0. RA (and perhaps an unsolicited NA, that one would
take more thought) might be worthy of being considered network control.
Some very good points Robert, Maybe I should ask this on an IETF list?I was thinking of ND in the broadest sense, including RAs, NS/NA for neighbor resolution, Duplicate Address Detection, reachability, address change, redirects, all of it.
But I think you're right that the class should depend on what the ND message is trying to accomplish.
Here are some further thoughts on what you suggested:Since RAs are critical for autoconfiguration they should be network/internetwork control. I include RAs without prefixes in that too because hosts need to receive those too for autoconfiguration the default router. However, I think probably DAD should be included there too, because it also keeps the network working. If DADs get lost then that may result in duplicate addresses.
Responses should probably use the DSCP from the packet they respond to. Except RA in response to RS, they should probably still be prioritized as above since they're sometimes responses to many RSs.
And when the ND protocol is invoked as a result of another packet it should probably reflect the same DSCP as the invoking packet, i.e. NS for neighbor resolution, redirects, and RSs. If RSs are too low priority then hosts will have a hard time "coming on to" the network because they don't get an address or a default router. Yes, they probably "eventually" get an RS through or receive the prioritized periodic RAs, but again user experience is already affected if plugging into the network doesn't get you network connectivity within reasonable time.
The IPv4 Router Requirements RFC says ICMPv4 should copy the ToS from the invoking packet, so this is hint in that direction.
Unsolicited ND used for reachability checks should probably fall into the same category of using the DSCP of the invoking traffic, although it may add complexity to have to remember the highest priority of all traffic that used the ND cache entry.
OTOH, one could argue it is simpler to just set all ND traffic to the same (sysctl'able) DSCP.
I guess it's really open to interpretation whether ND is network or internetwork control, whether it's only partly one of those, and/or should inherit the DSCP of invoking packet. The RFCs have mentioned routing is. Is it a stretch to say ND is routing or not...? It after all partly about finding the packet's way in the "neighborhood" (the link) and also about nodes getting their addresses which is pretty fundamental.
Cheers! /P