Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01

Fernando Gont <fgont@si6networks.com> Fri, 19 December 2014 08:26 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD221A8A96 for <ipv6@ietfa.amsl.com>; Fri, 19 Dec 2014 00:26:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwdWsKHfBjJA for <ipv6@ietfa.amsl.com>; Fri, 19 Dec 2014 00:26:19 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04261A040B for <ipv6@ietf.org>; Fri, 19 Dec 2014 00:26:19 -0800 (PST)
Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1Y1st3-00033y-5F; Fri, 19 Dec 2014 09:26:13 +0100
Message-ID: <5493E020.3010105@si6networks.com>
Date: Fri, 19 Dec 2014 05:21:52 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Brian Haberman <brian@innovationslab.net>, ipv6@ietf.org
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01
References: <CC2EE99E-475C-4DB5-9E7F-ED00B4D48561@employees.org> <86F24DAC-C017-4D09-9431-0C33134B55C2@employees.org> <5486B2E1.4050507@si6networks.com> <54870E28.3010502@innovationslab.net> <5487378A.10007@si6networks.com> <54883E46.9020509@innovationslab.net>
In-Reply-To: <54883E46.9020509@innovationslab.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/vNp8kWz1HgQ4CHEUFTLXKebiC74
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Dec 2014 08:26:22 -0000

Hi, Brian,

On 12/10/2014 09:36 AM, Brian Haberman wrote:
>> 
>> 1) In the same way we do for RFC6528 or RFC6056
>> 
>> 2) With something similar to 
>> (<http://www.si6networks.com/tools/ipv6toolkit>):
>> 
>> # frag6 -d TARGET --frag-id-poliy
> 
> That didn't answer the question.  In order to advance something on
> the standards track, there needs to be at least two interoperable 
> implementations.  How an implementation initializes a field like
> the fragment ID, TCP sequence number, or ephemeral port number has
> no affect on interoperability.
> 
> What you are describing in those documents is implementation
> guidance, not a protocol specification.  Given that, I would
> suggest that this document strike any normative text, drop the
> Updates tag, and move to Informational.

I personally have no issues with proceeding as indicated.

That said, I'm not sure I follow what you say above. This document has
a requirement that the IP ID must not be predictable, and
implementation advice on how to achieve that. The current status of
the ID is std track for the former, not for the later. As far as this
document is concerned, RFC2460 could already be advanced on the
stndards track, since there are at least four different and
interoperable implementations: FreeBSD, OpenBSD, Linux, and OpenSolaris.

While the (un)predicatability of the IP ID certainly does not affect
interoperability, I guess the same applies to lots of other specs
related to security (for instance, the choice of accepting a
non-authenticated packet/chunk_of_data when authentication mechanisms
are place probably does not affect interoperability.... yet we have
plenty of these (for obvious reasons) in the corresponding specs).

That said, and as noted above, I have no issues with proceeding as you
suggested if that's deemed as the right way to go.

Thanks!

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