From owner-freebsd-net@FreeBSD.ORG Tue Nov 13 18:54:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BE13116; Tue, 13 Nov 2012 18:54:55 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from mail01.lax1.stackjet.com (mon01.lax1.stackjet.com [174.136.104.178]) by mx1.freebsd.org (Postfix) with ESMTP id 65B448FC14; Tue, 13 Nov 2012 18:54:55 +0000 (UTC) Received: from [192.168.11.242] (c-71-202-44-241.hsd1.ca.comcast.net [71.202.44.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sean@chittenden.org) by mail01.lax1.stackjet.com (Postfix) with ESMTPSA id 4C3433E8D56; Tue, 13 Nov 2012 10:54:54 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 0.0.0.0/8 oddities... From: Sean Chittenden In-Reply-To: <50A20359.9080906@networx.ch> Date: Tue, 13 Nov 2012 10:54:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7C614093-6408-49C6-8515-F6C09183453B@chittenden.org> References: <50A20359.9080906@networx.ch> To: Andre Oppermann X-Mailer: Apple Mail (2.1499) Cc: "freebsd-net@freebsd.org" , gnn@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 18:54:55 -0000 >> 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 =A73 of RFC5735, it = would appear that this network is valid: >>=20 >> https://tools.ietf.org/html/rfc5735#section-3 >>=20 >>> 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). >>=20 >> 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 =3D=3D 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. >=20 > 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. >=20 >> ?? Any thoughts as to why? It doesn't appear that the current = behavior abides by RFC5735. >=20 > 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. >=20 > 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 =3D site-local NTP server. ^ | ^^ | | ^^^ | | | ^ | | | | | | | +------ primary, .20 =3D 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 seanc@FreeBSD.org