James Carlson wrote: >Darren Reed writes: > > >>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 >> >> > >So ... should that same thing work on Solaris one day or not? > >
I'd like it to, yes. >You previously said that IP Filter doesn't need to know the difference >between broadcast and multicast. But this makes it look as though >knowing that difference would in fact benefit IP Filter. > > It enables better rules to be written, yes. >>>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. >> >> > >I disagree. Setting both flags as an attempted emulation of the BSD >interface _is_ architectural, because it means that consumers of the >interface can't actually rely on it to implement user interface >artifacts such as the "with broadcast" filter. > >I could go along with this _if_ there's a commitment to repair the >interface before changing the stability. "Repair" would mean that >either the flags operate as intended, or that the interface itself is >removed. > > Are you taking to task the setting of both bits as a way of saying "I know it's not unicast, but I can't decide if it is multicast/broadcast" or something else? Darren
