Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

[Joe Touch <[e-mail]>]

On 6/1/2012 5:03 PM, Masataka Ohta wrote:
> C. M. Heard wrote:
> 
>> My one reservation is that I do not think it is strictly necessary
>> to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4
>> datagrams.
> 
> Do you mean
> 
>   >>  Sources of non-atomic IPv4 datagrams MUST rate-limit their output
>     to comply with the ID uniqueness requirements.
> 
> is too strict?
> 
> If so, I agree with you.
> 
>> On the other hand, the evidence available to me suggests
>> that existing implementations overwhelmingly comply with this ban
>> anyway, so it does not seem to do any harm.
> 
> I think most NAT boxes do not care ID uniqueness.
> 
> But, it is a lot worse than that.
> 
> Existing routers, which was relying on ID uniqueness of atomic
> packets, are now broken when they fragment the atomic packets.
> 
> So, the requirement may be:
> 
>   >>  Sources of non-atomic IPv4 datagrams SHOULD rate-limit their output
>     to comply with the ID uniqueness requirements.
> 
> or:
> 
>   >>  Sources of non-atomic IPv4 datagrams is encouraged to rate-limit
> their output
>     to comply with the ID uniqueness requirements.

The recommendation in this doc - that such sources MUST rate-limit - is
to comply with the ID uniqueness requirements already in RFC791 that
this doc does not deprecate - e.g., its use to support fragmentation.
It's not that they SHOULD do this in order to comply; if they don't,
they're not in compliance.

We all recognize that there are plenty of non-compliant NAT boxes
(actually, I'd be surprised if there were any compliant ones). Declaring
that non-compliance acceptable is not the purpose of this document.

> In addition, I have one question:
> 
>   Is there some document provided to obsolete the following:
> 
>     The IPv6 fragment header is present
> 
>     when the source has received
>     a "packet too big" ICMPv6 error message when the path cannot support
>     the required minimum 1280-byte IPv6 MTU and is thus subject to
>     translation
> 
>   which is meaningless from the beginning, because length of
>   IPv6 ID is 32 bit, from which it is impossible to generate
>   unique IPv4 ID.

None of which I am aware.

> and one comment:
> 
>   As expired IDs are referenced, may I suggest to add
> 
>     draft-ohta-e2e-nat-00.txt
> 
>   along with [Bo11] and [De11].

The current references - although currently expired - are under current
discussion in INTAREA, and updated versions are expected to be posted by
the time this document is published.

This document is not intended to provide a complete history of A+P
approaches, which would take more than adding a single long expired
reference.

Joe