Folks,
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
destination.
* "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
[RFC7739].
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
(<https://tools.ietf.org/html/rfc7739#appendix-B>) 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
<https://tools.ietf.org/html/draft-gont-predictable-numeric-ids>) and
<https://tools.ietf.org/html/draft-gont-numeric-ids-history>), I think
an explicit requirement is warranted.
Thanks,
Fernando
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
ietf(_at_)ietf(_dot_)org mailing lists by 2017-03-01. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ballot/
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
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492