Кратко

  • RFC 1191 предписал IPv4 source устанавливать Don't Fragment, а ограничивающему router — возвращать next-hop MTU в ICMP. Путь наблюдал ограничение; endpoint хранил оценку и выбирал меньший размер.
  • RFC 2923 описал PMTUD black hole: без ICMP TCP handshake и малые пакеты могли работать, но крупные segment исчезали. MSS не измерял весь путь.
  • В случае Cloudflare 2015 года TCP и ICMP распределялись ECMP по разным данным. Контрольное сообщение попало в сеть оператора, но не на backend с состоянием соединения.
  • PLPMTUD и DPLPMTUD позволили endpoint искать размер probes и подтверждением доставки. Независимость от ICMP потребовала трафика, состояния и осторожного различения MTU-ограничения и иных потерь.

Сообщение было доставлено, но лишилось контекста

Cloudflare расширила внутреннее применение Equal-Cost Multi-Path routing. Для TCP маршрутизатор вычислял hash из адресов и портов source и destination. Поэтому пакеты одного соединения возвращались на один сервер.

Для ICMP, согласно отчету компании, использовались только адреса source и destination. Packet Too Big мог оказаться на другом backend, хотя TCP flow продолжал идти правильно. Cloudflare прямо указала, что именно это произошло в ее случае.

Публикация говорит лишь о нескольких пользователях IPv6 tunnels. Она не дает мировой частоты и не доказывает ущерб или вину третьих лиц. Она устанавливает более узкий факт: control evidence может попасть в нужную организацию, но разминуться с состоянием, которое позволяет действовать.

Временно Cloudflare снизила IPv6 MTU до 1280 и включила probing RFC 4821 для IPv4. Затем появился daemon, который перехватывал IPv4 fragmentation-needed и IPv6 Packet Too Big и передавал их Ethernet broadcast всем backend.

Repository задавал по умолчанию один пакет в секунду от одного source и десять пакетов в секунду на interface. Общее распространение доказательства решало вопрос ownership state, но создавало новую поверхность проверки, нагрузки и abuse. Это решение конкретной архитектуры, а не универсальный стандарт.

Консервативный размер тоже распределял издержки

RFC 1191 в 1990 году определил Path MTU как минимальный MTU среди hops от source до destination. Значение относится к оцененному пути. Изменение route или добавление tunnel может изменить минимум при тех же адресах.

До этого host мог брать меньшее из 576 octets и MTU первого hop. Такой подход не предполагал большую способность неизвестного пути. На широких маршрутах он посылал излишне малые packets, а меньший последующий link все равно мог вызвать IPv4 fragmentation.

При fragmentation адаптация происходила внутри сети. Router делил datagram, destination собирал fragments; потеря одной части могла испортить весь datagram. RFC 8900 позднее добавил к уязвимостям stateful middleboxes, filters, tunnels и неодинаковые пути.

Исторический выбор был не между совершенством и ошибкой. Можно было всегда отправлять мало, позволять routers fragment, получать явное сообщение пути или совмещать методы. RFC 1191 выбрал feedback, чтобы приблизиться к реальной емкости без постоянной router fragmentation.

Router сообщал локальный факт, endpoint выбирал реакцию

В классическом IPv4 PMTUD source ставит Don't Fragment. Если router не может передать datagram через следующий link без fragmentation, он отбрасывает его и возвращает ICMP Destination Unreachable с code fragmentation needed.

RFC 1191 требует вложить next-hop MTU. Host уменьшает оценку. Он может посылать меньшие packets или перестать ставить DF; router не получает права выбирать transport policy.

Так возникла зависимость. Router непосредственно знает одну interface. Endpoint контролирует packetization. Ни один не управляет control surface другого, поэтому ICMP соединяет evidence и corrective power.

Увеличение размера нельзя было принять из ICMP. Endpoint должен позднее сам probe. RFC 1191 рекомендовал ждать после снижения не менее пяти минут, предпочтительно десять, прежде чем пробовать больше.

Это исторические рекомендации, не измерение всех современных stacks. Они выражают границу доказательства: routes меняются, messages бывают ложными или устаревшими, и локальное наблюдение не становится бессрочным разрешением.

IPv6 убрал fragmentation из routers, но не необходимость узнавать предел

Нынешняя базовая спецификация IPv6 требует, чтобы каждый link переносил 1280 octets либо предоставлял fragmentation и reassembly ниже IP. IPv6 routers не fragment packets в пути. Fragment header добавляет только source.

RFC 8200 настоятельно рекомендует PMTUD для размеров выше 1280. Минимальная implementation может ограничиться 1280. Это законный выход из полной discovery ценой эффективности на более широких путях, а не доказательство MTU=1280 повсюду.

По RFC 8201 ограничивающий router отправляет ICMPv6 Packet Too Big. Endpoint должен проверить, что процитированный packet относится к его traffic. Valid message снижает оценку, но не ниже IPv6 minimum 1280.

PTB не может повышать значение. После снижения source может probe вверх не чаще одного раза в пять минут, предпочтительно раз в десять. Router сообщает constraint; endpoint проверяет context и решает, сколько хранить.

RFC 4890 относит Packet Too Big к ICMPv6 traffic, который firewall не должен отбрасывать, поскольку коммуникация может быть предотвращена или серьезно нарушена. Это точная operational recommendation, не свидетельство повсеместного соблюдения и не требование пропускать весь ICMP без проверки.

Black hole скрывал объяснение, а не сам предел

RFC 2923 в 2000 году описал давно известную проблему. Router, kernel fault, configuration или firewall мешал ICMP error вернуться. Source продолжал отправлять размер, который path отбрасывал.

TCP создавал обманчивую частичную работоспособность. Малый handshake проходил. Первые данные могли пройти. Большой segment исчезал, а retransmissions повторяли размер. В примере FTP control connection работал, а bulk transfer останавливался.

Это повод расследовать, не готовый verdict. Congestion, corruption и asymmetric policy могут дать похожую потерю. Нужны размер, IP family, DF/Fragment, retransmissions и содержимое процитированного ICMP.

TCP MSS не заменяет PMTU. Это предел TCP payload, который готов принять receiver. Он не видит все tunnels прямого пути и не доказывает, что обратный путь совпадает.

RFC 2923 предпочитал исправить ICMP black hole. Локальное обнаружение могло уменьшить packet после timeouts. Оно восстанавливало некоторые sessions, но добавляло секунды и скрывало path defect, который оставался для других flows.

Легитимный filter не становится мерой end-to-end пути

Оператор может легитимно определять firewall policy своей сети. Источники не позволяют приписывать конкретному actor незаконность, злой умысел или частный мотив.

Проверяемая граница проще. Drop Packet Too Big не делает исходный packet передаваемым. Он убирает evidence и сохраняет constraint. Filter получает практическое veto над adaptation, не приобретая знания router или ответственности endpoint.

Tunnels добавляют headers после выбора размера. ECMP и anycast могут разделять instance данных и instance ошибки. MTU без времени, направления, flow и encapsulation не является постоянным свойством address block.

Для number-resource holder это важно. RIR распределяет addresses, но не сертифицирует end-to-end MTU каждой route. ASN, prefix и service IP могут не измениться, а крупные packets перестанут проходить после operational change.

PLPMTUD превратил отсутствие сообщения в поиск

RFC 4821 в 2007 году определил Packetization Layer PMTUD. Формирующий packets layer отправляет probes возрастающего размера и учится по delivery или loss. Он может действовать, даже когда ICMP не приходит.

Endpoint получает выход, но не certainty. Изолированная потеря большой probe может указывать на limit. Если рядом теряются другие packets, congestion или другая причина делает вывод неопределенным. Требуются search state, timers и повторные проверки.

Charter IETF PMTUD Working Group называла слабости прежнего метода хроническим препятствием для новых links и tunnels. Направление работы — начать с малого и probe вверх без зависимости от ICMP. Charter доказывает institutional scope, не universal consensus или deployment.

RFC 8899 распространил принцип на Datagram Packetization Layers. DPLPMTUD тестирует size, повышает confirmed value после delivery confirmation и снижает при black hole. Validated PTB может помочь, но не быть единственным источником и не использоваться для повышения.

UDP сам не дает acknowledgement. Application или packetization layer должны подтвердить probe. Вместе с power к endpoint переходят traffic, state и обязанность истолковать loss.

Современный исход — сосуществование, а не замена

Текущая TCP specification настоятельно рекомендует PMTUD и рекомендует PLPMTUD. Малые fallback sizes сохраняются, а RFC 9293 предупреждает о performance cost. Probing дополнил router signal, а не отменил его.

Нынешняя Linux documentation предлагает выбор. tcp_mtu_probing=0 отключает probing; mode 1 включает его после обнаружения ICMP black hole; mode 2 держит включенным от base MSS. Документированный interval по умолчанию равен десяти минутам.

Это product controls, не мировая статистика. Firewalls, tunnels, kernels, transports и applications разных поколений образуют installed base и механизм lock-in.

RFC 8900 поэтому не объявил fragmentation отмененной. Он перечислил fragility и рекомендовал upper layers снизить зависимость. Осталась комбинация explicit signal, validation, endpoint probing и conservative fallback.