Descubrimiento de MTU de ruta

Protocolo de red informática para determinar el tamaño máximo de los paquetes a transmitir

Path MTU Discovery ( PMTUD ) es una técnica estandarizada en redes informáticas 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 fue originalmente pensado para enrutadores en Protocolo de Internet versión 4 (IPv4). [1] Sin embargo, todos los sistemas operativos modernos lo utilizan en puntos finales. En IPv6 , esta función ha sido delegada explícitamente a los puntos finales de una sesión de comunicaciones. [2] Como una extensión del descubrimiento estándar de path MTU, una técnica llamada Path MTU Discovery de capa de empaquetamiento funciona sin soporte de ICMP . [3]

Implementación

En el caso de los paquetes IPv4, Path MTU Discovery funciona configurando el bit de bandera Don't Fragment (DF) en los encabezados IP de los paquetes salientes. Luego, cualquier dispositivo a lo largo de la ruta cuya MTU sea menor que el paquete lo descartará y enviará de vuelta 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 MTU de ruta de manera adecuada. El proceso se repite hasta que la MTU sea lo suficientemente pequeña como para atravesar toda la ruta sin fragmentación.

Como los enrutadores IPv6 no fragmentan los paquetes, no existe la opción No fragmentar en el encabezado IPv6 . Para IPv6, Path MTU Discovery funciona asumiendo inicialmente que la MTU de la ruta 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 menor que el paquete descartará el paquete y enviará de vuelta un mensaje ICMPv6 Paquete demasiado grande (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 sea lo suficientemente pequeña como para atravesar toda la ruta sin fragmentación. [4]

Si la MTU de la ruta cambia después de que se establece la conexión y se vuelve menor que la MTU de la ruta determinada previamente, el primer paquete grande causará un error ICMP y se encontrará la nueva MTU de la ruta más baja. Si la ruta cambia y la nueva MTU de la ruta es más grande, la fuente no se enterará del aumento, porque todos los enrutadores a lo largo de la nueva ruta podrán retransmitir todos los paquetes que la fuente envíe utilizando la MTU de la ruta más baja determinada originalmente. [5] [6] [4]

Problemas

Muchos dispositivos de seguridad de red bloquean todos los mensajes ICMP por razones de seguridad percibidas, incluidos los errores necesarios para el correcto funcionamiento de PMTUD. Esto puede dar lugar a conexiones que completan correctamente el protocolo de enlace de tres vías TCP , pero que luego se bloquean al intentar transferir datos. Este estado se conoce como conexión de agujero negro . [7]

Algunas implementaciones de PMTUD intentan evitar este problema infiriendo que se han descartado paquetes de gran tamaño debido a la MTU en lugar de a la congestión del enlace. Uno de estos esquemas está estandarizado en RFC 8899, Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). [3] En caso de pérdida de conectividad, DPLPMTUD utiliza paquetes de sondeo de tamaños controlados para sondear la MTU de la ruta. El reconocimiento de un paquete de sondeo indica que la MTU de la ruta es al menos del tamaño de ese paquete. El uso de DPLPMTUD está estandarizado en QUIC . [8] Sin embargo, para que los protocolos de la capa de transporte funcionen de manera más eficiente, los mensajes ICMP inalcanzables (tipo 3) aún deberían estar permitidos.

Algunos enrutadores, incluidos los del núcleo Linux [9] y Cisco [10] , ofrecen una opción para reducir el tamaño máximo de segmento (MSS) anunciado en el protocolo de enlace TCP como solución alternativa. Esto se conoce como fijación de MSS .

Otro problema es cuando los administradores de redes no actualizan correctamente la MTU entre dos saltos de capa 3 adyacentes si el enlace entre estos saltos está compuesto por múltiples segmentos de capa 2 con conmutadores entre ellos. Por lo general, la MTU en la interfaz L3 saliente se toma del primer segmento L2. Pero si el segundo segmento o los siguientes tienen una MTU menor, el conmutador que se encuentra entre ellos simplemente descartará silenciosamente el paquete sin informar ningún ICMP (porque solo los saltos de capa 3 pueden generar un "paquete demasiado grande" ICMP). Por lo tanto, en este caso, los administradores deben actualizar la MTU para cada interfaz L3 saliente a la MTU mínima de los segmentos de capa 2 utilizados hasta el siguiente salto L3.

Referencias

  1. ^ J. Mogul; S. Deering (noviembre de 1990). Path MTU Discovery. Grupo de trabajo de redes. doi : 10.17487/RFC1191 . RFC 1191. Proyecto de Norma. Obsoleto RFC 1063.
  2. ^ J. McCann; S. Deering ; J. Mogul (julio de 2017). R. Hinden (ed.). Path MTU Discovery for IP version 6. IETF . doi : 10.17487/RFC8201 . STD 87. RFC 8201. Estándar de Internet 87. Obsoleto RFC 1981.
  3. ^ ab G. Fairhurst; T. Jones; M. Tüxen; I. Rüngeler; T. Völker (septiembre de 2020). Descubrimiento de la MTU de la ruta de la capa de paquetización para transportes de datagramas. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC8899 . ISSN  2070-1721. RFC 8899. Norma propuesta. Actualizaciones RFC 4821, 4960, 6951, 8085 y 8261.
  4. ^ de Davies, Joseph (2012). Entender IPv6 (3.ª ed.). Redmond: Microsoft Press. pp. 146–147. ISBN 978-0735659148.OCLC 810455372  .
  5. ^ E. Comer, Douglas (2014). Interconexión de redes con TCP/IP, volumen 1 (6.ª ed.). Pearson, págs. 133-134. ISBN 0-13-608530-X.
  6. ^ Código fuente de Linux (IPv4) y código fuente de Linux (IPv6) ver línea con "mtu_expires" 10 * 60 segundos
  7. ^ K. Lahey (septiembre de 2000). Problemas de TCP con el descubrimiento de la MTU de ruta. Grupo de trabajo de redes. doi : 10.17487/RFC2923 . RFC 2923. Informativo.
  8. ^ J. Iyengar; M. Thomson, eds. (mayo de 2021). QUIC: Un transporte multiplexado y seguro basado en UDP. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9000 . ISSN  2070-1721. RFC 9000. Norma propuesta.
  9. ^ "Maltratar encabezados de paquetes - wiki de nftables". wiki.nftables.org . Consultado el 3 de julio de 2024 .
  10. ^ "Concepto de ajuste de MTU de Ethernet y MSS de TCP para conexiones PPPoE". Cisco . Consultado el 3 de julio de 2024 .
Obtenido de "https://es.wikipedia.org/w/index.php?title=Descubrimiento_de_MTU_de_ruta&oldid=1253678995"