Because there are legitimate reasons for async routing.
DirectPC/Isat/etc. (Satelite based services) come to mind immediately.
Customers dial-up to an ISP and downstream traffic returns via the sat
connection. Reverse-path immediately disables every one of these
customers. Qwest deployed this on us with no notice and killed off
thousands of customers in one fell swoop.
Although I agree with the principal, the implentation needs more thought
than a simple 'turn it on for 100%'.
Eric Krichbaum
Alexei Roudnev
Because there are legitimate reasons for async routing.
DirectPC/Isat/etc. (Satelite based services) come to mind immediately.
DirecPC has had satellite return path for a long time. Their older systems with dialup/cable for upstream involved loading of software into your PC. That software could EASILY have encapsulated the upstream packets into UDP packets so that their upstream packets were valid.
Customers dial-up to an ISP and downstream traffic returns via the sat
connection. Reverse-path immediately disables every one of these
customers. Qwest deployed this on us with no notice and killed off
thousands of customers in one fell swoop.
Although I agree with the principal, the implentation needs more thought
than a simple 'turn it on for 100%'.
The documents leading up to BCP38 began in 1996. This didn't just happen out of the blue. Some assumptions made by more than one group that routing decisions would forever be made based on destination IP address only.
One of these was mobile IP, and that WG worked on an alternative as soon as the ingress filtering draft started gaining momentum. Tunnels are a good answer where legitimate traffic has to flow in a way that does not match the addressing topology.
Having this dropped on you by Qwest without warning was a bad thing. I wonder if you asked them to temporarily undo it while while you worked with the vendor (Hughes in this case) to implement tunneling of the return traffic?
This is an interestig example - looks as some protocol, saying _these are my
legal SRC addresses_, desired on customer's link.