Parte I - Básico de IPv4 e Introdução ao Roteamento ICMP - Internet Control Message Protocol

Parte I - Básico de IPv4 e Introdução ao Roteamento

ICMP - Internet Control Message Protocol

ICMP - Internet Control Message ProtocolSabemos que o IP oferece um serviço não confiável

(sem conexão), visto que o datagrama pode perder-se duplicar-se ou atrasar-se durante a sua entrega. Porém problemas como excesso de tráfego em determinada rota, defeitos em conexões físicas, delays muito grandes, tabelas de roteamento com problemas e destino inativo, interferem na correta entrega dos datagramas. Para avisar o Host origem de eventuais problemas não podemos contar com o IP, pois não possui suporte desse tipo. Por isso foi criado o ICMP.


Em redes orientadas à conexão este processo é simples, pois temos uma rota única definida por onde passarão as informações dos Hosts origem e destino. Assim aproveitamos o tráfego de volta para avisar de possíveis problemas ocorridos durante a entrega da informação. Mas este problema não é tão simples no caso de redes IP, por isso criamos um protocolo específico para cumprir esta missão.


O protocolo ICMP é encapsulado em um datagrama (no seu campo DATA), e este é endereçado à origem.

Na verdade o ICMP passou a ter uma aplicação mais geral ainda. Atualmente qualquer Gateway que detecte uma situação atípica, usa o ICMP para reportar isso aos Hosts ou mesmo à outros Gateways. O mesmo ocorre com os Hosts que avisam Gateways ou mesmo outros Hosts, viabilizando assim um mecanismo único de troca de mensagens de controle e correção de erros.


Encapsulamento do Protocolo ICMP

ICMPHeader

ICMP DATA

DATAGRAMHeader

DATAGRAM DATA AreaICMPHeader

ICMP DATA

FRAME DATA AreaFRAMEHeader

FRAMETailer

DATAGRAMHeader

ICMPHeader

ICMP DATA

Mensagem ICMP

Datagrama IP

Quadro de nível 2


Antes de começarmos a descrever as situações de falha e a respectiva mensagem ICMP gerada, analisemos uma situação prática para termos verdadeira noção do que podemos fazer com o ICMP. Veja a figura à seguir.


LAN 3

LAN 4

LAN 1G1

G2 GX WAN

G2LAN 2

Host A

Host B

Supondo que o Host A mande um datagrama para o Host B. Ele o envia para G1.


G1 fazendo uso das suas tabelas de roteamento, envia para G2.

LAN 1G1

LAN 3

G2 GX WAN

LAN 4G2LAN 2

Host A

Host B


G2 devido à alguma falha interna, ou de tabelas de roteamento errada, ao invés de rotear para G3, encaminha o datagrama para GX.

LAN 1G1

LAN 3

G2 GX WAN

LAN 4G2LAN 2

Host A

Host B


GX impossibilitado de resolver o problema, descarta o datagrama e encapsula em um datagrama novo, endereçado ao Host A, uma mensagem ICMP, avisando da falha ocorrida.

LAN 1G1

LAN 3

G2 GX WAN

LAN 4G2LAN 2

Host A

Host B


Por meios já conhecidos o datagrama com a mensagem ICMP é roteado até a origem.

LAN 1G1

LAN 3

G2 GX WAN

LAN 4G2LAN 2

Host A

Host B


O Host A de posse da mensagem de erro toma providências para contornar o problema, se isso for possível.

LAN 1G1

LAN 3

G2 GX WAN

LAN 4G2LAN 2

Host A

Host B


É muito importante ressaltar que as mensagens são direcionadas para a origem. Mas o que pode fazer o Host A para corrigir o problema do exemplo se ele não conhece o Gateway G2 e muito menos o GX?

Na verdade as mensagens ICMP supõem que o administrador da Rede do Host A sabe o que fazer com a mensagem de erro, mas na verdade nem sempre ele tem algo para fazer, mas isso está fora do escopo do protocolo.


Um datagrama IP contendo uma mensagem ICMP no seu campo DATA, é identificado através do campo PROTOCOL, que terá o valor igual à 1.

Outro ponto importante é que, se uma mensagem ICMP sofre algum tipo de problema, como o relatado no exemplo anterior, não será gerada nenhuma mensagem de erro.

ERROR or CONTROLMESSAGE

TYPE CODE CHECKSUM

MENSAGEM ICMP


TYPE: Campo constituído de 8 bits, identifica a função do segmento ICMP conforme a tabela à seguir.


Tipo doCampo

Mensagem ICMP

0 Echo Reply3 Destination Unreachable4 Source Quench5 Redirect (Change a Route)8 Echo Request

11 Time Exceeded for a datagram12 Parameter Problem on a Datagram13 Timestamp Request14 Timestamp Reply15 Information Request (Obsolete)16 Information Reply (Obsolete)17 Address Mask Request18 Address Mask Reply


CODE: Constituído de 8 bits, provê informações adicionais para cada tipo de mensagens ICMP.

CHECKSUM: Constituído de 16 bits, utiliza o mesmo algoritmo que o protocolo IP, sendo utilizado para validação de suas informações (Header ICMP+Dados).


Vamos agora descrever as principais mensagens ICMP, e sus utilização.

As primeiras mensagens à serem vistas são “Echo Request” e “Echo Reply”, que são usadas para testar a capacidade de alcance de um destino. Passamos à descrever os campos desta mensagem e depois um exemplo de aplicação.


As mensagens Echo Request e Echo Reply possuem o seguinte formato.

. . .

OPTIONAL DATA

IDENTIFIER SEQUENCE NUMBER

TYPE (8 ou 0) CODE (0) CHECKSUM

ECHO REQUEST e ECHO REPLY


TYPE: Para ECHO REQUEST = 8 e ECHO REPLY = 0.

CODE: Não utilizado nestas mensagens devendo ficar em 0.

IDENTIFIER: Usado para personalizar as mensagens (é único para um par ECHO REQUEST/ECHO REPLY). Possui um gerador Randômico para criá-lo.


SEQUENCE NUMBER: Usado para controlar o fluxo das mensagens ECHO.

OPTIONAL DATA: Podemos, para algumas aplicações especiais, utilizar este campo, que é opcional, para enviar dados ao destino. Lembre-se que os dados enviados devem ser copiados na íntegra na mensagem de Reply.


As mensagens de ECHO REQUEST, é acessada através da função conhecida como PING, e a respectiva resposta do destino (o ECHO REPLY) é conhecida como PONG.

Este comando é disponível em alto nível na maioria dos sistemas operacionais, bastando para isso digitar o comando (ping <endereço destino>).


Essas mensagens ECHO REQUEST (ping) e ECHO REPLY (pong), são extremamente úteis para sabermos sobre a capacidade de alcançar um determinado destino.

Imagine que você acabou de instalar um roteador na rede, como você saberia se ele já está ativo? A maneira mais simples é de algum host disparar um ping para o endereço do roteador, se houver resposta há um forte indício que estamos no caminho certo, senão devemos imediatamente ver o que está errado ou faltando.


Outra situação importante é quando usamos um processo automático de pings e para testar a rota, por exemplo um gateway precisa ter certeza da capacidade de alcançar os hosts na sua vizinhança, pois só assim pode tomar decisões certas de roteamento.


Existem aplicações mais sofisticadas que fazem uso de vários “pings”, e através dos respectivos “pongs”efetuam análises estatísticas, gerando relatórios interessantes para o administrador da rede. Estas aplicações permitem a especificação do tamanho e conteúdo dos dados enviados (OPTIONAL DATA), e o período de envio dos pings.


A próxima mensagem é DESTINATION UNREACHABLE (Destino Inatingível).

. . .

INTERNET HEADER + FIRST 64 BITS OF DATAGRAM

UNUSED (DEVE SER TUDO 0)

TYPE (3) CODE (0-12) CHECKSUM

DESTINATION UNREACHABLE


TYPE: Possui valor fixo 3, e caracteriza a mensagem DESTINATION UNREACHABLE.

CODE: Possui valores que podem variar de 0 à 12, com uma especificação maior da causa do erro. Ver tabela seguinte.


Campo CODE Significado0 Network Unreachable1 Host Unreachable2 Protocol Unreachable3 Port Unreachable4 Fragmentation Needed and DF set5 Source Route Failed6 Destination Network Unknown7 Destination Host Unknown8 Source Host Isolated9 Communication with Destination Network

Administratively Prohibited10 Communication with Destination Host

Administratively Prohibited11 Network Unreachable for Type of Service12 Host Unreachable for Type of Service


Observe a riqueza de detalhes na descrição de problemas que fazem um destino ficar inatingível. Mesmo assim existem situações em que o ICMP é incapaz de detectar a falha. Ver exemplo à seguir.


O Host B, manda um datagrama para o Host A, sem saber que este está desconectado. O datagrama trafega normalmente pela rede até chegar no gateway G1.

LAN 1G1

LAN 3

G2 GX WAN

LAN 4G2LAN 2

Host A

Host B

Desligado


O Gateway G1 encaminha o datagrama para o Host A (desligado), pois não pode prever isso, já que não existem mecanismos em redes Ethernet (IEEE 802.3), que avisem que um destino está desativado.

LAN 1G1

LAN 3

G2 GX WAN

LAN 4G2LAN 2

Host A

Host B

Desligado

Neste caso não podemos mandar uma mensagem de Host Unreachable, pois G1 não sabe que o Host B está desligado. A única maneira de sabermos que ocorreu a falha é pelo timeout do controle end to end do TCP.


Continuamos à descrever os campos da mensagem DESTINATION UNREACHABLE.

INTERNET HEADER + FIRST 64 BITS OF DATAGRAM: Copiamos o Header do IP e mais 64 bits do campo de dados (Header TCP), do datagrama que gerou o problema, para que a origem tenha um panorama melhor do problema ocorrido.


A próxima mensagem ICMP é SOURCE QUENCH.

. . .


UNUSED (DEVE SER TUDO 0)

TYPE (4) CODE (0) CHECKSUM

SOURCE QUENCH


TYPE: Este campo possui o valor fixo igual à 4.CODE: Não tem valor ficando preenchido com

0.CHECKSUM: Igual à qualquer mensagem ICMP. INTERNET HEADER + FIRST 64 BITS OF

DATAGRAM: Copiamos o Header do IP e mais 64 bits do campo de dados (Header TCP), do datagrama que gerou o problema, para que a origem tenha um panorama melhor do problema ocorrido.


A mensagem SOURCE QUENCH é usada em situações de congestionamento da rede.

Congestionamento é um estado em que, por razões das características de transmissão de um Gateway, (Velocidade das portas, Throughput, Capacidade de armazenamento, etc.), ele se encontra temporariamente incapaz de atender à demanda de tráfego solicitada, e neste caso, pode descartar datagramas para normalizar o seu estado de funcionamento.


A Mensagem SOURCE QUENCH é utilizada toda vez que um datagrama é descartado, avisando o Host origem para baixar a sua capacidade de tráfego. Assim que o Host para de receber esta mensagem proveniente do Gateway, ele passa a aumentar gradativamente a sua capacidade de tráfego até o máximo.


Lembre-se que quando uma mensagem SOURCE QUENCH é recebida um datagrama já foi descartado e deverá ser retransmitido. Para evitar isso alguns Gateways mandam esta mensagem um pouco antes da necessidade de descartar (buffer quase cheio), o que pode diminuir o tráfego da rede devido à retransmissões.


Mensagem REDIRECT (Mudança de Rota):

. . .


GATEWAY INTERNET ADDRESS

TYPE (5) CODE (0 à 3) CHECKSUM

REDIRECT


TYPE: Recebe o valor 5.CODE: Pode ter valores variando

entre 0 e 3, descreve o tipo de redirecionamento requerido. Ver tabela à seguir.


Código Significado0 Redirect Datagrams for the Net (obsoloeto)1 Redirect Datagram for the Host2 Redirect Datagrams for the Type of Service and Net3 Redirect Datagrams for the Type of Service and Host


CHECKSUM: igual nas mensagens anteriores.

INTERNET HEADER + FIRST 64 BITS OF DATAGRAM: Copiamos o Header do IP e mais 64 bits do campo de dados (Header TCP), do datagrama que gerou a mensagem, com o intuito de facilitar na identificação da rota pelo Host origem.


HOST A

G1

LAN 1

G5

LAN 3

LAN 4

G2

LAN 5

G3

HOST B

LAN 2

G4

O Host A por não conhecer bem a rede pode mandar um datagrama para o Host B, escolhendo para isso o Gateway G1.

O Gateway G1 irá encaminhar normalmente o datagrama, apesar dele saber que o menor caminho seria se ele fosse encaminhado por G5.

O Gateway G1, avisa o Host A (através da mensagem REDIRECT) que existe um melhor caminho para atingir o destino desejado através de G5. Assim o Host A para esta aplicação, ou destino, ou ambos escolhe o Gateway G5, daqui para frente.


É preciso deixar claro que a mensagem REDIRECT é para comunicação entre Host/Gateway, não entre Gateways. O motivo de afirmarmos que G1 sabe de um melhor caminho para o destino, é porque ele conhece a tabela de roteamento de G5, e isso ocorre por causa de outros protocolos específicos de roteamento, que estudaremos na parte 2 deste módulo.


Mensagem TIME EXCEEDED FOR A DATAGRAM:

. . .


UNUSED (DEVE SER 0)

TYPE (11) CODE (0 ou 1) CHECKSUM

TIME EXCEEDED FOR A DATAGRAM


TYPE: Recebe o valor 11.CODE: Pode ser 0 ou 1, conforme

tabela abaixo:

Código Significado0 Time-to-live Count Exceeded1 Fragment Reassembly Time

Exceeded


CHECKSUM: igual nas mensagens anteriores.

INTERNET HEADER + FIRST 64 BITS OF DATAGRAM: Copiamos o Header do IP e mais 64 bits do campo de dados (Header TCP), do datagrama (ou fragmento) que foi descartado por não atingir o destino em tempo especificado (Time to Live).


Esta mensagem é usada toda vez que ocorrer um problema de descarte, por causa do tempo Time to Live ter sido excedido, e o datagrama (ou fragmento) não ter chegado ao destino. A principal causa disso é a formação de loops na rede, onde o datagrama entra e não pode mais sair.


Mensagem PARAMETER PROBLEM ON A DATAGRAM:

. . .


POINTER UNUSED (DEVE SER 0)

TYPE (12) CODE (0 ou 1) CHECKSUM

PARAMETER PROBLEM ON A DATAGRAM


TYPE: Recebe o valor 12.CODE: Pode ser 0 ou 1. Se for 0 o

POINTER aponta para o octeto com problemas. Se for 1 não podemos dizer qual octeto está com problema (não usamos o POINTER).

CHECKSUM: O mesmo que nas outras mensagens.


POINTER: Aponta para o octeto que apresenta problemas de parâmetros. Só é usado quando CODE = 0. Caso contrário não podemos especificar o erro e o POINTER perde a utilidade.

INTERNET HEADER + FIRST 64 BITS OF DATAGRAM: Copiamos o Header do IP e mais 64 bits do campo de dados (Header TCP), do datagrama com problemas, para que o HOST origem possa tomar providências.


Esta mensagem é usada quando o erro ocorrido não tiver nenhuma correlação com qualquer outra mensagem ICMP. Assim usamos apenas quando problemas no Header IP do datagrama forem encontrados, principalmente de campo invalidamente preenchidos.

ICMP - Internet Control Message ProtocolMensagem TIMESTAMP REQUEST e

TIMESTAMP REPLY:

TRANSMIT TIMESTAMP

RECEIVE TIMESTAMP

ORIGINATE TIMESTAMP



TIMESTAMP REQUEST e TIMESTAMP REPLY


TYPE: Recebe o valor 13 (TIMESTAMP REQUEST) ou 14 (TIMESTAMP REPLY).

CODE: Não usado e recebe o valor 0.CHECKSUM: O mesmo que nas

outras mensagens.IDENTIFIER: Número Randômico que

personaliza a mensagem.


SEQUENCE NUMBER: Contador que controla a seqüência Request-Reply.

ORIGINATE TIMESTAMP: composto de 32 bits, é utilizado pelo Host originador da mensagem TIMESTAMP REQUEST, onde insere o seu tempo em milissegundos (baseado na hora ZULU, do meridiano de Greenwich), no momento do envio do datagrama.


RECEIVE TIMESTAMP: É usado pelo receptor do REQUEST assim que este é lido e identificado. Contém a timestamp da recepção do REQUEST. É colocado na mensagem REPLY.

TRANSMIT TIMESTAMP: É usado pelo receptor do REQUEST, e é colocado na mensagem REPLY, com o timestamp do momento da transmissão desta mensagem.


Cabe salientar que apenas o ORIGINATE TIMESTAMP é usado na mensagem REQUEST, os demais são preenchidos para formar a mensagem REPLY.

Este recurso é usado para termos uma idéia de tempo que um datagrama demora para atingir um destino especificado.


Cabe salientar que não devemos confiar nas estatísticas geradas por esse recurso como valores absolutos, mas apenas valores orientativos e de momento, pois mesmo que façamos várias vezes esta medida, a rede é não orientada à conexão, e podemos ter diferentes rotas seguidas, dando timestamps diferentes.


Mensagem INFORMATION REQUEST e REPLY:

Não é mais usada tornando-se obsoleto. Foi criada para resolver problemas de endereçamento, hoje função realizada pelo ARP e RARP.


Mensagem ADDRESS MASK REQUEST e ADDRESS MASK REPLY:

ADDRESS MASK



ADDRESS MASK REQUEST e ADDRESS MASK REPLY


TYPE: Recebe os valores 17 (REQUEST) ou 18 (REPLY).

CODE: Sem função, valor 0.CHECKSUM: Igual à mensagens

anteriores.IDENTIFIER: Número Randômico que

personaliza as mensagens.


SEQUENCE NUMBER: Contador que controla o fluxo das mensagens REQUEST-REPLY.

ADDRESS MASK: a máscara da sub-rede que desejamos saber.


Para que um Gateway possa encaminhar corretamente uma mensagem ele precisa conhecer o endereçamento de NetID e de SubNetID. Caso haja subredes então precisamos conhecer às máscaras que definem o campo SubNetID. A mensagem ADDRESS MASK foi formulada com o intuito de conseguirmos esta máscara.


O funcionamento é simples, quando um Host quer conhecer o endereçamento de alguma subrede, ele manda a mensagem ADDRESS MASK REQUEST em broadcast ou direcionada para um Host destino conhecido pertencente à subrede em questão. O Gateway que estiver ligado à esta subrede responde com a mensagem ADDRESS MASK REPLY, preenchendo o campo ADDRESS MASK com o valor da máscara de subrede em questão.

Documents

Parte I - Básico de IPv4 e Introdução ao Roteamento ICMP - Internet Control Message Protocol