Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
RFC 7113

Note: This ballot was opened for revision 04 and is now closed.

(Ron Bonica; former steering group member) Yes

Yes ( for -04)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ()
No email
send info

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2012-11-10 for -05)
No email
send info
I have a few non-blocking comments, which you can chat with me about if you like.

-- General --
You use "discard" and "drop" packets, apparently interchangeably.  I suggest that you pick one and use it consistently.

Is there significance to the extra indentation of some paragraphs?  If so, can you explain this in the Introduction, perhaps with a sentence at the end, after the 2119 boilerplate.

-- Section 3 --
          An implementation that has such
          an implementation-specific limit MUST NOT claim compliance
          with this specification, and MUST pass the packet when such
          implementation-specific limit is reached.

I have a problem with that first MUST NOT, but it's a small thing.  I don't think 2119 key words are appropriate for compliance information.  I'd greatly prefer, "An implementation that has such an implementation-specific limit is not in compliance with this specification, and MUST pass the packet [...]."

-- Section 8.2 --
   [CPNI-IPv6]
              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)",  UK Centre for the Protection of
              National Infrastructure, (available on request).

I'm pretty sure the RFC Editor isn't going to like this.  Can you post this in the WG wiki?

(Benoît Claise; former steering group member) No Objection

No Objection (2012-11-14)
No email
send info
Minor point. Take it or leave it.
In section 2

   Section 2.2 describes an attack method based
   on the use of IPv6 fragmentation, possibly in conjunction with the
   use of IPv6 Extension Headers.  This later vector has been found to
   be effective with all existing implementations of the RA-Guard
   mechanism.

Question: do you want to insert "stateless" in the last sentence?
RFC 6105 makes the distinction between stateless and statefull

(Brian Haberman; former steering group member) (was Discuss) No Objection

No Objection (2012-11-14)
No email
send info
1. I find it quite amusing that this specification is supposedly targeted at "layer-2 devices", but requires these devices to be fully layer-3 aware.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection (2012-11-13 for -05)
No email
send info
Appendix B must be removed, as this is purely advertisement and it does not belong in any IETF draft/RFC.

(Pete Resnick; former steering group member) (was Discuss) No Objection

No Objection (2012-11-14)
No email
send info
I will let others continue the discussion as they see fit, but I'm not going to hold this up. That said, making all of the "MUST"s into "must"s doesn't really change the fact that this thing looks like it is giving protocol instructions to routers. Remember, 2119 doesn't require that the words be uppercased; 2119 is simply saying that words like "must" are used when there are interoperability requirements for a protocol. So the "must not claim compliance" bit is still wrong and should be removed. But again, I'm not willing to hold up an Informational document over that.

(Ralph Droms; former steering group member) (was Discuss) No Objection

No Objection (2012-11-14)
No email
send info
In my opinion, this document provides useful descriptions of attacks
on IPv6 RA-Guard and techniques for mitigating those attacks.

Revision -07, to be published as Informational without RFC 2119
language (except for text derived from other RFCs), is appropriately
written to provide guidance to implementors to mitigate the attacks
described in the document.

(Robert Sparks; former steering group member) No Objection

No Objection (2012-11-13 for -05)
No email
send info
I support the discuss positions already entered on this version of the document, particularly Ralph's and Stewart's.

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2012-11-14)
No email
send info
I support Ralph's and Russ' discuss.

(Stephen Farrell; former steering group member) No Objection

No Objection (2012-11-12 for -05)
No email
send info
- section 3, rule 3, last para: how can you have a MUST for
implementations that "MUST NOT claim compliance with this
specification"? Seems illogical. I'd say s/MUST/ought/ if
you want to be consistent, but its pretty harmless as-is.

- Appendix B: this advertisement seems unwarranted.

- The secdir review [1] had some suggestions for rewording
some of the security considerations that are worth a look.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03402.html

(Stewart Bryant; former steering group member) (was Discuss) No Objection

No Objection (2012-11-14 for -05)
No email
send info
Clearing on the basis of the editor's note addressing  ":Appendix B.  "Advice and guidance to vendors" is inappropriate for an IETF stream document and needs to be removed prior to publication."

(Wesley Eddy; former steering group member) No Objection

No Objection ()
No email
send info