>
> Let's try a SINGLE post this time. (Bloody OE screwed up on me on the last
> one).
>
> Here's verbatim from RFC 1918:
>
> -------
> Per RFC 1918:
>
> "Because private addresses have no global meaning, routing information
> about private networks shall not be propagated on inter-enterprise
> links, and packets with private source or destination addresses
> should not be forwarded across such links. Routers in networks not
> using private address space, especially those of Internet service
> providers, are expected to be configured to reject (filter out)
> routing information about private networks. If such a router receives
> such information the rejection shall not be treated as a routing
> protocol error.
>
> Indirect references to such addresses should be contained within the
> enterprise. Prominent examples of such references are DNS Resource
> Records and other information referring to internal private
> addresses. In particular, Internet service providers should take
> measures to prevent such leakage."
> ------
>
> To me it seems pretty clear.
>
> Steve
> ----- Original Message -----
> From: Michael H. Warfield <mhw@wittsend.com>
> To: Steve Costaras <stevecs@chaven.com>
> Cc: at Linux-Net <linux-net@vger.rutgers.edu>; Bruce Stephens
> <bruce@toorak.com>
> Sent: Sunday, June 06, 1999 20:22
> Subject: Re: Illegal IP addresses???
>
>
> > Steve Costaras enscribed thusly:
> >
> > > Yes, according to RFC 1918 the ranges:
> >
> > > 10.0.0.0 - 10.255.255.255 (10/8 prefix)
> > > 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
> > > 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
> >
> > > should be blocked by your ISP from getting on to the wires. However, I
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > No...
> >
> > I think that is an extrapolation based on the RFC but is
> > not in the RFC at all. I could be wrong, and I welcome anyone who can
> > state emphatically where in that RFC is says that source addresses of
> > this form must be blocked. Actually, I don't think the RFC CAN specify
> > this because it would have to deal with "block at what point" or "blocked
> > at what interface". Do we block it at the border gateways and autonomous
> > systems or do we block it at all routers (which would screw some private
> > networks royally).
> >
> > No...
> >
> > The RFC merely states that these addresses will not be assigned
> > and, as such, will never have a routing advertisement. It does not mean
> > that they must be blocked or handled any different from any other
> > unassigned address. It merely guarentees that they will never BE
> ASSIGNED.
> > As such, they can never be routed. It says nothing about being blocked.
> >
> > > have dealt with 5 major ISP's (digex, UUnet, PSI, et al to name a few)
> > > that DO NOT follow, nor do they want to follow this RFC. They would not
> > > give any reasons as to why and frankly I don't see why any major ISP
> would
> > > want to carry extra 'junk' traffic on their backbones. The only
> solution is
> > > to block it at your incoming serial interface. Ie. w/ a cisco something
> > > like
> > > this:
> >
> > > access-list 103 deny ip 10.0.0.0 0.255.255.255 any
> > > access-list 103 deny ip 172.16.0.0 0.15.255.255 any
> > > access-list 103 deny ip 192.168.0.0 0.0.255.255 any
> > > access-list 103 deny ip 127.0.0.0 0.255.255.255 any
> > > access-list 103 deny ip 255.0.0.0 0.255.255.255 any
> > > access-list 103 deny ip host 0.0.0.0 any
> > > access-list 103 deny ip 207.238.162.0 0.0.0.255 any
> >
> > This is something that everyone using the reserved addresses should
> > provide for themselves. You can NOT depend on an ISP doing this for you
> for
> > the simple reason that THEY may have reserved addresses in use or other
> > customers with reserved addresses in use. It is totally up to the user
> > of those addresses to provide the layers of blocking, insulation, and
> > translation required by that use. It is NOT up to the ISP.
> >
> > > This will:
> >
> > > 1) block the private address ranges
> > > 2) block the loopback address (127.0.0.*) which should also not be
> forwarded
> > > 3) block any packets WITHOUT a source address
> > > 4) block any packets that have a source address from within MY network.
> > > (i.e.. spoofing)
> > > 5) block any packets coming from a 'broadcast' network
> >
> >
> > > Steve
> > >
> > > ----- Original Message -----
> > > From: Bruce Stephens <bruce@toorak.com>
> > > To: at Linux-Net <linux-net@vger.rutgers.edu>
> > > Sent: Sunday, June 06, 1999 19:36
> > > Subject: Illegal IP addresses???
> >
> >
> > > > Hi y'all
> > > >
> > > > I'm getting a few hits on one of our Linux systems from an external
> > > > 192.168.x.x address.
> > > >
> > > > Now please feel free to correct me but I thought 192.168.x.x addresses
> > > were
> > > > not permitted on the Internet!! (Class C range)
> > > >
> > > > Yet this firewall is showing the following
> > > >
> > > > Jun 7 05:48:53 mitsi kernel: IP fw-in rej ppp0 UDP 192.168.5.192:137
> <our
> > > > IP address>:137 L=78 S=0x00 I=50150 F=0x0000 T=105
> > > > The hits are in rapid succession (up to 100 trying various IP
> addresses)
> > > >
> > > > Note the port...
> > > > - netbios-ns 137/tcp nbns
> > > > - netbios-ns 137/udp nbns
> > > >
> > > > so is this is another illegal Windoze system?
> > > > We have had similar attempts from 192.168.1.65 as well.
> > > >
> > > > PS We do use 192.168.0.x addresses ourselves (internally only through
> a
> > > > masquerade) but do not use addresses in the 192.168.1.x or 192.168.5.x
> > > > networks. AND we certainly DON'T use Windoze anywhere. (MacOS and
> Linux).
> > > > Your thoughts would be appreciated.
> > > > Bruce.
> >
> > Mike
> > --
> > Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
> > (The Mad Wizard) | (770) 925-8248 |
> http://www.wittsend.com/mhw/
> > NIC whois: MHW9 | An optimist believes we live in the best of all
> > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-net" in
> > the body of a message to majordomo@vger.rutgers.edu
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.rutgers.edu
>
-- --bill - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu