On Dec 31, 2015, at 1:54 PM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> 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