From owner-freebsd-security Tue Oct 5 17: 9:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id B285F14C3D for ; Tue, 5 Oct 1999 17:09:31 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id UAA13689; Tue, 5 Oct 1999 20:12:10 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199910060012.UAA13689@cc942873-a.ewndsr1.nj.home.com> Subject: Re: natd -deny_incoming In-Reply-To: from "f.johan.beisser" at "Oct 3, 1999 12:51:34 pm" To: jan@caustic.org (f.johan.beisser) Date: Tue, 5 Oct 1999 20:12:10 -0400 (EDT) Cc: ratebor@cityline.ru (Dmitriy Bokiy), freebsd-security@FreeBSD.ORG (FreeBSD Security ML) Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org f.johan.beisser wrote, > On Sun, 3 Oct 1999, Dmitriy Bokiy wrote: [snip] > > If that`s so is there some ground under it or is it just a "feature"? > > In other words: why do we need this option at all if "deny incoming to > > RFCs" could be default behavior? > > well, the problem with dening the unroutable networks (RFC 1918, > 192.168.0.0, 10.0.0.0, 172.16.0.0) from natd is that some folks (in my > lab, included) will want to have an unrouteable network inside of an > unroutable. I think the root of the original poster's confusion might be the use of such words as 'unroutable' when refering to the addresses set aside in RFC 1918. There is absolutely nothing 'unroutable' about these addresses _execpt_, to quote the RFC, an enterprise may use these addresses "without any coordination with IANA or an Internet registry." That is, these addresses have no meaning to the Internet-at-large, but you can do whatever the heck you want with them internally. You can route the heck out of 'em on your own network if you please. There is nothing unroutable about them (nor does the word 'unroutable' appear anywhere in the RFC). However, RFC 1918 recommends, "It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise." But this is a recommendation and not a requirement. Refering to them as 'private network numbers,' 'unregistered numbers,' or as the RFC says, 'private address space,' is more accurate and less confusing, IMHO. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message