Re: Operational comments on RAs vs DHC

[Francis Dupont <Francis.Dupont@fdupont.fr>]

 In your previous mail you wrote:

   A number of administrators that I know of deploying IPv6 (dual-stack) have
   commented on a common problem, specifically the problem of handling 'rogue'
   RAs in their networks.   This includes one admin at our site.
   
=> I strongly agree... We can avoid rogue RIP announces using a password
(poor for security but well suited for this) but there is nothing
for rogue default routers when preference is not deployed and nothing
at all for rogue prefix infos.
   
   There are various tools that could be used to mitigate rogue RAs, e.g.
   - Use of SEND (as and when it's implemented)

=> when I looked at implementing SEND I began by a filtering mechanism
for this reason. BTW with a modern IPsec it is easy to discard rogue
RAs by some extra SPD entries.

   - Vendors adding RA snooping to L2 devices
    (doesn't help shared media though)

=> I believe I understand your idea but it is not real "snooping".

   - Using a higher precedence RA (assuming hosts/routers support it)

=> this works only for the default router, i.e., solve only a part
of the whole issue.

   - Requiring L2 authentication, e.g. 802.1x (but that doesn't help against
     unwitting users)

=> doesn't help in the real world.

   - Using RA authentication (but then who does DHCP auth today?)

=> isn't SEND or a part of SEND? About DHCP auth, it doesn't work in
the real world, and network access control is not the job of DHCP
(cf. DHCPv6 list).

   - Using host-based packet filters (but these need configuring)
   
=> IMHO it is the best current solution and it can be done with IPsec.
Of course as you say it needs configuring... But how to recognize rogue RAs
without some kind of configuring?

   Is there a WG viewpoint on the practical short and long term solution to
   this problem?
   
=> it took many years to recognize a precedence is very useful (I have still
the (negative) answers when I tried this) so I am not very optimistic.
One can say that SEND is more than recommended in environments which
are not fully under your control too...

Regards

Francis.Dupont@fdupont.fr