Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation

Simon Perreault <simon.perreault@viagenie.ca> Wed, 11 January 2012 13:14 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94B621F86F4 for <v6ops@ietfa.amsl.com>; Wed, 11 Jan 2012 05:14:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPsX1BcG5QqU for <v6ops@ietfa.amsl.com>; Wed, 11 Jan 2012 05:14:23 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5C521F86D8 for <v6ops@ietf.org>; Wed, 11 Jan 2012 05:14:23 -0800 (PST)
Received: from balaise.nomis80.org (modemcable070.153-130-66.mc.videotron.ca [66.130.153.70]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7284A20D15; Wed, 11 Jan 2012 08:13:52 -0500 (EST)
Message-ID: <4F0D8B0F.2030400@viagenie.ca>
Date: Wed, 11 Jan 2012 08:13:51 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>
References: <4F04F5CA.6010802@si6networks.com> <4F05AA98.4090400@viagenie.ca> <4F0A4D7F.6000101@si6networks.com>
In-Reply-To: <4F0A4D7F.6000101@si6networks.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2012 13:14:23 -0000

On 01/08/2012 09:14 PM, Fernando Gont wrote:
> The second bullet in Section 3 is meant to address fragment-handling:
>
>     o  If the layer-2 device is unable to identify whether the packet is
>        an ICMPv6 Router Advertisement message or not (i.e., the packet is
>        a fragment, and the necessary information is missing), and the
>        IPv6 Source Address of the packet is a link-local address or the
>        unspecified address (::), block the packet.
>
> The idea is that if that non-first fragments are always forwarded,
> whereas first-fragments are blocked if:
>
> a) We've found that what follows the fragment header is an RA packet, or,
>
> b) this is a first-fragment, and it is missing upper-layer protocol
> information.

Ok, I understand now. Thanks.

I still don't see where in the text it is said that non-first fragments 
are always forwarded. It looks like it makes no difference between first 
and non-first.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca