IPv6 Mobility - Conceptos básicos

En la actualidad IP mobility es la única solución para mantener la conectividad en dispositivos que transitan a través de múltiples redes de acceso, que por ejemplo pasar de la red 4G a la red inalámbrica (802.11) y de allí a la red cableada. 
En estos casos, y para que esto sea posible, los dispositivos terminales debieran estar siempre accesibles con su dirección IP inicial. Esto requiere que el terminal pueda pasar de una red de acceso a otra de modo transparente, manteniendo su conexión. Debe ser transparente tanto para el usuario que se desplaza con su dispositivo móvil como para los dispositivos con los que se está comunicando.
IP Mobility se basa en un conjunto de conceptos específicos:

Home network.
Red en la cual se conecta inicialmente el nodo móvil y en la cual recibe una dirección IP que lo identifica.
La dirección IP del nodo móvil es una IP correspondiente al segmento IP de la home network.

Home agent.
Gateway (router) a través del cual el nodo móvil mantiene su comunicación activa cuando se encuentra en otros segmentos de red que no son su red inicial.
Es el default gateway original del nodo móvil y representa al mobile node en el home link cuando se ha desplazado. Por esto, responde los requerimientos de DAD y los mensajes network solicitation que se hacen a la home address del nodo móvil.
En él se registra el nodo móvil con su care-of address cuando se desplaza hacia el foreign link.
Mientras el nodo móvil esté fuera de su home link el home agent intercepta el tráfico que tiene como destino la home address del nodo móvil y lo coloca en un túnel que tiene como destino la care-of address correspondiente.

Mobile node.
Dispositivo identificado con una dirección IPv6 que se desplaza desde la home network hacia otros segmentos de red manteniendo su identidad IP original.
Cuando el nodo móvil se desplaza, cambia su localización pero no cambia su identidad. En función de esto el mobile node se registra con su home agent desde su nueva localización para que el home agent genere un túnel hasta el modo móvil para enviarle los paquetes que están dirigidos a su home link.

Home link.
Prefijo que identifica el enlace inicial sobre el cual se establece conectividad entre el nodo móvil y el home agent.
Todo el tráfico que tiene como destino el nodo móvil es enrutado a través de Internet hacia este home link.

Foreign link.
Segmento de red diferente al home link, al cual se ha desplazado el nodo móvil.

Home address.
Dirección unicast ruteable asignada al nodo móvil y utilizada como dirección permanente de ese nodo. Es una dirección perteneciente al segmento del home link.
Un dispositivo móvil puede contar con múltiples home address.

Care-of address.
Dirección de unicast ruteable asociada con el nodo móvil mientras se encuentra en el foreign link.
Si bien es posible que un nodo móvil reciba varias CoA en el foreign link, en el home agent se registrará una de esas direcciones como asociada a la home address, y recibe el nombre de CoA primaria.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
 el Glosario de Siglas y Términos de Networking
que está disponible en la Librería en Línea de EduBooks.

Estado actual de la implementación de IPv6

Estado de la Implementación de IPv6 v3.0 from Educática

Glosario de Siglas y Términos versión 1.

Hace ya mucho tiempo, cuando publiqué mi primer manual, me pareció necesario agregarle un glosario de siglas o abreviaturas que permitiera comprender el significado de cada una de ellas. Nuevos manuales, sobre nuevos temas han requerido la incorporación de cada vez nuevas siglas, algunas de ellas más o menos específicas. De allí que con el paso de los años he recopilado una cantidad importante de ellas.

Cada manual ha supuesto hasta aquí un glosario específico. Pero también es cierto que al limitarlo a las siglas que utilizo en el texto se limita muchas veces la respuesta que doy a la necesidad del lector ya que muchas veces el estudio personal lleva a quien estudia a incorporar nuevas siglas y con ello el requerimiento de conocer su significado.

Por esto he decidido no generar ya un glosario para cada manual por separado sino concentrar toda la información recopilada hasta el momento en un único volumen que por acuerdo con EduBooks ponemos como de libre acceso a partir del día de hoy.

En este glosario encontrará el significado de todas las siglas que utilizo en mis manuales, ordenadas alfabéticamente,  desarrolladas en su idioma original y cuando existe o es de uso habitual, en su traducción al castellano.

Glosario de Siglas y Términos de Networking versión 1.0 by Edubooks Ediciones

Esté utilizando o no uno de los manuales desarrollados por mí, espero que la información que encontrará en esta publicación le resulte de utilidad.

Implementación de IPv6: Dual Stack

Quizás, la estrategia preferida para la transición hacia las arquitecturas IPv6 es dual-stack: cada nodo opera simultáneamente con IPv4 e IPv6. Esto permite una transición progresiva uno a uno manteniendo la operación de la red y permitiendo administrar las transiciones.
Es particularmente útil sobre todo porque algunas aplicaciones requieren ser modificadas para operar sobre IPv6 y de esta manera al mantener ambos stacks operativos las aplicaciones viejas o que aún están pendientes de ser actualizadas pueden seguir operando sin dificultades, mientras que las aplicaciones nuevas o actualizadas comienzan a operar preferentemente sobre IPv6.

Hay disponible una API (Application Programming Interface) que soporta requerimientos DNS para IPv4 e IPv6 y permite responder a diferentes situaciones:

• Una aplicación que no soporta IPv6 o está forzada a utilizar IPv4, hace una solicitud DNS de un registro tipo A para IPv4.
  En consecuencia la aplicación enviará su solicitud de servicio utilizando IPv4 como protocolo de transporte. El servidor DNS responderá enviando exclusivamente la dirección IPv4 correspondiente al nombre que se consulta.
• Una aplicación que soporta solamente IPv6 o prefiere utilizar IPv6 operará sobre IPv6.
  La aplicación envía una solicitud exclusivamente de un registro AAAA con lo que obtendrá una dirección IPv6.
  En consecuencia la aplicación establecerá la conexión con el servidor utilizando IPv6 como protocolo de transporte en capa de red.
  Esto también se aplica cuando el dispositivo solamente tiene una dirección IPv6 configurada.
• Una aplicación que puede operar indistintamente con IPv4 o IPv6. Para cada nombre que debe resolver se envía una solicitud DNS que requiere los registros de ambos versiones de direcciones (IPv4 e IPv6).
  El servidor DNS responde enviando todas las direcciones IP disponibles (v4 y/o v6) que están asociadas a ese nombre.
  Ya con la información de ambos protocolos, es la aplicación la que elije utilizar una u otra. El comportamiento propuesto por defecto (RFC 3484) es utilizar la dirección IPv6, y por lo tanto operar con paquetes IPv6. Este comportamiento debiera ser posible de modificar a nivel del nodo.

Cisco IOS soporta la operación en modo dual-stack tan pronto como ambos protocolos están configurados en una interfaz. A partir de ese punto puede reenviar ambos tipos de tráfico.
Eso puede realizarse tanto cuando se asignan direcciones estáticas o por un proceso de configuración dinámica o de autoconfiguración.

Enlaces relacionados

• Post: IPv6 llegó para quedarse
• Post: ¿Estás preparado para IPv6?
• Video: ¿Estás preparado para IPv6?
• Presentación: Introducción al Direccionamiento IPv6
• Presentación: IPv6 en la certificación CCNA R&S
• Bibliografía: Protocolo IPv6 Básico versión 2

ICMPv6 en redes IPv6

¿Por qué insisto tanto en la importancia de ICMPv6 en las redes IPv6?
Básicamente porque hay una cantidad significativa de procedimientos esenciales para la operación de la red que dependen del intercambio de mensajes ICMPv6.
¿Cuáles son esos procedimientos?

Path MTU Discovery (PMTUD)
Una de las innovaciones que introduce ICMPv6 es el reemplazo del procedimiento de fragmentación de paquetes IPv4 por el descubrimiento del MTU de la ruta.
Para realizar este descubrimiento el dispositivo origen de la comunicación genera paquetes utilizando el MTU de su interfaz y si en la ruta hay un enlace con un MTU menor el dispositivo correspondiente le responde con un mensaje ICMPv6 Tipo 2 (packet too big) que incluye el MTU del enlace que causa el descarte de modo tal que la terminal de origen pueda ajustar su MTU al menor MTU de la ruta.
El filtrado de este tipo de mensajes ICMPv6 imposibilita la negociación y potencialmente podría dificultar la operación de aplicaciones sobre rutas que tienen MTUs limitados.
Una posibilidad es activar, cuando es posible, la opción "Guaranteed Not To Be Too Big" que genera paquetes de la longitud mínima soportada por IPv6: 1280 bytes. De este modo no se requiere PMTUD.

Neighbor Discovery (ND)
En redes IPv6 no hay operación de ARP. El descubrimiento de la dirección MAC de las terminales destino, junto a otras operaciones que optimizan la operación de la red ha sido incorporado en el procedimiento para descubrimiento de vecino.
Este procedimiento le permite a una terminal IPv6:

• Obtener la dirección de capa de enlace de un vecino.
• Encontrar los routers presentes en el segmento.
• Detectar vecinos IPv6.
• Desarrollar tareas de renumeración.

Con este propósito se utiliza un conjunto de mensajes ICMPv6:

• Tipo 133 - Router solicitation.
• Tipo 134 - Router advertisement.
• Tipo 135 - Neighbor solicitation.
• Tipo 136 - Neighbor advertisement.
• Tipo 137 - Redirect message.

El procedimiento de descubrimiento de vecinos es esencial para el proceso de elaboración de la comunicación extremo a extremo y se asienta en la utilización de direcciones multicast específicas que reciben la denominación de “solicited-node”.
Estos procesos se corren exclusivamente dentro del segmento de red local (las direcciones solicited-node son multicast de alcance local, no ruteable), por lo que su utilización es crítica solamente en la red local.

Autoconfiguración stateless
El proceso de autoconfiguración stateless es una de las características propias de IPv6 que permite la autoconfiguración IP de los puertos sin necesidad de la presencia de un servidor en la red. Este procedimiento también está basado en la operación de ICMPv6.
Los routers utilizan paquetes ICMPv6 Tipo 134 (Router Advertisement) para anunciar su presencia y los prefijos de red que están disponibles sobre el segmento. Los terminales utilizan estos mensajes para aprender prefijos /64 (tanto globales como locales) y luego derivar automáticamente el ID de nodo de 64 bits para completar la dirección que utilizará el puerto.
Por otra parte los terminales al inicializar su placa de red envían mensajes ICMPv6 Tipo 133 (Router Solicitation) para solicitar información de configuración de algún router disponible en el segmento de red.
Este proceso está diseñado para posibilitar la implementación de IPv6 en redes en las que no hay acceso a un servicio DHCPv6 y están compuestas por nodos  tipo thin clients con pocos recursos de memoria y procesamiento.

Por ser una función básica de IPv6, no requiere recursos adicionales en los nodos y permite la implementación masiva de nodos con configuración IPv6 automática.

Duplicated Address Detection (DAD)
Procedimiento que utiliza paquetes ICMPv6 Tipo 135 (Neighbor Solicitation) durante los procesos de autoconfiguración para verificar si otro nodo en la red ya está utilizando la dirección IPv6 que ha definido utilizar antes de hacerla operativa. 
Este procedimiento se utiliza en los procesos de autoconfiguración para asegurar que se utilicen IDs de nodo únicos en el segmento de red. Su alcance es exclusivamente el segmento de red local.

Neighbor Redirect
Mensajes utilizados en segmentos de red que cuentan con más un de gateway que son enviados por un router gateway a la terminal  origen de tráfico destinado a una red remota que tiene una mejor ruta accesible a través de otro router presente en el mismo segmento. 
Para esto el gateway envía mensajes ICMPv6 tipo 137 (Redirect) con el propósito de redirigir los paquetes IPv6 a otro router en el mismo segmento que tiene una mejor ruta de salida.
Como ocurre en el caso de IPv4, esta funcionalidad de redireccionamiento puede poner en riesgo la seguridad de la red por lo que se aconseja desactivarla.

Renumeración
La implementación de mensajes ICMPv6 Tipo 134 (Router Advertisement) permite desarrollar de modo automático procesos de renumeración de los segmentos IPv6 que aplican autoconfiguración stateless ya que permiten anunciar 2 prefijos para el mismo segmento, uno que se denomina válido y otro preferido.
Acotando el período de validez del prefijo que se debe abandonar el segmento progresivamente migra hacia el prefijo preferido.

Mensajes de echo
Como ocurre en redes IPv4, Ping es un programa también disponible en arquitecturas IPv6 que utiliza paquetes ICMPv6.
En este caso se trata de paquetes ICMPv6 Tipo 128 (Echo Request) y Tipo 129 (Echo Reply).

Enlaces de referencia

• Para revisar los diferentes tipos de mensajes ICMP
• Introducción a ICMPv6
• Bibliografía: Protocolo IPv6 Básico versión 2

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

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:

• El aprovechamiento de las direcciones de link local.
• La implementación de direccionamiento global con prefijos IPv6 /127.

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:

• Post: Diseño de subredes en IPv6
• Post: Direccionamiento IPv6 en enlaces punto a punto (1)
• Post: Tipos de direcciones IPv6
• Post: Direcciones IPv6 link local
• Post: IPv6 llegó para quedarse
• Post: ¿Estás preparado para IPv6?
• Video: ¿Estás preparado para IPv6?
• RFC 6164: Using 127-bit IPv6 prefixes on inter-router links.
• Bibliografía: Protocolo IPv6 Básico versión 2

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:

• Post: Diseño de subredes en IPv6
• Post: Tipos de direcciones IPv6
• Post: Direcciones IPv6 link local
• Post: IPv6 llegó para quedarse
• Post: ¿Estás preparado para IPv6?
• Video: ¿Estás preparado para IPv6?
• RFC 6164: Using 127-bit IPv6 prefixes on inter-router links.
• Bibliografía: Protocolo IPv6 Básico versión 2

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

• Post: Tipos de direcciones IPv6
• Post: Direcciones IPv6 link local
• Post: IPv6 llegó para quedarse
• Post: ¿Estás preparado para IPv6?
• Post: Direccionamiento IPv6 en enlaces punto a punto (1)
• Video: ¿Estás preparado para IPv6?
• Presentación: Introducción al Direccionamiento IPv6
• Presentación: IPv6 en la certificación CCNA R&S
• Bibliografía: Protocolo IPv6 Básico versión 2

Apunte Rápido ROUTE v5.1

Hace ya 10 años que comencé con la publicación de manuales de estudio en temas de networking. Finalmente he logrado iniciar la publicación de una serie de manuales dedicados específicamente a los exámenes de certificación que se requieren para completar la certificación CCNP R&S y la certificación CCDP.
Continuando una línea de trabajo que ya tiene su trayectoria propia, la de los Apuntes Rápidos, pongo ahora a disposición de quienes están preparando su examen el Apunte Rápido ROUTE 300-101 versión 5.1.
Si lo que estás necesitando es un manual sintético, semejante a los que ya publiqué para CCNA R&S, que abarque la totalidad del temario del examen de certificación de modo directo y simple, en castellano, este es el manual indicado.

El Apunte Rápido desarrolla de modo sintético la totalidad del temario del examen de certificación. En este caso particular he incluido en un anexo aparte (porque en realidad no es parte del temario del examen) un breve desarrollo sobre el protocolo IS-IS. Si bien IS-IS no es parte del temario del examen de certificación es un protocolo de enrutamiento que tiene importancia creciente en algunos entornos específicos y por lo tanto me pareció útil incluirlo como un apartado al final del manual.
En este manual se encuentran todos los contenidos necesarios para completar la preparación del examen de certificación.
Si eres un alumno de Academia o de Learning Partner, es posible que este manual te sea suficiente y al momento de estudiar utilices los materiales oficiales que recibiste durante tu cursada para aclarar dudas o buscar referencias necesarias.
Para quienes estudian por sí mismo (auto-estudio), este manual les sirve como referencia de base y deberán complementarlo con investigación personal.
Como es propio de los Apuntes Rápidos que desarrollo, no incluye herramientas pedagógicas (que son propias de las Guías de Preparación para el Examen), tales como mapas conceptuales, resúmenes, notas, cuestionarios, anexos de ejercicios, etc. Por el momento no tengo prevista la publicación de una guía de preparación para estos exámenes sino que el plan es continuar con el Apunte Rápido SWITCH.

Fecha de publicación: 21 de septiembre de 2015
Autor: Oscar A. Gerometta
CCSI / CCNA R&S / CCDA / CCNAwir / CCNA sec. / CCBF.
Creador –en el año 2000- del primer curso de apoyo para alumnos de Cisco Networking 
Academy program que se preparan a rendir su examen de certificación CCNA, logrando entre sus alumnos un nivel de aprobación superior al 95%.

Texto:
Se trata de una síntesis de los contenidos de estudio comprendidos en el nuevo examen de certificación ROUTE 300-101.
Está alineado al examen CCNP ROUTE 300-101. 

Para ver una demo de este manual, ingrese aquí.

Contenidos:

• El examen de certificación ROUTE.
• Conceptos básicos de enrutamiento IP.
• Implementación de RIPng.
• Implementación de EIGRP.
• Implementación de OSPF.
• Redistribución de rutas.
• Implementación de control de rutas.
• BGP - Conexión corporativa a Internet.
• Protección de routers y protocolos de enrutamiento.
• Anexo 1: Glosario de siglas.
• Anexo 2: Protocolo IS-IS.

Cantidad de páginas: 265

Algunas notas sobre esta versión:

• Cubre la totalidad del temario.
• Incluye enrutamiento IPv6.
• Se incluye tanto la configuración de OSPFv3 como Named EIGRP.
• IS-IS no es parte del temario del examen, ha sido incluido solo como información complementaria.
• Por tratarse de un Apunte Rápido no incluye laboratorios.

Para la compra: 
Apunte Rápido ROUTE 300-101 versión 5.1 en formato e-book ya se encuentra disponible, y se puede comprar en línea ingresando aquí.
Para consultas de precios o compras en formato impreso, diríjase directamente a Ediciones EduBooks por correo electrónico escribiendo  a libros.networking@gmail.com

Como siempre, cualquier sugerencia que puedas hacer, será muy bienvenida.

Características de los ebooks

• El formato ebook empleado sólo funciona sobre sistemas operativos Microsoft (Windows).
• Sólo se admite PayPal como forma de pago (consulte con la Editorial por otras formas de pago).
• Dispone de 5 días a partir del momento de la compra para descargar el ebook.
• Para poder ver la obra completa debe ingresar la clave de activación que recibirá por correo electrónico.
• Una vez realizada la compra recibirá un correo electrónico con indicaciones detalladas para que pueda realizar la activación.
• La clave de activación le permite activar su ebook en 1 terminal, y sólo puede ser leído desde esa terminal.
• Ud. puede solicitar la activación de una segunda copia en un dispositivo auxiliar (p.e. su notebook), solicitándolo por correo electrónico a libros.networking@gmail.com.
• En la terminal deberá tener instalada la aplicación Adobe Reader X versión 10.1.4.

Enlaces de interés:

• Información oficial sobre el examen de certificación.
• Demo en línea del manual.
• Biblioteca CCNP.

Actualizando nuestro conocimiento sobre estándares IEEE 802.11

Hace un tiempo ya, en el año 2007, publiqué un resumen de los diferentes estándares de redes inalámbricas IEEE 802.11 de mayor uso. Pasó mucho tiempo y se han introducido muchas novedades, por lo que me pareció conveniente hacer una actualización de esa publicación, orientada especialmente a revisar los puntos salientes de cada uno de los estándares de transmisión en capa física que son los de mayor impacto en el día a día de las redes inalámbricas.

Estándares actualmente disponibles

• IEEE 802.11bFecha de ratificación: 1999.
  Banda: 2,4 GHz.
  Ancho del canal: 22 Mhz.
  Tasa de transferencia que ofrece: Hasta 11 Mbps.
  Throughput máxim posibleo: 6 Mbps.
  Utiliza SISO con DSSS (Direct Sequence Spread Spectrum)
• IEEE 802.11aFecha de ratificación: 1999.
  Banda: 5 GHz.
  Ancho del canal: 20 Mhz.
  Tasa de transferencia que ofrece: Hasta 54 Mbps.
  Throughput máximo posible: 28 Mbps.
  Utiliza SISO con OFDM (Orthogonal Frecuency Division Multiplexing)
• IEEE 802.11gFecha de ratificación: 2003.
  Banda: 2,4 GHz.
  Ancho del canal: 22 Mhz.
  Tasa de transferencia que ofrece: Hasta 54 Mbps
  Throughput máximo posible: 27 Mbps
  Permite compatibilidad con 802.11b
  Utiliza SISO con OFDM.
• IEEE 802.11 n
  Fecha de ratificación: 2009.
  Banda: 2,4 y 5 GHz.
  Ancho del canal: 20 o 40 Mhz.
  Tasa de transferencia que ofrece: Hasta 600 Mbps. La mayor parte de los productos comerciales disponibles alcanzan hasta 300 Mbps y en algunos casos 450 Mbps.
  Throughput máximo posible en productos comerciales de 300 Mbps: 220 Mbps.
  Permite compatibilidad con 802.11 b y g en 2,4 GHz.
  Permite compatibilidad con 802.11 a en 5 GHz.
  Utiliza MIMO (hasta 4 cadenas) con OFDM.
• IEEE 802.11ac
  Fecha de ratificación: 2013.
  Banda: 5 GHz.
  Ancho del canal: 20, 40, 80 o 160 Mhz.
  Tasa de transferencia que ofrece: Hasta 6,7 Gbps. Los productos comerciales disponibles de primera ola pueden alcanzar una tasa de hasta 1,3 Mbps.
  Permite compatibilidad con 802.11 a y n.
  Los productos comerciales disponibles son de radio dual, por lo que pueden operar con clientes 802.11a, b, g, n y ac.
  Utiliza MU-MIMO (hasta 8 cadenas) con OFDM.

Estándares emergentes

• IEEE 802.11ad
  Fecha de ratificación: 2012.
  Banda: 60 GHz.
  Ancho del canal: 2,16 GHz.
  Tasa de transferencia que ofrece: Hasta 6,75 Gbps.
  Utiliza SISO con OFDM.
  Es promovido por la Wireless Wigabit Alliance (WiGig)
  Diseñado para posibilitar comunicaciones que requieren tasas de transmisión muy altas (como el video de alta definición) en distancias relativamente cortas.
• IEEE 802.11ah
  Fecha de ratificación estimada: 2016.
  Banda: 900 Mhz.
  Ancho de canal: 1, 2, 4, 8 o 16 MHz.
  Throughput: 100 Kbps a 40 Mbps.
  Diseñado para soportar comunicaciones que requieren tasas de transferencia bajas en conexiones de distancias más largas que las de los estándares actualmente en uso( hasta 1000 metros). Está diseñada para el despliegue de conectividad inalámbrica a sensores con requerimiento de bajo consumo de energía.
• IEEE 802.11af
  Fecha de ratificación: 2014.
  Banda: entre 54 y 790 MHz.
  Ancho del canal: 6, 7 u  8 MHz. Consolida hasta 4 canales.
  Tasa de transferencia que ofrece: Hasta 568,9 Mbps.
  Utiliza MU-MIMO (hasta 4 cadenas) con OFDM.
  Radio de cobertura, hasta 1000 metros.
  Aprovecha canales no utilizados de TV para transmisiones de dato con rangos de cobertura mucho mayores que los de las redes inalámbricas 802.11 tradicionales. Se considera una tecnología adecuada para dar conectividad en despliegues de sensores.

Buenas prácticas en la gestión de la red

Un tema recurrente en la gestión (management) de la red es el de las buenas practicas, mejores prácticas o best practices.
En este sentido hay diferentes tipos de recomendaciones de este tipo: buenas prácticas de seguridad, buenas prácticas de configuración, buenas prácticas de gestión, etc.
A solicitud de uno de los miembros del grupo de Facebook, junto con varios miembros hemos confeccionado la lista que presento a continuación. Es preciso tener presente que para este post he mantenido solamente prácticas relacionadas con el acceso y gestión del plano de management de los dispositivos. En futuras entregas veremos de ir generando listas semejantes para otras implementaciones.

Han colaborado en esta lista: Luis Miguel Zavaleta Leiva, Raffic Vera Constante, Eduardo Mendez, Moisés Morales, Gonzalo Hernán Aguilera Gatica y Augusto Iparraguirre Torrau. Muchas gracias a todos.

• Habilitar exclusivamente acceso remoto utilizando SSH (bloquear el Telnet).
• Si se van a utilizar interfaces gráficas aplicar HTTPS (bloquear HTTP).
• Definir una VLAN de gestión y autorizar solamente a dispositivos conectados a esa VLAN el acceso al plano de gestión aplicando ACLs con una política restrictiva.
• Implementar AAA para realizar autenticación, autorización y accounting en el acceso a los dispositivos.
• Si se va a implementar SNMP (tanto sea para monitoreo como para configuración) utilizar SNMP v3 con autenticación y cifrado.
• Implementar un servidor NTP interno y utilizarlo como fuente de sincronización del reloj de todos los dispositivos y sistemas.
• Implementar un servidor de Syslog para utilizarlo como repositorio de los registros de eventos los dispositivos de la red.
• Mantener actualizado el sistema operativo de los dispositivos de la red que lo permitan.
• Implementar un servidor FTP con control de acceso para mantener copias de respaldo actualizadas de configuraciones e imágenes de sistemas operativos.
• Mantener información detallada y actualizada de la red, restringiendo a personal autorizado el acceso a esa documentación.
• Mantener un inventario actualizado de hardware y software de la infraestructura.
• Mantener documentación actualizada de los procedimientos y acciones concernientes a los planes de contingencia y continuidad del negocio en lo que respecta al área de networking.

El virtual link en OSPF

OSPF es un protocolo de estado de enlace que aplica un esquema jerárquico de red en el que el área 0 es el área de backbone que interconecta todas las áreas no backbone.
Cada área debe tener continuidad física, y uno de los desafíos en redes que tienen gran extensión geográfico puede ser mantener la continuidad del área 0.
Para estos casos (u otros semejantes) en los que el esquema jerárquico de OSPF se ve afectado por la falta de continuidad física de un área, la implementación de enlaces virtuales (virtual links) permite dar continuidad a las áreas de modo transitorio.
Cisco insiste especialmente en que esta es una solución transitoria y no permanente, y que el problema debiera ser luego resuelto a partir del rediseño de la red.
En estos casos:

• El área a través de la cual se constituye el enlace virtual se denomina área de tránsito.

• La posibilidad de enlaces virtuales está contemplada en el estándar.

• Permiten solucionar discontinuidades temporales en una red. No deben ser una solución permanente.

• Opera como una adyacencia estándar OSPF, pero no requiere que estén directamente conectados.

• El protocolo hello intercambia paquetes cada 10 segundos sobre el enlace.

• Los LSAs aprendidos sobre enlaces virtuales utilizan la configuración DNA (DoNotAge) para prevenir tráfico excesivo.

Configuración:

Router(config)#router ospf [process id]

Router(config-router)#area [ID área de tránsito] virtual-link [router ID]