Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Fernando Gont <> Sun, 26 February 2017 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3B8212989D; Sat, 25 Feb 2017 23:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kJp7d9ot9M-v; Sat, 25 Feb 2017 23:01:13 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31502129630; Sat, 25 Feb 2017 23:01:13 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BC5FA809EA; Sun, 26 Feb 2017 08:01:07 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
References: <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sun, 26 Feb 2017 03:42:08 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:,, "" <>,, "" <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Feb 2017 07:01:15 -0000


Page 15 of the document says:

    For every packet that is to be fragmented, the source node generates
    an Identification value.  The Identification must be different than
    that of any other fragmented packet sent recently* with the same
    Source Address and Destination Address.  If a Routing header is
    present, the Destination Address of concern is that of the final

      *  "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.  Examples of
          algorithms that can meet this requirement are described in

This is certainly an improvement over RFC2460, which suggested the use
of a simple counter to achieve this requirement. While the algorithms in
RFC7739 are meant to result in non-predictable (by off-path attackers)
Identification values, I believe that this spec should clarify that
Identification values should not be predictable by off-path attackers.

The survey in Appendix B of RFC7739
(<>) shows some sample
popular implementations that, unfortunately, still employ predictable
Identification values.

Given too-frequent pattern of protocol implementations employing
improper numeric-identifier generators (see
<>) and
<>), I think
an explicit requirement is warranted.


On 02/01/2017 08:49 PM, The IESG wrote:
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'Internet Protocol, Version 6 (IPv6) Specification'
>   <draft-ietf-6man-rfc2460bis-08.txt> as Internet Standard
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2017-03-01. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>    This document specifies version 6 of the Internet Protocol (IPv6).
>    It obsoletes RFC2460
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> The document contains these normative downward references.
> See RFC 3967 for additional information: 
>     rfc4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft Standard - IETF stream)
>     rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

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