Subject: Responding to Ron's comment about removing fragmentation

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Nov 2014 10:29:35 -1000

[Ran out of mike line]

I don't know of a way to handle encapsulation (such as router doing GRE, 
IP-IP, IPsec tunnels) if we
  - allow hosts to send 1280 byte packets with doing path MTU discovery
  - don't allow the encapsulating node to fragment the packet (which is 
at least 1320 bytes after adding the outer headers)

Thus removing all support for fragmentation from IPv6 has the 
implication of removing all forms of IPv6 packet encapsulation from the 
IPv6 architecture.

Such a radical change doesn't make any sense to me.

    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Nov 2014 09:43:35 +1300

> Such a radical change doesn't make any sense to me.

I agree. I don't think it's realistic. It is really shocking that
some firewalls are alleged to drop fragments and/or ICMPv6-PTB,
and that people apparently don't send them back to the vendor as
a result. But that doesn't mean we don't need fragmentation sometimes.

    Brian

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 14 Nov 2014 20:44:11 +0000

Erik,

In one sense, I agree with you. Encapsulation is the best argument for fragmentation.

However, I think the designers of IPv6 anticipated the problem. Knowing that most interfaces support a 1500 byte MTU, the designers specified a required MTU of 1280. This leaves 220 bytes for encapsulation.

BTW, I don't intend to resurrect draft-bonica-6man-frag-deprecate. There doesn't appear to be WG support for that.

                                                                                    Ron

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Friday, November 14, 2014 3:30 PM
> To: IETF IPv6; Ron Bonica
> Subject: Responding to Ron's comment about removing fragmentation
> 
> [Ran out of mike line]
> 
> I don't know of a way to handle encapsulation (such as router doing GRE, IP-
> IP, IPsec tunnels) if we
>   - don't allow the encapsulating node to fragment the packet (which is at
> least 1320 bytes after adding the outer headers)
> 
> Thus removing all support for fragmentation from IPv6 has the implication of
> removing all forms of IPv6 packet encapsulation from the
> IPv6 architecture.
>

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 21:46:22 +0100

I don't know what the conversation was, but the general idea of removing
fragmentation sounds like a perfect plan to me.

We do need a way of allowing programs to request with the pMTU for a
certain source - dest pair is though. (some socket option)

>  - allow hosts to send 1280 byte packets with doing path MTU discovery

Do you mean 'without' in that sentence maybe?

All hosts are required to support ICMPv6 and thus PTBs and thus PMTUD.

And one always has the guarantee of being able to send 1280 bytes.

> implication of removing all forms of IPv6 packet encapsulation from the

It has the implication that the tunneling protocol has to handle
fragmentation.

eg, taking OpenVPN as an example, OpenVPN makes sure you have a 1500
byte path if you want that.

Indeed, that makes encapsulation protocols more tricky, but mostly in a
corner-case where you are close to 1280 bytes anyway.

Greets,
 Jeroen

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2014 10:47:39 -1000

Having a single MTU is not very useful thinking: Every tunnel then causes a fragmentation problem.

Instead, we need to keep two MTUs:
The one exported to the top of stack (inner MTU), and the one imported from the bottom of the stack (outer MTU)

The inner MTU is 1280, and with IPv6 it is really hard to use anything that is much closer to 1500, as old style (RFC 1191) PMTUD so overwhelmingly breaks and PLPMTUD (RFC 4821) incomprehensibly isn’t switched on.

The outer MTU is 1500 for all instances of reality.

By never sending more than 1280 from an application and never limiting the available MTU below what tunneling removes from 1500, most applications and tunnel stacks can just work well.

Apart from the cognitive dissonance problem, do we really need that 17 % (max) reduction in the number of packets that jamming up the inner MTU to the max would allow?

Grüße, Carsten

PS.: Yes, we made the mistake not to recognize these simple facts in 6LoWPAN.   See section 4 of draft-bormann-6lo-6lowpan-roadmap-00.txt for the (unofficial, but widely implemented) fix.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 21:49:47 +0100

On 2014-11-14 21:44, Ronald Bonica wrote:
> However, I think the designers of IPv6 anticipated the problem.
> Knowing that most interfaces support a 1500 byte MTU, the designers
> specified a required MTU of 1280. This leaves 220 bytes for
> encapsulation.

Exactly. And if one needs more space, then we need to talk about getting
MTU discovery also being able to scale up. See other threads ;)

> BTW, I don't intend to resurrect draft-bonica-6man-frag-deprecate.
> There doesn't appear to be WG support for that.

That is because there are people who do not want to change the work they
have been working on for a long long time.

Though I appreciate the effort that a lot of folks have stuck into it.
Fragmentation (and Flow Labels...) are not matching the ideas used on
the current Internet.

We have learnt a lot of over the close to 20 years that IPv6 has existed
and a lot has changed in the Internet during that time.

As IPv6 is in a way still in it's infancy we have still the possibility
to make changes to it.

Lets not hold "but I did a lot of work on that back then" stop
possibilities of fixing something that will be used for another 50 years.

Unless one wants to start doing this whole "IPng" thing again a lot
sooner than that...

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 21:56:48 +0100

On 2014-11-14 21:43, Brian E Carpenter wrote:
> a result.

It is not that firewalls do this per default.

It is because there are people who forcefully configure them this way.

> But that doesn't mean we don't need fragmentation sometimes.

Fragmentation is not needed. Packets that are larger than 1280 where the
MTU is 1280 should be split up by the tool/protocol sending those packets.

That is what TCP does. UDP rejects them so that the app can fix the size
and chunk them up properly.

Middle boxes that want to modify packets by inserting headers (eg IPSEC
as a general example) are considered broken in the IPv6 model which is
end-2-end.

Greets,
 Jeroen

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 14 Nov 2014 21:06:23 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Jeroen Massar
> 

I think that's a little harsh, Jeroen. In the real world, there are any number of amazingly dumb boxes, end systems, that need all the help they can get to work right. Especially in control systems, which frequently use UDP.

IPv6 acceptance is not helped when so many hard-learned lessons from IPv4 are simply ignored, or deemed unworthy.

Bert

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2014 11:24:49 -1000

I just sent Jeroen a message privately that I think could help framing the discussion about active measurement of MTUs.  See also the discussion about multi-MTU later in intarea.

One related draft is:
http://tools.ietf.org/html/draft-bormann-intarea-alfi-04.txt

We haven’t managed to find a way to make this work (except for “5. Another way of doing it”, and you be the judge whether this is the desirable way forward).

There are a number of very good uses for a way to collect information on the current path, and PMTUD is just the most pressing one (see RFC 4782 for a more esoteric one). We can’t put all of them in the flow label.  Hop-by-hop options are the architecturally correct way, but these seem to be irretrievably damaged by current deployment.

Grüße, Carsten

> On 14 Nov 2014, at 10:47, Carsten Bormann <[email-masked]> wrote:
>

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 22:36:10 +0100

On 2014-11-14 22:06, Manfredi, Albert E wrote:
>> -----Original Message----- From: ipv6
>> [mailto:[email-masked]] On Behalf Of Jeroen Massar
>> 
>> Fragmentation is not needed. Packets that are larger than 1280
>> where the MTU is 1280 should be split up by the tool/protocol
>> sending those packets.
>> 
>> That is what TCP does. UDP rejects them so that the app can fix the
>> size and chunk them up properly.
>> 
>> 
>> Middle boxes that want to modify packets by inserting headers (eg
>> IPSEC as a general example) are considered broken in the IPv6 model
>> which is end-2-end.
> 
> I think that's a little harsh, Jeroen.

Harshness is sometimes need to cut through the .... ;) *wink*

Modifying packets in the middle of a path is a broken concept.

One of the main reasons for having IPv6 is a larger address space, and
the main point of that is: Restoring End To End Connectivity.

Middleboxes that mess around with packets have nothing to do there.

The other IPv6 idea was: keep the core simple, push intelligence to the
hosts. Which is why we fortunately do not fragment in the routers anymore.

And when these hosts (src+dst) know the MTU, they do not need to
fragment. They *always* can get away with sending a 1280 MTUd packet as
that is the minimum packet size there is.

Note that having a middle-box do magic with your packet means you are
putting the logic in the core, which is wrong.

The current Load Balancer case demonstrate this: stupid middle box that
does not handle full IPv6 and thus does not handle ICMPv6 and that
clashes with the end-to-end principle.

> In the real world, there are any number of amazingly dumb boxes, end
> systems, that need all the help they can get to work right.
> Especially in control systems, which
frequently use UDP.

Can you provide examples of these "dumb" boxes and what the problem is
that they are trying to solve so that we can actually fix these "dumb"
boxes and make them a bit "smarter".

> IPv6 acceptance is not helped when so many hard-learned lessons from
> IPv4 are simply ignored, or deemed unworthy.

You mean those Fragmentation attacks that are often happening?

Or the spoofing happening all around the world?

Or the amplification factors of TCP?

Any others.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 23:03:29 +0100

On 2014-11-14 22:24, Carsten Bormann wrote:
> I just sent Jeroen a message privately that I think could help
> framing the discussion about active measurement of MTUs.  See also
> the discussion about multi-MTU later in intarea.

Yep, was reading through it ;)

Keeping it on list is a better idea indeed. Lot more brain power here
next to a lot more experienced people who can give backing reasons why
something would and would not work.

> We haven’t managed to find a way to make this work (except for “5.
> Another way of doing it”, and you be the judge whether this is the
> desirable way forward).

The biggest problem with having a MTU that is allowed to very small is a
spoofing attack that causes a host to start sending for instance 80
bytes packets

It does not matter if the signaling of that small MTU is done with PMTUD
or in a variable somewhere dubbed the MUALTU. If one is able to tell
another host "send very small packets" you got an attack on your hands.

I am thus of the opinion that our semi-random (anybody know how that
number came to be?) minimum MTU of 1280 is a great number as it gives us
a comfortable amount of data to be sent per packet, while not losing too
much (~18% of data given a IPv6+TCP header) on standard Ethernet of 1500
which is the norm.

Of course the real problem here is that attackers can spoof. And we all
know how hard the operator community is not deploying the advised
measures against that...

> There are a number of very good uses for a way to collect information
> on the current path, and PMTUD is just the most pressing one (see RFC
> 4782 for a more esoteric one).

4782 is way too complex and is very focused on TCP, there is more than
that out on the Internets, this magic UDP thing and SCTP for instance.

Just starting sending at 1280 while noting the MTU in the IPv6 header
(instead of this useless Flow Label thing) allows routers to indicate,
in the packet flow, what the MTU is and voila, problem solved, you can
scale your MTU to whatever you want.

Keeping routers simple and stupid is the best plan we have and one of
the best ideas backing IPv6.

> We can’t put all of them in the flow
> label.  Hop-by-hop options are the architecturally correct way, but
> these seem to be irretrievably damaged by current deployment.

Hop-By-Hop options are useless for routers because it requires parsing
after the first 40 bytes of the header. Routers should not have to
bother with that (looking behind the first 40 bytes of a packet) at all.

As an example, sixxsd does not look behind the first 40 bytes unless it
is a locally addressed packet. For forwarding it thus is really fast:
 - check src address is correct for the interface it came in on
 - update hop limit (ICMP Unreach when 0)
 - lookup egress interface based on destination address
 - check MTU and send PTB if needed
 - send packet on egress interface

(ignoring things like 'is that interface up' etc)
But it is a really fast process. The SHA1 verifies of AYIYA are the
heavy weights in the process, not the actual process of forwardings.

Also, one cannot add an option in the middle of a path as that option
might not fit. (eg sending a 1280 byte packet when the MTU is 1280).

Greets,
 Jeroen

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Nov 2014 15:17:59 -1000

> Do you mean 'without' in that sentence maybe?
Correct. Thanks.
> All hosts are required to support ICMPv6 and thus PTBs and thus PMTUD.

I haven't checked all the RFCs, but apart from the translation hook 
(with PMTU < 1280 due to SIIT and its successors), if a host is only 
sending packets smaller than 1281 bytes, then I don't think the host 
should be required to handle receiving PTB.
> It has the implication that the tunneling protocol has to handle
Sure. But moving the fragmentation from IPv6 fraghdr to some 
tunnel-protocol specific mechanism doesn't change anything. And since 
the architecture includes IP-in-IP encapsulation we would need 
fragmentation support in that protocol (which is IP).

    Erik

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 15 Nov 2014 03:47:56 +0100

> should be required to handle receiving PTB.

That works for the PTB case as indeed there will never be a PTB for 1280
as it will send that as a max.

(There are a lot of other situations where ICMP is required though)

> tunnel-protocol specific mechanism doesn't change anything.

It does change a major thing: Nodes implementing IPv6 do not need to
support fragmentation and it avoids various weird attacks.

Of course those attacks just go to the lower layer, eg TCP or a
tunneling proto which needs to now ensure it can send packets of 1280 by
splitting them up.

> And since

I disagree. If the outer MTU is not large enough to encapsulate an inner
packet of 1280 then the tunnel just is not going to work and the user
should chose a different tunneling protocol that handles the
fragmentation over such a small link size.

This is how proto-41 (IPv6 in IPv4) works. And no, we do not accept
fragmented IPv4 packets. Not going to bother reassembling them, too much
overhead a high link speeds.

Greets,
 Jeroen

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 14 Nov 2014 21:02:46 -0800 (PST)

> and chunk them up properly.

Some application protocols do not perform chunking but require that 
a message be encapsulated in a single UDP datagram, i.e., they rely 
on UDP to provide message framing.  DNS is one of those (unless it 
is in expensive TCP-fallback mode).  And it is an established fact 
that if DNSSEC is turned on, it's not difficult for UDP-encapsulated 
replies to exceed the 1280-byte guaranteed minimum MTU.  See Section 
3.2 of https://tools.ietf.org/html/draft-bonica-6man-frag-deprecate-02

If there were some incrementally deployable way of adding a 
fragmentation capability to UDP so that it does not have to rely on 
IP fragmentation for large datagrams, I think the case for removing 
fragmentation from IPv6 would be a lot stronger.  However, I've not 
seen such a proposal.  That's not for want of trying on my part, 
though it may well be from lack of imagination.

Mike Heard

---

From: Ray Hunter <[email-masked]>
Date: Sat, 15 Nov 2014 16:12:20 +0100

> The outer MTU is 1500 for all instances of reality.
I agree having a single MTU is broken thinking. There isn't even a 
specification of what exactly a "path" is in PMTUD.

There are plenty of people who need larger frames (for efficiency) e.g. 
disk over IP. And Metro Ethernet and MAN links regularly exceed 1500 MTU.

But I think you'll find that the reality is that there is actually a 
whole "stack of MTU's" to consider, not just "inside" and "outside", 
because people really do regularly have transport stacks like IP over 
.1q trunk over EoMPLS over Ethernet....... (including 2 label stacks)

If at any point in the stack the relevant MTU at that layer is exceed, 
then bad stuff happens, and any higher layers are rarely informed of 
what exactly has broken where: you just get black-holing.
> By never sending more than 1280 from an application and never limiting the available MTU below what tunneling removes from 1500, most applications and tunnel stacks can just work well.
Most, but not all.
> Apart from the cognitive dissonance problem, do we really need that 17 % (max) reduction in the number of packets that jamming up the inner MTU to the max would allow?
Yes. For the other apps. And it isn't 17% when talking about L2 MTU of 
9000 (or greater).

-- 
Regards,
RayH

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 15 Nov 2014 17:01:24 +0100

On 2014-11-15 16:12, Ray Hunter wrote:
>> The inner MTU is 1280, and with IPv6 it is really hard to use anything
>> that is much closer to 1500, as old style (RFC 1191) PMTUD so
>> overwhelmingly breaks and PLPMTUD (RFC 4821) incomprehensibly isn’t
>> switched on.
>>

The "Path" in PMTUD is for a single IP address to another IP address.
Hence one direction one might have a MTU of 1280 while in the other it
is a full 1500.

Unfortunately there is no way to indicate a prefix there so one could
optimize the caching of that info, but that would be hard anyway.

> disk over IP. And Metro Ethernet and MAN links regularly exceed 1500 MTU.

Definitely. And these are out in the cold at the moment unless they
manually force applications to use a large MTU.

>From an IPv6 perspective, IPv6 does not care.

The only thing those layers need to do is deliver packets with a size of
1280. That they support larger ones is a magic discovery thing at the
moment though, typically starting from the top: 1500 and then going
tuning the number down based on PMTU Discovery (ICMPv6 PTB).

> what exactly has broken where: you just get black-holing.

Having MTU < 1280 is the task of

Nodes that do not accept/parse/handle ICMPv6 and in particular PTBs do
not fulfill the IPv6 Node Requirements.

Now, while I state that I do think that we as the IETF should be making
it better to support such setups (eg Load Balancers doing pure ECMP
based load balancing) but in the end even those will still need to
properly handle ICMPv6.

That style Load Balancers would have been 'happier' if the source of the
ICMPv6 matched the original destination while the router that actually
sent the packet was represented in the ICMPv6 header. But that is also a
broken concept when doing source filtering (uRPF) and the path from
router to original source is not correct.

Greets,
 Jeroen

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 15 Nov 2014 19:52:15 +0100

Le 14/11/2014 21:29, Erik Nordmark a écrit :
> [Ran out of mike line]
>
> I don't know of a way to handle encapsulation (such as router doing
> GRE, IP-IP, IPsec tunnels) if we - allow hosts to send 1280 byte
> packets with doing path MTU discovery - don't allow the encapsulating
> node to fragment the packet (which is at least 1320 bytes after
> adding the outer headers)
>
> implication of removing all forms of IPv6 packet encapsulation from
> the IPv6 architecture.
>

I always thought this IP frag/defrag would be useful over L2s of
constrained devices, e.g. L2 "MTU" 127bytes.

Maybe have the L2 frag operations interact with IP frag (i.e. 802.15.4's
datagram_tag be the IP's frag Identification).

Alex

>
> Erik
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Nov 2014 22:59:42 -0800

> support fragmentation and it avoids various weird attacks.
Jeroen,

If a node doesn't send packets larger than 1280 it doesn't need to 
support fragmentation today.

Perhaps you are referring to the requirement that nodes support reassembly?
RFC 2460 does require reassembly and says
    A node must be able to accept a fragmented packet that, after
    reassembly, is as large as 1500 octets.

That requirement is associated with allowing nodes to send datagrams 
which are up to 1500 byte without any prior knowledge or negotiation 
with the destination.

> fragmentation over such a small link size.

If I understand correctly, you are suggesting that we should deprecate 
IPv6 in IPv6 tunneling.
I'm looking forward to your draft on that topic.

Regards,
    Erik

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 18 Nov 2014 21:32:22 +0000

Erik,

Yikes! When I made that comment at the mike, I didn't realize that it would reinvigorate a larger debate concerning fragmentation. Had I known that, I would have kept my seat ;-)

Having stirred the pot, I offer the following observations:

IPv6 fragmentation isn't working well. Studies show that fragments are discarded in a significant number of IPv6 paths. At every IETF, we hear about a new security issue associated with IPv6 fragmentation. So, our options are a) fix the security issues, b) ignore the security issues or c) deprecate IPv6 fragmentation.

All three options are painful. Pick your pain!

If the IETF were to deprecate IPv6 fragmentation, many applications would not be impacted at all. For example, an application that runs over TCP wouldn't be impacted, because TCP adjusts its MSS accommodate the PMTU. However, many applications might be adversely impacted. An examples are:

- Applications that run directly over IP (e.g., OSPF, RSVP, SIIT)
- Applications that run over UDP (e.g., DNSSEC)
- Tunnels

Of the application that run directly over IP, some rely on IPv6 fragmentation (e.g., SIIT), while others do not (OSPF, RSVP). The ones that do not rely on fragmentation run over a single link and never emit packets larger than the link MTU.

Some applications that run over UDP rely on IPv6 fragmentation (e.g. DNSSEC). To the extent that many IPv6 paths discard fragments, these applications are broken today. As Mike Heard suggests, this problem could be fixed by extending UDP to support fragmentation at the transport layer. I think that we should do this, regardless of whether the IETF deprecates IPv6 fragmentation. We need these extensions to fix current  brokenness.

I don't think that tunnels are a problem. Tunnels shouldn't present a problems so long as:

- tunnel interior nodes can deliver a PTB to the tunnel ingress
- the tunnel ingress executes PMTUD procedures
- the tunnel ingress router can deliver a PTB to the packet source.

In conclusion, I don't think that we should even discuss deprecating IPv6 fragmentation today. We can't deprecate IPv6 fragmentation  until Mike Heard's UDP extensions have been specified and widely deployed. However, the Transport Area should start work on Mike's UDP extensions ASAP.

                                                                            Ron

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Nov 2014 21:50:54 +0000

Hi Ron,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Ronald Bonica
> Sent: Tuesday, November 18, 2014 1:32 PM
> To: Erik Nordmark; IETF IPv6; Ron Bonica
> Subject: RE: Responding to Ron's comment about removing fragmentation
> 
> Erik,
> 
> Yikes! When I made that comment at the mike, I didn't realize that it would reinvigorate a larger debate concerning fragmentation.
> Had I known that, I would have kept my seat ;-)
> 
> IPv6 fragmentation isn't working well. Studies show that fragments are discarded in a significant number of IPv6 paths. At every IETF,
> we hear about a new security issue associated with IPv6 fragmentation. So, our options are a) fix the security issues, b) ignore the
> security issues or c) deprecate IPv6 fragmentation.

IPv6  fragmentation may be useful and necessary in some domains where security
issues and filtering are not matters for concern. So, I don't agree with option c) since
it would apply across *all* domains and not just those where there are problems. 

> If the IETF were to deprecate IPv6 fragmentation, many applications would not be impacted at all. For example, an application that
> runs over TCP wouldn't be impacted, because TCP adjusts its MSS accommodate the PMTU. However, many applications might be
> adversely impacted. An examples are:
> 
> Of the application that run directly over IP, some rely on IPv6 fragmentation (e.g., SIIT), while others do not (OSPF, RSVP). The ones
> that do not rely on fragmentation run over a single link and never emit packets larger than the link MTU.
> 
> Some applications that run over UDP rely on IPv6 fragmentation (e.g. DNSSEC). To the extent that many IPv6 paths discard fragments,
> these applications are broken today. As Mike Heard suggests, this problem could be fixed by extending UDP to support fragmentation
> at the transport layer. I think that we should do this, regardless of whether the IETF deprecates IPv6 fragmentation. We need these
> extensions to fix current  brokenness.
> 

Assuming PTBs are returned (which is not always the case), what does the
ingress do if it gets back a PTB with MTU=1280? The only alternative is to
start fragmenting.

> In conclusion, I don't think that we should even discuss deprecating IPv6 fragmentation today.

I don't disagree with that.

> We can't deprecate IPv6 fragmentation
> until Mike Heard's UDP extensions have been specified and widely deployed. However, the Transport Area should start work on
> Mike's UDP extensions ASAP.

Inserting a fragmentation layer either above or within the UDP header is fine. But,
UDP encapsulation may not always be necessary or desirable.

Thanks - Fred
[email-masked]

> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 19 Nov 2014 14:35:55 +0000

> In conclusion, I don't think that we should even discuss deprecating IPv6 fragmentation today. We can't deprecate IPv6 fragmentation  until Mike Heard's UDP extensions have been specified and widel…

Totally silly question:  if people feel they can get it right in a general way (not application/protocol specific) one layer up, why can’t they on the lower layer?

— 
Bjoern A. Zeeb             "Come on. Learn, goddamn it.", WarGames, 1983

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Nov 2014 15:43:44 +0100

On 2014-11-19 15:35, Bjoern A. Zeeb wrote:
>> In conclusion, I don't think that we should even discuss
>> deprecating IPv6 fragmentation today. We can't deprecate IPv6
>> fragmentation  until Mike Heard's UDP extensions have been
>> specified and widely deployed. However, the Transport Area should
>> start work on Mike's UDP extensions ASAP.
> 
> Totally silly question:  if people feel they can get it right in a
> general way (not application/protocol specific) one layer up, why
> can’t they on the lower layer?

Because IP does not know what the intent of sending a packet is.
The application does know that.

I'll use the 30k example: The application sends a message of 30k over
UDP. The packet is thus split up in about 30 pieces on a 1500 MTU link.

30 packets are sent in fragments.

One of those packets is dropped.

The receiver has 29 packets in it's buffer, waiting for the last piece
to complete the puzzle.

When should the receiver expire this? If the application has a 'resend'
option eg ala TCP, the application will ask for the full 30k again, as
it did not receive any of them.

And when we always lose 1/30 packets, even though 29 make it, the real
message never arrives.

UDP is lossy, but this kind of loss causes complete outage, not what is
intended.

TCP solves this by knowing the MTU (and using MSS) and retransmitting
only what is missing, not all of it.

Hence, much better to solve it on a lower layer where the intent is
known then to do it badly.

Greets,
 Jeroen

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Nov 2014 19:26:36 +0000

Bjoern,

This is far from being a silly question. In fact, you are forcing me to think!

On one hand, we shouldn't expect UDP-based reassembly code to be more robust than IP-based reassembly code. Humans will write both pieces of code and humans produce bugs.

On the other hand, I think that the following are benefits of moving fragmentation capability from layer 3 to layer 4:

1) Remove interaction between IP fragmentation and middle operating at layers 3 and 4

For example, most load balancers balance on a 5-tuple that includes both the UDP source and destination port. If we fragment at the IP layer, the source and destination ports appear in the first fragment only. Load balancing doesn't work so well. If we fragment at the UDP layer, the source and destination port appear in every packet. Load balancing works much better.

We might be able to make a similar statement for stateless firewalls.

2) Make IP fragmentation unavailable to protocols that don't need it

For example, TCP has no need of IP fragmentation. However, it is conceivable that somebody might fragment packets carrying TCP in order to facilitate some kind of attack (e.g., circumvent a stateless firewall). If we removed fragmentation capabilities from the IP layer, this would be impossible.

4) Enable purpose built reassembly strategies

Currently, most IP stacks implement a one-size-fits-all reassembly strategy. If we were to move fragmentation into UDP, the application could specify the reassembly strategy that works best for it. For example, one application may be willing to wait 100 ms for packet reassembly while another might be willing to wait for 10 seconds only.

                                                           Ron

> From: Bjoern A. Zeeb [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2014 9:36 AM
> To: Ronald Bonica
> Cc: Erik Nordmark; IETF IPv6; Ron Bonica
> Subject: Re: Responding to Ron's comment about removing fragmentation
> 
> > In conclusion, I don't think that we should even discuss deprecating IPv6
> fragmentation today. We can't deprecate IPv6 fragmentation  until Mike
> Heard's UDP extensions have been specified and widely deployed. However,
> the Transport Area should start work on Mike's UDP extensions ASAP.
> 
> Totally silly question:  if people feel they can get it right in a general way (not
> application/protocol specific) one layer up, why can't they on the lower
> layer?
> 
> -

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 20 Nov 2014 00:35:10 +0000

> The application does know that.

You used the “application” word (a couple of times throughout your reply).
That application thing is living on top of TCP/UDP/SCTP/..  Even more layers crossed.

I said “in a general way (NOT application/protocol specific).

—

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 20 Nov 2014 10:46:41 +0100

> I said “in a general way (NOT application/protocol specific).

An application should chose an appropriate protocol to send data with.

Not all protocols are appropriate.

Applications uses protocols and thus has to pick the best one:

 - they want a message sent from A to B: thus use IP
   - they want the message delivered in a stream, reliable: TCP
   - they want the message delivered in a stream, unreliable: SCTP[1]
   - they want the message delivered in packets, unreliable: UDP

As such, please expand a lot more on your question.

Greets,
 Jeroen

[1] can of course also make it reliable.

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 20 Nov 2014 17:29:10 +0100 (CET)

> It is because there are people who forcefully configure them this way.

Mm, there's apparently a sufficient supply of ... (stronger
adjective deleted) uninformed and paranoid people with administrator
rights to firewalls to go around.

Do we know if this is this the predominant reason for the high
failure rate of fragmentation?

The question is whether the prevalence of this unfortunate
combination should force our hand in protocol design and deployment.

Regards,

- Håvard

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 20 Nov 2014 17:39:16 +0100 (CET)

> And when we always lose 1/30 packets, even though 29 make it, the real

This is one of the arguments in the classical "Fragmentation
considered harmful" document from Kent and Mogul, readable at

http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf

> UDP is lossy, but this kind of loss causes complete outage, not what is

UDP isn't in itself lossy, it just doesn't guarantee delivery,
small difference, I know, but it can give the wrong impression...
Of course, the example with a 30K UDP datagram is rather extreme
-- as packet loss increases, the probability of one such complete
user datagram of making it through intact quickly decreases to 0.

However, I'm not sure tossing fragmentation in some form by the
wayside is a good idea, ref. DNS w/DNSSEC.  Most such normal
replies appear to currently fit in two or at most three
fragments, and for packet loss to be a real problem for those
datagrams ultimate delivery it has to be unbearably high also for
all other protocols.

Forcing DNSSEC to always use TCP will cause slower responses to
DNS lookups (who wants to be responsible for "making the web
slower"?) and will tax the resources on our publishing DNS name
servers way higher than they are being at the moment.

Regards,

- Håvard

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 20 Nov 2014 17:42:05 +0100

> failure rate of fragmentation?

As the people who know about these issues do not have access to the
equipment that is causing it, it mostly is guess work I would say.

I've seen/heard already several times some 'consultant' giving that
advice though; quite a fun topic to ask them about...

> combination should force our hand in protocol design and deployment.

That people forcefully break things they do not know they should not be
breaking is only one part.

Even locations with a lot of good and knowledgeable people sometimes
will break things on purpose as they will just not work in their
environment.

Take the big Load Balancer debate as a example.
(as described in the draft: draft-v6ops-pmtud-ecmp-problem-01)

The folks having those Load Balancers know that it not handling ICMPv6
at all and PTB in particular is a bad thing, but as they require
stateless and line-rate gear they basically have no other choice.

Greets,
 Jeroen