Escenario 2: Enlace de 2 sistemas IPv6 a través de un Back Bone IPv4

El segundo escenario presenta una posibilidad real donde se interconectan dos islas IPv6 a través de una red IPv4 pura. El esquema conceptual se presenta en la figura 37. Aquí el objetivo es implementar un escenario real probable para el ofrecimiento del servicio IPv6 y observar el comportamiento del protocolo bajo condiciones de operación dentro de un ambiente de producción normal.

Escenario 2: Tunel IPv6 Alestra-ITESM a través del Back Bone Alestra

Payload IPv6 Payload IPv6

Alestra Lab ITESM Lab TyR

Router Cisco 7200 DS IPv6/IPv4 App ServerLinux 3ffe:8240:800f:2:260:b0ff:fe3c:b2c1 10.0.1.4 Host Win 2000 3ffe:8240:800f:2:206:89ff:fe3c:c2d7 10.0.1.2 Router Cisco 2500 DS IPv6/IPv4 HTTP 3ffe:8241::200 DNS 3ffe:8241::9 Laptop Win 2000 3ffe:8240:800f:2:200:86ff:fe43:d2df 10.0.1.3

App Server Linux 2001:498:1::5 131.178.100.179 VLAN ipv6/v4 VLAN ipv4 VLAN ipv6 VLAN ipv6/v4 HUB 10/100 Mbps Switch Catalyst Cisco 2600 10/100 Mbps Switch Catalyst Cisco 2600 10/100 Mbps 3ffe:8240:800f:2::1 10.0.1.200 3ffe:8240:800f:1::1 148.244.150.254 3ffe:8240:800f:1::2 131.178.100.8 HUB 10/100 Mbps Fast Ethernet 10/100 Mbps 207.248.227.38 IPv4 Payload IPv6 2001:498:1::1 acc1mty.alestra.net gsr1mty.alestra.net acc2mty.alestra.net gwc55.mty.itesm.mx 131.178.101.253 207.248.224.238 131.128.100.1 Back Bone Alestra Lab Access Cisco 3600 E1 E3

Tunnel ipv6 over ipv4

Back Bone ITESM gwipv6.mty.itesm.mx gwmtycore1.mty.itesm.mx gwinternet.mty.itesm.mx gwnat1.mty.itesm.mx 10.16.0.131 10.16.0.194 207.248.226.173 207.248.224.245

Figura 37: Interconexión de dominios IPv6 a través de un back bone IPv4

En nuestro caso concreto, las islas IPv6 se encuentran físicamente en las instalaciones del ISP y del ITESM respectivamente, instaladas de la misma manera que la explicada en el escenario de prueba 1, solo que en este escenario ambos routers de borde se encuentran conectados de manera física al “Back bone” del ISP, es decir de la manera actual en que el ITESM se conecta a la red de Internet a través de IPv4. En este escenario el objetivo es establecer un mecanismo de Túnel entre el router Cisco 7200 (sito ISP) y el router Cisco 2500 (sitio ITESM.) Para este efecto, el requerimiento es que ambos routers sean configurados con capacidad Dual Stack, es decir, con la capacidad de entender tanto el protocolo IPv6 como el IPv4. Así, es tráfico IPv6 es encapsulado dentro de un paquete IPv4 con objeto de que pueda “viajar” a través del Back Bone, llegar al router 7200, des encapsular el paquete IPv6 y entregarlo al host apropiado dentro de la VLAN del sitio IPv6 del ISP.

El mecanismo utilizado para habilitar la entrega de paquetes IPv6 es exactamente el descrito en la sección 3.3.1. Específicamente, el tipo de túnel configurado fue del tipo manual, también descrito en el apartado 3.3.1.1.

Afortunadamente y para evitar la configuración de NATs u otros mecanismos, se pudo contar con una dirección pública para el router de borde en el sitio del ISP, gracias a esta medida, el servidor Linux puede enviar el tráfico IPv4 hasta una dirección privada. Esta operación se realiza configurando un túnel desde el router de acceso del ITESM (Dual Stack Cisco 2500), hasta el router de acceso del ISP (Dual Stack Cisco 7200) que a su vez, puede enviar el tráfico hasta la VLAN IPv6/IPv4 que solo posee direcciones privadas.

Además es necesario configurar rutas estáticas desde los servidores a los routers Dual Stack para habilitar la comunicación entre direcciones probadas y públicas. Este problema se elimina en IPv6 ya que todas las direcciones utilizadas son únicas por definición o de carácter público. (Aquí percibimos algunas ventajas de IPv6.)

Es importante recalcar, que el proceso descrito arriba implica que el tráfico IPv6 es encapsulado en IPv4 para poder diseccionarse a través del Back Bone, pero también el tráfico IPv4 es encapsulado dentro de otro paquete IPv4 para poder llegar a la VLAN con direcciones privadas. Así, tanto el tráfico IPv6 como el tráfico IPv4, están expuestos al proceso de encapsulamiento. Esto quiere decir que la única diferencia en el envío de los paquetes será el overhead de IPv6 y el enrutamiento a partir de los routers de acceso, que será IPv6 puro a partir de los routers Dual Stack para el caso del uso de dicho protocolo e IPv4 “puro” en el caso contrario.

Con objeto de garantizar la uniformidad de las pruebas, los túneles fueron definidos tanto en IPv6 como en IPv4 con los mismos destinos y las mismas fuentes físicas, lo que permite que la ruta seguida en la transmisión de la información sea con gran probabilidad fija, es decir, el tráfico generado dentro del escenario será enviado a través de los mismos routers, haciendo el mismo número de saltos y permitiendo de esta manera evaluar el desempeño de los protocolos siempre bajo las mismas condiciones de ruteo.

El escenario 2 permite evaluar también el desempeño de IPv6, interactuando con una red de ambiente de producción que transporta tráfico real. Las direcciones utilizadas, así como las capacidades de los enlaces y detalles de implementación se pueden observar en la figura 37.

4.4.2.1 Prueba 4: Generación de tráfico IPv6 a través del Back Bone IPv4.

Para esta prueba, la configuración e implementación de los servidores, hosts, daemon NTP, aplicaciones, direccionamiento etc. es la misma que la utilizada en el escenario 1. Solamente es necesario utilizar un conjunto de direcciones diferentes a las del escenario 1, con objeto de habilitar el ruteo a través del Back Bone. Las direcciones utilizadas en cada etapa de ruteo se pueden verificar en la figura 37.

Ya que este no es un ambiente 100% controlado y depende de las condiciones de aleatoriedad de la red. El procedimiento de prueba fue cambiado de manera significativa. En esta ocasión se pretendió caracterizar el comportamiento de IPv6 para distintos tipos de flujos de tráfico que son procesados dentro de un ambiente de tráfico IPv4 real.

La prueba consistió en generar flujos de tráfico en períodos de dos minutos, teniendo como fuente de tráfico el servidor Linux en el sitio del ITESM y como receptor, el servidor Linux en el sitio del ISP. Los flujos consistieron en paquetes con tamaños que iban desde 64 hasta 768 bytes y con frecuencias de transmisión desde 20 hasta 120 paquetes por segundo, generando con esto, throughputs desde 10Kbps hasta 737Kbps aproximadamente. Dichos flujos fueron generados durante un período de 3 semanas, a partir de las 7:00 p.m. y hasta las 12:00 a.m. de manera completamente aleatoria, buscando de esta manera, evaluar los resultados del desempeño considerando los

diferentes niveles de tráfico que pudieran estar siendo procesados por el Back Bone en diferentes instantes. Es decir, el objetivo de la prueba fue el de inferir por medio de una muestra, el comportamiento promedio de los diferentes flujos de datos al momento de pasar a través del Back Bone del ISP.

Los parámetros de desempeño seleccionados para este escenario, fueron el retardo de paquetes de una sola vía, la pérdida de paquetes y el trhoughput consumido para todos los diferentes tipos de flujos generados. Los procedimientos de medición para las características citadas fueron los mismos que los expuestos en el escenario 1.

4.4.2.2 Prueba 5: Generación de tráfico IPv4 puro a través del Back Bone.

Con objeto de establecer un marco de comparación entre IPv6 e IPv4, las mismas características de la prueba 4 y los mismo parámetros de medición fueron simplemente replicados en la prueba 5, con la única variante de utilizar un protocolo diferente: IPv4.

Como se puede observar en la figura 37 y en la configuración de los routers, es posible transmitir flujos de paquetes desde la misma fuente, hacia el mismo destino y por exactamente la misma ruta, utilizando IPv4 e IPv6. De esta manera, y considerando un mismo escenario, se puede hacer una comparación cuantitativa real entre el desempeño de IPv4 e IPv6. Cabe mencionar que al igual que con el escenario 1, las pruebas 4 y 5 se realizaron de manera paralela, es decir, generando alternativamente flujos con el formato IPv4 y con el formato IPv6.