Zeroconf – Wikipédia, a enciclopédia livre

Zeroconf, ou Zero Configuration Networking, é um conjunto de técnicas que criam de forma automática uma rede IP sem necessitar de configuração ou servidores.

Isto permite usuários inexperientes conectarem computadores, impressoras de rede e outros dispositivos e aguardar que o funcionamento da rede se estabeleça automaticamente. Sem o Zeroconf, um usuário precisaria configurar serviços especiais, tais como DHCP e DNS, ou configurar manualmente cada computador para acessar a rede.

Historicamente a primeira tentativa de implementação deste tipo de serviço foi realizada pela Apple com o AppleTalk, ainda nos anos 80. Com esta facilidade que já existia nos Macs, o usuário podia simplesmente ligar dois computadores numa rede que eles já estariam aptos a se comunicar.

Os principais requisitos propostos para a concepção do Zeroconf foram:

• Alocar endereços de rede sem um servidor DHCP (IPv4 Link-Local Addressing)
• Tradução entre nomes e endereços IP sem um servidor DNS (Multicast DNS)
• Localização de serviços, tipo impressoras, sem um servidor de diretório (DNS Service Discovery)
• Alocação de endereços de IP Multicast sem um MADCAP server (trabalhos futuros)
• A solução baseada nos quatro requisitos anteriores deve coexistir com as grandes redes configuradas, ou seja, não deve causar nenhum dano a uma rede quando uma máquina é conectada nesta.

O Zeroconf atualmente provê Link-local address, Multicast DNS e DNS Service Discovery.

Escolha dos endereços[editar | editar código-fonte]

Tanto o IPv4, como IPv6, tem padrões de auto configuração do endereço das interfaces de rede. Pelo RFC 3927, o IPv4 utiliza o 169.254.0.0/16 (link-local) conjunto de endereços. Para o IPv6, veja o RFC 4862.

A técnica para IPv4 é chamada IPv4 Link-Local address assignment (IPV4LL) no RFC 3927. Entretanto, a Microsoft se refere para este como Automatic Private IP Addressing (APIPA) ou Internet Protocol Automatic Configuration (IPAC).

Resolução de nomes[editar | editar código-fonte]

O paper que descreve como a resolução de nome deve ser concluída foi publicado por Bill Manning e Bill Woodcock em 2000 como "Multicast Domain Name Service",^[1] tornando público o trabalho feito pela Apple e Microsoft.

Existem dois modos muito similares de identificar qual item da rede tem um certo nome. O Multicast DNS (mDNS) da Apple é um em uso e é distribuído gratuitamente. O Link-local Multicast Name Resolution (LLMNR) da Microsoft é pouco usado, não está no padrão do IETF, mas foi publicado como informativo no RFC 4795.

Os dois protocolos tem diferenças menores em suas abordagens para a resolução de nomes. mDNS permite o dispositivo de rede escolher um nome do domínio no namespace ".local" e anunciá-lo usando um multicast IP address especial. Isto introduz semânticas especiais no namespace .local,^[2] o que é considerado um problema por alguns membros do IETF.^[3] O atual rascunho do LLMNR permite o dispositivo de rede escolher qualquer nome de domínio, o que é considerado um risco de segurança por alguns membros do IETF.^[4] O mDNS é compatível com o DNS-SD, como descrito na próxima seção, enquanto o LLMNR não será.^[5]

Descoberta de serviços[editar | editar código-fonte]

Protocolo da Apple: Multicast DNS/DNS-SD[editar | editar código-fonte]

O Multicast DNS (mDNS) é um protocolo que usa APIs similares ao do sistema de unicast DNS, mas a implementa de forma diferente. Cada computador na LAN armazena sua própria lista de DNS records (ex. A, MX, PTR, SRV, etc) e quanto um cliente mDNS quer saber o endereço IP de um PC dado o seu nome, o PC com o nome correspondente responde com seu endereço IP. O mDNS multicast address é 224.0.0.251.

O DNS based Service Discovery (DNS-SD) é a outra metade da solução da Apple, construído no topo do Domain Name System. É utilizado nos produtos da Apple, em várias impressoras de rede, produtos de terceiros e aplicações em vários sistemas operacionais. Em contraste com a tecnologia da Microsoft, SSDP, usa DNS, ao invés de HTTP. É utilizado DNS SRV (RFC 2782), TXT, e PTR records para advertir os Service Instance Names. Os hosts oferecem diferentes detalhes de publicação dos serviços disponíveis, tais como instância, tipo de serviço, nome do domínio e parâmetros opcionais de configuração. Tipos de serviço são fornecidos informalmente até se tornarem uma base. O registro de tipos de serviço é mantido e publicado pelo DNS-SD.org.

Muitos clientes de rede do Mac OS X, tais como o navegador Safari e o mensageiro instantâneo iChat, sua DNS-SD para localizar servidores próximos. No Windows, mensageiros instantâneos e clientes VoIP, com o Gizmo, suportam DNS-SD. Algumas distribuições Linux também incluem funcionalidades do DNS-SD.

O mDNS/DNS-SD foi desenvolvido na Apple Computer por Stuart Cheshire na mudança do AppleTalk para o IP.

Protocolo Microsoft: UPnP SSDP[editar | editar código-fonte]

O Simple Service Discovery Protocol (SSDP) é um protocolo UPnP, usado no Windows XP e em várias marcas de equipamentos de redes. O SSDP usa o anúncio da notificação HTTP que fornece o tipo de serviço URI e o Unique Service Name (USN). Os tipos de serviço são regulados pelo Universal Plug and Play Steering Committee.

Esforços em direção a um protocolo padrão IETF[editar | editar código-fonte]

Service Location Protocol (SLP), o único protocolo para serviço de descobrimento que alcançou o IETF Proposed Standard status, é suportado pelas impressoras de rede da Hewlett-Packard, Novell, Sun Microsystems, e Apple Inc, mas ignorado por alguns outros grandes vendedores. O SLP é descrito no RFC 2608 e RFC 3224 e implementações estão disponíveis tanto para Solaris, como Linux.

Padronização[editar | editar código-fonte]

RFC 3927, um padrão para escolha de endereços para itens de rede, foi publicado em Março de 2005 pelo Zeroconf IETF Working Group, que incluí indivíduos da Apple, Sun e Microsoft.^[6]

O LLMNR foi submetido para um adoção oficial no DNSEXT IETF Working Group, entretanto falhou ao ganhar o consenso e então foi publicado como um RFC informativo somente: RFC 4795.^[7] Na sequência do fracasso do LLMNR em se tornar um padrão da Internet, a Apple solicitou ao IETF para submeter a especificação do mDNS/DNS-SD para a publicação através de um RFC informativo também, dado que o mDNS/DNS-SD é muito mais largamente usado que o LLMNR.

RFC 2608, o padrão SLP para descobrir onde obter os serviços, foi publicado pelo SVRLOC IETF Working Group.^[8]

Principais implementações[editar | editar código-fonte]

Apple Bonjour[editar | editar código-fonte]

A mais largamente adotada solução Zeroconf é o Bonjour (ex-Rendezvous) da Apple Inc., que utiliza multicast DNS e DNS Service Discovery. A Apple trocou sua tecnologia preferida do Zeroconf do SLP para mDNS e DNS-SD entre o Mac OS X 10.1 e o 10.2, contudo o SLP continua a ser suportado pelo Mac OS X.

O mDNSResponder da Apple tem interfaces para C e Java^[9] e é disponibilizado para BSD, Mac OS X, Linux, outros sistemas operacionais baseados no POSIX e Windows. O download para Windows está disponível no website da Apple.^[10]

Avahi[editar | editar código-fonte]

O Avahi é a implementação do Zeroconf para o Linux e BSDs. Implementa IPv4LL, mDNS e DNS-SD. É parte da maioria das distribuições Linux, e está instalado por padrão em algumas. Se executado em conjunto com nss-mdns, ele também oferece a resolução dos nomes dos hosts.^[11]

O Avahi também implementa a compatibilidade binária das bibliotecas que emulam o Bonjour e a histórica implementação Howl do mDNS, de forma que os software que foram feitos utilizando estas implementações podem utilizar o Avahi através de interfaces emuladas.

Windows CE 5.0[editar | editar código-fonte]

Windows CE 5.0 inclui uma implementação própria da Microsoft do LLMNR.

Link-local IPv4 addresses[editar | editar código-fonte]

Existem algumas implementações disponíveis:

• Windows e Mac OS suportam o link-local addresses desde 1998. A Apple disponibilizou sua implementação de código aberto no pacote Darwin bootp.
• Avahi contém a implementação do IPv4LL na ferramenta avahi-autoipd.
• zcip (Zero-Conf IP)
• BusyBox pode embutir uma simples implementação do IPv4LL
• Stablebox, um fork do Busybox, oferece uma ligeiramente modificada implementação do IPv4LL chamada llad.
• zeroconf, um pacote baseado no Simple IPv4LL, um implementação feita por Arthur van Hoff.^[12]

As implementações acima são todas stand-alone daemons ou plugins para clientes DHCP que somente lidam com link-local IP addresses. Outras abordagens são para modificar clientes DHCP que já existem.

• Elvis Pfützenreuter escreveu um patch para o cliente/servidor uDHCP.^[13]

Nenhuma destas implementações de núcleo aborda questões como a difusão das respostas ARP replies^[14] ou de encerramento das atuais ligações à rede.

Referências[editar | editar código-fonte]

Veja também[editar | editar código-fonte]

• Universal Plug and Play
• Wireless
• Avahi (software)

Ligações externas[editar | editar código-fonte]

• JmDNS, uma implementação pura em Java do mDNS/DNS-SD
• pyZeroConf, uma pura implementação em Python do mDNS/DNS-SD
• Mono.Zeroconf, uma multiplataforma (Linux, Windows, Mac), Mono/.NET API para Zeroconf, suportando Bonjour e Avahi
• Especificação do Multicast DNS
• Especificação do DNS-Based Service Discovery
• Zeroconf.org - Página do Stuart Cheshire.
• dns-sd.org DNS based Service Discovery
• multicastdns.org Multicast DNS
• "Understanding Zeroconf and Multicast DNS", artigo de Dezembro de 2002, ligeiramente desatualizado, na O'Reilly Network.
• AIR Wiki : ZeroconfTechnologies
• Charter of the DNSEXT working group, os quais coordenaram a padronização do LLMNR
• Explanation of .local addresses, o qual foi usado com o mDNS, mas não é ainda padronizado pela IANA
• RFC 2608, Service Location Protocol, Version 2
• Zero Configuration Networking: The Definitive Guide, por Daniel Steinberg e Stuart Cheshire, O'Reilly