RA-guard ... useful or not (draft-vandevelde-v6ops-ra-guard )

Hello,

I would like to follow up on the discussion in the WG regarding solutions to the rogue RAs problem. As one of the co-authors of the RA-guard drafts I obviously see value in this work so I wanted to bring some of the pro arguments up for discussion. In return, I am looking for the counter arguments which could help reach a conclusion on the usefulness of this work.

Overview:
We see the RA-guard document as providing a framework for several solutions to the rogue-RA problem. These solutions can span the spectrum from basic (where the port of the L2 device is statically instructed to forward or not to forward RAs received from the connected device) to advanced (where a criteria is used by the L2 device to dynamically validate or invalidate a received RA, this criteria can even be based on SEND mechanisms). In its current format, the RA-guard document is a generalized perspective which could provide explicit examples (the authors have several) of implementations that could be built within its framework.

RA-guard as a deployment complement to SEND:
RA-guard does not intend to provide a substitute for SEND based solutions. It actually intends to provides solutions in those environments where SEND might not be suitable or immediately available. I think it might be fair to expect that there will be some time before SEND is ubiquitous in IPv6 networks and that its large scale deployment still requires a few things to be sorted out. It is also reasonable to expect that some devices might not consider implementing SEND at all. And even when they do, there are some deployment challenges ahead. Many dealing with provisioning hosts with trust anchor certificates. The RA-guard "SEND-validating" RA on behalf of hosts would potentially simplify some of these challenges.

RA-guard intends to provide simple solutions to the rogue-RA problem in such contexts and while in some cases it will do that through a simple solution in others, it leverages SEND between capable devices (L2 and routers) to provide protection to devices that do not consistently use SEND.