private ip addresses from ISP

Patrick W. Gilmore patrick at
Tue May 23 16:26:49 UTC 2006

On May 23, 2006, at 10:47 AM, Robert Bonomi wrote:

>> Really? You really want TTL-E messages with RFC1918 source addr? Even
>> if they're used as part of a denial of service attack? Even though
>> you can't tell where they actually came from?
> "Can be" is not sufficient (in and of itself, that is) reason to  
> block.
> _Anything_ "can be" used as part of a DOS attack.
> TTL-E messages _do_ have legitimate function in network management.
> TTL-E messages _can_ originate from RFC1918 space,  addressed to  
> 'public
> internet' addresses.  Usefully, and meaningfully.  Ever hear of  
> 'traceroute'?
> Ever use it where packets went across a network using RFC1918  
> internally?
> Ever had a route die _between_ two RFC1918 addressed nodes on  
> somebody elses
> network?
> If you don't like that example, substitute "host/network  
> unreachable", or
> 'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet.   
> If you
> don't get those messages back, you can't communicate.

Robert, to quote your own words: "You're either ignorant of network  
architecture, or trying to pick fights."

TTL-E messages "can" originate from any IP address.  They should  
not.  And allowing packets with RFC1918 source addresses to leave  
your administrative domain is bad network administration (not to  
mention going against the RFC).  There are no loopholes here, you are  
being a bad 'Netizen if you pass packets with bogon source addresses  
to your peers.  Period.

If you have issues where you need to send DNF or other messages to  
peers, it is incumbent upon _you_ to ensure those messages originate  
with valid source addresses.

It is perfectly acceptable - even good network hygiene - for other  
networks to drop any packets with bad source addresses at their  
boarder.  You cannot expect them to accept your packets just because  
you don't know how to architect a network properly.  If that breaks  
traceroute or PMTU-D or anything else, that is your fault, not theirs.

Please read RFC1918 again, as well as BCP38.  And perhaps a book on  


More information about the NANOG mailing list