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

From: [email-masked]
Date: Wed, 15 Aug 2018 08:58:41 -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-00.txt
	Pages           : 23
	Date            : 2018-08-15

Abstract:
   This document provides an overview of IP fragmentation.  It also
   explains how IP fragmentation reduces the reliability of Internet
   communication.

   Finally, this document proposes alternatives to IP fragmentation and
   provides recommendations for application 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-00
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-00

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: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Aug 2018 11:14:10 +1200

Hi,

Earlier I said:

>>    Application developers SHOULD NOT develop applications that rely on
>>    IPv6 fragmentation
> 
> It isn't obvious to me that this is an algorithmic requirement. If the application
> runs over TCP, how does the developer ensure that TCP will use an MSS that
> avoids the need for fragmentation? (The UDP situation is a bit clearer, but
> RFC8085 introduces considerable complexity, unless we accept that the
> Internet MTU for UDP is 576 or 1280.)

I've looked into this a bit for the UDP case, which doesn't have
the added complexity of MSS negotiation.

The only surefire way of avoiding fragmentation is to switch it
off. The recipe for doing that varies by operating system and version,
and between IPv4 and IPv6. (I have Python code that I've exercised
on Windows 7, Windows 10 and Linux. Thanks to Tom Herbert, Praveen
Balasubramanian and Nick Grifka for advice.)

Whether that automatically solves the problem depends on whether
PMTUD works, which is unpredictable. Therefore, if you want a protocol
*design* that is universal, it can't depend on PMTUD. Disabling 
fragmentation on its own is not enough. (That isn't news.)

The only universal solution therefore seems to be a fully specified
PLPMTUD solution, either built into the protocol design, or available
as a normative reference. I think that would be a better
recommendation than simply saying "don't rely on fragmentation."

IMHO RFC4821 isn't a sufficient normative reference for this.
Possibly draft-ietf-tsvwg-datagram-plpmtud will do it for UDP-based
protocols. But IMHO we need a solution for each transport protocol,
with widely available libraries.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Aug 2018 07:39:08 +0200 (CEST)

> recommendation than simply saying "don't rely on fragmentation."

Summary of my views:

Networks MUST support PMTUD.
Networks MUST support IP level fragmented packets.
Protocols/applications SHOULD have PMTUD blackhole detection.
Protocols/applications SHOULD do PLPMTUD.
Protocols/applications SHOULD avoid IP level fragmentation.

> IMHO RFC4821 isn't a sufficient normative reference for this. Possibly 
> draft-ietf-tsvwg-datagram-plpmtud will do it for UDP-based protocols. 
> But IMHO we need a solution for each transport protocol, with widely 
> available libraries.

Agreed. The libraries part is extremely important. Programmers 
implementing applications should not have to worry about this, it should 
be taken care of by the libraries they use. For them it should just work.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Aug 2018 10:57:34 +0200

> Networks MUST support IP level fragmented packets.

That is not realistic for the IPv4 Internet.
IPv4 fragments do have a higher drop probability than other packets. Just from the fact that multiple end-users are sharing a 16 bit identifier space.

>> IMHO RFC4821 isn't a sufficient normative reference for this. Possibly draft-ietf-tsvwg-datagram-plpmtud will do it for UDP-based protocols. But IMHO we need a solution for each transport protocol, with widely available libraries.
> 
> Agreed. The libraries part is extremely important. Programmers implementing applications should not have to worry about this, it should be taken care of by the libraries they use. For them it should just work.

Cheers,
Ole

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Aug 2018 05:19:04 -0700

> On Aug 16, 2018, at 1:57 AM, Ole Troan <[email-masked]> wrote:
> 

It’s really the fact that NATs that process fragments don’t reassemble before translating and/or don’t rate limit fragments they generate as already required by 791 (as explained in 6884).

A NAT that is broken isn’t helping users share addresses. It’s just broken.

Joe

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Aug 2018 14:47:30 +0200

Joe,

> It’s really the fact that NATs that process fragments don’t reassemble before translating and/or don’t rate limit fragments they generate as already required by 791 (as explained in 6884).

That’s incorrect.
See https://tools.ietf.org/html/rfc7597#section-8.3.3

> A NAT that is broken isn’t helping users share addresses. It’s just broken.

I wish it was that simple.

Cheers,
Ole

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Aug 2018 06:58:25 -0700

> On Aug 16, 2018, at 5:47 AM, Ole Troan <[email-masked]> wrote:
> 
> Joe,
> 
> See https://tools.ietf.org/html/rfc7597#section-8.3.3 <https://tools.ietf.org/html/rfc7597#section-8.3.3>

You should re-read that RFC. It correctly points out that this is a flaw in current devices. 

There is a solution - reassemble before NATing, and when issuing the new packets, issue then with IDs generated at the NAT.

The correct behavior is already indicated in RFC 6864, Sec 5.3.1

> I wish it was that simple.

It’s not simple, but saying that “fragmentation is broken” does not make it more simple either.

Joe

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Aug 2018 19:02:37 +0200

Joe,

> On 16 Aug 2018, at 15:58, Joe Touch <[email-masked]> wrote:
> 
> 
> 

These are not NATs. They are specifically designed to be stateless. Sure you can argue that the A+P solutions break the Internet, our answer to that oh well, move to IPv6. 

> It’s not simple, but saying that “fragmentation is broken” does not make it more simple either.

True. 
Regardless, I fear we aren’t going to agree on this, but at least I think we have understood each other’s points. 

Cheers 
Ole

---

From: Tom Herbert <[email-masked]>
Date: Thu, 16 Aug 2018 10:56:28 -0700

On Thu, Aug 16, 2018 at 10:02 AM, Ole Troan <[email-masked]> wrote:
> IPv4 fragments do have a higher drop probability than other packets. Just
> from the fact that multiple end-users are sharing a 16 bit identifier space.
>
>
> It’s really the fact that NATs that process fragments don’t reassemble
> before translating and/or don’t rate limit fragments they generate as
> already required by 791 (as explained in 6884).
>
>
> That’s incorrect.
> There is a solution - reassemble before NATing, and when issuing the new
> packets, issue then with IDs generated at the NAT.
>
>
> These are not NATs. They are specifically designed to be stateless. Sure you
> can argue that the A+P solutions break the Internet, our answer to that oh
> well, move to IPv6.
>
Ole,

The requirement that "Protocols/applications SHOULD avoid IP level
fragmentation." already acknowledges and provides advice on the
realities of the current state of fragmentation support in the
network. IMO, the statement that "Networks MUST support IP level
fragmented packets." is appropriate. It is simply restating the
existing requirement that nodes conform to Internet standards. If we
downgrade this to be "Networks SHOULD support IP level fragmented
packets." then I fear this is the start of making a a bunch of core
protocol requirements optional. I suspect we'll have softening of
other requirements like "Networks SHOULD support extension headers",
or "Networks SHOULD support protocols other than TCP". That would be
accepting and codifying non-conformance as well as the protocol
ossification that entails.

Tom

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Aug 2018 11:10:26 -0700

> On Aug 16, 2018, at 10:02 AM, Ole Troan <[email-masked]> wrote:
> 
> These are not NATs. They are specifically designed to be stateless

I think we also can agree that this, while intended, is the point of failure. 

Joe

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Aug 2018 20:31:13 +0200

> On 16 Aug 2018, at 20:10, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Sure, pick your poison. If you think a CGN cluster is more end to end friendly. 

It’s fascinating to watch IPv4 evolve through its last phase. :-)

Cheers 
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Aug 2018 08:53:05 +1200

Getting back to the draft under discussion:

On 2018-08-17 05:56, Tom Herbert wrote:
...> The requirement that "Protocols/applications SHOULD avoid IP level
> network. 

Acknowledges, yes. Provides *useful* advice, no. That was my original
point. IMNSHO, useful advice would be "support PLPMTUD, and this
is how to do it." Otherwise, application developers are on their own.

> IMO, the statement that "Networks MUST support IP level
> fragmented packets." is appropriate. 

As a motto for the Internet, yes. For the present draft, not so much.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Aug 2018 14:07:41 -0700

On Aug 16, 2018, at 1:53 PM, Brian E Carpenter <[email-masked]> wrote:

> As a motto for the Internet, yes. For the present draft, not so much

Th draft can still advise how to adapt with ole still making this assertion. 

Ie, we recognize that MUST != DO

But it outright to also provide specific advice on how frag should be supported so that noncompliance net devices can be fixed too. 

Joe