Hispanopedia Wiki
Articulo de referencia

Redes sin configuración

La configuración automática de red ( zeroconf ) es un conjunto de tecnologías que crea automáticamente una red informática funcional basada en el protocolo TCP/IP cuando se inte...

Hispanopedia WikiContenido en espanolLectura gratuita

La configuración automática de red ( zeroconf ) es un conjunto de tecnologías que crea automáticamente una red informática funcional basada en el protocolo TCP/IP cuando se interconectan ordenadores o periféricos de red. No requiere intervención manual del operador ni servidores de configuración especiales. Sin zeroconf, un administrador de red debe configurar servicios de red , como DHCP y DNS, o bien configurar manualmente los ajustes de red de cada ordenador.

Zeroconf se basa en tres tecnologías principales: la asignación automática de direcciones de red numéricas para dispositivos conectados a la red, la distribución y resolución automáticas de nombres de host de ordenadores y la localización automática de servicios de red , como dispositivos de impresión.

Fondo

Las redes informáticas utilizan direcciones de red numéricas para identificar los puntos finales de comunicación en una red de dispositivos participantes. Esto es similar a la red telefónica , que asigna una secuencia de dígitos para identificar cada teléfono. En los protocolos de red modernos , la información que se va a transmitir se divide en una serie de paquetes de red . Cada paquete contiene las direcciones de origen y destino de la transmisión. Los enrutadores de red examinan estas direcciones para determinar la mejor ruta de red para reenviar el paquete de datos en cada paso hacia su destino.

De forma similar a como los teléfonos se etiquetaban con su número, en las primeras redes era práctica común asignar una etiqueta de dirección a los dispositivos conectados. La naturaleza dinámica de las redes modernas, especialmente las residenciales, donde los dispositivos se encienden solo cuando es necesario, exige mecanismos de asignación de direcciones dinámicas que no requieran la intervención del usuario para su inicialización y gestión. Estos sistemas se asignan automáticamente nombres comunes, elegidos por el fabricante del equipo (como la marca y el número de modelo) o por los usuarios para identificar sus dispositivos. Los nombres y las direcciones se registran automáticamente en un directorio .

Las primeras redes informáticas se basaron en tecnologías de redes de telecomunicaciones, por lo que los protocolos tendían a dividirse en dos grupos: aquellos destinados a conectar dispositivos locales en una red de área local (LAN) y aquellos destinados principalmente a comunicaciones de larga distancia. Los sistemas de red de área amplia (WAN) solían tener una configuración centralizada, donde un administrador de red asignaba manualmente direcciones y nombres. Los sistemas LAN tendían a automatizar estas tareas, de modo que se podía añadir nuevo equipo a una LAN con una mínima intervención del operador y del administrador.

Un ejemplo temprano de un sistema LAN de configuración cero es AppleTalk , un protocolo introducido por Apple Inc. para los primeros ordenadores Macintosh en la década de 1980. Los Mac, así como otros dispositivos compatibles con el protocolo, podían añadirse a la red simplemente conectándolos; toda la configuración posterior era automática. Cada dispositivo seleccionaba automáticamente las direcciones de red mediante un protocolo conocido como Protocolo de Resolución de Direcciones de AppleTalk (AARP), mientras que cada máquina creaba su propio servicio de directorio local mediante un protocolo conocido como Protocolo de Enlace de Nombres (NBP). NBP incluía no solo un nombre, sino también el tipo de dispositivo y cualquier información adicional proporcionada por el usuario, como su ubicación física o disponibilidad. Los usuarios podían buscar cualquier dispositivo en la red con la aplicación Chooser , que filtraba los nombres según el tipo de dispositivo.

En las redes de protocolo de Internet (IP), la base de datos del sistema de nombres de dominio (DNS) de una red era inicialmente mantenida manualmente por un administrador de red. Los esfuerzos por automatizar el mantenimiento de esta base de datos llevaron a la introducción de varios protocolos nuevos que proporcionan servicios automatizados, como el Protocolo de configuración dinámica de host (DHCP).

Selección de direcciones

Los hosts de una red deben tener asignadas direcciones IP que los identifiquen de forma única ante otros dispositivos de la misma red. En algunas redes, existe una autoridad central que asigna estas direcciones a medida que se añaden nuevos dispositivos. Se introdujeron mecanismos para gestionar esta tarea automáticamente, y tanto IPv4 como IPv6 ahora incluyen sistemas de autoconfiguración de direcciones , lo que permite a un dispositivo determinar una dirección segura para usar mediante mecanismos sencillos. Para el direccionamiento de enlace local , IPv4 utiliza el bloque especial 169.254.0.0/16 , [ 1 ] mientras que los hosts IPv6 utilizan el prefijo fe80:: / 10 . Más comúnmente, las direcciones son asignadas por un servidor DHCP , a menudo integrado en hardware de red común como hosts de computadora o enrutadores.

La mayoría de los hosts IPv4 utilizan el direccionamiento local de enlace solo como último recurso cuando un servidor DHCP no está disponible. De lo contrario, un host IPv4 utiliza su dirección asignada por DHCP para todas las comunicaciones, ya sean globales o locales de enlace. Una razón es que los hosts IPv4 no están obligados a admitir múltiples direcciones por interfaz, aunque muchos lo hacen. Otra razón es que no todos los hosts IPv4 implementan la resolución de nombres distribuida (por ejemplo, DNS multicast ), por lo que descubrir la dirección local de enlace autoconfigurada de otro host en la red puede ser difícil. Descubrir la dirección asignada por DHCP de otro host requiere resolución de nombres distribuida o un servidor DNS unicast con esta información. Algunas redes cuentan con servidores DNS que se actualizan automáticamente con la información de host y dirección asignada por DHCP.

Los hosts IPv6 deben admitir múltiples direcciones por interfaz; además, cada host IPv6 debe configurar una dirección de enlace local incluso cuando haya direcciones globales disponibles. Los hosts IPv6 también pueden autoconfigurar direcciones adicionales al recibir mensajes de anuncio de enrutador, eliminando así la necesidad de un servidor DHCP. [ 2 ]

Tanto los hosts IPv4 como los IPv6 pueden generar aleatoriamente la parte específica del host de una dirección autoconfigurada. Los hosts IPv6 generalmente combinan un prefijo de hasta 64 bits con un EUI-64 de 64 bits derivado de la dirección MAC IEEE de 48 bits asignada de fábrica . La dirección MAC tiene la ventaja de ser globalmente única, una propiedad básica del EUI-64. La pila de protocolos IPv6 también incluye detección de direcciones duplicadas para evitar conflictos con otros hosts. En IPv4, el método se denomina autoconfiguración de direcciones de enlace local . [ 1 ] Sin embargo, Microsoft se refiere a esto como Direccionamiento IP privado automático (APIPA) [ 3 ] o Configuración automática del protocolo de Internet ( IPAC ). Esta función es compatible con Windows desde al menos Windows 98. [ 4 ]

descubrimiento de servicios de nombres

Los protocolos de Internet utilizan direcciones IP para las comunicaciones, pero estas no son fáciles de usar para los humanos; IPv6, en particular, utiliza cadenas de dígitos muy largas que no se introducen fácilmente de forma manual. Para solucionar este problema, Internet lleva mucho tiempo utilizando DNS, que permite asociar nombres legibles a las direcciones IP e incluye código para buscar estos nombres en un sistema de base de datos jerárquico. Los usuarios escriben nombres de dominio, como example.org , que el software DNS del ordenador busca en las bases de datos DNS para obtener una dirección IP, y luego la transfiere a la pila de protocolos para las comunicaciones posteriores. [ 5 ]

Para consultar una dirección mediante DNS, es necesario conocer la dirección IP del servidor DNS. Normalmente, esto se conseguía introduciendo la dirección de un servidor conocido en un campo de uno de los dispositivos de la red. En los primeros sistemas, esto solía ser necesario en todos los dispositivos, pero ahora se ha trasladado a un nivel superior de la jerarquía, a los servidores DHCP o a dispositivos de banda ancha como los módems de cable , que reciben esta información de su proveedor de servicios de internet . Esto ha reducido los requisitos de administración del usuario y proporciona un elemento clave para el acceso sin configuración. [ 5 ]

El DNS se diseñó para proporcionar nombres uniformes a grupos de dispositivos dentro del mismo dominio administrativo, como example.org , proporcionados por un servicio de nombres. Asignar una dirección a un dispositivo local, por ejemplo, thirdfloorprinter.example.org , normalmente requiere acceso de administrador al servidor DNS y suele hacerse manualmente. Además, no se espera que los servidores DNS tradicionales corrijan automáticamente los cambios de configuración. Por ejemplo, si una impresora se traslada de un piso a otro, el servidor DHCP local podría asignarle una nueva dirección IP. [ 5 ]

Para abordar la necesidad de configuración automática, Microsoft implementó el Servicio de Nombres NetBIOS , del cual el Servicio de Explorador de Equipos ya estaba presente en Microsoft Windows para Grupos de Trabajo 3.11 [ 6 ] desde 1992. El Servicio de Nombres NetBIOS no requiere configuración en redes con una sola subred y puede utilizarse junto con un servidor WINS o un servidor DNS de Microsoft que admita el registro automático seguro de direcciones. Este sistema tiene una sobrecarga de administración pequeña, aunque no nula, incluso en redes empresariales muy grandes. Los protocolos que puede usar NetBIOS forman parte del conjunto de protocolos abiertos Server Message Block (SMB) [ 6 ] , que también están disponibles en Linux e iOS, aunque Windows suele admitir una gama más amplia de denominados dialectos que pueden negociarse entre clientes Windows compatibles. Por ejemplo, los Servicios de Explorador de Equipos que se ejecutan en sistemas operativos de servidor o versiones posteriores de Windows se eligen como explorador maestro sobre aquellos que no ejecutan un sistema operativo de servidor o que ejecutan versiones anteriores de Windows. [ 6 ]

En 2000, Bill Manning y Bill Woodcock describieron el Servicio de Nombres de Dominio Multicast [ 7 ] que dio origen a las implementaciones de Apple y Microsoft. Ambas implementaciones son muy similares. El DNS Multicast (mDNS) de Apple se publica como una propuesta de estándar RFC 6762 , mientras que la Resolución de Nombres Multicast Link-local (LLMNR) de Microsoft se publica como RFC 4795 informativo . LLMNR está incluido en todas las versiones de Windows desde Windows Vista en adelante [ 8 ] y actúa como una alternativa paralela al Servicio de Nombres NetBIOS de Microsoft sobre IPv4 y como reemplazo sobre IPv6, ya que NetBIOS no está disponible sobre IPv6. La implementación de Apple está disponible como el servicio Bonjour desde 2002 en Mac OS X v10.2. La implementación de Bonjour (mDNSResponder) está disponible bajo la Licencia de Código Abierto Apache 2 [ 9 ] y está incluida en Android Jelly Bean y versiones posteriores [ 10 ] bajo la misma licencia.  

El uso de los servicios NetBIOS o LLMNR en Windows es prácticamente automático, ya que el uso de las API de cliente DNS estándar dará como resultado el uso de NetBIOS o LLMNR dependiendo del nombre que se esté resolviendo (si el nombre es local o no), la configuración de red vigente (por ejemplo, los sufijos DNS en vigor) y (en redes corporativas) las políticas vigentes (si LLMNR o NetBIOS están deshabilitados), aunque los desarrolladores pueden optar por omitir estos servicios para búsquedas de direcciones individuales.

Con el lanzamiento de Windows 10, Microsoft anunció la descontinuación de NetBIOS y LLMNR y adoptó mDNS. [ 11 ] [ 12 ] Si bien la implementación de Windows 10 en versiones anteriores (versión 1703) se limitaba a descubrir impresoras en red, dispositivos de duplicación de pantalla, altavoces inalámbricos, etc., las versiones posteriores (Windows 10 1903 y posteriores) también resolvieron nombres de host. [ 13 ] mDNS tiene prioridad en Windows 10 y posteriores, pero LLMNR, el Servicio de nombres de NetBIOS y SSDP continúan funcionando como alternativa por ahora junto con mDNS en Windows. [ 11 ]

Los protocolos mDNS y LLMNR presentan pequeñas diferencias en su enfoque para la resolución de nombres. mDNS permite que un dispositivo de red elija un nombre de dominio en el espacio de nombres DNS local y lo anuncie mediante una dirección IP de multidifusión especial. Esto introduce una semántica especial para el dominio de nivel superior local , [ 14 ] lo cual es considerado un problema por algunos miembros del IETF. [ 15 ] El borrador actual de LLMNR permite que un dispositivo de red elija cualquier nombre de dominio, lo cual es considerado un riesgo de seguridad por algunos miembros del IETF. [ 16 ] mDNS es compatible con DNS-SD, como se describe en la siguiente sección, mientras que LLMNR no lo es. [ 17 ]

descubrimiento de servicios

Los servicios de nombres como mDNS, LLMNR y otros no proporcionan información sobre el tipo de dispositivo ni su estado. Por ejemplo, un usuario que busca una impresora cercana podría tener dificultades si la impresora se llama Bob . El descubrimiento de servicios proporciona información adicional sobre los dispositivos. En ocasiones, el descubrimiento de servicios se combina con un servicio de nombres , como en el Protocolo de Enlace de Nombres de Apple y NetBIOS de Microsoft .

Descubrimiento de servicios NetBIOS

NetBIOS en Windows permite que hosts individuales en la red anuncien servicios, como recursos compartidos de archivos e impresoras. También permite, por ejemplo, que una impresora de red se anuncie como un host que comparte un dispositivo de impresión y cualquier servicio relacionado que admita. Dependiendo de cómo se conecte un dispositivo (directamente a la red o al host que lo comparte) y de los protocolos compatibles. Sin embargo, los clientes de Windows que se conectan a él pueden preferir usar SSDP o WSD con NetBIOS. NetBIOS es uno de los proveedores en Windows que implementa el proceso de descubrimiento más general denominado descubrimiento de funciones , que incluye proveedores integrados para PnP, Registro, NetBIOS, SSDP y WSD [ 18 ], de los cuales los dos primeros son solo locales y los tres últimos admiten el descubrimiento de dispositivos en red. Ninguno de ellos necesita configuración para su uso en la subred local. Tradicionalmente, NetBIOS solo ha sido compatible con impresoras caras para uso corporativo, aunque algunas impresoras básicas con Wi-Fi o Ethernet lo admiten de forma nativa, lo que permite usar la impresora sin configuración incluso en sistemas operativos muy antiguos.

WS-Discovery

El descubrimiento dinámico de servicios web ( WS-Discovery ) es una especificación técnica que define un protocolo de descubrimiento multicast para localizar servicios en una red local. Funciona a través de los puertos TCP y UDP 3702 y utiliza la dirección IP multicast 239.255.255.250 . Como su nombre indica, la comunicación entre nodos se realiza mediante estándares de servicios web, en particular SOAP sobre UDP . Windows lo admite a través de los perfiles de Servicios web para dispositivos y Perfil de dispositivos para servicios web . Muchos dispositivos, como las impresoras HP y Brother, también lo admiten.

Descubrimiento de servicios basado en DNS

DNS-SD (DNS Service Discovery [ 19 ] ) permite a los clientes descubrir una lista con nombre de instancias de servicio y resolver esos servicios a nombres de host utilizando consultas DNS estándar. La especificación es compatible con el software de servidor y cliente DNS unicast existente, pero funciona igualmente bien con mDNS en un entorno sin configuración. Cada instancia de servicio se describe utilizando un registro DNS SRV [ 20 ] y un registro DNS TXT [ 21 ] . Un cliente descubre la lista de instancias disponibles para un tipo de servicio dado consultando el registro DNS PTR [ 21 ] del nombre de ese tipo de servicio; el servidor devuelve cero o más nombres con el formato<Servicio>.<Dominio>,cadaunocorrespondiente a un par de registros SRV/TXT. Elregistro SRVdedominio que proporciona la instancia, mientras que el TXT puede contener parámetros de configuración específicos del servicio. Un cliente puede entonces resolver el registro A/AAAA para el nombre de dominio y conectarse al servicio.

Los tipos de servicio se asignan por orden de llegada. Originalmente, DNS-SD.org mantenía un registro de tipos de servicio, [ 19 ] pero desde entonces se ha fusionado con el registro de IANA para registros DNS SRV. [ 22 ]

Historia

En 1997, Stuart Cheshire propuso adaptar el protocolo Name Binding Protocol (NDP) de Apple a las redes IP para abordar la falta de capacidad de descubrimiento de servicios. [ 23 ] Posteriormente, Cheshire se unió a Apple y redactó propuestas preliminares de la IETF para mDNS y descubrimiento de servicios basado en DNS, apoyando la transición de AppleTalk a las redes IP. En 2002, Apple anunció una implementación de ambos protocolos bajo el nombre Rendezvous [ 24 ] (más tarde renombrado Bonjour). Se incluyó por primera vez en Mac OS X 10.2 , reemplazando el Service Location Protocol ( SLP) utilizado en 10.1 . En 2013, las propuestas fueron ratificadas como RFC 6762 [ 25 ] y RFC 6763. [ 26 ]  

DNS-SD con multidifusión

mDNS utiliza paquetes similares a los de DNS unicast para resolver nombres de host, con la diferencia de que se envían a través de un enlace multicast. Cada host escucha en el puerto mDNS 5353, transmitido a una dirección multicast conocida, y resuelve las solicitudes del registro DNS de su nombre de host local (por ejemplo , A , AAAA , CNAME ) a ​​su dirección IP. Cuando un cliente mDNS necesita resolver un nombre de host local a una dirección IP, envía una solicitud DNS para ese nombre a la dirección multicast conocida; el equipo con el registro A/AAAA correspondiente responde con su dirección IP. La dirección multicast de mDNS es 224.0.0.251 para IPv4 y ff02::fb para el direccionamiento local de enlace IPv6.

Las solicitudes de descubrimiento de servicios DNS, también conocidas como DNS-SD, pueden enviarse mediante mDNS para lograr un DNS-SD sin configuración. [ 27 ] Esto utiliza registros DNS PTR , SRV y TXT para anunciar instancias de tipos de servicio, nombres de dominio para dichas instancias y parámetros de configuración opcionales para conectarse a ellas. Sin embargo, los registros SRV ahora pueden resolverse a nombres de dominio .local , que mDNS puede resolver a direcciones IP locales.

Apoyo

DNS-SD es utilizado por productos de Apple, la mayoría de las impresoras de red, muchas distribuciones de Linux, incluidas Debian y Ubuntu , [ 28 ] y varios productos de terceros para diversos sistemas operativos. Por ejemplo, muchas aplicaciones de red de OS X escritas por Apple, incluidas Safari , iChat y Mensajes , pueden usar DNS-SD para localizar servidores cercanos y clientes peer-to-peer. Windows 10 incluye soporte para DNS-SD para aplicaciones escritas con JavaScript. [ 29 ] Las aplicaciones individuales pueden incluir su propio soporte en versiones anteriores del sistema operativo, de modo que la mayoría de los clientes de mensajería instantánea y VoIP en Windows son compatibles con DNS-SD. Algunas distribuciones de Unix , BSD y Linux también incluyen DNS-SD. Por ejemplo, Ubuntu incluye Avahi , una implementación de mDNS/DNS-SD, en su distribución base.

UPnP

UPnP cuenta con algunos componentes de protocolo cuyo propósito es el descubrimiento de servicios.

SSDP

El Protocolo Simple de Descubrimiento de Servicios (SSDP) es un protocolo UPnP utilizado en Windows XP y versiones posteriores. SSDP utiliza notificaciones HTTP que proporcionan una URI de tipo de servicio y un Nombre de Servicio Único (USN). Los tipos de servicio están regulados por el Comité Directivo de Universal Plug and Play. SSDP es compatible con numerosos fabricantes de impresoras, NAS y electrodomésticos, como Brother. También es compatible con ciertas marcas de equipos de red y con muchos firewalls para pequeñas oficinas y hogares (SOHO) , donde los equipos host detrás del firewall pueden abrir puertos para aplicaciones. Asimismo, se utiliza en sistemas de PC para cine en casa para facilitar el intercambio de contenido multimedia entre los equipos host y el centro multimedia.

DLNA

Digital Living Network Alliance (DLNA) es otro conjunto de estándares que utiliza UPnP para la detección de dispositivos en red. DLNA cuenta con una larga lista de fabricantes destacados que producen dispositivos como televisores, dispositivos NAS, etc., que lo admiten. DLNA es compatible con todos los sistemas operativos principales. La detección de servicios DLNA se basa en SSDP.

Esfuerzos para lograr un protocolo estándar de la IETF

SLP es compatible con las impresoras de red de Hewlett-Packard , Novell y Sun Microsystems . SLP se describe en los RFC 2608 y RFC 3224 , y existen implementaciones disponibles tanto para Solaris como para Linux .  

AllJoyn

AllJoyn es una pila de software de código abierto para una gran variedad de dispositivos, desde dispositivos IoT hasta ordenadores de tamaño completo, para el descubrimiento y control de dispositivos en redes (Wi-Fi, Ethernet) y otros enlaces (Bluetooth, ZigBee, etc.). Utiliza mDNS y HTTP sobre UDP y otros protocolos. Sin embargo, el proyecto no ha estado activo desde 2016 y no se recomienda su uso en nuevos proyectos. [ 30 ]

Normalización

RFC 2608 , el estándar SLP para determinar dónde obtener servicios, fue publicado en junio de 1999 por el grupo de trabajo SVRLOC IETF. [ 31 ] 

RFC 3927 , un estándar para elegir direcciones para elementos en red, fue publicado en marzo de 2005 por el grupo de trabajo Zeroconf de la IETF. El grupo incluía personas de Apple, Sun y Microsoft. [ 32 ] 

LLMNR se presentó para su adopción oficial en el grupo de trabajo DNSEXT de la IETF; sin embargo, no logró obtener consenso y, por lo tanto, se publicó como RFC 4795 informativo en enero de 2007. [ 33 ] 

Tras el fracaso de LLMNR para convertirse en un estándar de Internet y dado que mDNS/DNS-SD se utiliza mucho más ampliamente que LLMNR, la IETF solicitó a Apple que presentara las especificaciones de mDNS/DNS-SD para su publicación como RFC informativa.

En febrero de 2013, mDNS y DNS-SD se publicaron como propuestas de la vía de estandarización RFC 6762 y RFC 6763 .  

Problemas de seguridad

Debido a que mDNS opera bajo un modelo de confianza diferente al de DNS unicast (confía en toda la red en lugar de en un servidor DNS designado), es vulnerable a ataques de suplantación de identidad por parte de cualquier sistema dentro del mismo dominio de difusión . Al igual que SNMP y muchos otros protocolos de administración de red, también puede ser utilizado por atacantes para obtener rápidamente información detallada de la red y sus máquinas. [ 34 ] Por esta razón, las aplicaciones aún deben autenticar y cifrar el tráfico a hosts remotos (por ejemplo, a través de RSA , SSH , etc.) después de descubrirlos y resolverlos mediante DNS-SD/mDNS. LLMNR sufre vulnerabilidades similares. [ 35 ]

Implementaciones importantes

Apple Bonjour

Bonjour de Apple utiliza mDNS y DNS Service Discovery. Apple cambió su tecnología zeroconf preferida de SLP a mDNS y DNS-SD entre Mac OS X 10.1 y 10.2 , aunque Mac OS X sigue siendo compatible con SLP.

El mDNSResponder de Apple tiene interfaces para C y Java [ 36 ] y está disponible para BSD, Apple Mac OS X, Linux, otros sistemas operativos basados ​​en POSIX y MS Windows. Las descargas para Windows están disponibles en el sitio web de Apple. [ 37 ]

Avahi

Avahi es una implementación de Zeroconf para Linux y BSD . Implementa IPv4LL , mDNS y DNS-SD. Forma parte de la mayoría de las distribuciones de Linux y viene instalada por defecto en algunas. Si se ejecuta junto con nss-mdns, también ofrece resolución de nombres de host. [ 38 ]

Avahi también implementa bibliotecas de compatibilidad binaria que emulan Bonjour y la implementación histórica de mDNS Howl, por lo que el software diseñado para usar esas implementaciones también puede utilizar Avahi a través de las interfaces de emulación.

MS Windows CE 5.0

Microsoft Windows CE 5.0 incluye la implementación propia de Microsoft de LLMNR.

Sistema

Systemd implementa tanto mDNS como LLMNR en systemd-resolved.

Cuando no hay un servidor DHCP disponible para asignar una dirección IP a un host, este puede seleccionar su propia dirección de enlace local . Mediante una dirección de enlace local, los hosts pueden comunicarse a través de este enlace, pero solo localmente; no es posible el acceso a otras redes ni a Internet. Existen varias implementaciones de direcciones IPv4 de enlace local disponibles:

  • Apple Mac OS y MS Windows han admitido direcciones link-local desde Windows 98 y Mac OS 8.5 (ambos lanzados en 1998). [ 1 ] Apple lanzó su implementación de código abierto en el paquete Darwin bootp.
  • Avahi incluye una implementación de IPv4LL en la herramienta avahi-autoipd.
  • IP de Zero-Conf (zcip) [ 39 ]
  • BusyBox puede integrar una implementación sencilla de IPv4LL.
  • Stablebox, [ 40 ] una bifurcación de Busybox, ofrece una implementación de IPv4LL ligeramente modificada llamada llad.
  • Zeroconf [ 41 ] es un paquete basado en Simple IPv4LL, una implementación más corta de Arthur van Hoff . [ 42 ]

Las implementaciones anteriores son todas demonios independientes o complementos para clientes DHCP que solo manejan direcciones IP locales de enlace. Otro enfoque es incluir soporte en clientes DHCP nuevos o existentes:

Ninguna de estas implementaciones aborda problemas del núcleo como la difusión de respuestas ARP [ 45 ] o el cierre de conexiones de red existentes.

Véase también

Referencias

Notas

  1. 1 2 3 S. Cheshire ; B. Aboba; E. Guttman (mayo de 2005). Configuración dinámica de direcciones de enlace local IPv4 . Grupo de trabajo de redes. doi : 10.17487/RFC3927 . RFC 3927 .Norma propuesta.
  2. ↑ S. Thomson; T. Narten; T. Jinmei (septiembre de 2007). Autoconfiguración de direcciones sin estado IPv6 . Grupo de trabajo de redes. doi : 10.17487/RFC4862 . RFC 4862 .Borrador de estándar. Sustituye a RFC 2462. Actualizado por RFC 7527 .  
  3. ↑ "Apipa", MS Developer Network , Microsoft, archivado del original el 18 de marzo de 2017 , recuperado el 5 de julio de 2008.
  4. ↑ "Cómo usar el direccionamiento TCP/IP automático sin un servidor DHCP", Base de conocimientos , Microsoft, 6 de enero de 2021
  5. 1 2 3 Marshall Brain y Stephanie Crawford, "Cómo funcionan los servidores de nombres de dominio" , howstuffworks
  6. 1 2 3 "Descripción del servicio Microsoft Computer Browser" . Base de conocimientos de Microsoft . Microsoft . Consultado el 1 de noviembre de 2015 .
  7. ↑ Manning, Bill; Woodcock, Bill (agosto de 2000), "Servicio de nombres de dominio multidifusión" , IETF Datatracker , IETF
  8. ↑ Biblioteca Microsoft TechNet, Resolución de nombres de multidifusión de enlace local (página web), Microsoft, 5 de mayo de 2010
  9. ↑ Licencias y marcas comerciales de Bonjour (página web), Apple
  10. ↑ API de Android 4.1 (página web)
  11. 1 2 Alineación en mDNS: reducción gradual de la resolución de nombres NetBIOS y LLMNR
  12. ↑ mDNS en la empresa
  13. ↑ mDNS y DNS-SD se abren paso lentamente en Windows 10 , blog de Ctrl, 21 de octubre de 2015 , consultado el 30 de agosto de 2017.
  14. ↑ Re: Última llamada: 'Resolución de nombres de multidifusión de enlace local (LLMNR)' al estándar propuesto (mensaje de correo electrónico), IETF, archivado del original el 07/12/2008 , recuperado el 10/02/2006
  15. ↑ Re: Resumen de la última llamada del LLMNR (mensaje de correo electrónico), IETF, archivado del original el 07/12/2008 , recuperado el 10/02/2006
  16. ↑ Resumen de la última llamada del LLMNR (mensaje de correo electrónico), IETF, archivado del original el 7 de diciembre de 2008 , recuperado el 11 de noviembre de 2005.
  17. ↑ Más detalles sobre las diferencias (mensaje de correo electrónico), IETF
  18. ↑ "Acerca de la detección de funciones" . Centro de desarrollo de Windows . Microsoft . Consultado el 1 de noviembre de 2015 .
  19. 1 2 DNS-SD
  20. ↑ RFC 2782 
  21. 1 2 RFC 1035 
  22. ↑ Tipos de servicio , DNS-SD
  23. ↑ Cheshire, Stuart , Protocolo de enlace de nombres sobre IP (discurso)
  24. ↑ Conf cero
  25. ↑ S. Cheshire; M. Krochmal (febrero de 2013). DNS multicast . IETF . doi : 10.17487/RFC6762 . RFC 6762 .
  26. ↑ S. Cheshire; M. Krochmal (febrero de 2013). Descubrimiento de servicios basado en DNS . IETF . doi : 10.17487/RFC6763 . RFC 6763 .
  27. ↑ S. Cheshire ; M. Krochmal (febrero de 2013). Descubrimiento de servicios basado en DNS . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6763 . ISSN 2070-1721 . RFC 6763 . Estándar propuesto. Actualizado por RFC 8553 . 
  28. ↑ "Manifiesto de escritorio de Ubuntu 15.10" . Ubuntu . Consultado el 23 de octubre de 2015 .
  29. ↑ "Espacio de nombres Windows.Networking.ServiceDiscovery.Dnssd" . Centro de desarrollo de Windows . Microsoft . Consultado el 1 de noviembre de 2015 .
  30. ↑ Error al compilar con gcc moderno , consultado el 31/01/2025
  31. ↑ Carta del Protocolo de Localización de Servicios (svrloc) , IETF
  32. ↑ Carta de Redes de Configuración Cero (zeroconf) , IETF, archivada del original el 1 de noviembre de 2004 , consultada el 28 de octubre de 2004.
  33. ↑ Estatuto de las extensiones DNS (dnsext) , IETF, archivado del original el 7 de marzo de 2005 , consultado el 2 de marzo de 2005.
  34. ↑ Ataques de envenenamiento de nombres (MDNS) dentro de la LAN (registro en la World Wide Web), GNU citizen, 23 de enero de 2008
  35. ↑ Lodge, David (22 de septiembre de 2015). "Cómo conseguir que Windows te dé credenciales a través de LLMNR" . Pen Test Partners .
  36. ↑ Un encuentro con Java , Centro de desarrollo de Mac, 31 de agosto de 2004
  37. ↑ "Bonjour para MS Windows 1.0.4", Soporte , Apple
  38. ↑ Lennart, nss-mdns 0.10 , DE : 0 puntero
  39. ↑ zcip , Source forge
  40. ↑ "Caja estable", Código
  41. ↑ Zeroconf , AU : UTS, archivado del original el 9 de mayo de 2005 , recuperado el 4 de mayo de 2005.
  42. ↑ AVH IPv4LL (código fuente en C), Zero conf
  43. ↑ "Zeroconf en udhcpc", udhcpc (mensaje de correo electrónico), Busy box, mayo de 2005, archivado del original el 6 de febrero de 2006 , recuperado el 15 de marzo de 2006.
  44. ↑ Marples, Roy, dhcpcd (proyecto), archivado del original (wiki) el 12/07/2010 , consultado el 07/01/2011.
  45. ↑ "Mediciones ARP de enlace local", AIR (wiki), NE : UVA

Fuentes

  • Guttman, Erik (2001), "Autoconfiguración para redes IP: Habilitación de la comunicación local", IEEE Internet Computing , 5 (3): 81–86 , doi : 10.1109/4236.935181
  • JmDNS , Source Forge, una implementación pura en Java de mDNS/DNS-SD.
  • pyZeroConf , SourceForge, 11 de julio de 2015, una implementación pura en Python de mDNS/DNS-SD.
  • Mono.Zeroconf , proyecto Mono, una biblioteca multiplataforma (Linux, MS Windows, Apple Mac) unificada Mono/.NET para Zeroconf, compatible con Bonjour y Avahi.
  • WxServDisc , Source Forge, 13 de junio de 2013, un módulo de descubrimiento de servicios multiplataforma basado en wxWidgets sin dependencias externas.
  • Cheshire, Stuart, DNS multicast (borrador).
  • Cheshire, Stuart, Especificación de descubrimiento de servicios basada en DNS (borrador), DNS-SD.
  • Cheshire, Stuart, Zeroconf (charla técnica), archivado del original (vídeo) el 2 de marzo de 2008 , recuperado el 8 de marzo de 2006..
  • Cheshire, Stuart, Zeroconf, incluidos los borradores de Internet.
  • DNS-SDDescubrimiento de servicios basado en DNS
  • "DNS multicast" .
  • Protocolo de localización de servicios, versión 2. IETF . doi : 10.17487 /RFC2608 . RFC 2608 .
  • Steinberg, Daniel; Cheshire, Stuart, Redes de configuración cero: La guía definitiva , O'Reilly.