Zeroconf

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Protocolos Internet (TCP/IP)
Camada Protocolo
5.Aplicação HTTP, SMTP, FTP, SSH, Telnet, SIP, RDP, IRC, SNMP, NNTP, POP3, IMAP, BitTorrent, DNS, Ping ...
4.Transporte TCP, UDP, RTP, SCTP, DCCP ...
3.Rede IP (IPv4, IPv6) , ARP, RARP, ICMP, IPsec ...
2.Enlace Ethernet, 802.11 WiFi, IEEE 802.1Q, 802.11g, HDLC, Token ring, FDDI, PPP,Switch ,Frame relay,
1.Física Modem, RDIS, RS-232, EIA-422, RS-449, Bluetooth, USB, ...

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]

Serviço de Descobrimento[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]

  • 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[editar | editar código-fonte]

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