Es un error común que haya no fragmentación IPv6 porque el encabezado IPv6 no tiene el campo de desplazamiento de fragmentos que IPv4 hace; sin embargo, no es exactamente exacto. IPv6 no permite que los enrutadores fragmenten paquetes; sin embargo, los nodos finales pueden insertar un encabezado de fragmentación IPv6 .
Como RFC 5722 indica , uno de los problemas con la fragmentación es que tiende a crear agujeros de seguridad. Durante finales de la década de 1990 hubo varios ataques conocidos en Windows 95 que explotaron la superposición de fragmentos de IPv4 ; Además, la fragmentación en línea de los paquetes es riesgosa de quemar en el enrutador de silicio de Internet debido a la larga lista de problemas que deben manejarse. Uno de los mayores problemas es que la superposición de fragmentos almacenados en un enrutador (a la espera de su reensamblaje) podría ocasionar una vulnerabilidad de seguridad en ese dispositivo si se manejan mal. El resultado final es que la mayoría de las implementaciones de enrutadores envían paquetes que requieren fragmentación al software; esto no escala a grandes velocidades.
El otro problema es que si vuelve a ensamblar fragmentos, debe almacenarlos en un búfer durante un período de tiempo hasta que se reciba el resto. Es posible que alguien aproveche esta dinámica y envíe un gran número de fragmentos de IP sin terminar; obligando al dispositivo en cuestión a gastar muchos recursos esperando una oportunidad para volver a armarlo. Las implementaciones inteligentes limitan el número de fragmentos pendientes para evitar una denegación de servicio; sin embargo, limitar los fragmentos sobresalientes podría afectar legítimamente el número de fragmentos válidos que se pueden volver a ensamblar.
En resumen, hay demasiados problemas peludos para permitir que un enrutador maneje la fragmentación. Si los paquetes IPv6 requieren fragmentación, las implementaciones de los hosts deben ser lo suficientemente inteligentes como para usar TCP Path MTU discovery. Eso también implica que varios mensajes ICMPv6 deben ser permitidos de extremo a extremo; Curiosamente, muchos administradores de cortafuegos IPv4 bloquean ICMP para protegerse contra mapeos de red hostiles (y luego bloquean ingenuamente todo ICMPv6), sin darse cuenta de que al bloquear todo ICMPv6 se rompe las cosas de manera sutil .
notas finales:
ver sección 4.5 de la Internet Protocol, Version 6 (IPv6) Specification
De RFC 5722: Handling of Overlapping IPv6 Fragments:
firewalls usados comúnmente utilizan el algoritmo especificado en [RFC1858] para eliminar los paquetes maliciosos que intentan a overw rite partes del encabezado de capa de transporte en para omitir las comprobaciones de conexión entrante. [RFC1858] impide un ataque de fragmento superpuesto en un protocolo de capa superior (en este caso, TCP) recomendando que los paquetes con un desplazamiento de fragmento de 1 se descarten.
Si bien esto funciona bien para los fragmentos de IPv4, no funcionará para los fragmentos de IPv6. Esto se debe a que la parte fragmentable del paquete IPv6 puede contener encabezados de extensión antes del encabezado TCP, por lo que esta comprobación es menos efectiva.
Ver Teardrop attack (wikipedia)
Ver RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls
+1, es increíble cuánto más veloces pueden ser los enrutadores cuando pueden hacer todo en hardware – mpontillo
Bloquear todo v4 ICMP es igual de nocivo: las respuestas de Fragmentación necesaria son tan importantes para PMTUD en IPv4. – caf