Redes: entendendo o ICMP e o ARP

Além do TCP e do UDP, temos o ICMP (Internet Control Message Protocol), um protocolo de controle, que opera no nível 3 do modelo OSI (junto com o protocolo IP). Ao contrário do TCP e do UDP, o ICMP não é usado para a transmissão de dados, mas nem por isso deixa de desempenhar diversas funções importantes. A mais trivial delas é o ping, que usamos para verificar se uma determinada máquina está online.

Outra função importante do ICMP é o controle do TTL (time to live) de cada pacote TCP ou UDP. Os pacotes tem vida curta e sua única função é carregar os dados até o destino. Eles são transmitidos de um roteador a outro e, uma vez que chegam ao destino, são desmontados e destruídos.

Mas, o que acontece em casos onde não existe uma rota possível até o destino, seja porque a máquina está desligada, por erro no endereçamento, ou por um problema em algum dos links?

Existem duas possibilidades. A primeira é um roteador próximo perceber que a máquina está fora do ar e destruir o pacote. Neste caso, ele responde ao emissor com um pacote ICMP “Destination Unreachable”, avisando do ocorrido. Caso isso não aconteça, o pacote fica circulando pela rede, passando de um roteador a outro, sem que consiga chegar ao destino final.

O TTL existe para evitar que estes pacotes fiquem em loop eterno, sendo retransmitidos indefinidamente e assim consumindo banda de forma desnecessária. Graças a ele, os pacotes têm “vida útil”.

O TTL default varia de acordo com o sistema operacional usado. No Windows XP o default são 128 hops, enquanto nas versões atuais do Linux os pacotes são criados com um TTL de 64 hops. Cada vez que o pacote passa por um roteador, o número é reduzido em um. Se o número chegar a zero, o roteador destrói o pacote e avisa o emissor enviando um pacote ICMP “Time Exceeded”.

Na Internet, os roteadores são espertos o suficiente para conhecerem os roteadores vizinhos e escolherem a melhor rota para cada destino. Sempre que um roteador fica congestionado, os demais passam a evitá-lo, escolhendo rotas alternativas. Essa comunicação é feita através de pacotes ICMP “Redirect”, que avisam o emissor que uma rota mais rápida está disponível e os pacotes seguintes devem ser encaminhados através dela.

Naturalmente, este sistema não é infalível. Corrupções nas tabelas de roteamento, bugs nos softwares de controle, panes e defeitos em geral podem comprometer o trabalho dos roteadores, fazendo com que alguns pontos da rede fiquem inacessíveis. Surge então o clássico problema de um determinado endereço ou faixa de endereços ficar inacessível para usuários de um determinado provedor, muito embora continue disponível para o resto da rede.

Dentro da rede local, os pacotes são transformados em frames, onde são endereçados ao endereço MAC da placa de rede destino e não ao endereço IP. Acontece que, inicialmente, o sistema não sabe quais são os endereços MAC das placas dos outros micros da rede local, sabe apenas os endereços IP que deve acessar.

O ARP (Address Resolution Protocol) faz compania ao IP e ao ICMP na camada 3 do modelo OSI, oferecendo justamente uma forma simples de descobrir o endereço MAC de um determinado host, a partir do seu endereço IP. A estação manda um pacote de broadcast (chamado “ARP Request”), contendo o endereço IP do host destino e ele responde com seu endereço MAC. Como os pacotes de broadcast são custosos em termos de banda da rede, cada estação mantém um cache com os endereços conhecidos.

Naturalmente, isso é feito de forma transparente. É mais um detalhe técnico com o qual você não precisa se preocupar se quer apenas usar a rede, mas que é interessante estudar quando está interessado em entender seu funcionamento. Você pode verificar o cache de endereços ARP do seu micro (no Linux) usando o comando “arp”.

Existe também o “RARP” (reverse ARP), que tem a função oposta: contatar um host da rede quando o endereço MAC é conhecido, mas o endereço IP não. Embora menos usado, o RARP também é importante, pois ele é usado quando uma estação precisa obter sua configuração de rede via DHCP.

Ao receber o pacote de broadcast enviado pela estação, o servidor DHCP sabe apenas o endereço MAC da estação e não seu endereço IP (que afinal ainda não foi definido). Ele é capaz de responder à solicitação graças ao RARP. Sem ele, não teríamos DHCP.