lkml.org 
[lkml]   [1998]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Multicast and Masquerade clash
Hi,

Nigel Metheringham:
> A shortish term fix, which I don't like much since it puts some policy
> into the kernel, would be to make the demasquerade conditional on the
> stuff not being multicast. Multicast has a well defined address range set
> so detecting if the source/dest are multicast sets should be easy enough
> to do.
>
Multicast addresses need special handling anyway, so that isn't really a
problem IMHO.

> Outgoing stuff can be handled by firewall rules (different problem to that
> described above anyhow). You would normally use a router of some sort
> rather than trying to shove it down the masq tunnel anyhow.
>
Right. (Or an mrouted-controlled tunnel, in which case it's unicast again.)

> This still doesn't fix what happens if someone wants to bind a unicast
> port into the masq range.
>
Nobody should need to. Only multicast is special that way.

--
Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.145 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site