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
