¿NAT PARA IPV6?

La cuestión del agotamiento del espacio de direcciones IPv4 es una prioridad para el IETF desde principios de la década de los noventa. La combinación de las direcciones IPv4 privadas definidas en RFC 1918 y de NAT cumple un papel decisivo para retrasar este agotamiento. NAT presenta desventajas considerables, y en enero de 2011, la IANA asignó sus últimas direcciones IPv4 a los RIR.

Uno de los beneficios de NAT para IPv4 que no fueron intencionales es que oculta la red privada de Internet pública. NAT tiene la ventaja de que ofrece un nivel de seguridad considerable al denegar el acceso de las computadoras que se encuentran en Internet pública a los hosts internos. Sin embargo, no debe considerarse como un sustituto de la seguridad de red adecuada, como la que proporciona un firewall.

En RFC 5902, el Consejo de Arquitectura de Internet (IAB) incluyó la siguiente cita sobre la traducción de direcciones de red IPv6:

“En general, se cree que una caja NAT proporciona un nivel de protección porque los hosts externos no pueden iniciar directamente una comunicación con los hosts detrás de una NAT. No obstante, no se deben confundir las cajas NAT con los firewalls. Como se analizó en la sección 2.2 de RFC4864, el acto de traducción en sí mismo no proporciona seguridad. La función de filtrado con estado puede proporcionar el mismo nivel de protección sin requerir una función de traducción”.

Con una dirección de 128 bits, IPv6 proporciona 340 sextillones de direcciones. Por lo tanto, el espacio de direcciones no es un problema. IPv6 se desarrolló con la intención de que la NAT para IPv4 con su traducción entre direcciones IPv4 públicas y privadas resulte innecesaria. Sin embargo, IPv6 implementa una forma de NAT. IPv6 incluye su propio espacio de direcciones IPv6 privadas y NAT, que se implementan de manera distinta de como se hace para IPv4.

1.PNG

ESPACIO DE DIRECCIONES IPV4 PRIVADAS

No existen suficientes direcciones IPv4 públicas para asignar una dirección única a cada dispositivo conectado a Internet. Las redes suelen implementarse mediante el uso de direcciones IPv4 privadas, según se definen en RFC 1918. En la figura 1, se muestra el rango de direcciones incluidas en RFC 1918. Es muy probable que la computadora que utiliza para ver este curso tenga asignada una dirección privada.

1

Estas direcciones privadas se utilizan dentro de una organización o un sitio para permitir que los dispositivos se comuniquen localmente. Sin embargo, como estas direcciones no identifican empresas u organizaciones individuales, las direcciones privadas IPv4 no se pueden enrutar a través de Internet. Para permitir que un dispositivo con una dirección IPv4 privada acceda a recursos y dispositivos fuera de la red local, primero se debe traducir la dirección privada a una dirección pública.

Como se muestra en la figura 2, NAT proporciona la traducción de direcciones privadas a direcciones públicas. Esto permite que un dispositivo con una dirección IPv4 privada acceda a recursos fuera de su red privada, como los que se encuentran en Internet. La combinación de NAT con las direcciones IPv4 privadas resultó ser un método útil para preservar las direcciones IPv4 públicas. Se puede compartir una única dirección IPv4 pública entre cientos o incluso miles de dispositivos, cada uno configurado con una dirección IPv4 privada exclusiva.

2.PNG

Sin NAT, el agotamiento del espacio de direcciones IPv4 habría ocurrido mucho antes del año 2000. Sin embargo, NAT presenta algunas limitaciones, las cuales se analizan más adelante en este capítulo. La solución al agotamiento del espacio de direcciones IPv4 y a las limitaciones de NAT es la transición final a IPv6.

EVOLUCIÓN DEL PROTOCOLO DE ROUTING DINÁMICO

Los protocolos de routing dinámico se utilizan en el ámbito de las redes desde finales de la década de los ochenta. Uno de los primeros protocolos de routing fue el RIP. RIPv1 se lanzó en 1988, pero ya en 1969 se utilizaban algunos de los algoritmos básicos en dicho protocolo en la Advanced Research Projects Agency Network (ARPANET).

A medida que las redes evolucionaron y se volvieron más complejas, surgieron nuevos protocolos de routing. El protocolo RIP se actualizó a RIPv2 para hacer lugar al crecimiento en el entorno de red. Sin embargo, RIPv2 aún no se escala a las implementaciones de red de mayor tamaño de la actualidad. Con el objetivo de satisfacer las necesidades de las redes más grandes, se desarrollaron dos protocolos de routing: el protocolo OSPF (abrir primero la ruta más corta) y sistema intermedio a sistema intermedio (IS-IS). Cisco desarrolló el protocolo de routing de gateway interior (IGRP) e IGRP mejorado (EIGRP), que también tiene buena escalabilidad en implementaciones de redes más grandes.

Asimismo, surgió la necesidad de conectar distintas internetworks y proporcionar routing entre ellas. En la actualidad, se utiliza el protocolo de gateway fronterizo (BGP) entre proveedores de servicios de Internet (ISP). El protocolo BGP también se utiliza entre los ISP y sus clientes privados más grandes para intercambiar información de routing.

Con la llegada de numerosos dispositivos que usan IP para consumidores, el espacio de direccionamiento IPv4 quedó prácticamente agotado, por lo que surgió IPv6. A fin de admitir la comunicación basada en IPv6, se desarrollaron versiones más nuevas de los protocolos de routing IP, como se muestra en la fila de IPv6 en la Figura.

1.PNG

VERIFICACIÓN DE UNA RUTA ESTÁTICA

Además de ping y traceroute, los comandos útiles para verificar las rutas estáticas incluyen:

  • show ip route
  • show ip route static
  • show ip route red

En la figura 1, se muestra un ejemplo del resultado que genera el comando show ip route static. En el ejemplo, el resultado se filtra con la barra vertical y el parámetro begin. El resultado refleja el uso de rutas estáticas con la dirección del siguiente salto.

1.PNG

En la figura 2, se muestra un ejemplo del resultado del comando show ip route 192.168.2.1.

2.PNG

En la figura 3, se verifica la configuración de ip route en la configuración en ejecución.

3.PNG

CONFIGURACIÓN DE UNA INTERFAZ DE ROUTER IPV6

La configuración de una interfaz IPv6 es similar a la configuración de una interfaz para IPv4. La mayoría de los comandos de configuración y verificación de IPv6 del IOS de Cisco son muy similares a sus equivalentes de IPv4. En la mayoría de los casos, la única diferencia es el uso de ipv6 en lugar de ip en los comandos.

Se debe realizar lo siguiente con la interfaz IPv6:

  • Configurarla con la dirección IPv6 y la máscara de subred: utilice la dirección ipv6 dirección-ipv6/longitud-prefijo Comando de configuración de interfaz [link-local | eui-64].
  • Activar la interfaz: la interfaz se debe activar mediante el comando no shutdown.

A diferencia de IPv4, las interfaces IPv6 generalmente tienen más de una dirección IPv6. Como mínimo, los dispositivos IPv6 deben tener una dirección link-local de IPv6, pero también es muy probable que tengan una dirección de unidifusión global de IPv6. IPv6 también admite la capacidad de que una interfaz tenga varias direcciones de unidifusión global de IPv6 de la misma subred. Los siguientes comandos se pueden usar para crear, de forma estática, una dirección de unidifusión global o link-local de IPv6:

  • ipv6 address dirección-ipv6/longitud-prefijo : crea una dirección de unidifusión global de IPv6 según lo especificado.
  • ipv6 address dirección-ipv6/longitud-prefijo eui-64: configura una dirección de unidifusión global de IPv6 con un identificador de interfaz (ID) en los 64 bits de bajo orden de la dirección IPv6 mediante el proceso EUI-64.
  • ipv6 address dirección-ipv6/longitud-prefijo link-local: configura una dirección link-local estática en la interfaz que se usa en lugar de la dirección link-local que se configura automáticamente cuando se asigna la dirección de unidifusión global de IPv6 a la interfaz, o cuando se habilita con el comando de interfaz ipv6 enable. Recuerde que el comando de interfaz ipv6 enable se usa para crear de forma automática una dirección link-local de IPv6, así se haya asignado una dirección de unidifusión global de IPv6 o no.

En la topología de ejemplo que se muestra en la figura 1, el R1 se debe configurar para que admita las siguientes direcciones de red IPv6:

  • 2001:0DB8:ACAD:0001:/64 o, de manera equivalente, 2001:DB8:ACAD:1::/64
  • 2001:0DB8:ACAD:0002:/64 o, de manera equivalente, 2001:DB8:ACAD:2::/64
  • 2001:0DB8:ACAD:0003:/64 o, de manera equivalente, 2001:DB8:ACAD:3::/64

1.PNG

Cuando el router se configura con el comando de configuración global ipv6 unicast-routing, el router comienza a enviar mensajes de anuncio de router ICMPv6 por la interfaz. Esto permite que una computadora que está conectada a la interfaz configure una dirección IPv6 y establezca un gateway predeterminado de forma automática, sin necesidad de utilizar los servicios de un servidor de DHCPv6. Por otra parte, una computadora conectada a la red IPv6 puede tener la dirección IPv6 configurada manualmente, como se muestra en la Figura 2. Observe que la dirección de gateway predeterminado configurada para la PC1 es la dirección de unidifusión global de IPv6 de la interfaz GigabitEthernet 0/0 del R1.

2.PNG

Las interfaces del router en la topología de ejemplo se deben configurar y habilitar como se muestra en las figuras 3 a 5.

345

TRACEROUTE: PRUEBA DE LA RUTA

El comando ping se usa para probar la conectividad entre dos hosts, pero no proporciona información sobre los detalles de los dispositivos entre los hosts. Traceroute (tracert) es una utilidad que genera una lista de saltos que se alcanzaron correctamente a lo largo de la ruta. Esta lista puede proporcionar información importante sobre la verificación y la solución de problemas. Si los datos llegan al destino, el rastreo indica la interfaz de cada router que aparece en la ruta entre los hosts. Si los datos fallan en algún salto a lo largo del camino, la dirección del último router que respondió al rastreo puede indicar dónde se encuentra el problema o las restricciones de seguridad.

Tiempo de ida y vuelta (RTT)

El uso de traceroute proporciona el tiempo de ida y vuelta para cada salto a lo largo de la ruta e indica si un salto no responde. El tiempo de ida y vuelta es el tiempo que le lleva a un paquete llegar al módulo remoto de E/S y el tiempo que la respuesta del host demora en regresar. Se utiliza un asterisco (*) para indicar un paquete perdido o sin respuesta.

Esta información se puede utilizar para ubicar un router problemático en la ruta. Si en la pantalla se muestran tiempos de respuesta elevados o pérdidas de datos de un salto en particular, esto constituye un indicio de que los recursos del router o sus conexiones pueden estar sobrecargados.

TTL de IPv4 y límite de saltos de IPv6

Traceroute utiliza una función del campo TTL en IPv4 y del campo límite de saltos de IPv6 en los encabezados de capa 3, junto con el mensaje de tiempo superado de ICMP.

La primera secuencia de mensajes enviados desde traceroute tiene un valor de 1 en el campo TTL. Esto hace que el TTL agote el tiempo de espera del paquete IPv4 en el primer router. Este router luego responde con un mensaje de ICMPv4. Traceroute ahora tiene la dirección del primer salto.

A continuación, Traceroute incrementa progresivamente el campo TTL (2, 3, 4…) para cada secuencia de mensajes. De esta manera se proporciona al rastreo la dirección de cada salto a medida que los paquetes agotan el límite de tiempo a lo largo del camino. El campo TTL sigue aumentando hasta que se alcanza el destino, o se incrementa a un máximo predefinido.

Después de alcanzar el destino final, el host responde con un mensaje ICMP de puerto inalcanzable o con un mensaje ICMP de respuesta de eco en lugar del mensaje ICMP de tiempo superado.

PING: PRUEBA DE LA CONECTIVIDAD A LA LAN LOCAL

También es posible utilizar el comando ping para probar la capacidad de comunicación de un host en la red local. Por lo general, esto se realiza haciendo ping a la dirección IP del gateway del host. Un ping al gateway indica que la interfaz del host y la interfaz del router que cumplen la función de gateway funcionan en la red local.

Para esta prueba, se suele usar la dirección de gateway porque el router generalmente está en funcionamiento. Si la dirección de gateway no responde, se puede enviar un ping a la dirección IP de otro host en la red local que se sepa que funciona.

Si el gateway u otro host responden, los hosts locales pueden comunicarse correctamente en la red local. Si el gateway no responde pero otro host sí lo hace, esto podría indicar un problema con la interfaz de router que sirve como gateway.

Una posibilidad es que se haya configurado la dirección de gateway incorrecta en el host. Otra posibilidad es que la interfaz del router puede estar en funcionamiento, pero se le ha aplicado seguridad, de manera que no procesa o responde solicitudes de ping.

1.PNG