DEFINIÇÃO PROTOCOLO LLMNR (LINK LOCAL MULTICAST NAME RESOLUTION) E DIFERENÇAS EM RELAÇÃO AO PROTOCOLO NETBIOS



RESUMO

O próposito do artigo revela-se na definição e comparação dos protocolos de resolução de nomes Netbios e LLMNR (Link-Local Multicast Name Resolution) em ambientes de redes em que não seja possível a implantação de um servidor de domímio.
Procura-se também definir as principais característas entre os dois processos de resolução de nomes em ambientes de redes na plataforma Windows, dentre suas vantagens e desvantagens.


Palavras-chave: Netbios: LLMNR. Resolução. Windows. Redes. Comparação.


ABSTRACT

The purpose of the article appears to be the definition and comparison of protocols for Netbios name resolution and LLMNR (Link-Local Multicast Name Resolution) in network environments where it is not possible to implement a server domímio.
Search also define the main character between the two processes name resolution on network environments on the Windows platform, among its advantages and disadvantages.

Keywords: Netbios: LLMNR. resolution. Windows.Network. Comparaison.



SUMÁRIO

RESUMO........................................................................................................................
ABSTRACT....................................................................................................................
1. INTRODUÇÃO 6
2. RESOLUÇÕES DE NOMES 8
3. NETBIOS 11
3.1 REGISTRO 13
3.2 RESOLUÇÃO 13
4. PROTOLOCO LINK LOCAL MULTICAST NAME RESOLUTION ? LLMNR 15
4.1 RESOLUÇÃO DE NOMES USANDO LLMNR 16
4.2 VERIFICAÇÃO UNICAST 16
4.3 LLMNR COMO PROTOCOLO DE RESOLUÇÃO DE NOME SEGURO 17
4.4 USO DO LLMNR EM REDES MICROSOFT E HABILITAÇÃO 17
5. DIFERENÇA DE USO ENTRE O PROTOCOLO NETBIOS E O PROTOCOLO LLMNR 19
6. CONSIDERAÇÕES FINAIS 20
REFERÊNCIAS..............................................................................................................






1. INTRODUÇÃO

A rede mundial de computadores, a internet, é caracterizada por identificadores que representam cada host . A esse identificador dá-se o nome de IP (Protocol Internet). A primeira versão do protocolo IP, Ipv4, é composto de trinta e dois bits divididos em quatro octetos. Cada octeto oferta duzentos e cinquenta e cinco endereço totalizando aproximadamente quarenta e três bilhões de endereços únicos possíveis.
Devido ao crescimento exponencial da internet sabe-se que oferta de números de endereço da versão Ipv4 irá se esgotar. Para resolver esse problema uma das soluções adotadas foi criar o serviço NAT (Network Address Translation), cuja solução permite que várias empresas utilizem a faixa de endereços privados (endereço reservados para atribuição interna), como esquema de endereço de sua rede local.
A solução definitiva, até o momento, veio com o lançamento da segunda versão do protocolo de endereço IP, o Ipv6. Ao contrário do Ipv4 o Ipv6 constituído de cento e vinte e oito bits divididos em oito blocos de dezesseis bits, o que segundo Kaplan e Rhodes são aproximadamente 6.67 * 10^27 endereços Ipv6 por metro quadrado em nosso planeta, o que "espera-se" que seja a solução definitiva para o esgotamento de endereços IP?s.
Além do aumento de ofertas de endereços IP?s o Ipv6 traz muitos atributos úteis: auto-configuração de endereço, endereços anycast , endereços multicast obrigatórios, IPsec, estrutura simplificada de cabeçalho, entre outros.
Uma das características acima que deve-se destacar é o uso obrigatório de endereços multicast. Desse novo atributo surge a necessidade de protocolos de resolução de nomes multicast em ambientes de redes corporativos em que não tenha sido implementado servidores DNS (Domain Name Services) e que se deseja usar processos de resolução de nomes de forma a não gerar muito tráfego na rede.

O protocolo de resolução de nomes mais usado em ambientes, que não dispõem de DNS é o protocolo NetBIOS. Esse protocolo se comunica com os computadores de redes por meio do processo de difusão, ou seja, quando um host solicita um acesso a um recurso na rede o pedido é enviado para todas as máquinas que se encontram na mesma sub-rede.
Para Mackin e Northrup (2009, p. 122) o tráfego em uma rede NetBios é "ruidoso" e, devido às informações que transmitem não é particularmente segura.
Ainda, conforme Mackin e Northrup (2009, p.122), o Netbios é habilitado por padrão nas redes microsoft. Essa ativação surgiu da necessidade de os usuários usarem, convencionalmente, o nome de convenção universal (nome simples configurado para um recurso, exemplo, computador01) para ter acesso a outros recurso na rede.
No entanto, o Netbios segundo especificação do protocolo publicado na biblioteca Technet (2005), não suporta a versão mais recente do protocolo IP, o Ipv6.
Nesse sentido, as empresas em que mantém seus ativos de redes com tecnologia Microsoft e que esta passando a usar o IPv6, busca-se por serviços ou protocolos que suportem esse novo esquema de endereçamento e, que minimizem o tráfego na rede e garanta a segurança dos dados do início ao final da transmissão dos pacotes, em ambientes onde não há implementação de domínios.
Assim e diante das novas necessidades por protocolos que otimizem o tráfego da rede, que forneçam resolução de nomes simples e eficaz em ambientes corporativos onde ainda não tenha sido implementado servidores DNS (Service Name Domain), busca-se demonstrar as vantagens e uso do protocolo LLMNR (Link Local Multicast Name Resolution) em ambientes de redes Microsoft Ipv6 como também: conhecer o processo de resolução de nomes, a definição do protocolo Netbios e sua funcionalidade, a definição do protocolo LLMNR e sua funcionalidade e a uma comparaçao entre ambos no que se refere a vantagens e desvantagens em ambientes de redes microsoft.



2. RESOLUÇÕES DE NOMES

Na perspectiva de Comer (1998, p. 423) os primeiros sistemas de computadores forçavam os usuários a entender endereços numéricos para acessarem os recursos disponíveis na rede.
Para o acesso de recursos na rede cada interface de rede conectada ao computador precisa de um endereço físico único. O IEEE define o formato e a atribuição de endereços LAN (Network Area Local ? Rede Local) físicos para cada interface de rede. O IEEE requer endereços MAC (Media Access Control ? Controle de Acesso a Mídia) "unicast", globalmente únicos, em todas as placas de interface. Para garantir um endereço MAC único, os fabricantes das placas codificam o endereço físico na placa, geralmente em um chip de ROM (Memory Only Read ? Memória de Somente Leitura). A primeira metade do endereço identifica o fabricante da placa e a segunda metade o fabricante determina um número que jamais usou. Odom (2008, p.47).
Ainda, segundo Gouveia (2007, p 66) o que normalmente acontece é que os computadores, ao se comunicarem entre si, enviam sempre o endereço MAC para a rede e só depois o número IP (Internet Protocolo).
O IP estabelece um endereçamento lógico, possibilitando que qualquer destino seja identificado, facilitando sua busca. Furukawa(p 51).
Para facilitar o entendimento, o endereço IP está associado ao MAC de cada host (dispositivo de rede), da mesma forma um nome de computador, ou de qualquer recurso acessível na rede está associado a um endereço IP.
Para a associação do endereço MAC, que é de 48 bits, com o endereço IP de 32 bits foi definido um protocolo que mapeia de forma dinâmica o MAC ao IP, esse protocolo é o ARP (Address Resolution Protocol ? Protocolo Resolução de Endereços).
Comer (1996, p. 82) nos fornece uma idéia por trás da conversão dinâmica com o ARP: quando um host "A" quer descobrir o endereço IP, ele transmite por difusão um pacote especial que pede ao host destinatário que responda com seu endereço físico. Todos os hosts, inclusive o destinatário, recebem a solicitação, mas somente o host destino reconhece o pacote.
Para reduzir custos com comunicações, os computadores que usam ARP mantêm um cache com mapeamento entre endereços físicos e IP?s , recentemente adquirido, e assim não precisam freqüentemente usar ARP. Sempre que um computador recebe uma resposta ARP, ele guarda em seu cache o endereço IP do transmissor e seu endereço de hardware correspondente para pesquisas sucessivas. Comer (1998, p. 83)
No entanto, conforme Odom (2008, 88), os projetistas de redes precisam tentar fazer com que o uso da rede seja o mais simples possível, pois os usuários vão querer no máximo, se lembrar do nome de outro computador com o qual desejam se comunicar, pois eles não vão querer se lembrar de endereços IP?s).
Um nome de computador é um nome amigável que é atribuído ao endereço do computador para identificá-lo como um host TCP/IP .
Assim, a resolução de nomes é o processo de obtenção do endereço IP associado ao nome do computador, Microsoft (2003, p 4).
Em ambiente de rede Microsoft o nome do host pode ter até 255 caracteres e pode conter caracteres alfanuméricos, hífens e pontos. As duas formas mais comuns de nomes de hosts segundo Microsoft (2005) são: alias e nomes de domínio.
"Alias", apelido, é um único nome associado a um endereço IP. Já um nome de domínio é estruturado para ser usado na Internet e contém pontos e separadores.
No primeiro caso e em redes microsoft, alias, o principal protocolo de resolução de nomes usado é NetBios¸
No segundo, o protocolo usado em grande escala é o DNS , que na visão de Sousa (2009, p. 136) é o sistema de tradução de domínios (www) para os seus respectivos endereços IP que trafegam na rede; os endereços IP ficam em tabelas em banco de dados nos servidores DNS. O DNS gerencia e traduz nomes dos domínios edu,.net;.gov;.mil.
A definição de mecanismos de resolução de nomes é requerido, pois para os usuários de computadores é mais fácil lembrar de nomes que de números. Logo, torna-se mais cômodo acessar os recursos pelo nome do que digitar um amontoado de números difíceis de memorizar.

3. NETBIOS

Segundo o RFC 1001 ? Request for Comments (1987) o Netbios ou NetBEUI foi criado pela IBM para ser usado por grupo de computadores que estão no mesmo domínio de broadcast . A aplicação Netbios possui mecanismo de localização de recursos, estabelecimento de conexão, envio e recebimento de dados, finalização da conexão e em relação ao modelo conceitual OSI o Netbios está incluso na camada de transportes e sessão.
Carvalho (1998, p 118) define que o Netbios não é um protocolo, mas sim uma interface de programação que fornece às aplicações de redes um serviço de transmissão confiável orientado a conexão (garantia de entrega de pacotes), um serviço de nomes para identificar seus usuários na rede, e opcionalmente um serviço de transmissão de datagramas não-confiável.
No domínio de Morimoto (2003, p 72) o mesmo foi concebido como padrão para ser usado para pequenas redes no processo de mapeamento de nomes onde não seja possível a implantação de serviços de redes de domínio.
Já de acordo com publicação da Microsoft (2003, p14) o NetBios atua para interconetar aplicativos nas camadas Sessão e Transportes do TCP/IP e fornece serviço de mensagens e de alocação de recursos.
Ainda, conforme publicação acima, o NetBios define nomes lógicos sobre a rede, estabelece sessões entre dois nomes lógicos na rede e dá suporte a transferência confiável de dados entre computadores com uma sessão estabelecida.
Do ponto de vista da arquitetura a Microsoft (2003, p. 14) define a especificação NetBios em duas partes.
Primeiramente como um mecanismo de comunicação inter-processos IPC (Interprocess Communictation) e uma interface de programação API (Apllicatiion Programming Interface) que permite que os aplicativos compatíveis com NetBios comuniquem-se remotamente através de uma rede e solicitem serviços das camadas mais inferiores da pilha de protocolos TCP/IP.
Em segundo, define como um protocolo localizado nas camadas de sessão e transporte do modelo de referência OSI (Interconexão de Sistemas Abertos) que disponibiliza funções como o estabelecimento e a conclusão de sessões bem como registro, recuperação e resolução de nomes.
O tráfego de pacotes Netbios inclui as seguintes portas: o tráfego de sessão na porta TCP 139, tráfego de gerenciamento de nomes na porta UDP 137 e o tráfego de datagramas na porta UDP 138 conforme Davies (2005).
Com relação as principais vantagens do protocolo Netbios o RFC 1001 (1987) cita, que não precisa de gerenciamento centralizado, permite operações com a internet e minimiza o número de difusão ativo.
No primeiro aspecto, gerenciamento centralizado, por se tratar de um padrão usado pelas redes Micrososft o Netbios já esta implementado e não requer nenhum esforço técnico para seu funcionamento.
Em se tratando de permitir operações pela internet o processo só deve funcionar com a presença de um "gateway" .
O Netbios pressupõe que serviços de difusão são suportados somente por protocolos UDP e por isso a justificativa do uso da difusão em consideração ao uso protocolo UDP que Kurose (2005, p 146) define como um serviço que provê a aplicação solicitante um serviço não confiável, não orientado para conexão (não precisa estabelecer, gerenciar e fechar conexões, tendo apenas que transmitir dados), ou seja, como não será preciso à confirmação de envio e recebimento de pacotes na rede o tráfego é reduzido.
Para o envio e recebimento dos dados o Netbios define um nome para cada recurso na rede e para o RFC 1001 (1987) possui vários atributos, entre um espaço de nome.
O espaço de nome permite somente dezesseis caracteres alfanuméricos, sendo o último caractere usado para identificar o recurso ou serviço a que se está referindo o computador. Não deve iniciar com asterisco. Pode representar um só computador ou um grupo de computadores (a existência de nomes duplicados na rede impossibilita a comunicação com o recurso).
Um exemplo de um recurso NetBios é o componente Compartilhamento de arquivos e impressora para redes Microsoft, em um computador que pertence a família Windows. Quando o computador é iniciado, esse componente registra um nome NetBios único, baseado no nome do seu computador e no caractere identificador que representa o componente, Microsoft (2005, p 15).


3.1 Registro

Ao usuário ligar a máquina na rede o computador envia uma solicitação de registro por meio do serviço de solicitação de registro de mensagens. A solicitação pode ser feita por meio de uma difusão, nesse caso a difusão é usada a fim de verificar se existe outro recurso na rede com o mesmo nome (Davies, 2005).
Caso existe algum outro recurso usando o nome, o host de posse do nome envia uma resposta negativa ao computador do usuário solicitante, em seguida o computador do usuário exibe uma mensagem de erro.
A segunda hipótese, o nome solicitado não está sendo usado na rede exige que o computador do usuário envie um pedido unicast (único) para o servidor de nomes Netbios realizarem o registro do recurso.

3.2 Resolução

Para Davies (2005) Quando uma aplicação Netbios que se comunicar com outro host TCP/IP, aplicação envia uma mensagem de consulta de nomes na rede local ou envia um pedido unicast ao servidor de nomes netbios para resolução. Nesse caso, o serviço de solicitação de consulta de nome já contém o nome Netbios do host destinatário.
Ainda, conforme o autor, no primeiro caso em que o remetente não possua o nome do destinatário uma mensagem de broadcast é enviada para a rede, o computador que o nome Netbios corresponder ao solicitado responde com uma resposta positiva, o restante descarta o pacote. Se o servidor de nome Netbios (NBNS), caso exista na rede, não reter nenhuma mensagem positiva dos hosts na rede, ele envia uma mensagem negativa ao serviço de Resposta de consulta de nomes. Na plataforma Windows XP, quando não é encontrado um recurso na rede uma mensagem de erro é exibida e transmite para o usuário não localização do recurso.
Como visto acima temos dois modos de um computador da plataforma Windows resolver nomes, entretanto, além dos dois métodos de resolução de nomes acima existe o método padrão Cache de Nome Netbios.
Dos três métodos padrão o cache de nome Netbios é o primeiro método a ser usado no processo de mapeamento dos recursos na rede. O cache acelera o processo de mapeamento, uma vez que o host solicitante já tem conhecimento de qual o IP que está associado ao nome.



4. PROTOLOCO LINK LOCAL MULTICAST NAME RESOLUTION ? LLMNR

Para Cable Guy (2006) o LLMNR é um novo protocolo que fornece um método adicional de resolução de nomes, em que é usado em rede que não dispõem de um servidor de nomes DNS.
Sendo assim, conforme RFC 4795 (2007), o objetivo do protocolo é habilitar a resolução de nomes em cenários em que ainda não tenha implementado algum servidor DNS e necessite permite resolução de nomes.
Outro fator importante definido no RFC 4795 (2007) é que o LLMNR suporta, é compatível com futuros formatos do protocolo DNS, tipos e classes, além de operar em uma porta separada e com um resolvedor de cache dedicado. Isso aconteçe porque o LLMNR usa a mensagem similar ao formato do pacote DNS e usa uma porta diferente, a porta UDP 5355.
Além dos itens citados acima o protocolo LLMNR oferece suporte ao protocolo do Ipv6 ao contrário do protoclo Netbios que só funciona com o protoloco Ipv4, Cable Guy (2006).
Com o próposito de reduzir o tráfego na rede o protocolo LLMNR usa "multicast " e endereços "unicast". Um exemplo retirado da publicação de Cable Guy seria é formação de uma sub-rede com um grupo de compuradores formados "ad hoc" padrão IEEE 802.11 redes sem-fio. Com o LLMNR os hosts na rede podem resolver consultas de nome sem a necessidade de um servidor DNS.
Ainda de acordo com publicação do Techenet (2008), os computadores clientes DNS podem utilizar o LLMNR para resolver nomes num segmento de rede quando um servidor DNS não está disponível. Se um roteador falhar, retirando uma sub-rede de todos os servidores DNS existentes na rede, os clientes existentes que suporta LLMNR poderão continuar a resolver nomes numa base ponto-a-ponto até que a ligação da rede seja restaurada.


4.1 Resolução de Nomes usando LLMNR

Conforme RFC 4795 (2007) as consultas do protocolo são enviadas e recebidas usando a porta 5355. No caso do Ipv4 a solicitação é enviada para o endereço 224.0.0.252, em relação ao Ipv6 é usado o endereço FF02:0:0:0:0:0.
Em uma visão simplificada o processo de resoluçao de nomes dá-se da seguinte maneira: primeiramente o host responsável pela consulta envia a solicitação para o endereço multicast da rede, um destinatário somente responte a solcitiação se ele for autoritativo para a consulta, caso seja verdadeiro a resposta da consulta é envida via endereço unicast por meio do protocolo de transporte UDP. Ao receber a respota o host de origem processa a solicitção e inicia-se o acesso dos recursos desejados do usuário. RFC 4795 (2007).
O uso do endereço unicast pode ser usado nas seguintes situações: o host de origem repete a consulta depois que ele recebeu do host de destino, ou o host de origem consulta um registro para um endereço IP completo sendo a versão Ipv4 ou Ipv6. RFC 4795 (2007).
Por medidas de segurança as solicitações unicast deve ser realizadas pelo protocolo de transportes TCP, consutas oriundas de conexões não TCP devem serem descartadas. RFC 4795 (2007).
4.2 Verificação Unicast

Definido pelo RFC 4795 (2007), antes de enviar uma resposta ao remetente, o receptor configurado com um endereço único verifica se há um outro host na rede LLMNR que é autoritativo para o mesmo nome da interface. Uma vez que o receptor confirmar que é único, o processo de resolução de nome se inicia.
Para fazer a verificação do nome único, o receptor deve enviar uma consulta LLMNR para todos os protocolos na rede (Ipv4 e Ipv6). Se nenhuma resposta é recebida, o receptor nesse momento passa a ser o remetente, a consulta é retransmite no máximo três vezes considerando que o tempo de vida é de trinta segundos para cada transmissão. Se mesmo após as três tentativas não for recebido nenhuma resposta o endereço é considerado único.
Para o caso de houver uma resposta o host verifica se o endereço de origem é igual a qualquer endereço atribuído nas interfaces locais da máquina. Se for encontrado um endereço correspondente não considerado um conflito uma vez que se trata de uma interface da própria rede, o resultado é a finalização da verificação. (RFC 4795, 2007).

4.3 LLMNR como protocolo de resolução de nome seguro

Na descrição de suas caracaterísticas atribuídas pelo RFC 4795 o LLMNR possibilita mecanismo de defesa contra ataques de negação de serviço e contra spoofing.
Para isso, o receptor LLMNR responde somente a uma consulta se ele for autoritativo. O número do tempo de vida do pacote deve ser diminuido para evitar negação de serviçoe e para garantir uma camada a mais de segurança o LLMNR suporta o protocolo de autenticação "IPsec Encapsultation Security Payloa (ESP)".
O Ipsec pode ser usado na autenticação de uma consulta ou resposta unicast ou nas respostas para uma solicitação multicast. (RFC 4795, 2007).

4.4 Uso do LLMNR em Redes Microsoft e Habilitação

De acordo com Mackin e Northrup (2009) o LLMNR não resolve nomes nos sistemas operacionais Windows Server 2003, Windows XP ou versões anteriores do windwos. O mesmo oferece suporte, somente, para o Windows Server 2008, Windows Vista e versões posteriores.
A habititação do LLMNR no Windows Vista é realizada por meio do Network Discovery (Descoberta de Rede), um recurso que pode ser ativado na central de rede e compartilhamento do sistema operacional. (Mackin; Northrup, 2009).
Nesse caso, você pode ativar o LLMNR somente para um setor da rede empresa criando um grupo multicast. Caso aconteçe alguma indisponibilidade no servidor DNS os computadores que estão com o protocolo ativado continua a resolver nomes por meio da tabela de mapeamento do serviço.



5. DIFERENÇA DE USO ENTRE O PROTOCOLO NETBIOS E O PROTOCOLO LLMNR

Mackin e Northrup (2009), uma das principais vantagens do protocolo LLMNR é que ele é compatível com o protocolo Ipv6. A segunda vantagem refere-se ao uso do processo de resoluçao de nomes multicast. Já o Netbios usa o processo de "broadcast", difusão, em que todos os computadores da rede recebe a mensagem.
Para exemplificar a situação acima, no cenário onde foi ativado o uso do protocolo LLMNR em um setor específico de uma empresa, caso o servidor DNS da rede fica-se indisponível somente os computadores clientes iriam ouvir a consulta de nomes de outras computadores.
Se fosse usado o Netbios, todos os micros da rede iria ouvir a consulta, como diz Mackin e Northrup (2009) se observar o tráfego em uma rede Netbios, você verá que ela é "ruídosa" e, devido às informações que transmite, não é particulamente segura.
Em se tratando de desvantagem, o protocolo LLMNR não resolve nomes de computadores rodando o Windows Server 2003, Windows XP ou qualquer outra versão anterior. Mackin e Northrup (2009) consta que na prática, o LLMNR não habilita a conectividade com clientes em uma rede Windows exclusivamente Ipv4.
Ainda, conforme os autores acima, o protocolo não resolve nomes de vizinhos por padrão, você tem de habilitar a descoberta de rede em todos os computadores da sub-rede.
Uma outra e última desvantagem é que o LLMNR não pode ser utilizado para resolver nomes de computadores além da sub-rede local. Mickin e Northrup (2009).


6. CONSIDERAÇÕES FINAIS

Verifica-se que o processo de resolução de nomes facilita o modo de como os usuários acessam os recursos na rede. Ao invés de usar números, você escreve o nome do recurso e por traz desse processo existe mecanismo que convertem o nome solicitado em endereços IP?s.
Em redes corporativas o principal protocolo de resolução de nomes é o DNS (Servidor de Nomes de Domínio), no entanto em empresas que não despontam de artefatos para a implantação e sustentação do DNS buscou-se por soluções padronizadas e de fácil implementação.
No caso de ambientes de redes Microsoft uns dos principais protocolos de resolução de nomes é o Netbios. Como visto anteriormente, o protocolo possibilita a computadores clientes na mesma rede a se comunicarem sem a necessidade de configurações complexas.
No entanto, sabe-se que o protocolo Netbios por usar o processo de resolução de nomes por difusão (solicitação é enviada a todos os computadores na rede) causa um tráfego de rede considerável podendo causas erros nos acessos aos recursos da rede.
Ainda, entendemos o não suporte do protocolo Netbios a versão do protocolo IPv6. Nesse sentido, a Microsoft se empenhou em projetar por meio do RFC 4795 um protocolo de resolução de nomes de fácil implementação, seguro e que desse suporte ao IPv6.
O LLMNR possibilita a computadores Windows Vista, Windows Server 2008 ou superiores a possibilidade de criar um grupo de computadores para comunicação sem a necessidade de existir o DNS.
Durante o decorrer do assunto foi dado o exemplo de uma empresa que possui-se um servidor DNS e quando esse servidor fica-se indisponível os computadores com o protocolo LLMNR ativado pode-se se comunicar de forma rápida e segura.
Outro exemplo seria criar uma rede entre dois ou mais computadores que usam o IPv6 por meio do padrão IEEE 802.2 e esses computadores se comunica-se sem a necessidade de um servidor DNS.
Tendo em vista os aspectos de cada protocolo apresentado buscou-se fazer uma análise comparativa entre ambos com o intuito de apontar as melhorias ofertadas pelo protocolo LLMNR no processo de resolução de nomes.
Assim sendo, podemos afirmar que ambos os protocolos possui vantagens e desvantagens, entretanto o maior dos destaque fica por mérito do protocolo LLMNR por ter disponibilidade de aceitar o protocolo IPv6.
Fica a propostas por intensificar melhorias nos protocolos de resolução de nomes similar ao LLMNR a fim de ser usado como um padrão de acesso aos recursos da rede em quaisquer ambientes de rede, seja esse arquitetura Linux ou arquitetura Microsoft.


REFERÊNCIAS.

COMER, Douglas E. Interligação em Rede com TCP/IP. Rio de Janeiro. 2ª Ed. Campus. 1998.
ODOM, Wendell. CCENT/CCNA ICND1. Rio de Janeiro. 2ª Ed. Alta Books. 2008.
FURUKAWA. Introdução a Tecnologia de Redes de Computadores. FCP Fundamental.
MICROSOFT. 2180A ? Implementação de uma infra-estrutura de rede do Microsoft Windows Server 2003: hosts de rede. 2003.
SOUZA, Lindeberg Barros. Guia Total de Redes de Computadores Edt Érica. 2009.
MORIMOTO, E Carlos. Guia Completo de Redes. 3ª Ed.. Guia do Hardware.
RFC 1001. Protocol Standard for a Netbios Service on a TCP/UDP transport: Concepts and methods. . Disponível em Março de 1987. Acessado em 26 de Janeiro de 2010.
RFC 1002. Protocol Standard for a Netbios Service on a TCP/UDP transport: Detailed Specifications. 1987. Disponível em . Acessado em 26 de janeiro de 2010.
.
RFC 4795. Link-Local Multicast Name Resolution (LLMNR). 2007. Disponível em . Acessado em 26 de Janeiro de 2010.
CARVALH et al., Redes de Dados ? Aspectos Gerais. Unicamp. 1998. 4ª Ed.
KUROSE, James F; ROSS, Keith W. Redes de Computadores e a Internet ? Uma abordagem top-down. Edt. Pearson. 3ª Ed. 2005.
KAPLAN, Aaron; RHODES, Tom. Rede IPv6. . Acessado em 01 de fevereiro de 2010.
DAVIES, Joe. Fundamententals for Microsoft Windows. - NetBios over TCP/IP. . Disponível em 27 de Junho de 2005. Acessado em 01 de Fevereiro de 2010.
GUY, Gable. Link-Local Multicast Name Resolution.. 2006. http://technet.microsoft.com/en-us/library/bb878128.aspx. Acessador em 11 de Fevereiro de 2006.
MICROSOFT TECHNET. Função do Servidor DNS. 2008. Disponível . Acessado em: 22 de fevereiro de 2010.

Autor: Reginaldo Reis De Santana


Artigos Relacionados


O Que São Nomes De Domínio

Introdução Ao Ipv6 E O Impacto Nos Negócios Com A Saturação Do Ipv4.

Web X Internet

Conhecendo Mais A Fundo Da Estrutura Da Internet

Segurança Em Redes Sem Fio

O Básico Do Protocolo Pop3

Windows Server 2003 Versões