"Internet Protocol" (IP)Professor Adjunto do Departamento de Engenharia Informática do ISEP 1 IntroduçãoO protocolo IP teve origem em 1970 no desenvolvimento da ARPANET, esta rede foi depois interligada a outras formando em 1980 um vasto conjunto que passou a ser conhecido por Internet. Com a inclusão do protocolo IP no UNIX, em 1982, um grande número de universidades passou a formar as suas redes que por sua vez também foram ligadas à Internet. O protocolo IP fornece um serviço de datagramas que é depois usado por outros protocolos de nível superior, tais como o TCP (Transmission Control Protocol) e o UDP (User Datagram Protocol).  O IP é um protocolo que cuja funcionalidade se aproxima da camada de rede (nível 3) do MR-OSI, como tal fornece um serviço de transferência de dados independente da implementação da camada de ligação lógica (nível 2). A independencia relativamente às camadas inferiores e um esquema de encaminhamento asseguram a comunicação através de redes concatenadas com nível 2 heterogeneo. Uma transferência de dados entre dois nós usando o protocolo IP pode seguir um caminho em que os dados são transportados pelas mais diversas tecnológias de nível inferior, tais como Ethernet, Token-Ring, ATM, X.25, FDDI, etc. Este facto é totalmente transparente para os nós finais. O mecanismo de endereçamento é também independente dos níveis inferiores e na "internet" uma administração hierarquica das gamas disponíveis assegura que cada nó possui um endereço universal. A especificação completa do protocolo IP pode ser obtida na RFC 791, no presente documento são apenas abordados alguns aspectos considerados fundamentais. 2 EndereçamentoO mecanismo de endereçamento do protocolo IP utiliza apenas 4 octetos (32 bits) para designar de um modo universal um nó. Os quatro bytes que constituem um endereço IP são normalmente representados na notação decimal, separados por um ponto. Destes quatro bytes, alguns são usados para identificar a rede e os restantes para identificar o nó dentro dessa rede. O valor dos primeiros bits (mais significativos) indicam quantos octetos são reservados para cada uma das finalidades. Se o endereço IP se inicia com o bit 0, então trata-se de um endereço de classe A, caso contrário trata-se de uma rede de classe B ou C quando o 2º bit possui respectivamente o valor 0 ou 1. A mascara de rede define a parte do endereço IP que é usada para rede e para host, sendo a parte de rede preenchida com bits 1 e a parte de host com bits 0, normalmente a mascara é representada em notação hexadecimal, com os octetos separados por um ponto. Devido a terem utilizações especiais, os endereços com todos os bits zero ou um são reservados. A rede 127 é reservada para testes de loopback, nomeadamente o endereço de "host" 127.0.0.0 corresponde sempre ao proprio "host". A tabela seguinte apresenta um resumo dos endereços de rede e nó (host).
Para "broadcast" numa rede é utilizado o número de "host" mais elevado (todos os bits a 1), o "broadcast" apenas se refere a uma dada rede, sendo por isso usado apenas em aplicações de rede local. A tabela seguinte apresenta um exemplo para cada classe de rede:
2.1 Sub-RedesA motivação da definição de várias classes de redes suportando quantidades diversas de nós (hosts) é evidente: permitir uma melhor adaptação à realidade das organizações. Na prática verifica-se contudo que três classes se revelam insuficientes para todo o tipo de situações. Quando um organização necessita de uma grande quantidade de redes IP a solução consiste na sub-divisão de uma rede atribuida em várias sub-redes. O processo é meramente interno e não deve transparecer para o exterior (RFC 950), consiste em reservar alguns dos bits mais significativos da parte de "host" para identificar a sub-rede. Por exemplo uma rede de classe C utiliza 8 bits para o host, deste oito podemos reservar alguns dos mais significativos para sub-rede e os restantes para host, a seguinte apresenta alguns casos possíveis. Algumas Sub-Redes de Classe C
Como se pode verificar continua a ser necessário evitar os número de host e rede com todos os bits a zero ou um, este facto diminui o aproveitamento dos endereços (por exemplo com a mascara FF.FF.FF.F0 obtem-se um total de 196 hosts (14 x 14), contra um total de 254 com a mascara FF.FF.FF.00), contudo, a utilização de sub-redes justifica-se em muitos casos. A título de exemplo, considere-se a divisão da rede de classe C 193.123.42 em 14 sub-redes de 14 hosts cada, utilizando portanto a máscara FF.FF.FF.F0. Na tabela seguinte apresentam-se alguns algumas caracteristicas dessas sub-redes:
Os valores entre parêntesis indicam números de sub-rede, isto é apenas se referem à parte de sub-rede. Exercício
2.2 ARP ("Address Resolution Protocol")O facto de os endereços serem totalmente independentes dos níveis inferiores tem diversas vantagens, nomeadamente na sua utilização sobre níveis 1 e 2 heterogéneos, contudo coloca alguns problemas:
O primeiro problema é resolvido por configuração local estática, geralmente definindo num ficheiro de configuração os dados necessários, existem contudo soluções de configuração centralizada que serão referidas mais tarde. O segundo problema apenas se coloca quando o nó de destino se encontra na mesma rede (algo que é facil de saber por simples análise dos endereços), quando a máquina de destino não se encontra na mesma rede o "datagrama" é enviado para o "default gateway", trata-se do dispositivo de encaminhamento que assegura a ligação da rede corrente a outras redes. O protocolo ARP (RFC 826) permite obter, sempre que necessário, o endereço físico de uma máquina mediante o conhecimento do seu endereço IP (encaminhamento directo). Quando uma máquina pretende enviar um "datagrama" IP a outra máquina cujo endereço IP conhece, usa o protocolo ARP para enviar em “broadcast” um pedido no qual consta o endereço IP de destino. Todas as máquinas escutam o pedido e aquela que possui o endereço IP indicado responde enviando o seu endereço físico. O protocolo ARP é implementado directamente sobre o nível de ligação lógica e a informação é colocada directamente sobre "tramas". A estrutura dos dados é comum para ARP e RARP (ver adiante). A sequência de campos é a seguinte: FMAC (16 bits) - Formato do endereço MAC (de ligação lógica) FPROT (16 bits) - Formato do endereço de Rede (no caso IP) LMAC ( 8 bits) - Comprimento do endereço MAC LPROT ( 8 bits) - Comprimento do endereço de Rede OPCODE (16 bits) - Comando/Pedido SMAC - endereço MAC de origem SIP - endereço de rede de origem DMAC - endereço MAC de destino DIP - endereço de rede de destino A parte final da estrutura (depois do OPCODE) tem tamanho variável, por exemplo no caso IP sobre Ethernet será de 20 bits (6+4+6+4). O campo OPCODE pode ter um dos seguintes valores que asseguram tanto a operação ARP como RARP: 1 - ARP request 2 - ARP reply 3 - RARP request 4 - RARP reply Cada máquina é responsável por manter dinamicamente uma tabela de correspondência entre endereços físicos e endereços IP recentemente usados (tabela ARP), este procedimento reduz a frequência do recurso ao protocolo ARP. Exercício - Demonstração Em ambiente UNIX ou Windows em modo de linha de comando.
É possivel configurar certos nós para funcionarem como servidores de ARP, trata-se de máquinas que vão responder a pedidos ARP que não lhes dizem respeito. A instalação de um servidor de ARP pode ser útil em termos de segurança. Muitos protocolos de aplicação das redes IP baseiam a segurança no endereço IP de proveniência dos pedidos, com um servidor de ARP um possivel intruso local terá de forjar não só o endereço IP, mas também o endereço MAC correcto. 2.3 BOOTP/DHCP e RARPO "BOOT Protocol", o "Dynamic Host Configuration Protocol" (RFC 2131) e o "Reverse Address Resolution Protocol" (RFC 903) são utilizados para obtenção dos parâmetros de configuração IP, nomeadamente o endereço IP. A utilização destes protocolos é muito vantajosa em termos administrativos, a configuração de todas as máquinas é centralizada num "host" onde se instala um servidor adequado (BOOTP/DHCP ou RARP). O protocolo BOOTP/DHCP é mais completo do que o RARP: enquanto o RARP apenas permite a obtenção do endereço IP, o BOOTP é um protocolo para BOOT de máquinas "diskless", assim permite a obtenção de um ficheiro-imagem para o arranque da máquina, de entre os parâmetros IP fornecidos encontram-se, além do endereço IP, a mascara de rede, uma lista de servidores de nomes e uma lista de "gateways". Ambos os protocolos utilizam principios semelhantes, emitem em "broadcast" um pacote, o servidor ao receber o pacote verifica o endereço MAC de origem e consulta a sua base de dados para devolver a informação que está associada a esse endereço MAC. O formato dos pacotes RARP é idêntico ao dos pacotes ARP. O protocolo BOOTP é implementado a um nível totalmente diferente: usa UDP sobre IP, quando o pedido é emitido é usado como endereço de origem 0.0.0.0 (endereço desconhecido) e endereço de destino 255.255.255.255 ("broadcast" na rede corrente). 3 Datagramas IPO protocolo IP disponibiliza um serviço base de transferência de dados baseado em "datagramas". Cada "datagrama" é totalmente independente dos restantes (serviço não orientado à conexão) e trata-se de um serviço não fiável:
Apesar do caracter de elementar do serviço de "datagramas" do protocolo IP, são incluidos alguns mecanismos que o tornam especialmente adequado para comunicações a longa distancia através da concatenação de infra-estruturas de comunicação heterogéneas:
3.1 Estrutura do "datagrama" IPOs campos que constituem um datagrama IP são os seguintes: --------------------------------------------------------------------- Versão (4 bits) Internet Header Length (IHL) (4 bits) Tipo de serviço (8 bits) Comprimento Total (16 bits) Identificação (16 bits) Flags (3 bits) Offset de Fragmento (13 bits) Tempo máximo de vida (8 bits) Protocolo (8 bits) CheckSum do cabeçalho (16 bits) Endereço de Origem (32 bits) Endereço de Destino (32 bits) Opções (numero de bits variável) Padding (assegura que o cabeçalho tem um comprimento múltiplo de 32 bits) --------------------------------------------------------------------- Dados (variável, mas deve ser sempre um múltiplo de oito, um "datagrama" IP pode ter até 65535 bytes) --------------------------------------------------------------------- O primeiro campo contém a versão do protocolo IP, actualmente a versão mais utilizada ainda é a 4 que está a ser descrita neste documento, mas encontra-se em expansão a versão 6 (IPv6). A versão do protocolo condiciona a estrutura do "datagrama" e mecanismos implementados. O campo IHL contém o número de conjuntos de 32 bits que constituem o cabeçalho, o valor mínimo é 5 que corresponde a um cabeçalho de 20 bytes. O campo "Tipo de serviço". Este campo divide-se na especificação de 8 níveis de prioridade (3 bits), dois níveis de fiabilidade, dois níveis de atraso e dois níveis de capacidade. O comprimento total do "datagrama" (cabeçalho + dados) é indicado no campo seguinte, o seu valor máximo é de 65535 bytes. Os 3 campos seguintes (Identificação; Flags; Offset de Fragmento) estão relacionados com o mecanismo de fragmentação/reagrupamento que será abordado adiante. O tempo máximo de vida é um contador de saltos até à auto-destruição do "datagrama". É inicializado pelo emissor e sempre que o "datagrama" é transferido entre redes por um "router" o seu valor é decrementado em uma unidade, quando chega a zero o "datagrama" é ignorado. O campo "Protocolo" contém um identificador do protocolo responsável pelos dados que são transportados, trata-se de um simples mecanismo de multiplexagem para permitir a coexistência de vários protocolos a utilizarem o IP como base. A seguir apresenta-se o exemplo de um ficheiro /etc/protocols de um sistema UNIX, com vários identificadores de protocolo: # # protocols This file describes the various protocols that are # available from the TCP/IP subsystem. It should be # consulted instead of using the numbers in the ARPA # include files, or, worse, just guessing them. # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol idp 22 IDP # WhatsThis? raw 255 RAW # RAW IP interface # End. O checksum do cabeçalho é calculado por somatório de todos os conjuntos de 16 bits do cabeçalho, o campo checksum é ignorado neste somatório. Como os valores de alguns campos são alterados nos "routers", estes são obrigados a efectuar o calculo e actualizar este campo antes de procederem à retransmissão do "datagrama". Pseudo-cabeçalho IPOs protocolos de nível superior necessitam de usar alguns campos do cabeçalho IP, nomeadamente para cálculo dos seus próprios "checksums", para esse efeito é definida uma estrutura lógica designada por "Pseudo-cabeçalho" IP, contendo os campos necessários: Source Address (32 bits) Destination Address (32 bits) ZERO (8 bits) Protocol (8 bits) Data Length (16 bits) 3.2 OpçõesAs opções são um campo de comprimento variável onde são incluidos parâmetros que nem sempre são necessários, a existência deste campo de comprimento variável possibilita também extensões à funcionalidade do protocolo, as implementações correntes limitam o comprimento das opções a 40 octetos (neste caso limite o cabeçalho IP fica com 56 octetos). Devido ao comprimento variável das opções é adicionado o campo "padding" (enchimento) assegura um alinhamento de 32 bits do cabeçalho. Algumas das opções mais comuns são:
3.3 Fragmentação e ReagrupamentoOs "datagramas" IP são encapsulados em "tramas" ou estrutura equivalente do nível de ligação lógica. Para cada tipo de implementação do nível 2 existe uma quantidade máxima de dados que cada "trama" pode transportar, este valor é conhecido por MTU ("Maximum Transmission Unit"). Devido aos diferentes valores de MTU a abordagem [1 datagrama : 1 trama] não é eficiênte pois seria necessário reduzir o tamanho máximo dos "datagramas" ao menor MTU. A solução é implementar um mecanismo de fragmentação/reagrupamento que realize um ajuste automático ao MTU praticado em cada ligação. A fragmentação dos "datagramas" implica a cópia do cabeçalho original para cada fragmento, os valores dos seguintes campos do cabeçalho IP tornam-se importantes: ... Identificação (16 bits) Flags (3 bits) Offset de Fragmento (13 bits) ... Protocolo (8 bits) ... Endereço de Origem (32 bits) Endereço de Destino (32 bits) ... Em cada "router" um "datagrama" IP é sempre reconstituido, só depois é novamente fragmentado para suportar o MTU da ligação seguinte. Para que os "fragmentos" de diferentes "datagramas" não se confundam entre sí, para cada "datagrama" o emissor define um valor para o campo "Identificação" de tal modo que, em conjunto com os campos "Endereço de Origem", "Endereço de Destino" e "Protocolo" defina um valor único. O primeiro bit do campo "Flags" é colocado a 1 para indicar que existem mais fragmentos a seguir, o valor zero indica que se trata do último fragmento ou que o "datagrama" não foi fragmentado. O segundo bit do campo "Flags" pode ser colocado a 1 para evitar a fragmentação, neste caso se o MTU não suporta o tamanho do "datagrama", este é ignorado. O terceiro bit do campo "Flags" não é utilizado. O campo "Offset de Fragmento" indica a posição relativa do fragmento no "datagrama" original, o valor é especificado em unidades de 64 bits, por esta razão os fragmentos (excepto o último) têm comprimentos de dados múltiplos de 64 bits. No caso de se tratar de um "datagrama" não fragmentado ou o primeiro fragmento de um "datagrama" este campo possui o valor zero. 4 EncaminhamentoOs mecanismos de encaminhamento ("routing") destinam-se a fazer os "datagramas" chegar ao seu destino, quando existe uma grande quantidade de redes concatenadas esta tarefa pode não ser tão simples como parece. O "routing" de "datagramas" IP baseia-se em endereços de rede, os dispositivos que realizam o encaminhamento são conhecidos por "routers", ou na terminologia internet por "gateways". Um "router IP" não é mais do que um "host" que possui um endereço IP em mais do que uma rede, com o "software" adequado pode assegurar a transferência de "datagramas" entre as várias redes nas quais possui endereço. Geralmente um "router" possui mais do que uma interface física, assegurando a transferência de "datagramas" entre técnologias de ligação lógica que podem ser diferentes. Contudo uma rede IP é uma definição lógica, podendo coexistir mais do que uma rede IP a partilhar a mesma rede de ligação lógica, neste caso um "router" de ligação destas redes IP sobrepostas pode assegurar a sua interligação como uma única interface física possuidora de dois endereços IP. A internet é constituida por um vasto conjunto de redes das quais podemos distinguir duas categorias com diferenças substanciais sob o ponto de vista de "routing":
As redes de transito são divididas em várias categorias hierarquicas, como por exemplo redes regionais, nacionais e internacionais. Apenas as redes de transito do nível mais baixo estão ligadas a redes terminais, as de nível superior asseguram a interligação entre outras redes de transito. 4.1 Tabelas de EncaminhamentoUma tabela de encaminhamento é um conjunto de associações (rede, rota 1, rota 2, ...) cada associação regista várias rotas possiveis para atingir a rede indicada. Cada rota é da forma (próximo gateway, métrica), indica qual o "gateway" seguinte para onde deve ser enviado o "datagrama" e qual a métrica associada a essa rota. A métrica é uma medição da eficiência do caminho até ao destino, pode ser definida com base em vários critérios tais como:
Tanto os "hosts" como os "gateways" implementam geralmente tabelas de encaminhamento, as tabelas de encaminhamento podem ser estáticas ou dinâmicas. Uma tabela estática é definida pelo administrador da rede, sempre que se produzem alterações na topologia da rede as tabelas devem ser actualizadas manualmente. As informações de encaminhamento podem ser trocadas entre "gateways" de modo a actualizar dinamicamente as tabelas. Para o efeito usam-se protocolos de "routing". Os protocolos de "routing" usados nas redes terminais são conhecidos por IGP ("Interior Gateway Protocols"), o mais comum é o RIP ("Routing Information Protocol"), os protocolos usados nas redes de trânsito são conhecidos por EGP ("Exterior Gateway Protocols"). Uma entrada importante nas tabelas de encaminhamento é a "default route". É muitas vezes definida estáticamente, todos os "datagramas" cuja rede de destino não consta na tabela de encaminhamento são enviados para o "gateway" especificado na "default route". Um sistema autónomo é um conjunto de redes administradas por uma única entidade, a informação de encaminhamento é trocada entre os "gateways" usando um IGP comum, os "gateway" que asseguram a ligação ao exterior ("gateways de fronteira") implementam o mesmo IGP do sistema autónomo mais um EGP para troca de informação com o exterior. A informação IGP numca deve sair para o exterior, por exemplo se o sistema autónomo usa sub-redes esse facto não transparece para o exterior. 4.2 RIPO protocolo RIP (RFC 1058) é um IGP muito usado no interior de redes terminais para estabelecer dinamicamente as tabelas de encaminhamento nos "hosts" e "gateways". Por se destinar a sistemas autónomos de pequena dimensão o custo máximio admissivel tem o valor 15. Como o custo coincide geralmente com o número de "hops" está limitado sistemas em que o número máximo de "hops" é 15. Devido às particularidades do RIP as tabelas de encaminhamento possuem uma forma particular, cada entrada é constituida pelos seguintes campos: Endereço IP - Pode tratar-se do endereço de uma rede ou de um "host" particular, o RIP não faz distinção. O valor 0.0.0.0 é usado para especificar a "default route". Gateway - Próximo "gateway" da rota. Custo da interface - Custo associado à rede por onde o "datagrama" seria enviado (desde o "gateway" actual até ao gateway mencionado). Geralmente é usado o valor 1 para todos os "hops", a menos que as diferenças relativas de eficiência justifiquem valores superiores. Métrica - O método mais usado é o número de "hops" até ao destino (supondo todos os "hops" possuem um custo unitário). Tempo de Vida - Devido ao tipo de implementação as informações dinâmicas de encaminhamento possuem um tempo de vida. Cada entrada de uma tabela RIP pode ainda conter informação adicional, tais como caracteristicas adicionais da ligação (MTU, Taxa de Transmissão, etc). A métrica de uma rota é dada pelo somatório dos custos dos "hops" por onde passa, o objectivo do RIP é calcular automaticamente os custos de cada rota de modo a efectuar o encaminhamento mais eficiênte. Cada "gateway" sabe o por configuração estática o custo de cada rede onde está ligado (interface). O calculo de custos de rotas baseia-se na difusão periodica em "broadcast" das tabelas RIP por cada "gateway". Quando um "gateway" recebe uma tabela RIP de outro "gateway" adiciona a cada métrica o custo da interface por onde recebeu a informação e actualiza a sua própria tabela RIP. O tempo de vida é importante, se um "gateway" é desactivado ou uma ligação interrompida um conjunto de rotas ficará inoperacional. Graças ao esgotamento do tempo de vida essas rotas deixam de constar das tabelas RIP porque a difusão periodica por RIP desse informação já não chega aos "gateways". Quando este tipo de situação ocorre os "gateways" possuem ainda um método de indicar aos outros "gateways" que a rota não está acessivel, para o efeito associam-lhe um custo de 16 nas tabelas RIP que difundem. 4.3 Encaminhamento RIP EstáticoNem sempre é necessário implementar a actualização automática das tabelas por RIP. Os protocolos de encaminhamento são especialmente importantes quando existem rotas alternativas para um mesmo destino, caso contrário apenas facilitam a tarefa administrativa. Em muitos casos um sistema autónomo não está nessas condições e a difusão periodica de tabelas RIP em "broadcast" só contribui para aumentar o tráfego residual nas redes porque a informação difundida é sempre a mesma. O encaminhamento em redes terminais nas quais não existem rotas alternativas pode muito bem ser feito por definição estática das tabelas de RIP, os "gateways" podem então ser configurados de modo a não difundirem informação RIP pela rede. Na maioria dos casos (redes com um único "gateway") basta definir rotas por defeito, muitas vezes especificando simplesmente o "default gateway". Quando um "host" não sabe qual o "default gateway" da rede onde se encontra existem várias opções:
4.4 Protocolo RIPO protocolo RIP (RFC 1058) transmite a informação encapsulada em "datagramas" UDP, as mensagens RIP são compostas pelos seguintes campos: ------------------------- Comando (8 bits) -> Indica o objectivo da mensagem Versão (8 bits) -> Indica a versão do RIP ZERO (16 bits) -> Deve conter o valor zero ------------------------- AF (16 bits) -> Identificador da familia de endereços ZERO (16 bits) -> Deve conter o valor zero Endereço IP (32 bits) -> Endereço IP de rede, host ou "default route" ZERO (32 bits) -> Deve conter o valor zero ZERO (32 bits) -> Deve conter o valor zero Métrica (32 bits) -> Métrica associada ......................... ------------------------- A última parte da mensagem (de "AF" até "Métrica") pode ser repetida até 25 vezes, o campo AF ("Address Family") indica o formato do endereço. O campo AF permite a utilização do RIP em tipos de rede que usam formatos de endereços diversos. No caso do protocolo IP a familia tem o valor 2. O campo "Endereço IP" indica o objectivo da rota, pode ser um endereço de rede ou host, pode ainda tratar-se da definição da "default route", nesse caso o valor será 0.0.0.0. O "gateway" que fica associado à rota é o endereço de origem do "datagrama" UDP onde esta informação foi colocada. De 30 em 30 segundos cada "gateway" copia a informação das suas tabelas RIP e envia-a (geralmente por "broadcast") a todos os "gateways" vizinhos. Quando um "gateway" recebe uma mensagem RIP procede à actualização das suas tabelas, as mensagens RIP são difundidas continuamente pelos "gateways", quando uma entrada da tabela não é actualizada durante 180 segundos é considerada obsoleta e a sua métrica é colocada a 16. Quando uma entrada da tabela RIP é considerada obsoleta (métrica = 16) inicia-se o procedimento de remoção ("garbage-collect"), para tal é iniciado um temporizador a 120 segundos, se chegar a zero sem que a sua métrica seja alterada é definitivamente removida. Os valores para o campo "Comando" são os seguintes:
O comando "request" é usado para pedir uma resposta com toda ou parte da tabela RIP, normalmente são realizados por "broadcast" para a porta UDP 520. O receptor processa individualmente cada entrada, se existe rota para o endereço especificado coloca a métrica apropriada, caso contrário coloca a métrica em 16. Para pedir a totalidade da tabela RIP o emissor deve colocar o valor zero no identificador de familia. O comando "response" pode ser enviado em resposta a um "request", pode tratar-se de uma actualização regular (30 em 30 segundos) ou uma actualização forçada por se ter verificado uma alteração nas métricas da tabela RIP local. Quando um comando "response" é recebido o receptor procede à actualização da sua tabela de RIP: Para cada rota recebida: - nova métrica = métrica recebida + custo da interface (se maior do que 16 => nova métrica = 16) - se não existe localmente esse destino e métrica < 16 => adicionar à tabela - se já existe esse destino, o "gateway" é o mesmo e a métrica a mesma => actualizar o temporizador - se já existe esse destino, mas a métrica é menor do que a actual, sejam os gateways os mesmos ou não => adoptar a menor métrica e desencadear um "response" forçado. 5 "Internet Control Message Protocol" (ICMP)O ICMP (RFC 792) é um protocolo auxiliar que dá informações sobre o funcionamento do protocolo IP, nomeadamente permite notificar os nós IP da ocorrência de determinados tipos de erros. As mensagens ICMP são transportadas por "datagramas" IP com o identicador de protocolo 1, embora a constituição das mensagem ICMP seja variável, os primeiros 32 bits possuem sempre o mesmo significado:
Os principais tipos de mensagem ICMP são:
As mensagens de erro (Destination Unreachable; Source Quench; Redirect; Time Exceeded; Parameter Problem) transportam o cabeçalho IP do "datagrama" original, mais 64 bits. O cabeçalho IP devolvido permite identificar o "datagrama" no qual ocorreu o erro. Os 64 bits adicionais são importantes porque permitem obter parte do cabeçalho do protocolo de nível superior que estava a ser transportado pelo "datagrama" IP. |