Path MTU Discovery ( PMTUD ) es una técnica estandarizada en redes de computadoras para determinar el tamaño máximo de la unidad de transmisión (MTU) en la ruta de red entre dos hosts de Protocolo de Internet (IP), generalmente con el objetivo de evitar la fragmentación de IP . PMTUD se diseñó originalmente para enrutadores con Protocolo de Internet versión 4 (IPv4). [1] Sin embargo, todos los sistemas operativos modernos lo utilizan en terminales. En IPv6 , esta función se ha delegado explícitamente a los puntos finales de una sesión de comunicaciones. [2]
PMTUD está estandarizado para IPv4 en RFC 1191 [3] y para IPv6 en RFC 8201 (que dejó obsoleto RFC 1981, el anterior estándar IPv6 PMTUD). [4] RFC 4821 [5] describe una extensión de las técnicas que funciona sin el apoyo del Protocolo de mensajes de control de Internet . RFC 8899 [6] actualiza RFC 4821 mediante la introducción de directrices para el uso de la capa de paquetización PMTUD con UDP y SCTP.
Implementación
Para los paquetes IPv4, Path MTU Discovery funciona estableciendo el bit de marca Don't Fragment (DF) en los encabezados IP de los paquetes salientes. Luego, cualquier dispositivo a lo largo de la ruta cuya MTU sea más pequeña que el paquete lo descartará y enviará un mensaje de Fragmentación necesaria (Tipo 3, Código 4) del Protocolo de mensajes de control de Internet (ICMP) que contiene su MTU, lo que permite que el host de origen reduzca su Ruta MTU de forma adecuada. El proceso se repite hasta que la MTU es lo suficientemente pequeña como para recorrer todo el camino sin fragmentación.
Los enrutadores IPv6 no admiten la fragmentación y, por lo tanto, no admiten la opción No fragmentar . Para IPv6, Path MTU Discovery funciona asumiendo inicialmente que la ruta MTU es la misma que la MTU en la interfaz de la capa de enlace donde se origina el tráfico. Luego, de manera similar a IPv4, cualquier dispositivo a lo largo de la ruta cuya MTU sea más pequeña que el paquete descartará el paquete y enviará un mensaje ICMPv6 Packet Too Big (Tipo 2) que contiene su MTU, lo que permite que el host de origen reduzca su MTU de ruta de manera adecuada. El proceso se repite hasta que la MTU es lo suficientemente pequeña como para recorrer todo el camino sin fragmentación. [7]
Si la MTU de ruta cambia después de que se establece la conexión y es más baja que la MTU de ruta determinada previamente, el primer paquete grande causará un error ICMP y se encontrará la nueva MTU de ruta más baja. Por el contrario, si PMTUD encuentra que la ruta permite una MTU más grande de lo que es posible en el enlace inferior, el sistema operativo repetirá periódicamente para ver si la ruta ha cambiado y ahora permite paquetes más grandes. Tanto en Linux como en Windows, este temporizador está configurado de forma predeterminada en diez minutos. [8] [9]
Problemas
Muchos de los llamados dispositivos de seguridad de red bloquean todos los mensajes ICMP para obtener beneficios de seguridad percibidos, [10] incluidos los errores que son necesarios para el correcto funcionamiento de PMTUD; tenga en cuenta que esto es a pesar del artículo de referencia que describe específicamente un buen ICMP como el que se requiere para que PMTUD funcione correctamente. Esto puede dar como resultado conexiones que completen correctamente el protocolo de enlace de tres vías de TCP , pero que luego se cuelguen cuando se transfieran los datos. Este estado se conoce como conexión de agujero negro . [11]
Algunas implementaciones de PMTUD intentan prevenir este problema infiriendo que los paquetes de carga útil grandes se han descartado debido a MTU en lugar de debido a la congestión del enlace. Sin embargo, para que el Protocolo de control de transmisión (TCP) funcione de manera más eficiente, se deben permitir los mensajes ICMP inalcanzables (tipo 3). En RFC 4821 se ha estandarizado un método robusto para PMTUD que se basa en TCP u otro protocolo para sondear la ruta con paquetes cada vez más grandes.
Una solución alternativa utilizada por algunos enrutadores es cambiar el tamaño máximo de segmento (MSS) de todas las conexiones TCP que pasan por enlaces con MTU menor que el valor predeterminado de Ethernet de 1500. Esto se conoce como sujeción MSS . [12]
Referencias
- ^ RFC 1191, Path MTU Discovery , J. Mogul, S. Deering (noviembre de 1990)
- ^ RFC 1981, Path MTU Discovery para IP versión 6 , J. McCann, S. Deering, J. Mogul (agosto de 1996)
- ^ Mogul, J .; Deering, S. (noviembre de 1990). "Path MTU Discovery" . tools.ietf.org . ISSN 2070-1721 . Consultado el 18 de mayo de 2021 .
- ^ Mogul, Jeffrey; Hinden, Robert (julio de 2017). "Path MTU Discovery para IP versión 6" . tools.ietf.org . ISSN 2070-1721 . Consultado el 15 de abril de 2019 .
- ^ RFC 4821, Descubrimiento de MTU de ruta de la capa de paquetización , M. Mathis, J. Heffner (marzo de 2007)
- ^ RFC 8899, Descubrimiento de MTU de ruta de la capa de paquetización para transportes de datagramas , G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, T. Völker (septiembre de 2020)
- ^ Davies, Joseph (2012). Comprensión de IPv6 (3ª ed.). Microsoft Press. págs. 146-147. ISBN 9780735659148.
- ^ código fuente de linux (ipv4) y código fuente de linux (ipv6) ver línea con "mtu_expires" 10 * 60 segundos
- ^ Davies, Joseph (2012). Comprensión de IPv6 (3ª ed.). Redmond: Microsoft Press. pag. 147. ISBN 978-0735659148. OCLC 810455372 .
- ^ Michael Mullins (21 de octubre de 2003). "Evite el sondeo de los piratas informáticos bloqueando el tráfico ICMP" . Consultado el 12 de julio de 2013 .
- ^ RFC 2923, Problemas de TCP con Path MTU Discovery , K. Lahey (septiembre de 2000)
- ^ "Eludir los problemas de Path MTU Discovery con MSS Clamping (para usuarios de ADSL, cable, PPPoE y PPtP)" . lartc.org . Consultado el 15 de abril de 2019 .