>>>> Hello. I ran in to an interesting situation in what appears to be an >>>> exotic situation. Specifically, after reviewing RFC5735 again and >>>> searching for a datacenter-local or rack-local IP range (i.e trying to >>>> provide services that are guaranteed to be provided in the same rack as >>>> the server), I settled on the 0.0.0.0/8 network. Per §3 of RFC5735, it >>>> would appear that this network is valid: >>>> >>>> https://tools.ietf.org/html/rfc5735#section-3 >>>> >>>>> 0.0.0.0/8 - Addresses in this block refer to source hosts on "this" >>>>> network. Address 0.0.0.0/32 may be used as a source address for this >>>>> host on this network; other addresses within 0.0.0.0/8 may be used to >>>>> refer to specified hosts on this network ([RFC1122], Section 3.2.1.3). >>>> And this works as expected, with regards to TCP services. But ICMP? Not so >>>> much. Is there a reason that ICMP would fail, but TCP (e.g. ssh) works? >>>> For example, I pulled 0.42.123.10 and 0.42.123.20 as IP addresses to use >>>> for NTP servers, but much to my surprise, I could ssh between the hosts, >>>> but I couldn't ping. Is this intentional? I understand that 0.0.0.0/32 == >>>> INADDR_ANY for source addresses, but it doesn't appear that there should >>>> be a restriction of inbound echoreq packets. According to tcpdump(1), the >>>> host is receiving echoreq packets, however no echorep packets are >>>> generated. As a work around, I threw things in to a more traditional >>>> RFC1918 network and things immediately worked for both SSH and ICMP. >>> 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. -sc -- Sean Chittenden s...@chittenden.org _______________________________________________ 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"
