Date: Tue, 5 Oct 1999 20:12:10 -0400 (EDT) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: jan@caustic.org (f.johan.beisser) Cc: ratebor@cityline.ru (Dmitriy Bokiy), freebsd-security@FreeBSD.ORG (FreeBSD Security ML) Subject: Re: natd -deny_incoming Message-ID: <199910060012.UAA13689@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <Pine.BSF.4.05.9910031234160.41067-100000@pogo.caustic.org> from "f.johan.beisser" at "Oct 3, 1999 12:51:34 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910060012.UAA13689>