RFC 2923

TCP Problems with Path MTU Discovery

📅 published September 2000, from ietf

TCP Problems with Path MTU Discovery 🦋

okay bestie, this is RFC 2923, written by K. Lahey from dotRocket, Inc. 💅 It's Informational, dated September 2000, and it's from the Network Working Group. It doesn't specify any Internet standard. It's just sharing info, and the header doesn't list anything it obsoletes or updates. 🌸

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🫶

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 💜

okay so this memo is a catalog of several known TCP implementation problems involving Path Maximum Transmission Unit Discovery (PMTUD). It covers the long-standing black hole problem, stretch ACKs caused by mixing up Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. it's giving troubleshooting diary, honestly 😭

1. Introduction ✨

This memo catalogs several known TCP implementation problems dealing with Path MTU Discovery [RFC1191], including the long-standing black hole problem, stretch ACKs due to confusion between MSS and segment size, and MSS advertisement based on PMTU. The goal is to improve conditions on the existing Internet by making current TCP/IP implementations better. main character energy for the whole stack 🔥

PMTUD can be used with any upper-layer protocol, but it's most commonly used by TCP, so this document doesn't try to cover problems other upper-layer protocols run into. Path MTU Discovery for IPv6 [RFC1981] only deals with IPv6-specific issues, not the TCP issues in this doc. 🦋

Every problem gets described with the same set of fields, so here's the template:

  • Name of Problem: the name of the problem. In this memo, the name is the subsection heading. 🏷️
  • Classification: one or more problem categories it falls under: "congestion control", "performance", "reliability", or "non-interoperation -- connectivity failure". 🎀
  • Description: a definition of the problem, short and sweet but with the background it needs. 📝
  • Significance: a brief summary of the kinds of environments where the problem matters. 🌍
  • Implications: why the problem is seen as a problem. 🤔
  • Relevant RFCs: the RFCs that define the TCP spec the problem conflicts with. These RFCs often qualify behavior with terms like MUST, SHOULD, MAY, and others written capitalized. See RFC 2119 for the exact meaning of those terms. bestie, these are the magic words 🪄
  • Trace file demonstrating the problem: one or more ASCII trace files showing the problem, if applicable. 👀
  • Trace file demonstrating correct behavior: one or more examples of what correct behavior looks like in a trace, if applicable. ✅
  • References: references that go deeper on the problem. 📚
  • How to detect: how to test an implementation to see if it has the problem. This can include tricky bits about making the problem show up and reading traces to spot it (if applicable). 🕵️‍♀️
  • How to fix: for known causes, how to correct the implementation. 🛠️

2. Known implementation problems 🍓

2.1. Black Hole Detection 🕳️

Classification

Non-interoperation -- connectivity failure 💀

Description

okay so a host does Path MTU Discovery by sending out as big a packet as it can, with the Don't Fragment (DF) bit set in the IP header. If the packet is too big for a router to forward onto a particular link, the router must send an ICMP Destination Unreachable -- Fragmentation Needed message to the source address. Then the host shrinks the packet size based on that ICMP message. 🧚

As pointed out in [RFC1435], routers don't always do this correctly. Lots of them fail to send the ICMP messages, for all sorts of reasons, from kernel bugs to configuration problems. Firewalls are often misconfigured to suppress every ICMP message. IPsec [RFC2401] and IP-in-IP [RFC2003] tunnels shouldn't cause these kinds of problems, as long as the implementations follow the advice in the relevant documents. 🙈

PMTUD, as documented in [RFC1191], fails when the right ICMP messages never reach the originating host. The upper-layer protocol keeps sending large packets and, without the ICMP messages, never finds out that it needs to make them smaller. Its packets are vanishing into a PMTUD black hole. 🕳️😭

Significance

When PMTUD fails because the ICMP messages are missing, TCP can also completely fail under some conditions. 💔

Implications

This failure is super hard to debug, because pings and some interactive TCP connections to the destination host still work. Bulk transfers fail on the first large packet, and the connection eventually times out. 😤

Almost always, these situations can be blamed on a misconfiguration in the network, and that should get fixed. Still, it seems unfair for some TCP implementations to have interoperability failures over paths that don't affect other TCP implementations (that is, ones without PMTUD). That creates a market disincentive for shipping TCP implementations with PMTUD enabled. not the vibe 🙅‍♀️

Relevant RFCs

RFC 1191 describes Path MTU Discovery. RFC 1435 gives an early description of these kinds of problems. 📖

Trace file demonstrating the problem

Made using tcpdump [Jacobson89] recording at an intermediate host. 🔍

20:12:11.951321 A > B: S 1748427200:1748427200(0)
     win 49152 <mss 1460>
20:12:11.951829 B > A: S 1001927984:1001927984(0)
     ack 1748427201 win 16384 <mss 65240>
20:12:11.955230 A > B: . ack 1 win 49152 (DF)
20:12:11.959099 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:13.139074 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:16.188685 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:22.290483 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:34.491856 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:58.896405 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:13:47.703184 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:14:52.780640 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:15:57.856037 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:17:02.932431 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:18:08.009337 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:19:13.090521 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:20:18.168066 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:21:23.242761 A > B: R 1461:1461(0) ack 1 win 49152 (DF)

The short SYN packet has no trouble crossing the network, because it's tiny. ICMP echo packets used to check connectivity will succeed too. 🏃‍♀️

Large data packets fail to cross the network, and eventually the connection times out. This is especially confusing when the application starts with a very small write, which succeeds, and then sends a bunch of large writes, which all fail. 😵‍💫

Trace file demonstrating correct behavior

Made using tcpdump recording at an intermediate host. ✅

16:48:42.659115 A > B: S 271394446:271394446(0)
     win 8192 <mss 1460> (DF)
16:48:42.672279 B > A: S 2837734676:2837734676(0)
     ack 271394447 win 16384 <mss 65240>

16:48:42.676890 A > B: . ack 1 win 8760 (DF)
16:48:42.870574 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
16:48:42.871799 A > B: . 1461:2921(1460) ack 1 win 8760 (DF)
16:48:45.786814 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
16:48:51.794676 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
16:49:03.808912 A > B: . 1:537(536) ack 1 win 8760
16:49:04.016476 B > A: . ack 537 win 16384
16:49:04.021245 A > B: . 537:1073(536) ack 1 win 8760
16:49:04.021697 A > B: . 1073:1609(536) ack 1 win 8760
16:49:04.120694 B > A: . ack 1609 win 16384
16:49:04.126142 A > B: . 1609:2145(536) ack 1 win 8760

In this one, the sender watches four packets fail to cross the network (with a two-packet initial send window) and turns PMTUD off. Every packet after that has the DF flag off, and the size is set to the default of 536 [RFC1122]. the sender basically gives up on the big stuff and goes small 🥹

References

This problem has been discussed a lot on the tcp-impl mailing list. The name "black hole" has been around for years. 💬

How to detect

This shows up as a TCP connection that hangs (it stops making progress) until a timeout closes it. Often it looks like the connection connects and starts transferring, then ends after 15 minutes with zero bytes transferred. It's especially annoying with an application like ftp, which works perfectly while it uses small packets for control info, then fails on bulk transfers. 😩

A series of ICMP echo packets will show that the two end hosts can still pass packets. A series of MTU-sized ICMP echo packets will show some fragmentation, and a series of MTU-sized ICMP echo packets with DF set will fail. this is so confusing for network engineers trying to diagnose it, I feel for them 🫠

There are several traceroute implementations that do PMTUD and can demonstrate the problem. 🗺️

How to fix

TCP should notice that the connection is timing out. After several timeouts, TCP should try sending smaller packets, maybe with the DF flag turned off for each packet. If that works, it should keep PMTUD turned off for the connection for some reasonable period of time, and after that it should probe again to see if the path has changed. 🔧

Note that under IPv6 there is no DF bit. It's implicitly on at all times. Fragmentation isn't allowed in routers, only at the originating host. Luckily, the minimum supported MTU for IPv6 is 1280 octets, which is much bigger than the 68 octet minimum in IPv4. That makes it more reasonable for IPv6 TCP implementations to fall back to 1280 octet packets, while IPv4 implementations will probably have to turn off DF to respond to black hole detection. the IPv6 folks really get the easier route here ✨

Ideally, ICMP black holes should be fixed when they're found. 🧹

If hosts start implementing black hole detection, these problems might go unnoticed and unfixed. That's especially sad, because detection can take several seconds each time, and those delays could add up to a significant, hidden drop in performance. Hosts that implement black hole detection should probably log the black holes they detect, so they can get fixed. 📋💖

2.2. Stretch ACK due to PMTUD ✨

Name of Problem

Stretch ACK due to PMTUD 🦋

Classification

Congestion Control / Performance 💅

Description

okay so, when a naively implemented TCP stack talks to a PMTUD equipped stack, it tries to send an ACK for every second full-sized segment 🙈. If it works out what "full-sized" means from the advertised MSS, things can go really wrong with PMTUD 💀.

The PMTU can end up being a small fraction of the advertised MSS. When that happens, an ACK only gets generated super rarely 😭.

Significance

Stretch ACKs have a bunch of unfortunate effects, which [RFC2525] covers in more detail. Most of them come from the infrequent arrival of ACKs, which pushes the connection toward being more bursty 🌪️. They can also slow down congestion window growth 🐢.

Implications

The full implications of stretch ACKs are outlined in [RFC2525] 📚.

Relevant RFCs

RFC 1122 lays out the requirements for how often ACKs get generated ⏰. [RFC2581] builds on that and makes it clear that delayed ACK is a SHOULD, not a MUST 🫶.

Trace file demonstrating it

Made using tcpdump recording at an intermediate host. The timestamp options from all but the first two packets have been removed for clarity 🧚.

18:16:52.976657 A > B: S 3183102292:3183102292(0) win 16384
     <mss 4312,nop,wscale 0,nop,nop,timestamp 12128 0> (DF)
18:16:52.979580 B > A: S 2022212745:2022212745(0) ack 3183102293 win
     49152 <mss 4312,nop,wscale 1,nop,nop,timestamp 1592957 12128> (DF)
18:16:52.979738 A > B: . ack 1 win 17248  (DF)
18:16:52.982473 A > B: . 1:4301(4300) ack 1 win 17248  (DF)
18:16:52.982557 C > A: icmp: B unreachable -
     need to frag (mtu 1500)! (DF)
18:16:52.985839 B > A: . ack 1 win 32768  (DF)
18:16:54.129928 A > B: . 1:1449(1448) ack 1 win 17248  (DF)
     .
     .
     .
18:16:58.507078 A > B: . 1463941:1465389(1448) ack 1 win 17248  (DF)
18:16:58.507200 A > B: . 1465389:1466837(1448) ack 1 win 17248  (DF)
18:16:58.507326 A > B: . 1466837:1468285(1448) ack 1 win 17248  (DF)
18:16:58.507439 A > B: . 1468285:1469733(1448) ack 1 win 17248  (DF)
18:16:58.524763 B > A: . ack 1452357 win 32768  (DF)
18:16:58.524986 B > A: . ack 1461045 win 32768  (DF)
18:16:58.525138 A > B: . 1469733:1471181(1448) ack 1 win 17248  (DF)
18:16:58.525268 A > B: . 1471181:1472629(1448) ack 1 win 17248  (DF)
18:16:58.525393 A > B: . 1472629:1474077(1448) ack 1 win 17248  (DF)
18:16:58.525516 A > B: . 1474077:1475525(1448) ack 1 win 17248  (DF)
18:16:58.525642 A > B: . 1475525:1476973(1448) ack 1 win 17248  (DF)
18:16:58.525766 A > B: . 1476973:1478421(1448) ack 1 win 17248  (DF)
18:16:58.526063 A > B: . 1478421:1479869(1448) ack 1 win 17248  (DF)
18:16:58.526187 A > B: . 1479869:1481317(1448) ack 1 win 17248  (DF)
18:16:58.526310 A > B: . 1481317:1482765(1448) ack 1 win 17248  (DF)
18:16:58.526432 A > B: . 1482765:1484213(1448) ack 1 win 17248  (DF)
18:16:58.526561 A > B: . 1484213:1485661(1448) ack 1 win 17248  (DF)
18:16:58.526671 A > B: . 1485661:1487109(1448) ack 1 win 17248  (DF)
18:16:58.537944 B > A: . ack 1478421 win 32768  (DF)
18:16:58.538328 A > B: . 1487109:1488557(1448) ack 1 win 17248  (DF)

Look at that gap between ACKs 🤯. It's way bigger than two times the segment size. It works out to be almost exactly two times the advertised MSS 😱. The transfer ran long enough to confirm the stretch ACK wasn't just the result of lost ACK packets 🕵️‍♀️.

Trace file demonstrating correct behavior

Made using tcpdump recording at an intermediate host. The timestamp options from all but the first two packets have been removed for clarity 💖.

18:13:32.287965 A > B: S 2972697496:2972697496(0)
     win 16384 <mss 4312,nop,wscale 0,nop,nop,timestamp 11326 0> (DF)
18:13:32.290785 B > A: S 245639054:245639054(0)
     ack 2972697497 win 34496 <mss 4312> (DF)
18:13:32.290941 A > B: . ack 1 win 17248 (DF)
18:13:32.293774 A > B: . 1:4313(4312) ack 1 win 17248 (DF)
18:13:32.293856 C > A: icmp: B unreachable -
     need to frag (mtu 1500)! (DF)
18:13:33.637338 A > B: . 1:1461(1460) ack 1 win 17248 (DF)
     .
     .
     .
18:13:35.561691 A > B: . 1514021:1515481(1460) ack 1 win 17248 (DF)
18:13:35.561814 A > B: . 1515481:1516941(1460) ack 1 win 17248 (DF)
18:13:35.561938 A > B: . 1516941:1518401(1460) ack 1 win 17248 (DF)
18:13:35.562059 A > B: . 1518401:1519861(1460) ack 1 win 17248 (DF)
18:13:35.562174 A > B: . 1519861:1521321(1460) ack 1 win 17248 (DF)
18:13:35.564008 B > A: . ack 1481901 win 64680 (DF)
18:13:35.564383 A > B: . 1521321:1522781(1460) ack 1 win 17248 (DF)
18:13:35.564499 A > B: . 1522781:1524241(1460) ack 1 win 17248 (DF)
18:13:35.615576 B > A: . ack 1484821 win 64680 (DF)
18:13:35.615646 B > A: . ack 1487741 win 64680 (DF)
18:13:35.615716 B > A: . ack 1490661 win 64680 (DF)
18:13:35.615784 B > A: . ack 1493581 win 64680 (DF)
18:13:35.615856 B > A: . ack 1496501 win 64680 (DF)
18:13:35.615952 A > B: . 1524241:1525701(1460) ack 1 win 17248 (DF)
18:13:35.615966 B > A: . ack 1499421 win 64680 (DF)
18:13:35.616088 A > B: . 1525701:1527161(1460) ack 1 win 17248 (DF)
18:13:35.616105 B > A: . ack 1502341 win 64680 (DF)
18:13:35.616211 A > B: . 1527161:1528621(1460) ack 1 win 17248 (DF)
18:13:35.616228 B > A: . ack 1505261 win 64680 (DF)
18:13:35.616327 A > B: . 1528621:1530081(1460) ack 1 win 17248 (DF)
18:13:35.616349 B > A: . ack 1508181 win 64680 (DF)
18:13:35.616448 A > B: . 1530081:1531541(1460) ack 1 win 17248 (DF)
18:13:35.616565 A > B: . 1531541:1533001(1460) ack 1 win 17248 (DF)
18:13:35.616891 A > B: . 1533001:1534461(1460) ack 1 win 17248 (DF)

In this trace, an ACK gets generated for every two segments that arrive 🎉. The segment size is a bit bigger here, even though it's the same source hosts. That's because this trace has no timestamp options 🌸.

How to detect

You can spot this condition in a packet trace when the advertised MSS is significantly larger than the actual PMTU of a connection 🔍.

How to fix

Several solutions for this problem have been proposed 💡.

A simple solution is to ACK every other packet, regardless of size 🍓. The catch is that this can generate tons of ACKs when there are lots of very small packets 😵. You see this with applications like the X Window System 🪟.

A slightly more complex solution would monitor the size of incoming segments and try to figure out what segment size the sender is using 🧐. This needs a bit more state in the receiver, but it makes receiver silly window syndrome avoidance computations more accurate [RFC813] ✨.

2.3. Determining MSS from PMTU ✨

Classification: Performance 📈

Description

okay so the MSS you advertise at the start of a connection is supposed to come from the MTUs of your system's interfaces 🎀 (for efficiency and other reasons it might not be the biggest MSS possible). but some systems use PMTUD-determined values to pick the MSS they advertise 🙈

and that means the advertised MSS ends up smaller than the largest MTU the system can actually receive 💅

Significance

the advertised MSS is basically how you tell the other side "hey, this is the biggest TCP segment I can take" [RFC879] 🫶. if that number is too small, the remote system has to use smaller segments when it sends to you, and the only reason is that your system found a smaller PMTU earlier 😭

now, the asymmetric routes on the Internet are a whole thing [Paxson97] 🌈, so it's totally possible the return PMTU is different from the sending PMTU. limiting your segment size like this can hurt performance and mess with the PMTUD algorithm 💀

and even if the route was symmetric, a limit this artificially low makes it impossible to probe later and find out if the PMTU has changed 🙅‍♀️

Implications

the entire point of PMTUD is to send the biggest segment possible 👑. if long-running connections can't probe for a larger PMTU, the performance gains just never happen 😤. this literally destroys the whole point of PMTUD 💔

Relevant RFCs RFC 1191. [RFC879] has a complete discussion of MSS calculations and appropriate values 📚. note that this practice doesn't violate any of the specifications in these RFCs ✅.

Trace file demonstrating it

this trace was made with tcpdump running on an intermediate host 🔍. host A opens two separate consecutive connections, A1 and A2, to host B 🧚. router C is where the MTU bottleneck lives. as usual, TCP options are removed from all non-SYN packets 🙈

22:33:32.305912 A1 > B: S 1523306220:1523306220(0)
     win 8760 <mss 1460> (DF)
22:33:32.306518 B > A1: S 729966260:729966260(0)
     ack 1523306221 win 16384 <mss 65240>
22:33:32.310307 A1 > B: . ack 1 win 8760 (DF)
22:33:32.323496 A1 > B: P 1:1461(1460) ack 1 win 8760 (DF)
22:33:32.323569 C > A1: icmp: 129.99.238.5 unreachable -
     need to frag (mtu 1024) (DF) (ttl 255, id 20666)
22:33:32.783694 A1 > B: . 1:985(984) ack 1 win 8856 (DF)
22:33:32.840817 B > A1: . ack 985 win 16384
22:33:32.845651 A1 > B: . 1461:2445(984) ack 1 win 8856 (DF)
22:33:32.846094 B > A1: . ack 985 win 16384
22:33:33.724392 A1 > B: . 985:1969(984) ack 1 win 8856 (DF)
22:33:33.724893 B > A1: . ack 2445 win 14924
22:33:33.728591 A1 > B: . 2445:2921(476) ack 1 win 8856 (DF)
22:33:33.729161 A1 > B: . ack 1 win 8856 (DF)
22:33:33.840758 B > A1: . ack 2921 win 16384

[...]

22:33:34.238659 A1 > B: F 7301:8193(892) ack 1 win 8856 (DF)
22:33:34.239036 B > A1: . ack 8194 win 15492
22:33:34.239303 B > A1: F 1:1(0) ack 8194 win 16384
22:33:34.242971 A1 > B: . ack 2 win 8856 (DF)
22:33:34.454218 A2 > B: S 1523591299:1523591299(0)
     win 8856 <mss 984> (DF)
22:33:34.454617 B > A2: S 732408874:732408874(0)
     ack 1523591300 win 16384 <mss 65240>
22:33:34.457516 A2 > B: . ack 1 win 8856 (DF)
22:33:34.470683 A2 > B: P 1:985(984) ack 1 win 8856 (DF)
22:33:34.471144 B > A2: . ack 985 win 16384
22:33:34.476554 A2 > B: . 985:1969(984) ack 1 win 8856 (DF)
22:33:34.477580 A2 > B: P 1969:2953(984) ack 1 win 8856 (DF)

[...]

notice the SYN packet for session A2 advertises an MSS of 984 👀 that's the bug!! 🐛

Trace file demonstrating correct behavior

same setup as before 🧸: tcpdump on an intermediate host, host A opening two separate consecutive connections, A1 and A2, to host B, and router C as the MTU bottleneck. TCP options are removed from all non-SYN packets, as usual ✨

22:36:58.828602 A1 > B: S 3402991286:3402991286(0) win 32768
     <mss 4312,wscale 0,nop,timestamp 1123370309 0,
      echo 1123370309> (DF)
22:36:58.844040 B > A1: S 946999880:946999880(0)
     ack 3402991287 win 16384
     <mss 65240,nop,wscale 0,nop,nop,timestamp 429552 1123370309>
22:36:58.848058 A1 > B: . ack 1 win 32768  (DF)
22:36:58.851514 A1 > B: P 1:1025(1024) ack 1 win 32768  (DF)
22:36:58.851584 C > A1: icmp: 129.99.238.5 unreachable -
     need to frag (mtu 1024) (DF)
22:36:58.855885 A1 > B: . 1:969(968) ack 1 win 32768  (DF)
22:36:58.856378 A1 > B: . 969:985(16) ack 1 win 32768  (DF)
22:36:59.036309 B > A1: . ack 985 win 16384
22:36:59.039255 A1 > B: FP 985:1025(40) ack 1 win 32768  (DF)
22:36:59.039623 B > A1: . ack 1026 win 16344
22:36:59.039828 B > A1: F 1:1(0) ack 1026 win 16384
22:36:59.043037 A1 > B: . ack 2 win 32768  (DF)
22:37:01.436032 A2 > B: S 3404812097:3404812097(0) win 32768
     <mss 4312,wscale 0,nop,timestamp 1123372916 0,
      echo 1123372916> (DF)
22:37:01.436424 B > A2: S 949814769:949814769(0)
     ack 3404812098 win 16384
     <mss 65240,nop,wscale 0,nop,nop,timestamp 429562 1123372916>
22:37:01.440147 A2 > B: . ack 1 win 32768  (DF)
22:37:01.442736 A2 > B: . 1:969(968) ack 1 win 32768  (DF)
22:37:01.442894 A2 > B: P 969:985(16) ack 1 win 32768  (DF)
22:37:01.443283 B > A2: . ack 985 win 16384
22:37:01.446068 A2 > B: P 985:1025(40) ack 1 win 32768  (DF)
22:37:01.446519 B > A2: . ack 1025 win 16384
22:37:01.448465 A2 > B: F 1025:1025(0) ack 1 win 32768  (DF)
22:37:01.448837 B > A2: . ack 1026 win 16384
22:37:01.449007 B > A2: F 1:1(0) ack 1026 win 16384
22:37:01.452201 A2 > B: . ack 2 win 32768  (DF)

and look at that, the same MSS got used for both session A1 and session A2 🎉 slay ✨

How to detect

you can detect this with a packet trace of two separate connections 🔎. the first one should invoke PMTUD, and the second one should start soon enough after the first that the PMTU value hasn't timed out yet ⏰.

How to fix

the MSS should be determined from the MTUs of the interfaces on the system, as outlined in [RFC1122] and [RFC1191] 🩷.

3. Security Considerations ✨

okay, serious moment 🚨. the one security concern this memo raises is that ICMP black holes are often caused by overzealous security administrators who block all ICMP messages 🙅‍♀️. it is vitally important that anyone designing and deploying security systems understands the impact of strict filtering on upper-layer protocols 😱. the safest website in the world is worthless if most TCP implementations can't transfer data from it 💀. it would be way nicer to fix all of the black holes than to fix all of the TCP implementations 🫠.

4. Acknowledgements 🫶

big thank-yous to Mark Allman, Vern Paxson, and Jamshid Mahdavi for generously helping review the document 💖, and to Matt Mathis for early suggestions about the mechanisms that can cause PMTUD black holes, plus review 🌸. the structure for describing TCP problems, and the early description of that structure, comes from [RFC2525] 📚. and special love to Amy Bock, who helped perform the PMTUD tests that discovered these bugs 👑🎀.

5. References

  • [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
  • [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
  • [RFC813] Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
  • [Jacobson89] V. Jacobson, C. Leres, and S. McCanne, tcpdump, June 1989, ftp.ee.lbl.gov
  • [RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
  • [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
  • [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
  • [Paxson96] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking (5), pp.~601-615, Oct. 1997.
  • [RFC2525] Paxon, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, I. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
  • [RFC879] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, November 1983.
  • [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.

6. Author's Address 📬

Kevin Lahey dotRocket, Inc. 1901 S. Bascom Ave., Suite 300 Campbell, CA 95008 USA

Phone: +1 408-371-8977 x115 email: kml@dotrocket.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society 🌈✨

📦 where this page comes from