Fabian Knittel schrieb: > Peter Stuge schrieb: >> It would be nice to be able to use VID 0 to mean untagged packets. > > Hm, nice idea. I'll implement it in my next round of patches.
I've just noticed a detail that might warrant discussion. To make sure we're talking about the same thing, this is how I intended --vlan-tag 0 to be handled: Packets coming in from the tap device: If the packet has no 802.1Q header or the 802.1Q header's VID field is 0, the vid is assumed to be 0 and the packet will be forwarded to all clients who's --vlan-tag is set to 0. Packets outgoing via the tap device: Packets originating from clients who's --vlan-tag is set to 0 are passed on to the tap device without change, i.e. no 802.1Q header is attached or removed. A potential 802.1Q header already present within the packet is left untouched. This would allow the Priority Code Point (PCP) field to be used. Now, to the slight difficulty: What happens with outgoing frames from clients who's --vlan-tag is set to 0, where the frame contains a 802.1Q header with VID field != 0? Pushed onto a network which uses vlan tags, this would allow a client to inject packets into a different network. (For --vlan-tag != 0 this is no problem, because we unconditionally wrap the packets in 802.1Q headers with a new VID.) Possible solutions: a) Inspect outgoing packets for --vlan-tag == 0 clients. Drop packets that have a VID != 0. b) Always wrap outgoing packets with 802.1Q headers and set the VID to 0. (This would make the code-patch uniform for all --vlan-tag values.) I think I slightly prefer solution a), as it allows the PCP field to be used and doesn't add needless overhead to outgoing packets. Cheers Fabian
signature.asc
Description: OpenPGP digital signature
