(Translated by https://www.hiragana.jp/)
Zeroconf: diferenças entre revisões – Wikipédia, a enciclopédia livre Saltar para o conteúdo

Zeroconf: diferenças entre revisões

Origem: Wikipédia, a enciclopédia livre.
Explorar interativamente o histórico
← Ver a alteração anterior
Conteúdo apagado Conteúdo adicionado
VisualTexto wiki
Davemustaine (discussão | contribs)
25 518 edições
m
Alch Bot (discussão | contribs)
Robôs
440 564 edições
m Robô: Alteração da categoria redirecionada Protocolos Internet para Protocolos da Internet
 
(Há 23 revisões intermédias de 23 utilizadores que não estão a ser apresentadas)
Linha 7: Linha 7:
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.
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 requerimentos propostos para a concepção do Zeroconf foram:
Os principais requisitos propostos para a concepção do Zeroconf foram:
* Alocar endereços de rede sem um servidor [[DHCP]] (IPv4 Link-Local Addressing)
* 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)
* 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)
* 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)
* Alocação de endereços de IP Multicast sem um MADCAP server (trabalhos futuros)
* A solução baseada nos quatro requerimentos anteriores devem coexistir com as grandes redes configuradas, ou seja, não devem causar nenhum dano a uma rede quando uma máquina é conectada nesta.
* 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''.
O Zeroconf atualmente provê ''Link-local address'', ''Multicast DNS'' e ''DNS Service Discovery''.


== Escolha dos endereços ==
== 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.
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 [http://msdn.microsoft.com/en-us/library/aa505918.aspx ''Automatic Private IP Addressing'' (APIPA)] ou ''Internet Protocol Automatic Configuration'' (IPAC).
A técnica para IPv4 é chamada ''IPv4 Link-Local address assignment'' (IPV4LL) no RFC 3927. Entretanto, a [[Microsoft]] se refere para este como [https://web.archive.org/web/20170318001826/https://msdn.microsoft.com/en-us/library/aa505918.aspx ''Automatic Private IP Addressing'' (APIPA)] ou ''Internet Protocol Automatic Configuration'' (IPAC).


== Resolução de nomes ==
== 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"<ref>http://www.watersprings.org/pub/id/draft-manning-dnsext-mdns-00.txt</ref>, tornando público o trabalho feito pela [[Apple, Inc.|Apple]] e Microsoft.
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",<ref>http://tools.ietf.org/html/draft-manning-dnsext-mdns</ref> tornando público o trabalho feito pela [[Apple, Inc.|Apple]] e Microsoft.


Existe dois modos muito similares de identificar qual item da rede tem um certo nome. O [[Multicast]] [[Domain name system|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.
Existem dois modos muito similares de identificar qual item da rede tem um certo nome. O [[Multicast]] [[Domain Name System|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 anunciar ele usando um multicast IP address especial. Isto introduz semânticas especiais no ''namespace'' .local,<ref>[http://www1.ietf.org/mail-archive/web/ietf/current/msg37126.html Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard<!-- Bot generated title -->]</ref> o que é considerado um problema por alguns membros do IETF.<ref>[http://www1.ietf.org/mail-archive/web/ietf/current/msg37773.html Re: Summary of the LLMNR Last Call<!-- Bot generated title -->]</ref> 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.<ref>[http://www1.ietf.org/mail-archive/web/ietf/current/msg37740.html Summary of the LLMNR Last Call<!-- Bot generated title -->]</ref> O mDNS é compatível com o DNS-SD, como descrito na próxima seção, enquanto o LLMNR não será.<ref>[http://www.mhonarc.org/archive/html/ietf/2005-08/msg00494.html Mais detalhes sobre as diferenças]</ref>
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,<ref>{{Citar web |url=http://www1.ietf.org/mail-archive/web/ietf/current/msg37126.html |titulo=Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard<!-- Bot generated title --> |acessodata=2008-07-24 |arquivourl=https://web.archive.org/web/20081207202354/http://www.ietf.org/mail-archive/web/ietf/current/msg37126.html |arquivodata=2008-12-07 |urlmorta=yes }}</ref> o que é considerado um problema por alguns membros do IETF.<ref>{{Citar web |url=http://www1.ietf.org/mail-archive/web/ietf/current/msg37773.html |titulo=Re: Summary of the LLMNR Last Call<!-- Bot generated title --> |acessodata=2008-07-24 |arquivourl=https://web.archive.org/web/20081207202402/http://www.ietf.org/mail-archive/web/ietf/current/msg37773.html |arquivodata=2008-12-07 |urlmorta=yes }}</ref> 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.<ref>{{Citar web |url=http://www1.ietf.org/mail-archive/web/ietf/current/msg37740.html |titulo=Summary of the LLMNR Last Call<!-- Bot generated title --> |acessodata=2008-07-24 |arquivourl=https://web.archive.org/web/20081207202357/http://www.ietf.org/mail-archive/web/ietf/current/msg37740.html |arquivodata=2008-12-07 |urlmorta=yes }}</ref> O mDNS é compatível com o DNS-SD, como descrito na próxima seção, enquanto o LLMNR não será.<ref>[http://www.mhonarc.org/archive/html/ietf/2005-08/msg00494.html Mais detalhes sobre as diferenças]</ref>


== Serviço de Descobrimento ==
== Descoberta de serviços ==
=== Protocolo da Apple: Multicast DNS/DNS-SD ===
=== 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. [[Domain Name System#Types_of_DNS_records|A]], [[MX record|MX]], [[Domain Name System#Types_of_DNS_records|PTR]], [[SRV record|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 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. [[Domain Name System#Types of DNS records|A]], [[MX record|MX]], [[Domain Name System#Types of DNS records|PTR]], [[SRV record|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 [[Domain Name System|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 [http://www.dns-sd.org/ServiceTypes.html registro de tipos de serviço] é mantido e publicado pelo [http://www.dns-sd.org DNS-SD.org].
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 [[Domain Name System|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 [http://www.dns-sd.org/ServiceTypes.html registro de tipos de serviço] é mantido e publicado pelo [http://www.dns-sd.org DNS-SD.org].
Linha 47: Linha 47:
=== Esforços em direção a um protocolo padrão IETF ===
=== 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 [[Internet standard#Proposed standard|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 Operating System|Solaris]], como [[Linux]].
[[Service Location Protocol]] (SLP), o único protocolo para serviço de descobrimento que alcançou o [[Internet standard#Proposed standard|IETF Proposed Standard]] status, é suportado pelas impressoras de rede da [[Hewlett-Packard]], [[Novell (empresa)|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 Operating System|Solaris]], como [[Linux]].


== Padronização ==
== 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.<ref>[http://www.ietf.org/html.charters/OLD/zeroconf-charter.html Zero Configuration Networking (zeroconf) Charter<!-- Bot generated title -->]</ref>
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.<ref>{{Citar web |url=http://www.ietf.org/html.charters/OLD/zeroconf-charter.html |titulo=Zero Configuration Networking (zeroconf) Charter<!-- Bot generated title --> |acessodata=2008-07-24 |arquivourl=https://web.archive.org/web/20041101173627/http://www.ietf.org/html.charters/OLD/zeroconf-charter.html |arquivodata=2004-11-01 |urlmorta=sim }}</ref>


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.<ref>[http://www.ietf.org/html.charters/dnsext-charter.html DNS Extensions (dnsext) Charter<!-- Bot generated title -->]</ref> 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.
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.<ref>{{Citar web |url=http://www.ietf.org/html.charters/dnsext-charter.html |titulo=DNS Extensions (dnsext) Charter<!-- Bot generated title --> |acessodata=2008-07-24 |arquivourl=https://web.archive.org/web/20031008105543/http://www.ietf.org/html.charters/dnsext-charter.html |arquivodata=2003-10-08 |urlmorta=yes }}</ref> 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.<ref>[http://www.ietf.org/html.charters/OLD/svrloc-charter.html Service Location Protocol (svrloc) Charter<!-- Bot generated title -->]</ref>
RFC 2608, o padrão SLP para descobrir onde obter os serviços, foi publicado pelo SVRLOC IETF Working Group.<ref>{{Citar web |url=http://www.ietf.org/html.charters/OLD/svrloc-charter.html |titulo=Service Location Protocol (svrloc) Charter<!-- Bot generated title --> |acessodata=2008-07-24 |arquivourl=https://web.archive.org/web/20060405124046/http://www.ietf.org/html.charters/OLD/svrloc-charter.html |arquivodata=2006-04-05 |urlmorta=sim }}</ref>


== Principais implementações ==
== Principais implementações ==
Linha 72: Linha 72:
=== Windows CE 5.0 ===
=== Windows CE 5.0 ===


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


=== Link-local IPv4 addresses ===
=== Link-local IPv4 addresses ===


Existe algumas implementações disponíveis:
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 (operating system)|Darwin]] bootp.
* Windows e Mac OS suportam o link-local addresses desde 1998. A Apple disponibilizou sua implementação de código aberto no pacote [[Darwin (operating system)|Darwin]] bootp.
Linha 83: Linha 83:
* [[BusyBox]] pode embutir uma simples implementação do IPv4LL
* [[BusyBox]] pode embutir uma simples implementação do IPv4LL
* [http://code.google.com/p/stablebox/ Stablebox], um fork do Busybox, oferece uma ligeiramente modificada implementação do IPv4LL chamada llad.
* [http://code.google.com/p/stablebox/ Stablebox], um fork do Busybox, oferece uma ligeiramente modificada implementação do IPv4LL chamada llad.
* [http://www.progsoc.uts.edu.au/~wildfire/zeroconf/ zeroconf], um pacote baseado no Simple IPv4LL, um implementação feita por Arthur van Hoff.<ref>http://www.zeroconf.org/AVH-IPv4LL.c</ref>
* [https://web.archive.org/web/20050509093846/http://www.progsoc.uts.edu.au/~wildfire/zeroconf/ zeroconf], um pacote baseado no Simple IPv4LL, um implementação feita por Arthur van Hoff.<ref>http://www.zeroconf.org/AVH-IPv4LL.c</ref>


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.
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.<ref>[http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html [udhcp&#93; Fwd: Zeroconf in udhcpc<!-- Bot generated title -->]</ref>
* Elvis Pfützenreuter escreveu um patch para o cliente/servidor uDHCP.<ref>[http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html {{Wayback|url=http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html |date=20060206072249 }} [udhcp&#93; Fwd: Zeroconf in udhcpc<!-- Bot generated title -->]</ref>


Nenhuma destas implementações de kernel aborda questões como a difusão das respostas [[Address Resolution Protocol|ARP]] replies<ref>[http://www.science.uva.nl/research/air/wiki/LinkLocalARPMeasurements AIR Wiki: Link-Local ARP Measurements<!-- Bot generated title -->]</ref> ou de encerramento das atuais ligações à rede.
Nenhuma destas implementações de núcleo aborda questões como a difusão das respostas [[Address Resolution Protocol|ARP]] replies<ref>[http://www.science.uva.nl/research/air/wiki/LinkLocalARPMeasurements AIR Wiki: Link-Local ARP Measurements<!-- Bot generated title -->]</ref> ou de encerramento das atuais ligações à rede.


== Referências ==
== Referências ==


<div class="references-small">
<div class="references-small">
* {{cite journal | author=Erik Guttman | title=Autoconfiguration for IP Networking: Enabling Local Communication | journal=IEEE Internet Computing | volume=5 | issue=3 | pages=81–86 | year=2001 | doi=10.1109/4236.935181 }}
* {{citar periódico|autor =Erik Guttman |título=Autoconfiguration for IP Networking: Enabling Local Communication |periódico=IEEE Internet Computing | volume=5 |número=3 |páginas=81–86 |ano=2001 | doi=10.1109/4236.935181 }}
</div>
</div>
{{reflist}}
{{reflist}}
Linha 104: Linha 104:
* [[Avahi (software)]]
* [[Avahi (software)]]


=={{Ligações externas}}==
==Ligações externas==


* [http://jmdns.sourceforge.net/ JmDNS], uma implementação pura em Java do mDNS/DNS-SD
* [http://jmdns.sourceforge.net/ JmDNS], uma implementação pura em Java do mDNS/DNS-SD
* [http://sourceforge.net/projects/pyzeroconf/ pyZeroConf], uma pura implementação em [[Python (programming language)|Python]] do mDNS/DNS-SD
* [http://sourceforge.net/projects/pyzeroconf/ pyZeroConf], uma pura implementação em [[Python]] do mDNS/DNS-SD
* [http://mono-project.com/Mono.Zeroconf Mono.Zeroconf], uma multiplataforma (Linux, Windows, Mac), Mono/.NET API para Zeroconf, suportando Bonjour e Avahi
* [http://mono-project.com/Mono.Zeroconf Mono.Zeroconf], uma multiplataforma (Linux, Windows, Mac), Mono/.NET API para Zeroconf, suportando Bonjour e Avahi
* [http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt Especificação do Multicast DNS]
* [http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns Especificação do Multicast DNS]
* [http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt Especificação do DNS-Based Service Discovery]
* [http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd-06 Especificação do DNS-Based Service Discovery]
* [http://www.zeroconf.org/ Zeroconf.org] - Página do Stuart Cheshire.
* [http://www.zeroconf.org/ Zeroconf.org] - Página do Stuart Cheshire.
* [http://dns-sd.org/ dns-sd.org] DNS based Service Discovery
* [http://dns-sd.org/ dns-sd.org] DNS based Service Discovery
Linha 116: Linha 116:
* [http://www.oreillynet.com/pub/a/wireless/2002/12/20/zeroconf.html "Understanding Zeroconf and Multicast DNS"], artigo de Dezembro de 2002, ligeiramente desatualizado, na O'Reilly Network.
* [http://www.oreillynet.com/pub/a/wireless/2002/12/20/zeroconf.html "Understanding Zeroconf and Multicast DNS"], artigo de Dezembro de 2002, ligeiramente desatualizado, na O'Reilly Network.
* [http://www.science.uva.nl/research/air/wiki/ZeroconfTechnologies AIR Wiki : ZeroconfTechnologies]
* [http://www.science.uva.nl/research/air/wiki/ZeroconfTechnologies AIR Wiki : ZeroconfTechnologies]
* [http://ietf.org/html.charters/dnsext-charter.html Charter of the DNSEXT working group], os quais coordenaram a padronização do LLMNR
* [https://web.archive.org/web/20050307044356/http://www.ietf.org/html.charters/dnsext-charter.html Charter of the DNSEXT working group], os quais coordenaram a padronização do LLMNR
* [http://www.dotlocal.org/ Explanation of .local addresses], o qual foi usado com o mDNS, mas não é ainda padronizado pela [[Internet Assigned Numbers Authority|IANA]]
* [https://web.archive.org/web/20070105225245/http://dotlocal.org/ Explanation of .local addresses], o qual foi usado com o mDNS, mas não é ainda padronizado pela [[Internet Assigned Numbers Authority|IANA]]
* RFC 2608, Service Location Protocol, Version 2
* RFC 2608, Service Location Protocol, Version 2
* [http://www.oreilly.com/catalog/bonjour/index.html Zero Configuration Networking: The Definitive Guide], por Daniel Steinberg e Stuart Cheshire, O'Reilly
* [http://www.oreilly.com/catalog/bonjour/index.html Zero Configuration Networking: The Definitive Guide], por Daniel Steinberg e Stuart Cheshire, O'Reilly


[[Category:Apple Inc.]]
[[Categoria:Apple]]
[[Categoria:Protocolos da Internet]]
[[Category:Windows communication and services]]
[[Categoria:DNS]]
[[Category:Network protocols]]
[[Category:Domain name system]]
[[Category:Configuration]]

[[de:Zeroconf]]
[[es:Zeroconf]]
[[fr:Zeroconf]]
[[id:Zeroconf]]
[[it:Zeroconf]]
[[nl:Zeroconf]]
[[ja:APIPA]]
[[pl:Automatic Private IP Addressing]]
[[en:Zeroconf]]
[[ru:Zeroconf]]
[[fi:Zeroconf]]
[[tr:Zeroconf]]

Edição atual tal como às 05h01min de 27 de agosto de 2023

Pilha de protocolos TCP/IP
Camada de aplicação
Camada de transporte
Camada de rede
Camada de enlace de dados

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.

[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 
  1. ↑ http://tools.ietf.org/html/draft-manning-dnsext-mdns
  2. ↑ «Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard». Consultado em 24 de julho de 2008. Arquivado do original em 7 de dezembro de 2008 
  3. ↑ «Re: Summary of the LLMNR Last Call». Consultado em 24 de julho de 2008. Arquivado do original em 7 de dezembro de 2008 
  4. ↑ «Summary of the LLMNR Last Call». Consultado em 24 de julho de 2008. Arquivado do original em 7 de dezembro de 2008 
  5. ↑ Mais detalhes sobre as diferenças
  6. ↑ «Zero Configuration Networking (zeroconf) Charter». Consultado em 24 de julho de 2008. Arquivado do original em 1 de novembro de 2004 
  7. ↑ «DNS Extensions (dnsext) Charter». Consultado em 24 de julho de 2008. Arquivado do original em 8 de outubro de 2003 
  8. ↑ «Service Location Protocol (svrloc) Charter». Consultado em 24 de julho de 2008. Arquivado do original em 5 de abril de 2006 
  9. ↑ MacDevCenter.com - A Rendezvous with Java
  10. ↑ Apple - Support - Downloads - Bonjour for Windows 1.0.4
  11. ↑ nss-mdns 0.10
  12. ↑ http://www.zeroconf.org/AVH-IPv4LL.c
  13. ↑ [https://web.archive.org/web/20060206072249/http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html Arquivado em 6 de fevereiro de 2006, no Wayback Machine. [udhcp] Fwd: Zeroconf in udhcpc]
  14. ↑ AIR Wiki: Link-Local ARP Measurements

Veja também

[editar | editar código-fonte]

Ligações externas

[editar | editar código-fonte]
Obtida de "https://pt.wikipedia.org/w/index.php?title=Zeroconf&oldid=66489636"