Rogue IPv6 Router Advertisement Problem Statement
RFC 6104

I found this document to be quite clear and informative. I have a few comments that could improve readability: 

1. Many acronyms lack expansion at first occurance. For example because NA is not expanded the last paragraph in section 1 is hard to understand. Also lacking - VLAN, DHCPO, SeND, ICS. 

2. It would be good to provide references to the tools descreibed in Section 3.8

3. Section 3.10 - not clear what exactly is meant by 'different layer 2 medium' - if this means 'physically separate layer 2 network' than the later terminology is better.

I support the duscuss by Tim (as does Ari's review below).

Review by Ari Keränen:

1. Introduction

   In
   addition a network experiencing malicious attack of this kind is
   likely to also experience malicious NA and related messages also.

Expand "NA".


2.3. Malicious misconfiguration

   In writing this text we came to the conclusion that the
   issue of malicious attack, due to the other complementary attacks
   that are likely to be launched using rogue NA and similar messages,
   are best considered elsewhere.

If there is such a document, reference could be useful.


3.2. Introduce RA snooping

   This type of solution
   has appeal because it is a familiar model for enterprise network
   managers, but it can also be used to complement SeND, by a switch
   acting as a SeND proxy for hosts.

Expand "SeND" and add reference to the RFC or Section 3.4.


4. Scenarios and mitigations

   In this section we summarise the scenarios and practical mitigations
   described above in a matrix format.  We consider, for the case of a
   rogue multicast RA, which of the mitigation methods helps protect
   against each cause.

I would suggest using "against administrator and user errors" instead of "against each cause", since you have only two causes (it took a couple of cycles to figure out what "each cause" meant here).


5.1. Unicast RAs

   The above discussion was initially held on the assumption that rogue
   multicast RAs were the cause of problems on a shared network subnet.
   However, the specifications for Router Advertisements allow them to
   be sent unicast to a host, as per Section 6.2.6 of RFC4861.  If a
   host sending rogues RAs sends them unicast to the soliciting host,
   that RA may not be seen by other hosts on the shared medium, e.g. by
   a monitoring daemon.  In most cases though, an accidental rogue RA is
   likely to be multicast.

Wouldn't it then make sense to recommend for such daemons to capture RAs in a promiscuous mode?


5.5. Recovering from bad configuration state

   A host that is aware of
   protocols such as shim6 may believe it is genuinely multihomed.

Missing shim6 reference.


7. Security Considerations

   This document is Informational.  It does not describe solutions for
   malicious attacks on a network for which malicious RAs may be part of
   a broader attack, e.g. including malicious NA messages.

The security effects of non-malicious RAs could be discussed.

Stig is now with Cisco.

I support Tim's DISCUSS position.

It's not clear what he following means:

"But for accidental problems like Windows ICS and 6to4, it could be useful." 

In particular references are needed.

===========
In Section 5.1

If a host sending rogues RAs
                       ^
Spurious "s"

===========

"In the case of Windows ICS"

Needs a reference (and an expansion of "ICS"

===========

Section 8

"Where managed switches are no available"

S/no/not/

Then next line I think s/moreso/more so/