Subject: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

From: [email-masked]
Date: Wed, 10 Oct 2018 07:38:49 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group WG of the IETF.

        Title           : IP Fragmentation Considered Fragile
        Authors         : Ron Bonica
                          Fred Baker
                          Geoff Huston
                          Robert M. Hinden
                          Ole Troan
                          Fernando Gont
	Filename        : draft-ietf-intarea-frag-fragile-01.txt
	Pages           : 24
	Date            : 2018-10-10

Abstract:
   This document describes IP fragmentation and explains how it reduces
   the reliability of Internet communication.

   This document also proposes alternatives to IP fragmentation and
   provides recommendations for developers and network operators.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-01
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 10 Oct 2018 16:22:47 +0000

I made this comment earlier, but it does not appear to have made it into this version.
Some applications invoke IP fragmentation as a performance optimization, and that
should be mentioned here. But, it also needs to say that RFC4963 warns against
reassembly errors at high data rates.

Suggestion is to add the following to the introduction:

   "While this document identifies issues associated with IP
   fragmentation, it does not recommend deprecation.  Some applications
   (e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Others (e.g.,
   [IPERF3]) invoke IP fragmentation as a performance optimization, but
   can incur reassembly errors at high data rates [RFC4963]."

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, October 10, 2018 7:39 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-intarea-frag-fragile-01.txt
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 Oct 2018 13:55:16 -0700

Thanks for the updated draft. Here are a few comments:

"While this document identifies issues associated with IP
fragmentation, it does not recommend deprecation.  Some applications
(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation."

I would add that use of fragmentation is also expected to work and be
common in limited domains where issues in security and
interoperability in intermediate nodes can be addressed,

>From the draft: "This section explains how IP fragmentation reduces
the reliability of Internet communication." In reality, for most of
the examples in this section it's really implementations (NAT,
firewall, etc.) that are breaking IP fragmentation (and other things
as well).

Sections 4.1-4.4 could be summarized to say that some intermediate
devices perform functions based on inspecting transport layer headers,
and these fail when fragments are presented that don't contain the
transport layer information. This could be further subdivided into
stateful and stateless mechanisms. Policy routing, firewalls, NAT are
just examples of functions that break with fragmentation.

For section 4.5 I'm not sure that being insecure makes fragmentation
unreliable. Similarly 4.6 isn't really a problem with fragmentation
but a process to avoid fragmentation. Maybe section 4 should be
"Problems related to the use of IP fragmentation".

"It is difficult to determine why network operators drop fragments."
In what sense is this "difficult"? Difficult because there are no ICMP
errors for dropped fragments, difficult because network operators
don't share their policy on fragmentation, or other meaning?

Tom

On Wed, Oct 10, 2018 at 7:38 AM,  <[email-masked]> wrote:
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area