Request for comment -- BCP38

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.

Regards,

Baldur