turning on comcast v6
baldur.norddahl at gmail.com
Fri Jan 3 12:01:04 UTC 2014
On Fri, Jan 3, 2014 at 10:24 AM, Doug Barton <dougb at dougbarton.us> wrote:
> ... and yet most IPv4 networks are not "completely unprotected."
We are apparently talking about "completely unprotected" networks here.
Otherwise there is simply no problem. You would be filtering RA and many
other things, because that is best practice and required by many security
> ... which is simple to accomplish with a DOS, even if the clients
> implement the protocol correctly.
If we are on an unprotected network and we have evil intend, all is lost.
The hacker can simply steal the traffic with a simple arp ping or a ton of
other methods. The original claim was not evil intend, but that of an
accident. But it still requires three mistakes: bad clients, bad routers
and bad configuration.
> That is the behavior specified in the RFC. Actual implementations might do
>> something different, but that is hardly the fault of the protocol
>> 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.
Doesn't work when I try it. The clients just keep using the old gateway and
prefix. But I can't rule out there are bad clients out there, just that it
does not happen on my network. Can you give any examples of bad clients?
> 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
> 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.
This one is something that all major clients have correctly by now. It is a
rather common use case for IPv6 after all. The user connects two gateways
to his network and gets carefree automatic failover with a 30 seconds timer
to detect failure. May not be good enough for your enterprise network, but
sure is quite useful in the SOHO environment.
And you still haven't provided an argument about why the default route
>> should not be added to DHCPv6.
I was not arguing that it didn't. Just that the perceived problem is not
However, I might be inclined to believe that default route in DHCPv6 is a
bad idea. It is a confusing concept, since we already no less than three
methods (*) to discover default route and you want to add a fourth. This
would be something that needs to be implemented in every client, and thus
will not really be usable for at least a decade. By then everyone are used
If you did add default route to DHCPv6, what is then supposed to happen to
the other routes, that the client might discover? By the arguments in this
thread, you do not really want default route from RA, but instead some
security mechanism, that would prevent the client from obtaining routes and
prefixes in addition to the one you provided. That seems to be a completely
(*) prefix::, fe80:: and the one you get from RA.
More information about the NANOG