La red de configuración cero ( zeroconf ) es un conjunto de tecnologías que crea automáticamente una red informática utilizable basada en el conjunto de protocolos de Internet (TCP/IP) cuando se interconectan ordenadores o periféricos de red. No requiere la intervención manual de un operador ni servidores de configuración especiales. Sin zeroconf, un administrador de red debe configurar 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 ordenador.
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áticas 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 los puntos finales de las 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 para 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 cómo se etiquetaban los teléfonos con su número de teléfono, en las primeras redes era una práctica común colocar una etiqueta de dirección en los dispositivos conectados en red. La naturaleza dinámica de las redes modernas, especialmente las redes residenciales en las que los dispositivos se encienden solo cuando es necesario, requiere mecanismos de asignación de direcciones dinámicas que no requieran la participación del usuario para su inicialización y administración. Estos sistemas se asignan automáticamente nombres comunes elegidos por el fabricante del equipo, como una marca y un número de modelo, o elegidos por los usuarios para identificar su equipo. Los nombres y las direcciones se ingresan automáticamente en un servicio de directorio .
Las primeras redes informáticas 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 redes de área amplia (WAN) tendían a tener una configuración centralizada, en la que un administrador de red asignaba manualmente direcciones y nombres. Los sistemas LAN tendían a proporcionar una mayor automatización de estas tareas, de modo que se pudieran añadir nuevos equipos 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 las primeras computadoras Macintosh en la década de 1980. Las Mac, así como otros dispositivos compatibles con el protocolo, podían agregarse a la red simplemente conectándolos; toda la configuración posterior estaba automatizada. Las direcciones de red eran seleccionadas automáticamente por cada dispositivo utilizando un protocolo conocido como AppleTalk Address Resolution Protocol (AARP), mientras que cada máquina creaba su propio servicio de directorio local utilizando un protocolo conocido como Name Binding Protocol (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 de una red era mantenida inicialmente de forma manual por un administrador de red. Los esfuerzos por automatizar el mantenimiento de esta base de datos condujeron a la introducción de una serie de nuevos protocolos que proporcionaban 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 autoconfiguración de direcciones , lo que permite que un dispositivo determine una dirección segura para usar a través de mecanismos simples. Para el direccionamiento local de enlace , 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 computadora o enrutadores.
La mayoría de los hosts IPv4 utilizan el direccionamiento local de enlace solo como último recurso cuando no hay un servidor DHCP disponible. De lo contrario, un host IPv4 utiliza su dirección asignada por DHCP para todas las comunicaciones, globales o locales de enlace. Una razón es que los hosts IPv4 no están obligados a admitir varias direcciones por interfaz, aunque muchos lo hacen. Otra es que no todos los hosts IPv4 implementan la resolución de nombres distribuida (por ejemplo, DNS de multidifusión ), por lo que descubrir la dirección local de enlace configurada automáticamente de otro host en la red puede ser difícil. Descubrir la dirección asignada por DHCP de otro host requiere una resolución de nombres distribuida o un servidor DNS de unidifusión 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 hay direcciones globales disponibles. Además, los hosts IPv6 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 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 globalmente única, una propiedad básica del EUI-64. La pila de protocolos IPv6 también incluye la detección de direcciones duplicadas para evitar conflictos con otros hosts. En IPv4, el método se denomina configuración automática de direcciones locales de enlace . [1] Sin embargo, Microsoft se refiere a esto como Direccionamiento automático de IP privado (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 pueden ingresar manualmente con facilidad. Para abordar este problema, Internet ha utilizado durante mucho tiempo el DNS, que permite asociar nombres legibles por humanos con direcciones IP e incluye un 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 entrega 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. Esto se ha logrado normalmente escribiendo la dirección de un servidor conocido en un campo de uno de los dispositivos de la red. En los primeros sistemas, esto era normalmente necesario en todos los dispositivos, pero se ha trasladado a un nivel superior de 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 del DNS era proporcionar nombres uniformes a grupos de dispositivos dentro del mismo ámbito de administración, como example.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 de forma manual. Además, no se espera que los servidores DNS tradicionales corrijan automáticamente los cambios en la configuración. Por ejemplo, si se traslada una impresora 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ó NetBIOS Name Service , parte del cual es el Computer Browser Service ya en Microsoft Windows for Workgroups 3.11 [6] ya en 1992. NetBIOS Name Service no requiere configuración en redes con una sola subred y se puede utilizar junto con un servidor WINS o un servidor DNS de Microsoft que admita el registro automático seguro de direcciones. Este sistema tiene una pequeña, pero no nula, sobrecarga de administración incluso en redes empresariales muy grandes. Los protocolos que NetBIOS puede utilizar son parte de la suite 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 denominados dialectos que se pueden negociar entre los clientes de Windows que lo admiten. Por ejemplo, los Computer Browser Services que se ejecutan en sistemas operativos de servidor o versiones posteriores de Windows se eligen como el denominado navegador maestro sobre 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 dio origen a las implementaciones de Apple y Microsoft. Ambas implementaciones son muy similares. El DNS de multidifusión (mDNS) de Apple se publicó 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 publicó como RFC 4795 informativo. LLMNR se incluye en todas las versiones de Windows a partir de Windows Vista [8] y actúa como una alternativa paralela para el Servicio de nombres NetBIOS de Microsoft sobre IPv4 y como un 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 se incluye 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 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 un nombre local o no), la configuración de red vigente (por ejemplo, los 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 pequeñas diferencias 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 utilizando una dirección IP de multidifusión especial. Esto introduce una semántica especial para el dominio de nivel superior local , [11] lo que algunos miembros del IETF consideran un problema. [12] El borrador actual de 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 proporcionan información sobre el tipo de dispositivo o su estado. Un usuario que busque una impresora cercana, por ejemplo, podría verse obstaculizado si la impresora tuviera 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 Protocolo de vinculación de nombres de Apple y NetBIOS de Microsoft .
NetBIOS en Windows permite que los hosts individuales de la red anuncien servicios, como archivos compartidos e impresoras. También permite, por ejemplo, que una impresora de red se anuncie a sí misma como un host que comparte un dispositivo de impresión y cualquier servicio relacionado que admita. Esto depende de cómo esté conectado un dispositivo (a la red directamente o al host que lo comparte) y de qué protocolos sean compatibles. Sin embargo, los clientes de Windows que se conecten a él pueden preferir usar SSDP o WSD mediante 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 el descubrimiento de dispositivos en red. Ninguno de ellos necesita ninguna configuración para su uso en la subred local. Tradicionalmente, NetBIOS solo se ha admitido en impresoras costosas para uso corporativo, aunque algunas impresoras de nivel de entrada con Wi-Fi o Ethernet lo admiten de forma nativa, lo que permite que la impresora se use 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 sobre el puerto TCP y UDP 3702 y utiliza la dirección de multidifusión IP 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-over-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 servicio y resolver esos servicios en nombres de host mediante consultas DNS estándar. La especificación es compatible con el software de cliente y servidor DNS unicast existente, pero funciona igualmente bien con mDNS en un entorno de configuración cero. 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 de la forma <Service>.<Domain>, 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. 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. En un principio, DNS-SD.org mantenía un registro de tipos de servicio [16], pero desde entonces se ha fusionado con el registro de la IANA para registros SRV de DNS [19] .
En 1997, Stuart Cheshire propuso adaptar el maduro Protocolo de Vinculación de Nombres 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 de propuestas preliminares de IETF para mDNS y Descubrimiento de Servicios basado en DNS, apoyando la transición de AppleTalk a redes IP. En 2002, Apple anunció una implementación de ambos protocolos bajo el nombre de Rendezvous [21] (más tarde renombrado Bonjour). Se incluyó por primera vez en Mac OS X 10.2 , reemplazando al Protocolo de Ubicación de Servicios (SLP) utilizado en 10.1 . [ cita requerida ] En 2013, las propuestas fueron ratificadas como RFC 6762 [22] y RFC 6763. [23]
mDNS utiliza paquetes similares a los de unicast DNS 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 ) 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 de multidifusión conocida; la computadora 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 el direccionamiento de enlace local IPv6.
Las solicitudes DNS Service Discovery, también conocidas como DNS-SD , también se pueden enviar mediante mDNS para generar DNS-SD sin configuración. [24] Esto utiliza registros DNS PTR , SRV y TXT para anunciar instancias de tipos de servicio, 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 productos Apple, la mayoría de impresoras de red, muchas distribuciones Linux incluyendo Debian y Ubuntu , [25] y una serie de productos de terceros para varios sistemas operativos. Por ejemplo, muchas aplicaciones de red OS X escritas por Apple, incluyendo Safari , iChat y Messages , pueden usar DNS-SD para localizar servidores cercanos y clientes peer-to-peer. Windows 10 incluye soporte para DNS-SD para aplicaciones escritas usando JavaScript. [26] Las aplicaciones individuales pueden incluir su propio soporte en versiones anteriores del sistema operativo, de tal manera que la mayoría de los clientes de mensajería instantánea y VoIP en Windows soportan DNS-SD. Algunas distribuciones 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 tiene algunos componentes de protocolo con el propósito de descubrimiento de servicios.
El protocolo simple de descubrimiento de servicios (SSDP) es un protocolo UPnP que se utiliza en Windows XP y versiones posteriores. El SSDP utiliza anuncios de notificación HTTP que proporcionan un URI de tipo de servicio y un nombre de servicio único (USN). Los tipos de servicio están regulados por el Comité Directivo Universal Plug and Play. El SSDP es compatible con muchos fabricantes de impresoras, NAS y dispositivos, como Brother. Es compatible con ciertas marcas de equipos de red y con muchos dispositivos de firewall SOHO , donde los equipos host que se encuentran detrás pueden abrir huecos para las aplicaciones. También se utiliza en sistemas de PC de cine en casa para facilitar el intercambio de medios entre los equipos host y el centro multimedia.
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 principales sistemas operativos. La detección de servicios DLNA se realiza sobre 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 tanto para Solaris como para 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 (Wi-Fi, Ethernet) y otros enlaces (Bluetooth, ZigBee, etc.). Utiliza mDNS y HTTP sobre UDP y otros protocolos.
El RFC 2608, el estándar SLP para determinar dónde obtener servicios, fue publicado en junio de 1999 por el grupo de trabajo IETF SVRLOC. [27]
En marzo de 2005, el grupo de trabajo IETF Zeroconf publicó el RFC 3927, un estándar para elegir direcciones para elementos en red. El grupo incluía a personas de Apple, Sun y Microsoft. [28]
LLMNR fue presentado para su adopción oficial en el grupo de trabajo DNSEXT de IETF, sin embargo no logró obtener consenso y por lo tanto fue publicado como RFC 4795 informativo en enero de 2007. [29]
Tras el fracaso de LLMNR en convertirse en un estándar de Internet y dado que mDNS/DNS-SD se utiliza mucho más ampliamente que LLMNR, el IETF le pidió a Apple que presentara las especificaciones mDNS/DNS-SD para su publicación también como RFC informativo. [ cita requerida ]
En febrero de 2013, mDNS y DNS-SD se publicaron como propuestas de estándares RFC 6762 y RFC 6763.
Debido a que mDNS opera bajo un modelo de confianza diferente al de un 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 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 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.
El 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 para 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. Forma parte de la mayoría de las distribuciones de Linux y se instala 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 utilizar esas implementaciones también puede utilizar Avahi a través de las interfaces de emulación.
Microsoft Windows CE 5.0 incluye la propia implementación de LLMNR de Microsoft.
Systemd implementa mDNS y LLMNR en systemd-resolved.
Cuando no hay ningún servidor DHCP disponible para asignar una dirección IP a un host, el host puede seleccionar su propia dirección local de enlace . Al utilizar una dirección local de enlace, los host pueden comunicarse a través de este enlace, pero solo de forma local; no es posible acceder a otras redes ni a Internet. Hay algunas implementaciones de direcciones IPv4 locales de enlace disponibles:
Las implementaciones anteriores son todas daemons o complementos independientes para clientes DHCP que solo se ocupan de direcciones IP locales de enlace. Otro enfoque es incluir compatibilidad en clientes DHCP nuevos o existentes:
Ninguna de estas implementaciones aborda problemas del núcleo como la difusión de respuestas ARP [41] o el cierre de conexiones de red existentes.
Notas
Fuentes