Re: [PATCH] don't try to track broadcasts or multicasts (4/4)

[Henrik Nordstrom <hno@marasystems.com>]

On Sunday 09 June 2002 19:18, Harald Welte wrote:

> the results are actually quite interesting - but maybe there's a
> particular reason for TCP behaving different than other
> protocols...

Broadcast or multicast does not apply to TCP. It does in the other 
protocols (ICMP / UDP). A broadcast or multicast packet received by 
TCP is with no doubt a martian as there is no aspect of TCP that can 
be safely used on other than unicast links.

Linux ICMP seems to have some provision to filter out broadcasts when 
they do not make sense, but it could do better I think..

But I think this aspect of the Linux IP stack can be ignored local 
traffic. If you receive a broadcast frame addressed to your unicast 
IP address then the processing should not be much different from 
receiving a broadcast frame addressed to your broadcast address. The 
likelyhood that there is TCP/IP implementations sending you broadcast 
link frames when unicast was intended is very low.

But the reverse cannot be assumed. There is special applications of 
TCP/IP where multicast is used as local transport. This can be seen 
in some odd active-active load balancing products where all servers 
must see all packets, so a Linux server/router can be required to 
receive unicast IP frames from a multicast link source address or to 
sent unicast IP to a multicast link address..

If this is considered in a bridge environment using the 
bridge-netfilter integration then obviously no optimization based on 
unicast/multicast link transport can be done on forwarded packets..

Regards
Henrik