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

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Oct 2006 07:23:54 +0300

FYI.

The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Fragmentation Considered Very Harmful '
>    <draft-heffner-frag-harmful-02.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-11-17.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-heffner-frag-harmful-02.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
>   

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Oct 2006 13:38:32 +0300 (EEST)

>>    <draft-heffner-frag-harmful-02.txt> as an Informational RFC

I raised this in private comment, but I'll mention this again because 
the authors disagreed with the first point and apparently forgot the 
second one.  Hopefully this would result in others taking a look at 
the draft as well.

- The title should really be "IPv4 Fragmentation Considered Very 
Harmful" plus some minor wording changes.  The document does not as 
written provide sufficient justification why IPv6 fragmentation should 
be considered "very harmful" as IPv6 has 2^16 more bits of fragment 
space, mandatory PMTUD, and routers not fragmenting packets.

I have no problem that the draft also mentions how the considerations 
also apply to IPv6, but not underlining that the serious problems 
mentioned in the draft are IPv4-specific is not good.

- in a couple of places like in 2nd to last paragraph of S2, and S6, 
you forget to mention that the protocol number is also a 
disambiguating factor in the fragment ID generation.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Oct 2006 07:20:55 -0700

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>

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Oct 2006 09:05:03 -0700

Some other observations:

RFC4301 still recommends that it is acceptable to clear the DF bit (sec
5.1.2.1), although it does so in the process of tunneling. That
tunneling is (IMO) already covered in RFC2003, which (in sec 3.1)
prohibits such behavior. Those cases are important to note, and to note
that tunnels - of any kind - are a particularly vexing case as a result.
See RFC4459 for more info.

The document doesn't consider the implications of trying to avoid
fragmentation. There are three choices, all of which should be addressed:

1) use conventional path-MTU that relies on NACKs
	(discussed)

2) use the updated version of path-MTU (pmtud I-D)
	(not discussed)

3) send the smallest possible segment (68 bytes, as per RFC791)
	however, as per 4459, it's impossible to send that over
	a tunnel and not potentially need to fragment it

It's also worth noting - as others pointed out - that this is
IPv4-specific, and that IPv6's prohibition of in-network fragmentation
doesn't solve the problem (notably because a tunnel acts as an endpoint
for its encapsulated packets, so tunnels remain a problem).

I'm not sure this covers all known problems, but it'd be nice to have
something more definitive on the issue rather than 'yet another document
to put in a roadmap on MTU issues'.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Oct 2006 20:01:57 +0300 (EEST)

> See RFC4459 for more info.

Note that in RFC 4301, 'clearing the DF bit' is in the context of new 
outer (encapsulating) header.  The original inner packet's DF bit is 
not modified.  So maybe you implied that fragmentation could be a 
particularly serious issue especially between tunnel endpoints if 
those don't set DF?

(Some implementations also allow modification of the inner DF bit as 
described in 4459 but that's a separate topic..)

> for its encapsulated packets, so tunnels remain a problem).

I'm not sure what you mean by "doesn't solve the problem".  Certainly 
there is still fragmentation in IPv6 world (see below), but I guess 
the main issue with respect to this draft is whether it can be 
classified "Very Harmful"?

It's true that the tunnel encap/decap points may need to fragment and 
reassemble the encapsulating packet in certain cases (see Section 7 of 
RFC2473), but still there is 16 bits more of ID space, which is 
significant improvement -- not enough for "Very Harmful" in my book.

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Oct 2006 11:05:59 -0700

Pekka Savola wrote:
> outer (encapsulating) header.  The original inner packet's DF bit is not
> modified.  So maybe you implied that fragmentation could be a
> particularly serious issue especially between tunnel endpoints if those
> don't set DF?

Yes. The issue is that the fragmentation won't get signalled back to the
origin (internal) endpoint.

> I'm not sure what you mean by "doesn't solve the problem". 

IMO, it won't make fragmentation less likely. Tunneling will drive
fragmentation up, i.e.

> Certainly
> there is still fragmentation in IPv6 world (see below), but I guess the
> main issue with respect to this draft is whether it can be classified
> "Very Harmful"?
> 

The 16 bits of ID space there can be _more_ limiting, not less. The
protocol type is constant (IP inside), so the 16 bits is for all
tunneled traffic. And tunnels can be aggregation points, which means
that multiple IP sources sent over a tunnel use the same tunnel endpoint
addresses. The only thing left is the IP ID field; all other fields are
identical for tunneled traffic, which makes things worse, not better.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Oct 2006 11:13:46 -0700

Folks interested in tunnel MTU issues for in-the-network
tunnels should also look at and comment on:

http://internet-drafts.osmirror.nl/draft-templin-linkadapt-02.txt

Fred
[email-masked] 

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 11:06 AM
To: Pekka Savola
Cc: [email-masked]
Subject: Re: [Int-area] FW: Last Call: 'Fragmentation Considered Very
Harmful'to Informational RFC (draft-heffner-frag-harmful)

> outer (encapsulating) header.  The original inner packet's DF bit is
not
> particularly serious issue especially between tunnel endpoints if
those

> there is still fragmentation in IPv6 world (see below), but I guess
the

Joe

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Oct 2006 22:55:34 +0300 (EEST)

> identical for tunneled traffic, which makes things worse, not better.

All I was saying was that IPv4 has 16 ID bits, IPv6 has 32.  Even for 
tunneled traffic, because ICMPv6 errors are required to contain full 
payload up to 1280 bytes, with IPv6 you _can_ propagate the ICMP 
errors received from the outside to the inside if you wish to. With 
ICMPv4 you don't necessarily have enough payload information to do so. 
I.e., there's only one corner case of using around 1280 byte MTUs and 
packet sizes where you fragmentation is _required_.  I'd say this 
situation is much better with IPv6 than with IPv4.

---

From: John Heffner <[email-masked]>
Date: Fri, 13 Oct 2006 10:17:42 -0400

Pekka Savola wrote:
> second one.  Hopefully this would result in others taking a look at the 
> draft as well.
> 

Someone has also just pointed out a potential ambiguity in the term 
"Fragmentation" so we may be changing the title.

[snip]

> - in a couple of places like in 2nd to last paragraph of S2, and S6, you 
> forget to mention that the protocol number is also a disambiguating 
> factor in the fragment ID generation.

Yes, this was an oversight and has been corrected in our working copy. 
(I think S6 was fixed in -02, please correct me if I'm wrong.)

Thanks,
   -John

---

From: Matt Mathis <[email-masked]>
Date: Fri, 13 Oct 2006 16:11:18 -0400 (EDT)

> mentioned in the draft are IPv4-specific is not good.

I disagree.  If you do the math, 2^32 * 1500 Bytes / MSL is only about one
terabit/second, which we will probably hit in 10-20 years.  I know that number
sounds mind-boggling, but let me assure you than in the early 90's, when we
were just getting FDDI (100 Mb/s) and DS-3's working in the wide area, 10 Gb/s
was equally inconceivable.

Thanks,
--MM--

---

From: Matt Mathis <[email-masked]>
Date: Fri, 13 Oct 2006 17:14:52 -0400 (EDT)

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Oct 2006 15:17:01 -0700

> (Ok one caveat: tunnels can also work if they greatly
> strengthen the IP ID and/or do their own fragmentation).

Right, which is why people should read and comment on:

Fred

Thanks,
--MM--

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Oct 2006 15:57:34 -0700

> (*mostly, because the other route is to strictly enforce the IP ID wrap time

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

> 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

---

From: Matt Mathis <[email-masked]>
Date: Sat, 14 Oct 2006 14:24:39 -0400 (EDT)

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

let me get this straight: you would like to declare all IPv4 TCP
connections running at full speed over fast Ethernet and faster to be
protocol violations?  Some how I don't think others would agree.

> - clear DF in the outer header and take your chances

You missed my point (and part of why the problem space starts looking
fractal).  If you think of the tunnel as a separate protocol that uses
additional methods to protect itself from corruption (say by use of IPSEC, or
an enhanced fragmentation mechanism, etc.) then it can be designed to support
safe fragmentation.  The fact that the payload is also IP packets which
happen to be tagged DF, becomes irrelevant because they are not participating in
the fragmentation itself.  They are just opaque payload data.  (Note that the
tunnel should use it's own IPID space, not copied from the payload.)

There is not an easy way to detect if any particular combination of tunnel and
endpoint features are safe, except to test if it fails with IPID=0.
Unfortunately there are too many false fails to ship products in this
configuration.

One of the things I have musing about is writing a super jumbo tunnel protocol
that would use its own fragmentation to put 64k IP jumbograms into 1500 byte
IP packets with FEC (and without using IP fragmentation).   Think of the
implications....

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

---

From: Joe Touch <[email-masked]>
Date: Sat, 14 Oct 2006 13:43:20 -0700

> protocol violations?  Some how I don't think others would agree.

Unless they stripe across separate IP addresses or ports, they are
violations of 791. We can change that, but we have not yet. Until we do,
it is a violation.

> safe fragmentation.

That's basically what I said too.

> The fact that the payload is also IP packets which

That's true for the inner packet header, not the outer. The outer
defines how the tunnel works, and that's where fragmentation beyond the
tunnel head-end is problematic.

> Unfortunately there are too many false fails to ship products in this

The issue of head-end fragmentation is independent from IPID=0; others
noted that this can be used for duplicate deletion in routers, so
flagging all your packets with the same ID is a good way to trigger
something (router, host) into thinking duplication is going on.

> IP packets with FEC (and without using IP fragmentation).   Think of the

You'd have to fragment the jumbogram to do this, right?

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Oct 2006 13:09:16 -0700

Joe,

> doesn't involve a new header either, and might be worth noting.

FWIW, the period during which the blackholing occurs could
be indefinite if the network doesn't deliver the ICMPs. I
agree that the ICMPs are nice to have, but the mechanism
should work even if they are absent.

Fred