Red de configuración cero

Ir a: navegación, búsqueda de

Red de configuración cero (Zeroconf) es un conjunto de tecnologías que crea automáticamente un usable red informática basado en el Conjunto de protocolos de Internet (TCP/IP) cuando los ordenadores o periféricos de red están interconectados. No requiere la intervención del operador manual o los servidores de configuración especial.

Zeroconf se basa en tres tecnologías de base: asignación de direcciones de red numérica para los dispositivos en red, distribución automática y resolución de la computadora nombres de hosty la localización automática de servicios de red, tales como dispositivos de impresión. Sin zeroconf, un administrador de red debe configurar servicios, tales como Dynamic Host Configuration Protocol (DHCP) y Sistema de nombres de dominio (DNS), o configurar de cada ordenador la red manualmente.

Contenido

  • 1 Fondo
  • 2 Selección de direcciones
  • 3 Resolución de nombres
  • 4 Servicio de descubrimiento
    • 4.1 Descubrimiento de servicio basadas en DNS
      • 4.1.1 Apple multicast DNS/DNS-SD
    • 4.2 Microsoft UPnP SSDP
      • 4.2.1 Esfuerzos hacia un protocolo estándar IETF
  • 5 Normalización
  • 6 Cuestiones de seguridad
  • 7 Principales implementaciones
    • 7.1 Apple Bonjour
    • 7.2 Avahi
    • 7.3 MS Windows CE 5.0
    • 7.4 Direcciones locales del vínculo IPv4
  • 8 Véase también
  • 9 Referencias
  • 10 Enlaces externos

Fondo

Redes de computadoras utilizan direcciones numéricas para identificar los extremos 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 el moderno protocolos de redes, información a transmitir se divide en una serie de paquetes de red. Cada paquete contiene las direcciones de origen y de destino. Routers de red examinan estas direcciones para determinar la mejor ruta de red en la expedición del paquete de datos en cada paso hacia su destino.

Semejantemente a los teléfonos mostrando un número de la tarjeta, era una práctica común en redes tempranas para colocar una etiqueta de dirección en los dispositivos en red. La naturaleza dinámica de las redes modernas, especialmente las redes residenciales en los dispositivos que están poder solamente cuando sea necesario, requiere ad-hoc, los mecanismos de asignación de dirección dinámica que no requieren intervención del usuario para la inicialización y manejo. Estos sistemas asignan automáticamente direcciones a nombres comunes, elegido por el fabricante del equipo, como el número de modelo y marca de fábrica, o elegidos por los usuarios para la identificación de sus equipos. Los nombres y direcciones se introducen automáticamente en un servicio de directorio.

La historia temprana de las redes de computadora basada en tecnologías de las redes de telecomunicaciones y por lo tanto, protocolos tendidos a divididos en dos grupos, aquellos destinados a conectar dispositivos locales en un red de área local (LAN) y aquellos destinados principalmente para las comunicaciones de larga distancia. Red de área amplia Sistemas (WAN) solían han centralizado de configuración, donde una autoridad podría asignar direcciones y nombres, a menudo utilizando medios manuales.

Sistemas de LAN tendían a proporcionar más automatización de estas tareas, para que nuevos equipos podrían agregarse a una LAN con un mínimo de intervención del operador. Es un ejemplo temprano de un sistema de cero-configuración de LAN AppleTalk, un protocolo presentado por Apple Inc. para los primeros Macintosh computadoras en la década de 1980. Mac, así como otros dispositivos compatibles con el protocolo como el Apple IIGS y una variedad de impresoras y servidores de archivos, podrían añadirse a la red, conectando toda la configuración adicional fue automatizado. Direcciones de red automáticamente fueron seleccionadas por cada dispositivo utilizando un protocolo conocido como AARP, mientras que cada máquina construyó su propio servicio de directorio local mediante un protocolo conocido como NBP. NBP incluía no sólo un nombre, sino el tipo de dispositivo y cualquier información adicional suministrada por el usuario como su estado físico del dispositivo o ubicación. Los usuarios podrían ver cualquier dispositivo en la red con la aplicación Selector, que filtran nombres basados en el tipo de dispositivo.

En Protocolo de Internet las redes, la Sistema de nombres de dominio fue mantenida generalmente manualmente por un administrador de red. Esto condujo a la introducción de un número de nuevos protocolos brindando servicios automatizados, tales como la Dynamic Host Configuration Protocol (DHCP).

Selección de direcciones

Los protocolos de Internet asignan objetos en la red una o más único Direcciones IP identifican a otros dispositivos en la misma red. Estas direcciones funcionan de manera similar a números de teléfono, permitiendo que los dispositivos conectar a otro mediante la identificación del dispositivo remoto por su dirección de la misma manera que una llamada telefónica está conectada mediante la marcación de un número de teléfono.

A diferencia del sistema de teléfono, una red IP no necesariamente incluye a algún tipo de autoridad central que asigna las direcciones como se agregan nuevos dispositivos. Se introdujeron mecanismos para manejar esta tarea y IPv4 e IPv6 ahora incluyen sistemas para configuración automática de direcciones, que permite que un dispositivo para determinar una dirección segura para usar a través de mecanismos simples. Para local de vínculo abordar, IPv4 utiliza el bloque especial 169.254.0.0/16 como se describe en RFC 3927 mientras que hosts IPv6 utilizan el prefijo fe80:: / 10. Más comúnmente, en las redes modernas direcciones son asignadas por un DHCP servidor, a menudo incorporado al hardware redes comunes como anfitriones de computadora o routers.

La mayoría hosts IPv4 utilizan el direccionamiento local de vínculo sólo como último recurso cuando un servidor DHCP no está disponible. Un host IPv4 si no usa su dirección asignada por DHCP para todas las comunicaciones, globales o local de vínculo. Una razón es que hosts IPv4 no están obligados a soportar múltiples direcciones por interfaz, aunque muchos lo hacen. Otra es que no todos los implementos de host IPv4 distribución (por ejemplo, la resolución de nombres Multicast DNS), así que puede ser difícil detectar la dirección local de vínculo se autoconfigure de otro host en la red. Sin embargo, también descubrir la dirección asignada por DHCP de otro host requiere la resolución de nombres distribuidos o un servidor DNS de unidifusión con esta información, y algunas redes disponen de servidores DNS que se actualizan automáticamente con la información de host y la dirección asignada por DHCP.

Hosts IPv6 están obligados a soportar múltiples direcciones por interfaz; Además, cada host IPv6 es necesaria para configurar una dirección de enlace local incluso cuando las direcciones globales están disponibles. Hosts IPv6 pueden además Self-configurar direcciones adicionales tras la recepción de mensajes de anuncio de encaminador, eliminando así la necesidad de un servidor DHCP.[1]

Hosts IPv4 e IPv6 pueden generar aleatoriamente la parte específica del host de una dirección se autoconfigure. Hosts IPv6 generalmente combinan un prefijo de hasta 64 bits con un EUI-64 de 64 bits derivado del 48-bit asignado en fábrica IEEE Dirección MAC. La dirección MAC tiene la ventaja de ser única en el mundo, una propiedad heredada por la EUI-64. La pila del protocolo IPV6 incluye detección de direcciones duplicadas para evitar conflictos con otros hosts. En IPv4, se llama al método configuración automática de direcciones locales del vínculo.[2] Sin embargo, Microsoft se refiere a esto como Automatic Private IP Addressing (APIPA)[3] o Configuración automática del Protocolo Internet (IPAC) (apoyados desde por lo menos Windows 98[4]).

Resolución de nombres

Los protocolos de Internet utilizan direcciones IP para las comunicaciones, pero estos no son muy legibles; IPv6 utiliza en particular muy largas cadenas de dígitos que no son fácilmente introducidas manualmente. Para solucionar este problema, el internet ha usado por mucho tiempo el Sistema de nombres de dominio (DNS), que permite nombres legibles ser asociado a direcciones IP e incluye código para buscar estos nombres de un sistema de base de datos jerárquica configurados automáticamente. Los usuarios escribir en común nombres, como Copro.org, que busca en las bases de datos DNS remotos, software DNS de la computadora se traduce en la correcta dirección IP, y luego las manos de encima esa dirección a la redes software para comunicaciones más.[5]

Buscando una dirección DNS requiere la dirección IP del servidor DNS a ser conocido. Normalmente esto se ha logrado escribiendo la dirección de un servidor conocido en un campo en uno de los dispositivos en la red. En los primeros sistemas esto fue requerido normalmente en todos los dispositivos, pero esto ha sido empujado a una capa en la jerarquía de los servidores DHCP o dispositivos de red de área amplia como módems de cable reciben esta información de su proveedor de servicios IP. Esto ha reducido la carga de administración de usuario y proporciona un elemento clave de acceso de configuración cero.[5]

DNS pretendía proporcionar nombres uniformes a los grupos de dispositivos dentro del mismo reino de administración, tales como Copro.org, proporcionada por un servicio de nombres. Asignación de una dirección a un dispositivo local, por ejemplo, thirdfloorprinter.copro.org, normalmente requiere acceso de administrador en el servidor DNS y a menudo se lleva a cabo manualmente. Además, los servidores DNS tradicionales no se esperan corregir automáticamente a los cambios de configuración. Por ejemplo, si una impresora se mueve de un piso a otro se puede asignar una nueva dirección IP del servidor DHCP local.[5]

Para atender las necesidades de configuración automatizada, en el año 2000, Bill Manning y Bill Woodcock describieron el Multidifusión Domain Name Service[6] que generó las implementaciones por Apple y Microsoft. Ambas implementaciones son muy similares. Apple Multicast DNS (mDNS) se publica como las normas de pista propuesta)RFC 6762), mientras que el de Microsoft Resolución de nombres multidifusión local de vínculo (LLMNR) es poco utilizado[citación necesitada] y no es la especificación de un IETF un seguimiento de las normas de publicación. El último fue publicado como informativos RFC 4795.

Los dos protocolos tienen diferencias menores en su enfoque de resolución de nombres. mDNS permite que un dispositivo de red elegir un nombre de dominio en el locales DNS espacio de nombres y anunciar usando una dirección IP multicast especial. Esto introduce una semántica especial para el dominio locales,[7] que se considera un problema por algunos miembros de la IETF.[8] El proyecto actual de LLMNR permite que un dispositivo de red elegir cualquier nombre de dominio, que se considera un riesgo de seguridad por algunos miembros de la IETF.[9] mDNS es compatible con DNS-SD como se describe en la sección siguiente, aunque no es LLMNR.[10]

Servicio de descubrimiento

mDNS proporciona la capacidad de proporcionar y encontrar nombres DNS para dispositivos locales, sin embargo, no proporciona información sobre el tipo de dispositivo o su estado. Un usuario buscando una impresora cercana, por ejemplo, podría ser bloqueado si la impresora se dio el nombre de "Bob".

Este es el propósito de la protocolos de descubrimiento de servicio (SDP), que proporcionan el concepto de"descubrimiento". Sistemas de SDP a veces se han combinado con servicios de nombres, como en Apple NBP, mientras que muchos sistemas carecían de este concepto, como enredaderas. SDP es una adición relativamente nueva a la propiedad intelectual.

Descubrimiento de servicio basadas en DNS

DNS-SD se describe en RFC 6763. Esta norma permite a los clientes a descubrir una lista de servicios por tipo en un dominio especificado mediante consultas DNS estándar llamada. La instancia del servicio puede describirse utilizando un (DNS SRVRFC 2782) y (TXT DNSRFC 1035) registro. Esta especificación es compatible con ambos DNS de multidifusión y unidifusión DNS server y client software existente. Un cliente Descubre la lista de disponibles instancias de un tipo de servicio determinado mediante una consulta para un registro DNS PTR [RFC1035] con el nombre de la forma "< servicio >. < dominio >", que devuelve un conjunto de cero o más nombres, que son los nombres de los pares de registros DNS SRV/TXT antes mencionados.

Apple multicast DNS/DNS-SD

En 1997 Stuart Cheshire propuesta[11][¿fuente auto-publicado?] adaptación Apple Computeres Nombre de protocolo de enlace para redes IP. Cheshire posteriormente se unió a Apple y autor IETF propuestas de proyecto para Multicast DNS y el descubrimiento de servicio basadas en DNS, apoyando la transición de AppleTalk Para IP creación de redes. En 2002,[12] Apple anunció la implementación de ambos protocolos bajo el nombre de Rendezvous (retitulado más adelante Bonjour), incluido en Mac OS X 10.2 y reemplazar la Protocolo de ubicación de servicio utilizado en 10.1.[citación necesitada] En 2013, las propuestas fueron ratificadas como RFC 6762[13] y RFC 6763.[14]

Multicast DNS (mDNS) es un protocolo que utiliza la API similares a unicast Sistema de nombres de dominio Pero implementado sobre un protocolo de multidifusión. Cada equipo de la LAN almacena su propia lista de DNS registros de recursos (por ejemplo, A, MX, SRV) y se une al grupo de multidifusión de mDNS. Cuando un cliente de mDNS quiere saber la dirección IP de un computadora dado su nombre, mDNS cliente envía una solicitud a una dirección de multidifusión conocida; el ordenador con el correspondiente un registro responde con su dirección IP. El mDNS es dirección de multidifusión 224.0.0.251 para IPv4 y ff02::FB para el direccionamiento IPv6 local de vínculo.

Descubrimiento de servicio basadas en DNS (DNS-SD) es la otra mitad de la solución de Apple, construida sobre el sistema de nombres de dominio; ver RFC 6763.[15] Se utiliza en productos de Apple, muchas impresoras de red y un número de aplicaciones en diferentes sistemas operativos y productos de terceros. La solución de Apple utiliza mensajes de DNS, en contraste con tecnologías competidoras de Microsoft, SSDP, que utiliza los mensajes HTTP. Utiliza DNS SRV, TXT, y PTR registros para anunciar los nombres de instancia de servicio. Los anfitriones ofreciendo servicios publican los detalles de los servicios disponibles: ejemplo, tipo de servicio, nombre de dominio y los parámetros de configuración opcional. Tipos de servicio reciben informalmente en primera base. Existe un registro de tipo de servicio,[16] mantenido y publicado por DNS-SD.org.[17]

Muchos Apple Mac OS X redes de clientes, tales como la Navegador Safari y el iChat software de mensajería instantánea, utilizar DNS-SD para localizar cerca de servidores. En MS Windows, algunos mensajes instantáneos y VoIP Algunos clientes compatibles con DNS-SD. Unix, BSD, y las distribuciones de Linux también incluyen funcionalidad DNS-SD.

Microsoft UPnP SSDP

Protocolo de descubrimiento de servicio simple (SSDP) es un UPnP Protocolo, utilizado en la em. Windows XP y varias marcas de equipos de red. SSDP utiliza anuncios de notificación HTTP que dan un tipo de servicio URI y un servicio único nombre (USN). Tipos de servicio son regulados por el Universal Plug and Play del Comité Directivo.

SSDP se apoya en muchos SOHO Aparatos de cortafuegos, donde equipos host detrás de él pueden perforar los orificios para las aplicaciones. También se utiliza en Centro de medios sistemas, donde los medios de comunicación intercambian entre equipos host y el centro de medios de comunicación se facilita mediante SSDP.

Esfuerzos hacia un protocolo estándar IETF

Protocolo de ubicación de servicio (SLP) es apoyada por Hewlett-Packardes red impresoras, Novell, y Sun Microsystems. SLP se describe en RFC 2608 y RFC 3224 y están disponibles tanto para las implementaciones Solaris y Linux.

Normalización

RFC 3927, un estándar para elegir direcciones para artículos en red, fue publicado en marzo de 2005 por el grupo de trabajo IETF Zeroconf, que incluye individuos de Apple, Sun y Microsoft.[18]

LLMNR fue presentado para su aprobación oficial en el grupo de trabajo IETF DNSEXT, sin embargo no lograron ganar consenso y así ha sido publicado como RFC informativo solamente: RFC 4795.[19]

Tras el fracaso de LLMNR para convertirse en un estándar de Internet, Apple se le preguntó por la IETF para presentar las especificaciones mDNS/DNS-SD para su publicación como RFC informativo, dado que mDNS/DNS-SD se utiliza mucho más ampliamente que LLMNR. En febrero de 2013 mDNS y DNS-SD fueron publicados como estándares pista propuestas RFC 6762 y RFC 6763.

RFC 2608, el estándar SLP para averiguar dónde obtener servicios, fue publicado por el grupo de trabajo IETF SVRLOC.[20]

Cuestiones de seguridad

Porque mDNS opera bajo un modelo de confianza diferentes de unidifusión DNS — confiando en toda la red en lugar de un servidor DNS designado, es vulnerable a ataques de suplantación de identidad por cualquier sistema dentro del rango IP multicast. Como SNMP y muchos otros protocolos de gestión de red, también puede ser utilizado por los atacantes para ganar rápidamente el conocimiento detallado de la red y sus máquinas.[21]

Principales implementaciones

Apple Bonjour

Bonjour (anteriormente conocido como Rendezvous) de Apple Inc., utiliza multicast DNS y DNS Service Discovery. Apple cambió su tecnología zeroconf preferido de SLP mDNS y DNS-SD entre Mac OS X 10.1 y 10.2, aunque SLP continúa con el apoyo de Mac OS X.

MDNSResponder de Apple posee interfaces para C y Java[22] y está disponible en BSD, Apple Mac OS X, Linux, otros POSIX sistemas operativos basados y MS Windows. Las descargas de Windows están disponibles desde el sitio web de Apple.[23]

Avahi

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 Linux y se instala por defecto en algunos. Si ejecuta conjuntamente con nss-mdns también ofrece sede de resolución de nombres.[24]

Avahi también implementa bibliotecas de compatibilidad binaria que emulan Bonjour y la implementación de mDNS histórico Howl, para usar las implementaciones de software 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 implementación de Microsoft de LLMNR.

Direcciones locales del vínculo IPv4

Hay algunos Dirección de enlace local IPv4 implementaciones disponibles:

  • Apple Mac OS y Windows MS han apoyado a direcciones locales del vínculo desde 1998. Apple lanzó su implementación open-source en el Darwin paquete de BOOTP.
  • Avahi contiene una implementación de IPv4LL en la herramienta avahi-autoipd.
  • Cero-Conf IP (zcip).[25]
  • BusyBox puede incrustar una implementación simple de IPv4LL.
  • Stablebox,[26] un tenedor de Busybox, ofrece una implementación de IPv4LL ligeramente modificada llamada llad.
  • Zeroconf,[27] un paquete basado en simples IPv4LL, una implementación más corta por Arthur van Hoff.[28]

Las implementaciones anteriores son demonios todo independientes o plugins para DHCP clientes que tienen que ver sólo con las direcciones locales de enlace IP. Otro enfoque es incluir el soporte en nuevos o existentes de los clientes DHCP:

  • Elvis Pfützenreuter ha escrito un parche para el cliente/servidor uDHCP.[29]
  • dhcpcd[30] es un opensource DHCP cliente para Linux y BSD Eso incluye soporte IPv4LL. Se incluye como estándar en NetBSD.

Ninguno de estos temas implementaciones direcciones del núcleo como difusión ARP respuestas[31] o cerrar las conexiones de red existentes.

Véase también

  • Servicio de Proxy de sueño, también conocido como Bonjour sueño Proxy[32]
  • Cero configuración inalámbrica

Referencias

Notas

  1. ^ RFC 4862, IETF
  2. ^ RFC 3927, IETF
  3. ^ "Apipa", MS Developer Network, Microsoft
  4. ^ "Cómo utilizar el direccionamiento automático TCP/IP sin un servidor DHCP", Base de conocimientos, Microsoft
  5. ^ a b c Marshall cerebro y Stephanie Crawford, "Cómo funcionan los servidores de nombre de dominio", howstuffworks
  6. ^ Manning, Multidifusión Domain Name Service (borrador), aguas termales
  7. ^ Re: Última llamada: 'Linklocal multidifusión resolución de nombres (LLMNR)' que propone estándar (mensaje de correo electrónico), IETF
  8. ^ Re: Resumen de la última llamada LLMNR (mensaje de correo electrónico), IETF
  9. ^ Resumen de la última llamada LLMNR (mensaje de correo electrónico), IETF
  10. ^ Más detalles sobre las diferencias (mensaje de correo electrónico), IETF
  11. ^ Cheshire, Stuart, Nombre vinculante Protocolo sobre IP (rant)
  12. ^ Cero conf
  13. ^ "Historia 6762 documento RFC". IETF.
  14. ^ "Historia 6763 documento RFC". IETF.
  15. ^ RFC 6763, IETF
  16. ^ Tipos de servicio, DNS-SD
  17. ^ DNS-SD
  18. ^ Cero configuración de redes (zeroconf) carta, IETF
  19. ^ Extensiones DNS (dnsext) carta, IETF
  20. ^ Protocolo de ubicación de servicio (svrloc) carta, IETF
  21. ^ Nombre (MDNS) ataques dentro de la LAN, envenenamiento (Registro de World Wide Web), ciudadano de GNU
  22. ^ Una cita con Java, Mac Dev Center, 2004-08-31
  23. ^ "Bonjour para MS Windows 1.0.4", Apoyo, Apple
  24. ^ Lennart, NSS-mdns 0.10, DE:: puntero 0
  25. ^ zcip, Fragua de la fuente
  26. ^ "Caja estable", Código, Google
  27. ^ Zeroconf, AU:: UTS
  28. ^ AVH IPv4LL (Código fuente C), cero conf
  29. ^ "Zeroconf en udhcpc", udhcpc (mensaje de correo electrónico), casilla ocupada, mayo de 2005
  30. ^ Eso, Roy, dhcpcd (wiki) (proyecto)
  31. ^ "Las mediciones de ARP link-Local", AIRE (wiki) NE:: UVA
  32. ^ "Mac OS X v10.6: sobre Wake on Demand (Apple artículo HT3774)". Apple. 2009-08-27. 2009-09-15. Configurar Wake on Demand","configurar un Proxy de sueño Bonjour

Fuentes

  • Guttman, Erik (2001), "configuración automática de redes IP: permitiendo la comunicación Local", IEEE Internet Computing 5 (3): 81-86, Doi:10.1109/4236.935181

Enlaces externos

  • JmDNS, Fragua de la fuente, una aplicación Java pura de mDNS/DNS-SD.
  • pyZeroConf, Fragua de la fuente, un puro Python implementación de mDNS/DNS-SD.
  • Mono.Zeroconf, Proyecto mono, una multiplataforma (Linux, MS Windows, Apple Mac), unificado biblioteca .NET/Mono para Zeroconf, apoyando tanto Bonjour y Avahi.
  • WxServDisc, Fragua de la fuente, un módulo de descubrimiento de servicio multiplataforma wxWidgets sin dependencias externas.
  • Cheshire, Stuart, Especificación (el proyecto), Multicast DNS.
  • ———, Especificación de descubrimiento de servicio basadas en DNS (el proyecto), DNS‐SD.
  • ———, Zeroconf (video) (tech talk), Google.
  • ———, Zeroconf, incluyendo borradores de Internet.
  • DNS-SD, DNS basado en el descubrimiento de servicio
  • Multicast DNS.
  • Johns, brezo (diciembre de 2002), Zeroconf comprensión y Multicast DNS (artículo), O'Reilly, un poco anticuado.
  • "Zeroconf Technologies", AIRE (wiki), NL: UVA.
  • Grupo de trabajo DNSEXT (carta), IETF, que coordina la normalización LLMNR.
  • RFC 2608, Protocolo de ubicación de servicio, versión 2
  • Steinberg, Daniel; Cheshire, Stuart, Cero configuración redes: La guía definitiva, O ' Reilly.

Otras Páginas

Obtenido de"https://en.copro.org/w/index.php?title=Zero-configuration_networking&oldid=644830536"