WGLC for draft-ietf-v6ops-ra-guard-01.txt (was: Re: Rogue RA WGLC)

[Thomas Narten <narten@us.ibm.com>]

Fred Baker <fred@cisco.com> writes:

> This is to initiate a two week working group last call of draft-chown- 
> v6ops-rogue-ra-02.txt and draft-ietf-v6ops-ra-guard-01.txt.

What is the intended status of the ra-guard document? Informational?
(I would assume it is not going on standards track, since the proposed
behavior only loosely specified.)

At this point, I lean against publishing this document at all (in
fairness, I also opposed taking it on as WG document at all.)

My overall issue with it is that it offers little utility (IMO) beyond
that provided by simple L2 filtering. E.g., just dropping all RAs from
ports other than those that are authorized to send RAs. I would assume
existing switches support this sort of thing, and I can't think of an
example right off where an IETF document was published to encourage
such behavior. I.e., vendors are generally smart enough to provide
such facilities already, and don't need an IETF document to do so. If,
the IETF were to publish a document, I think it would be more useful
for it to clearly describe what sorts of port blocking filters should
be provided (and why), so vendors would understand the benefits of
doing so. But again, IMO, just simple filtering is sufficient, and
having an RA Guard entity that looks at RAs, compares them against
detailed configuration information for validity (which, btw, is yet
more one place where misconfiguration can mess things up), doesn't
have sufficient benefits to recommend.

On details of the "stateful learning", the LEARNING state seems to me
to be rather simplistic and would be ineffective after, say, a power
failure. Given it's overall lack of robustness, I have doubts it is
worth recommending this.

Thomas