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

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Sep 2019 14:08:27 -0700

Joe,

> On Aug 30, 2019, at 4:36 PM, Joe Touch <[email-masked]> wrote:
> 
> Hi, all,
> 
> I disagree with the changes indicated in this version.
> 
> The new text is both incorrect does not IMO reflect WG consensus.
> 
> It is simply false that "it WILL break" or "new protocols can't possibly know whether fragmentation works" - you even cite studies where this works the majority of the time (failing 37% for IPv6 DNS resolvers is succeeding 63%). This is not the same as ICMP-based MTU discovery. Users absolutely can test and know this.
> 
> I repeat my previous suggestion with caps for emphasis- that, LIKE ALL PROTOCOLS AND FEATURES IN THE INTERNET, IP fragmentation is not guaranteed to work on any given path and should be confirmed before being relied upon.

The relevant text in -16 is:

  6.1.  For Application and Protocol Developers

  Developers SHOULD NOT develop new protocols or applications that rely
  on IP fragmentation.  When a new protocol or application is deployed
  in an environment that does not fully support IP fragmentation, it
  SHOULD operate correctly, either in its default configuration or in a
  specified alternative configuration.

  While there may be controlled environments where IP fragmentation
  works reliably, this is a deployment issue and can not be known to
  someone developing a new protocol or application.  It is not
  recommended that new protocols or applications be developed that rely
  on IP fragmentation.  Protocols and applications that rely on IP
  fragmentation will fail to work on the Internet.

The text in the first paragraph is unchanged in this version of the draft and has been there for awhile.  The recommendation is still SHOULD NOT.   This does allow other usage if there is a good reason to do so.

The new second paragraph (written to resolve the DISCUSS comment) attempts to discuss the the controlled environment case. It clearly states it is a recommendation (along the lines of the SHOULD NOT) in the first paragraph and explains why.

Note, personally I think, citing your case of failing 37% of the time, is consistent with “will fail to work on the Internet”.

Also, isn’t this the reason why this draft exists, that is fragmentation is fragile.

I hope this helps to explain the change.

Thanks,
Bob

> 
> Joe
> 
> 
> On 2019-08-30 14:31, [email-masked] wrote:
> 
>> 
>> 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-16.txt
>>     Pages           : 28
>>     Date            : 2019-08-30
>> 
>> Abstract:
>>    This document describes IP fragmentation and explains how it
>>    introduces fragility to 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-16
>> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-16
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-16
>> 
>> 
>> 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/
>> 
>> _______________________________________________
>> Int-area mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/int-area
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Tue, 3 Sep 2019 14:20:24 -0700

> The text in the first paragraph is unchanged in this version of the draft and has been there for awhile.  The recommendation is still SHOULD NOT.   This does allow other usage if there is a good re…

Bob, I don't understand this change. The old text had a normative
requirement (a MAY), but the new paragraph doesn't include any
normative requirements. Why? It seems like the WG had come to
consensus on the previous text, but the new text is substantially
different beyond just being an edit.

Tom

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Sep 2019 17:20:03 -0700

Tom,

> On Sep 3, 2019, at 2:20 PM, Tom Herbert <[email-masked]> wrote:
>> 

The change was made to resolve an IESG Discuss.

The first paragraph is still normative and covers the second paragraph.  SHOULD NOT and MAY are related.  The second paragraph describes the controlled environment case in more detail.

The text in -15

   Developers MAY develop new protocols or applications that rely on IP
   fragmentation if the protocol or application is to be run only in
   environments where IP fragmentation is known to be supported.

This isn't workable.  How can a developer possibly know what environment the code is going to be running in?  For example, when code is checked into a Linux distribution, how would the developer know where it is going to be running and IP fragmentation is works reliably?

Bob

---

From: Tom Herbert <[email-masked]>
Date: Tue, 3 Sep 2019 19:51:57 -0700

> This isn't workable.  How can a developer possibly know what environment the code is going to be running in?  For example, when code is checked into a Linux distribution, how would the developer kn…

Bob,

Linux kernel has supported fragmentation for more than twenty years.
If a packet length not marked with DF exceeds MTU it will be
fragmented. That's the default behavior and it is in deployment for a
long time. I don't see any bug here, nor any reason to change the host
implementation. The bug related to fragmentation seems to be that some
non-conformant middleboxes don't properly handle fragments. IMO, the
draft misses an opportunity to influence the change needed to fix
this.

In regards to the changes in the latest version of the draft, Joe had
previoulsy suggested the following alternate text:

“The Internet is a best-effort system and lacks a formal validation or
conformance mechanism. Like any other protocol feature, IP
fragmentation is useful only when it actually works - both by
successfully traversing routers and other in-network devices and when
it is correctly supported by endpoints. As a consequence, like any
other protocol feature, IP fragmentation MAY be used by new protocols
that validate its successful traversal and provide an alternate as a
backup.”

It seemed like this proposed text was positively received on this list
and there wasn't any pushback to it. Is inclusion of this text still
under consideration?

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Sep 2019 08:51:27 -0700

Bob, 

> The new second paragraph (written to resolve the DISCUSS comment) attempts to discuss the the controlled environment case. It clearly states it is a recommendation (along the lines of the SHOULD NO…

It drops the idea that this is allowed - and is factually incorrect. 

First, this absolutely can be known to deployers. This is not like
silent ICMP too-big drops where the cause of the drop cannot be known. 

Second, it's already widely deployed to deal with IP-IP tunnels. 

> Note, personally I think, citing your case of failing 37% of the time, is consistent with "will fail to work on the Internet".

Failing 37% of the endpoints is not the same as failing 37% of the time.
And no, neither one is consistent with "will fail on the Internet". If
you think 37% = will fail, then I'll open a personal casino for you with
those odds for you to win... 

> Also, isn't this the reason why this draft exists, that is fragmentation is fragile.

There are differences of opinion even within the WG as to why this draft
exists. I would believe the authors believe as you state, but others of
us believe that "implementations are buggy" is more the take-home. The
WG and IETF last calls tried to strike a balance that this change
undoes. 

This is not respecting the view of the WG or IETF. 

Joe