12 de octubre de 2015

Direccionamiento IPv6 en enlaces punto a punto (1)

Un tema aparte cuando se trata de redes local (no me siento cómodo diciendo "subredes") en IPv6 es el de los enlaces punto a punto.
Cuando arrastramos nuestra cultura IPv4 al ámbito de redes IPv6 seguimos pensando en la escasez y el desperdicio; y cuando trasladamos esto a enlaces punto a punto inmediatamente surge el modelo de subredes /30 con solamente 4 IPs para cada subred.

Y entonces hay una pregunta de rigor: ¿un prefijo IPv6 /64 para un enlace punto a punto? ¿No es un desperdicio?
En realidad este es un punto más en el que debemos tener presente la variedad de direcciones de unicast que manejan las interfaces IPv6. No sólo tenemos direcciones globales que podrían ser escasas en un futuro hipotético (no hay que olvidar que en este momento IANA ha tomado para su asignación solamente 1/8 del espacio disponible y todavía está lejos de agotarse), sino que también contamos con direcciones unicast link local y unique local.

Por este motivo hay 2 soluciones recomendadas:
  • La implementación de direccionamiento global con prefijos IPv6 /127.
    Esta solución tiene sus detalles, pero está recomendada en el RFC 6164.
  • El aprovechamiento de las direcciones de link local para los enlaces de infraestructura.
    Es un recurso completamente válido, aunque tiene algunas limitaciones que deben ser tenidas en cuenta al momento de tomar definiciones.
En este artículo me centraré en el uso de direcciones link local, dejo para un post futuro el uso de direcciones globales con prefijos /127.

Las direcciones link local:
  • Son identificadores plenamente operativos y únicos dentro del segmento de red. 
  • No son ruteables y se asignan automáticamente en el momento en que el protocolo comienza a ser operativo en la interfaz. 
  • Se generan a partir del prefijo FE80::/10 sin requerir asignación del espacio de direccionamiento unicast global. 
  • Toda interfaz cuenta con una dirección link local generada automáticamente.
  • En los dispositivos de infraestructura esas direcciones se generan utilizando EUI-64, con lo que no varían a lo largo del tiempo y una interfaz mantiene siempre la misma dirección link local a menos que se modifique por configuración.
  • Se integran en la tabla de enrutamiento y pueden operar como identificadores del próximo salto.
  • Son las utilizadas por los protocolos de enrutamiento como EIGRP y OSPFv3 para identificar los dispositivos vecinos.
La consecuencia inmediata de esto es que todas las interfaces seriales en las que se activa IPv6 cuentan con una dirección de link local y por lo tanto son inmediatamente operativas a nivel de capa 3. De este modo, las interfaces y las redes asociadas se integran inmediatamente en la tabla de enrutamiento.
Por lo tanto no es necesario asignar direccionamiento IPv6 global a las interfaces que se integran en un enlace punto a punto. Para eso es suficiente el direccionamiento link local.

Las interfaces que integran los enlaces punto a punto que son parte de la infraestructura de transporte (no estoy hablando de enlaces de acceso) en general no son origen o destino de tráfico sino que son interfaces de tránsito a través de las cuales en paquete se enruta hacia destinos remotos. Para esto lo que se requiere es que cuenten con direccionamiento operativo, que se integre en el proceso de enrutamiento, y para esto una dirección link local es suficiente.
¿Cuándo estas interfaces necesitan un direccionamiento ruteable (que no sea link local)?
Cuando se convierten en origen o destino de tráfico.
¿Y cuándo esas interfaces son origen o destino de tráfico?
En primer lugar, son origen o destino de actualizaciones de protocolos de automatización tales como los protocolos de enrutamiento. Pero como ya dije, para esto se utiliza la dirección link local no la dirección global aún cuando la haya.
En segundo lugar, cuando se utiliza la dirección de la interfaz para definir el acceso al plano de gestión o para tareas de diagnóstico. Para hacer un telnet o un tracert por ejemplo. Por eso hay otras opciones que no  desarrollaré ahora, será objeto de otro post.

Limitaciones de esta implementación:
  • No se puede utilizar la dirección de las interfaces para tareas de diagnóstico como ping.
  • No se puede utilizar la dirección de las interfaces para acceder remotamente a la gestión utilizando SNMP, Telnet o SSH.
  • En sesiones eBGP es más simple utilizar direcciones globales, de lo contrario es necesario sobreescribir el atributo nexthop.
  • Al realizar traceo de las rutas no se recibe identificación de los saltos intermedio.
Algunos recursos en línea:

No hay comentarios.:

Publicar un comentario

Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.