Network Working Group A. Durand Request for Comments: 3901 SUN Microsystems, Inc. BCP: 91 J. Ihren Category: Mejor Practica Actual Autonomica September 2004 Traducción: Oscar Alberto Walther Pautas Operacionales Del Transporte Dns de IPv6 Estado de esta nota Este documento especifica las Mejores Prácticas Actuales en Internet para la Comunidad de Internet, y solicita la discusión y sugerencias para mejorarla. La distribución de esta nota es ilimitada. Mención de propiedad intelectual Copyright (C) The Internet Society (2005). Resumen Esta nota proporciona pautas y la mejor Práctica Corriente para hacer funcionar DNS en un mundo donde las preguntas y las respuestas son llevadas en un ambiente mixto de redes de IPv6 e IPv4. 1. Introducción al problema de la fragmentación del espacio de nombres: despues de la cadena de remision Una resolución que trata de buscar un nombre comienza con root, y sigue remisiones hasta que sea enviado a un servidor de nombre que es autoritario para el nombre.Si en algún sitio debajo de la cadena de remisiones es enviado a un servidor de nombre que es sólo accesible sobre un transporte que la resolución no puede usar, la resolución es incapaz de terminar la tarea. Cuando Internet se mueva desde IPv4 a una mezcla de IPv4 y de IPv6 es solamente cuestión de tiempo hasta que esto comience a suceder. La jerarquía completa DNS entonces comienza a fragmentarse en un gráfico donde servidores de nombre autoritarios para ciertos nodos son sólo accesibles sobre un cierto transporte.La preocupación es que una resolución usando sólo una versión particular de IP y preguntando la información sobre otro nodo usando la misma versión de IP no puede hacerse porque en algún sitio en la cadena de servidores que se a tenido acceso durante el proceso de resolución, uno o varios de ellos sólo serán accesibles con la otra versión de IP. Con todos los datos DNS sólo disponibles sobre el transporte de IPV4 todo es simple. La resolución de IPv4 puede utilizar el mecanismo previsto de remisiones siguientes de Root y Down mientras que la resolución de IPv6 tienen que trabajar Durand & Ihren Best Current Practice [Page 1] RFC 3901 Pautas de Transporte de Dns IPv6 September 2004 a traves de un "traductor", es decir, ellos tienen que usar a un servidor de nombre recurrente en una llamada "dual stack" como host "forwarder" ya que ellos no pueden tener acceso a los datos DNS directamente. Con todos los datos DNS sólo disponibles sobre el transporte de IPv6 todo sería igualmente simple, a excepción de servidores de nombre recurrentes IPv4 que tienen que cambiar a una configuración de transporte Sin embargo, la segunda situación no se presentará en el futuro próximo. En cambio, la transición será de IPv4 sólo a una mezcla de IPv4 e IPv6, con tres categorías de datos DNS según si la información está disponible sólo sobre el transporte de IPv4, o sólo sobre IPv6 o ambos. Tener datos del DNS disponibles en ambos transportes es la mejor situación. La pregunta principal es cómo asegurarse de que se convierte a la norma lo más rápidamente posible. Sin embargo, mientras es obvio que algunos datos DNS sólo estarán disponibles sobre el transporte de v4 durante mucho tiempo es también obvio que es importante evitar fragmentar el espacio de nombre disponible solo para host IPv4. Por ejemplo, durante la transición no es aceptable romper el espacio de nombre que actualmente tenemos disponible solo para los host IPv4. 2. Terminología La frase "IPv4 servidor de nombre" indica a un servidor de nombre disponible sobre el transporte de IPv4.Esto no implica nada sobre que DNS [1,2] los datos son servidos.Igualmente, "IPv6 [4,5,6] el servidor de nombre" indica a un servidor de nombre disponible sobre el transporte de IPv6. La frase "servidor de nombre de dual-stackl" indica a un servidor de nombre que realmente es configurado para dirigir ambos protocolos, IPv4 and IPv6, y no simplemente un servidor que corre en un sistema capaz de correr ambos pero realmente configurado para correr uno sólo. 3. Policy Based Avoidance of Name Space Fragmentation Hoy hay sólo unas "zonas" DNS en Internet pública que están disponibles sobre el transporte de IPv6, y la mayor parte de ellos pueden ser considerados como "experimentales". Sin embargo, tan pronto como los dominios de root y los dominios de nivel superiores esten disponibles sobre el transporte de IPV6, es razonable de esperar que se hará más común tener zonas servidas por servidores IPV6. Teniendo aquellas zonas servidas sólo por servidores de nombres IPv6 no sería un buen desarrollo, ya que esto fragmentará IPV4 anteriormente no fragmentado y hay razones fuertes de encontrar un mecanismo para evitarlo. Durand & Ihren Best Current Practice [Page 2] RFC 3901 Pautas de Transporte de Dns IPv6 September 2004 El acercamiento recomendado para mantener la continuidad del espacio de nombres es usar la política administrativa, según lo descrito en la siguiente sección. 4. Pautas recomendadas para el transporte DNS IPv6 A fin de conservar continuidad de espacio de nombre, las siguiente políticas administrativas son recomendadas: -cada servidor de nombre recurrente DEBERÍA ser solo IPv4 o dual stack Esto elimina los servidores recurrentes de IPv6 solamente. Sin embargo, uno podría diseñar configuraciones donde una cadena de servidores de nombre de IPv6 remita las preguntas a un sistema de servidores de nombre recurrente dual stack que realiza realmente esas preguntas recurrentes - cada zona DNS DEBERÍA ser servida por al menos un servidor de nombre accesible autoritario de IPv4. Esto elimina las zonas de DNS servidas solamente por los servidores de nombres autoritarios de IPv6. Nota: los procesos de validación de zona DEBERÍAN asegurar que hay al menos un registro de dirección de IPv4 disponible para los servidores de nombre de cualquier delegación infantil dentro de la zona. 5. Consideraciones de Seguridad Las pautas descritas en esta nota no introducen ninguna nueva consideración de seguridad en el protocolo del DNS o los panoramas operacionales asociados. 6. Reconocimiento Este documento es el resultado de muchas conversaciones que pasaron en la comunidad DNS en IETF y en otra parte desde 2001. Durante ese período del tiempo, un número de bosquejos del Internet se han publicado para clarificar los varios aspectos de las ediciones en juego. Este documento se concentra en la conclusión de aquellas discusiones. Los autores quisieran reconocer el papel de Pekka Savola en su revisión cuidadosa del documento Durand & Ihren Best Current Practice [Page 3] RFC 3901 Pautas de Transporte de Dns IPv6 September 2004 7. Normas de Referencia [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. 8. Las Direcciones de los Autores Alain Durand SUN Microsystems, Inc 17 Network circle UMPK17-202 Menlo Park, CA, 94025 USA EMail: Alain.Durand@sun.com Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden EMail: johani@autonomica.se Durand & Ihren Best Current Practice [Page 4] RFC 3901 Pautas de Transporte de Dns IPv6 September 2004 Declaración Completa de Derechos de autor Copyright (C) The Internet Society (2005). Este documento es sujeto a los derechos, licencias y restricciones contenidas en BCP 78, y excepto como puesto en adelante allí, los autores conservan todos sus derechos. Este documento está conforme a las derechas, a las licencias y a las restricciones contenidas en BCP 78, y excepto como dispuesto en esto, los autores conservan todos sus derechos. Este documento y la información contenida en el se proporcionan en su forma "TAL CUAL ES" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK FORCE NIEGAN TODAS LAS GARANTIAS, EXPRESAS O IMPLICITAS, INCLUYENDO, PERO NO LIMITADO A CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACION AQUI EXPUESTA NO INFRINJA NINGUN DERECHO O CUALQUIER GARANTIA IMPLICITA DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECIFICO. La Propiedad intelectual El IETF no toma ninguna posición en cuanto a la validez o el alcance de cualquier Derecho de Propiedad intelectual u otros derechos que podrían ser reclamados para pertenecer a la puesta en práctica o el empleo de la tecnología descrita en este documento o el grado al cual cualquier licencia bajo tales derechos podría o no podría estar disponible; tampoco esto representa esto esto ha hecho cualquier esfuerzo independiente para identificar cualquier tal derecho. La Información sobre los procedimientos en lo que concierne a derechos en documentos RFC puede ser encontrada en BCP 78 Y BCP 79. Las copias de los accesos de IPR hechos a la secretaría del IETF y a cualquier aseguramiento de licencias de ser hecho disponible, o el resultado de una tentativa hecha para obtener una licencia o un permiso general para el uso de las tales derechas propietarias por los ejecutores o los usuarios de esta especificación se pueden obtener del depósito en línea del IETF IPR en http://www.ietf.org/ipr. El IETF invita a cualquier parte interesada a traer su atención a cualquier derecho de autor, patentes o usos evidentes, u otro derecho de propiedad que puede cubrir la tecnología para poner en práctica este estándar. Por favor dirija la información al IETF en ietf-ipr@ietf.org. Reconocimiento El financiamiento para el editor del RFC es actualmente proporcionado por la 'Internet Society.' Traducción al castellano Grupo de traducción de RFC al español: http://www.rfc-es.org Octubre 2005 Oscar Alberto Walther Cent. Uruguayo 442 1874 Buenos Aires Agentina Tel: (+5411) 4207-7481 Correo-e: oscaraw@gmail.com Durand & Ihren Best Current Practice [Page 5]