IPv6 para el administrador de Windows: Como funciona la resolución de nombres en un escenario dual IPv4/IPv6

Articulo original (https://blogs.technet.com/b/askpfeplat/archive/2013/11/11/ipv6-for-the-windows-administrator-how-name-resolution-works-in-a-dual-ipv4-ipv6-scenario.aspx)

Hola, soy Venkat Kalyanasundaram, Senior PFE del área metropolitana de Nueva York.

Como alguien que trabaja constantemente con IPv6, comúnmente veo surgir el mismo conjunto de preguntas una y otra vez. Quiero tomar un poco de tiempo para abordar algunas de las preguntas más comunes y tratar de quitar el misterio de IPv6 de una vez por todas. Este es el primer post de una serie, así que estén al pendiente de las siguientes entregas para conocer más bondades de IPv6.

La primera pregunta que quiero tratar es extremadamente común. ¿Cómo funciona el proceso de resolución de nombres en un escenario de dual stack con Windows? Siendo más específico, nos gustaría saber ¿Cuál es el impacto a nuestro entorno de red cuando se habilita IPv6 en Windows?

Bueno, resolvamos esto de una vez. Como hemos dicho antes, no es recomendable deshabilitar IPv6 en los equipos Windows (En el FAQ de IPv6 para Microsoft Windows pueden revisar la pregunta "¿Cuál es la recomendación de Microsoft sobre deshabilitar IPv6?" para más detalles.)

La clave aquí es tener un entendimiento básico sobre cómo funciona el proceso de resolución de nombres en Windows cuando se habilitan IPv4 e IPv6.

En el mundo de IPv4, estamos acostumbrados a manejar el proceso de resolución de nombres usando Microsoft WINS y DNS. En el mundo de IPv6, WINS ya no importa. En otras palabras, las direcciones IPv6 no se registran en WINS y deben ser manejadas totalmente vía DNS. Una dirección IPv6 es representada como un registro AAAA (cuádruple A) en DNS similar a como se representa una dirección IPv4 como un registro de Host A. El concepto de registro PTR (para resolución de nombres inversa - de dirección IP a nombre de host) también se aplica a las direcciones IPv6 en DNS.

Con IPv4, normalmente estamos acostumbrados a tener registrada en DNS una sola dirección IP para una máquina dada. Con IPv6, tenemos que lidiar con diferentes tipos de direcciones (Link Local, Global etc. como comentaron anteriormente Mark y Ray en su blog https://blogs.technet.com/b/askpfeplat/archive/2013/06/24/ipv6-for-the-windows-administrator-ipv6-fundamentals.aspx). Tengan en cuenta que no todos los tipos de direcciones IPv6 se registran en DNS. Por ejemplo, una dirección Link Local que inicia con FE80: (dirección no enrutable, activa solamente dentro de su subred local) no es registrada en DNS. Mientras que una dirección Global se registra en DNS con un registro AAAA (cuádruple A). Cuando se trabaja con tecnologías de transición, las direcciones de Teredo no se registran en DNS. El artículo de Microsoft Technet Comportamiento del cliente DNS explica este comportamiento a detalle.

Repasemos algunos escenarios de la vida real en donde la red corporativa existente está funcionando casi al 100% con IPv4 y ustedes están tratando de introducir máquinas Windows nuevas con dual stack habilitado (IPv4 e IPv6 activos). Intentaremos averiguar cómo se comunican estas máquinas nuevas con la red existente.

Escenario #1:

Como se puede ver en el diagrama de arriba, tenemos dos máquinas (digamos que son un cliente Windows 7 y un Appserver1 ejecutando Windows 2008/R2) ubicadas en dos subredes diferentes con IPv4 e IPv6 activado (dual stack). Cuando habilitamos IPv6, la dirección Link Local (que inicia con FE80: lo cual puede verificarse con la salida del comando IPCONFIG) se configurará automáticamente en Windows. No vamos a entrar al detalle de cómo es generada de forma automática la dirección Link Local. Ese es un tema que trataremos en una entrega posterior. Vamos a asumir que no hemos configurado ninguna dirección Global de IPv6 ni alguna dirección para tecnologías de transición de IPv6.

El servidor AppServer1 registra su IPv4 en DNS. Como la dirección Link Local de IPv6 no es enrutable y esta confinada a la subred local, no se registra en DNS. En otras palabras, en DNS tenemos un sólo registro Host A para el nombre AppServer1 que apunta a la dirección IPv4 10.1.0.2, aun cuando tenemos habilitado IPv6 en el servidor.

Digamos que el cliente Windows 7 necesita comunicarse con el servidor AppServer1, vamos a ver cómo funcionan las cosas en el background desde la perspectiva de la red y la resolución de nombres. Inicialmente el cliente envía una petición al servidor DNS para resolver el nombre "AppServer1.contoso.com". El servidor de DNS le responde con un registro A apuntando a  la dirección IPv4 10.1.0.2. Entonces el cliente se comunica con el AppServer1 enviándole una solicitud a la dirección IPv4 10.1.0.2. Como se puede ver, la comunicación se sigue estableciendo vía IPv4 aunque tengamos habilitado IPv4 e IPv6 tanto del lado del cliente, como del lado del servidor. No existe impacto al performance de la red. Aun cuando el cliente o el servidor estuvieran configurados solo con una dirección IPv4 (sin dirección IPv6), encontraríamos el mismo comportamiento que acabamos de explicar.

Escenario #2:

Extendamos un poco más el escenario #1. Esta vez, digamos que el cliente está configurado con dual stack (con una dirección IPv4 y una dirección IPv6 Link Local como en el escenario #1), pero esta vez el servidor está configurado con una dirección IPv4 y una dirección IPv6 Global.

En este escenario, el AppServer1 va a registrar en DNS su registro Host A (apuntando a la dirección IPv4 10.1.0.2) y su registro AAAA (para la dirección IPv6 Global). En este caso también se genera la dirección Link Local en el AppServer1, la cual no se registra en DNS.

¿Qué pasará cuando el cliente Windows 7 quiera comunicarse con el AppServer1 en este escenario? El cliente envía una petición al servidor DNS para resolver solo el registro Host A para el nombre AppServer1. El cliente nunca intentará consultar el registro AAAA (aun cuando el servidor DNS tenga el registro AAAA del AppServer1), lo anterior porque el cliente sabe que el solamente tiene configurada una dirección Link Local que no es enrutable. El servidor DNS responde con la dirección IPv4, después de lo cual, el cliente se comunica vía IPv4 similar a como sucedió en el escenario #1.

Escenario #3:

Vamos a asumir que para este escenario, hemos configurado direcciones IPv6 globales, tanto en el cliente como en el servidor. También vamos a asumir que el equipo de redes ha configurado los ruteadores para rutear correctamente las direcciones IPv6. Esto significa que hemos realizado acciones específicas para configurar direcciones IPv6 globales en nuestra red, ya sea manualmente o utilizando el servidor DHCP o incluso desde el ruteador. (Sí, es posible configurar las direcciones IPv6 directamente desde el ruteador... Este tópico se cubre brevemente aquí: https://blogs.technet.com/b/askpfeplat/archive/2013/07/08/ipv6-for-the-windows-administrator-more-ipv6-subnetting-zones-address-autoconfiguration-router-advertisements-and-ipv4-comparisons.aspx)

En este escenario tanto el cliente como el servidor registran en DNS su registro Host A (para su dirección IPv4) y su registro AAAA (para su dirección IPv6 Global). Cuando el cliente Windows 7 intenta comunicarse con el AppServer1 en este escenario, hace la consulta a DNS para resolver el nombre AppServer1. El servidor DNS le responde con el valor del registro A (apuntando a la dirección IPv4) y con el valor del registro AAAA (que apunta a la dirección IPv6 Global) del servidor AppServer1. En este caso, el cliente se comunica con el servidor mediante IPv6. Si ambos registros (A y AAAA) pueden ser resueltos, el comportamiento por default en Windows es tratar de comunicarse vía IPv6.

Recapitulando…

Como puede verse en los escenarios de arriba, el escenario #3 es el único en donde el cliente y el servidor se comunican vía IPv6. En este escenario, los administradores de Windows y de Redes han realizado tareas  específicas para configurar las direcciones IPv6 globales en los ruteadores y en los equipos Windows. Si no se han realizado dichas tareas específicas y se habilita IPv4 e IPv6 en los equipos Windows con la configuración predeterminada, el impacto a la red es mínimo, como se puede constatar en los escenarios #1 y #2.

Como han podido notar en los escenarios anteriores, hemos usado direcciones IPv4 en el rango de direcciones privadas. Si en su red están usando direcciones IPv4 públicas (rangos distintos al 10.x.y.z, 172.16.x.y o 192.168.x.y) hay unas cuantas cosas más que debemos tener en cuenta. En mi próximo post, abordaré estas cuestiones.

Venkat