Request for comment -- BCP38

Mike Hammett nanog at
Mon Sep 26 16:00:25 UTC 2016

The only asymmetric routing broken is when the source isn't in public Internet route-able space. That just leaves those multi-ISP WAN routers that NAT it. 

Mike Hammett 
Intelligent Computing Solutions 


----- Original Message -----

From: "Laszlo Hanyecz" <laszlo at> 
To: nanog at 
Sent: Monday, September 26, 2016 10:47:43 AM 
Subject: Re: Request for comment -- BCP38 

On 2016-09-26 15:12, Hugo Slabbert wrote: 
> On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase <math at> wrote: 
>> This might break some of those badly-behaving "dual ISP" COTS routers 
>> out there 
>> that use different inbound from outbound paths since each is the 
>> fastest of 
>> either link. 
> As it should. 
> If you have links from both ISP A and ISP B and decide to send traffic 
> out ISP A's link sourced from addresses ISP B allocated to you, ISP A 
> *should* drop that traffic on the floor. There is no automated or 
> scalable way for ISP A to distinguish this "legitimate" use from 
> spoofing; unless you consider it scalable for ISP A to maintain 
> thousands if not more "exception" ACLs to uRPF and BCP38 egress 
> filters to cover all of the cases of customers X, Y, and Z sourcing 
> traffic into ISP A's network using IPs allocated to them by other ISPs? 

This is a legitimate and interesting use case that is broken by BCP38. 
The effectiveness of BCP38 at reducing abuse is dubious, but the 
benefits of asymmetric routing are well understood. Why should everyone 
have to go out of their way to break this.. it works fine if you just 
don't mess with it. 

> If you want to play asymmetry tricks, get some PI space and make 
> arrangements. If that's outside your wheelhouse, get an ISP that will 
> sell this to you as a service either with dissimilar links they 
> provide to you or over-the-top with tunnels etc. 
> Playing NAT games with different classes of traffic to e.g. send 
> traffic type 1 over ISP A and traffic type 2 over ISP B *BUT* using 
> the corresponding source addresses in each case and having the traffic 
> return back over the same links is fine and dandy. If you send 
> traffic into an ISP-provided link using addresses from another 
> provider, though, that ISP *should* be dropping that traffic. If they 
> don't, send them here so we can yell at them. 

So instead of being able to use simple destination based routes to 
direct their traffic, like the service provider can, the CPE operator 
has to learn and implement policy based routing and manage state to 
juggle each of the IP addresses they are assigned. It's orders of 
magnitude harder to do this with the current ecosystem of routers/CPEs, 
than it is to add a destination route. I think stuff like this is one 
of the reasons why many are hesitant to implement this type of 
filtering. It makes a specific type of abuse easier to track down *for 
someone else* but it doesn't help you much and it can cause debugging 
nightmares when something doesn't work due to filtering. 


>> I did this manually when I was messing around with multiple broadband 
>> links on 
>> a fbsd router years ago, was glad it worked at the time. 
>> /kc 
>> On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said: 
>> >No -- BCP38 only prescribes filtering outbound to ensure that no 
>> packets leave your network with IP source addresses which are not 
>> from within your legitimate allocation. 
>> > 
>> > - ferg 
>> > 
>> > 
>> >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell 
>> <list at> wrote: 
>> >>Is this an accurate thumbnail summary of BCP38 (ignoring for the 
>> moment 
>> >> 
>> >>the issues of multi-home), or is there something I missed? 
>> >> 
>> >>> The basic philosophy of BCP38 boils down to two axioms: 
>> >>> 
>> >>> Don't let the "bad stuff" into your router 
>> >>> Don't let the "bad stuff" leave your router 
>> >>> 
>> >>> The original definition of "bad stuff" is limited to source- 
>> >>> address grooming both inbound and outbound. I've expanded on 
>> the 
>> >>> original definition by including rule generation to control 
>> >>> broadcast address abuse. 
>> > 
>> >-- 
>> >Sent from my Android device with K-9 Mail. Please excuse my brevity. 
>> -- 
>> Ken Chase - math at Toronto Canada 

More information about the NANOG mailing list