Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

Fernando Gont <fgont@si6networks.com> Thu, 31 May 2012 15:19 UTC

Return-Path: <fgont@si6networks.com>
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 23C5121F879E for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 08:19:13 -0700 (PDT)
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=[AWL=-0.000, 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 v0bIYFZKDD4p for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 08:19:12 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6899E21F8760 for <v6ops@ietf.org>; Thu, 31 May 2012 08:19:12 -0700 (PDT)
Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.174]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1Sa79b-0008Na-8w; Thu, 31 May 2012 17:19:11 +0200
Message-ID: <4FC78BE8.6060102@si6networks.com>
Date: Thu, 31 May 2012 12:19:04 -0300
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ran Atkinson <ran.atkinson@gmail.com>
References: <07004891-BB63-4D5A-B858-1069B97CD47F@gmail.com>
In-Reply-To: <07004891-BB63-4D5A-B858-1069B97CD47F@gmail.com>
X-Enigmail-Version: 1.5pre
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
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: Thu, 31 May 2012 15:19:13 -0000

On 05/30/2012 06:05 PM, Ran Atkinson wrote:
> Rule 4 is both a protocol change and (misguided) operational mitigation.  
> Rule 4 is mandatory according to this document and will cause certain 
> perfectly valid IPv6 packets to be dropped instead of forwarded.  The
> rule damages IPv6 and impairs utility of IPv6 in the real world.

I have asked (some of) this already, but will retry:

1) How large do you expect packets employing CALIPSO become? (mostly
curious here)

2) Do you find it acceptable to have your (mtu-zized) traffic be 50%
overhead (at the very least)?
(FWIW, I'm obviously implying that the IPv6 header chain is spanning
multiple fragments, and hence at least the first fragment is 100%
headers -- and not necessarily as a result of employing CALIPSO).

3) Don't you find packets breaking stateless translators "impairing the
utility of IPv6 in the real world"?
(FWIW, packets with an IPv6 header chain spanning multiple fragments do)

4) Do you expect there will not be stateless filtering in IPv6?

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492