Las redes de configuración cero ( zeroconf ) son un conjunto de tecnologías que crean automáticamente una red informática utilizable basada en Internet Protocol Suite (TCP/IP) cuando las computadoras o los periféricos de la red están interconectados. No requiere intervención manual del operador ni servidores de configuración especiales. Sin zeroconf, un administrador de red debe configurar los servicios de red , como el Protocolo de configuración dinámica de host (DHCP) y el Sistema de nombres de dominio (DNS), o configurar manualmente los ajustes de red de cada computadora.
Zeroconf se basa en tres tecnologías principales: asignación automática de direcciones de red numéricas para dispositivos en red, distribución y resolución automática de nombres de host de computadoras y ubicación automática de servicios de red , como dispositivos de impresión.
Las redes informáticas utilizan direcciones de red numéricas para identificar puntos finales de comunicaciones en una red de dispositivos participantes. Esto es similar a la red telefónica que asigna una cadena 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 manera similar a que los teléfonos estuvieran etiquetados con su número de teléfono, era una práctica común en las primeras redes adjuntar una etiqueta de dirección a los dispositivos conectados en red. La naturaleza dinámica de las redes modernas, especialmente las redes residenciales en las que los dispositivos se encienden sólo cuando es necesario, requieren mecanismos dinámicos de asignación de direcciones que no requieran la participación del usuario para la inicialización y administración. Estos sistemas se asignan automáticamente nombres comunes elegidos por el fabricante del equipo, como una marca y número de modelo, o elegidos por los usuarios para identificar su equipo. Los nombres y direcciones se ingresan automáticamente en un servicio de directorio .
Las primeras redes de computadoras se basaban en tecnologías de redes de telecomunicaciones y, por lo tanto, los protocolos tendían a dividirse en dos grupos: los destinados a conectar dispositivos locales a una red de área local (LAN) y los destinados principalmente a comunicaciones de larga distancia. Estos últimos sistemas de red de área amplia (WAN) tendían a tener una configuración centralizada, donde un administrador de red asignaba direcciones y nombres manualmente. Los sistemas LAN tendían a proporcionar una mayor automatización de estas tareas para que se pudieran agregar nuevos equipos a una LAN con un mínimo de intervención del operador y administrador.
Un ejemplo temprano de un sistema LAN sin configuración es AppleTalk , un protocolo introducido por Apple Inc. para las primeras computadoras Macintosh en los años 1980. Los Mac, así como otros dispositivos que admitan el protocolo, podrían agregarse a la red simplemente conectándolos; toda la configuración adicional fue automatizada. Cada dispositivo seleccionó automáticamente las direcciones de red utilizando un protocolo conocido como Protocolo de resolución de direcciones AppleTalk (AARP), mientras que cada máquina creó su propio servicio de directorio local utilizando un protocolo conocido como Protocolo de enlace de nombres (NBP). NBP incluía no sólo 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 Selector , que filtraba 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 para una red inicialmente la mantenía manualmente un administrador de red. Los esfuerzos para automatizar el mantenimiento de esta base de datos llevaron a la introducción de una serie de nuevos protocolos que proporcionan servicios automatizados, como el Protocolo de configuración dinámica de host (DHCP).
A los hosts de una red se les deben asignar 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 agregan nuevos dispositivos. Se introdujeron mecanismos para manejar esta tarea automáticamente, y tanto IPv4 como IPv6 ahora incluyen sistemas para la configuración automática de direcciones , lo que permite a un dispositivo determinar una dirección segura para usar a través de mecanismos simples. Para el direccionamiento de enlace local , IPv4 usa el bloque especial 169.254.0.0 / 16 , [1] mientras que los hosts IPv6 usan 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 computadoras o enrutadores.
La mayoría de los hosts IPv4 utilizan el direccionamiento de enlace local sólo 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, globales o de enlace local. Una razón es que no se requiere que los hosts IPv4 admitan múltiples direcciones por interfaz, aunque muchos sí lo hacen. Otra es que no todos los hosts IPv4 implementan resolución de nombres distribuida (por ejemplo, DNS de multidifusión ), por lo que puede resultar difícil descubrir la dirección de enlace local configurada automáticamente de otro host en la red. Descubrir la dirección asignada por DHCP de otro host requiere una resolución de nombre distribuida o un servidor DNS de unidifusión con esta información; Algunas redes cuentan con servidores DNS que se actualizan automáticamente con información de dirección y host asignados por DHCP.
Se requiere que los hosts IPv6 admitan múltiples direcciones por interfaz; Además, cada host IPv6 debe configurar una dirección de enlace local incluso cuando hay direcciones globales disponibles. Los hosts IPv6 también pueden autoconfigurar direcciones adicionales al recibir mensajes de anuncio del 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 configurada automáticamente. 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 única a nivel mundial, 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 llama configuración automática de dirección local de enlace . [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 ). La característica es compatible con Windows desde al menos Windows 98 . [4]
Los protocolos de Internet utilizan direcciones IP para las comunicaciones, pero no son fáciles de usar para los humanos; IPv6 en particular utiliza cadenas de dígitos muy largas que no se ingresan fácilmente manualmente. Para abordar este problema, Internet ha utilizado durante mucho tiempo DNS, que permite asociar nombres legibles por humanos con 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 ejemplo.org , que el software DNS de la computadora busca en las bases de datos DNS para recuperar una dirección IP y luego pasa esa dirección a la pila de protocolos para futuras comunicaciones. [5]
Para buscar una dirección mediante DNS es necesario conocer la dirección IP del servidor DNS. Normalmente, esto se logra escribiendo la dirección de un servidor conocido en un campo en uno de los dispositivos de la red. En los primeros sistemas, esto normalmente era necesario en todos los dispositivos, pero se ha elevado un nivel en la jerarquía a los servidores DHCP o dispositivos de banda ancha como 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 lado del usuario y proporciona un elemento clave de acceso sin configuración. [5]
El objetivo de DNS era proporcionar nombres uniformes a grupos de dispositivos dentro del mismo ámbito de administración, como ejemplo.org , proporcionado por un servicio de nombres. La asignación de una dirección a un dispositivo local, por ejemplo, Thirdfloorprinter.example.org , normalmente requiere acceso de administrador al servidor DNS y, a menudo, se realiza manualmente. Además, no se espera que los servidores DNS tradicionales corrijan automáticamente los cambios en la configuración. Por ejemplo, si una impresora se traslada de un piso a otro, es posible que el servidor DHCP local le asigne una nueva dirección IP. [5]
Para abordar la necesidad de configuración automática, Microsoft implementó el Servicio de nombres NetBIOS , parte del cual es el Servicio de exploración de computadoras que ya se encontraba en Microsoft Windows para trabajo en grupo 3.11 [6] ya en 1992. El Servicio de nombres NetBIOS no requiere configuración en redes con una sola subred. y puede usarse 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 gestión pequeña, pero no nula, incluso en redes empresariales muy grandes. Los protocolos que NetBIOS puede utilizar son parte del conjunto de protocolos abiertos Server Message Block (SMB) [6] que también están disponibles en Linux e iOS, aunque Windows normalmente admite una gama más amplia de los llamados dialectos que pueden negociarse entre clientes de Windows. que lo sustentan. Por ejemplo, los servicios de navegación informática que se ejecutan en sistemas operativos de servidor o versiones posteriores de Windows se eligen como los llamados navegadores maestros en lugar de aquellos que no ejecutan un sistema operativo de servidor o ejecutan versiones anteriores de Windows. [6]
En 2000, Bill Manning y Bill Woodcock describieron el servicio de nombres de dominio de multidifusión [7] que generó las implementaciones de Apple y Microsoft. Ambas implementaciones son muy similares. El DNS de multidifusión (mDNS) de Apple se publica como una propuesta de seguimiento de estándares RFC 6762, mientras que la Resolución de nombres de multidifusión local de enlace (LLMNR) de Microsoft se publica como RFC 4795 informativo. LLMNR se incluye en todas las versiones de Windows desde Windows Vista en adelante [8] y actúa como alternativa para el 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 servicio Bonjour desde 2002 en Mac OS X v10.2. La implementación 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 esencialmente automático, ya que el uso de 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 un nombre local o no), la red configuración vigente (por ejemplo, sufijos DNS vigentes) 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.
Los protocolos mDNS y LLMNR tienen diferencias menores en su enfoque de 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 , [11] que algunos miembros del IETF consideran un problema. [12] El borrador actual del LLMNR permite que un dispositivo de red elija cualquier nombre de dominio, lo que algunos miembros del IETF consideran un riesgo de seguridad. [13] mDNS es compatible con DNS-SD como se describe en la siguiente sección, mientras que LLMNR no lo es. [14]
Los servicios de nombres como mDNS, LLMNR y otros no brindan información sobre el tipo de dispositivo o su estado. Un usuario que busque una impresora cercana, por ejemplo, podría verse obstaculizado si a la impresora se le asigna el nombre "Bob". El descubrimiento de servicios proporciona información adicional sobre los dispositivos. El descubrimiento de servicios a veces se combina con un servicio de nombres , como en el Name Binding Protocol de Apple y NetBIOS de Microsoft .
NetBIOS en Windows admite hosts individuales en la red para anunciar servicios, como archivos compartidos e impresoras. También admite, por ejemplo, una impresora de red para anunciarse como un host que comparte un dispositivo de impresora y cualquier servicio relacionado que admita. Dependiendo de cómo esté conectado un dispositivo (directamente a la red o al host que lo comparte) y qué protocolos son compatibles. Sin embargo, los clientes de Windows que se conectan a él pueden preferir usar SSDP o WSD usando 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 [15] de los cuales los dos primeros son solo locales y los tres últimos admiten descubrimiento de dispositivos en red. Ninguno de estos necesita ninguna 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 utilizar la impresora sin configuración incluso en sistemas operativos muy antiguos.
Web Services Dynamic Discovery ( WS-Discovery ) es una especificación técnica que define un protocolo de descubrimiento de multidifusión para localizar servicios en una red local. Opera a través del puerto TCP y UDP 3702 y utiliza la dirección IP de multidifusión 239.255.255.250 . Como sugiere el nombre, la comunicación real entre nodos se realiza utilizando estándares de servicios web, en particular SOAP sobre UDP . Windows lo admite en forma de Servicios web para dispositivos y Perfil de dispositivos para servicios web . Muchos dispositivos, como las impresoras HP y Brother, lo admiten.
DNS-SD (DNS Service Discovery[16]) permite a los clientes descubrir una lista con nombre de instancias de servicios y resolver esos servicios en nombres de host mediante consultas DNS estándar. La especificación es compatible con el servidor DNS de unidifusión existente y el software cliente, pero funciona igualmente bien con mDNS en un entorno sin configuración. Cada instancia de servicio se describe utilizando un registro DNS SRV[17]y DNS TXT[18]. Un cliente descubre la lista de instancias disponibles para un tipo de servicio determinado consultando el registro DNS PTR[18]del nombre de ese tipo de servicio; el servidor devuelve cero o más nombres con el formato <Servicio>.<Dominio>, cada uno correspondiente a un par de registros SRV/TXT. Elregistro SRVse resuelve en el nombre de dominio que proporciona la instancia, mientras que el TXT puede contener parámetros de configuración específicos del servicio. Luego, un cliente puede resolver el registro A/AAAA para el nombre de dominio y conectarse al servicio.
Los tipos de servicio se brindan por orden de llegada. DNS-SD.org originalmente mantenía un registro de tipo de servicio, [16] pero desde entonces se ha fusionado con el registro de IANA para registros DNS SRV. [19]
En 1997, Stuart Cheshire propuso adaptar el maduro Name Binding Protocol de Apple a las redes IP para abordar la falta de capacidad de descubrimiento de servicios. [20] Posteriormente, Cheshire se unió a Apple y fue autor del borrador de propuestas del IETF para mDNS y Service Discovery basado en DNS, apoyando la transición de AppleTalk a las redes IP. En 2002, Apple anunció la implementación de ambos protocolos bajo el nombre Rendezvous [21] (más tarde rebautizado como Bonjour). Se incluyó por primera vez en Mac OS X 10.2 , reemplazando el Protocolo de ubicación de servicios (SLP) utilizado en 10.1 . [ cita necesaria ] En 2013, las propuestas fueron ratificadas como RFC 6762 [22] y RFC 6763. [23]
mDNS utiliza paquetes similares al DNS de unidifusión para resolver nombres de host, excepto que se envían a través de un enlace de multidifusión. Cada host escucha en el puerto mDNS, 5353, transmitido a una dirección de multidifusión conocida y resuelve las solicitudes para el registro DNS de su nombre de host .local (por ejemplo, A , AAAA , CNAME ) en su dirección IP. Cuando un cliente mDNS necesita resolver un nombre de host local en una dirección IP, envía una solicitud DNS para ese nombre a la dirección de multidifusión conocida; el ordenador con el registro A/AAAA correspondiente responde con su dirección IP. La dirección de multidifusión mDNS es 224.0.0.251 para IPv4 y ff02::fb para direccionamiento local de enlace IPv6.
Las solicitudes DNS Service Discovery, también conocidas como DNS-SD, también se pueden enviar utilizando mDNS para generar DNS-SD sin configuración. [24] Esto utiliza registros DNS PTR , SRV, TXT para anunciar instancias de tipos de servicios, nombres de dominio para esas instancias y parámetros de configuración opcionales para conectarse a esas instancias. Pero los registros SRV ahora pueden resolverse en nombres de dominio .local , que mDNS puede resolver en direcciones IP locales.
DNS-SD es utilizado por los productos Apple, la mayoría de las impresoras de red, muchas distribuciones de Linux, incluidas Debian y Ubuntu , [25] y varios productos de terceros para varios sistemas operativos. Por ejemplo, muchas aplicaciones de red OS X escritas por Apple, incluidas Safari , iChat y Messages , pueden usar DNS-SD para localizar servidores cercanos y clientes punto a punto. Windows 10 incluye soporte para DNS-SD para aplicaciones escritas con JavaScript. [26] 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 admiten DNS-SD. Algunas distribuciones de Unix , BSD y Linux también incluyen DNS-SD. Por ejemplo, Ubuntu incluye Avahi , una implementación mDNS/DNS-SD, en su distribución base.
UPnP tiene algunos componentes de protocolo con el propósito de descubrir servicios.
El Protocolo simple de descubrimiento de servicios (SSDP) es un protocolo UPnP que se utiliza en Windows XP y versiones posteriores. SSDP utiliza anuncios de notificación HTTP que brindan un URI de tipo de servicio y un nombre de servicio único (USN). Los tipos de servicios están regulados por el Comité Directivo Universal Plug and Play. SSDP es compatible con muchos fabricantes de impresoras, NAS y electrodomésticos, como Brother. Es compatible con ciertas marcas de equipos de red y en muchos dispositivos de firewall SOHO , donde las computadoras host detrás de él pueden perforar agujeros para las aplicaciones. También se utiliza en sistemas de PC de cine en casa para facilitar el intercambio de medios entre las computadoras host y el centro multimedia.
Digital Living Network Alliance (DLNA) es otro conjunto de estándares que utiliza UPnP para el descubrimiento de dispositivos en red. DLNA tiene una larga lista de fabricantes destacados que producen dispositivos como televisores, dispositivos NAS, etc., que lo admiten. DLNA es compatible con todos los principales sistemas operativos. El descubrimiento de servicios DLNA se superpone al SSDP.
SLP es compatible con las impresoras de red de Hewlett-Packard , Novell y Sun Microsystems . SLP se describe en RFC 2608 y RFC 3224 y hay implementaciones disponibles para Solaris y Linux .
AllJoyn es una pila de software de código abierto para una gran variedad de dispositivos, desde dispositivos IoT hasta computadoras de tamaño completo, para el descubrimiento y control de dispositivos en redes (Wifi, Ethernet) y otros enlaces (Bluetooth, ZigBee, etc.). Utiliza mDNS y HTTP sobre UDP y otros protocolos.
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. [27]
RFC 3927, un estándar para elegir direcciones para elementos en red, fue publicado en marzo de 2005 por el grupo de trabajo IETF Zeroconf. El grupo incluía personas de Apple, Sun y Microsoft. [28]
LLMNR se presentó para su adopción oficial en el grupo de trabajo DNSEXT del IETF; sin embargo, no logró obtener consenso y, por lo tanto, se publicó como RFC 4795 informativo en enero de 2007. [29]
Tras el fracaso de LLMNR para convertirse en un estándar de Internet y dado que mDNS/DNS-SD se usa mucho más ampliamente que LLMNR, el IETF le pidió a Apple que enviara las especificaciones mDNS/DNS-SD para su publicación también como RFC informativo. [ cita necesaria ]
En febrero de 2013, mDNS y DNS-SD se publicaron como propuestas de seguimiento de estándares RFC 6762 y RFC 6763.
Debido a que mDNS opera bajo un modelo de confianza diferente al DNS de unidifusión: 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 transmisión . Al igual que SNMP y muchos otros protocolos de gestión de red, los atacantes también pueden utilizarlo para obtener rápidamente un conocimiento detallado de la red y sus máquinas. [30] Debido a esto, 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 a través de DNS-SD/mDNS. LLMNR sufre de vulnerabilidades similares. [31]
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 SLP sigue siendo compatible con Mac OS X.
mDNSResponder de Apple tiene interfaces para C y Java [32] y está disponible en BSD, Apple Mac OS X, Linux, otros sistemas operativos basados en POSIX y MS Windows. Las descargas de Windows están disponibles en el sitio web de Apple. [33]
Avahi es una implementación de Zeroconf para Linux y BSD . Implementa IPv4LL , mDNS y DNS-SD. Es parte de la mayoría de las distribuciones de Linux y está instalado de forma predeterminada en algunas. Si se ejecuta junto con nss-mdns, también ofrece resolución de nombres de host. [34]
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 creado para usar esas implementaciones también puede utilizar Avahi a través de las interfaces de emulación.
Microsoft Windows CE 5.0 incluye la implementación propia de LLMNR de Microsoft.
Systemd implementa mDNS y LLMNR en formato systemd-resolved.
Cuando no hay un servidor DHCP disponible para asignar una dirección IP a un host, el host puede seleccionar su propia dirección de enlace local . Al utilizar una dirección de enlace local, los hosts pueden comunicarse a través de este enlace, pero sólo localmente; El acceso a otras redes e Internet no es posible. Hay algunas implementaciones de direcciones IPv4 locales de enlace disponibles:
Las implementaciones anteriores son demonios o complementos independientes para clientes DHCP que solo tratan con direcciones IP de enlace local. Otro enfoque es incluir soporte en clientes DHCP nuevos o existentes:
Ninguna de estas implementaciones aborda problemas del kernel como la transmisión de respuestas ARP [41] o el cierre de conexiones de red existentes.
Notas
Fuentes