Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: private ip addresses from ISP

  • From: Robert Bonomi
  • Date: Tue May 23 09:23:23 2006

> Date: Tue, 23 May 2006 03:33:34 -0400
> From: Richard A Steenbergen <ras@e-gerbil.net>
> To: nanog@nanog.org
> Subject: Re: private ip addresses from ISP
>
>
> On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote:
> > 
> > > 	3) You are seeing packets with source IPs inside private space
> > > arriving at
> > > your interface from your ISP?
> ...
> > Sorry to dig this up from last week but I have to strongly disagree with
> > point #3.  
> > >From 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.
> > 
> > The ISP shouldn't be "leaving" anything to the end-user, these packets
> > should be dropped as a matter of course, along with any routing
> > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space
> > into my network piss me off, and get irate phone calls for their
> > trouble.
>
> The section you quoted from RFC1918 specifically addresses routes, not 
> packets.

I quote, from the material cited above:
      "  ..., and packets with private source or destination addresses
       should not be forwarded across such links.  ...  "

There are some  types of packets that can legitimately have RFC1918 source
addresses --  'TTL exceeded' for example -- that one should legitimately
allow across network boundaries.
>          If you're receiving RFC1918 *routes* from anyone, you need to 
> thwack them over the head with a cluebat a couple of times until the cluey 
> filling oozes out. If you're receiving RFC1918 sourced packets, for the 
> most part you really shouldn't care.

*I* care.  

When those packets contain 'malicious' content, for example.

When the provider =cannot= tell me which of _their_own_customers_ originated 
that attack, for example.  (This provider has inbound source-filtering on 
their Internet 'gateway' routers, but *not* on their customer-facing equipment 
(either inbound or outbound.)

It's even more comical when the NSP uses RFC1918 space internally, and does 
*not* filter those source addresses from their customers.

>                                      There are semi-legitimate reasons for 
> packets with those sources addresses to float around the Internet, and 
> they don't hurt anything. 

I guess you don't mind paying for transit of packets that _cannot_possibly_
have any legitimate purpose on your network.

Some of us, on the other hand, _do_ object. 

YMMV






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.