> On Dec 31, 2015, at 1:54 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > On 01/01/2016 06:04, Jared Mauch wrote: > ... >> The reason we (as an operator) can’t use BCP-38 is the vendor hardware can’t do it at line-rate and the performance hit is too much to sustain. > > That seems worth a bit more discussion. I'd always naively assumed that BCP38 was > scalable since all it appears to need is a prefix match, and routers are very > good at matching prefixes; it's just that they don't normally match the source > prefix. Could some router-vendor person comment on this? The problem is you have to lookup on the SRC part of packet in addition with DST part. These are now two lookups in the forwarding path. Then you have to decide the policy (drop|pass|count). I’ve told vendors I’d like to be able to remark packets that are a lookup miss. This means I can easier count/track them in flow data, etc. But for the small percentage of spoofed packets, the cost on the rest is so high when we are often PPS limited on even the largest routers. The 40-byte packet benchmark of the late 90s isn’t seen today. > There's another issue here, though. BCP-38 and uRPF are also a potential cause of > connectivity problems: https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host Yes, this is a problem, there’s no good way to communicate the “feasible paths” policy amongst all the devices involved. Knowing what’s connected or downstream to me is easy, knowing 1 hop away gets much harder and increases with each node/edge traversed. - Jared