Re: 6MAN Minutes, Actions, and Document Status

Fernando Gont <> Thu, 26 April 2012 23:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C78C021E8041 for <>; Thu, 26 Apr 2012 16:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mgCHUKYuK-gF for <>; Thu, 26 Apr 2012 16:55:21 -0700 (PDT)
Received: from (unknown [IPv6:2a02:27f8:1025:18::232]) by (Postfix) with ESMTP id 399C021E8029 for <>; Thu, 26 Apr 2012 16:55:21 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <>) id 1SNYWi-0004SA-Fv; Fri, 27 Apr 2012 01:55:17 +0200
Message-ID: <>
Date: Thu, 26 Apr 2012 17:53:28 -0300
From: Fernando Gont <>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Ole Trøan <>
Subject: Re: 6MAN Minutes, Actions, and Document Status
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: " Mailing List" <>, Bob Hinden <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Apr 2012 23:55:21 -0000

Hi, Ole,

On 04/26/2012 08:50 AM, Ole Trøan wrote:
>> I think that draft-gont-6man-predictable-fragment-id is also ready 
>> for wg call for adoption as wg document -- I've rev'ed the
>> document since IETF 83 in response to the feedback received during
>> my presentation (i.e., just require the Frag ID to be
>> unpredictable, without mandating any particular algorithm).
> the chairs have an action item on taking this to the mailing list. 
> there was an issue that I believe Bob raised, if we were going to 
> have publish RFCs on every field in TCP/IP protocols that should
> have unpredictable values, or if we should have a generic
> recommendation applying to protocol design in general.

I believe that a generic document about protocol design that discusses
this issue would be valuable, such that *new* protocols and protocol
implementations do not incur into this problem. However, in this
particular case (Fragment ID), the IPv6 standard itself is suggesting
to use a counter, and hence the spec should be fixed.

That aside, different fields have different requirements. For example,
the constraints for randomizing the transport protocol ports are
different from those of producing unpredictable IDs, and different from
those of say, randomizing the TCP sequence numbers, or randomizing the
IPv6 Flow Label. The consequences of the particular approach that you
follow vary quite a bit in each case.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492