Перейти к содержанию

Path MTU Discovery (обнаружение MTU пути)

Между вашим устройством и сервером может лежать туннель, у которого MTU меньше, чем у локального Ethernet. В IPv6 маршрутизаторы пакеты не режут: слишком большой пакет отбрасывается, а отправителю прилетает Packet Too Big. Процедура, которая из таких сообщений выводит безопасный размер пакета, и есть Path MTU Discovery.

Обновлено Редакция GAW

Содержание

Path MTU Discovery (PMTUD, обнаружение MTU пути) — процедура RFC 8201, по которой узел IPv6 узнаёт наибольший размер пакета, который пройдёт весь путь до адресата без фрагментации. Path MTU равен минимуму из MTU всех каналов на пути (разд. 1). В IPv6 маршрутизаторы не фрагментируют пакеты: слишком большой пакет отбрасывается, а источник получает ICMPv6 Packet Too Big с MTU узкого канала — на этом и построено обнаружение.

Как работает

  1. Источник считает PMTU равным MTU своего первого канала и шлёт пакеты такого размера (разд. 3).
  2. Маршрутизатор, у которого исходящий канал уже, отбрасывает пакет и обязан отправить Packet Too Big — ICMPv6 тип 2, код 0, в поле MTU — MTU следующего канала (RFC 4443 разд. 3.2).
  3. Источник уменьшает оценку PMTU до этого значения и уменьшает пакеты; циклов может быть несколько, если дальше есть ещё более узкий канал (разд. 3, 4).
  4. Рост PMTU обнаруживают редкими пробами большим пакетом: не раньше чем через 5 мин после последнего PTB, рекомендуется 10 мин; кешированное значение стареет примерно за 10 мин, а таймаут должен настраиваться вплоть до бесконечности (разд. 4, 5.3).
Правило RFC 8201Значение
Нижняя граница оценки PMTU1280 — минимальный MTU IPv6, PTB с меньшим MTU отбрасывается (разд. 4)
Увеличение оценки по PTBзапрещено — такой PTB может быть устаревшим или подделкой (разд. 4)
Проба увеличенияне чаще раза в 5 мин, рекомендуется 10 мин (разд. 4)
Multicast-адресатминимум PMTU по всем путям (разд. 3)
Сосед на том же каналеPMTUD выполняется всё равно: сосед может оказаться за прокси ND (разд. 3)

Минимум 1280 и 6LoWPAN

RFC 8200 (разд. 5) требует от любого канала MTU не меньше 1280 октетов; канал, не способный на это, обязан фрагментировать и собирать ниже уровня IPv6. Так устроен 6LoWPAN: радиокадр 127 байт, но для IPv6 канал выглядит как MTU 1280. Отсюда простой выход для прошивки, которой PMTUD не по силам: никогда не слать пакеты больше 1280, и RFC 8200 прямо допускает это для минимальных реализаций. Фрагментацию у источника заголовком Fragment стандарт не рекомендует там, где приложение может подстроить размер, а собирать узел обязан пакеты до 1500 октетов.

Чёрная дыра и альтернативы

Если на пути межсетевой экран отбрасывает ICMPv6, Packet Too Big не доходит: тройное рукопожатие TCP маленькими сегментами проходит, а передача данных зависает — RFC 8201 (разд. 1) называет это black-hole connection. Для таких путей есть PLPMTUD (RFC 4821): размер подбирается пробами самого транспорта, без ICMP. Для TCP важно и другое: MSS, полученная от партнёра, ограничивает сегменты независимо от PMTU, а своя MSS в опции говорит о пределе сборки, не о пути (разд. 5.4). Для UDP Zephyr реализует DPLPMTUD (RFC 8899), сам PMTUD по RFC 8201 там есть для IPv6 и по RFC 1191 для IPv4. Сообщения об ошибках, включая PTB и Time Exceeded из термина Hop Limit, и ICMP Echo — всё один протокол ICMPv6, на который завязано и Neighbor Discovery. MTU проводного интерфейса микроконтроллера обсуждается в статье «Ethernet для микроконтроллеров».

Частые вопросы

Почему минимальный MTU IPv6 равен 1280 байт и что это даёт?

RFC 8200 (разд. 5) обязывает каждый канал передавать пакет 1280 октетов целиком; канал вроде IEEE 802.15.4 с кадром 127 байт обязан фрагментировать ниже IPv6 — это делает 6LoWPAN. Поэтому узел, который не хочет заниматься PMTUD, может просто никогда не слать пакеты больше 1280 и быть уверенным, что они дойдут. RFC 8201 (разд. 4) запрещает опускать оценку PMTU ниже 1280 и предписывает отбрасывать Packet Too Big с меньшим MTU.

Что такое Packet Too Big?

Сообщение ICMPv6 типа 2 с кодом 0 и полем MTU следующего канала (RFC 4443 разд. 3.2). Маршрутизатор обязан отправить его источнику, если пакет больше MTU исходящего канала; в отличие от других ошибок ICMPv6, оно отправляется и на пакеты с групповым адресом назначения. Источник, получив его, уменьшает оценку PMTU до указанного значения и уменьшает пакеты (RFC 8201 разд. 3, 4); увеличивать оценку по содержимому PTB нельзя.

Соединение TCP устанавливается, но данные не идут — при чём тут PMTUD?

Это «чёрная дыра» из RFC 8201 (разд. 1): межсетевой экран на пути режет ICMPv6, тройное рукопожатие с маленькими сегментами проходит, а большие сегменты данных отбрасываются на узком канале, и Packet Too Big до отправителя не доходит. Выходы — не слать пакеты больше 1280 или использовать PLPMTUD (RFC 4821), который подбирает размер пробами без ICMP; в Zephyr для UDP есть DPLPMTUD (RFC 8899).

Источники

  1. IETF. J. McCann, S. Deering, J. Mogul, R. Hinden (ed.). Path MTU Discovery for IP version 6. RFC 8201, July 2017 — разд. 1: PMTU — минимум из MTU всех каналов пути; узлы IPv6 должны реализовывать PMTUD, минимальная реализация (например, загрузочное ПЗУ) может её опустить и слать пакеты не больше минимального MTU; при блокировке ICMPv6 возникает «чёрная дыра» — тройное рукопожатие TCP проходит, а передача данных зависает (RFC 2923); для таких путей — PLPMTUD, RFC 4821; разд. 3: источник сначала считает PMTU равным MTU первого перехода; узел, не способный переслать пакет, отбрасывает его и возвращает Packet Too Big; источник уменьшает оценку по полю MTU, циклов может быть несколько; обнаружение роста PMTU — редкими пробами; для multicast берётся минимум по всем путям; PMTUD выполняется и для адресатов, которые кажутся соседями; разд. 4: PTB с MTU меньше минимального MTU IPv6 отбрасывается, оценка ниже минимума не опускается; после PTB узел обязан уменьшить пакеты; проба увеличения — не раньше 5 мин после PTB, рекомендуется 10 мин; по содержимому PTB оценку не увеличивают; разд. 5.3: кешированные значения стареют около 10 мин, таймаут должен настраиваться вплоть до бесконечности; разд. 5.4: TCP хранит MSS партнёра и не шлёт сегменты больше неё независимо от PMTU; значение в опции MSS от PMTU не зависит и определяется пределом сборки приёмника
  2. IETF. S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 8200, July 2017 — разд. 5: каждый канал обязан иметь MTU не меньше 1280 октетов — минимальный MTU IPv6; канал, не способный передать 1280 целиком, фрагментирует ниже уровня IPv6; настраиваемые каналы (PPP) — не меньше 1280, рекомендуется 1500 и больше под туннели; узлам настоятельно рекомендуется PMTUD, минимальная реализация может слать не больше 1280; фрагментация — только заголовком Fragment у источника, и её не рекомендуют там, где можно подстроить размер; узел обязан собирать фрагментированный пакет до 1500 октетов
  3. IETF. A. Conta, S. Deering, M. Gupta. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 4443, March 2006 — разд. 3.2: Packet Too Big — тип 2, код 0, поле MTU — MTU следующего канала; маршрутизатор обязан отправить его, если пакет больше MTU исходящего канала; в отличие от других ошибок, отправляется и в ответ на пакет с multicast-адресом назначения
  4. Zephyr Project. Zephyr Project Documentation (latest): Networking — Overview — Supported Features: фрагментация и Path MTU Discovery (RFC 8201) для IPv6, RFC 1191 для IPv4; DPLPMTUD (RFC 8899) для протоколов поверх UDP и для UDP-сокетов через UDP options (RFC 9868, RFC 9869)
Страница помогла?

Нашли ошибку? ·

Смотрите также