Recientemente encontré un problema de IPv6 NAT. Después de resolverlo, siempre quise escribir algo metafísico, qué es correcto, qué está mal, qué es razonable, qué es irrazonable, documentos irrelevantes, código irrelevante o incluso tecnología irrelevante, simplemente casual Charla. Ayer resolví mis pensamientos en el camino del trabajo. Es fin de semana, así que escribamos un poco.
Si un paquete es demasiado grande pero no se puede fragmentar, por ejemplo, los paquetes IPv4 y todos los paquetes IPv6 que llevan la bandera DF, el dispositivo de reenvío enviará un mensaje ICMP a la estación de origen de los datos, lo que significa que usted El texto es demasiado grande, reduzca los datos y vuelva a enviarlo.
Para IPv4, no necesitamos preocuparnos demasiado por este mensaje ICMP, porque en las redes IPv4, siempre que el mensaje IP en sí no esté marcado con DF, se puede fragmentar arbitrariamente. Incluso si lleva la marca DF, tenemos suficiente experiencia para corresponder, pero En el caso de IPv6, las cosas se vuelven más complicadas, especialmente cuando hay dispositivos NAT en los enlaces intermedios.
A excepción de la estación de origen, los paquetes IPv6 no se pueden fragmentar en todo el proceso. Por lo tanto, si encuentra un dispositivo con una MTU más pequeña que el tamaño del paquete, debe asegurarse de que el mensaje ICMP demasiado grande enviado por el dispositivo pueda llegar correctamente a la estación de origen. En una red IPv6 salto por salto estándar, esto no es un problema, porque no importa qué ruta siga, siempre que el mensaje ICMP llegue a la estación de origen, todo estará bien. Sin embargo, si el mensaje original pasa por un dispositivo NAT, se debe garantizar estrictamente que el mensaje ICMP devuelto pasa por el mismo dispositivo NAT, condición que no se puede garantizar sin medios especiales en una red real, especialmente en el caso de ECMP. .
Echemos un vistazo a un caso de los comentarios del código nf_conntrack del kernel de Linux: La
siguiente figura muestra varias situaciones del caso y el enlace NAT:
Para que el mensaje ICMP demasiado grande llegue a la estación de origen a través del mismo dispositivo NAT, tenemos que tomar algunas medidas para vincular el mensaje ICMP demasiado grande al flujo de datos original y ejecutar la misma política de equilibrio de carga (como en el caso de ECMP). Introducir mucho trabajo extra, sí, es muy frustrante.
¡Marido!
¿IPv6 todavía necesita NAT y por qué?
Obviamente, IPv6 no tiene el problema de direcciones insuficientes. Obviamente, IPv6 puede llevar un encabezado de seguridad para garantizar la seguridad. Obviamente, IPv6 puede ocultar hosts con ID de host aleatorio. Obviamente, IPv6 no necesita NAT en absoluto.
IPv4 también estaba limpio al principio. NAT no se incluyó en el diseño inicial. Esta tecnología posterior se introdujo para resolver algunos de los problemas inherentes de IPv4. Sin embargo, ¿por qué y por qué debería llevarse este legado de IPv4 a La nueva era de IPv6. ¡Heredar algo incorrecto no tiene sentido para IPv6!
Sin NAT, IPv6 depende completamente del enrutamiento para la interconexión de toda la red. Ésta es la intención original de Internet. Sin embargo, aún más radicalmente, ¡incluso IPv6 sin NAT no es tan bueno como IPv4!
¡IPv6 puede ser otro error!
NAT es para resolver los problemas de IPv4, y también lo es IPv6. NAT resuelve algunos de los problemas de IPv4, e IPv6 afirma que resuelve todos los problemas de IPv4. Sin embargo, lamentablemente, después del carnaval de las nuevas tecnologías, es difícil imaginar el costo que hay detrás. Para resolver los problemas de IPv4, el costo de introducción .
¿Es importante asignar una dirección IP a cada grano de arena o ahorrar un kilovatio-hora de electricidad?
IPv6 necesita más espacio para almacenarse y transmitirse. Al mismo tiempo, las direcciones IPv6 de 128 bits descartarán la mayoría de los algoritmos de búsqueda de enrutamiento IPv4. Al mismo tiempo, el algoritmo de coincidencia de prefijos más largo no tiene cambios esenciales. Esto requiere más energía para suavizar esta transición. , El diseño de algoritmos más complejos, aunque la asignación jerárquica de direcciones reduce efectivamente el tamaño de la tabla de enrutamiento IPv6, pero solo se reduce.
En esencia, IPv6 es lo mismo que IPv4 y los procesadores de 64 bits son para los procesadores de 32 bits, solo con la esperanza de realizar milagros enérgicamente, pero el precio que hay detrás es el cambio cualitativo de varias instalaciones de soporte. Daré el viejo ejemplo, el rascacielos de 600 metros. Los edificios son fáciles de construir, pero un rascacielos de 1200 metros es difícil, porque la complejidad del sistema de soporte aumentará exponencialmente, no temas que las hormigas se vuelvan tan grandes como las personas, porque se aplastarán.
Tal vez no sea apropiado que IPv4 use la misma dirección IP en el mismo espacio de direcciones para identificar el terminal y la red en sí al mismo tiempo. Claramente hay dos niveles, pero tienen que estar comprimidos en un espacio de direcciones. Con el tiempo, encontrará que el número de terminales está aumentando. De hecho, los nodos intermedios no se han expandido en las magnitudes correspondientes. En los últimos 40 años, el número de nuestras terminales ha aumentado a varios miles de millones, pero el crecimiento de los enrutadores ha sido mucho menor en varios órdenes de magnitud. Los dos no necesitan la misma escalabilidad. El terminal y la red no son lo mismo. Ponerlos en la misma dirección en el mismo espacio de direcciones puede que no sea lo más fácil.
De hecho, siempre he pensado que la idea de diseño del protocolo LISP (Locator Identity Separation) es muy buena, bueno, debería ser la más simple.
De acuerdo, no es adecuado para presentar el tema de LISP, así que se acabó. Dime bien, esto es solo un ensayo metafísico, no tiene nada que ver con detalles técnicos, así que no importa si es correcto, no conozco detalles técnicos. Escriba aqui.
Los zapatos de cuero en Wenzhou, Zhejiang están mojados, por lo que no engordan con la lluvia.