"Introducción Las implementaciones de IPv4 generalmente asocian una máscara de red con una dirección cuando se asigna una dirección IPv4 a una interfaz. Esa máscara de red junto con la dirección IPv4 designa un prefijo de enlace. Los nodos consideran que las direcciones cubiertas por un prefijo de enlace se adjuntan directamente a el mismo enlace que el nodo emisor @ es decir @, envían tráfico para dichas direcciones directamente en lugar de a un enrutador. Consulte la Sección 3.3.1 de [RFC1122]. Antes del desarrollo de la división en subredes [RFC0950] y el enrutamiento entre dominios sin clases (CIDR ) [RFC4632]@ la máscara de red de una dirección podría derivarse directamente de la dirección simplemente determinando si era una dirección Clase A@ B@ o C. Hoy@, asignar una dirección a una interfaz también requiere especificar una máscara de red a utilizar. de especificar una máscara de red específica al asignar una dirección @ algunas implementaciones recurrirían a derivar la máscara de red de la clase de la dirección. El comportamiento de IPv6 como se especifica en Neighbor Discovery (ND) [RFC4861] es bastante diferente. La determinación del enlace es independiente de la asignación de direcciones. Un host puede tener direcciones IPv6 sin ningún prefijo de enlace relacionado o puede tener prefijos de enlace que no estén relacionados con ninguna dirección IPv6 asignada al host. Inicialmente se debe considerar que cualquier dirección asignada en una interfaz no tiene estructura interna como se muestra en [RFC4291]. En IPv6@ por defecto@ un host trata solo el prefijo de enlace local como en enlace. La recepción de una opción de información de prefijo (PIO) con el bit L establecido [RFC4861] y una vida útil válida distinta de cero crea (o actualiza) una entrada en la lista de prefijos. Todos los prefijos en la lista de prefijos de un host (es decir, @ aquellos prefijos que aún no han expirado) se consideran conectados por ese host. La definición de enlace en la sección Terminología de [RFC4861]@ modificada por este documento@ define la lista completa de casos en los que un host considera que una dirección está en enlace. Las entradas de direcciones individuales pueden caducar mediante el mecanismo de detección de inaccesibilidad de vecinos. Los paquetes IPv6 enviados utilizando el algoritmo de envío conceptual como se describe en [RFC4861] solo activan la resolución de direcciones para las direcciones IPv6 que el remitente considera que están en el enlace. Los paquetes a cualquier otra dirección se envían a un enrutador predeterminado. Si no hay un enrutador @ predeterminado, entonces el nodo debe enviar una indicación de destino inalcanzable ICMPv6 como se especifica en [RFC4861]. Se proporcionan más detalles en las secciones ""Comportamiento del host"" y ""Reglas del host"" de este documento. (Tenga en cuenta que [RFC4861] cambió el comportamiento cuando la lista de enrutadores predeterminada está vacía. En la versión anterior de Neighbor Discovery [RFC2461]@ si la lista de enrutadores predeterminada está vacía@ en lugar de enviar la indicación ICMPv6 Destino inalcanzable@ al nodo [RFC2461] se supuso que el destino estaba en el enlace). Tenga en cuenta que ND tiene como alcance un único enlace. Se supone que todas las respuestas de Solicitud de Vecino (NS) se envían por la misma interfaz en la que se recibió la consulta correspondiente sin utilizar el Algoritmo de Envío Conceptual. La falla de las implementaciones de host para implementar correctamente el modelo de subred IPv6 puede resultar en una falta de conectividad IPv6. Consulte la sección ""Comportamiento de implementación incorrecto observado"" para obtener más detalles. Este documento desaproba los dos últimos puntos de la definición de "en enlace" en [RFC4861] para abordar los problemas de seguridad que surgen de implementaciones de ND particulares. El comportamiento del anfitrión se aclara en las secciones ""Comportamiento del anfitrión"" y ""Reglas del anfitrión"".
RFC 5942-2010 Historia
2010RFC 5942-2010 Modelo de subred IPv6: la relación entre enlaces y prefijos de subred (Actualizaciones: 4861)