Again, this doc is about updating the IPv4 ID specification in RFC791 - which has not yet been updated.
The IPv6-IPv4 translation that creates IPv4 IDs is currently non-compliant with RFC791 and does not override RFC791. This document's update might make that translation easier, but it doesn't make it worse - which is why there remains no need to address that issue in this doc. If you disagree with that conclusion, please contact the INTAREA WG chairs directly. Joe On 8/12/2012 2:25 AM, Masataka Ohta wrote: > Joe Touch wrote: > > Hi, > >>>>> RFC2765 specifies that translators can merely copy the >>>>> low-order bits of the field. >>>> >>>> Yes, but this is not compatible with RFC791. >>> >>> Then, which should we revice? RFC791, RFC2765 or both? >> >> 2765. > > Is it a consensus of IETF? > > Note that it also imply revising RFC2460, because rfc2765 specifies > a way of ID mapping, where as rfc2460 specifies 32bit->16bit mapping > will be performed by translators. > > Note also that there already are working implementations of > rfc2460 and rfc2765. > >> There is no useful way to revise 791 to make the text in 2765 correct. > > Revising rfc791 not requiring a very strong uniqueness is > useful reflecting current practice better than your draft, > even though your draft claims "closely reflect current > practice". > > Moreover, I can see no useful way to revise rfc2765. Do you > have any suggestion? > >>> Without such a decision, there is no point to publish something >>> based on RFC791 and is not compatible with RFC2765. >> >> Sure there is - when IPv6 is not involved. > > But, your draft involves IPv6 and, for example, the following > statement in your draft: > > IPv6, even at typical MTUs, is capable of 18.7 Tbps with > fragmentation between two IP endpoints as an aggregate across all > protocols, > > is not compatible with rfc2460 and rfc2765. > >> An IPv6 source might never send packets larger than IPv4 can natively >> handle - i.e., it could send packets 576 bytes or smaller. In that case, >> the IPv6 source would never get an ICMP "too big" because they're not as >> far as IPv4 is concerned. In that case, the IPv6 source would never >> insert the Fragmentation Header. > > I'm afraid minimum MTU of IPv4 is 68, not 576 bytes. > > Anyway, IPv6 node having no idea on PMTU will send a lot of > exactly 1280 byte long packets, because it will make TCP > most efficient. > >> That is the fundamental flaw in these IPv6 RFCs, but it is behavior that >> is out of scope for an IPv4 source. My doc focuses on the behavior of >> IPv4 sources. > > While I think IPv6 RFCs have many fundamental flaws, a problem > is that there are people in IETF insisting not to admit them > flaws. > > Do you think you can make them admit a flaw? > >>> That is the problem. That is, if you insist on RFC791 as is, not >>> enough is specified on how to generate IPv6 ID. >> >> Yes, but that does not affect an IPv4 source; it remains a problem, but >> out of scope for this doc. > > It is out of scope, if only rfc791 is not revised. > > >>> Thus, there can be only one way (the one in RFC2765) to map IPv6 >>> ID to IPv4 ID > >> Yes, this is a nice goal, but it would have required IPv6 hosts insert >> 16-bit IDs into *every* packet and make them just as unique as IPv4 does. > > No, not *every* packet. But, as you wrote: > >>>> Further, the source might already be inserting the fragmentation header >>>> (e.g., on a 2KB packet). > > every such packet is required to have a unique 32bit ID which must > also be unique as a 16bit ID after translation. > >>> Then, as fixing RFC2460 is politically impossible, we must >>> abandone IPv6 and live with IPv4 forever. >> >> I didn't say we couldn't fix - or at least try to fix - this situation. >> But it remains out of scope for this doc. > > If only you can convince people we should fix rfc2460, not rfc791. > >>> but, "the specification of the similar field in IPv6" is, in >>> your opinion, incomplete, let's finish it first, >> >> IPv6 is fine when it talks to IPv6 only. The goal is to make IPv4 work >> in a similar way. > > You are saying dual stack is clean and the way to go and all the > other IPv6 deployment scenarios should be ignored. > >> it doesn't make it completely correct, though - there remain >> problems that have nothing to do with the changes in this doc that need >> to be addressed separately. > > The question is whether you can have a consensus that rfc2460 > is not completely correct or not. > >>> For another example, >>> >>> Finally, the IPv6 ID field is >>> 32 bits, and required unique per source/destination address pair for >>> IPv6, >>> >>> is, in your opinion, violation of RFC791. >> >> No; the violation occurs only when the lower 16 bits are masked off and >> used by themselves by on-path translators. That has nothing to do with >> the quoted text above. > > The problem is that, if rfc2460 is not "completely correct", above > text in your draft should be something based not on the current > rfc2460 but on completely correctly revised rfc2460, such as > "IPv6 ID field is required unique after translated into 16 bit > IPv4 ID". > >> But neither of the above requires that IPv6 IDs must be easily >> translatable into valid IPv4 addresses using the existing mechanism. > > IPv4 addresses? What do you mean? > > Masataka Ohta >
