On 14/11/2012 07:32, Joe Holden wrote:
On 14/11/2012 07:25, Sean Chittenden wrote:
The check to drop ICMP replies to a source of 0.0.0.0/8 was added
in r120958 as part of a fix for link local addresses. It was only
applied to ICMP which is inconsistent as you've found out.
?? Any thoughts as to why? It doesn't appear that the current
behavior abides by RFC5735.
Reading this section and RFC1122 it is not entirely clear to me
what the allowed scope of 0.0.0.0/8 is. I do agree though that
blocking it only in ICMP is not useful if it is allowed in the
normal IP input path.
Can you please check how other OS's (Linux, Windows) deal with it?
0/8 is not supposed to be used, as per the rfc. As such it doesn't
work on most systems (Linux, network appliance vendors included) so
this working *should* be a bug, IMO.
Where does it say that it shouldn't be used? Which RFC & ยง? There
are plenty of RFCs and I haven't exhaustively read things, so I
reserve the right to be wrong & corrected, but I haven't seen
anything that says, "do not use 0.0.0.0/8." 0.0.0.0/32, yes, that's
a reserved and special IP address, but the remainder of the /8? It's
a stretch to argue that it can't be used.
There are several, including the one you referenced where it
references the other addresses can only be used as a source address.
It is vague but accepted that 0/8 isn't usable as anything other than
that.
Can you be more specific? I read "other addresses within 0.0.0.0/8 may
be used to refer to specified hosts on this network" as an indication
that use of 0/8 is intended to be supported.
Regardless, why are you trying to do something that is unsupported by
pretty much every vendor/operator/os?
Status quo is fine and dandy if it's rational, backed up with a
justification and can be understood, but I'm not seeing anything that
suggests there's a good reason which indicates 0/8 shouldn't be used
or supported. -sc
It's official registration is for "self identification", "this" network
doesn't mean the connected network.
All in all, even allowing an address in 0/8 to be configured is a bug
based on both a) the various RFCs and intended use and b) that's how
everyone else accepts that it should work anyway, so RFC is irrelevant
in that case.
Actually, after testing it doesn't look like there is any special
handling for other ranges either, going to need a seasoned net developer
to weigh in on this one
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
