3. Navegando IPv6

Acceso desde una LAN IPv6 a Google y YouTube

El escenario es similar al que planteamos en el capítulo anterior.

Un equipo con IPv6 abre un navegador y accede a dos páginas: www.google.com y www.youtube.com.

En este capítulo se utiliza IPv6.

Una computadora posee, por ejemplo, la dirección global: 2001:db8:100:1::20/64

y su router tiene en la interfaz LAN: 2001:db8:100:1::1/64

La interfaz WAN del router pertenece a otra red IPv6, por ejemplo: 2001:db8:200:10::1/64

A diferencia del caso IPv4 anterior, la dirección del host : 2001:db8:100:1::20 es una dirección IPv6 globalmente enrutable. Por lo tanto, el router no necesita reemplazarla por su propia dirección , aqui en principio NO sería necesario hacer NAT, al menos no por cuestiones de modificar la dirección privada, que  NO existe.

Supongamos nuevamente que el usuario abre dos pestañas del navegador:

  • www.google.com
  • www.youtube.com

Luego de realizar la resolución DNS,  supongamos que obtiene, de manera ilustrativa:

  • www.google.com → 2001:db8:300::100
  • www.youtube.com → 2001:db8:400::200

El sistema operativo crea conexiones independientes utilizando puertos efímeros, 5100 para Google y 51501 para Yotube.

Para Google:  [2001:db8:100:1::20]:51500 → [2001:db8:300::100]:443

Para YouTube: [2001:db8:100:1::20]:51501 → [2001:db8:400::200]:443

Nota: ver que esto sería una 4-tupla.

Los corchetes son una convención habitual cuando se representa una dirección IPv6 junto con un número de puerto, ya que la propia dirección IPv6 contiene el carácter :.

Los sockets siguen existiendo 

El concepto de socket no cambia por utilizar IPv6,  Para la conexión con Google tenemos:

Socket cliente: [2001:db8:100:1::20]:51500 el socket de cada endpoint

Socket servidor de Google : [2001:db8:300::100]:443 el socket de cada endpoint

Y la conexión TCP puede identificarse mediante la correspondiente 4-tupla (dos  end point) :

  1. 2001:db8:100:1::20
  2. 51500
  3. 2001:db8:300::100 
  4. 443

Para el caso de YouTube:

Socket cliente:

[2001:db8:100:1::20]:51501

Socket servidor:

[2001:db8:400::200]:443

La utilización de puertos efímeros continúa siendo necesaria porque permiten distinguir múltiples conexiones simultáneas originadas en el mismo host.

¿Qué ocurre cuando el paquete llega al router?

Para Google, el paquete sale originalmente como:

IPv6 origen: 2001:db8:100:1::20

IPv6 destino: 2001:db8:300::100

TCP origen: 51500

TCP destino: 443

Al recibirlo, el router consulta su tabla de encaminamiento IPv6 y determina por qué interfaz debe reenviarlo.

Pero, a diferencia de IPv4 con PAT:

  1. no modifica la dirección IPv6 de origen => menos trabajo para el Router!.
  2. Tampoco modifica el puerto TCP de origen.  => menos trabajo para el Router!.

  3. Por lo tanto, el router no necesita una tabla de traducción como:  192.168.1.20:51500 ↔ 181.30.40.50:61000    => menos trabajo para el Router! , porque no existe esa traducción.

El paquete sale por la interfaz WAN manteniendo:

[2001:db8:100:1::20]:51500 → [2001:db8:300::100]:443

Para YouTube ocurre exactamente lo mismo:

[20:01:db8:100:1::20]51501 → [2001:db8:400::200]:443

No existe tabla PAT en el Router.

En IPv4 teníamos conceptualmente una tabla como ésta:

Host interno Puerto interno Dirección pública Puerto público Destino
192.168.1.20 51500 181.30.40.50 61000 Google
192.168.1.20 51501 181.30.40.50 61001 YouTube

En IPv6, esa tabla PAT desaparece.

El router podría mantener otras tablas relacionadas con el funcionamiento normal de la red, por ejemplo:

  • tabla de encaminamiento IPv6;

  • tabla de vecinos;

  • estado de conexiones del firewall;

  • información de Neighbor Discovery.

Pero no necesita una tabla que traduzca dirección y puerto privados hacia una dirección pública única.

Capa 2 en IPv6

La situación de capa 2 es conceptualmente muy parecida a IPv4.

La computadora observa que el servidor Google no pertenece a su prefijo local de Red 1 : 2001:db8:100:1::/64 es otra Red, la Red 2 del ISP

Por lo tanto, debe enviar el paquete al router. Sin embargo, IPv6 no utiliza ARP.  En su lugar utiliza Neighbor Discovery Protocol (NDP), que funciona mediante ICMPv6.

El host determina la dirección MAC de su router utilizando mensajes Neighbor Solicitation y Neighbor Advertisement.

Supongamos:

MAC PC ( la propia, conocida) MAC Router LAN (desconocida) :
00:11:22:33:44:55 AA:AA:AA:AA:AA:01

Neighbor Solicitation

Vamos a asumir que la PC no tiene es su tabla de vecinos la MAC del Router.

Entonces la  PC quiere conocer la MAC de: AA:AA:AA:AA:AA:01  que se corresponde a la IP del Router que SI conoce: [20:01:db8:100:1::20]

Entonces  calcula el multicast de nodo solicitado  usando los últimos 24 bits de la dirección IP del Router para crear la misma: 00:00:20
Se forma la dirección multicast: FF02::1:FF00:0020 Entonces el host envía:

Neighbor Solicitation: Destino: FF02::1:FF00:0020

¿Quién recibe ese multicast?

Solo los hosts que estén escuchando ese grupo. 

Normalmente:

1 host

porque cada host escucha solo sus propios solicited-node multicast. 

Recordar que la dirección de multicast de nodo solicitado se forma a partir de los últimos 24 bits de la dirección IP,  con esto NO son muchas las direcciones IP que tienen los últimos 24 bits iguales, esto descarta que un mensaje de multicast pueda ser considerado un Broascast, que esto SI sucede en IPv4 son TODOS los host que deben procesar este mensaje.

Conclusión

IPv6 elimina el broadcast y lo reemplaza por:

multicast específico

Esto:

  • reduce tráfico

  • reduce carga de CPU

  • escala mejor en redes grandes

Un host IPv6 típico escucha varios multicast al mismo tiempo, por ejemplo:

FF02::1          All nodes
FF02::1:FFxx:xxxx   Solicited-node
FF02::FB         mDNS
FF02::1:2        DHCPv6

Por eso IPv6 puede funcionar sin broadcast.

Cuando la Tabla de Vecino tiene la entrada de MAC que necesitamos.

La trama Ethernet enviada dentro de la LAN tendrá:

MAC origen: 00:11:22:33:44:55   - >  MAC destino: AA:AA:AA:AA:AA:01

Dentro de ella estará encapsulado el paquete IPv6:

2001:db8:100:1::20 → 2001:db8:300::100

El router recibe la trama, elimina el encabezado Ethernet y analiza la dirección IPv6 destino.

Luego crea una nueva trama para el siguiente enlace, esto es en CAPA 2, no en capa 3, en Capa 3 sigue como vino el Datagrama.

Por lo tanto, igual que ocurría con IPv4:

las direcciones MAC cambian salto a salto.

Pero las direcciones IPv6 origen y destino permanecen, en condiciones normales, extremo a extremo.

Respuesta del servidor

Google recibe directamente como dirección de origen:

2001:db8:100:1::20

y no la dirección del router.

Por lo tanto responde:

[2001:db8:300::100]:443 → [2001:db8:100:1::20]:51500

La respuesta es encaminada por Internet hasta llegar al router de la LAN.

El router observa la dirección IPv6 destino:

2001:db8:100:1::20

consulta su tabla de encaminamiento y determina que ese host se encuentra conectado a su interfaz LAN.

Mediante su Neighbor Cache conoce -o averigua mediante NDP- la dirección MAC correspondiente al host, vamos a asumir que ya la tiene.

Finalmente genera una trama:

MAC Router LAN → MAC PC

conteniendo:

[2001:db8:300::100]:443 → [2001:db8:100:1::20]:51500

El sistema operativo recibe el segmento TCP y utiliza el puerto destino 51500 para entregarlo a la conexión correspondiente con Google.

Para YouTube sucede lo mismo con el puerto 51501.

Entonces, ¿qué función cumple el router IPv6?

En IPv4 con PAT el router realizaba dos funciones muy visibles:

  1. encaminamiento;

  2. traducción de direcciones y puertos.

En IPv6, normalmente realiza principalmente:

  1. encaminamiento entre prefijos IPv6;

  2. funciones de firewall;

  3. Neighbor Discovery en sus enlaces;

  4. eventualmente Router Advertisement para informar al host acerca del prefijo, gateway y otros parámetros.

No necesita ocultar los hosts detrás de una única dirección pública.

Esto restaura una característica fundamental del diseño original de IP:

la comunicación extremo a extremo.

El servidor puede observar directamente la dirección IPv6 global del host que origina la comunicación.

¿Significa esto que el host queda desprotegido?

No, el PAT en algunos ISP es mencionado como una protección para el usuario, pero es mas bien un argumento de venta.

La ausencia de NAT no significa ausencia de seguridad.

En una red IPv6 es habitual que el router utilice un firewall con inspección de estado.

Por ejemplo, puede permitir:

LAN → Internet

para conexiones iniciadas desde el interior y permitir los paquetes de respuesta correspondientes.

Al mismo tiempo puede bloquear conexiones nuevas iniciadas desde Internet hacia los equipos de la LAN.

Por lo tanto:

NAT no debe confundirse con firewall.

En IPv4 ambas funciones suelen encontrarse en el mismo equipo y esto puede generar la impresión de que NAT proporciona la seguridad.

En IPv6 la separación conceptual resulta mucho más clara.

Comparación final IPv4 vs. IPv6

IPv4 con PAT:

192.168.1.20:51500

↓ PAT

181.30.40.50:61000

↓

Google:443

El servidor Google ve:

181.30.40.50:61000

IPv6:

[2001:db8:100:1::20]:51500

↓

Router IPv6, sin traducción

↓

[2001:db8:300::100]:443

El servidor Google ve directamente:

[2001:db8:100:1::20]:51500

Por lo tanto, la diferencia esencial puede resumirse así:

En IPv4 con PAT, el router modifica el socket visible desde Internet.

En IPv6, normalmente el router solamente encamina el paquete; los sockets de los extremos permanecen identificables de extremo a extremo.