On Wed, 11 Oct 2006, Joe Touch wrote: > The document fails to note that some implementations set the > Identification field to 0. IMO, this is incorrect operation, since there > are no reserved values for that field (including 0). > > E.g.: > http://archive.cert.uni-stuttgart.de/archive/bugtraq/2002/04/msg00184.html > Some cases are claimed to be corrected, but that message indicates a > remaining, deliberate case (if anyone has a handy Linux kernel, it'd be > useful to check). > > Some issues with IPID=0 came up last August on the int-area list, > notably regarding the ROHC review. See also draft-ietf-rohc-tcp-13.txt, > sec 3.2, the Oct 6, 2006 draft (!). I *still* do not consider that > compliant behavior, and it's worth referring to here, IMO>
When working on a much earlier version of this document (before we removed all prescriptive language) I advocated that we encourage people to set the IP ID to zero, because implementations that hard fail when IP ID is zero are (*mostly) statistically failing today. Put another way, given that the IP ID field is not large enough, all values of IP ID are approximately zero anyhow, and any protection is only an illusion. (*mostly, because the other route is to strictly enforce the IP ID wrap time and fragment lifetimes.) BTW, We removed the prescriptive language because there are a huge number of partial solutions, each of which has lots of baggage in the form of preconditions and caveats. We started to write them down, but the solution space (and document) become fractal. The only complete solution is to use a really robust method to get the correct MTU, and then don't fragment. (Ok one caveat: tunnels can also work if they greatly strengthen the IP ID and/or do their own fragmentation). Thanks, --MM-- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
