Обнаружение MTU пути ( PMTUD ) - это стандартизированный метод в компьютерных сетях для определения максимального размера единицы передачи (MTU) на сетевом пути между двумя хостами Интернет-протокола (IP), обычно с целью предотвращения фрагментации IP . PMTUD изначально предназначался для маршрутизаторов с протоколом Интернета версии 4 (IPv4). [1] Однако все современные операционные системы используют его на конечных точках. В IPv6 эта функция явно делегирована конечным точкам сеанса связи. [2]
PMTUD стандартизирован для IPv4 в RFC 1191 и для IPv6 в RFC 8201 (который устарел RFC 1981, предыдущий стандарт IPv6 PMTUD). [3] RFC 4821 [4] описывает расширение методов, которое работает без поддержки Internet Control Message Protocol . RFC 8899 [5] обновляет RFC 4821, вводя рекомендации по использованию PMTUD уровня пакетирования с UDP и SCTP.
Реализация [ править ]
Для пакетов IPv4 обнаружение MTU пути работает путем установки бита флага « Не фрагментировать» (DF) в IP-заголовках исходящих пакетов. Затем любое устройство на пути, MTU которого меньше, чем размер пакета, отбросит его и отправит обратно сообщение Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4), содержащее его MTU, что позволяет хосту-источнику уменьшить его Правильный путь MTU. Процесс повторяется до тех пор, пока MTU не станет достаточно маленьким, чтобы пройти весь путь без фрагментации.
Маршрутизаторы IPv6 не поддерживают фрагментацию и, следовательно, не поддерживают параметр « Не фрагментировать» . Для IPv6 обнаружение MTU пути работает, изначально предполагая, что MTU пути совпадает с MTU на интерфейсе канального уровня, откуда исходит трафик. Затем, как и в случае с IPv4, любое устройство на пути, MTU которого меньше, чем пакет, отбрасывает пакет и отправляет обратно сообщение ICMPv6 Packet Too Big (Type 2), содержащее его MTU, позволяя хосту-источнику соответственно уменьшить свой MTU пути. Процесс повторяется до тех пор, пока MTU не станет достаточно маленьким, чтобы пройти весь путь без фрагментации. [6]
Если значение Path MTU изменяется после установки соединения и становится меньше, чем ранее определенное значение Path MTU, первый большой пакет вызовет ошибку ICMP и будет обнаружен новый, более низкий MTU пути. И наоборот, если PMTUD обнаруживает, что путь допускает больший MTU, чем возможно на нижнем канале, ОС будет периодически повторно проверять, изменился ли путь, и теперь допускает более крупные пакеты. И в Linux, и в Windows этот таймер по умолчанию установлен на десять минут. [7] [8]
Проблемы [ править ]
Многие так называемые устройства сетевой безопасности блокируют все сообщения ICMP для предполагаемых преимуществ безопасности [9], включая ошибки, которые необходимы для правильной работы PMTUD; обратите внимание, это несмотря на то, что в упомянутой статье конкретно описывается хороший протокол ICMP, подобный тому, который необходим для правильной работы PMTUD. Это может привести к соединениям, которые правильно завершают трехстороннее квитирование TCP , но затем зависают при передаче данных. Это состояние называется связью с черной дырой . [10]
Некоторые реализации PMTUD пытаются предотвратить эту проблему, делая вывод, что большие пакеты полезной нагрузки были отброшены из-за MTU, а не из-за перегрузки канала. Однако для наиболее эффективной работы протокола управления передачей (TCP ) следует разрешить сообщения ICMP о недоступности (тип 3). Надежный метод для PMTUD, который полагается на TCP или другой протокол для проверки пути с прогрессивно большими пакетами, был стандартизирован в RFC 4821.
Обходной путь, используемый некоторыми маршрутизаторами, заключается в изменении максимального размера сегмента (MSS) всех TCP-соединений, проходящих по каналам с MTU ниже, чем значение по умолчанию для Ethernet, равное 1500. Это известно как ограничение MSS . [11]
Ссылки [ править ]
- ↑ RFC 1191, Path MTU Discovery , J. Mogul, S. Deering (ноябрь 1990 г.)
- Перейти ↑ RFC 1981, Path MTU Discovery for IP version 6 , J. McCann, S. Deering, J. Mogul (август 1996 г.)
- ^ Могул, Джеффри; Хинден, Роберт (июль 2017 г.). «Обнаружение MTU пути для IP версии 6» . tools.ietf.org . ISSN 2070-1721 . Проверено 15 апреля 2019 года .
- ^ RFC 4821, Обнаружение MTU пути уровня пакетирования , М. Матис, Дж. Хеффнер (март 2007 г.)
- ^ RFC 8899, Обнаружение MTU пути уровня пакетирования для передачи дейтаграмм , Г. Фэрхерст, Т. Джонс, М. Тюксен, И. Рюнгелер, Т. Фёлькер (сентябрь 2020 г.)
- ^ Дэвис, Джозеф (2012). Понимание IPv6 (3-е изд.). Microsoft Press. С. 146–147. ISBN 9780735659148.
- ^ исходный код linux (ipv4) и исходный код linux (ipv6) см. строку с "mtu_expires" 10 * 60 секунд
- ^ Дэвис, Джозеф (2012). Понимание IPv6 (3-е изд.). Редмонд: Microsoft Press. п. 147. ISBN. 978-0735659148. OCLC 810455372 .
- ^ Майкл Маллинз (2003-10-21). «Предотвратить зондирование хакерами, заблокировав трафик ICMP» . Проверено 12 июля 2013 .
- ^ RFC 2923, Проблемы TCP с обнаружением MTU пути , К. Лахи (сентябрь 2000 г.)
- ^ «Обход проблемы обнаружения MTU пути с помощью ограничения MSS (для пользователей ADSL, кабеля, PPPoE и PPtP)» . lartc.org . Проверено 15 апреля 2019 .
