Zeroconf

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

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

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", 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, o que é considerado um problema por alguns membros do IETF. 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. O mDNS é compatível com o DNS-SD, como descrito na próxima seção, enquanto o LLMNR não será.

Descoberta de serviços

Protocolo da Apple: Multicast DNS/DNS-SD

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

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

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

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.

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. 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.

Principais implementações

Apple Bonjour

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 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.

Avahi

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.

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

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

Link-local IPv4 addresses

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.

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.

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

Referências

• Erik Guttman (2001). «Autoconfiguration for IP Networking: Enabling Local Communication». IEEE Internet Computing. 5 (3): 81–86. doi:10.1109/4236.935181 

Veja também

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

Ligações externas

• 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