rfc 1812 third party address on traceroute

William Herrin bill at herrin.us
Tue May 31 15:26:03 UTC 2016

On Tue, May 31, 2016 at 1:03 AM, Randy Bush <randy at psg.com> wrote:
>                .-----------------.
>                |                 |
>                |               B |--------- D
>     S ---------| A      R        |
>                |               C |--------- (toward S)
>                |                 |
>                `-----------------'
> i would desire the source of the time
> exceeded message to be A.  after all, this is the interface to which i
> sent the icmp with the TTL to expire.

Hi Randy,

I've thought for a number of years that routers should have an "ip
icmp-error-from" interface directive which allows the operator to
specify the source address for ICMP errors messages generated due to
packets received on that interface.

The behavior you describe where the time-exceeded message comes from C
instead of A is a nuisance. The RDNS gives you clues which point in
the wrong direction. Darn. Guess you'll have to rely on the preceding
router to tell you where the packet came from before it reached R.

The behavior Mikael notes is more deadly. Bogon filters drop packets
from RFC1918 sources. They aren't subtle enough to allow ICMP errors
through while dropping other IP packets. With bogon filters in place,
ICMP errors originated from RFC1918 space don't reach S. PMTUD dies
and your TCP connections die along with it. It's really important that
an Internet router not originate ICMP from!

It would also have been nice if ICMP error messages had defined a text
comment field where ops could place diagnostic information such as the
received interface. Overloading the functionality of the layer-3
address for any purpose (such as hanging an RDNS entry with textual
diagnostic information) is bad bad bad. Probably too late to shoehorn
that in.

Bill Herrin

William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

More information about the NANOG mailing list