Mike,
Thanks for your comments. See inline:
Note that all VLAN packets have SAP value
0x8100. Therefore, we propose that all VLAN packets be sent upstream
if the stream is in promiscuous mode.
Both of these statements are true only on the physical PPA, not on VLAN
PPAs; this should be made clear somehow. (A VLAN tagged packet actually
has *two* SAPs, one on the physical stream and another on the VLAN
stream.) Also, I'd add the word SAP or DL_PROMISC_SAP to the second
sentence above ("... is in SAP promiscuous mode") just to be perfectly
clear.
Sure. I will make both clear.
As a result, if snooping on a
physical link, VLAN tagged packets should be visible if they pass the
physical-layer filter.
I'd call that "physical address" filter instead of "physical-layer".
In the "Data Link Provider Interface Specification", it is:
"DL_PROMISC_PHYS indicates promiscuous mode at the physical level"
I will change it to physical-level filter to make it consistent with the
specification.
As already discussed, network observation applications (which make use
of the DL_PROMISC_SAP promiscuity and the DLIOCRAW ioctl) will be
able to see VLAN packets on physical links, and will not strip the VLAN
tag in a VLAN packet, even on a VLAN link.
Wording nit: the subject seems to change between the two verb clauses of
this sentence (this case doesn't impact whether *applications* strip VLAN
tags). Maybe s/will not strip/will see/ .
Today. Some drivers do strip the VLAN tags on a VLAN link even when it
is in raw mode. This case also tries to make this clearly defined.
In theory, VLAN packets are just packets of SAP value 0x8100. They
are nothing more special than other packets, for example, IP
packets.
I'd replace "In theory" with "To the physical link".
Okay.
One final question: VLANs are often used to implement security domains or
other forms of isolation. The model defined by this case does seem to
allow "leakage" between VLANs if a VLAN link consumer uses raw mode to
transmit a "forged" VLAN header or a packet with no VLAN tag. In the near
future we may be granting DLPI layer access to zones or virtual machines
that are not trusted with full privileges in the global zone/physical
domain. Does this create a problem? Should the VLAN software prevent it?
Should we specify that enforcement now as part of this case? Should we at
least allude to it with a statement like the following?
It is considered an error to request a VLAN link in raw mode to transmit a
packet with an incorrect header (one that specifies some other VLAN) but
the provider interface will not necessarily prevent the transmission or
report an error. Software that needs to transmit on multiple VLANs should
use the physical link or multiple VLAN links as needed.
Thanks. I will add this.
- Cathy
_______________________________________________
networking-discuss mailing list
[email protected]
