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

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    v6ops mailing list <v6ops@ietf.org>,
    v6ops chair <v6ops-chairs@tools.ietf.org>
Subject: Document Action: 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)' to Informational RFC (draft-ietf-v6ops-ra-guard-implementation-07.txt)

The IESG has approved the following document:
- 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
  (draft-ietf-v6ops-ra-guard-implementation-07.txt) as Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Ronald Bonica and Benoit Claise.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/


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.

RFC Editor Note

OLD>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
<OLD
NEW>
<NEW

OLD>
          RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies
          that the first-fragment (i.e., the fragment with the Fragment
          Offset set to 0) MUST contain the entire IPv6 header chain,
          and allows intermmediate systems such as routers to drop those
          packets that fail to comply with this requirement.
<OLD
NEW>
          RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies
          that the first-fragment (i.e., the fragment with the Fragment
          Offset set to 0) must contain the entire IPv6 header chain,
          and allows intermmediate systems such as routers to drop those
          packets that fail to comply with this requirement.
<NEW

OLD>
          RATIONALE: By definition, Router Advertisement messages MUST
          originate on-link, MUST have a link-local IPv6 Source Address,
          and MUST have a Hop Limit value of 255.  [RFC4861].

<OLD
NEW>
          RATIONALE: By definition, Router Advertisement messages MUST
          originate on-link, must have a link-local IPv6 Source Address,
          and MUST have a Hop Limit value of 255.  [RFC4861].

<NEW

OLD>
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate  Requirement Levels", BCP 14, RFC 2119, March 1997.
<OLD
NEW>
<NEW