[146992] in North American Network Operators' Group
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS
daemon@ATHENA.MIT.EDU (Jimmy Hess)
Wed Nov 30 11:14:59 2011
In-Reply-To: <CALFTrnNFjFZtmWay4T4ASYbZZf0vcaaUVc7G=sLEyV78qKBAgw@mail.gmail.com>
Date: Wed, 30 Nov 2011 10:13:56 -0600
From: Jimmy Hess <mysidia@gmail.com>
To: Ray Soucy <rps@maine.edu>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps@maine.edu> wrote:
> Saying you can mitigate neighbor table exhaustion with a "simple ACL"
> is misleading (and you're not the only one who has tried to make that
> claim).
It's true, though, you can.
But you can also mitigate neighbor table exhaustion by using a long prefix /126;
you create an upper bound on the number of neighbor table entries that
are possible,
and that bound is less than your device's memory capacity for neighbor
table entries.
This is a more reliable mitigation than an ACL; it is also simpler
and less likely for an
operator to mistake to render the mitigation useless, or cause other issues.
From a pure security POV, it's easy to reject ACL mitigation in favor
of inherent
designed-in mitigation / non-vulnerability.
From a network design POV, there may still be reasons to prefer the ACL method.
They better be good reasons, such as a requirement for SLAAC on a large LAN.
--
-JH
