turning on comcast v6

Fri Jan 3 09:24:22 UTC 2014

On 01/03/2014 01:15 AM, Baldur Norddahl wrote:
> On Fri, Jan 3, 2014 at 9:40 AM, Doug Barton <dougb at dougbarton.us> wrote:
>
>> On 01/02/2014 10:30 PM, TJ wrote:
>>
>>> I'd argue that while the timing may be different, RA and DHCP attacks
>>> are largely the same and are simply variations on a theme.
>>>
>>
>> Utter nonsense. The ability to nearly-instantly switch traffic for
>> nearly-all nodes on the network is a very different thing than what a rogue
>> DHCP server could do, even if you have ridiculously short lease times,
>> which most don't.
>>
>
> The IPv6 protocol does not give you such an ability (by accident - a hacker
> can steal your IPv4 network too with your completely unprotected network).

... and yet most IPv4 networks are not "completely unprotected."

> There seems to be a lack of detailed understanding of the RFCs in this
> thread.

You can rest assured that I know them pretty well.

> Adding a new router to an already running network will add a second
> router to all clients. But no clients will actually switch to the new
> router unless the old one fails.

... which is simple to accomplish with a DOS, even if the clients 
implement the protocol correctly.

> That is the behavior specified in the RFC. Actual implementations might do
> something different, but that is hardly the fault of the protocol designer.
> Have anyone here actually tested this, or are we just making up stuff?

It's been demonstrated several times at various venues, including at 
least 1 IETF meeting.

> Another person claimed that there would be 15 minuttes or more until the
> network was fixed, after removing a rogue router. That too is completely
> wrong. Every client will monitor the currently used router. If it stops
> responding for 30 seconds, the clients will switch to an alternative router.

Again, you're assuming that the clients implement correctly, however I 
think this one is more common than not since this behavior has been 
prescribed long enough now.

> Also, routers are supposed to monitor their uplink. If the uplink is down,
> no RA should be sent on the downlinks and any current active prefixed
> should be withdrawn. Not all routers implement this, but at the least the
> CPEs are starting to do it correctly. This whole thread builds on the
> assumption that you are using equipment with either bad implementation or
> bad configuration.

... or old enough not to have the latest bells and whistles. And I would 
also argue that when it comes to IPv6 "bad configuration" is still more 
common than not.

> Blocking RA from client ports is just one simple ACL rule on the switch.

If your switch has that code. Given that RA Guard is a fairly recent 
invention, I would argue that at minimum the common case is that any 
random network device does not.

And you still haven't provided an argument about why the default route 
should not be added to DHCPv6.

Doug