Dirección de Enlace-Local

Las direcciones de enlace local se asignan usando los procedimientos de stateless address autoconfiguration para Internet Protocol versión 4 (IPv4)[1]​ e IPv6.[2]​ En IPv4, las direcciones de enlace local pueden usarse cuando no hay disponible un mecanismo externo de configuración de direcciones, tal como DHCP, u otro mecanismo principal de configuración ha fallado. En IPv6, las direcciones de enlace local son necesarias para el funcionamiento interno de varios componentes del protocolo.

Las direcciones de enlace local para IPv4 están definidas en el bloque 169.254.0.0/16. En IPv6, están reservadas con el prefijo fe80::/10.[3]

IPv4

La Internet Engineering Task Force (IETF) reservó el bloque desde 169.254.1.0 hasta 169.254.254.255[nota 1]​ para direccionamiento de enlace-local en Internet Protocol Version 4. Se asignan a interfaz por el propio host, por ejemplo stateless address autoconfiguration (autoconfiguración de dirección sin estado) cuando otros modos de asignación de direcciones no están disponibles.[1]

Debido a que no es deseable tener múltiples direcciones asignadas a una interfaz,[4]​ antes de asignar automáticamente una dirección IP, el host suele buscar un servidor DHCP en la red.

En el proceso automático de configuración de direcciones, los hosts seleccionan aleatoriamente una dirección candidata dentro del rango reservado y utilizan peticiones ARP para asegurarse de que la dirección no está en uso en otro host. En caso contrario, se selecciona una nueva dirección. Después de asignar una dirección de enlace local, si aparece disponible una dirección pública o privada, se prefiere para nuevas conexiones el uso de dicha dirección privada/pública antes que la de enlace-local.[5]

Microsoft llama a este método de autoconfiguración de dirección Automatic Private IP Addressing (APIPA).[6]​ Algunas veces ha sido referido también como auto-IP.

IPv6

Internet Protocol Versión 6 (IPv6) requiere que el sistema operativo asigne direcciones de enlace-local a las interfaces de red aunque tenga direcciones operativas ya configuradas. Una dirección única de enlace-local tiene el prefijo fe80::/10 en notación CIDR estándar de IPv6.[2]

Los hosts IPv6 tienen habitualmente más de una dirección IPv6 asignada a cada interfaz de red. La dirección de enlace-local es necesaria para operaciones de subcapa IPv6 dentro del Neighbor Discovery Protocol. Las direcciones de enlace local pueden asignarse automáticamente (stateless, sin estado) o por DHCPv6.

La autoconfiguración de dirección IPv6 sin estado se realiza por un componente del Neighbor Discovery Protocol (NDP), tal y como se especifica en la RFC 4862. La dirección se crea a partir del prefijo de red y la Dirección MAC de la interfaz.

La asignación de direcciones de enlace local IPv6 implica automáticamente la presencia en este prefijo de red, a diferencia de las direcciones de otros ámbitos.

IPv6 introduce significados adicionales a la asignación de direcciones a interfaces de red. Mediante los avisos NDP de rangos de red un router o servidor dedicado puede anunciar información de configuración a todas las interfaces conectados a la red, provocando asignaciones adicionales en dichas interfaces con propósitos de routing local o global. Este proceso es también considerado a veces stateless (sin estado), dado que el servidor de rangos de red no recibe ni hace log de las asignaciones individuales. La unicidad (no duplicidad) se garantiza automáticamente por la metodología basada en direcciones MAC y por los algoritmos de detección de direcciones duplicadas.

Véase también

Notas

  1. Las primeras y las últimas 256 direcciones del rango 169.254/16 están reservadas para uso futuro por la RFC 3927.

Referencias

  1. a b RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses, S. Cheshire, B. Aboba, E. Guttman, The Internet Society (May 2005)
  2. a b RFC 4291,IP Version 6 Addressing Architecture - 2.4. Address Type Identification, R. Hinden, S. Deering, The Internet Society (February 2006)
  3. (en inglés) Understanding IPv6 Link Local Address
  4. RFC 3927 sección 1.9
  5. RFC 3927 sección 2.6.1
  6. «APIPA». Microsoft. Archivado desde el original el 18 de marzo de 2017. Consultado el 2 de agosto de 2010.