--- 1/draft-ietf-v6ops-ra-guard-implementation-06.txt	2012-11-14 18:14:19.333841791 +0100
+++ 2/draft-ietf-v6ops-ra-guard-implementation-07.txt	2012-11-14 18:14:19.361841938 +0100
@@ -1,19 +1,19 @@
 
 IPv6 Operations Working Group (v6ops)                            F. Gont
 Internet-Draft                                                   UK CPNI
 Updates: 6105 (if approved)                            November 14, 2012
 Intended status: Informational
 Expires: May 18, 2013
 
   Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
-              draft-ietf-v6ops-ra-guard-implementation-06
+              draft-ietf-v6ops-ra-guard-implementation-07
 
 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
@@ -256,36 +256,41 @@
    The second fragment presents the same challenges as the second
    fragment of the previous variant.  That is, it would be impossible
    for a device processing only the second fragment to locate the second
    Destination Options header (and hence the ICMPv6 header), since the
    "Hdr Ext Len" field of the first Destination Options header is
    present in the first fragment (rather than the second).
 
 3.  RA-Guard implementation advice
 
    The following filtering rules must be implemented as part of an "RA-
-   Guard" implementation on those ports that are not allowed to send
-   ICMPv6 Router Advertisement messages, such that the vulnerabilities
-   discussed in this document are eliminated:
+   Guard" implementation on ports that face interfaces that are not
+   allowed to send ICMPv6 Router Advertisement messages, such that the
+   vulnerabilities discussed in this document are eliminated:
 
    1.  If the IPv6 Source Address of the packet is not a link-local
        address (fe80::/10), RA-Guard must pass the packet.
 
-          RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to
-          discard Router Advertisement messages if their IPv6 Source
-          Address is not a link-local address.
+          RATIONALE: This prevents "RA-Guard" from dedicating compute
+          cycles to filtering packets that originate off-net and, if
+          they are RA's, would not be accepted by the host.  Section
+          6.1.2 of [RFC4861] requires nodes to discard Router
+          Advertisement messages if their IPv6 Source Address is not a
+          link-local address.
 
    2.  If the Hop Limit is not 255, RA-Guard must pass the packet.
 
-          RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to
-          discard Router Advertisement messages if their Hop Limit is
-          not 255.
+          RATIONALE: This prevents "RA-Guard" from dedicating compute
+          cycles to filtering packets that originate off-net and, if
+          they are RA's, would not be accepted by the host.  Section
+          6.1.2 of [RFC4861] requires nodes to discard Router
+          Advertisement messages if their Hop Limit is not 255.
 
    3.  RA-Guard must parse the IPv6 entire header chain present in the
        packet, to identify whether the packet is a Router Advertisement
        message.
 
           RATIONALE: [RFC6564] specifies a uniform format for IPv6
           Extension Header, thus meaning that an IPv6 node can parse an
           IPv6 header chain even if it contains Extension Headers that
           are not currently supported by that node.  Additionally,
           [I-D.ietf-6man-oversized-header-chain] requires that if a