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

[Masataka Ohta <[e-mail]>]

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.

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.

and one comment:

 As expired IDs are referenced, may I suggest to add

   draft-ohta-e2e-nat-00.txt

 along with [Bo11] and [De11].

						Masataka Ohta