[was] addition to ipfw (read vlans from bridge)..

[Yar Tikhiy]

On Mon, Dec 25, 2006 at 12:22:02PM -0800, Julian Elischer wrote:
> Yar Tikhiy wrote:
> >On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote:
> >>Taking to heart comments by Andre and Max (Laier),
> >>I have redone this patch in a different manner.
> >>
> >>The aim is to be able to see inside vlans when bridging.
> >>Now, this is a 6.x patch to bridge.c because that is what we
> >>are using, but I will make a similar patch to if_bridge.c
> >>for 6 and 7 if this meets with approval.
> >>
> >>
> >>Basically if it is a vlan packet, take off the whole vlan header instead 
> >>of just the ether header, but pass to ipfw, an ether header with
> >>the real protocol field substituted in.
> >>when finishing put back everything we removed before.
> >>
> >>
> >>The only addition I'd do to this would be to add a sysctl
> >>to turn it on if people thought it would be break POLA too much
> >>to have it work by default.
> >
> >Excuse me, but I'd like to second Andre's opinion.  We should stop
> >fiddling with the mbuf contents in favour of teaching ipfw (or the
> >interface code between bridge and ipfw) of 802.1q (or its
> >generalisation.)  Now that the 802.1q VLAN technology has been well
> >integrated in the general Ethernet framework by IEEE, there is very
> >litte sense left in such hacks.  If ipfw is to stay L2-agnostic,
> >then let's just pass the offset of the IP header into the mbuf to
> >it.  The 802.1q header is so nice and simple and easy to parse at
> >any level.  So this patch can be OK in 6.x for the only sake of
> >preserving the pfil ABI, but it should die along with it.  An
> >extended interface is apparently called for in HEAD.
> 
> You are the one who complained that it should not be done in ipfw,
> and that we should do it the same way we currently handled the
> removal and re-addition of the ethernet header. So that's what I did.
> (in the bridge code), by teaching the ethernet header handling code
> to handle vlan tags as well.
> 
> If what you are suggesting is that we pass into ipfw an 'offset'
> into the packet as well as the packet, then yes I like that idea,
> but I didn't see Andre suggest it.

Do you consider only ideas by Andre? ;-)  By Andre's opinion I
meant this:

	Please have the ipfw code examine the vlan tag in the mbuf instead of
	fiddling with the mbuf contents.

	-- 
	Andre

If we want ipfw to know of L2, then examining the VLAN tag in it
is OK.  If not really, then ipfw (or any pfil filter) can get just
the offset of IP.

> I can however submit another patch that does that..
> 
> However I'd like to hear from you a response to the mail
> I sent you with a pure cleanup patch that removes mopst occurrances
> of mtod() from ipfw.. if you did not get that email I can resend it
> to you.

Pardon, but you seem to mistake me for Max Laier. :-)  OTOH this is
a good chance for me to ask you a similar question: Did you recieve
my mail on m_copym() usage in the kernel?  I can resend it to you
if you didn't. ;-)  Honestly, I'd appreciate much if you dropped a
line on the topic.

> >There is also work in progress to introduce nested VLANs AKA Q-n-Q.
> >They seem to present a challenge to the scheme you are implementing.
> 
> not a permanent problem.. it could be modified to handle it.
> but I'll take it into account in the next version if
> you think it is a required feature.. what is the maximum
> nesting level?

Infinity.  Why to introduce such a hard limit?  Well, 802.1ad allows
just two tags: the customer (C) tag and the service (S) tag, but
each gets its own ethertype.  C-TAG's is 81-00 while S-TAG's is
88-a8.  I don't think we support the different ethertypes yet, so
Q-n-Q is just the nesting of type 81-00 tags.  (802.1ad appears a
funny reading: it's essentially a patch against the 802.1q text!)
Cisco and Juniper boxes seem to have a limit of two tags as well.
While they may have a reason to (all those ASICs, you know,) we
don't have it.  Allowing for only two tags will tempt us into
duplicating code instead of developing fair algos and interfaces.

-- 
Yar