Network Working Group S. Thomson Request for Comments: 2462 Bellcore Obsoletes: 1971 T. Narten Categoría: Standards Track IBM Diciembre 1998 Configuración Automática sin Estado de Direcciones IPv6 Estado de esta Nota: This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Resumen Este documento especifica los pasos tomados por una máquina cuando determina cómo autoconfigurar sus interfases en IP versión 6. El proceso de autoconfiguración incluye la creación de una dirección de enlace local y la verificación de su unicidad en un enlace, determinando qué información debe ser autoconfigurable (dirección, otra información o ambas), y en el caso de direcciones si serán obtenidas mediante el proceso sin estados, con estados o ambos. Este documento define el proceso para generar una dirección de enlace el proceso para generar direcciones locales y globales mediante autoconfiguración sin estado y el proceso de detección de direcciones duplicadas. Los detalles de la autoconfiguración mediante el protocolo con estado se especifican en otro lugar. Indice 1. INTRODUCCIÓN............................................. 2 2. TERMINOLOGÍA............................................. 4 2.1. Requisitos.......................................... 6 3. OBJETIVOS DE DISEÑO...................................... 7 4. DESCRIPCIÓN DEL PROTOCOLO............................... 8 4.1. Renumeración de instalaciones....................... 10 5. ESPECIFICACIÓN DEL PROTOCOLO............................. 10 5.1. Variables de configuración de los nodos............. 11 5.2. Variables relacionadas con la autoconfiguración..... 11 5.3. Creación de Direcciones de enlace locales........... 12 Thomson & Narten Standards Track [Page 1] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 5.4. Detección de Direcciones Duplicadas................. 13 5.4.1. Validación de Mensajes......................... 14 5.4.2. Enviando Mensajes de Solicitud de Vecino....... 14 5.4.3. Recibiendo Mensajes de Solicitud de Vecino..... 15 5.4.4. Recibiendo Mensajes de Anuncio de Vecino....... 16 5.4.5. Fallo en la Detección de Direcciones Duplicadas 16 5.5. Creación de Direcciones Globales y Locales.......... 16 5.5.1. Solicitando Anuncios de Router................. 16 5.5.2. Ausencia de Anuncios de Router............. 17 5.5.3. Procesado de las Anuncios de Router............ 17 5.5.4. Caducidad de la Vida de las Direcciones........ 19 5.6. Consistencia de la Configuración.................... 19 6. CONSIDERACIONES DE SEGURIDAD............................. 20 7. Referencias.............................................. 20 8. Agradecimientos y Direcciones de los Autores............. 21 9. APÉNDICE A: SUPRESIÓN DE LOOPBACK Y DETECCIÓN DE DIRECCIONES DUPLICADAS................................. 22 10. APÉNDICE B: CAMBIOS DESDE RFC 1971....................... 24 11. Cláusula de Copyright Completa........................... 25 1. INTRODUCCIóN Este documento especifica los pasos tomados por una máquina cuando determina cómo autoconfigurar sus interfases en IP versión 6. El proceso de autoconfiguración incluye la creación de una dirección de enlace local y la verificación de su unicidad en un enlace, determinando qué información debe ser autoconfigurable (dirección, otra información o ambas), y en el caso de direcciones si serán obtenidas mediante el proceso sin estados, con estados o ambos. Este documento define el proceso para generar una dirección de enlace el proceso para generar direcciones locales y globales mediante autoconfiguración sin estado y el proceso de detección de direcciones duplicadas. Los detalles de la autoconfiguración mediante el protocolo con estado se especifican en otro lugar. IPv6 define mecanismos de autoconfiguración de dirección tanto con estado como sin estado. La autoconfiguración sin estado no requiere configuación manual de servidores, configuración mínima (si acaso) de routers y ninguna de servidores adicionales. El mecanismo sin estado permite que una máquina genere su propia dirección mediante una combinación de infomación disponble localmente y anunciada por los routers. Los routers anuncian prefijos que identifican la(s) subred(es) asociada(s) a un enlace y las máquinas generan "identificadores de interfaz" que identifican unívocamente a un interfaz en una subred. La dirección se forma combinando ambos. Si no hay routers, una máquina tan sólo puede generar direcciones de enlace local. Sin embargo, las direcciones de enlace local son bastante para permitir la comunicación entre nodos conectados al mismo enlace. Thomson & Narten Standards Track [Page 2] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 En el modelo de configuración con estado, las máquinas obtienen direcciones de interfaz y/o información de configuración y parámetros de un servidor. Los servidores mantienen una base de datos que lleva un registro de qué direcciones han sido asignadas a qué máquina. El protocolo de configuración con estado permite a la máquinas obtener direcciones, información de configuración o ambas de un servidor. La configuración automática con estado y sin estado son complementarias. Por eemplo, una máquina puede usar configuración sin estado para configurar sus direcciones y usar configuración con estado para obtener el resto de información. La configuración con estado es objeto de trabajo posterior [DHCPv6]. La aproximación sin estado se usa cuando una instalación no se preocupa demasiado de las direcciones exactas que usa cada máquina mientras sean únicas y rutables. La aproximación con estado se usa cuando una instalación requiere un control más fino de las asignación de direcciones. Ambos mecanismos, con y sin estado, pueden ser usados simultaneamente. El administrador de la instalación especifica qué tipo de autoconfiguración usar mediante la configuración de los campos apropiados de los mensajes de anuncio de los routers [DISCOVERY]. Las direcciones IPv6 se ceden a un interfaz por un tiempo determinado (puede ser infinito). Cada dirección tiene un tiempo de vida asociado que indica por cuánto tiempo se asocia una direccion con un interfaz. Cuando un tiempo de vida acaba, la asociación (y la dirección) se vuelven inválidas y la dirección puede ser reasignada a otro interfaz cualquiera en Internet. Para gestionar las asociaciones que expiran con estilo, una dirección pasa por dos fases distintas cuando es asignada a un interfaz. Inicialmente, una dirección es "preferida", lo que quiere decir que se puede usar sin restricciones para cualquier comunicación. Más tarde, las direcciones se "desaprueba" anticipandose a la inminente caducidad de la asociación al interfaz. Mientras una dirección esté en estado desaprobado, se desalienta el uso de la dirección, aunque no se prohibe estrictamente. Nuevas comunicaciones (p.e. abrir una nueva conexión TCP) debería usar una dirección preferida siempre que sea posible. Una dirección obsoleta debería ser usada sólo por aquellas aplicaciones que han estado usándola y pudieran tener problema para cambiarla sin interrumpir el servicio. Para asegurar que todas las direcciones configuradas sean únicas en un enlace dado, los nodos ejecutan un algoritmo de "detección de dirección duplicada independientemente de si son obtenidas mediante autoconfiguración con estados o sin ellos. Este documento define el algoritmo de Detección de Direcciones Duplicadas. Thomson & Narten Standards Track [Page 3] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 El proceso de autoconfiguración que se especifica en este documento aplica sólamente a máquinas y no routers. Ya que la autoconfiguración descrita aquí usa información anunciada por routers, éstos deben ser configurados de otro medio. Sin embargo, se espera que los routers generen direcciones de enlace local usando el mecanismo descrito en este documento. Además los routers deberían pasar el proceso de Detección de Direcciones Duplicadas que se describe aquí antes de asignarlas a un interfaz. En la Sección 2 se dan definiciones de la terminología usada en el documento. La Sección 3 describe los objetivos de diseño que llevan al proceso de autoconfiguración actual. La Sección 4 introduce el protocolo y la Sección 5 lo describe en detalle. 2. TERMINOLOGÍA IP - Internet Protocol Versión 6. Los términos IPv4 y se usan <<<--- ojo: en la RFC original faltaba lo de después del y ;-) sólo cuando sea necesario para evitar ambigüedades. nodo - un dispositivo que implemente IP. router - un nodo que reenvía los paquetes IP que no vayan explícitamente dirigidos a él. máquina - los nodos que no son routers. capa superior - capa de protocolo inmediatamente encima de IP. Por ejemplo, protocolos de transporte como TCP y UDP, protocolos de control como ICMP, protocolos de rutado como OSPF y protocolos de internet o de capas mas bajas que son "tunelizados" sobre (es decir, encapsulados en) IP, como IPX, Appletalk o el mismo IP. enlace - medio o facilidad de comunicación sobre el que los nodos pueden comunicarse en la capa de enlace, es decir, la capa inmediatamente encima de IP. Sirvan como ejemplo Ethernet (simple o puenteada), enlaces PPP, X.25, Frame Relay ,redes ATM, "túneles" de capa internet (o superior) como túneles sobre IPv4 o IPv6 mismo. interfaz - punto de conexión de un nodo con un enlace. paquete - una cabecera IP mas su carga. dirección - identificador de un interfaz o conjunto de ellos en la capa IP. dirección unicast - identificador de un sólo interfaz. Un paquete enviado a una dirección unicast es entregado al interfaz identificado por esa dirección. Thomson & Narten Standards Track [Page 4] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 dirección multicast - un identificador para un conjunto de interfaces (típicamente pertenecientes a distintos nodos). Un paquete enviado a una dirección multicast es entregado a todos los interfaces identificados por esa dirección. dirección anycast - un identificador para un conjunto de interfaces (típicamente pertenecientes a distintos nodos). Un paquete enviado a una dirección multicast se entrega a uno de los interfaces identificado por esa dirección (el "mas cercano", según la medida de distancia del protocolo de rutado). Ver ADDR-ARCH]. dirección multicast de nodo solicitado - una dirección multicast a la que se envían los mensajes de Solicitud de Vecino. El algoritmo para calcular la dirección se da en [DISCOVERY]. dirección de capa de enlace - identificador de un interfaz en la capa de enlace. Como ejemplo, las direcciones IEEE 802 de Ethernet y E.164 de los enlaces RDSI. dirección de enlace local- direcciones que sólo tienen ámbito en el enlace local y se usan para alcanzar los nodos vecinos que estén conectados al mismo enlace. Todos los interfaces tienen una dirección unicast de enlace local. dirección local de instalación - una dirección cuyo ámbito está limitado a la instalación local. dirección global - una dirección con ámbito ilimitado. comunicación - cualquier intercambio de paquete entre nodos requiere que la dirección de cada nodo usado en el intercambio permanezca igual mientras dure el intercambio de paquetes. Algunos ejemplos son las conexiones UDP o una petición - respuesta UDP. dirección tentativa - una dirección cuya unicidad en un enlace está siendo verificada, antes de asignarla a un interfaz. Una dirección tentativa no se considera asignada a un interfaz en el sentido común. Un interfaz descarta los paquetes recibidos dirigidos a una dirección tentativa, pero acepta los paquetes de Descubrimiento de Vecino relacionados con la Detección de Direcciones Duplicadas dirigidos a la dirección tentativa. dirección preferida - una dirección asignada a un interfaz con el uso por capas superiores sin restricciones. Las direcciones preferidas pueden ser usadas como direcciones origen (o destino) de paquetes enviados desde (o hacia) el interfaz. Thomson & Narten Standards Track [Page 5] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 dirección obsoleta - dirección asignada a un interfaz cuyo uso se evita, pero no se prohibe. Una dirección obsoleta no debe usarse más como dirección de origen para comunicaciones nuevas, pero los paquetes enviados de o hacia direcciones obsoletas son entregados normalmente. Una dirección obsoleta puede seguir siendo usada como dirección origen en aquellas comunicaciones en las que el cambio a una dirección preferida sea problemático para las capas superiores (como las conexiones TCP abiertas) dirección válida - una dirección preferida o obsoleta. Una dirección válida puede aparecer como la dirección origen o destino de un paquete, y el sistema de rutado de internet debe entregar los paquetes enviados a direcciones válida a los destinos supuestos. dirección inválida - una dirección que no es asingada a ningún interfaz. Una dirección válida se vuelve invalida cuando expira su tiempo de vida. Las direcciones inválidas no deben aparecer como origen o destino de un paquete. En este último caso, el sistema de rutado internet será incapaz de entregar el paquete, en el caso anterior el recipiente del paquete no podrá responder al destinatario. tiempo de vida preferido - cantidad de tiempo en el que una dirección es preferida (es decir, el tiempo hasta desaprobarla). Cuando el tiempo de vida preferido expira, la dirección se desapureba. tiempo de vida válido - cantidad de tiempo en el que una dirección es válida (es decir, el tiempo hasta invalidarla). El tiempo de vida válido debe ser mayor o igual al preferido. Cuando el tiempo de vida expira, la dirección se invalida. identificador de interfaz - identificador dependiente del enlace para un interfaz que (al menos) es único por enlace ADDR-ARCH]. La autoconfiguración sin estado combina un identificador de interfaz con un prefijo para formar una dirección. Desde el punto de vista de la autoconfiguración de direcciones, un identificador de interfaz es una cadena de bits de longitud conocida. La longitud exacta del identificador de enlace y la forma en que se crea se definen en un documento aparte específico para el tipo de enlace que cubre los temas relacionados con la transmisión de IP sobre un tipo particular de enlace (por ejemplo [IPv6-ETHER]). En muchos casos, el identificador será el mismo que la dirección de enlace del interfaz. 2.1. Requisitos Las palabras DEBE, NO DEBE, REQUERIDO, (SHALL, SHALL NOT,) DEBERIA, <- shall verbo auxiliar: problemilla :-? NO DEBERIA, RECOMENDADO, PUEDE y OPCIONAL, cuando aparezcan en este documento, deben interpretarse como se describe en [KEYWORDS]. Thomson & Narten Standards Track [Page 6] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 3. OBJETIVOS DE DISEÑO La autoconfiguración sin estado se diseña pensando en los siguientes objetivos: o No debería ser necesario configurar máquinas antes de onectarlas a la red. Consecuentemente, se necesita un mecanismo que permita a una máquina obtener o crear direcciones únicas para cada uno de sus interfaces. La autoconfiguración de direcciones asume que cada interfaz puede proveer un identificador único para ese interfaz (es decir, un "identificador de interfaz"). En el caso mas simple, un identificador de interfaz consiste en la dirección de enlace. Un identificador de interfaz puede ser combinado con un prefijo para formar una dirección. o Instalaciones pequeñas consistentes en un conjunto de máquinas compartiendo un enlace no deberían necesitar un servidor con estado o un router como prerequisito para comunicarse. La comunicación conectar y usar se consigue mediante el uso de direcciones de enlace local. Las direcciones de enlace local tienen un prefijo conocido que identifica el (único) enlace compartido al que el conjunto de nodos se conecta. Una máquina forma una dirección de enlace local añadiendo su identificador de enlace al prefijo local de enlace. o Una instalación grande, con muchas redes y routers no debería necesitar la presencia de un servidor con estado. Para generar direcciones locales a la instalación o globales, las máquinas deben determinar los prefijos que identifican las subredes a las que se conectan. Los routers generan Anuncios de Router periódicos que incluyen opciones listando el conjunto de prefijos activos en un enlace. o La configuración de direcciones debería facilitar la enumeración elegante de las máquinas de una instalación. Por ejemplo, una instalación puede querer renumerar todos los nodos cuando cambia de proveedor de servicio. La renumeración se consigue a través de la cesión de direcciones a interfases y la asignación de múltiples direcciones al mismo interfaz. El tiempo de cesión proporciona el mecanismo mediante el que una instalación desfasa prefijos viejos. La asignación de direcciones múltiples a un interfaz proporciona un periodo de transición durante el que tanto la dirección nueva como la desfasada funcionan simultaneamente. o Los administradores de sistemas necesitan la capacidad de especificar si se usa la autoconfiración con estado, sin estado o ambas. Los anuncios de router incluyen testigos especificando qué mecanismos debe usar una máquina. Thomson & Narten Standards Track [Page 7] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 4. DESCRIPCIÓN DEL PROTOCOLO Esta sección describe someramente los pasos típicos que se dan cuando un interfaz se autoconfigura. La autoconfiguración se ejecuta sólo en enlaces con capacidad de multicast, y comienza cuando un interfaz con capacidad multicast se activa, por ejemplo, en el arranque. Los nodos (tanto máquinas como routers) comienzan el proceso de autoconfiguración genrando una dirección de enlace local para el interfaz. Una dirección de enlace local se forma añadiendo el indentificador del interfaz al prefijo del enlace local ya conocido. Antes de que puedan asignarse direcciones de enlace local a un interfaz y sean usadas un nodo debe intentar verificar que esta dirección "tentativa" no está en uso ya por otro nodo del enlace. Especificamente, envía un mensaje de Solicitud de Vecino conteniendo la dirección tentativa como el destino. Si otro nodo ya está usando esa dirección, devolverá un Anuncio de Vecino diciéndolo. Si otro nodo está intentando usar esa dirección, enviara una Solicitud de Vecino para el destino también. El número exacto de veces que se (re)transmite la Solicitud de Vecino y el tiempo de retraso entre solicitudes consecutivas es específico del enlace y puede ser fijado mediante la gestión del sistema. Si un nodo determina que su dirección de enlace local tentativa no es única, se detiene la autoconfiguración y se requiere la configuración manual del enlace. Para simplificar la recuperación en este caso, debe ser posible que un administrador pueda forzar un identificador de interfaz alternativo que sustituya al identificador por defecto, de manera que el mecanismo de autoconfiguración pueda ser aplicado de nuevo usando el nuevo (supuestamente único) identificador de interfaz. De otro modo, las direcciones de enlace local (y otras) deberán ser configuradas a mano. Una vez que un nodo asegura que su dirección de enlace local tentativa es única, la asigna al interfaz. En este momento, el nodo tiene conectividad a nivel IP con los nodos vecinos. Los pasos restantes de la autoconfiguración son ejecutados sólo por las máquinas; la (auto)configuración de routers está fuera del alcance de este documento. La siguiente fase de la autoconfiguración implica obtener un Anunci de Router o concluir que no hay routers alrededor. Si hay routers, enviarán un Anuncio de Router que especifica qué tipo de autoconfiguración debería hacer una máquina. Si no hay routers, debe invocarse la autoconfiguración con estado. Los routers envían Anuncios de Router periodicamente, pero el retraso entre anuncios sucesivos generalmente será mayor que el que quisiera esperar una máquina ejecutando la autoconfiguración [DISCOVERY]. Para obtener un anuncio rápidamente, un host envía una o mas Solicitudes Thomson & Narten Standards Track [Page 8] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 de Router al grupo de multicast todos-los-routers. Los Anuncios de Routers contienen dos testigos indicando qué tipo de autoconfiguración con estado (si aplica) debe usarse. Un testido de "configuración de dirección gestionada" indica si las máquinas deben usar la autoconfiguración con estado para obtener direcciones. Un testigo de "otra configuración con estado" indica si las máquinas deben usar autoconfiguración con estado para obtener información adicional (excluyendo direcciones). Los Anuncios de Routers también contienen cero o mas opciones de Información de Prefijo que contienen información usada por la autoconfiguración de dirección sin estado para generar direcciones de enlace local y globales. Debe notarse que los campos de la autoconfiguración con y sin estado en los Anuncios de Router son procesados independientemente uno del otro, pudiendo una máquina usar tanto autoconfiguración con estado como sin estado simultaneamente. Un campo de opción Información de Prefijo, el "testigo de configuración de dirección autónoma", indica si la opción se aplica o no a la autoconfiguración sin estado. Si lo hace, los campos de opciones adicionales contienen un prefijo de subred junto con un valor de tiempo de vida indicando por cuanto tiempo las direcciones creadas con el prefijo permanecen preferidas y válidas. Ya que los routers generan Anuncios de Router periodicamente, las máquinas recibirán nuevos anuncios continuamente. Las máquinas procesan la información contenida en cada anuncio como se describe arriva, añadiendo a y refrescando la información recibida en anuncios anteriores. Por seguridad, debe ser comprobada la unicidad de todas las direcciones antes de su asignación a un interfaz. Sin embaroog, en el caso de direcciones creadas mediante la autoconfiguración sin estado, la unicidad de una dirección se determina principalmente por la porción de la dirección formada de un identificador de enlace. De esta manera, si un nodo ya ha comprobado la unicidad de una dirección de enlace local, las direcciones adicionales creadas a partir del mismo interfaz no necesitan ser comprobadas individualmente. Por el contrario, toas las direcciones obtenidas manualmente o via autoconfiguración de dirección con estado deben comprobar individualmente su unicidad. Para permitir instalaciones que crean que la sobrecarga de realizar Detecciones de Direcciones Duplicadas contraresta el beneficio, el uso de la Detección de Direcciones Duplicadas puede ser desactivado mediante ajustes administrativos o usando testigos en cada interfaz. Para acelerar el proceso de autoconfiguración, una máquina puede generar sus direcciones de enlace local (y verificar su unicidad) en paralelo con la espera por Advertencias de Router. Ya que un router puede retraser las respuestas a Solicitudes de Router unos segundos, el tiempo total necesitado para completar la autoconfiguración puede ser significativamente más largo si se ejecutan los dos pasos en serie. Thomson & Narten Standards Track [Page 9] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 4.1. Renumeración de instalaciones La cesión de direcciones facilita la renumeración de sitios proporcionando un mecanismo para caducar direcciones asignadas a interfaces en las máquinas. En este momento, los protocolos de nivel superior como TCP no dan soporte para cambiar direcciones extremo mientras está abierta una conexión. Si un a dirección de un extremo se vuelve inválida, las conexiones abiertas se rompen y toda comunicación con la dirección iválida falla. Incluso cuando las aplicaciones usan UDP como protocolo de transporte, las direciones deben (generalmente) permanecer invariantes durante un intercambio de paquetes. Categorizar las direcciones válidas en preferidas y obsoletas nos proporciona una manera de indicar a las capas superiores que una dirección válida puede volverse inválida en breve, y que las comunicaciones futuras usando esta dirección fallarán en caso de que el tiempo de vida de la dirección válida expire antes de que la comunicación finalice. Para evitar esta situación, las capas superiores deben usar una dirección preferida (asumiendo que una de suficiente ámbito exista) para incremetar las posibilidades de que una dirección permanezca válida mientras dure la comunicación. Es decisión de los administradores configurar los tiempos de vida para minimizar el impacto de las comunicaciones fallidas cuando se efectua una renumeración. El período de desaprobación debería ser suficientemente largo para que la mayor parte (si no todas) las comunicaciones usen la nueva dirección cuando una dirección se torne inválida. Se espera que la capa IP provea un medio para que las capas superiores (incluyendo las aplicaciones) puedan elegir la dirección origen más apropiada dado un destino determinado y posiblemente otras restricciones. Una aplicación puede optar por elegir la dirección de origen ella misma antes de empezar una nueva comunicación o puede dejar la dirección sin especificar, en cuyo caso las capas superiores usarán el mecanismo provisto pro la capa IP para elegir una dirección adecuada para la aplicación. Las reglas de selección de dirección detalladas están más allá del ámbito de este documento. 5. ESPECIFICACIÓN DEL PROTOCOLO La autoconfiguración se efectúa en cada interfaz, en máquinas con capacidad multicast. Para máquinas con varios interfaces, se ejecuta la autoconfiguración independientemente para cada interfaz. La autoconfiguración se refiere primariamente a máquinas, con dos excepciones. Se supone que los routers generan direcciones de enlace local mediante el procedimiento perfilado abajo. Además, los routers efectuarán una Detección de Dirección Duplicada para cada dirección antes de asignarla a un interfaz. Thomson & Narten Standards Track [Page 10] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 5.1. Variables de configuración de los nodos Un nodo DEBE permitir que la siguiente variable de autoconfiguración sea configurada por el gestor del sistema para cada interfaz: DupAddrDetectTransmits <--- NO LAS TRADUZCO: por claridad El número de mensajes de Solicitud de Vecino consecutivos que se envían mientras se hace una Detección de Dirección Duplicada para una dirección tentativa. Un valor de cero inidca que la Detección de Direcciones Duplicadas no se ha hecho para esa dirección tentativa. Un valor de uno indica una sóla transmisión sin retransmisiones detrás. Por defecto: 1, pero puede ser sobreescrito con valores específicos al tipo de enlace en los documentos que traten temas relativos a la transmisión de IP sobre tipos de enlace particulares. (por ejemplo, [IPv6-ETHER]). La autoconfiguración también asume la presencia de la variable RetransTimer como se define en [DISCOVERY]. Para la autoconfiguración, RetransTimer especifica el retraso entre transmisiones consecutivas de Solicitudes de Vecino efectuadas durante Detección de Direcciones Duplicadas (si DupAddrDetectTransmits es mayor que 1), así como el tiempo que un nodo espera después de enviar la última Solicitud de Venino antes de acabar el proceso de Detección de Direcciones Duplicadas. 5.2. Variables relacionadas con la autoconfiguración Una máquina mantiene un número de estructuras de datos y testigos relacionados con la autoconfiguración. En lo que sigue, usaremos variables conceptuales y mostraremos cómo son usadas para la autoconfiguración. Las variables específicas se usan a efectos de demostración sólamente; una implementación no necesita tenerlas mientras su comportamiento externo sea consistente con lo descrito en este documento. Más allá de la formación de direcciones de enlace local y del uso de la Detección de Direcciones duplicadas, lo que hacen los routes para (auto)configurar sus interfaces está fuera del alcance de este documento. Las máquinas mantienen las siguientes variables en cada interfaz: Thomson & Narten Standards Track [Page 11] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 ManagedFlag Copiado del campo testigo M (es decir, el testigo de "configuración de dirección gestionada") del mensaje de Anuncio de Router recibido más recientemente. El testigo indica si las direcciones se configurarán usando el mecanismo de autoconfiguración con estado. Comienza en el estado FALSO. OtherConfigFlag Copiado del campo testigo M (es decir, el testigo de "configuración de dirección gestionada") del mensaje de Anuncio de Router recibido más recientemente. El testigo indica si la información que no sea de la dirección se obtendrá usando el mecanismo de autoconfiguración con estado. Comienza en el estado FALSO. The flag indicates whether or not information other than addresses is to be obtained using the stateful autoconfiguration mechanism. It starts out in a FALSE state. Además, cuando el valor de ManagedFlag es CIERTO, el valor de OtherConfigFlag es implícitamente CIERTO también. No es configuración válida de una máquina que use la autoconfiguración con estado para pedir direcciones sólamente, sin que acepte también otra información de configuración. Una máquina también mantiene una lista de direcciones junto con sus tiempos de vida correspondientes. La lista de direcciones contiene onjuntamente direcciones autoconfiguradas y configuradas manualmente. 5.3. Creación de Direcciones de enlace locales Un nodo forma una dirección de enlace local cuando un interfaz se activa. Un interfaz puede pasar a estar activado después de cualquiera de los siguientes eventos: - El interfaz se inicializa en el momento arranque del sistema. - El interfaz se reinicializa después de un fallo temporal o después de ser temporalmente desactivado por la gestión del sistema. - El interfaz se conecta a un enlace por primera vez. - El interfaz se activa por la gestión del sistema después de ser administrativamente desactivado. Thomson & Narten Standards Track [Page 12] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 Una dirección de enlace local se forma precediendo el prefijo de enlace local FE80::0 [ADDR-ARCH] (de longitud aproximada) al identificador del interfaz. Si el identificador del interfaz tiene una longitud de N bits, el identificador del interfaz reemplaza los N bits 0 más a la derecha del prefijo de enlace local. Si el identificador de interfaz tiene mas de 118 bits, la autoconfiguración falla y se requiere configuración manual. Note que los identificadores de interfaz serán típicamente de 64 bits y basados en identificadores EUI-64 como se describe en [ADDR-ARCH]. Una dirección de enlace local tiene un tiempo de vida preferido y válido infinito; nunca expira. 5.4. Detección de Direcciones Duplicadas La Detección de Direcciones Duplicadas se efectua en direcciones unicast antes de asignarlas a un interfaz cuya variable DupAddrDetectTransmits es mayor que cero. La detección de direcciones duplicadas DEBE tener en cuenta todas las direcciones unicast, independientemente de si se obtienen manualmente, con estado o sin estado, con la excepción de los casos siguientes: - NO SE DEBE EJECUTAR la Detección de Direcciones Duplicadas en para direcciones anycast. - DEBERÍA ser comprobada la unicidad de cada dirección individual unicast. Sin embargo, cuando se usa autoconfiguración con estado, la unicidad de direccioes se determina sólamente con el identificador de interfaz, asumiendo que los prefijos de subred se asignan correctamente (es decir, si todos las direcciones de un interfaz se generan del mismo identificador, o todas las direcciones o ninguna serán duplicados). Por esto, dado un conjunto de direcciones formadas del mismo identificador de interfaz, es suficiente comprobar que la dirección de enlace local generada del identificador es única en un enlace. En estos casos, la unicidad de la dirección de enlace DEBE SER COMPROBADA y, si no se detecta dirección duplicada, la implementación PUEDE elegir saltarse la Detección de Direcciones Duplicadas derivadas del mismo identificador de interfaz. El proceso de detección de direcciones duplicadas usa Solicitudes de Vecino y mensajes de Anuncio como se describe debajo. Si se descubre una dirección duplicada durante el procedimiento, la dirección no puede ser asignada al interfaz. Si la dirección se deriva de un identificador de interfaz, se necesita asignar un nuevo identificador al interfaz, o todas las direcciones IP del interfaz tendrán que ser configuradas manualmente. Nótese que el método de detección de duplicados no es completamente fiable, y Thomson & Narten Standards Track [Page 13] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 es posible que sigan existiendo direcciones duplicadas (p.e. si el enlace se particionó cuando se ejecutaba la Detección de Direcciones Duplicadas). Una dirección en la que se aplica el proceso de Detección de Direcciones Duplicadas se denomina tentativa hasta que se completa el proceso con éxito. Una dirección tentativa no se considera "asignada a un interfaz" en el sentido tradicional. Es decir, el interfaz debe aceptar mensajes de Solicitud y de Anuncio de Vecino que contengan la dirección tentativa como dirección destino, pero procesará estos paquetes de manera diferente a aquellos cuya dirección destino concuerde con las direcciones asignadas al interfaz. Otros paquetes dirigidos a la dirección tentativa deben ser descartados en silencio. Debe notarse también que la Detección de Direcciones Duplicadas debe ser ejecutada antes de asignar una dirección a un interfaz para prevenir que múltiples nodos usen la misma dirección simultáneamente. Si un nodo comienza a usar una dirección en paralelo con la Detección de Direcciones Duplicadas, y otro nodo ya está usando la dirección, el nodo ejecutando la Detección de Direcciones Duplicadas procesará erróneamente tráfico destinado al otro nodo, lo que resultará en consecuencias tan negativas como la reinicialización de las conexiones TCP abiertas. Las siguients subsecciones describen pruebas específicas que un nodo ejecuta para verificar la unicidad de una dirección. Una dirección es considerada única si ninguno de estas pruebas indica la presencia de una dirección duplicada durante los RetransTimer milisegundos después de enviar DupAddrDetectTransmits Solicitudes de Vecino. Una vez que una dirección se determina como única, puede ser asignada a un interfaz. 5.4.1. Validación de Mensajes Un nodo DEBE descartar en silencio cualquier mensaje de Solicitud o Anuncio de Vecino que no pase las comprobaciones de validación especificadas en [DISCOVERY]. Una solicitud que pase estas comprobaciones se denomina un anuncio o solicitud válido. 5.4.2. Enviando Mensajes de Solicitud de Vecino Antes de enviar una Solicitud de Vecino, un interfaz DEBE unir las direciones de multicast de todos los nodos y la de multicast de nodo solicitado de la dirección tentativa. La última asegura que el nodo reciba Anuncios de Vecino de otros nodos usando la dirección ya y la última asegura que dos nodos intentando usar la misma dirección simultáneamente detecten la presencia del otro. Para comprobar una dirección, un nodo envía DupAddrDetectTransmits Solicitudes de Vecino, separadas RetransTimer milisegundos. La dirección Destino de la solicitud se fija como la dirección que se Thomson & Narten Standards Track [Page 14] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 comprueba, la dirección IP origen se fija como inespecificada y la IP destino se fija como la dirección multicast de nodo solicitado de la dirección destino. Si la Solicitud de Vecino es el primer mensaje enviado de un interfaz después de la (re)inicialización del mismo, el nodo debe retrasar el envío del mensaje un número aleatorio entre 0 y MAX_RTR_SOLICITATION_DELAY como se especifica en [DISCOVERY]. Este sistema alivia congestiones cuando muchos nodos arrancan en un enlace a la vez, como en un fallo de alimentación, y puede evitar inconsistencias cuando más de un nodo intenta solicitar la misma dirección a la vez. Para aumentar la robusteza del algoritmo de Detección de Direcciones Duplicadas, un interfaz DEBE recibir y procesar los datagramas enviados a la dirección de multicast de todos los nodos o a la de multicast de nodo solicitado de la dirección tentativa mientras retrasa la transmisión de la Solicitud de Vecino inicial. 5.4.3. Recibiendo Mensajes de Solicitud de Vecino Al recibir un mensaje de Solicitud de Vecino válido en un interfaz, el comportamiento del nodo depende de si la dirección destino es tentativa o no. Si la dirección destino no es tentativa (es decir, es asignada al interfaz receptor), la dolicitud se procesa y se describe en [DISCOVERY]. Si la dirección destino es tentativa, y la dirección origen es una dirección unicast, el remitente de la solicitud está haciendo resolución de dirección del destino; La solicitud debe ser ignorada en silencio. En caso contrario, se procesaría como se describe abajo. En todos los casos, los nodos NO DEBEN responder a las Solicitudes de Vecino de direcciones tentativas. Si la dirección origen de la Solicitud de Vecino es la dirección sin especificar, la solicitud viene de un nodo haciendo Detección de Direcciones Duplicadas. Si la solicitud viene de otro nodo, la dirección tentativa está duplicada y no debe ser usada (de ningún modo). Si la solicitod es del propio nodo (porque el nodo recibe sus paquetes de multicast), la solicitud no debe señalar la presencia de direcciones duplicadas. Nota para implementadores: muchos interfaces proveen sistemas para que capas superiores activen o desactiven el retorno de paquetes de multicast. Los detalles de cómo se implementa semejante característica pueden hacer que la Detección de Direcciones Duplicadas no funcione correctamente. Consulte el Apéndice para mas discusiones. Los tests que siguen identifican condiciones bajo las que una dirección tentativa no es única: Thomson & Narten Standards Track [Page 15] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 - Si una Solicitud de Vecino de una dirección tentativa es recibida antes de haber enviado una, la dirección tentativa está duplicada. Si una Solicitud de Vecino de una dirección tentativa se recibe antes de haber enviado una, la dirección tentativa es un duplicado. Esta condición ocurre cuando dos nodos ejecutan simultáneamente la Detección de Direcciones Duplicadas, pero transmiten solicitudes iniciales en momentos distintos (por ejemplo, eligiendo retrasos aleatorios distintos antes de transmitir una solicitud inicial). - Si el número de Solicitudes de Vecino recibidas excede al número esperado basado en la semántica del retorno (es decir, el interfaz no retorna paquetes pero se ha recibido una solicitud o mas), la dirección tentativa está duplicada. Esta condición ocurre cuando dos nodos ejecutan Detección de Direcciones Duplicadas más o menos a la vez. 5.4.4. Recibiendo Mensajes de Anuncio de Vecino Cuando se recibe un Anuncio de Vecino válido en un interfaz, el comportamiento del nodo depende de si la dirección destino es tentativa o concuerda con una dirección de unicast o anycast asignada al interfaz. Si la dirección destino se asigna al interfaz en recepción, la solicitud se procesa y se describe en [DISCOVERY]. Si la dirección destino es tentativa, es que no es única. 5.4.5. Fallo en la Detección de Direcciones Duplicadas Una dirección tentativa que se determina como duplicada según lo descrito arriba NO DEBE ser asignada a un interfaz y el nodo DEBERIA registrar un mensaje de gestión de sistema. Si la dirección es una dirección de enlace local formada de un identificador de interfaz, el interfaz DEBE ser desactivado. 5.5. Creación de Direcciones Globales y Locales Las direcciones globales y locales a la instalación se forman añadiendo un identificador de interfaz a un prefijo de longitud apropiada. Los prefijos se obtienen de opciones de Información de Prefijo contenidas en Anuncios de Router. La creación de direcciones globales y locales a la instalación y la configuración de otros parámetros ocmo se describe en esta sección DEBERÍA ser configurable localmente. No obstante, el procesado descrito abajo DEBE ser activado por defecto. 5.5.1. Solicitando Anuncios de Router Los Anuncios de router se envían períodicamente a la dirección de multicast de todos los nodos. Para obtener anuncios rápidamente, las máquinas envían Solicitudes de Router, como se discute en [DISCOVERY]. Thomson & Narten Standards Track [Page 16] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 5.5.2. Ausencia de Anuncios de Router Si un enlace no tiene routers, una máquina DEBE intentar usar autoconfiguración con estado para obtener direcciones y otra información de configuración. Una implementación PUEDE proporcionar una manera de desactivar la invocación de autoconfiguración con estado en este caso, pero por defecto DEBERÍA estar activada. Desde el punto de vista de la autoconfiguración, un enlace no tiene routers si no se reciben Advertencias de Router después de un número pequeño de Solicitudes de Router como se describe en [DISCOVERY]. 5.5.3. Procesado de las Anuncios de Router Al recibir un Anuncio de Router válido (como se define en [DISCOVERY]), una máquina copia el valor del testigo M del anuncio en ManagedFlag. Si el valor deManagedFlag cambia de FALSO a CIERTO, y la máquina no está ejecutando ya el protocolo de autoconfiguración con estado, la máquina debe invocar el protocolo de autoconfiguración de direcciones, pidiendo tanto información de direcciones como otra complementaria. Si el valor de ManagedFlag camiba de CIERTO a FALSO, la máquina debe continuar ejecutando la autoconfiguración con estado, es decir, el cambio en el valor de ManagedFlag no tiene efecto. Si el valor del testigo no cambia, no se hace nada especial. En particular, una máquine NO DEBE reinvocar la configuración con estado si ya está participando en el protocolo con estado como resultado de un anuncio anterior. El campo testigo O de un anuncio se procesa de manera análoga. Una máquina copia el valor del testigo O en OtherConfigFlag. Si el valor de OtherConfigFlag cambia de FALSO a CIERTO, la máquina debería invocar el protocolo de autoconfiguración con estado, pidiendo información (excluyendo direcciones si ManagedFlag se pone a FALSO). Si el valor de OtherConfigFlag cambia de CIERTO a FALSO, la máquina debería continuar con el protocolo de autoconfiguración con estado, es decir, el cambio del valor de OtherConfigFlag no tiene efecto. En particular, una máquina NO DEBE reinvocar la configuación con estado si ya participa en el protocolo con estado como resultado de un anuncio previo. Para cada opción de Información de Prefijo en el Anuncio de Router: a) Si el testigo Autónomo no está activado, ignorar la opción de Información de Prefijo. Thomson & Narten Standards Track [Page 17] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 b) Si el prefijo es el prefijo de enlace local, ignorar en silencio la opción de Información de Prefijo. c) Si el tiempo de vida preferido es mayour que el tiempo de vida válido, ingorar silenciosamentela opción de Información de prefijo. Un nodo PUEDE desear registrar un error de gestión en este caso. d) Si el prefijo anunciado no coincide con el prefijo de una dirección ya en la lista, y el Tiempo de Vida Válido no es 0, formar uan dirección (y añadirla a la lista) combinando el prefijo anunciado con el identificador de interfaz del enlace: | 128 - N bits | N bits | +---------------------------------------+------------------------+ | prefijo de enlace | id. de interfaz | +----------------------------------------------------------------+ Si la suma de la longitud de prefijo y la del interfaz no es igual a 256 bits, la opción de Información de Prefijo DEBE ser ignorada. Una implementación PUEDE desear registrar un error de gestión en este caso. Es responsabilidad del administrador de sistema asegurarse que las longitudes de los prefijos contenidos en lso Anuncios de Routers son consistentes con la longitud de los identificadores de interfaz para ese tipo de enlace. Note que los identificadores de interfaz típicamente tendrán 64 bits, y se basarán en identificadores EUI-64 como se discute en [ADDR-ARCH]. Si se forma con éxito una dirección, la máquina la añadirá a la lista de direcciones asignadas al interfaz, inicializando sus tiempos de vida preferido y válido con la opción de Información de Prefijo. e) Si el prefijo anunciado concuerda con el prefijo de una dirección autoconfigurada (es decir, una obtenida via autoconfiguración con o sin estado) en la lista de direcciones asociadas con el interfaz, la acción específica a ejecutar depende del Tiempo de Vida válido, la acción específica a ejecutar depende del Tiempo de Vida Válido en el anuncio recibido y el Tiempo de Vida asociado con la dirección previamente autoconfigurada (que llamamos StoredLifetime en la discusión que sigue): 1) Si el tiempo de vida recibido es mayor de 2 horas o mayor que StoredLifetime, actualizar el Tiempo de Vida guardado en la dirección correspondiente. 2) Si StoredLifetime es menos que o igual a 2 hours y el Tiempo Vida recibido es menor que o igual a StoredLifetime, ignorar el prefijo, a no ser que el Anuncio de Router del que esta Thomson & Narten Standards Track [Page 18] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 opción de Información de Prefijo se obtuvo haya sido autenticada (por ejemplo, via IPSec [RFC2402]). Si el anuncio de Router fue autenticado, StoredLifetime debería ser fijado al Tiempo de Vida en la opción recibida. 3) En otro caso, reiniciar el Tiempo de Vida almacenado a las correspondientes dos horas. Las reglas anteriores se refieren a un ataque de denegación obsoletade servicio en el que anuncios falsos pueden contener prefijos con Tiempos de Vida Válidos muy pequeños. Sin las reglas anteriores, un sólo anuncio autenticado conteniendo opciones de Información de Prefijo falsas con tiempos de vida cortos podrían causar que todas las direcciones de un nodo expirasen prematuramente. Las reglas anteriores aseguran que anuncios legítimos (enviados periódicamente) "cancelarán" los tiempos de vida cortos antes de que tengan efecto. 5.5.4. Caducidad de la Vida de las Direcciones Una dirección preferida se vuelve obsoleta cuando su tiempo de vida preferido expira. Una dirección deaprobada DEBERÍA continuar siendo usada como dirección origen en las comunicaciones existentes, pero NO DEBERÍA ser usada en nuevas comunicaciones si una dirección (no obsoleta) alternativa está disponible y tiene ámbito suficiente. Las capas IP y superiores (por ejemplo, TCP, UDP) deben continuar aceptando datagramas destinados a una dirección obsoleta pero gestor del sistema DEBE tener la capacidad de desactivar tal característica, y la característica DEBE estar desactivada por defecto. Una dirección (y su asociación con un interfaz) se convierte en inválida cuando su tiemo de vida válido expira. Una dirección inválida NO DEBE ser usada como dirección origen en comunicaciones salientes y NO DEBE ser reconocida cmoo un destino en un interfaz receptor. 5.6. Consistencia de la Configuración Es posible que las máquinas obtengan información de direcciones usando tanto los protocolos con estado como sin él, ya que ambos pueden estar activados a la vez. También es posible que los valores de otros parámetros de configuración como el tamaño de la MTU y el límite de saltos se aprendan de Anuncios de Router y del protocolo de configuración con estado. Si la misma información de configuración se obtiene de fuentes variadas, el valor de esta información debe ser consistente. Sin embargo, no se considera un error fatal recibir información inconsistentes de múltiples fuentes. Las máquinas Thomson & Narten Standards Track [Page 19] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 aceptan la union de la información recibida via protocolos con y sin estado. Si la información inconsistente se aprende de fuentes diferentes, los valores obtenidos más recientemente tienen siempre precedencia sobre la información aprendida antes. 6. CONSIDERACIONES DE SEGURIDAD La configuración de direcciones sin estado permite a una máquina conectarse a una red, configurar una dirección y comenzar a comunicarse con otros nodos sin autenticarse o registrarse siquiera con la instlación local. Aunque esto permite a usuarios no autorizados conectarse y usar la red, la amenaza es inherente a la arquitectura de Internet. Cualquier nodo con una conexión física a una red puede generar una dirección (usando distintas técnicas ex profeso) que de conectividad. El uso de la Detección de Direcciones Duplicadas abre la posibilidad de ataques de denegación de servicio. Un nodo puede responder las Solicitudes de Vecino de direcciones tentativas, causando que el otro nodo rechaze la dirección por duplicada. Este ataque es similar a otros ataques incluyendo el falseo de mensajes de Descubrimiento de Vecino y puede ser evitado requiriendo que los paquetes de Descubrimiento de Vecino sean autenticados [RFC2402]. 7. Referencias [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [ADDR-ARCH] Hinden, R. and S. Deering, "Internet Protocol Version (IPv6) Addressing Architecture", RFC 2373, July 1998 [DHCPv6] Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress. Thomson & Narten Standards Track [Page 20] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 [DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 8. Agradecimientos Los autores quisieran agradecer a los miembros de los grupos de trabajo de IPNG y de ADDRCONF por sus opiniones. En particular, gracias a Jim Bound, Steve Deering, Richard Draves, y Erik Nordmark. gracias también a John Gilmore por alertar al grupo de la vulnerabilidad al ataque de denegación de servicio por "Anuncios de Prefijos de Tiempo de Vida nulos"; este documento añade cambios que solucionan esta vulnerabilidad. DIRECCIONES DE LOS AUTORES Susan Thomson Bellcore 445 South Street Morristown, NJ 07960 USA Phone: +1 201-829-4514 EMail: set@thumper.bellcore.com Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 EMail: narten@raleigh.ibm.com Thomson & Narten Standards Track [Page 21] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 9. APÉNDICE A: SUPRESIÓN DE LOOPBACK Y DETECCIÓN DE DIRECCIONES DUPLICADAS Determinar si una solicitud multicast recibida ha sido un retorno (loopback) al remitente o si ha venido de otro nodo depende de la implementación. Un caso problemático ocurre cuando dos interfaces conectados al mismo enlacen tienen el mismo identificador y dirección de capa de enlace, y además envían paquetes con contenidos idénticos mas o menos a la vez (Por Ejemplo, Solicitudes de Vecino para una dirección tentativa como parte de los mensajes de Detección de Direccioens Duplicadas). Aunque un receptor recibe ambos paquetes, no puede determinar cuál es un retorno y cuál viene de otro nodo por la mera comparación de los contenidos (ya que son idénticos). En este caso particular, no es necesario saber con precisión qué paquete ha sido un retorno y cual un envío; si alguien recibe mas solicitudes de las que envía, la dirección tentativa está duplicada. Sin embargo, esta situación no siempre es tan sencilla. La especificación de multicast de IPv4 [RFC1112] recomienda que el interfaz permita que los protocolos de capas superiores inhiban la entrega local de paquetes enviados a un grupo multicast del que la máquina remitente es miembro. Algunas aplicaciones saben que no habrá más miembros del grupo en la misma máquina, y eliminar el retorno evita que tengan que recibir (y descartar) los paquetes que ellas mismas envían. Una manera directa de implementar esta característica es desactivar el retorno en a nivel hardware (si lo soporta el hardware), haciendo retorno de paquetes (si se pide) por software. Los interfaces en los que el hardware suprime por si sólo el retorno, un nodo ejecutando Detección de Direcciones Duplicadas simplemente cuenta el número de Solicitudes de Vecino recibidas por dirección tentativa y las compara con el número esperado. Si difieren, la dirección tentativa está duplicada. A veces el harware no puede suprimir el retorno. Sin embargo, un heurístico software posible para filtrar retornos no deseados es descartar cualquier paquete recibido cuya dirección de capa de enlace sea la misma que la del interfaz que recibe. Desafortumadamente, este criterio implica descartar también todos los paquetes enviados por otro nodo usando la misma dirección de capa de enlace. La Detección de Direcciones Duplicadas fallará en los interfaces que filtren paquetes recibidos de esta manera: o Si un nodo ejecutando Detección de Direcciones Duplicadas descarta los paquetes recibidos que tengan la misma dirección de capa de enlace origen que el interfaz que los recibe, también descartará paquetes de otros nodos que usen la misma dirección de capa de enlace, incluyendo Anuncios de Vecino y Solicitudes de Vecino requeridas para ejecutar correctamente la Detección de Thomson & Narten Standards Track [Page 22] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 Direcciones Duplicadas. Este problema particular puede ser evitado desactivando temporalmente la supresión de retorno por software mientras el nodo ejecute una Detección de Direcciones Duplicadas. o Si un nodo que ya usa una dirección IP concreta descarta los paquetes recibidos con la misma dirección origen de capa de enlace que el interfaz, también descartará los mensajes de Solicitud de Vecino de la Detección de Direcciones Duplicada enviados por otros nodos que también usen la misma direcciónd de capa de enlace. Consecuentemente, la Detección de Direcciones Duplicadas fallará, y el otro nodo configurará una dirección duplicada. Ya que generalmente es imposible saber cuándo otro nodo está ejecutando la Detección de Direcciones Duplicadas, este escenario puede ser evitado sólo si la supresión del retorno se desactiva permanentemente. De esta forma, ejecutar la Detección de Direcciones Duplicadas correctamente en el caso en el que dos interfaces están usando la misma dirección de capa de enlace, una implementación debe interpretar correctamente la semántica de retorno de multicast de un interfaz, y el interfaz no puede descartar paquetes recibidos simplemente porque la dirección origen de capa de enlace sea la misma que la del interfaz. Thomson & Narten Standards Track [Page 23] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 10. APÉNDICE B: CAMBIOS DESDE RFC 1971 o Cambio del documento para usar el término "identificador de interfaz" en vez de "símbolo de interfaz" por consistencia con otros documentos IPv6. o Aclaración de la definición de dirección obsoleta para dejar claro que es correcto continuar enviando o recibiendo de/a direcciones obsoletas. o Rescritura, por aclararla, de la sección 5.4 (sin cambios de contenido). o Se añaden reglas a la Sección 5.5.3 procesado de Anuncios de Router para evitar ataques de denegación de servicio potenciales cuando se anuncian prefijos con Tiempos de Vida muy cortos. o Aclarada la redacción de la Sección 5.5.4 para dejar claro que todos los protocolos de capas superiores deben procesar (es decir, enviar y recibir) los paquetes enviados a direcciones obsoletas. Thomson & Narten Standards Track [Page 24] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998 11. Cláusula de Copyright Completa Copyright (C) The Internet Society (1997). Todos los derechos reservados. Este documento y sus traducciones puede ser copiado y facilitado a otros, y los trabajos derivados que lo comentan o lo explican o ayudan a su implementación pueden ser preparados, copiados, publicados y distribuídos, enteros o en parte, sin restricción de ningún tipo, siempre que se incluyan este párrafo y la nota de copyright expuesta arriba en todas esas copias y trabajos derivados. Sin embargo, este documento en sí no debe ser modificado de ninguna forma, tal como eliminando la nota de copyright o referencias a la 'Internet Society' u otras organizaciones de Internet, excepto cuando sea necesario en el desarrollo de estándares Internet, en cuyo caso se seguirán los procedimientos para copyrights definidos en el proceso de Estándares Internet, o con motivo de su traducción a otras lenguas aparte del Inglés. Los permisos limitados concedidos más arriba son perpétuos y no serán revocados por la 'Internet Society' o sus sucesores o cesionarios. Este documento y la información contenida en él se proporcionan en su forma "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK FORCE RECHAZAN CUALESQUIERA GARANTIAS, EXPRESAS O IMPLICITAS, INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACION AQUI EXPUESTA NO INFRINGIRA NINGUN DERECHO O GARANTIAS IMPLICITAS DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECIFICO. Thomson & Narten Standards Track [Page 25]