rfc 1812 third party address on traceroute

Owen DeLong owen at delong.com
Tue May 31 14:35:30 UTC 2016


It seems to me that a plain text reading of RFC-1812 is as Randy describes undesirable. It also seems that the violation of this text is commonplace in actual implementations because of yet another time where operators have made it clear to developers that the IETF is silly. 

I like the Linux solution... Comply with the RFC by default and provide a knob to do the "right thing" if desired. 

Best of all would be to put forth an errata against RFC1813 to change the text to specify the inbound interface of the packet triggering the ICMP message when applicable. The behavior currently described should be preserved for ICMP packets which are not triggered by inbound packets. 

Owen


> On May 31, 2016, at 01:27, Job Snijders <job at instituut.net> wrote:
> 
>> On Mon, May 30, 2016 at 10:03:33PM -0700, Randy Bush wrote:
>>               .-----------------.
>>               |                 |
>>               |               B |--------- D
>>    S ---------| A      R        |
>>               |               C |--------- (toward S)
>>               |                 |
>>               `-----------------'
>> 
>> if the source of a traceroute from S toward D with TTL to expire on R,
>> and R's FIB wants to exit via C to get back to S (yes, virginia, the
>> internet is highly asymmetric), the source address of the time exceeded
>> message should be C.
>> 
>> of course, simpletons such as 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.
>> 
>> is anyone seeing the dreaded rfc1812 behavior in a citable fashion?  how
>> common is it?
> 
> On most Linux the default behaviour is using source address "C", but
> this can be corrected by setting the following somewhere in your
> /etc/sysctl.d/ files:
> 
>    # make traceroute nice
>    net.ipv4.icmp_errors_use_inbound_ifaddr=1
> 
> Kind regards,
> 
> Job



More information about the NANOG mailing list