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

[Joe Touch <[e-mail]>]

Bob, 

On 2019-09-03 14:08, Bob Hinden wrote:

> Joe,
> 
>> On Aug 30, 2019, at 4:36 PM, Joe Touch <[e-mail]> 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.

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