Re: rfc2460bis and Frag ID generation

[Bob Hinden <[e-mail]>]

Fernando,

> On Feb 4, 2016, at 11:00 AM, Fernando Gont <[e-mail]> 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