Re: rfc2460bis and Frag ID generation

Bob Hinden <bob.hinden@gmail.com> Thu, 04 February 2016 19:24 UTC

Return-Path: <bob.hinden@gmail.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 43A981ACE10 for <ipv6@ietfa.amsl.com>; Thu, 4 Feb 2016 11:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 MhHXOUCTRUv3 for <ipv6@ietfa.amsl.com>; Thu, 4 Feb 2016 11:24:21 -0800 (PST)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8659E1ACE0F for <6man@ietf.org>; Thu, 4 Feb 2016 11:24:21 -0800 (PST)
Received: by mail-io0-x233.google.com with SMTP id g73so104417652ioe.3 for <6man@ietf.org>; Thu, 04 Feb 2016 11:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=2U6WQ/fnuuOAWQiKOKYeVVe4rmR3nd88kDvIJWhiayk=; b=kggO3VHmgc5J9ANIP0ChyUprTr5of+hirPFTcQr3hlMwi9tHL3C2Rh7uMJIF89pT29 SZCAwfWZuN8qc1ssDPodv1LcQlDedsXYfVldthrSsw9uSSLRCJ5G1x3bOZb4dKxzQJwo qNhC4IkuKex53rnZQ44vBOY7Mku6TO0g1cdaExuZc1wyfzJqRp49rOXTMfSwM5bkyIDJ DXYVZbhBRzYJ/MROyQRxsFxm5jJtR4weEQYytHW331yMyP80/T2lcKJl40yRmkyOSZsm gST3Dd+615MnHETlNG4EQDlcFBi9mxiEaBJfd4wc/IUjdJ2MBbqXD00FK3Va/Sv66/Sf oAiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=2U6WQ/fnuuOAWQiKOKYeVVe4rmR3nd88kDvIJWhiayk=; b=WZpTJsT8qJZvUSm2wvfA8XNnL3i6F7hrCVsN8wmTh6l21qBLsig7II0e67SDDJMqzX LXS3JVqtJ+VkZFxBGcWPkeKXY3QamuXhZyAcVBfGnZ+LQL4GEFkPyzCSyrvHwcd9DjAi BUWh/RjjoeKaUb0w3GyS0ArvzgVecuQI2cGvTyAvBTpPBZXIHGLlgca6bCFLLs6jCS8O 0//hQ+8IH89I5CtrV0DQ87my4ha2PIjzhQhx/ucI7sLMpuUP4wyPwcsoQYHslhoUBiZt +/PtBiKOqPfV3jJQMk8vjQeQuJxvaPaVGkTcbU+r725eaESOeFYajlNoE9HfqfFVSP3C XKmg==
X-Gm-Message-State: AG10YOSGl1+wfrSA2G8R8V6Z2/+/X82hTrG1o0UhvcJf292EwkCH6AEw7khosP+A1V+y3w==
X-Received: by 10.107.29.19 with SMTP id d19mr12585006iod.24.1454613860982; Thu, 04 Feb 2016 11:24:20 -0800 (PST)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id l11sm5365302iol.17.2016.02.04.11.24.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Feb 2016 11:24:20 -0800 (PST)
Subject: Re: rfc2460bis and Frag ID generation
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4ACEDEB9-8B61-4A28-B772-286AC49370C0"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <56B39FB8.4090604@si6networks.com>
Date: Thu, 4 Feb 2016 11:24:18 -0800
Message-Id: <6EF1C55C-FE16-4019-A6C9-6AD67DA42E84@gmail.com>
References: <56B39FB8.4090604@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/tDOXngsdoo147VWNKNZM6aBUvJU>
Cc: "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 04 Feb 2016 19:24:23 -0000

Fernando,

> On Feb 4, 2016, at 11:00 AM, Fernando Gont <fgont@si6networks.com>; wrote:
> 
> Bob/folks,
> 
> The current text regarding frag ID generation in rfc2460bis says:
> 
> ---- cut here ----
>      *  "recently" means within the maximum likely lifetime of a
>         packet, including transit time from source to destination and
>         time spent awaiting reassembly with other fragments of the same
>         packet.  However, it is not required that a source node know
>         the maximum packet lifetime.  Rather, it is assumed that the
>         requirement can be met by maintaining the Identification value
>         as a simple, 32-bit, "wrap-around" counter, incremented each
>         time a packet must be fragmented.  It is an implementation
>         choice whether to maintain a single counter for the node or
>         multiple counters, e.g., one for each of the node's possible
>         source addresses, or one for each active (source address,
>         destination address) combination.
> ---- cut here ----
> 
> 
> I suggest changing the text to:
> 
> ---- cut here ----
>      *  "recently" means within the maximum likely lifetime of a
>         packet, including transit time from source to destination and
>         time spent awaiting reassembly with other fragments of the same
>         packet.  However, it is not required that a source node know
>         the maximum packet lifetime.  Rather, it is assumed that the
>         requirement can be met by implementing an algorithm that
>         results in a low identification reuse frequency. [RFC7739]
>         discusses possible algorithms that can meet this requirement
>         while avoiding possible security and privacy issues.
> ---- cut here ----
> 
> (where the ref to RFC7739 is obviously informative, rather than normative).
> 
> -- Bottom-line is that rfc2460bis shouldn't suggest algorithms that
> have known issues, and it's better to have an informative reference to
> RFC7739, where possible algorithms are discussed.
> 
> Thoughts?

I looked at this earlier and also thought the 32-bit wrap around counter text was dated.  I am OK with something similar to what you proposed.  My read of the current text is that it is describes the 32-bit wrap around counter as an example, as opposed the only way to do it, so an update like this would be OK.

Other comments?

Thanks,
Bob


Replies:

References: