¿Los enrutadores combinan paquetes divididos cuando llegan si fueron divididos por el enrutador anterior en la ruta?

Primero, analicemos la teoría: en teoría, un enrutador que recibe un paquete que es más grande que el MTU del siguiente salto tiene la opción de rechazar el paquete o fragmentar el paquete y reenviarlo en dos (o más) partes al siguiente salto. Cuando un enrutador fragmenta un paquete para reenviarlo a través de un transporte con una MTU más pequeña que el tamaño del paquete, en teoría el reensamblaje tendrá lugar en el destino final, y es obligación del destino final volver a ensamblar los fragmentos, no reenviador intermedio posterior en el camino.

En la práctica, la fragmentación rara vez ocurre. Muy pocos dispositivos intermedios en realidad fragmentarán los paquetes; prácticamente todos los dispositivos de reenvío están configurados actualmente para rechazar paquetes que son demasiado grandes para reenviarlos en lugar de fragmentarlos. La especificación IPv4 permite a los reenviadores negarse a fragmentar paquetes de más de 576 bytes, y muy pocos transportes tienen hoy un tamaño máximo de paquete tan bajo, por lo que en la práctica la fragmentación obligatoria de IPv4 es extremadamente rara en la actualidad. El estándar IPv6 prohíbe la fragmentación por completo: un enrutador IPv6 debe rechazar cualquier paquete que no pueda reenviar debido a las limitaciones de MTU.

Además, el reensamblaje puede tener lugar antes de la llegada de los fragmentos al destino. Es posible que varios dispositivos intermedios (como los traductores de direcciones de red y los firewalls de inspección de paquetes) necesiten volver a ensamblar fragmentos antes de que puedan realizar sus funciones respectivas, y a veces lo harán en lugar de simplemente rechazar los fragmentos por completo. Sin embargo, hoy es más probable que tales dispositivos simplemente rechacen fragmentos en lugar de intentar volver a ensamblarlos.

Hay una serie de ataques que dependen del abuso de la fragmentación, lo que ha llevado a una gran cantidad de pilas de red simplemente rechazando todos los fragmentos por razones de seguridad. Debe suponer que, en una red moderna, la fragmentación nunca ocurrirá, y que los paquetes que exceden la MTU de cualquier host a lo largo de la ruta serán rechazados, posiblemente en silencio. Si lo necesita, use el algoritmo de descubrimiento de MTU de ruta (https://www.ietf.org/rfc/rfc1191…) para determinar la MTU máxima admitida a lo largo de una ruta.

Es vagamente útil entender el algoritmo de fragmentación desde el punto de vista de la historia y el desarrollo de TCP / IP, pero no se encontrará con este problema en un entorno práctico. Si está escribiendo una pila TCP / IP, probablemente sea mejor que simplemente rechace los fragmentos entrantes y se niegue a reenviar paquetes que tendrían que estar fragmentados, pero si desea escribir el código para tratar con ellos, asegúrese de cualquier código Usted escribe es resistente a los ataques de fragmentación de paquetes. Muchos de estos ataques se basan en enviar fragmentos deliberadamente malformados con superposiciones, o en enviar un gran número de fragmentos muy pequeños para causar un ataque de desbordamiento del búfer o denegación de servicio; su código debe ser capaz de manejar este tipo de ataques de manera robusta.

No. El reensamblaje de segmentos es responsabilidad del host de destino.

Con suerte, el descubrimiento de ruta MTU significa que el creador establece el tamaño del paquete en algo que no necesitará fragmentación. 1500 byte es bastante seguro en las redes modernas, o alrededor de 9000 si sabe que los jumbogramas son compatibles en todas partes.

Cuando se trata de límites de paquetes, a TCP no podría importarle menos. TCP se siente responsable de la entrega de un flujo de datos en el orden correcto y sin pérdidas para la aplicación dirigida.

Todas las capas, TCP, IP y enlace de datos a segmentación y reensamblaje a su conveniencia. Como diseñador de aplicaciones, no puede confiar en los paquetes entregados como los paquetes que envió.

No. El reensamblaje solo se realiza en el destino. Esto se hace para evitar múltiples retrasos / caídas de reensamblado en un enlace que requiere fragmentación.