😆 🐙 🤛🏻 IPv6: lo estás haciendo mal 🧑🏿‍🤝‍🧑🏽 👩🏻‍🚒 🗓️

Hay muchas ideas falsas y mitos sobre IPv6. A menudo, los proveedores de alojamiento no entienden cómo usarlo y piensan enfoques obsoletos del mundo de IPv4. Por ejemplo, al tener miles de millones de direcciones IPv6, el proveedor vende direcciones a los clientes individualmente, en lugar de asignar una red completa / 64, como se deduce de las recomendaciones.

Sucede que los anfitriones asignan direcciones IPv6 a diferentes clientes dentro de la misma red / 64. Al mismo tiempo, los servicios grandes, como Google, perciben todas las direcciones dentro del rango / 64 como un solo cliente. Como resultado, los clientes pueden sufrir debido a las actividades de un compañero de banda.

La disponibilidad de direcciones IPv6 le permite asignar direcciones externas completas a recursos internos, como contenedores o clientes VPN. Para hacer esto, el host debe proporcionar al cliente una red enrutada separada. Desafortunadamente, casi nadie puede hacer esto.

En este artículo, analizaremos los principales errores en el uso de proveedores de IPv6.

Historia: RFC 3177

En 2001, las recomendaciones sobre la asignación de direcciones recomendadas (perdón por la tautología, esto es importante) para resaltar:

/ 48 en general
/ 64 si detrás hay una y solo una subred
/ 128 si uno y solo un dispositivo

El documento ofensivo RFC 2119, que rige la aplicación de varios niveles de cumplimiento obligatorio de las instrucciones, define "recomendado" de la siguiente manera:
Las palabras "Debería" o "Recomendado" significan que puede haber razones razonables en ciertas circunstancias para no actuar de esta manera, sin embargo, la elección de una línea diferente de comportamiento debe ser una decisión equilibrada tomada con plena comprensión de las consecuencias.
Quizás nadie tenía una comprensión completa de las consecuencias en ese momento, tal vez "ciertas circunstancias" no estaban definidas, pero, de una forma u otra, todos siguieron las recomendaciones.

En general, al momento de escribir el documento, el tráfico IPv6 era extremadamente raro y se encontraba, en su mayor parte, en institutos y redes personales de entusiastas curiosos. Algunos problemas reales comenzaron a acumularse y analizarse, pero tomó mucho tiempo.
El replanteamiento comenzó en 2005. Finalmente, estas recomendaciones quedaron en desuso en 2011.

Conciencia del problema: RFC 6177

La nueva política de direccionamiento establece explícitamente que / 48 es solo un deseo, no un requisito. No se proporciona ninguna indicación de números específicos, sin embargo, se indica que / 64 o menos funciona en condiciones normales.

La lógica principal al recomendar el tamaño de la emisión del bloque / 48 al consumidor final persiguió tres objetivos.

Primero, el espacio de direcciones asignado debe ser suficiente para fines del consumidor y fácilmente extensible, sin sentadillas con barra. Sí, eso es exactamente lo que dice, solo en la versión en inglés: salta a través de los aros. Una de las razones importantes para cambiar a IPv6 es cambiar el tamaño de destino existente de "dirección única" a "subredes múltiples".

En segundo lugar, el cambio de proveedor debería haberse realizado con un mínimo de problemas. Si puede guardar el antiguo esquema de dirección de subred cuando se muda a un nuevo espacio de direcciones, esto ahorrará mucho trabajo

. En tercer lugar, la asignación del bloque / 48 debería cubrir el aumento de las necesidades del espacio de direcciones de un consumidor en desarrollo.

Aunque se cumplieron todas estas condiciones, se hizo evidente que la recomendación / 48 era, por decirlo suavemente, redundante.

Pin / 64 como unidades de emisión

Además del orden de distribución, había otros puntos. Resultó que muchas características de IPv6 no funcionan si el prefijo de red no es / 64. A saber, no funcionan:

Descubrimiento de vecinos (ND)
Descubrimiento de vecindad segura (ENVIAR)
algunas partes de Mobile IPv6
Sitio Multihoming por intermediación IPv6
muchas pequeñas cosas diferentes

Un factor adicional fue el hecho de que muchas de las tecnologías que se diseñaron se basaban precisamente en dicho prefijo de red.

No solo la amenaza de romper el nuevo estándar fue la razón para escribir nuevas recomendaciones. Dos opiniones de dudosa validez también fueron muy populares.
Primero, muchos dispositivos implementan el enrutamiento IPv6 mediante programación, con muletas y bicicletas, y por lo tanto no están listos para una transición completa. Un posible aumento en el retraso debido a esto puede aumentar muchas veces, si no un orden de magnitud. La definición predeterminada de la subred / 64 reduciría en gran medida estos retrasos.

En segundo lugar, cambiar a un nuevo estándar siempre es una molestia para el soporte técnico y los administradores del sistema. Se suponía que un solo prefijo / 64 reduciría este dolor a un valor aceptable.

La situación en los frentes

Como ya sucedió a principios de 2001, muchos grandes jugadores de Internet perciben la recomendación / 64 como un estándar. Por un lado, es bueno, por otro lado, no tan bueno.

Para muchos sistemas de calificación, por ejemplo, para el reconocimiento de spam, todas las direcciones de un bloque se considerarán pertenecientes a un spammer. En teoría, esto debería facilitarle la vida al usuario, de hecho, todo lo contrario.

A menudo, los proveedores no se molestan con cosas como aprender sobre prácticas comunes. Las direcciones pueden emitirse de acuerdo con cualquier principio, al menos incluso de acuerdo con el horóscopo.

Hay varios problemas típicos, y todos ellos se derivan de la violación de las recomendaciones por parte del proveedor, por un lado, y la estricta adhesión a ellos por parte de otras organizaciones por el otro.
La emisión de direcciones de un bloque a varios usuarios puede llevar al hecho de que todos serán considerados como un usuario real, por ejemplo, máquinas en la red de la organización.

Si varias personas de este bloque comienzan a buscar gatos al mismo tiempo, Google puede decidir que esta botnet enviará solicitudes de estafa de búsqueda o alguna otra cosa que no sea muy buena. Desde su punto de vista, este es todo un usuario. El resultado lógico es un captcha cada vez más complicado.

Esta, como saben, es la respuesta más inofensiva a una estafa hipotética.
La situación inversa es la emisión a un usuario de direcciones de diferentes bloques. Si los usuarios de estos bloques caen en la lista negra de alguien, entonces las direcciones de un usuario honesto caerán con ellos. Historia particularmente interesante: algunas de sus direcciones fueron prohibidas por una red publicitaria, otras fueron prohibidas por otra.

Además, son posibles otras sorpresas desagradables. Por ejemplo, recibió el bloque / 64, pero este es un bloque dinámico, como una dirección dinámica: hoy 2001: DA8: 1D01: FA13 :: / 64, mañana 2001: DA8: 1D01: FC15 :: / 64. ¡Nuevas aventuras cada día!
Hay una posibilidad considerable de encontrar varias combinaciones de estos problemas y otros rastrillos curiosamente curvos en el apéndice.

Emita IPv6 desde nuestro servidor

Si tenemos quintillones de direcciones IP, ¿por qué no dar direcciones IP reales, por ejemplo, a clientes VPN para que vayan a Internet sin NAT y puedan aceptar conexiones entrantes del mundo? Suena genial, pero en la práctica no es tan fácil. Esto requerirá una red IPv6 separada enrutada a través de la dirección IP asignada a la interfaz del servidor.

Suponga que a un servidor se le asigna una dirección 2a01:baba::c0fee:dead/64, entonces los clientes VPN necesitarán una red separada, 2a01:baba:fafa:0f0f::/64como enrutada a través de la dirección 2a01:baba::c0fee:dead/64.

Desafortunadamente, muy pocos proveedores de alojamiento tienen las herramientas para emitir tales redes a los clientes, por lo que debe usar muletas como ND Proxy .

Conclusión

Leer las recomendaciones del IETF no es la actividad más interesante, pero es extremadamente útil. Llenarlos con largas tardes de invierno claramente no vale la pena, pero también descuidar leer secciones que son importantes para usted también es indeseable.

Al elegir un proveedor, asegúrese de que él comparta este punto de vista.

Debe comprender que el enfoque incorrecto para la asignación de direcciones no perjudica al proveedor, y para la mayoría de los contratos ni siquiera puede ser la base de una compensación.
Sin embargo, esto puede resultar ser un factor clave para usted, aunque usted mismo aún no lo sospeche.