CONTEÚDOS DO CAPÍTULO
Introdução
O problema da resolução de endereços Dois tipos de endereços de hardware Resolução por meio de mapeamento direto Resolução em uma rede mapeada diretamente
Resolução de endereço IPv4 através de vínculo dinâmico O cache ARP
ARP cache timeout Refinamentos ARP
Relação de ARP com outros protocolos Implementação do ARP
Encapsulamento e identificação do ARP Formato de mensagem ARP
Revalidação automática de cache ARP Resolução de endereços reversos (RARP) Caches ARP nos comutadores da camada três Proxy ARP
Descoberta de vizinho IPv6 Resumo
6.1
6.2
Introdução
O capítulo anterior descreveu os esquemas de endereçamento IPv4 e IPv6 e mostrou que uma internet se comporta como uma rede virtual, usando apenas os endereços atribuídos ao enviar e receber pacotes. O Capítulo 2 reviu várias tecnologias de hardware de rede e observou que duas máquinas em determinada rede física só podem se comunicar se conhecerem o endereço físico uma da outra. O que não mencionamos é como um host ou um roteador mapeia um endereço IP para o endereço físico correto quando precisa enviar um pacote por uma rede física. Este capítulo aborda esse mapeamento, mostrando como ele é implementado nos IPv4 e IPv6.
O problema da resolução de endereços
Considere duas máquinas A e B que se conectam à mesma rede física. Cada uma possui um endereço IP atribuído IA e IB e um endereço de hardware (MAC, HA e HB). Por fim, a comunicação precisa ser executada enviando frames pela rede usando endereço de hardware que os equipamentos da rede reconhecem. Nosso objetivo, porém, é permitir que aplicativos protocolos de alto nível trabalhem apenas com endereços de Internet. Ou seja, queremos elaborar software que esconda o endereço de hardware em uma pilha de protocolos de nível baixo. Por exemplo, considere que a
6.3
máquina A precise enviar um pacote IP para a máquina B pela rede à qual ambas se conectam, mas A só conhece o endereço Internet de B, IB. Surge a pergunta: como A mapeia o endereço Internet de B no endereço de hardware de B, HB? Existem duas respostas, o IPv4 normalmente usa uma e o IPv6 usa a outra. Vamos considerar cada uma.
É importante notar que o mapeamento de endereço deve ser realizado a cada passo ao longo do caminho desde a origem até o destino final. Em particular surgem dois casos. Primeiro, no último passo da entrega de um pacote IP, ele deve ser enviado por uma rede física até o destino final. A máquina que envia o datagrama (normalmente um roteador) precisa mapear o endereço Internet do destino final para o endereço hardware do destino antes que a transmissão seja possível. Segundo, em qualquer ponto ao longo do caminho da origem ao destino, fora o passo final, o pacote precisa ser enviado a um roteador intermediário. Veremos que o software de protocolo sempre usa um endereço IP para identificar o próximo roteador ao longo do caminho. Assim, o emissor deve mapear o endereço Internet do roteador para o endereço de hardware.
O problema de mapear os endereços de alto nível em endereços físicos é conhecido como problema de resolução de endereço e foi resolvido de várias maneiras. Alguns conjuntos de protocolos mantêm tabelas em cada máquina, contendo pares de endereços de alto nível e endereços físicos. Outros protocolos resolvem o problema codificando endereços de hardware em endereços de alto nível. O uso de qualquer uma das técnicas de forma exclusiva torna o endereçamento de alto nível, na melhor das hipóteses, desajeitado. Este capítulo discute duas técnicas para resolução de endereços usadas pelos protocolos TCP/IP, e mostra quando cada uma é apropriada.
Dois tipos de endereços de hardware
Existem dois tipos básicos de endereços de hardware: os que são maiores do que a parte host de um endereço IP e os que são menores. Como ele dedica 64 bits para a parte do host de um endereço, o IPv6 acomoda todos os tipos de endereços de hardware. Portanto, a distinção só é importante para IPv4. Comecemos por considerar a técnica utilizada para IPv6 e para IPv4 quando os endereços são suficientemente pequenos. Vamos então considerar uma técnica que usa IPv4 quando os endereços são grandes.
6.4
Figura 6.1
Resolução por meio de mapeamento direto
O IPv6 usa uma técnica conhecida como mapeamento direto. A ideia básica é simples: usar o endereço de hardware de um computador como parte do host do seu endereço de Internet. O IPv4 pode usar mapeamento direto quando os endereços são suficientemente pequenos. A Figura 6.1 ilustra o conceito.
Uma ilustração do esquema de um mapeamento direto no qual um endereço de hardware de um computador é inserido em seu
endereço IP.
Para ver como mapeamento direto trabalha com IPv4, é importante saber que alguns hardwares usam, como endereços de hardware, inteiros pequenos, configuráveis. Sempre que um novo computador é adicionado a essa rede, o administrador do sistema escolhe um endereço de hardware e configura a placa de rede do computador. A única regra importante é que dois computadores não podem ter o mesmo endereço. Para tornar a tarefa fácil e segura, um administrador geralmente atribui endereços sequencialmente: ao primeiro computador ligado à rede, é atribuído o endereço 1, ao segundo computador, o endereço 2, e assim por diante.
Enquanto um gerente tem a liberdade de escolher os dois, um endereço IP e um endereço de hardware, o par de endereços pode ser selecionado de tal forma que o endereço de hardware e a parte do host do endereço IP sejam idênticos. O IPv6 faz essa atribuição trivial – o endereço de hardware sempre se ajusta na área do endereço usado para um ID de interface. Para o IPv4, considere um exemplo em que à rede foi atribuído o prefixo IPv4:
192.5.48.0 / 24
O prefixo de rede ocupa os três primeiros octetos, deixando um octeto para o ID de host. Ao primeiro computador da rede é atribuído um endereço de hardware 1 e o endereço IP 192.5.48.1, ao segundo computador é atribuído o endereço de hardware 2 e o endereço IP 192.5.48.2, e assim por diante.
6.5
6.6
Ou seja, a rede está configurada de tal forma que o octeto de baixa ordem de cada endereço IP é o mesmo do endereço de hardware do computador. Claro, o exemplo só funciona se os endereços de hardware estiverem entre 1 e 254.
Resolução em uma rede mapeada diretamente
Se o endereço IP de um computador inclui seu endereço de hardware, a resolução de endereço é trivial. Dado um endereço IP, o endereço de hardware do computador pode ser obtido da parte do host. No exemplo anterior, se o software de protocolo fornece o endereço IP de um computador na rede (por exemplo, 192.5.48.3), o endereço de hardware correspondente pode ser computado simplesmente extraindo o octeto 3 de baixa ordem. Como o nome mapeamento direto indica, ele pode ser feito sem qualquer referência de dados externos. Na verdade, o mapeamento é extremamente eficiente, pois só requer poucas instruções de máquina. O mapeamento direto tem a vantagem de que novos computadores podem ser adicionados à rede sem mudar as atribuições existentes e sem propagar novas informações aos computadores existentes.
Matematicamente, o mapeamento direto significa selecionar uma função f que mapeia o endereço IP de redes físicas. Resolver endereços IP IA significa computar
HA = f (IA)
Embora seja possível escolher mapeamentos diferentes desse exemplo, queremos que o cálculo de f seja eficiente e também que as escolhas sejam fáceis para um humano entender. Assim, é preferível um esquema em que o relacionamento entre o endereço IP e o endereço de hardware seja óbvio.
Resolução de endereço IPv4 através de vínculo dinâmico
Embora eficiente, o mapeamento direto não pode ser usado com IPv4 se endereços de hardware forem maiores que o endereço IPv4. Especificamente, um endereço Ethernet MAC não pode ser mapeado diretamente em um endereço IPv4 porque tem comprimento de 48 bits, e o endereço IPv4 só tem 32 bits. Além disso, devido ao fato de ser atribuído quando um dispositivo é fabricado, um endereço Ethernet MAC não pode ser mudado.
Os projetistas dos protocolos TCP/IP descobriram uma solução criativa para o problema de resolução de endereço para redes como Ethernet, que possuem capacidade de broadcast. A solução permite que novos hosts ou roteadores sejam acrescentados à rede sem recompilar código, e não exige manutenção de um banco de dados centralizado. Para evitar a manutenção de um banco de dados centralizado, os projetistas escolheram usar um protocolo de baixo nível para vincular endereços dinamicamente. Chamado Address Resolution Protocol (ARP), o protocolo oferece um mecanismo que é razoavelmente eficiente e que não requer que um administrador configure tabelas manualmente.
A ideia por trás da tradução dinâmica com ARP é simples: quando ele quer traduzir o endereço IP IB, um host envia por broadcast uma requisição de pacote ARP que pede ao host com endereço IP IB para responder com seu endereço de hardware HB. Todos os hosts, incluindo B, recebem a requisição, mas somente o host B reconhece seu endereço IP e envia uma resposta que contém seu endereço de hardware. O ARP só é usado quando um host precisa mandar um pacote IP. Então, quando ele recebe uma resposta ao seu requisito, o host que fez a requisição usa a informação para enviar pacotes diretamente para B. Podemos fazer o resumo a seguir.
O Address Resolution Protocol, ARP, permite que um host encontre o endereço físico de um host alvo na mesma rede física, a partir somente do endereço IP do host alvo.
A Figura 6.2 ilustra o protocolo ARP mostrando uma solicitação do host A para B, e a resposta de B . Note que, embora a solicitação seja broadcast, a resposta não é.
Figura 6.2
6.7
Ilustração de ARP onde (a) host A envia uma solicitação ARP contendo IB, e (b) host B responde com uma resposta ARP que especifica seu endereço de hardware HB.
O cache ARP
Pode parecer tolice que, para A enviar um pacote para B, ele primeiro envia um broadcast que consome tempo em cada host. Ou então pode parecer tolice ainda maior que A transmita por broadcast a pergunta “como posso alcançar você?” em vez de apenas transmitir o pacote que deseja entregar. Mas existe um motivo importante para a troca. O broadcasting é muito mais dispendioso de ser usado toda vez que uma máquina precisa transmitir um pacote a outra, pois cada máquina na rede deve receber e processar o pacote de broadcast. Então, o software ARP em A usa uma otimização: ele grava a resposta e reusa a informação para transmissões sucessivas.
A norma especifica que o software ARP deve manter um cache de ligações de endereço IP a hardware recém-adquiridas. Ou seja, sempre que um computador envia uma solicitação ARP e recebe uma resposta ARP, ele salva o endereço IP e informações de endereço de hardware correspondentes em seu cache temporariamente. Isso reduz os custos globais de comunicação de forma dramática. Ao transmitir um pacote, um computador sempre olha em seu cache antes de enviar uma solicitação ARP. Se ele encontrar a ligação desejada, não precisa enviar um pedido.
6.8
Assim, quando dois computadores em uma rede se comunicam, eles começam com um pedido e resposta ARP e, em seguida, repetidamente transferem pacotes sem usar ARP para cada pacote.
Experiências mostram que, devido ao fato de a maioria das comunicações de rede envolverem mais de uma transferência, mesmo um cache pequeno é útil.
ARP cache timeout
O cache ARP oferece um exemplo de estado flexível, uma técnica normalmente usada nos protocolos de rede. O nome descreve uma situação em que a informação pode se tornar “velha” sem aviso. No caso do ARP, considere dois computadores, A e B, ambos conectados a uma Ethernet. Considere que A tenha enviado uma requisição ARP e B tenha respondido. Além disso, considere que, depois da troca, B falhe. O computador A não receberá qualquer notificação da falha. Além do mais, por já ter informação de vínculo de endereço para B em seu cache ARP, o computador A continuará a enviar pacotes para B. O hardware Ethernet não fornece indicação de que B não está on-line, pois a Ethernet não tem entrega garantida. Assim, A não tem como saber quando as informações em seu cache ARP se tornaram incorretas.
Em um sistema que usa o estado flexível, a responsabilidade pela exatidão é do proprietário do cache. Normalmente, os protocolos que implementam o estado flexível utilizam timers que são configurados quando informação é adicionada ao cache, e quando o timer expira, a informação é deletada. Por exemplo, sempre que a informação de vínculo é colocada em um cache ARP, o protocolo exige que um timer seja definido, com um tempo limite (timeout) típico de 20 minutos. Quando o timer expira, a informação deve ser removida. Depois da remoção, existem duas possibilidades: se nenhum outro pacote for enviado ao destino, nada ocorrerá; se um pacote tiver de ser enviado ao destino e não houver um vínculo presente no cache, o computador seguirá o procedimento normal de transmitir uma requisição ARP por broadcast e obter o vínculo. Se o destino ainda for alcançável, o vínculo novamente será colocado no cache ARP. Se não, o emissor descobrirá que o destino está off-line.
O uso do estado flexível no ARP tem vantagens e desvantagens. A principal vantagem surge pela autonomia. Primeiro, um computador pode
6.9
•
•
determinar quando a informação em seu cache ARP deve ser invalidada independente dos outros computadores. Segundo, um emissor não precisa da comunicação bem-sucedida com o receptor ou um terceiro para determinar que um vínculo se tornou inválido; se um destino não responder a uma requisição ARP, o emissor o declarará como parado. Terceiro, o esquema não conta com o hardware da rede para fornecer transferência confiável ou informar a um computador se outro computador está on-line. A principal desvantagem do estado flexível surge pelo atraso – se o intervalo do timer for de N minutos, um emissor não detectará que um receptor falhou antes que N minutos tenham passado.
Refinamentos ARP
Vários refinamentos ARP foram incluídos no protocolo que reduz a quantidade de tráfego de rede e automatiza a recuperação após uma mudança de endereço de hardware.
Em primeiro lugar, observe que o host A só transmite uma solicitação ARP broadcast para B quando se tem um pacote de Internet pronto para enviar para B. Como a maioria dos protocolos de Internet envolvem um intercâmbio bilateral, há uma alta probabilidade de que o host B irá enviar um pacote de Internet de volta para A, em um futuro próximo. Para antecipar a necessidade de B e evitar o tráfego extra de rede, ARP solicita que A inclua o seu endereço de IP para hardware de ligação ao enviar uma solicitação a B, que extrai a ligação de A a partir da solicitação e salva a ligação em seu cache ARP. Assim, quando enviar um pacote de Internet para A, B encontrará a ligação já em seu cache.
Em segundo lugar, perceber que, devido às solicitações serem transmitidas via broadcast, todas as máquinas da rede recebem uma cópia da solicitação. O protocolo especifica que cada máquina extraia o endereço de ligação IP para hardware do remetente a partir da solicitação, e utilize as informações para atualizar a ligação em seus cache. Por exemplo, se A transmite uma solicitação broadcast, as máquinas da rede vão atualizar suas informações para A. Máquinas
•
6.10
que ainda não têm uma entrada para A em seu cache não adicionarão informações de A; a norma especifica apenas a atualização do endereço de hardware em entradas existentes. A ideia é que, se uma máquina já teve comunicação com A, seu cache não deve ser obstruído com uma entrada inútil.
Em terceiro lugar, quando um computador tem a sua interface host substituída, (por exemplo, porque o hardware falhou), seu endereço físico muda. Os outros computadores da rede que tem armazenada uma ligação em seu cache ARP precisam ser informados para que possam alterar a entrada. O computador pode avisar aos outros sobre um novo endereço, transmitindo uma solicitação broadcast ARP gratuita. Alterar um endereço MAC requer a substituição de uma NIC, que ocorre quando um computador está desligado. Como um computador não sabe se o seu endereço MAC mudou, a maioria dos computadores transmite um ARP gratuito durante a inicialização do sistema. O ARP gratuito tem um objetivo secundário: ver se alguma outra máquina está usando o mesmo endereço IP. A máquina de inicialização envia uma solicitação ARP para o seu próprio endereço IP; se receber uma resposta, deve haver um erro de configuração ou um problema de segurança em que um computador é intencionalmente imitado.
A seguir se resume a ideia-chave de atualizações automáticas de cache.
O endereço de ligação IP-para-hardware do remetente está incluído em cada transmissão ARP broadcast; receptores usam as informações para atualizar suas informações de ligação de endereço. O destinatário usa a informação para criar uma nova entrada de cache na expectativa de uma resposta.
Relação de ARP com outros protocolos
Como vimos, como o IPv6 usa mapeamento direto, não precisa de ARP. Assim, ARP fornece apenas um possível mecanismo de mapeamento de um endereço IP para um endereço de hardware. Curiosamente, ARP e outros mecanismos de ligação de endereço seriam completamente desnecessários
6.11
se pudéssemos redesenhar todo o hardware de rede para reconhecer endereços IP. Assim, do nosso ponto de vista, a ligação de endereço só é necessária para ocultar os endereços de hardware subjacentes. Conceitualmente, impusemos nosso novo esquema de endereçamento IP acima de qualquer mecanismo de endereço de baixo nível que o hardware usa. Portanto, vemos ARP como um protocolo de baixo nível associado ao hardware, em vez de uma parte fundamental dos protocolos TCP/IP, que são executados acima do hardware. A ideia pode ser resumida:
ARP é um protocolo de baixo nível que esconde o endereçamento subjacente usado pelo hardware de rede, que nos permite atribuir um endereço IP arbitrário para cada máquina. Pensamos em ARP como associado com o sistema de rede física, e não como parte dos protocolos da Internet.
Implementação do ARP
Funcionalmente, o ARP é dividido em duas partes. A primeira fornece resolução de endereços para pacotes de saída: dado o endereço IP de um computador na rede, ele encontra o endereço de hardware do computador. Se um endereço não está no cache, ele envia uma solicitação. A segunda parte lida com pacotes ARP de entrada. Ele atualiza o cache, responde às solicitações de outros computadores na rede e checa se uma resposta coincide com uma solicitação pendente.
A resolução de endereços para os pacotes que saem parece ser direta, mas pequenos detalhes complicam uma implementação. Dado um endereço IP de um computador para o qual um pacote deve ser enviado, o software consulta seu cache ARP para ver se contém o mapeamento do endereço IP para o endereço hardware. Se estiver no cache, o software extrai o endereço hardware, insere no endereço de destino em um frame de saída e o envia. Se não estiver no cache, duas coisas devem acontecer. Primeiro, o host deve guardar o pacote de saída para que possa ser enviado assim que o endereço estiver resolvido. Segundo, o software ARP deve enviar uma solicitação ARP.
A coordenação entre a parte da ARP que envia pedidos e a parte que recebe respostas pode se tornar complicada. Se uma máquina de destino está desligada ou muito ocupada para aceitar o pedido, nenhuma resposta será recebida (ou a resposta pode ser atrasada). Além disso, como a
Ethernet é um sistema de entrega de melhor esforço, o pedido de transmissão broadcast ARP inicial ou a resposta pode ser perdida. Portanto, um remetente deve retransmitir o pedido pelo menos uma vez, o que significa que um temporizador deve ser utilizado e o lado de envio deve cancelar o temporizador se uma resposta chega. Mais importante, surge a questão: enquanto ARP está resolvendo um determinado endereço IP, o que acontece se outro aplicativo tentar enviar para o mesmo endereço? O ARP pode optar por criar uma fila de pacotes de saída, ou simplesmente pode optar por descartar pacotes sucessivos. Em qualquer caso, as principais decisões de design envolvem o acesso concorrente. Outras aplicações podem prosseguir enquanto o ARP resolve o endereço? Se outro aplicativo tentar enviar para o mesmo endereço, as aplicações devem ser bloqueadas ou o ARP deve simplesmente criar uma fila de pacotes de saída? Como pode ser desenvolvido o software ARP para se prevenir que se transmita desnecessariamente um segundo pedido para um computador?
Um detalhe final distingue a gestão de cache ARP da gestão de um cache típico. Em um cache típico, os tempos de espera são usados para eliminar entradas inativas. Assim, o registro data/hora de uma entrada é reiniciado