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