>> 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?
I... err.. I don't have any Linux or windows boxes that I can play with for a
few weeks, but I can stand one up later this month sometime. ELINUXFREE ?
> You may also want to search for this question on NANOG, and if not
> found raise it there.
I looked around to see if this was changed recently, but I couldn't find any
reference as such. The thought was to pluck an easy mnemonic for remembering
and correlating network services that are guaranteed and required to be
site-local and not available through an MPLS or VPN network (10/8, 192.168/16
and 172.16/12 are managed by BGP or some other IGP, I wanted something
explicitly that would not match).
0.42.123.10 & 0.42.123.20 = site-local NTP server.
^
| ^^
| | ^^^
| | | ^
| | | |
| | | +------ primary, .20 = secondary
| | +--------- "port 123 services"
| +------------ "the answer to"
+--------------- site/data center local
There were a host of convenience things that came for free with this, including
easy to identify what traffic should be on the segment, etc. DNS would be at
0.42.53.{10,20}, etc. Answering questions like "this data center's DNS server
is at 172.29.167.4" is a PITA, and it doesn't need to be.
I saw you just made a commit to enable this a few minutes ago, thank you. Any
plans to MFC r242956? Thanks Andre. -sc
--
Sean Chittenden
[email protected]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[email protected]"
