Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2022-07-06
07 Cindy Morgan This document now replaces draft-gont-v6ops-ra-guard-implementation, draft-gont-v6ops-ra-guard-evasion instead of draft-gont-v6ops-ra-guard-implementation
2015-10-14
07 (System) Notify list changed from v6ops-chairs@ietf.org, draft-ietf-v6ops-ra-guard-implementation@ietf.org to (None)
2014-02-11
07 (System) RFC published
2014-02-10
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-01-13
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-01-08
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-12-03
07 (System) RFC Editor state changed to EDIT from MISSREF
2013-03-12
07 Fred Baker Changed shepherd to Fred Baker
2012-11-20
07 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2012-11-19
07 (System) IANA Action state changed to No IC
2012-11-19
07 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-11-19
07 Amy Vezza IESG has approved the document
2012-11-19
07 Amy Vezza Closed "Approve" ballot
2012-11-19
07 Amy Vezza Ballot approval text was generated
2012-11-19
07 Amy Vezza Ballot writeup was changed
2012-11-16
07 Francis Dupont Request for Telechat review by GENART Completed: On the Right Track. Reviewer: Francis Dupont.
2012-11-16
07 Ron Bonica State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2012-11-15
07 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2012-11-15
07 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2012-11-15
07 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2012-11-15
07 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-11-15
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-11-15
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-11-14
07 Benoît Claise
[Ballot comment]
Minor point. Take it or leave it.
In section 2

  Section 2.2 describes an attack method based
  on the use of …
[Ballot comment]
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
2012-11-14
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-11-14
07 Ralph Droms
[Ballot comment]
In my opinion, this document provides useful descriptions of attacks
on IPv6 RA-Guard and techniques for mitigating those attacks.

Revision -07, to be …
[Ballot comment]
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.
2012-11-14
07 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2012-11-14
07 Ron Bonica Ballot writeup was changed
2012-11-14
07 Sean Turner [Ballot comment]
I support Ralph's and Russ' discuss.
2012-11-14
07 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2012-11-14
07 Pete Resnick
[Ballot comment]
I will let others continue the discussion as they see fit, but I'm not going to hold this up. That said, making all …
[Ballot comment]
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.
2012-11-14
07 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2012-11-14
07 Ron Bonica Ballot writeup was changed
2012-11-14
07 Ron Bonica Intended Status changed to Informational from Best Current Practice
2012-11-14
07 Fernando Gont New version available: draft-ietf-v6ops-ra-guard-implementation-07.txt
2012-11-14
06 Fernando Gont New version available: draft-ietf-v6ops-ra-guard-implementation-06.txt
2012-11-14
05 Sean Turner
[Ballot discuss]
One more cook in the process kitchen:

If you're updating 6105, then how is it an informative reference?  It needs to be normative …
[Ballot discuss]
One more cook in the process kitchen:

If you're updating 6105, then how is it an informative reference?  It needs to be normative (regardless of the track discussion).

A follow on issue with staying on BCP/standards track is that if this draft stays on BCP/Standards track and the 6105 reference is normative, then it's a downref.
2012-11-14
05 Sean Turner [Ballot comment]
I support Ralph's and Russ' discuss.

Glad to see the RFC editor's note removing App B.
2012-11-14
05 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2012-11-14
05 Brian Haberman
[Ballot discuss]
1. I am curious about the interesting specification of rules 3 & 4.  The guidance puts requirements on all hosts to enforce the …
[Ballot discuss]
1. I am curious about the interesting specification of rules 3 & 4.  The guidance puts requirements on all hosts to enforce the rules described in ietf-6man-oversized-header-chain, which is still being discussed in the 6MAN WG.  Do the rules defined here force all hosts to implement the rules in ietf-6man-oversized-header-chain even if that draft is abandoned?  Or, from a procedural standpoint, will this draft remain in RFC Editor limbo until ietf-6man-oversized-header-chain is approved (given that it is a normative reference).

2. Rule 3 has a completely bogus use of 2119 keywords.  How does one enforce : "An implementation that has such an implementation-specific limit MUST NOT claim compliance with this specification..."?

3. I cannot accept that RFC 6105 is an Informative reference given that this draft is giving implementation advice for implementing it. How could you not need to completely understand RFC 6105 when following this implementation advice?
2012-11-14
05 Brian Haberman
[Ballot comment]
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 …
[Ballot comment]
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.
2012-11-14
05 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2012-11-14
05 Stewart Bryant
[Ballot comment]
Clearing on the basis of the editor's note addressing  ":Appendix B.  "Advice and guidance to vendors" is inappropriate for an IETF stream document …
[Ballot comment]
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."
2012-11-14
05 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2012-11-13
05 Russ Housley
[Ballot discuss]

  I think that the updates to RFC 6105 belong in an informational RFC,
  and then any BCP statements about the updated …
[Ballot discuss]

  I think that the updates to RFC 6105 belong in an informational RFC,
  and then any BCP statements about the updated protocol belong in a
  separate document.
2012-11-13
05 Russ Housley Ballot discuss text updated for Russ Housley
2012-11-13
05 Robert Sparks [Ballot comment]
I support the discuss positions already entered on this version of the document, particularly Ralph's and Stewart's.
2012-11-13
05 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-11-13
05 Ralph Droms
[Ballot discuss]
In my opinion, this document provides useful descriptions of attacks
on IPv6 RA-Guard and techniques for mitigating those attacks.
However, I don't understand …
[Ballot discuss]
In my opinion, this document provides useful descriptions of attacks
on IPv6 RA-Guard and techniques for mitigating those attacks.
However, I don't understand how this document can be BCP or Standards
Track when it is based on and updates an Informational document,
which, in turn, is only cited as an Informative reference.  RFC 6105
is written so as to describe "IPv6 RA-Guard" without RFC 2119
language.  Why is this document not written in the same way and
published as Informational?
2012-11-13
05 Ralph Droms
[Ballot comment]
In general, couldn't this entire document be summarized in one
sentence to the effect of "An RA-Guard implementation should be sure
to parse …
[Ballot comment]
In general, couldn't this entire document be summarized in one
sentence to the effect of "An RA-Guard implementation should be sure
to parse the entire header chain to ensure it properly detects all
Router Advtertisement messages."?  Perhaps section 3 is describing
other advice to implementors as well as rules for mitigating the
attacks in section 2?

In section 3:

1. I don't understand how rules 1 and 2 derive from (or are
in any way related to) the attacks described in section 2.

2. I don't understand rule 5, which doesn't say anything about
checking the origin of the RA, the source address or the hop count.
2012-11-13
05 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms
2012-11-13
05 Ron Bonica Ballot writeup was changed
2012-11-13
05 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-11-13
05 Stewart Bryant [Ballot discuss]
Appendix B.  "Advice and guidance to vendors" is inappropriate for an IETF stream document and needs to be removed prior to publication.
2012-11-13
05 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant
2012-11-13
05 Martin Stiemerling [Ballot comment]
Appendix B must be removed, as this is purely advertisement and it does not belong in any IETF draft/RFC.
2012-11-13
05 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2012-11-12
05 Russ Housley [Ballot discuss]

  How can a BCP update an Informational RFC?
2012-11-12
05 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley
2012-11-12
05 Stephen Farrell
[Ballot comment]

- section 3, rule 3, last para: how can you have a MUST for
implementations that "MUST NOT claim compliance with this
specification"? …
[Ballot comment]

- 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
2012-11-12
05 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2012-11-10
05 Pete Resnick
[Ballot discuss]
The document status of BCP is an utter mystery to me. This looks like protocol to me, and I therefore have no idea …
[Ballot discuss]
The document status of BCP is an utter mystery to me. This looks like protocol to me, and I therefore have no idea why it is not Proposed Standard. There's nothing in the document to indicate that this is something that isn't worthy of standardization, and shepherd writeup does not explain other than to say:

  The document status requested by the working group for
  draft-gont-v6ops-ra-guard-implementation-04  Implementation Advice for
  IPv6 Router Advertisement Guard (RA-Guard) is BCP. The document provides
  advice thought to be best current practice for the implementation of
  RA-Guard protection specified in RFC6105

I see nothing in the document to indicate that this is "advice", but rather a bunch of MUSTs. That sounds pretty standards-track to me. However, this document is updating RFC6105, which is Informational. I could conceive of an argument that this one should be Informational too. Or that 6105 be put on the standards track. But I see nothing justifying BCP.
2012-11-10
05 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2012-11-10
05 Barry Leiba
[Ballot comment]
I have a few non-blocking comments, which you can chat with me about if you like.

-- General --
You use "discard" and …
[Ballot comment]
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?
2012-11-10
05 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2012-11-09
05 Barry Leiba
[Ballot discuss]
-- Section 3 --
  1.  If the IPv6 Source Address of the packet is not a link-local
      address (fe80::/10), …
[Ballot discuss]
-- Section 3 --
  1.  If the IPv6 Source Address of the packet is not a link-local
      address (fe80::/10), RA-Guard MUST pass the packet.
...
  2.  If the Hop Limit is not 255, RA-Guard MUST pass the packet.

I'm confused: is "pass" right here?  It seems that it should be "MUST discard [or drop] the packet."  Or do I have a basic misunderstanding?
2012-11-09
05 Barry Leiba
[Ballot comment]
I have a few non-blocking comments, which you can chat with me about if you like.

-- General --
You use "discard" and …
[Ballot comment]
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.

-- Section 2.2 --
      A layer-2 device could, however, at least detect that that an
      ICMPv6 message (or some type) is being sent, since the "Next
      Header" field of the Destination Options header contained in the
      first fragment is set to "58" (ICMPv6).

Is there significance to the extra indentation of this paragraph?  If so, can you explain what it is?

-- 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?
2012-11-09
05 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2012-11-09
05 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-11-08
05 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2012-11-08
05 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2012-11-06
05 Ron Bonica Placed on agenda for telechat - 2012-11-15
2012-11-06
05 Ron Bonica Ballot writeup was changed
2012-11-01
05 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-11-01
05 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-11-01
05 Pearl Liang
IANA has reviewed draft-ietf-v6ops-ra-guard-implementation, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there …
IANA has reviewed draft-ietf-v6ops-ra-guard-implementation, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.
2012-10-29
05 Cindy Morgan New version available: draft-ietf-v6ops-ra-guard-implementation-05.txt
2012-10-26
04 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Implementation Advice for IPv6 Router Advertisement …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
  as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
  employed to mitigate attack vectors based on forged ICMPv6 Router
  Advertisement messages.  Many existing IPv6 deployments rely on RA-
  Guard as the first line of defense against the aforementioned attack
  vectors.  However, some implementations of RA-Guard have been found
  to be prone to circumvention by employing IPv6 Extension Headers.
  This document describes the evasion techniques that affect the
  aforementioned implementations, and formally updates RFC 6105, such
  that the aforementioned RA-Guard evasion vectors are eliminated.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ballot/


No IPR declarations have been submitted directly on this I-D.


2012-10-26
04 Cindy Morgan State changed to In Last Call from Last Call Requested
2012-10-26
04 Ron Bonica Last call was requested
2012-10-26
04 Ron Bonica State changed to Last Call Requested from IESG Evaluation
2012-10-26
04 Ron Bonica Last call announcement was generated
2012-07-13
04 Samuel Weiler Request for Early review by SECDIR Completed: Ready. Reviewer: Kathleen Moriarty.
2012-06-28
04 Samuel Weiler Request for Early review by SECDIR is assigned to Kathleen Moriarty
2012-06-28
04 Samuel Weiler Request for Early review by SECDIR is assigned to Kathleen Moriarty
2012-06-24
04 Francis Dupont Request for Last Call review by GENART Completed. Reviewer: Francis Dupont.
2012-06-12
04 Ron Bonica Removed from agenda for telechat
2012-06-12
04 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-06-12
04 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-06-11
04 Ron Bonica Removed as returning item on telechat
2012-06-11
04 Ron Bonica Ballot has been issued
2012-06-11
04 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2012-06-11
04 Ron Bonica Created "Approve" ballot
2012-06-05
04 Ron Bonica Placed on agenda for telechat - 2012-06-21
2012-06-05
04 Ron Bonica Added as returning item on telechat
2012-06-05
04 Pearl Liang
IANA has reviewed draft-ietf-v6ops-ra-guard-implementation-04, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there …
IANA has reviewed draft-ietf-v6ops-ra-guard-implementation-04, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.
2012-05-31
04 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-05-31
04 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2012-05-29
04 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Implementation Advice for IPv6 Router Advertisement …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
  as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
  employed to mitigate attack vectors based on forged ICMPv6 Router
  Advertisement messages.  Many existing IPv6 deployments rely on RA-
  Guard as the first line of defense against the aforementioned attack
  vectors.  However, some implementations of RA-Guard have been found
  to be prone to circumvention by employing IPv6 Extension Headers.
  This document describes the evasion techniques that affect the
  aforementioned implementations, and formally updates RFC 6105, such
  that the aforementioned RA-Guard evasion vectors are eliminated.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ballot/


No IPR declarations have been submitted directly on this I-D.


2012-05-29
04 Amy Vezza State changed to In Last Call from Last Call Requested
2012-05-29
04 Ron Bonica Last call was requested
2012-05-29
04 Ron Bonica Last call announcement was generated
2012-05-29
04 Ron Bonica Ballot approval text was generated
2012-05-29
04 Ron Bonica State changed to Last Call Requested from AD Evaluation
2012-05-29
04 Ron Bonica State changed to AD Evaluation from Publication Requested
2012-05-23
04 Ron Bonica Ballot writeup was changed
2012-05-23
04 Ron Bonica Ballot writeup was generated
2012-05-23
04 Cindy Morgan
1)

The document status requested by the working group for
draft-gont-v6ops-ra-guard-implementation-04  Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard) is BCP. The document provides …
1)

The document status requested by the working group for
draft-gont-v6ops-ra-guard-implementation-04  Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard) is BCP. The document provides
advice thought to be best current practice for the implementation of
RA-Guard protection specified in RFC6105

2)

Technical Summary

  The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
  employed to mitigate attack vectors based on forged ICMPv6 Router
  Advertisement messages.  Many existing IPv6 deployments rely on RA-
  Guard [RFC6105] as the first line of defense against the
  aforementioned attack vectors.  However, some implementations of
  RA-Guard have been found to be prone to circumvention by employing
  IPv6 Extension Headers. This document describes the evasion
  techniques that affect the aforementioned implementations, and
  provides advice on the implementation of RA-Guard, such that the
  RA-Guard evasion vectors are eliminated.

Working Group Summary

Initial version of this draft was announced on the v6ops list 1/5/12,a
previous  related draft draft-gont-v6ops-ra-guard-evasion first
discussed 6/1/11 was supplanted by it Some initial discussion on the
list and between the authors WG chairs and IESG members asked for
guidance on the work being done in V6ops versus the security or internet
areas. Probably as a consequence of the original RFC 6105 RA-Guard work
was done under the v6ops charter it was concluded that v6ops was an
appropriate venue to provide advice to implementers. The document was
accepted as working group document on 2/13/12. Working-group last call
commenced 04/22/12 and Completed on 5/6/12. 26 messages in favor from 11
participants were recorded with none opposed. The outcome of the WGLC is
consistent with the v6ops discussion during IETF 82.

Document Quality

The document has received significant review both within v6ops and
elsewhere in the community such as SAAG and 6man.

Personnel

The document shepherd is Joel Jaeggli co-chair of the v6ops working
group. The responsible AD is Ron Bonica.

3)

The document shepherd as has reviewed the Document in it's present form
and previously as WG participant. Draft 03 and 04 were produced in
response to critique during WG last call and address outstanding nits.
To the extent that we believe all outstanding criticism we belive that
the document is ready for IESG
review and IETF last call.

4)

No concerns with the availability or quality of reviews exist.

5)

As with the RA-Guard before it (RFC 6105) and similar efforts with the
DHCP protocol, the act of hardening a protocol against the potential for
abuse; in this case by filtering ICMPV6 Router advertisements, and
particular recommendations for the handling of extension headers has
both operational considerations and implications for potential future
flexibility. The recommendations (section 3)  are worthy of special
attention in the context of review.

6)

The document shepherd has no special concerns with the current draft.

7)

The document shepherd is aware, of no IPR declarations by the authors or
participants in the activity related to the draft. Precursor work to
this document was carried out with funding from the  UK Centre for the
Protection of National Infrastructure (CPNI).

8)

Insofar as the Document Shepherd is aware no IPR disclosure has been
filed against this document.

9)

As noted in section 2 subsection Working Group Summary discussion of
this document was active prior to it's acceptance as a WG document and
subsequently at the Paris IETF prior to the the documents' last call.
The wg last call was not controversial but did attract favorable support
as well as useful critique.

10)

No appeals are forseen.

11)

Idnits reports two unused references which are in-fact cited. No
outstanding idnits issues are present in draft-04

12)

No formal reviews should be required.

13)

Normative and informative references are correctly identified.

14)

No normative references block publication.

15)

There are no downward normative references.

16)

The document provides additional guidance to an implmentor of RFC 6105
RA-Guard . Devices implementing RFC 6105 are interpreting the validity
or appropriateness of ipv6 ND messages constructed according to RFC 4861
on the basis of local-policy.

17)

The draft does not require any consideration from IANA.

18)

N/A

19)

No formal language code is present or requires Validation
2012-05-23
04 Cindy Morgan Note changed to 'Joel Jaeggli (joelja@bogus.com) is the document shepherd.'
2012-05-23
04 Cindy Morgan Note added 'Joel jaeggli (joelja@bogus.com) is the document shepherd.'
2012-05-23
04 Cindy Morgan Intended Status changed to Best Current Practice
2012-05-23
04 Cindy Morgan IESG process started in state Publication Requested
2012-05-23
04 (System) Earlier history may be found in the Comment Log for draft-gont-v6ops-ra-guard-implementation
2012-05-22
04 Fernando Gont New version available: draft-ietf-v6ops-ra-guard-implementation-04.txt
2012-05-11
03 Fernando Gont New version available: draft-ietf-v6ops-ra-guard-implementation-03.txt
2012-03-08
02 Fernando Gont New version available: draft-ietf-v6ops-ra-guard-implementation-02.txt
2012-03-03
01 Fernando Gont New version available: draft-ietf-v6ops-ra-guard-implementation-01.txt
2012-02-12
00 (System) New version available: draft-ietf-v6ops-ra-guard-implementation-00.txt