private ip addresses from ISP
Patrick W. Gilmore
patrick at ianai.net
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
> _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
> internet' addresses. Usefully, and meaningfully. Ever hear of
> Ever use it where packets went across a network using RFC1918
> Ever had a route die _between_ two RFC1918 addressed nodes on
> somebody elses
> 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