[189537] in North American Network Operators' Group
Re: rfc 1812 third party address on traceroute
daemon@ATHENA.MIT.EDU (Marc Storck)
Wed Jun 1 15:16:17 2016
X-Original-To: nanog@nanog.org
From: Marc Storck <mstorck@voipgate.com>
To: Randy Bush <randy@psg.com>
Date: Wed, 1 Jun 2016 19:16:08 +0000
In-Reply-To: <m2r3cihl96.wl%randy@psg.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
With BCP38 in mind, could therre be situations where Router R is not allowe=
d to source packets with address A out of intergace C?
I think that the possibility does exist.
E.g. If interface A and C are upstream interfaces, router R may use an IP a=
ddress from ISP A on interface A and an address from ISP C on interface C.
Obviously BCP38 is not widely deployed but yet...
Regards,
Marc
> On 31 mai 2016, at 07:05, Randy Bush <randy@psg.com> wrote:
>=20
> rfc1812 says
>=20
> 4.3.2.4 ICMP Message Source Address
>=20
> Except where this document specifies otherwise, the IP source address
> in an ICMP message originated by the router MUST be one of the IP
> addresses associated with the physical interface over which the ICMP
> message is transmitted. If the interface has no IP addresses
> associated with it, the router's router-id (see Section [5.2.5]) is
> used instead.
>=20
> some folk have interpreted this to mean that, if a router R has three
> interfaces
>=20
> .-----------------.
> | |
> | B |--------- D
> S ---------| A R |
> | C |--------- (toward S)
> | |
> `-----------------'
>=20
> 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.
>=20
> 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.
>=20
> ras's preso,
> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Tracerout=
e_N47_Sun.pdf
> page 10 illustrates this issue with rfc1812
>=20
> cursory research and talking with C & J seem to indicate that they do
> what i want not what some folk have interpreted 1812 to mean. at least
> on some models.
>=20
> is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how
> common is it?
>=20
> randy
