Home page logo

nanog logo nanog mailing list archives

Re: subnet prefix length > 64 breaks IPv6?
From: Ray Soucy <rps () maine edu>
Date: Wed, 28 Dec 2011 18:08:32 -0500

As much as I argue with Owen on-list, I still enjoy reading his input.

It's a little uncalled for to be so harsh about his posts.  A lot of
us are strong-willed here, and many of us read things we've posted in
the past and ask "what was I thinking, that's ridiculous"; and perhaps
I'm just saying that because I do so more than most.

But really, let's stay civil.

I don't disagree with your other comments much, but I do think (hope
actually) that DHCPv6 snooping will not filter link-local traffic.
That would be a job for an ND inspection kind of technology, and one I
would hope was configurable.  There is no DHCPv6 for link-local so it
would be kind of silly to have DHCPv6 snooping restrict that traffic
completely.  It will be a little less straight forward than DHCP
snooping is, no doubt.

And I will admit I can be a Cisco fanboy at times, but only because
they've consistently been able to deliver on IPv6 more that other
vendors I've worked with.  Like any vendor it can be hard to get
through to the people who matter, but Cisco has been pretty good at
responding to us when we poke them on these matters.  Surprisingly,
most of the time the delay is waiting on a standard to be established
so they can implement that rather than their own thing.

On Wed, Dec 28, 2011 at 5:39 PM, Jeff Wheeler <jsw () inconcepts biz> wrote:
On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy <rps () maine edu> wrote:
The suggestion of disabling ND outright is a bit extreme.  We don't
need to disable ARP outright to have functional networks with a
reasonable level of stability and security.  The important thing is

I don't think it's at all extreme.  If you are dealing with an access
network where DHCPv6 is the only legitimate way to get an address on a
given LAN segment, there is probably no reason for the router to use
ND to learn about neighbor L3<>L2 associations.  With DHCPv6 snooping
the router can simply not use ND on that segment, which eliminates
this problem.  However, this feature is not yet available.

It would also be difficult to convince hosting customers to use a
DHCPv6 client to populate their gateway's neighbor table.  However, if
this feature comes along before other fixes, it will be a good option
for safely deploying /64s without ND vulnerabilities.

that we work with vendors to get a set of tools (not just one) to
address these concerns.  As you pointed out Cisco has already been
doing quite a bit of work in this area, and once we start seeing the
implementations become more common, other vendors will more than
likely follow (at least if they want our business).

Maybe I'm just a glass-half-full kind of guy. ;-)

I think your view of the Cisco work is a little optimistic. :)  What
they have done so far is simply acknowledge that, yes, ND exhaustion
is a problem, and give the customer the option to mitigate damage to
individual interfaces / VLANs, on the very few platforms that support
the feature.

Cisco has also given the SUP-2T independent policers for ARP and ND,
so if you have a SUP-2T instead of a SUP720 / RSP720, your IPv4 won't
break when you get an IPv6 ND attack.  Unfortunately, there are plenty
of people out there who are running IPv6 /64s on SUP720s, most who do
not know that an attacker can break all their IPv4 services with an
IPv6 ND attack.

The most important thing is that network operators are aware of these
issues, have a basic understanding of the implications, and are
provided with the knowledge and tools to address them.

We certainly agree here.  I am glad the mailing list has finally moved
from listening to Owen DeLong babble about this being a non-problem,
to discussing what work-arounds are possible, disadvantages of them,
and what vendors can do better in the future.

My personal belief is that DHCPv6 snooping, with ND disabled, will be
the first widely-available method of deploying /64s "safely" to
customer LAN segments.  I'm not saying this is good but it is a
legitimate solution.

Jeff S Wheeler <jsw () inconcepts biz>
Sr Network Operator  /  Innovative Network Concepts

Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]