Matt, John,
1/ During the lifetime of this draft its scope has become restricted to
soley describing the problem. That's good (and it's a good solid draft),
but the abstract or intro needs to explictly say what it is deliberately
not setting out to say (not describing partial solutions, not proposing
solutions).
2/ Given the new restricted scope, the title is wrong - it's snappy, but
not appropriate for this draft any more. It should be "Field Wrapping
Problems with IP Fragmentation" or some such.
"IPv4 Fragmentation Considered Very Harmful" attributes blame squarely on
the fragmentation protocol (as opposed to re-assembly implementations - see
later). This title effectively says "You SHOULD NOT fragment with a 16b ID
field", which is beyond what the text dares to say, and it's beyond what an
informational draft should say.
Even if this was a BCP rather than informational, I would say it would be
wrong to deprecate 16b fragmentation anyway. There are good reasons why
fragmentation is useful (e.g. in tunnels), so we need to try really hard to
find robust ways to do it before writing it off as deprecated. Saying it's
very harmful should only be a last resort if we /prove/ it cannot ever be
done robustly.
As we know, one way to fragment with improved robustness is to use more
bits for the ID field. But if 16b fragmentation is a problem now, 32b
fragmentation will be a problem in the future (not so distant future as
Matt pointed out on int-area
<http://osdir.com/ml/[email protected]/msg00545.html>). IP is
sufficiently pivotal at the neck of the hour glass that anything we say
about it should endure for decades. I would contend that the IETF shouldn't
condone putting off a problem to a later date when we know it will return.
The present title leads us towards that sort of solution, implying "32b ID
fields aren't [ever] very harmful" - on a draft that isn't even meant to be
discussing solutions.
Given hierarchical layering is here to stay (and always has been), it would
be more fruitful to admit that we need to be able to do fragmentation
robustly and so we cannot avoid choosing an ID field width that will
- either not be wide enough at some future time
- or will be overly wasteful today.
In this vein, it would be useful to focus everyone on designing better
re-assembly /implementations/ around a 16b fragmentation /protocol/ (see a
possible idea below). There is no proof yet that we have reached the end of
our innovation potential on this.
A sketch idea for a more robust re-assembly implementation:
On receipt of each fragment, within the re-assembly implementation increase
the precision of the ID field by adding a "received timestamp" of
sufficient precision. Then on a first pass, match fragments only if the
fragment IDs match AND the timestamps are within a certain narrow range of
each other. Otherwise hold the fragment and, as a last resort later, widen
the timestamp range that will cause a match - perhaps when the fragment is
about to be expired from the buffer (...rest of implementation left as an
exercise for the reader).
In summary, a 16bit fragment ID field should be innocent until proven
guilty. As long as the culprit might be /implementations/, the title
shouldn't presume the IPv4 fragmentation /protocol/ is guilty.
3/ The draft should say something about how the problem gets worse if the
sender uses a pseudo-random number generator for the IPid field (as recent
versions of OpenBSD and some versions of FreeBSD do). Then there is no
longer a deterministic wrapping problem, but there is /always/ some small
probability of a clash within the max packet lifetime. A good ref for this is:
S. Bellovin, ``A Technique for Counting NATted Hosts,'' Proceedings of the
Second Internet Measurement Workshop, November 2002.
http://www.cs.columbia.edu/~smb/papers/fnat.pdf
Bob
At 07:06 06/12/2006, Lars Eggert wrote:
Hi,
could the people who had commented on the -02 revision during IETF LC
please take a look whether the latest revision addresses their issues?
Begin forwarded message:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv4 Fragmentation Considered Very Harmful
Author(s) : J. Heffner, et al.
Filename : draft-heffner-frag-harmful-03.txt
Pages : 9
Date : 2006-12-5
Thanks,
Lars
____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe, Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
