James Carlson wrote:
>Darren Reed writes:
>
>
>>James Carlson wrote:
>>
>>
>>>Do the clients using this interface need to know the difference
>>>between multicast and broadcast in order to function correctly?
>>>
>>>
>>>
>>>
>>No.
>>
>>
>
>So, then, why distinguish?
>
>It looks like you're trying to emulate the BSD {MSG,M}_[BM]CAST flags,
>but I'm unsure why that's a useful thing when the emulation (as
>defined) doesn't work, it seems like there's no plan to make it work,
>and the consumers don't need to know that information anyway.
>
>
IPFilter needs to know whether or not the packet is unicast
or not so that you can do policy based routing without copying
over broadcast/multicast packets, e.g.
pass in on bge0 to bge1:192.168.1.1 from any to any with not mbcast
This works pre-S10U4 and is broken in nevada/s10u4+.
On BSD, the same rule works (applying to both broadcast and multicast)
but because of the flags that are specific to broadcast/multicast are
present in their equivalent of the mblk_t, it is also possible to write
rules that are specific to one, e.g:
block in quick all with broadcast
>...
>
>For what it's worth, I care about this because it seems like there's a
>plan to make this interface open to projects other than IP Filter. As
>just a private interface, the change probably falls below the radar.
>
>
Yes, I'm with you there.
>>>If so, then why not have this interface resolve the amibiguity? That
>>>can be done by checking the destination address (dl_dest_addr_*) when
>>>you see that dl_group_address is set.
>>>
>>>
>>>
>>>
>>Even if they did, once the packet reaches IP, it's beyond the
>>scope of IP to determine what the MAC destination address
>>meant at the MAC layer.
>>
>>
>
>I don't think that's the point. The point is what sort of
>functionality makes sense for users of this interface. What gyrations
>IP may need to go through to provide the needed information are a
>separate design and implementation matter (and I don't think I share
>the concern about "scope" -- our IP _implementation_ is already hip
>deep in MAC layer trivia, and doing a compare between dl_dest_addr_*
>and dl_brdcst_addr_*, to both of which IP has ready access, shouldn't
>be hard).
>
>
I'll look into this but it makes no difference to the architecture,
only the implementation that would enable setting just one of
the flags rather than both.
Darren
