Subject: IPv6 Fragment Retransmission

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 25 Oct 2021 21:01:29 +0000

Hi, here is a new -00 entitled: "IPv6 Fragment Retransmission". It proposes
using the "Reserved" field in the IPv6 Fragment Header to encode an Ordinal
value that increments by one for each successive fragment in a fragmented
IPv6 packet. The destination uses the Ordinal value to detect missing fragments
and can then send a "Fragmentation Report" ICMPv6 message to the source to
request retransmission. This allows for timely best-effort retransmissions of
individual fragments, which may reduce the incidence of slow end-to-end
retransmissions of entire packets.

Any interest?

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 25, 2021 1:42 PM
To: [email-masked]
Subject: I-D Action: draft-templin-6man-fragrep-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : IPv6 Fragment Retransmission
        Author          : Fred L. Templin
	Filename        : draft-templin-6man-fragrep-00.txt
	Pages           : 7
	Date            : 2021-10-25

Abstract:
   Internet Protocol version 6 (IPv6) provides a fragmentation and
   reassembly service for end systems allowing for the transmission of
   packets that exceed the path MTU.  However, loss of just a single
   fragment requires retransmission of the original packet in its
   entirety, with the potential for devastating effects on performance.
   This document specifies an IPv6 fragment retransmission scheme that
   matches the loss unit to the retransmission unit.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-fragrep/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-templin-6man-fragrep-00

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

_______________________________________________
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: Philip Homburg <[email-masked]>
Date: Tue, 26 Oct 2021 21:33:30 +0200

>retransmissions of entire packets.

This is certainly a clever idea. It is hard to say how useful this is.
There is a strong trend to avoid fragmentation as much as possible.

This reminds me a bit of TCP selective acknowledgements and fast retransmit.

Using concepts from TCP, your proposal can be simplified quite a bit.
The first is to use offsets within the packet (like TCP sequence numbers)
instead of a counter. Though a flag bit might be used to indicate that the
sender speaks this protocol.

We can assume that packet loss is rare and the we want to retransmit as soon
as possible. So it make sense that the report only contains one ID and one
range of missing bytes. The current format is overly complex.

It makes sense to be a bit more explict on how long to wait if
the last fragment is missing. This can avoid problems with overly agressive
reporting or timeout that are too long and get overtaken by transport 
layer timeouts.

Then probably the biggest issue is how long the sender holds on to fragments.
Typically, the IP layer doesn't have an RTT estimate.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Oct 2021 21:45:18 +0200

On 2021-10-25, at 23:01, Templin (US), Fred L <[email-masked]> wrote:
> 
> IPv6 Fragment Retransmission

This is not the same thing, but RFC 8931.
(If you want to know what this might morph into.)

Grüße, Carsten

---

From: Bob Hinden <[email-masked]>
Date: Tue, 26 Oct 2021 16:20:10 -0700

> On Oct 26, 2021, at 12:33 PM, Philip Homburg <[email-masked]> wrote:
> …..
> 

I suspect for this to be useful, it would be major change to most hosts stacks.

I also suspect there would be a lot of non-trivial interactions on transport protocols regarding how and when they do a retransmission.

Bob

---

From: Geoff Huston <[email-masked]>
Date: Wed, 27 Oct 2021 11:45:07 +1100

> On 27 Oct 2021, at 10:20 am, Bob Hinden <[email-masked]> wrote:
> 
> 
> 

Particularly UDP, and with particular implications for the DNS application in DNS servers.

Geoff

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 27 Oct 2021 00:50:50 +0000

I agree with the question raised by Philip.
This is a typical transport layer function. To support this, not simply a field in the fragmentation option, but also many other implementations in the stack.
Also what's the cooperation between this and TCP? Is there any impact?
Are we going to keep the layering or do a cross layer optimization?
I do not see the necessity of implementing this in IP layer while TCP can do this.

Best,
Tianran

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: Wednesday, October 27, 2021 3:34 AM
To: [email-masked]
Subject: Re: IPv6 Fragment Retransmission 

In your letter dated Mon, 25 Oct 2021 21:01:29 +0000 you wrote:
>Hi, here is a new -00 entitled: "IPv6 Fragment Retransmission". It 
>proposes using the "Reserved" field in the IPv6 Fragment Header to 
>encode an Ordinal value that increments by one for each successive 
>fragment in a fragmented
>IPv6 packet. The destination uses the Ordinal value to detect missing 
>fragment s and can then send a "Fragmentation Report" ICMPv6 message to 
>the source to request retransmission. This allows for timely 
>best-effort retransmissions of individual fragments, which may reduce 
>the incidence of slow end-to-end retransmissions of entire packets.
>
>Any interest?

Using concepts from TCP, your proposal can be simplified quite a bit.
The first is to use offsets within the packet (like TCP sequence numbers) instead of a counter. Though a flag bit might be used to indicate that the sender speaks this protocol.

We can assume that packet loss is rare and the we want to retransmit as soon as possible. So it make sense that the report only contains one ID and one range of missing bytes. The current format is overly complex.

It makes sense to be a bit more explict on how long to wait if the last fragment is missing. This can avoid problems with overly agressive reporting or timeout that are too long and get overtaken by transport layer timeouts.

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 27 Oct 2021 08:50:40 +0000

Hi Fred,
It was possible in the feedback message
To mention only the window that is missing (two "fragment offsets").
It would be simple and smaller than the full list of fragments.
The fact that such an approach supports only 1 fragment loss is probably not important
Because typical fragmentation is 2 fragments and typical loss is 1 fragment,
the probability is small for many fragments and many losses at the same time.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: Tuesday, October 26, 2021 12:01 AM
To: [email-masked]
Subject: IPv6 Fragment Retransmission

Hi, here is a new -00 entitled: "IPv6 Fragment Retransmission". It proposes using the "Reserved" field in the IPv6 Fragment Header to encode an Ordinal value that increments by one for each successive fragment in a fragmented
IPv6 packet. The destination uses the Ordinal value to detect missing fragments and can then send a "Fragmentation Report" ICMPv6 message to the source to request retransmission. This allows for timely best-effort retransmissions of individual fragments, which may reduce the incidence of slow end-to-end retransmissions of entire packets.

Any interest?

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 25, 2021 1:42 PM
To: [email-masked]
Subject: I-D Action: draft-templin-6man-fragrep-00.txt

Abstract:

_______________________________________________
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: Philip Homburg <[email-masked]>
Date: Wed, 27 Oct 2021 11:26:01 +0200

> I also suspect there would be a lot of non-trivial interactions on
> transport protocols regarding how and when they do a retransmission.

I wondered where this could be useful. For TCP it probably doesn't make
a lot of sense. TCP already has extensive support for retransmission of
segments. Likewise, QUIC is not an obvious candidate.

So where it could be useful is first tunneling. There is a always a 
possibiliy you have to tunnel over a path MTU of 1280 and still provide a
tunnel link MTU of 1280. If we can improve fragmentation that could make
life a lot easier.

There other obvious candidate is DNS. Though DNS is a bit tricky because
lots of sites seem to filter fragmented packets. 

For the sending side, the obvious question is whether it is possible
to buffer, say, 500 ms worth of fragmented packets. In the case of heavily
anycast, load balanced services like DNS, there is also the question whether
any ICMP would make it back to the sender.

---

From: [email-masked]
Date: Wed, 27 Oct 2021 11:56:53 +0200

> tunnel link MTU of 1280. If we can improve fragmentation that could make

Agree, tunneling doesn't have other solutions (apart from a well managed MTU).
There are (at least) two problems with IP fragmentations:
 - the receiving host may need to do lots of work prior to being able to validate if the reassembled packet is for valid communication
 - middleboxes in the network cannot identify the flow, hindering NAT, filtering etc.

Which makes me think that fragmentation must be done above IP.

O.

---

From: Mike Simpson <[email-masked]>
Date: Wed, 27 Oct 2021 11:50:17 +0100

Would more fragmentation processing not open up more DOS attack surface on the protocol?

On the basis that fragmentation isn’t really meant to happen how big a problem is it?

> On 27 Oct 2021, at 09:51, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi Fred,

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Oct 2021 21:52:40 +1100

On Wed, 27 Oct 2021, 20:57 , <[email-masked]> wrote:

>  - the receiving host may need to do lots of work prior to being able to
> validate if the reassembled packet is for valid communication

Agree. I suggested the MSS and Fragment options in the UDP Options ID for
that reason (draft-ietf-tsvwg-udp-options).

Retransmission of IP fragments won't solve the problem of transit networks
blocking them.

I've been thinking about the observation that fragments are blocked by many
networks, and I think in a lot of cases it is by accident. When being
taught packet filtering I don't remember ever being taught to allow
fragments, and the implicit or explicit deny all at the end drops them. I
don't remember being at any ISP networks where people explicitly said "we
should block fragments".

Infosec people are known to actively drop them because they don't have
transport layer port information in them.

By moving fragmentation to the transport layer, all IP packets will have
transport layer headers and therefore ports to apply ACLs or stateful
firewall rules to.

I'm not entirely sure what that means for tunnelling protocols or others
that rely on IP fragmentation like OSPF. Some of those protocols are
network interior protocols, so they're less likely to encounter firewalls
or ACLS that will drop fragments if they use them.

Still, perhaps shift them all to over UDP and use the MSS/Fragmentation
options? (With QUIC/HTTP3 using UDP, perhaps the 3rd edition of TCP/IP
illustrated will be "UDP/IP Illustrated''?)

Regards,
Mark.

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 27 Oct 2021 11:20:24 +0000

Indeed,
Imagine the misconfiguration when one fragment (probably 1st) is permitted but all others are always filtered.
How many times these lost fragments would be sent over the wire? Billions.
It should be probably in the specification that fragment retransmission should not happen more than N times, then the source should try something else.
Eduard
-----Original Message-----
From: Mike Simpson [mailto:[email-masked]] 
Sent: Wednesday, October 27, 2021 1:50 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Templin (US), Fred L <[email-masked]>; [email-masked]
Subject: Re: IPv6 Fragment Retransmission

> It was possible in the feedback message To mention only the window 
> that is missing (two "fragment offsets").
> The fact that such an approach supports only 1 fragment loss is 
> probably not important Because typical fragmentation is 2 fragments 
> and typical loss is 1 fragment, the probability is small for many fragments and many losses at the same time.
> Eduard
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 27 Oct 2021 15:22:05 +0200

> Agree, tunneling doesn't have other solutions (apart from a well
> managed MTU).  There are (at least) two problems with IP fragmentations:
>  - the receiving host may need to do lots of work prior to being
>  able to validate if the reassembled packet is for valid communication

This amount of work seems to be similar to what TCP is doing. 

For a protocol that runs over UDP, you can have the application do the
segmentation, but if the application is a kernel module, then it doesn't
seem to make a big difference.

For big DNS reponses, you can either use IP fragmentation of retry over TCP.

>  - middleboxes in the network cannot identify the flow, hindering

If the fragments arrive in order, then the first fragment can be used to 
assign the internal flow ID to the <source address, fragment header ID>
tuple. It gets annoying if fragments are reordered. Though if retransmission
works, then in theory a middle box can drop fragments that arrive before the
first fragment.