20 de octubre de 2015

Direccionamiento IPv6 en enlaces punto a punto (2)

Como mencioné en el post anterior, hay 2 soluciones propuestas para aplicar direccionamiento en enlaces punto a punto:
Si bien el uso solamente de direcciones link local es una solución viable y que no requiere ninguna elaboración adicional, tiene sus limitaciones:
  • Las herramientas de diagnóstico (ping, traceroute) no se pueden aplicar utilizando estas direcciones.
  • No se puede acceder remotamente a través de estas interfaces utilizando un Telnet o SSH.
  • Puede utilizarse en entornos eBGP, pero requiere configuración adicional.
En estos casos es entonces conveniente aplicar direccionamiento global. Y entonces volvemos al planteo inicial de esta serie de posts. ¿No es demasiado utilizar prefijos /64?
Hay quienes responden que no, que hay suficiente espacio disponible y se facilita la configuración ya que se puede apelar a la asignación automática de ID de interfaz, y de hecho se utilizan en esos enlaces prefijos /64.
Ahora bien, más allá de la discusión de la necesidad o no de cuidar desde ahora la disponibilidad de direcciones globales es cierto que se trata de segmentos de red que por su propia naturaleza no están destinados a crecer en cantidad de puertos y que por lo tanto carece de sentido asignarles espacios de direccionamiento tan amplios y que nunca serán utilizados.
Por otra parte, el uso de prefijos /64 o semejantes en enlaces entre routers deja abiertas posibilidades de ataques en diferentes contextos. De allí la recomendación de utilizar prefijos /127 en enlaces punto a punto, cualquiera sea la tecnología de capa 2 utilizada.

¿Por qué /127 y no /126?
Una vez más, si arrastramos nuestros conceptos IPv4 a la arquitectura IPv6, lo lógico parece ser utilizar prefijos /126: para un enlace punto a punto se necesitan 4 direcciones IP: 2 direcciones útiles (una para cada puerto) y 2 reservadas.
Pero... en IPv6 las cosas no son iguales.

En IPv6 no hay broadcast, por lo tanto no existen las direcciones reservadas de broadcast.
Tampoco hay una dirección reservada de red, pero sí existe la dirección subnet-router unicast. Las direcciones subnet-router unicast es la dirección IPv6 con todos los bits correspondientes al ID de nodo en cero. Estas direcciones se utilizan cuando un nodo necesita comunicarse desde cualquier punto de la red global con cualquiera de los routers presentes en un enlace (podríamos llamarla dirección "todos los routers de un enlace"). Está definida en el RFC 4291.
Un ejemplo:
Se asigna a un segmento de red el prefijo 2001:db8:1:1::/64
Dentro de ese segmento, el ID 2001:db8:1:1:0:0:0:0 se utiliza como dirección anycast para identificar todos los puertos de routers con direccionamiento global de ese prefijo conectados a ese segmento.
No es lo mismo que la dirección FF02::2, que es la dirección multicast que identifica todos los routers que implementan IPv6, no un prefijo específico, y que sólo puede utilizarse localmente, no globalmente.

Por este motivo, inicialmente el uso de prefijos /127 en enlaces punto a punto no era posible debido al conflicto que se genera con las direcciones subnet-router anycast, lo que llevaba a utilizar prefijos /126.
Sin embargo, el RFC 6164 de abril de 2011 exige que los routers soporten la asignación de /127 en enlaces punto a punto mediante la supresión en los prefijos /127 de as direcciones subnet-router anycast.

Cisco IOS soporta prefijos /127 en enlaces punto a punto.

Conclusión:
Entonces, ¿cuando necesito tener acceso remoto a interfaces punto a punto entre routers, por ejemplo para conectarme por SSH, puedo utilizar direccionamiento global unicast con prefijos /127?
Es una posibilidad, pero no la única. En un próximo post haré una sugerencia para solucionar este requerimiento.

Donde es conveniente utilizar direccionamiento global unicast con prefijos /127 es sin dudas en enlaces punto a punto que conectan dispositivos de borde ente sistemas autónomos. ¿Por qué?

  • Porque de esta manera se simplifica la configuración de vecindades eBGP.
  • Porque las interfaces pueden ser identificadas claramente al diagnosticar una ruta utilizando traceroute.

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.