NIST IPv6 document

Jeff Wheeler jsw at inconcepts.biz
Wed Jan 5 17:44:23 UTC 2011


On Wed, Jan 5, 2011 at 12:26 PM, Phil Regnauld <regnauld at nsrc.org> wrote:
> Jeff Wheeler (jsw) writes:
>> Not good, but also does not affect any other interfaces on the router.
>        You're assuming that all routing devices have per-interface ARP tables.

No, Phil, I am assuming that the routing device has a larger ARP table
than 250 entries.  To be more correct, I am assuming that the routing
device has a large enough ARP table that any one subnet could go from
0 ARP entries to 100% ARP entries without using up all the remaining
ARP resources on the box.  This is usually true.  Further, routing
devices usually have enough ARP table space that every subnet attached
to them could be 100% full of active ARP entries without using up all
the ARP resources.  This is also often true.

To give some figures, a Cisco 3750 "pizza box" layer-3 switch has room
for several thousand ARP entries, and I have several with 3000 - 5000
active ARPs.  Most people probably do not have more than a /20 worth
of subnets for ARPing to a pizza box switch like this, but it does
basically work.

As we all know, a /64 is a lot more than a few thousand possible
addresses.  It is more addresses than anyone can store in memory, so
state information for "incomplete" can't be tracked in software
without creating problems there.  Being fully stateless for new
neighbor learning is possible and desirable, but a malicious host on
the LAN can badly impact the router.  This is why per-interface knobs
are badly needed.  The largest current routing devices have room for
about 100,000 ARP/NDP entries, which can be used up in a fraction of a
second with a gigabit of malicious traffic flow.  What happens after
that is the problem, and we need to tell our vendors what knobs we
want so we can "choose our own failure mode" and limit damage to one
interface/LAN.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts




More information about the NANOG mailing list