On Sat, Jan 22, 2005 at 10:50:18AM +0500, Boris Kovalenko wrote: > Hello! > > 802.1p is just a 3 bits of 802.1Q header. Based on it Layer 2 > devices may assign packets to different output queues (more simple, > 802.1p > is QoS at Layer 2). So, You have right, this value differentiates packets > within a vlan and Layer 2 device may make a decision what packets should > be processed first. Of course, we may give the application the ability > to set this value itself, but what to do with old applications that have > no knowledge about this ability? Ok, You suppose to mark packets within > PF/IPFW. Yes, the idea is good too, but what to do on routers not > running any firewall software? So, may be right way will be:
I'm slightly concerned about the old application issue, but more about binary-only code then applications with source. I don't think the issue of forcing people to run a firewall is significant. These days you can just load one since PFIL_HOOK are non-optional. There's also the fact that this is a feature that is not useful unless you understand the implications (including the fact that you can't trust the values unless you trust the wire and those on it.) Priorities have the potential to be a powerful tool, but I think there are a lot of subtleties when you start using them on end-hosts. > 1. Mark 802.1p at application level > 2. Mark 802.1p at PF/IPFW level. But we shold foresee a keyword to trust > application level information or override it. For example > ipfw add 802.1p trust 6 on any to any ssh <-- this trust application > level information and set 802.1p to 6 if it is omitted > ipfw add 802.1p override 6 on any to any ssh <-- this silently set > 802.1p == 6, regardless of application I'm not sure why you need trust and override. It seems like you only need the ability to set or remove values as well as acting on already attached tags (which we're going to need to carry around as m_tags so we can filter on and modify them in conjunction with layer 3 information). > 3. Mark 802.1p at vlan drivers like 2 > ifconfig vlan0 > vlan: 100 802.1p: 6 CFI: 0 mode: trust vlandev: bge0 > Here we are trusting received from low level information and set 6 if it > is omitted > ifconfig vlan0 > vlan: 100 802.1p: 6 CFI: 0 mode: override vlandev: bge0 > Here we silently set 6. If you're not going to do separate interfaces per priority (or perhaps set of priorities[0]) I'm not sure what the point of having the interface do anything is. Filtering is the job of the firewall so I'm not convinced we should be doing it in the vlan device. There's also the complication that we need to handle the vlan=0 case which shouldn't be treated as a vlan at all and should be decapsulated in the actual device without a trip through the vlan code. My suspicion is that we need to rethink the current separation of ether and vlan code. Making vlans less optional and doing more of the handling in ether_input and ether_output might be a good thing. -- Brooks [0] What I've read says that many switches group sets of priority values together reducing the set of valid values. -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp6YXSsIRFVK.pgp
Description: PGP signature
