Request for comment -- BCP38
baldur.norddahl at gmail.com
Mon Sep 26 20:08:36 UTC 2016
This means we can receive some packet on transit port A and then route out
>> a ICMP response on port B using the interface address from port A. But
>> transit B filters this ICMP packet because it has a source address
>> belonging to transit A.
> Interesting. But this looks like a feature request for the router
> vendor, and not like an issue with BCP 38 filtering as such.
Can you quote an RFC for anything that the router is doing wrong? Is
there a requirement that a router must support source routing?
In our case we actually did contact the vendor. Turns out that it will
do source routing but not for packets from the control plane. There is
no way to resolve the issue with the current software available to us.
The vendor is not priotizing fixing this as I am also unable to point to
any RFC that is being violated.
Even if or when we get a fix, this will continue to be a problem because
it is a very common setup. There are thousands of networks out there
that have the issue and many of them are probably not even realising it.
>> From this follows that BCP38 can break things like traceroute and path MTU
>> discovery in what is a very common setup.
> That doesn't follow. In order to break PMTUD, you also need an MTU
> drop. Is that a common configuration for routers in points in the
> network where this would matter?
It is not a common configuration which was what I said in the text you
removed from that quote:
"From this follows that BCP38 can break things like traceroute and path
MTU discovery in what is a very common setup. The only reason we do not
have a bigger problem is that few networks will have a downward MTU
change at this point in the network".
Besides it appears that path MTU is broken in general.
We accept the problem because the only actual consequence is that
traceroute is a little funky.
More information about the NANOG