On 20/08/16 23:05, Slawa Olhovchenkov wrote:
I am think this substitution is very bad idea (by design).
Also, on transmit side this is must be irrelevant on received L2
header (and this in many cases this is will be L2 unicast packet). For
other cases packet will be created on host and don't have any received
information.
Whilst I agree with your concerns about multipoint, I support the
motivation behind Ryan's original change: optimize the common case.
On the other hand, I'm suggesting a slight extension to it -- one which
would probably require adoption across some L2-exposed subsystems, or
anywhere which might reinterpret an M_BCAST from re-entrant
encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon
then decides it needs to be NATted and forwarded somewhere else).
Whilst I believe the scope for problems like this are limited (and
perhaps to Netgraph permutations), I do believe they exist, and should
be defensively coded for.
And: If, the logic for this can be factored out into one additional bit,
in a conditional branch (or small set of those) in terms of delta to the
existing FreeBSD data plane path -- i.e. my suggestion;
Then: we should be able to preserve correctness for multipoint
configurations, without sacrificing performance.
Or, a possible tie-breaker:
...we ensure that M_BCAST is cleared at all times before possible
re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols
decide themselves if re-entered about M_BCAST based on DMAC.
On received side for host relaing on L2 information for accepting
packet as host targeting sound like security hole.
In router case receiving broadcast packet in any way need additional
check for dst IP address (host part is all zero or all one? what about
handling this broadcast type (RFC talk about conroling variation of
this)? what about sysctl control of receiving routed broadcast
packets? what about handling 255.255.255.255?)
I believe most of this is already special-cased in ip_fastfwd.c (which
gnn@ of course has merged, as it's full of sensible FIB-like operators
which most router forwarding planes adopt on *their* IP input paths up
to the forwarding decision), assuming the Ethernet input path colours
packets with the right flags.
Although, no direct distinction between IPv4 directed or undirected
broadcast is made, until that code (or a full rtalloc()) is hit.
In the past, I have tried to "hack around" the issue on the output
(send) side, by introducing IP_ONESBCAST from BSD/OS.
The fundamental problem there is that the IPv4 socket APIs were never
designed to deal with 'with link' as well as 'with destination'
particularly well -- i.e. to direct traffic to a particular host, with
correct L2 resolution, but over a specific choice of link (or even,
class of link).
So, for correct behaviour when handling packets like this, the XORP FEA
and libfeaclient frameworks would attempt to fully-bind control sockets
requiring broadcast input where possible (OLSR being one candidate, but
there are also other protocols requiring them).
In any way, this is irrelevant to L2 broadcast MAC and present L2
broadcast flags.
On the contrary, I believe in teasing as much explanation about the
Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends
much background to the original problem posed by Ryan's change, to those
who may not be from a primarily networking-oriented background.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
