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