Post original 

Hola todos, Mark de vuelta con un nuevo tema del cual no hemos hablado realmente mucho en el blog, IPv6. Cuando voy a sitio donde los clientes, tiendo a tener dos discusiones una y otra vez. Primero, los puertos RPC y los firewalls. Ned Pyle se ha ocupado de cada uno de ellos aquí y aquí. La segunda, IPv6. El punto de este post no es como funciona todo en profundidad técnicamente, el punto es entrar en una discusión similar a las discusiones en sitio que he tenido una que otra semana y que está orientada al administrador de Windows/Sistema. Ray Zabillia y yo tenemos planeadas más publicaciones acerca de conceptos básicos y como funciona todo en las próximas semanas. Si este es un tema de interés, podemos empezar desde ahí y profundizar realmente en algunas de las tecnologías de transición e incluso en cómo generar su propio laboratorio. ¡Por favor, háganoslo saber en los comentarios! Ahora demos un vistazo a las discusiones en sitio.

“A quien le interesa IPv6, tenemos IPv4 trabajando y funciona muy bien.”

Apuesto a que sí. Este es un argumento lógico similar a, “a quien le interesa equipos en 64-bit, tenemos 32-bit”. ¿Quieren hacer esa afirmación así? En febrero 3 de 2011, la Corporación de Internet para Nombres y Números Asignados (ICANN por siglas en inglés) se unió a la Organización de Recursos Numéricos (NRO por sus siglas en ingles), la Junta de Arquitectura de Internet (IAB por sus siglas en ingles) y la Sociedad de Internet (Internet Society) para anunciar que el conjunto de direcciones públicas del Protocolo de Internet versión 4 (IPv4) había sido completamente asignado.

En septiembre 14 de 2012, el RIPE NCC comenzó a asignar espacio de direcciones IPv4 desde el ultimo /8 del espacio de direcciones IPv4 que contiene. Actualmente el espacio de direcciones IPv4 se asigna de acuerdo a la sección 5.6 de las Políticas para la asignación de direcciones IPv4 del servicio de RIPE NCC para la región. Los paquetes de direcciones IPv4 del RIR (Regional Internet Registry) están próximos a agotarse RIPE NCC IPv4 Paquetes de direcciones disponibles. Poco tiempo después, los proveedores de internet (ISPs) agotarán sus paquetes de direcciones. Es en este punto donde los clientes se verán afectados por el agotamiento, porque no existirán mas direcciones IPv4 disponibles para entregarles. Todas habrán desaparecido.

También hay varias limitaciones de IPv4. No estoy diciendo que necesita implementar IPv6 mañana, pero no hagamos cosas hoy que harán difícil en el futuro realizar la transición hacia IPv6.

“¿Limitaciones de IPv4?, ¿como cuáles?”

Bueno, para empezar estamos escasos de direcciones como se ha dicho anteriormente. Lo más probable es que usted está consiguiendo MÁS dispositivos conectados a Internet, no menos. Pero vamos a suponer que usted tiene la suerte de tener una clase completa de direcciones A o B para sí mismo y no necesita más direcciones en el futuro previsible. ¿Necesita seguridad a nivel IP o necesitará de ella en el futuro? Supongo que sí. IPSec es opcional en IPv4, pero se ha convertido en un estándar en IPv6 desde el primer día, lo cual hace que las implementaciones de IPSEC sean consistentes a través de las implementaciones de los proveedores. ¿Qué pasa con la calidad de servicio (QoS)? IPv4 puede hacerlo utilizando el campo Tipo de Servicio (TOS), pero no funciona cuando se cifra el paquete. Así que espero que usted no quiera tener LA SEGURIDAD y LA CALIDAD DEL SERVICIO al mismo tiempo. Se está haciendo más y más difícil forzar IPv4 a hacer lo que se logra fácilmente en IPv6.

“Tenemos NAT funcionando en este momento, entonces está bien”

Esa es otra bola de cera. Por no hablar de la complejidad que se añade a la red que puede hacer que la solución de problemas sea aún más difícil de tratar, pero no todas las aplicaciones funcionan con NAT debido al hecho de no tener una dirección IP "real" en el cliente. Hacer que IPSec funcione con NAT también es un reto. NAT puede resolver algún problema, pero también puede introducir algunos otros. Probablemente no es sostenible en el largo plazo.

“Hmmm todo esto suena como que usted debería hablar con el equipo de redes acerca de esto, ellos están al fondo del pasillo. Este no es mi problema”

Está bien, hemos llegado al núcleo de este argumento. Es ABSOLUTAMENTE su problema. Si nunca ha tenido que solucionar problemas de un servidor que no es capaz de conectarse a otro servidor, éste debe ser su primer día en el trabajo. Saber solucionar problemas de conectividad es una herramienta crítica dentro de la bolsa de herramientas para la solución de problemas. Si no es así, añádala de inmediato, de nada. Ser capaz de comprender una dirección IPv6 y todo lo que significa será útil y en realidad, una necesidad en el futuro. He tenido clientes donde el equipo de red está “probando” IPv6 y el cliente empieza a recibir esta "dirección misteriosa". ¿Eso es normal?, ¿Está funcionando como se supone?, ¿Estoy en la red correcta?, todas estas preguntas pueden responderse hoy con una dirección IPv4, ¿por qué NO responder a ellas solo porque la dirección se ve diferente? La idea de no tener conocimiento básico de IPv4 hoy es impensable, tener habilidades de IPv6 no sólo le pondrá por delante de la curva hoy y le preparará para el futuro. Un ejemplo de la vida real, aquí en breve.

“Si, pero aun así, escucho que IPv6 daña las cosas, esa es la razón de por qué yo lo tengo que deshabilitar”

Por supuesto que usted tiene. En primer lugar, todavía tengo que escuchar que IPv6 "mete la pata". En segundo lugar, esto no es deshabilitar IPv6, esto es desligarlo del adaptador de red. Si su objetivo es deshabilitar IPv6 en el sistema, usted no lo ha hecho. Todavía se está ejecutando en el sistema. Si tiene que volver a marcar esa casilla NO HAY UNA MANERA PROGRAMATICAMENTE de hacerlo. Así que si se ha adelantado e incorporado la casilla desmarcada de la imagen y necesita IPv6 en ese adaptador de red, usted necesitará iniciar sesión EN CADA MAQUINA Y VOLVERLA A MARCAR. ¡Oh, qué divertido que será! Si usted tiene que desactivarlo siga el KB 929852 utilizando la llave de registro de Componentes deshabilitados. Recomiendo no deshabilitarlo, pero si para usted es absolutamente necesario, utilice una GPO para que pueda deshacer fácilmente esto en el futuro. Como se indica en el KB, si usted hace uso de la clave de registro de Componentes deshabilitados la casilla indicada permanecerá marcada. Ese es el comportamiento esperado.

“Todo eso está muy bien en teoría, pero ¿esto realmente sucede en el mundo real?"

Aquí en AskPFELatamPlat tenemos una perspectiva única por pasar tanto tiempo frente a tantos clientes, logramos ver lo que sucede en el mundo real. Recientemente Ray estaba ayudando a uno de nuestros grandes clientes empresariales en su migración de Directorio Activo de Windows Server 2003 a Windows Server 2008 R2. Ellos sólo habían instalado unos pocos controladores de dominio en 2008 R2 y poco tiempo después Ray recibió una llamada de uno de los arquitectos de AD de la empresa pidiendo que le explicara por qué él estaba obteniendo direcciones IPv6 en respuesta a su "ping" en los controladores de dominio 2008 R2. Además, ¿por qué había dos direcciones IPv6 asignadas? ¿Y por qué una de las direcciones siempre comenzaba con FEC0 y la otra con 2002? ¿Qué direcciones están siendo registradas en el DNS?

Ahora en este cliente en particular la mayor parte del soporte y administración de TI, incluyendo la de Directorio Activo había sido subcontratada con un proveedor de terceros. Así que Ray tuvo una reunión con el personal de AD propio del cliente y varios miembros del personal de AD de parte del subcontratista. Uno de los miembros del personal de soporte del tercero para AD dijo que esto tenía una solución fácil, que simplemente sólo sería desmarcar la casilla protocolo IPv6 en la configuración del adaptador de red para desactivar IPv6 y los problemas serían resueltos.

¿Ve el problema de la vida real? Si un proveedor le está diciendo que deshabilite IPv6 para "arreglar un problema" o que "observa que este causa problemas" retroceda un poco y pregúntele qué es lo que realmente está arreglando o los problemas que este está causando. Haga que sea específico. Es hora de no permitir que IPv6 sea este gran misterio del universo.

"Bien, hablando de todo un poco, cual es la posición de Microsoft sobre IPv6?"

Voy a dejar que la documentación oficial haga la charla en este caso. Respuesta corta, déjelo encendido. Originalmente lo puede encontrar en IPv6 para Microsoft Windows: Preguntas frecuentes (artículo en Ingles).

Es lamentable que algunas organizaciones deshabilitan IPv6 en sus computadores que funcionan con Windows 7, Windows Vista, Windows Server 2008 R2 o Windows Server 2008, donde está instalado y habilitado por defecto. Muchos deshabilitan IPv6 basados en el supuesto de que no están ejecutando aplicaciones o servicios que lo utilicen. Otros podrían deshabilitarlo debido a una percepción errónea de que tener tanto IPv4 como IPv6 habilitado efectivamente duplica su tráfico Web y de DNS. Esto no es cierto.

Desde la perspectiva de Microsoft, IPv6 es una parte obligatoria del sistema operativo Windows y está habilitado y se incluye en las pruebas de servicio y aplicación estándar de Windows durante el proceso de desarrollo del sistema operativo. Debido a que Windows se ha diseñado específicamente con IPv6 actualidad, Microsoft no realiza ninguna prueba para determinar los efectos de deshabilitar IPv6. Si IPv6 es desactivado en Windows 7, Windows Vista, Windows Server 2008 R2 o Windows Server 2008 o versiones posteriores, algunos componentes no funcionarán. Es más, podrían ser aplicaciones que usted puede pensar que no están utilizando IPv6, tales como Asistencia remota, Grupo Hogar, DirectAccess y Windows Mail.

Por lo tanto, Microsoft recomienda que deje IPv6 habilitado, incluso si usted no tiene una red habilitada para IPv6, ya sea nativo o tunelizado. Al dejar IPv6 habilitado, usted no deshabilita aplicaciones y servicios que solo usen IPv6 (por ejemplo, Grupo Hogar en Windows 7 y DirectAccess en Windows 7 y Windows Server 2008 R2 utilizan sólo IPv6) y sus anfitriones pueden tomar ventaja de una conectividad IPv6 mejorada.

“¿Que productos de Microsoft soportan IPv6?”

Obtenga la lista oficial aquí. Son bastantes.

“¿Algo más que yo deba saber?”

Una cita textual del prefacio de “Understanding IPV6 – Third Edition” lo resume muy bien.

“"En los últimos 24 meses, hemos hecho grandes progresos hacia el objetivo de mejorar la Internet. IPv6 ya no es el protocolo de Internet de la próxima generación, sino que se ha convertido en el protocolo de Internet de la generación actual.

El lanzamiento mundial de IPv6 en junio de 2012 marcó un punto de inflexión clave en esta transición. Cuando lea este libro, algunos de los servicios web más importantes del mundo, no sólo de Microsoft, sino de toda la comunidad de la tecnología, están en funcionamiento en la Internet IPv6. Millones de usuarios con equipos listos para IPv6 están utilizando IPv6 para interactuar con estos servicios y con algunos otros. Las aplicaciones, los sistemas operativos, la infraestructura de enrutamiento, los proveedores de Internet, y los servicios no solamente están listos, están activados”.

-Chris Palmer

IPv6 Program Manger

Microsoft

Bien, espero que en este punto dentro del post, usted haya girado en torno a IPv6 completamente y esté listo para profundizar en el. El punto de esto es que IPv6 no está llegando, está aquí ahora. IPv4 es, de hecho, la tecnología antigua o heredada. En nuestra próxima publicación vamos a entrar en más detalle y dar sentido a todo. No se preocupe, no es tan aterrador.

-Mark “IPv6 Ready” Morowczyski y Ray “IPv6 Ready” Zabilla

Hola a todo, una vez más Mark. En nuestro último tema hablamos acerca del ¿por qué usted debe preocuparse acerca de IPv6?. En este nuevo blog Ray Zabilla y yo vamos a desmitificar el enigma de las direcciones IPv6 y le dará una mejor comprensión del espacio de direcciones IPv6 y la sintaxis. Compararemos también diferentes conceptos que abordan entre IPv4 e IPv6.

Comencemos con un ejemplo común que estamos acostumbrados a ver.

Ahí está, una dirección IPv6. No temas no asusta.

Vamos a desglosar esta información y compararla con algo que sí sabemos bastante bien IPv4. La dirección IPv6 es de 128 bits de largo y IPv4 son 32 bits de longitud. Por eso IPv6 permite mucha más direcciones. Si usted desea ser más específico, IPv6 le permite 340.282.366.920.938.463.463.374.607.431.768.211.456 direcciones. Dile adios al bebé NAT!

El desglose de la direcciön IPv6

La dirección IPv4 se dividen en 8 bits, escrito en decimal y separados por un ".". Desde la pantalla tenemos la dirección 10.0.1.114.Dirección IPv6 se divide en 16 bits, escrito en hexadecimal y están separados por un ":". Desde la pantalla tenemos la FE80 :: D9E : bed6 : 4917 : C7DF%12

Otra de las diferencias significativas con las direcciones IPv6 y las direcciones IPv4 es que las direcciones IPv6 se expresan como números hexadecimales en lugar de números decimales. Dependiendo de su fondo esto puede hacer que sea más fácil o más difícil de entender, pero no te despegues permítenos explicar las reglas de la dirección IPv6. Si usted no tiene mucha experiencia trabajando con los números hexadecimales aquí hay un par de enlaces que proporcionan un poco más de detalle, si usted desea tener una mejor comprensión.

http://www.codemastershawn.com/library/tutorial/hex.bin.numbers.php

http://en.wikipedia.org/wiki/Hexadecima

Las calculadoras integradas también pueden convertir a hexadecimal para usted. Sólo tienes que cambiar a " programador"

De buelta al tema direcciones IPv6. Lo que realmente me ayudó a entender cómo leerlos fue reconocer los límites que contiene 4 caracteres hexadecimales y debe haber 8 conjuntos de ellos. Por ejemplo, sería algo como "abcd : abcd : abcd : abcd : abcd : abcd : abcd : abcd" Cada caracter en este grupo puede estar formado por 4 bits también conocidos como 'nibbles'. Así que vamos a hacer algunos cálculos aquí. Cada personaje es de 4 bits , hay 4 personajes por juego para un total de 16 bits. Tenemos 8 juegos, 8 x 16 = 128 bits. Todo concuerda.

Ahora nuestra dirección IPv6 reflejada en la captura de pantalla no cumple con el número total de caracteres y faltan algunos grupos. Vamos a escribirlo en la forma larga y dar consejos poder acortar la dirección mediante la compresión de ceros.

FE80:0000:0000:0000:0d9e:bed6:4917:C7DF%12

En primer lugar un grupo de 0s puede ser representado por dos puntos dobles " : " . Sólo se puede utilizar una vez por cada dirección. Así que nuestra nueva dirección con 0s comprimidos se puede escribir como FE80::0d9e:bed6:4917:C7DF%12. Mi otro truco mental es el siguiente. Sé que debería tener un conjunto de 8, así que tomo el número del conjunto que tengo de solo 0 y los substraigo del conjunto total de 8. Bien de nuevo a nuestra dirección.

Si se compara nuestra dirección en la salida de FE80::d9e:bed6:4917:C7DF%12 a nuestros nuevas direcciones con 0s comprimidos FE80::0d9e:bed6:4917:C7DF%12 tenemos un extra 0. Sin embargo También puede comprimir los principales 0s en la dirección . Así tenemos , FE80::d9e:bed6:4917:C7DF%12. Vamos a hacer algunos otros ejemplos y para poder aclarar los ejemplos.

Ejemplos

Vamos a empezar con la dirección IPv6 original desde arriba.

Esto se conoce como puntos hexadecimal

FE80:0000:0000:0000:0d9e:bed6:4917:C7DF%12

Forma binaria

1111111010000000000000000000000000000000000000000000000000000000

0000110110011110101111101101011001001001000101111100011111011111

Dividido en 16 bits

1111111010000000 0000000000000000 0000000000000000 0000000000000000

0000110110011110 1011111011010110 0100100100010111 1100011111011111

Supresión de ceros

FE80:0:0:0:d9E:bed6:4917:C7DF

Supresión de ceros con la supresión de " dos puntos dobles " Una secuencia única contigua de bloques de 16 bits se pone en 0 puede ser comprimido por "::" ( doble punto) Un doble de punto puede utilizarse solamente una vez cuando se comprime una dirección .

FE80::d9E: bed6:4917:C7DF

No se puede utilizar la compresión de cero para incluir parte de un bloque de 16 bits

FF02:30:0:0:0:0:0:5 no se puede hacer FF02:3::5, pero si FF02:30::5

Más ejemplos de compresión cero

2003:00ef:67ea:0000:ffdc:1268:0002:0044

2003:ef:67ea::ffdc:1268:2:44

3ffe:0039:ebc0:5600:cda0:0098:bca2:0096

3ffe:39:ebc0:5600:cda0:98:bca2:96

2109:de00:b00d:0087:0000:0000:0000:0027

2109:de00:b00d:87::27

300f:0000:0000:0096:0000:0000:0054:fdec

300f::96:0:0:54:fdec

Nótese que usamos el ":: " una vez , aunque tuvimos varios bloques de 0.

2999:0000:dead:beef:cafe:0000:0000:0001

2999::dead:beef:cafe:0:0:1

En general, el resumen de la espacio de direcciones IPv6 puede ser visto como sigue .

· Espacio de direcciones de 128 bits

· 2¹²⁸ posibles direcciones

· 340,282,366,920,938,463,463,374,607,431,768,211,456 direcciones (3.4 x 10³⁸ o 340 undecillones) (undecilion ni siquiera estaba en el corrector ortográfico de MS Word !)

· 6.65 x 10²³ direcciones por cada metro cuadrado de la superficie de la Tierra

· 128 bits para permitir una flexibilidad de erutación de un multinivel, jerárquico

Ahora que hemos definido el formato de una dirección IPv6 vamos a pasar a algunas de las otras características y funciones de IPv6.

Tipos de direcciones IPv6

IPv6 tiene tres tipos de direcciones , que se pueden clasificar según el tipo y alcance.

Unicast - Una dirección unicast identifica una única interfaz dentro del alcance del tipo de dirección de unicast. Con la topología de enrutamiento apropiada, los paquetes dirigidos a una dirección unicast se entregan a una sola interfaz.

Lo que esto significa, por ejemplo, es una dirección unicast global, que es similar a una dirección pública IPv4 y único a través de Internet, se entrega un paquete de interfaz única a otra interfaz única. Una dirección unicast local es similar a una dirección APIPA que es único a la subred local, de modo que el paquete sólo puede ser enviado a un dispositivo dentro del alcance. Hablaremos más acerca de Dirección IPv6 en el próximo enlace.

Los siguientes ejemplos son direcciones IPv6 unicast:

· Direcciones unicast globales agregables (IPv4 pública )

· Direcciones locales de vínculo (IPv4 APIPA 169.254.xx )

· Unique Local (IPv4 direcciones privadas )

· Direcciones locales del sitio están en cesando formalmente en el RFC 3879

· Direcciones especiales

· Direcciones de compatibilidad

· Direcciones de Transición

Mulitcast - Dirección de un conjunto de interfaces entregado a todas las interfaces del conjunto (paquete se entrega a múltiples interfaces)

Anycast – Dirección de un conjunto de interfaces, pero la entrega es sólo a una única interfaz en el conjunto. Se envía un paquete a la más cercana de múltiples interfaces (en términos de distancia de enrutamiento) .Éste puede ser un poco difícil de entender, pero creo que uno de los mejores ejemplos que se nos ocurrió fue algo así como un servidor proxy, donde usted puede tener varios servidores ubicados en la red, pero sólo desea reenviar paquetes a la más cercanos.

No más broadcast

Nota: ( Técnicamente IPv6 no tiene una dirección de broadcast, pero prácticamente la dirección IPv6 Multicast especial enviará un paquete a todos los nodos en donde obtenemos el mismo resultado , por ejemplo FF02::1)

Eso es todo, esos son los tipos de direcciones IPv6. Ahora vamos a pasar al alcance de ellos .

Alcance de direcciones IPv6

Global Address - El alcance de dirección en su totalidad de IPv6 en el Internet

Una dirección de unicast global es equivalente a una dirección pública IPv4. El alcance es todo IPv6 en el Internet, por lo tanto son globalmente enrutable y pueden utilzarse en la Internet IPv6. La dirección de Internet IPv6 ha sido diseñado desde su creación para mantener el intercambio eficiente, jerárquico de direccionamiento y enrutamiento direcciones de modo de unicast están diseñados para ser agregados o resumidos para facilitar la creación de una infraestructura de enrutamiento eficaz.

· Prefijo de Enrutamiento Global ( parte de la topología de enrutamiento público - junto con 001 prefijo )

· ID de subred ( la topología del sitio )

· Id. de interfaz

Direccion de enlace Local – El alcance de la dirección es un solo enlace

Una direccion IPv6 Unicast son similares a las direcciones IPv4 APIPA utilizados por los equipos que ejecutan Microsoft Windows. Los anfitriones en el mismo enlace (la misma subred) utilizan estas direcciones configuradas automáticamente a comunicarse entre sí. Se requiere una dirección de enlace-local para algunos procesos como "Neighbour Discovery" Descubrimiento de Vecinos y siempre se configura de forma automática, incluso en ausencia de todas las demás direcciones unicast.

· Equivalente a IPv4 dirección APIPA

· FE80 :: / 64 prefijo

· Única subred , configuración sin enrutadores

· Proceso de descubrimiento de vecinos

· Direcciones locales de vínculo son ambiguas por el ID de zona se utiliza

·para identificar la interfaz específica

· IDs de zona sólo se utilizan para las direcciones locales de vínculo desde

· Direcciones enrutables no son ambiguas. Ex. fe80::2b0:d0ff:fee9:4.143%3

· Windows Vista y por encima muestran el identificador de la zona de IPv6

·las direcciones locales en la salida del comando ipconfig.

Local Unico /Sitio de direcciones locales – Alternativa direccionamiento privado globales para el tráfico de la internet

Direcciones locales de sitio proporcionan una alternativa frente a un direccionamiento privado globales para el tráfico de la intranet. Sin embargo debido a que el prefijo de la dirección local de sitio puede ser reutilizado para hacer frente a múltiples sitios dentro de una organización, un prefijo de la dirección local de sitio puede ser duplicado. La ambigüedad de las direcciones locales del sitio en una organización aumenta la complejidad y dificultad para aplicaciones, enrutadores y administradores de red.

En consecuencia, la dirección local de sitio han dejado de utilizarse y las direcciones locales únicas han superado este reto. El objetivo es reemplazar todas las direcciones locales del sitio con un nuevo tipo de direcciones que sería privada a una organización pero a la vez único a través de todos los sitios de la organización. En otras palabras, las direcciones locales únicas tienen un alcance global a la organización, pero su accesibilidad está limitada por las políticas de la topología de enrutamiento y políticas de filtrado en los limitadores de Internet. Las Organizaciones no anunciar sus prefijos de direcciones locales únicas fuera de su organización o crear entradas de DNS para estos por internet.

El ID Global (vea el diagrama a continuacion) identifica un sitio específico dentro de una organización y se establece en un valor aleatorio de 40 bits. Mediante la derivación de un valor aleatorio para el ID Global, una organización puede tener los prefijos de 48 bits estadísticamente únicos asignados a sus sitios. Además, el pensar que dos organizaciones que utilicen direccionamiento local único que pueda ser capaz de entrelazarse tiene una baja probabilidad de duplicar el prefijo de la dirección local única de 48 bits, lo que minimiza la remuneración sitio. A diferencia de los prefijos Global de Enrutamiento utilizados en direcciones globales, los identificadores globales en las direcciones locales no están diseñados para ser resumidos.

Mientras ULAs no tenían el propósito de ser registrado de ninguna forma, aún podría ocurrir que varias organizaciones generen o utilizan el mismo prefijo y, como tal, todavía exista una posibilidad de colisiones. Como resultado, un sitio de registro voluntario ULA se ha establecido en http://www.sixxs.net/tools/grh/ula/ para ayudar a minimizar las colisiones ULA. Claro está esto si todo el mundo utilizara este registro, la posibilidad de colisiones debería estar cerca de cero.

· RFC 4193 define esta dirección local única

· Equivalente a la dirección IPv4 privada

· FD00 :: / 8 prefijo

· Reemplazo para las direcciones locales de sitio

· Alcance global , sin identificación zona requerida

Las direcniones IPv6 especiles

· Sin especificar Dirección

· 0:0:0:0:0:0:0:0 o ::

· Dirección en bucle

· 0:0:0:0:0:0:0:1 o :: 1

Compatibilidad o transición de direcciones

Se utiliza para IPv4 a IPv6. Vamos a tener un próximo blog dedicado a las tecnologías de transición.

· Dirección compatible con IPv4

0:0:0:0:0:0:w.x.y.z or ::w.x.y.z

El w.x.y.z es la representación decimal con puntos de una dirección IPv4 pública), es utilizado por los nodos IPv6 / IPv4 que se están comunicando con IPv6 sobre una infraestructura IPv4 que utiliza direcciones IPv4 públicas, como por ejemplo en el Internet. Direcciones compatibles con IPv4 están en desuso en el RFC 4291 y no son compatibles con IPv6 para Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7 y Windows Vista.

· Direcciones asignadas de IPv4

0:0:0:0:0:FFFF:w.x.y.z or ::FFFF:w.x.y.z

La dirección asignada de IPv4 se utiliza para representar una dirección IPv4 como una dirección IPv6 de 128 bits

· Direcciones 6to4

2002:WWXX:YYZZ,

Una dirección IPv6 6to4 tiene el formato en que WWXX : YYZZ es la representación hexadecimal con dos puntos de w.x.y.z (una dirección IPv4 pública )2002:WWXX:YYZZ::WWXX:YYZZ

· Direcciones ISATAP

Prefijo de 64 bits:0:5EFE:w.x.y.z o prefijo de 64 bits:200:5EFE:w.x.y.z

Una dirección ISATAP de un prefijo de 64 bits: 0:5 EFE : w.x.y.z , donde w.x.y.z es una dirección IPv4 privada y se asigna a un nodo para el Sitio -Intra el direccionamiento automático de túne Protocolo ( ISATAP ) tecnología de transición IPv6..

· Dirección Teredo

Prefijo 2001::/32

Una dirección global que utiliza el prefijo 2001::/32. Teredo está diseñado para funcionar incluso en la presencia de traductores de direcciones de red (NAT).

Mete un Homerun!

Sé que esto ha sido mucho para procesar , pero vamos a volver a la captura de pantalla original y resumen la dirección FE80::d9e:bed6:4917:C7DF%12.

Ahora sabemos cuánto tiempo es (128 bits) y donde de todo el cero fuimos. Sabemos también los diferentes tipos y alcances de las direcciones de IPv6. Traer de vuelta a la pantalla el prefijo FE80 significa que es sólo una dirección de enlace local, que es el equivalente a IPv4 APIPA. La próxima vez que alguien dice esta dirección IPv6 FE80 está causando problemas de enrutamiento sólo tiene que decir , que no es más que una dirección IPv6 APIPA y sorprende a todos con su conocimiento de IPv6. En nuestro próximo post vamos a cubrir algunos temas más avanzados en las direcciones IPv6.

Mark “FE80:Chicago” Morowczynski y Ray “FE80:Minneapolis” Zabilla

Hola, mi nombre es Pierre RICCA, soy un Ingeniero de Campo de Premier (PFE) especializado en Active Directory y scripting de PowerShell. Inicié como PFE en Microsoft Francia en noviembre de 2010. Una parte importante de mi trabajo consiste en realizar revisiones de salud, análisis de riesgos y transferir conocimiento sobre tecnologías Microsoft para nuestros clientes en Francia.

Introducción

En el trabajo de campo, los clientes constantemente solicitan consejos y practicas recomendadas sobre cómo optimizar la resolución de nombres de DNS y, aun cuando la topología de DNS de cada cliente es única, existen algunas recomendaciones generales.

Probablemente sepan que es posible almacenar las zonas de DNS en una instancia de Active Directory si instalan el servidor de DNS en un Controlador de Dominio. Almacenar las zonas de DNS en Active Directory tiene múltiples beneficios: puede tomarse ventaja de la replicación de Active Directory y también permite tener múltiples servidores DNS “maestros” (SOA) para la misma zona de DNS.

Con algunos clientes he visto ambientes en los cuales una sola zona de DNS almacena todos los registros de DNS del forest. El ambiente del cliente está compuesto por un dominio raíz llamado “contoso.com” y algunos dominios hijo llamados “child1.contoso.com”, “child2.contoso.com”, “child3.contoso.com” y “child4.contoso.com”.

Esta imagen muestra como se ve este ambiente en la consola de administración de DNS:

Como pueden ver en el ejemplo, solo existe una zona “forward lookup” (contoso.com), en la cual, cada dominio hijo tiene su sub espacio de nombres para esa zona. Este tipo de configuración típicamente aparecerá si no se instala el rol de “DNS server” antes de ejecutar el DCPROMO para la creación de un nuevo dominio hijo. Notarán que el sub espacio de nombres “_MSDCS” también está almacenado en la zona de DNS padre.

Esta configuración tiene una desventaja principal: Si se instala un DNS server en un dominio hijo, no es posible seleccionar que se almacenen solo los registros específicos para ese dominio hijo, solo será posible almacenar la zona “contoso.com” completa, afectando el desempeño de la replicación de Directorio Activo así como el tamaño de la base de datos.

Para este tipo de ambientes, la mayoría de las veces recomendamos dividir los registros de DNS para cada dominio hijo en zonas de DNS separadas y usar una delegación en la zona de DNS del dominio raíz para cada una de las zonas hijo. La siguiente imagen muestra un ejemplo de la configuración recomendada.

Este artículo presentará una solución para dividir la gran zona del dominio “contoso.com” un sub zonas de DNS específicas para cada dominio hijo.

Historia de la división de zonas de DNS

A partir de Windows Server 2003, cuando se inicia la instalación de un nuevo bosque de Directorio Activo, DCPROMO creara dos zonas de DNS separadas, una llamada "_MSDCS.tudominio.com" y otra llamada "tudominio.com". Aquí hay un ejemplo de mi dominio “dom2k3.com”:

Este comportamiento permite tener diferentes ámbitos de replicación para las diferentes zonas de DNS. Por default, la zona “_MSDCS” del dominio raíz debe ser replicada a “All DNS servers in the Active Directory forest”, mientras que la zona de DNS del dominio debe ser replicada solo a “All DNS servers in the Active Directory domain”. Se pueden revisar y modificar estas opciones en el tab “General” de las propiedades de la zona:

Cuando el bosque se crea en Windows 2000 Server, DCPROMO no separa la zona “_MSDCS” de la zona del dominio raíz y esta zona se almacena directamente en la zona del dominio raíz. Para separar la zona “_MSDCS” y emular el comportamiento por default de “Windows Server 2003”, se debe realizar la división de las zonas de forma manual. El proceso de separación se detalla en el artículo técnico: “How to reconfigure a _MSDCS subdomain to a forest-wide DNS application directory partition when you upgrade from Windows 2000 to Windows Server 2003” http://support.microsoft.com/kb/817470/en-us.

La migración de los registros de DNS del dominio hijo

El artículo técnico mencionado anteriormente (KB 817470) sugiere dividir la zona “_MSDCS” mediante la creación de una nueva zona de DNS “_MSDCS” vacía, después de lo cual se debe forzar a cada controlador de dominio a registrarse en DNS dentro de la nueva zona.

Desafortunadamente, dicho procedimiento no puede ser utilizado en el escenario que hemos planteado, debido a que necesitamos migrar todos los registros existentes de los dominios hijo (incluyendo los registros estáticos), a una nueva zona de DNS dedicada al dominio hijo. En nuestro escenario, cada dominio hijo ha estado corriendo en producción por unos cuantos años y cuenta con unos cuantos miles de registros de DNS para cada dominio hijo. Una recreación manual de estos registros de DNS sería muy complicada y se llevaría mucho tiempo. La única solución que nos queda es utilizar un script!

He aquí el método que utilizamos.

Por favor tomen en cuenta que los scripts presentados en este artículo se proveen como ejemplo y no tienen soporte de parte de Microsoft. Antes de aplicar esta solución, asegúrense de respaldar sus zonas de DNS y estar preparados para hacer una recuperación de las zonas en caso de que suceda algo inesperado. En mi experiencia, esta solución puede tomar unas cuantas horas de principio a fin. Recomiendo encarecidamente aplicar esta solución fuera de horario de trabajo. El proceso automático de registros en DNS no estará disponible durante el tiempo que tome la migración de zonas.

Paso 1: Exportar la zona de DNS.

En primer lugar, necesitamos exportar la zona de DNS actual hacia un archivo. Afortunadamente, el comando “DNSCMD” permite realizar esta tarea. A continuación hay un ejemplo de cómo hacerlo:

Dnscmd /zoneexport contoso.com export.dns

Este commando va a crear un archive llamado “export.dns” debajo de la ruta “%SYSTEMROOT%\DNS\” (por ejemplo: “C:\Windows\system32\dns\export.dns”).

Paso 2: Crear un archivo de DNS específico para cada dominio hijo.

Ahora necesitamos dividir nuestro archivo plano “export.dns” en archivos específicos para cada dominio hijo, también es necesario exportar los registros de DNS de los dominios hijo hacia el archivo correspondiente.

Aquí hay un ejemplo del contenido del archivo “export.dns”:

…

MyComputer1234.child1 [AGE:3606209] 1200 A 172.2.3.4

MyComputer5678 [AGE:1782367] 1200 A 172.5.6.7

MyComputer90AB.child2 [AGE:2457912] 1200 A 172.9.0.1

MyComputerCDEF.child2 [AGE:1982627] 1200 A 172.10.11.12

…

Debemos analizar el archivo “export.dns” a fin de filtrar los registros de DNS correspondientes a los dominios hijo y crear un nuevo archivo de DNS específico para cada dominio hijo.

En el ejemplo anterior, deberíamos extraer la siguiente información para el dominio “child1.dns”:

…

MyComputer1234 [AGE:3606209] 1200 A 172.2.3.4

…

Deberíamos extraer la siguiente información para el dominio “child2.dns”:

…

MyComputer90AB [AGE:2457912] 1200 A 172.9.0.1

MyComputerCDEF [AGE:1982627] 1200 A 172.10.11.12

…

Noten que el registro “MyComputer1234.child1” del archivo “export.dns” debe ser convertido a “MyComputer” (sin “.child1”) cuando sea copiado hacia el archivo “child1.dns” (y lo mismo se debe tener en cuenta para los registros en child2). Noten también que el registro “MyComputer5678” del archivo “export.dns” es un registro presente directamente en el dominio raíz “contoso.com” y no debe ser copiado hacia ningún archivo de DNS de los dominios hijo.

He creado un script de ejemplo que puede extraer y convertir automáticamente dichos registros de DNS y exportar el resultado en los archivos “child.dns”. Por favor tomen en cuenta que este script es provisto como ejemplo y no tiene soporte de parte de Microsoft. Aquí hay un ejemplo de cómo usarlo:

.\Extract-DNSZone.PS1 -inputFile “C:\Scripts\export.dns” -outputFile “C:\Scripts\child1.contoso.com.ns” -extractZoneName "child1"

Pueden repetir esta operación para cada dominio hijo.

Paso 3: Importar las zonas de DNS de los dominios hijo

Ahora deberíamos tener un archivo de DNS específico para cada zona de cada dominio hijo (generada en el paso previo).

Es necesario importar estos archivos de los dominios “hijo” al servidor DNS. Primero hay que copiar dichos archivos al folder “%SYSTEMROOT%\DNS\” (por ejemplo: “C:\Windows\system32\dns\”).

Entonces hay que abrir la consola de administración de DNS. Dar clic derecho en “Forward Lookup Zones” y seleccionar “New Zone…”.

Dar clic en “Next”, después seleccionar “Primary zone” y asegurarse de que la opción “Store the zone in Active Directory” no este seleccionada (porque queremos cargar la zona desde un archivo) y dar clic en “Next”.

Introducir el nombre de la zona correspondiente al dominio hijo que vamos a importar (por ejemplo: child1.contoso.com) y dar clic en “Next”.

Seleccionar la opción “Use this existing file” y verificar que el nombre corresponda al nombre del archive de DNS del dominio hijo que vamos a importar, después de lo cual, dar clic en “Next”.

Seleccionar “Do not allow dynamic updates” (no queremos permitir las actualizaciones dinámicas mientras nuestro proceso de migración no haya terminado) después dar clic en “Next” y luego dar clic en “Finish”. Las actualizaciones dinámicas pueden habilitarse al final del proceso de migración de nuestras zonas de DNS.

Es necesario repetir esta operación para cada uno de los dominios hijo. Ahora, desde la consola de administración de DNS, deberían verse el dominio raíz y los dominios hijo con zonas de DNS independientes.

Paso 4: Replicar las zonas de DNS de los dominios hijo hacia todos los servidores de DNS en el bosque

En este paso, vamos a habilitar la replicación de las zonas de DNS de los dominios hijo hacia todos los servidores de DNS en el bosque. El alcance de replicación de cada zona se puede cambiar a “domain wide” al final del proceso de migración de nuestras zonas de DNS.

Desde la consola de administración de DNS, dar clic derecho en una de las zonas de DNS de un dominio hijo y abrir las propiedades de la zona.

Dar clic en el botón “Change” que esta junto al texto “Type: Primary”. Habilitar la opción “Store the zone in Active Directory” y dar clic en “OK”. Dar clic en “Yes” cuando solicite confirmación para integrar la zona a Directorio Activo.

A continuación, dar clic en el botón “Change” que aparece junto al texto “Replication: All DNS servers in this domain”. Seleccionar la opción “To all DNS servers running on domain controllers in the forest” y dar clic en “OK”.

He aquí un resumen de la configuración que deberían tener:

Dar clic en “OK” y repetir este mismo procedimiento para cada una de las zonas de los dominios hijo.

Paso 5: Restaurar las ACL (listas de control de acceso) de los registros de DNS

Ahora necesitamos restablecer los permisos (ACL) de los registros de DNS. Esto es especialmente importante si quieren configurar las actualizaciones dinámicas de DNS de forma segura. Cuando las actualizaciones dinámicas de DNS son configuradas como “seguras”, el servidor de DNS revisará las ACL de los registros de DNS para verificar si el servidor miembro del dominio tiene los permisos para modificar un registro de DNS en particular.

Desafortunadamente, el comando “DNSCMD /zoneexport” no exporta la información de las ACLs. Por eso es necesario que copiemos las ACLs de los registros desde la “vieja” zona del dominio raíz hacia el registro DNS correspondiente en la nueva zona de DNS del dominio hijo. Una vez más, he creado un script de ejemplo para realizar esto. Este script require del modulo de PowerShell para Directorio Activo, el cual puede ser instalado como una característica opcional de Windows Server (Optional Features) o puede ser instalado en un cliente Windows como parte de las herramientas de administración remota (Remote Server Administration Tools). Por favor tomen en cuenta que este script es provisto como ejemplo y no tiene soporte de parte de Microsoft. Aquí hay un ejemplo de cómo utilizarlo:

.\Copy-DNSACL.ps1 -SourceZoneDN "DC=contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=contoso,DC=com" -TargetZoneDN "DC=child1.contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=contoso,DC=com" -TargetDNSZoneShortName "child1"

Aquí hay un ejemplo del resultado del script:

Hay que repetir este paso para cada una de las zonas de los dominios hijo. Ahora, si observan en el tab de “Security” de las propiedades de un registro de DNS, podrán ver que el servidor miembro del dominio tiene control total (full control) sobre sus registros.

Paso 6: Habilitar nuevamente las actualizaciones dinámicas

Su el ambiente en que están trabajando utiliza actualizaciones dinámicas es momento de volver a habilitarlas. Para lo anterior hay que ir al tab “General” de las propiedades de la zona de DNS del dominio hijo y seleccionar “Secure only” o “Nonsecure and secure” del combo que esta junto al texto “Dynamic Updates” (si no estan seguros, pueden usar la misma configuración que tiene la zona de DNS raíz).

Paso 7: Limpiar los registros de DNS “viejos” y delegar las zonas de DNS de los dominios hijo

Antes de limpiar los registros de DNS viejos, deben asegurarse de:

- Tener un respaldo de la “vieja” zona de DNS y ser capaces de recuperarla.

- Que la resolución de DNS este trabajando apropiadamente tanto para los registros de la zona raíz, como para los registros de las zonas de DNS de los dominios hijo.

- Que las actualizaciones dinámicas esten trabajando adecuadamente.

- Que no se haya identificado ningún problema hasta ahora.

Para limpiar los registros viejos, hay que abrir la consola de administración de DNS y expandir la “vieja” zona de DNS del dominio raíz. (¡Asegúrense de que no vayan a borrar la nueva zona de DNS del dominio hijo!) Dar clic derecho en la sub zona “child1” bajo la zona raíz y seleccionar “Delete”.

Ahora la sub zona “Child1” ha desaparecido de las “sub zonas” debajo de “contoso.com”, pero la nueva zona “child1.contoso.com” aún está presente como una zona de DNS independiente.

Para que los servidores de DNS que hospedan la zona “contoso.com” pero que no hospedan la zona “child1.contoso.com” sean capaces de resolver esta última, es necesario crear una delegación para la zona “child1” desde la zona “contoso.com”. Para lo anterior, dar clic derecho sobre la zona “contoso.com” y seleccionar “New delegation…”.

Dar clic en “next” y digitar el nombre del dominio hijo (por ejemplo: child1) y dar clic en “Next”.

De la lista que aparece en la pantalla “Name Servers”, agregar todos los servidores que están hospedando la zona “child1.contoso.com” (esta podría ser una lista larga, dependiendo del tamaño del ambiente en el que estén trabajando), después dar clic en “Next” y dar clic en “Finish”.

Ahora se puede ver “child1 como una delegación de “contoso.com” en la consola de administración de DNS.

Es necesario repetir esta operación para cada uno de los dominios hijo. Al final, en la consola de administración de DNS se debe ver algo como esto:

¡Buen trabajo! ¡el proceso de migración ha finalizado! Ahora ya se puede cambiar el alcance de replicación para las zonas de los dominios hijo si lo desean. Como ultima tarea deben revisar que la lista de los registros NS sea coherente para todas las zonas de DNS. También pueden considerar volver a habilitar las opciones de “Aging” y “Scavenging” para estas nuevas zonas si así lo desean.

12-6-13- Puedes encontrar los scripts en el repositorio de TechNet. 

http://gallery.technet.microsoft.com/scriptcenter/Copy-ACL-of-DNS-records-97837128

http://gallery.technet.microsoft.com/scriptcenter/Extract-a-specific-DNS-dc633d77

-Pierre Ricca