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