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 17:07:40 -0500

You will always be exposed to attacks if you're connected to the Internet.

(Not really sure what you were trying to say there.)
My primary concerns are attacks originated from external networks.
Internal network attacks are a different issue altogether (similar to
ARP attacks or MAC spoofing), which require different solutions.

As previously discussed in a recent thread, the attack vector you
describe (in a service provider environment) can be mitigated though
architecture simply by effective CPE design (isolated link network to
CPE, L3 hand-off at CPE, with stateful packet inspection; and small or
link-local prefixes for link networks).  Thankfully, this isn't a
model that is anything new; many networks are already built in this

The only point contested is the validity of longer-than 64-bit
prefixes; which I think I've spoken enough on.

Enterprise and Data Center environments have a different set of
[similar] concerns.  Which is where the most concern on exploitation
of ND and large prefixes comes into play.  I think most of us have
been at this for long enough to have given up on the
one-configuration-fits-all school of network design.  A stateful
firewall internally can be a strong tool to mitigate this attack
vector in such environments, depending on their size.  For networks
where a stateful firewall isn't practical, though, that is where
stronger router implementation comes into play.

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
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 being able to use longer prefixes than 64-bit helps
considerably.  I think that seeing routers that can implement ND in
hardware (or at least limit its CPU usage), and not bump known
associations for unknown ones will help considerably.  Stateful
firewalls (where appropriate) will help considerably.  And L2 security
features (ND inspection with rate-limiting, RA guard, DHCPv6 snooping)
will all help -- considerably.  Combined, they make for an acceptable
solution by current standards.

As was also pointed out, though, many networks don't even implement
this level of security for IP internally; the difference is that many
of them haven't needed to for external attacks because of the
widespread use of NAT, stateful firewalls, and much smaller address
space.  That is a little different in the IPv6 world, and why there is
concern being expressed on this list.

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.

This really isn't much different than IPv4.

On Wed, Dec 28, 2011 at 4:08 PM, Jeff Wheeler <jsw () inconcepts biz> wrote:
On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy <rps () maine edu> wrote:
There are a few solutions that vendors will hopefully look into.  One
being to implement neighbor discovery in hardware (at which point
table exhaustion also becomes a legitimate concern, so the logic
should be such that known associations are not discarded in favor of
unknown associations).

Even if that is done you are still exposed to attacks -- imagine if a
downstream machine that is under customer control (not yours) has a
whole /64 nailed up on its Ethernet interface, and happily responds to
ND solicits for every address.  Your hardware table will fill up and
then your network has failed -- which way it fails depends on the
table eviction behavior.

Perhaps this is not covered very well in my slides.  There are design
limits here that cannot be overcome by any current or foreseen
technology.  This is not only about what is broken about current
routers but what will always be broken about them, in the absence of
clever work-arounds like limits on the number of ND entries allowed
per physical customer port, etc.

We really need DHCPv6 snooping and ND disabled for campus access
networks, for example.  Otherwise you could give out addresses from a
limited range in each subnet and use an ACL (like Owen DeLong suggests
for hosting environments -- effectively turning the /64 into a /120
anyway) but this is IMO much worse than just not configuring a /64.

On Wed, Dec 28, 2011 at 10:45 AM,  <sthaug () nethelp no> wrote:
I'm afraid I don't believe this is going to happen unless neighbor
discovery based attacks become a serious problem. And even then it would
take a long time.

The vendors seem to range from "huh?" to "what is everyone else
doing?" to Cisco (the only vendor to make any forward progress at all
on this issue.)  I think that will change as this topic is discussed
more and more on public mailing lists, and as things like DHCPv6
snooping, and good behavior when ND is disabled on a subnet/interface,
begin to make their way into RFPs.

As it stands right now, if you want to disable the IPv6 functionality
(and maybe IPv4 too if dual-stacked) of almost any datacenter /
hosting company offering v6, it is trivial to do that.  The same is
true of every IXP with a v6 subnet.  I think once some bad guys figure
this out, they will do us a favor and DoS some important things like
IXPs, or a highly-visible ISP, and give the vendors a kick in the
pants -- along with operators who still have the "/64 or bust"
mentality, since they will then see things busting due to trivial

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 ]