2011-06-06 9 views
7

Estaba trabajando en un proyecto que incluye el desarrollo de una aplicación usando sockets de Java. Sin embargo, al leer algunos fundamentos y el nuevo paradigma de IPv6 que me motivó a hacer la siguiente pregunta,¿Cuáles son los beneficios de eliminar la fragmentación de IPv6?

¿Cuáles son los beneficios de eliminar la fragmentación de IPv6?

Sería útil si alguien me puede entender por qué?

He investigado en Internet pero no he encontrado ninguna descripción útil.

Respuesta

12

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:

  1. ver sección 4.5 de la Internet Protocol, Version 6 (IPv6) Specification

  2. 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.

  3. Ver Teardrop attack (wikipedia)

  4. Ver RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls

+1

+1, es increíble cuánto más veloces pueden ser los enrutadores cuando pueden hacer todo en hardware – mpontillo

+4

Bloquear todo v4 ICMP es igual de nocivo: las respuestas de Fragmentación necesaria son tan importantes para PMTUD en IPv4. – caf

4

No tengo la respuesta "oficial" para usted, pero basándome en la lectura de cómo IPv6 maneja datagramas que son demasiado grandes, mi conjetura sería reducir la carga en los enrutadores. La fragmentación y el reensamblaje generan gastos generales en el enrutador. IPv6 mueve esta carga a los nodos finales y requiere que realicen el descubrimiento MTU para determinar el tamaño máximo de datagrama que pueden enviar. Es lógico pensar que los nodos finales son más adecuados para la tarea porque tienen menos datos para procesar. Efectivamente, los enrutadores tienen suficiente en sus placas; tiene sentido obligar a los nodos a manejarlo y permitir que los enrutadores simplemente eliminen algo que exceda su umbral de MTU.

Idealmente, el resultado final sería que los enrutadores pueden manejar una carga mayor en IPv6 (siendo iguales) que en IPv4 porque no hay fragmentación/reensamblaje de los que tengan que preocuparse. Esa potencia del procesador se puede dedicar al tráfico de enrutamiento.

+1

"_La fragmentación y el reensamblado generan gastos indirectos en el enrutador_" ¿por qué un ** enrutador manejaría el reensamblaje? – curiousguy

0

IPv4 tiene una MTU mínimo garantizado de 576 bytes, IPv6 es 1280 bytes, y la recomendación es de 1.500 bytes, la diferencia es básicamente el rendimiento . Como la mayoría de los segmentos de LAN para el usuario final son 1.500 bytes, reduce la sobrecarga de la infraestructura de red para almacenar el estado debido a la fragmentación adicional de lo que son efectivamente redes heredadas que requieren tamaños más pequeños.

Para UDP no existe una definición en los estándares IPv4 sobre la reconstrucción de paquetes fragmentados, lo que significa que cada plataforma puede manejarlo de manera diferente. IPv6 afirma que la fragmentación y el ensamblaje siempre ocurrirán en la pila de IP y los fragmentos no se presentarán a las aplicaciones.

+4

Lo siento, no es correcto que IPv6 requiera 1500 bytes. [RFC 2460] (http://www.faqs.org/rfcs/rfc2460.html) permite MTU de capa2 desde 1280 bytes, consulte la Sección 5. –

+3

¿Por qué es importante si el fragmento es TCP o UDP? La fragmentación IPv4 se maneja en la capa IP. –

+0

@Mike conjunto de datagramas no está garantizado. Muchas pilas de middleware de mensajería incluyen código específicamente para la reconstrucción cuando la pila IP subyacente no lo garantiza. –

Cuestiones relacionadas