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. 

?? Any thoughts as to why? It doesn't appear that the current behavior abides 
by RFC5735.

-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"

Reply via email to