subnet prefix length > 64 breaks IPv6?

Wed Dec 28 23:08:32 UTC 2011

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 at inconcepts.biz> wrote:
> On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy <rps at 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 at 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
http://www.networkmaine.net/