Re: [Int-area] FW: Last Call: 'Fragmentation Considered Very Harmful' to Informational RFC (draft-heffner-frag-harmful)

[Joe Touch <[e-mail]>]

Matt Mathis wrote:
> 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.)

I'd prefer that approach to deliberately encourage breaking fragmentation.

> 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).

This is the bigger issue. Tunnels supposed to honor the DF bit, but
basically cannot. There are two alternatives:

- clear DF in the outer header and take your chances

- set the DF bit in the outer header but allow the head of a tunnel to
fragment

	this is close to what Fred suggests, but IMO a lot simpler.
	here's the idea:

	- tunnel head MAY fragment even if arriving packet has DF set

	- tunnel MUST set DF in all segments emitted (no further
	fragmentation, which appears to be otherwise possible if DF
	is clear)

	- tunnel 'remembers' an MTU for each outgoing link
	(it can be the min of all outgoing link MTUSs)

	- when tunnel receives ICMP too-big, it recalibrates the
	MTU accordingly and fragments subsequent packets accordingly

This method uses conventional PMTU, i.e., sends large packets and resets
the MTU down when ICMP NACKs are received, vs. Fred's draft which
involves probes. It has disadvantages (susceptible to blackholing) but
doesn't involve a new header either, and might be worth noting.

This makes a tunnel act just like a link (which it *IS*!); links like
ATM do this routinely; when they fragment, they take responsibility for
monitoring the fragments.

FWIW, this differs from what 2003 and 2401/4301 say regarding DF; they
lump whether you can fragment and how to set/clear the DF bit in the
same bin. It'd be much more useful to separate the two.

(Fred - consider this input to your doc ;-)

Joe
		


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area