NIST IPv6 document

Jeff Wheeler jsw at inconcepts.biz
Wed Jan 5 16:49:47 UTC 2011


On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum <iljitsch at muada.com> wrote:
>> that a lot of smart people agree is a serious design flaw in any IPv6
>> network where /64 LANs are used
>
> It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive.

It appears you want to have a semantic argument.  I could grant that,
and every point in my message would still stand.  However, given that
the necessary knobs to protect the network with /64 LANs do not exist
on any platform today, vendors are not talking about whether or not
they may in the future, and that no implementation with /64 LANs
connected to the Internet, or any other routed network which may have
malicious or compromised hosts, "design flaw" is correct.

This is a much smaller issue with IPv4 ARP, because routers generally
have very generous hardware ARP tables in comparison to the typical
size of an IPv4 subnet.  You seem to think the issue is generating NDP
NS.  While that is a part of the problem, even if a router can
generate NS at an unlimited rate (say, by implementing it in hardware)
it cannot store an unlimited number of entries.  The failure modes of
routers that have a full ARP or NDP table obviously vary, but it is
never a good thing.  In addition, the high-rate NS inquiries will be
received by some or all of the hosts on the LAN, consuming their
resources and potentially congesting the LAN.  Further, if the
router's NDP implementation depends on tracking the status of
"incomplete" on-going inquiries, the available resource for this can
very easily be used up, preventing the router from learning about new
neighbors (or worse.)  If it does not depend on that, and blindly
learns any entry heard from the LAN, then its NDP table can be totally
filled by any compromised / malicious host on the LAN, again, breaking
the router.  Either way is bad.

This is a fundamentally different and much larger problem than those
experienced with ARP precisely because the typical subnet size is now,
quite literally, seventy-quadrillion times as large as the typical
IPv4 subnet.

On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum <iljitsch at muada.com> wrote:
> A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use.

It would certainly be nice to have a stateful firewall on every single
LAN connection.  Were there high-speed, stateful firewalls in 1994?
Perhaps the IPng folks had this solution in mind, but left it out of
the standards process.  No doubt they all own stock in SonicWall and
are eagerly awaiting the day when "Anonymous" takes down a major ISP
every day with a simple attack that has been known to exist, but not
addressed, for many years.

You must also realize that the stateful firewall has the same problems
as the router.  It must include a list of allocated IPv6 addresses on
each subnet in order to be able to ignore other traffic.  While this
can certainly be accomplished, it would be much easier to simply list
those addresses in the router, which would avoid the expense of any
product typically called a "stateful firewall."  In either case, you
are now maintaining a list of valid addresses for every subnet on the
router, and disabling NDP for any other addresses.  I agree with you,
this knob should be offered by vendors in addition to my list of
possible vendor solutions.

On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum <iljitsch at muada.com> wrote:
> Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away.

I do not conceptually disagree with sparse subnets.  With the
equipment limitations of today, they are a plan to fail.  Let's hope
that all vendors catch up to this before malicious people/groups.

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




More information about the NANOG mailing list