27 de octubre de 2015

Introducción a ICMPv6

Ya en otras oportunidades, hablando de la arquitectura IPv6, hice referencia a la importancia que adquiere en la operación de IPv6 la versión correspondiente ICMPv6.
Por esto me ha parecido oportuno, y a sugerencia de un grupo de los seguidores de Facebook, realizar una serie de posts en torno al papel que ocupa ICMPv6 en las redes IPv6.
Por eso, en primer lugar, revisemos los aspectos generales del protocolo:

 ICMPv6 es en algunos aspectos semejante a ICMPv4 y en otros incorpora nuevas funcionalidades:
  • ICMPv6 es parte de IPv6.
  • Permite realizar operaciones de diagnóstico y reporte de problemas.
  • Utiliza 2 tipos de mensajes: mensajes de error y mensajes de información.
  • El paquete ICMP es transportado como contenido de un paquete IPv6 convencional con un valor de next header = 58.
  • El paquete ICMPv6 se transporta al final de la cadena de extensiones de encabezado, si la hay, del mismo modo que la información de capa 4.
  • El paquete ICMPv6 tiene 4 campos específicos:
    * El campo tipo identifica el tipo de mensaje ICMP que contiene.
    * El campo código da detalles más específicos sobre el tipo de mensaje que contiene.
    * El campo checksum es el resultado del procesamiento del paquete ICMP completo para que el destino pueda verificar la integridad del paquete que recibe.
    * En el campo datos se envía información que el receptor puede aprovechar para tareas de diagnóstico u operación.
  • ICMPv4 frecuentemente se encuentra bloqueado por políticas de seguridad en redes corporativas como una contramedida de seguridad. ICMPv6 no es diferente, pero tiene la posibilidad de ser asegurado con la implementación de autenticación y encriptación, lo que reduce la posibilidad de un ataque basado en ICMPv6.
Para revisar la variedad de mensajes ICMPv6, en comparación con ICMP en entornos IPv4, sugiero revisar el post "Reconsiderando ICMP".

Bibliografía: Protocolo IPv6 Básico versión 2


No hay comentarios.:

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

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

8 de octubre de 2015

Diseño de subredes en IPv6

Cuando abordamos el diseño de redes IPv6 inevitablemente surge el tema del "cálculo de subredes
IPv6". Durante un tiempo me he resistido a hablar de este tema. Esta resistencia de mi parte tiene un motivo claro: Cuando mencionamos el término "subred" automáticamente todos los que hemos trabajado redes IPv4 pensamos en los mecanismos habituales de cálculo de la máscara de subred en función de cantidad de nodos y cantidad de subredes necesarias e intentamos trasladar esos conceptos al marco del nuevo protocolo. Esto no es aplicable a IPv6. En IPv6 no existe la máscara de subred.
IPv6 es un protocolo diferente de IPv4, una evolución ciertamente, pero una evolución importante que incorpora una multitud de conceptos nuevos que apuntan a resolver las dificultades que ha presentado IPv4 en los últimos30 años:
  • IPv6 incorpora un espacio de direccionamiento más amplio.
    Esto a veces hace pensar en un espacio de direccionamiento inagotable, y si bien no estoy de acuerdo con esa afirmación, no podemos negar que la cantidad de direcciones posibles es claramente muy grande.
  • IPv6 incorpora múltiples tipos de direcciones de unicast que no están presentes en IPv4: link local, unique local y globales.
  • En el diseño mismo de las direcciones globales IPv6 se considera una estructura jerárquica tripartita: red global | red local | nodo.
  • La nomenclatura estándar adoptada para las direcciones utiliza 32 dígitos hexadecimales (cada dígito represente 4 bits) separados en 8 campos de 4 dígitos cada uno.
  • IPv6 incorpora nuevos mecanismos de asignación de configuración y de ID de nodo. Asignación stateless de configuración y autoconfiguración de la porción de nodo.
Un tema importante: los diferentes tipos de direcciones de unicast
En IPv6 hay 3 tipos básicos de direcciones unicast: link local, unique local y globales.
De estos 3 tipos, las que se suelen tomar como referencia son las direcciones globales. Estas direcciones tienen una estructura jerárquica de 3 niveles como ya dije, sin que el RFC indique que cada uno de esos niveles tenga asignada una longitud obligatoria. El único límite son los 128 bits.
Sin embargo, en la implementación concreta del direccionamiento global se recomienda observar algunas prácticas:
  • Al llamado identificador de red global se recomienda asignar un total de 48 a 56bits.
    Sobre esta base, los organismos regionales de asignación de direcciones suelen asignar prefijos de hasta /32 bits a los ISPs (en algunos casos incluso prefijos más cortos) con la recomendación de que se utilicen prefijos /48 o /56 para los clientes corporativos. De esta manera se aseguran que toda la red de un ISP pueda ser sintetizada (sumarizada) en un único prefijo /32 o menor.
  • Por otra parte, se sugiere que el identificador de red local sea un /64, de modo tal que en una red corporativa se pueden utilizar 8 o 16 bits para identificar la red local, permitiendo dividir de esta manera la red corporativa en 256 o 65536 redes internas que se publican como una sola red /56 o /48 hacia el ISP.
  • Finalmente se sugiere que los últimos 64 bits se reserven para el identificador de nodo.

De esta forma, sin necesidad de definir una márcara de subred, la estructura misma de la dirección IP y los mecanismos de asignación de direcciones globales dejan entre 8 y 16 bits para la división interna de la red en subredes o redes locales.

 ¿Por qué dejar 64 bits para el identificador de nodo?
Para quienes estamos acostumbrados a trabajar en la escasez propia de IPv4, utilizar 64 bits para identificar el nodo puede parecer un exceso. Pero debemos recordar que IPv6 no está diseñado a partir de la escasez sino de la funcionalidad y la practicidad.
Entre las funciones nuevas que introduce IPv6 están las direcciones de link local y el proceso de autoconfiguración stateless. En ambos casos se recurre a la generación automática de un identificador de nodo único dentro del segmento sin necesidad de intervención del Administrador al que denominamos autoconfiguración del ID de nodo.
Hay 2 mecanismos definidos con este propósito:
  • EUI-64, que opera a partir de la dirección MAC de la interfaz.
  • ID Privado, que se genera a partir de una variable pseudo random.
En ambos casos el ID de nodo que se genera automáticamente es un ID de 64 bits de longitud. Por este motivo la recomendación es dejar 64 bits para el ID de nodo siempre. Si no lo hiciéramos no se podrían utilizar los procedimientos de autoconfiguración y sería necesario recurrir a la configuración estática de las interfaces o a la implementación obligatoria de DHCPv6.

 ¿Cómo habría que diseñar las subredes entonces?
Si tenemos en cuenta lo dicho hasta aquí, tomemos un ejemplo para hacer el diseño del direccionamiento de redes locales (subredes).
Supongamos el el ISP ALFA ha recibido del organismo regional correspondiente el prefijo

 2001:abcd::/32

 La empresa BETA solicita a nuestro ISP un espacio de direccionamiento global, como consecuencia de lo cual se le asigna el prefijo

 2001:abcd:a1::/48

 Sobre la base de este prefijo, el Administrador de la red necesita definir 8 redes locales o subredes, las que podría hacer de la siguiente manera:

 2001:abcd:a1:0::/64   Gestión de la red
2001:abcd:a1:1::/64   Telefonía
2001:abcd:a1:2::/64   Red inalámbrica interna
2001:abcd:a1:3::/64   Red inalámbrica de visitantes
2001:abcd:a1:4::/64   Ventas
2001:abcd:a1:5::/64   Administración
2001:abcd:a1:6::/64   Gerencia
2001:abcd:a1:7::/64   Operaciones

 De esta manera:
  • Contamos con una red diferente para cada una de las áreas de la empresa.
  • Tenemos la posibilidad de crecer con nuevas redes en la medida en que se requiera, sin que esto signifique una dificultad o requiera rediseño.
  • La Empresa publica una única ruta global hacia el ISP (2001:abcd:a1::/48).
  • El ISP publica una única ruta global hacia Internet (2001:abcd::/32).
  • Internamente se puede implementar autoconfiguración en aquellos dispositivos que no requieran configuración estática o que no soporten o que por política no sea necesario que reciban configuración por DHCPv6.
  • El cuarto campo de la dirección IP identifica claramente la red local a la que pertenece cada IP.
  • No son necesarios cálculos de máscaras de subred de ningún tipo.
Enlaces relacionados


1 comentario: