On Wed, 29 Aug 2001, David Stevens wrote:
> I think a simple interpretation for the flag is best (for example,
> "will forward packets received on this interface" with the implication
> from that that you join
> the all-routers group, set isRouter on NA's, etc.) Forward flag not set
> should
> be "won't forward packets received, won't set isRouter, etc", but will
> still forward
> packets received on other intf's to it, IMHO.
Simple is good (, as long as it doesn't limit your options too much).
> There will always be scenarios that aren't covered-- even overloading
> "input and output" breaks at some point and you split forwarding to "input"
> and
> "output" flags to prevent forwarding in cases like your example, you can
> also
> imagine 4 interfaces A, B, C, D where you might want A & B hosts to talk
> to each
> other and C & D hosts to talk to each other, but not A-C, or A-D, B-C
> or B-D. No input/output forwarding flags combination covers that.
> At some point, you need a filter with complex rules for the complex
> cases. I would chuck the global flags and just use interface forwarding for
> input,
> routing table, routing protocols, etc (and a filter, if needed) for output
> decisions,
The more complex scenarios are left to be handled with netfilter.
However, netfilter cannot control what bits you put in ICMPv6 ND messages
and the like though, only whether forwarding should be possible or not.
IPv4 doesn't have stuff like IsRouter bit in _normal_ ND messages, which
makes it more challenging to be able to control forwarding/ICMPv6
interaction of the interfaces, so direct comparison is not really
applicable.
These problems basically come up if you there would be only one flag
"enable all/disable all". With interface-specific flag, or the
current (more complex) approach, these problems can be avoided AFAICS.
> and leave "all" as a convenient shorthand for setting the per-interface
> flags.
> In that case, devconf shouldn't be checked, just the interface flag.
Based on IPv4, this would be the "intuitive" approach.
I'm not sure whether the current approach is due to (older) specification
that "either node (and all its interfaces) is a router or it is not", or
whether there were any other technical reasons for it, e.g. address
scoping.
Do you remember this/care to comment on the ideas, Alexey?
(I'm sure you would anyway, but still... :-)
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
|