[146997] in North American Network Operators' Group
RE: IPv6 prefixes longer then /64: are they possible in DOCSIS
daemon@ATHENA.MIT.EDU (Jamie Bowden)
Wed Nov 30 11:56:35 2011
Date: Wed, 30 Nov 2011 11:55:07 -0500
In-Reply-To: <CAAAwwbU_Z8zxN=Ghj9hQJOF_9SLADo6sNYyixi1et6XLKEEB_Q@mail.gmail.com>
From: "Jamie Bowden" <jamie@photon.com>
To: "Jimmy Hess" <mysidia@gmail.com>, "Ray Soucy" <rps@maine.edu>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Jimmy Hess [mailto:mysidia@gmail.com]
> Sent: Wednesday, November 30, 2011 11:14 AM
> To: Ray Soucy
> Cc: NANOG
> Subject: Re: IPv6 prefixes longer then /64: are they possible in
DOCSIS
> networks?
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> From a pure security POV, it's easy to reject ACL mitigation in favor
> of inherent
> designed-in mitigation / non-vulnerability.
>=20
> 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.
Or maybe the IETF could, you know, decouple SLAAC from a particular
netmask and make the world a better place for all of us who aren't
backbone providers. Do we have to recreate the mistakes from v4 all
over again?
Jamie
