Skip site navigation (1)Skip section navigation (2)
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>