CAP REDES E COMUNICAÇÃO DE DADOS Redes - PROTOCOLO TCP/IP. Redes - Parte III PROTOCOLO TCP/IP 91 1 ENDEREÇO IP 91 2 SUB-REDES E SUPER-REDES 96

Transcrição

1 Redes - Parte III PROTOCOLO TCP/IP 91 1 ENDEREÇO IP MÁSCARA DE REDE ENDEREÇO DE BROADCAST ENDEREÇOS DE REDES ESPECIAIS: OUTRAS NOTAÇÔES DE ENDEREÇAMENTO 95 2 SUB-REDES E SUPER-REDES EXERCÍCIOS Exercícios para Laboratório: 98 3 PROTOCOLOS ARP E RARP ARP (Address Resolution Protocol) RARP (Reverse Address Resolution Protocol) A FORMA DA MENSAGEM ARP ou RARP EXERCÍCIOS: PROTOCOLO IP O FORMATO DE UM DATAGRAMA IP FRAGMENTAÇÃO E REMONTAGEM DOS DATAGRAMAS ROTEAMENTO IP ENVIO DIRETO ENVIO INDIRETO ROTEAMENTO IP POR TABELAS ROTEAMENTO TIPO "NEXT-HOP" ROTA PADRÃO ROTAS ESPECIFICAS DE HOSTS ROTEAMENTO ENVOLVENDO SUB-REDES E SUPER-REDES ALGORITMO DE ROTEAMENTO EXERCÍCIOS PROTOCOLO ICMP FINALIDADE FORMATO DA MENSAGEM ICMP

2 7 PROTOCOLO DE PORTAS PROTOCOLO UDP FORMA DAS MENSAGENS UDP QUANDO UTILIZAMOS O UDP? Exercícios: PROTOCOLO TCP PROPORCIONANDO A CONFIABILIDADE NO ENVIO E RECEBIMENTO A IDENTIFICAÇÃO DAS CONEXÕES A FORMA DOS SEGMENTOS TCP INICIO E TÉRMINO DAS CONEXÕES - "THREE WAY HANDSHAKE" EXEMPLOS DE SERVIÇOS TCP: QUANDO UTILIZAMOS O TCP? EXERCÍCIOS: 127 ANEXO: 128 TESTE 1: 128 TESTE 2: 128 TESTE 3: 129 TESTE 4: 129 TESTE 5: 130 TESTE 6: 131 TESTE 7: 131 TESTE 8: 132 CONCLUSÕES DOS TESTES

3 Redes - Parte III PROTOCOLO TCP/IP Denominamos de TCP/IP um conjunto de protocolos encontrados em todas as camadas do modelo TCP/IP. Todos, de alguma forma, usam endereços IPs. Mesmo aqueles encontrados na camada de interface (ARP e RARP) associam o endereço físico ao endereço IP. Neste capítulo veremos alguns detalhes do TCP/IP, seus protocolos e respectivos cabeçalhos e detalhes de funcionamento e configuração de algumas aplicações. 1 ENDEREÇO IP No protocolo TCP/IP, um nó com ou sem identidade física pode possuir sua identidade lógica IP. Esta identidade é um Número IP ou endereço IP. Este número tem um tamanho de 32 bits e é representado, normalmente, na forma decimal de cada byte separado por um "." (ponto). Ao receber um datagrama IP o software TCP/IP de um equipamento compara o endereço de destino existente no cabeçalho do protocolo de rede com seu endereço IP. Se o resultado desta operação coincidir com seu endereço IP (ou um conjunto deles associado àquela máquina), então a máquina de destino é ela mesma. Caso o endereço não coincida então o datagrama é descartado. Um endereço IP é constituído por uma tripla (bits de identificação da classe, identificação da rede - netid, identificação do nó lógico daquela rede - hostid). Quando aplicamos a máscara, tratamos o endereço IP como uma dupla (identificação de rede, que envolve os bits da classe e o netid, e o hostid). Identificamos as classes de endereçamento como mostra a figura: Assim, no formato decimal byte-a-byte, temos as seguintes faixas de endereçamento: 91

4 Classe Início Final A até B até C até D até E até Algumas faixas de endereçamento e endereços individuais são reservadas para endereçamento específico. É o caso do endereço que, dependendo do objetivo da implementação TCP/IP (software de roteamento ou usado por uma estação) representa o endereço de uma máquina gateway ou mesmo um endereço global. O endereço representa um endereço coringa. Se não fosse pelas restrições de roteamento, um pacote enviado para este endereço alcançaria TODAS as máquinas de uma rede, por maior que ela fosse. Cada rede tem, portanto, um endereço que a identifica, ou endereço de rede, que representa a identificação da rede; e um endereço coringa ou endereço de broadcast. que representa todos os nós lógicos daquela rede. Com as classes de rede, temos um pequeno número de redes lógicas que admitem um grande número de endereços de nós lógicos (redes da Classe A) e um grande número de redes lógicas com um pequeno número de nós lógicos (redes da Classe E). As classes D e E são muito especiais. São representam endereços lógicas de multicast e experimentais, respectivamente. Reparem que um endereço IP representa, neste caso, uma "rede" de máquinas. 1.1 MÁSCARA DE REDE Como se identifica a rede? Uma vez que o endereçamento IP possui 32 bits isto significa 4Giga-endereços diferentes o que exigiria uma tabela de igual tamanho para ser tratada caso o roteamento fosse por endereço absoluto. Separando em redes as tabelas são reduzidas. Para isto, usamos o endereço de máscara. Operando logicamente (AND) tais máscaras sobre o endereço IP o resultado fornece a identificação da rede. Um exemplo de máscara válida para uma rede que contém a maquina de número IP é: máscara = , cuja representação binária é: Relembrando, a tabela verdade da função lógica E (AND): 92

5 0 AND 0 = 0 0 AND 1 = 0 1 AND 0 = 0 1 AND 1 = 1 Assim, na forma binária, considerando o endereço , ( ) AND ( ) = ( ) número IP de identificação da rede) ou, na representação decimal: De forma genérica: (número IP da máquina) AND (máscara) = (número IP de identificação da rede) ID da Rede = #IP.AND. #MÁSCARA 1.2 ENDEREÇO DE BROADCAST. E quanto ao endereço de broadcast? Como dito anteriormente, o Endereço IP de broadcast é um endereço coringa, ou seja, todas as máquinas de uma mesma rede IP também se reconhecem por este endereço que tem os bits do hostid em 1, e pode ser calculado por: (end. broadcast) = (ID da rede) + (NOT.máscara) (NOT) é uma operação lógica e apresenta a seguinte tabela: NOT 1 = 0 NOT 0 = 1 Assim, se a máscara é: (NOT) = Somando entre este resultado ao endereço da rede temos o endereço de broadcast ( ) ( ) = ( ) (endereço de broadcast) Visto a necessidade das máscaras, as classes de rede receberam as máscaras padronizadas: 93

6 Classe Máscara Padrão A B C D E Com isto, a classe A possui 256 redes e cada rede (256*256*256) endereços. Tirando o endereço IP da rede e o endereço de broadcast, uma rede classe A permite nós válidos (teoricamente). Por que teoricamente? Porque o endereço não foi desconsiderado. Porque, apesar de válido, a classe A inicia em que também não foi desconsiderado. A Classe B permite redes e cada rede com este mesmo valor de nós Tirando o endereço de rede e o endereço de broadcast temos endereços válidos por rede. A Classe C permite redes e cada rede com 256 nós (teóricos). Tirando o endereço de rede e o endereço de broadcast temos 254 endereços válidos por rede. As Classe D e E representam redes de um único nó lógico. Estas redes não possuem endereço de broadcast. Assim, podemos generalizar para quaisquer redes oriundas das classes A, B e C as regras de Identificação de Rede e do endereço de broadcast. 1.3 ENDEREÇOS DE REDES ESPECIAIS: O IANA (Internet Address Number Authority) selecionou alguns espaços de endereçamento para fins especiais (RFC1597, RFC1700). Estes espaços de endereçamento atendem às redes públicas, privativas, multicast e redes lógicas puramente virtuais (rede local - interna ao equipamento). Os espaços de endereçamento de redes públicas são para aquelas interligadas à Internet. Os espaços de endereçamento de redes privadas não devem ser conectadas diretamente à Internet usando tais endereços (elas já existem lá!). As redes lógicas puramente virtuais fazem parte de todo e qualquer implementação TCP/IP (qualquer equipamento com TCP/IP ativo). As redes destinadas à multicast (propagação controlada de serviços dedicados), associam faixas de endereçamento para alguma atividade envolvendo um grupo específico de máquinas. Exemplo: videoconferência (áudio/vídeo). Todas as máquinas que farão parte da aplicação de videoconferência também se identificam com algum endereço do espaço IP até (Multimedia Conference Calls). Os valores das redes privativas são: 94

7 CLASSE Blocos de Endereços Faixa de endereçamento A > B > > , > C > , > , > Rede Interna Classe A Redes Públicas Todas as outras do espaço de endereçamento das Classes A, B e C Redes de Multicast Compreende os endereços a classe D. Redes Reservadas Classe E OBSERVAÇÔES: Estas atribuições de números podem sofrer alterações sem qualquer aviso prévio do IANA. É altamente recomendável manter atualizado sobre as RFCs. A última modificação ocorreu em outubro de 1994 (RFC1597 e RFC1700). 1.4 OUTRAS NOTAÇÔES DE ENDEREÇAMENTO Com o aparecimento de endereçamento genérico (classless addressing [CIDR1, CIDR2]), a parte do número de identificação da rede pode ter qualquer tamanho, e toda a noção de classes de endereços torna-se sem importância. Há casos especiais para o endereçamento IP que podem ser resumidos usando as recentes notações de endereçamento IP: ou Endereço IP ::= { <Número da Rede>, <Número do Nó> } Endereço IP ::= { <Número da Rede>, <Número da Subnet>,<Número do Nó> } Também usarmos a notação "-1" para indicar que o campo contém todos os bits em 1 Seguem alguns casos especiais comuns: (a) {0, 0} Este nó da rede. Pode ser usado como um endereço de origem. 95

8 (b) {0,<Número do Nó>} Nós especificado na mesma rede. Pode ser usado como um endereço de origem. (c) { -1, -1} Propagação Limitada (Limited broadcast). Pode ser usado como um endereço de destino, e um datagrama como este endereço nunca pode ser redirecionado para rede externas. (d) {<Número da Rede>, -1} Broadcast Direcionado para uma rede (todas as máquinas conectadas àquela rede) Pode ser usado como um endereço de destino. D (e) {<Número da Rede>, <Número da Sub-Rede>, -1} Ídem ao anterior, porém direcionado para a Sub-Rede especificada. (f) {<Número de Rede>, -1, -1} Broadcast Direcionado a todas as sub-redes naquela rede. Somente pode ser usado como um endereço de destino. (g) {127, <any>} Endereço de Nó de Loopback Interno. Nunca deve aparecer fora do nó. Exemplos: 1) Considerando os padrões de classes, identificar as classes e as redes dos endereços IPs: a) b) c) d) e) ) Escreva os endereços acima considerando a notação de classless. 2 SUB-REDES E SUPER-REDES Como vimos a máscara aplicada em um endereço IP de um nó, identifica a rede lógica que aquele nó pertence. Vimos também a existência de máscaras padrões segundo as classes de rede. O uso de máscaras independe da classe que aquele bloco (ou blocos) pretence(m) A capacidade de endereçamento IP da Internet pode alcançar seus limites em breve. Isto foi previsto em 1994, e foi pedido aos integrantes da Internet para adotar técnicas de segmentação de redes. Com o crescimento da grande rede as tabelas de rotas também se ampliaram gerando atrasos sensíveis nos sistemas de roteamento. Para contornar estes problemas adota-se a técnica de segmentação (sub-redes) e fusão de redes contíguas permitindo as super-redes. Segmentar logicamente uma rede é dividi-la em novas redes lógicas aplicando máscaras não convencionais, habilitando bits de menor ordem. Em outras palavras segmentar redes 96

9 significa habilitar bits (estado 1 à direita da máscara padrão) e fundir redes em desabilitar os bits (estado 0 - zero - à esquerda da máscara padrão). Exemplo: 1) Segmentar uma rede classe B em 2 sub-redes. Fornecer a nova máscara. Partindo da máscara padrão para uma rede Classe B: Dividindo a rede em 2 sub-redes, ou "deslocamento à direita de 1 bit" (máscara padrão) = (máscara após = segmentação) 2) Qual o valor da máscara para uma super-rede resultante de 2 redes classe B (contíguas)? Partindo da máscara padrão para uma rede Classe B: Unir as 2 redes em 1 super-rede ou "deslocar à esquerda o último bit da máscara" (máscara padrão) = (máscara após = união) Cabe lembrar a condição de endereço de identificação da rede e de broadcast não podem ser esquecidos quando tratamos de redes que correspondem às classes A, B e C. Isto limita a segmentação de redes até o bit 2 (inclusive) da máscara. Vamos considerar a máscara padrão para a classe C Escrevendo o byte com o valor 0 na forma binária: Para dividir em dois segmentos, este último byte apresenta-se: Para 4 segmentos Para 8 segmentos:

10 Ou seja, o número de segmentos está associado ao número de bits que estamos preenchendo com valor 1. Assim, é possível deduzir que o número de segmentos (S) e o número de bits deslocados (N) estão relacionados, por: N S = 2 Isto é valido até que seja alcançado o bit 2 do último byte. Partindo da máscara padrão de uma única rede da classe A, N < 23 ( sub-redes com 2 nós); partindo da máscara padrão de rede classe B, N<15 (16384 sub-redes com 2 nós), e para rede classe C : N<7 (64 sub-redes com 2 nós) EXERCÍCIOS 3) Fazer o mesmo do exercício 1 para uma rede classe C 4) Idem ao 2 para uma rede classe C. 5) Identificar a máscara para segmentar uma rede classe C em 4 sub-redes 6) Identificar a máscara para criar uma super-rede de 4 redes contíguas da classe C. 7) Identificar os novos endereços de rede e broadcast para cada segmento de sub-rede e das super-redes. 2.2 Exercícios para Laboratório: Considere um conjunto de 4 máquinas que fazem parte de uma rede classe C. 1) Teste a conectividade destas máquinas (use o comando ping) 2) Calcule a máscara necessária para dividir a rede em 2 segmentos. Modifique a máscara de duas das máquinas de modo que cada uma das selecionadas façam parte de uma subrede. Avise ao professor destas mudanças para que ele tome outras providencias de configuração. Teste a conectividade lógica entre as máquinas de segmentos diferente e entre uma máquina da rede padrão e a do segmento. Descreva e explique os fatos ocorridos? 3 PROTOCOLOS ARP E RARP Para explicar os protocolos ARP e RARP formulando duas perguntas: 98

11 Se 2 máquinas compartilham da mesma rede física, como é que uma conhecerá o endereço ethernet da outra se a primeira só conhece o endereço Internet (IP) da segunda? Como uma máquina diskless consegue determinar seu endereço IP? Para resolver estes problemas foram inseridos no TCP/IP dois protocolos de baixo nível. Estes protocolos estão no limite inferior da camada IP e são conhecidos como ARP e RARP. 3.1 ARP (Address Resolution Protocol) Uma forma de estabelecer o mapeamento entre endereço IP e endereço físico é o que denominamos de mapeamento direto. Uma solução é tomar o hostid do endereço IP como índice de uma tabela contendo o endereço físico da interface correspondente. Esta tabela estaria armazenada em memória (permanente ou não) e seria carregada em memória em tempo de boot. Mas isto tem alguns inconvenientes, pois não é raro a atualização de placas de rede ou mesmo o transporte de uma máquina para redes físicas diferentes, exigindo uma solução mais dinâmica. Para resolver este problema os projetistas buscaram uma solução bem simples, que lembra a capacidade de broadcast das redes Ethernet, e que evita problemas de centralização de serviços e manutenção das tabelas de mapeamento. O protocolo projetado denomina-se ARP (Address Resolution Protocol) e está fundamentado na seguinte idéia: Quando um Host A quer conhecer o Endereço físico de um Host B cujo endereço Internet (IP) é conhecido, ele (Host A) envia um frame especial para a rede questionando qual o endereço físico F b do Host de endereço IP b. Todos os hostes receberão o pacote, mas somente o próprio Host de endereço IP b responderá à solicitação com seu endereço Ethernet. A partir de então, o host A poderá enviar pacotes diretamente para o host B usando o endereço físico informado. Desta idéia elementar, surgiram otimizações: - Ao enviar um pacote para o host de destino em frames de broadcast, o transmissor já envia as informações sobre si mesmo, prevendo a continuidade da comunicação, evitando a solicitação em sentido contrário. - Todas as respostas são armazenadas em memória. Assim, antes de enviar um novo frame ARP, o host verifica o IP do destinatário em suas tabelas. O pacote com frame de broadcast só será enviado caso não encontre qualquer referencia ou associação entre endereço IP e endereço ethernet. 3.2 RARP (Reverse Address Resolution Protocol) 99

12 A resposta da segunda pergunta está no uso de máquinas que prestam serviço de RARP. A idéia é a mesma do ARP, ou seja, por broadcast. Uma estação diskless (sem disco) envia para o meio físico um frame tipo broadcast solicitando seu IP. Todas as máquinas que compartilham daquela rede física recebem o frame. Apenas as que prestam serviço RARP responderão a solicitação. A resposta estará em função do endereço ethernet informado. Há serviços alternativos ao RARP, conhecidos como BOOTP e DHCP. 3.3 A FORMA DA MENSAGEM ARP ou RARP Uma mensagem ARP tem a forma apresentada pela figura abaixo. Os números indicam a ordem do campo no frame e não a identificação do bit do campo. Onde HARDWARE TYPE PROTOCOL TYPE HLEN PLEN OPERATION SENDER HA SENDER IP Especifica o tipo da interface de onde se busca a informação. Para interface Ethernet o valor é 1. é o tipo de endereço do protocolo de maior nível. O valor é para o protocolo IP. é o tamanho do endereço de hardware (físico) É o tamanho do endereço IP. Com estes dois campos HLEN e PLEN, é possível coletar informações de qualquer tipo de rede. Define o tipo de operação: 1 - Requisição ARP, 2 - Resposta ARP, 3 - Solicitação RARP, 4- Resposta RARP. É o endereço de hardware do solicitante É o endereço IP do solicitante 100

13 TARGET HA TARGET IP É o endereço de hardware da máquina de destino (RARP) É o endereço IP da máquina de destino (RARP). Quando o frame (quadro) chega ao destino, esta máquina lê a informação dos campos correspondentes ao emissor e retorna o pacote com suas informações. 3.4 EXERCÍCIOS: 1) Ao ligar o seu equipamento, verifique a tabela de endereços físicos através do comando " arp -a" (sem as aspas). 2) Selecione uma outra máquina da mesma rede física e repita o comando. Agora, de uma destas máquinas mande um pacote ICMP (PING) para a outra máquina. Verifique as tabelas de ARP das duas máquinas. 3) Pesquise as RFCs que comentam sobre o ARP e RARP. 4 PROTOCOLO IP O protocolo IP é um mecanismo utilizado para o envio de datagramas. Este mecanismo apresenta as seguintes características: É não confiável (não há garantias de recebimento). Um pacote pode ser pedido, se atrasar, ser enviado fora de ordem, sem que exista uma forma de detectar este tipo de condição nesta camada. É não orientado à conexão, pois cada datagrama é tratado de forma independente um do outro; É dito "best-effort delivery" porque o software se esforça no envio do datagrama, ou seja, somente descartará o datagrama após tentar todos os recursos possíveis. O protocolo IP proporciona 3 definições importantes: A unidade de transferencia de dados, os datagramas, tem uma forma exata. Realiza a função de roteamento Informa, de alguma forma, como os nós (hosts e roteadores) devem tratar o datagrama, quando as mensagens de erro devem ser geradas, e em quais condições um datagrama deve ser descartado. 101

14 4.1 O FORMATO DE UM DATAGRAMA IP Considerando a ordem de envio dos bits, o formato do datagrama IP é: onde: VER HLEN SERVICE TYPE versão do protocolo IP. Este campo de 4 bits tem o valor =4 (IPv4) Tamanho do cabeçalho em palavras de 32 bits. O menor valor é 5 (sem opções IP ou padding) Ou TOS (Type of Service), é um campo de 8 bits composto por: PREFER D T R SEM USO PREFER - Especifica a preferencia/prioridade do datagrama sobre outros. Admite os seguintes valores: Network Control (Controle de rede local) Controle de Internetwork CRITIC/ECP (É um datagrama Crítico) Flash Override (mais rápido apagando o pacote anterior) Flash (mais rápido) Imediato Alguma Prioridade Rotina (Normal) 102

15 Esta preferencia deve ser tratada adequadamente. O controle destas preferencias deve ser feito localmente. D: 0 = Normal, 1 = Reduzir o atraso. T: 0 = Throughput Normal, 1 = Alto Throughput. R: 0 = Confiabilidade Normal, 1 = Alta Confiabilidade. Bit 6-7: Reservado para uso futuro (não informado). Selecionar os BITS D,R e T não significa melhorar o desempenho geral daquela rede. Em alguns casos, selecionar um deles implica na deterioração de outro recurso. TOTAL LENGTH IDENTIFICATION FLAGS É o tamanho daquele datagrama, incluindo os dados. (não se trata do tamanho de um datagrama original, caso tenha sido fragmentado) É uma identificação do datagrama. No caso de uma fragmentação do datagrama, esta ID é COPIADA para cada fragmento É um conjunto de flags de fragmentação: BIT VALOR 0 DF MF O bit 0 é sempre 0. É reservado. DF = 0, datagrama pode ser fragmentado, = 1, o datagrama não pode ser fragmentado MF =0, sinaliza que este datagrama é o último de uma fragmentação; =1, sinaliza que há mais fragmentos em relação ao datagrama original. FRAGMENT OFFSET TIME TO LIVE é medido em unidades de 8 octetos (64 bits). O primeiro fragmento tem offset=0. Representa a posição do primeiro octeto de dados no pacote de referencia (original). Exemplo: Tamanho de dados de um datagrama é 1500 e seja necessário atravessar uma rede com MTU de 700. Primeiro fragmento contém 700 (OFFSET = zero), o segundo contém os próximos 700 (OFFSET = 700) e o último contém 100 (OFFSET = 1400) Este campo indica o tempo máximo de vida do datagrama tem para permanecer no sistema. Se contém um valor zero, então o datagrama deve ser destruído e 103

16 deve ser enviado para a origem do datagrama uma mensagem de erro. Este campo tem seu valor reduzido de pelo menos 1 unidade todas as vezes que for processado, mesmo que o tempo de processamento de roteamento seja inferior a 1 segundo. O TTL é um limite superior de tempo de vida de um datagrama. O objetivo é descartar o datagrama no caso dele não conseguir ser enviado para o destino. PROTOCOL HEADER CHECKSUM SOURCE IP ADDRESS DESTINATION IP ADDRESS IP OPTIONS Especifica o tipo do protocolo que contém os dados, conforme os valores definidos em RFC1700 ou mais atual (Assigned Numbers) Considerando este valor inicialmente zero, tratando o cabeçalho como uma seqüência de 16 bits. Ver RFCs 1071, 1624 e 1141 Endereço IP de origem Endereço IP de destino O campo IP OPTIONS tem um tamanho variável e depende das opções selecionadas. Algumas opções tem um tamanho de 1 octeto enquanto outras tem um tamanho variável. Quando as OPÇÕES IP estão presentes no datagrama, elas aparecem de forma contínua, sem qualquer separador entre elas. Cada opção consiste de um simples octeto que pode ser seguido por um ou mais octetos de dados daquela opção. O octeto de código de opções é dividido em 3 campos: BIT CAMPO CP CLASSE NÚMERO OPÇÃO CP É um flag que controla como os roteadores tratarão as opções durante a fragmentação. se CP =1 então o a opção deve ser copiada em todos os fragmentos, Se 0 (zero), então a opção é copiada somente para o primeiro fragmento. CLASSE DE OPÇÃO N.º da Opção N.º de octetos Descrição 104

17 variável 0 7 variável variável 2 4 variável Fim da lista de opções. Usado se as "opções" não terminarem no final do cabeçalho (Ver PADDING) Sem operação (usado para alinhamento dos octetos numa lista de opções). Restrições de segurança e tratamento (para aplicações militares) Roteamento livre. Usado para rotear um datagrama através de um caminho específico. Neste caso, a rota fornecida deve ser seguida, mas pode acontecer de existir alguns roteadores intermediários que não constam na lista. Registro de rota. Usado para traçar rota. (Obsoleto) Era usado em redes SATNET como um identificador. Roteamento forçado. Usado para rotear um datagrama através de um caminho especificado. Neste caso, o roteamento deve seguir a lista de rotas com rigor. Internet Timestamp. Usado para registrar os tempos dos roteamentos Um exemplo de campo de Opções: ROTEAMENTO Registro de rota livre - Cada roteador deve inserir seu IP na lista, após verificar se existe campo livre para isto, através dos campos de comprimento e do apontador. 105

18 Estas e outras opções podem ser encontradas com detalhes nas RFCs 760 e 791 PADDING DATA O campo PADDING é preenchido com ZEROS até completar os 32 bits quando o campo IP OPTIONS apresentar um tamanho inferior. O campo DATA possui o pacote do protocolo de transporte usado (UDP, TCP, ICMP, etc) Os campos IP OTIONS e PADDING não são necessários em todos os datagramas IP. 4.2 FRAGMENTAÇÃO E REMONTAGEM DOS DATAGRAMAS O tamanho de um datagrama depende da tecnologia empregada no meio físico. Uma rede Ethernet, por exemplo, limita o tamanho dos dados de um frame em 1500 octetos. Quando usando com um cabeçalho SNAP o padrão é 1492 octetos. Uma rede FDDI permite 4470 octetos de dados por frame. Estes limites são denominamos de MTU (Maximum Transfer Unit). Ao atravessar redes físicas diferentes com MTUs diferentes, o datagrama deve ser divido em partes ou fragmentos. O processo de dividir o datagrama é conhecido por FRAGMENTAÇÂO. 106

19 Uma vez que um datagrama foi fragmentado, os fragmentos continuarão isoladamente até o destino e será remontado lá (só no destino!) Na fragmentação, cada parte receberá um cabeçalho próprio, podendo conter campos do cabeçalho original e acrescido de informações que permitirão a sua remontagem. Estas informações consistem dos campos IDENTIFICATION, FRAGMENT OFFSET, e FLAGS bem definidos. Caso o flag de "não fragmentar" estiver definido (DF=1) e for necessário uma fragmentação, o datagrama é descartado e o remetente receberá uma mensagem de erro (normalmente via ICMP). 5 ROTEAMENTO IP Denominamos de ROTEAMENTO o mecanismo de escolha de um caminho usado para enviar pacotes. Roteador é um equipamento com capacidade de realizar esta função. Uma máquina pode ser um roteador. Encontramos, também roteadores dedicados. Como vimos, o datagrama IP contém em seu cabeçalho, dentre outras informações, o endereço IP de destino. Vimos, também, que um endereço IP pode ser desmembrado em um endereço de rede e endereço do nó naquela rede através da uma operação lógica envolvendo uma máscara. Vimos, ainda, que o cabeçalho de um frame encontramos os endereços físicos de um nó. O Roteamento IP é, portanto, o mecanismo utilizado para transferir datagramas IP entre interfaces após uma análise dos cabeçalhos destes datagramas selecionando um melhor caminho (sob algum aspecto). A implementação de roteamento se localiza na camada de rede. Sob este ponto de vista, qualquer máquina conectada à rede física estabelece algum tipo de roteamento. Vejamos o por quê! 5.1 ENVIO DIRETO Para definir Envio Direto, Comer (1995, Vol.1, página 111) resume: Ou seja, Transmission of an IP datagram between two machines on a single physical network does not involve routers. The sender encapsulates the datagram in a physical frame, binds the destination IP address to a physical hardware address, and sends the resulting frame directly to the destination. A transmissão de um datagrama IP entre 2 máquinas em uma única rede física não envolve roteadores. A máquina responsável pelo envio, encapsula o datagrama num frame físico, acopla o endereço IP de destino ao endereço físico do hardware, e envia o frame resultante diretamente para o destino. 107

20 Apesar de não ser um especialista de expressão como o Dr. Comer, que certamente explicaria esta afirmação de melhor modo que será apresentada aqui, gostaria de tecer alguns comentários sobre esta afirmação. Isto não é uma crítica! É apenas um ponto de vista. A afirmação do Dr. Comer é válida desde que naquela rede física exista apenas uma rede lógica IP e que o envio use recursos diretos da camada de interface. Vejamos o porquê. A grande maioria das máquinas com TCP/IP implementam algum algoritmo de roteamento baseado na rede de destino. O princípio básico do roteamento, neste caso, consiste na análise do endereço IP de destino (parcela de rede de destino) em relação ao endereço IP de origem (parcela de rede da origem). Caso estas partes resultem em valores diferentes, o datagrama IP deve ser enviado para um roteador. Assim, de uma forma genérica (qualquer tipo de roteamento) não basta só o compartilhamento da mesma rede física. É preciso uma condição mais ampla e a afirmação deve ser interpretada na forma: A transmissão de um datagrama IP entre 2 máquinas em uma única rede (física + lógica IP) não envolve roteadores. A máquina responsável pelo envio, encapsula o datagrama num frame físico, acopla o endereço IP de destino ao endereço físico do hardware, e envia o frame resultante diretamente para o destino. OBS: Uma aplicação que trabalha com acesso direto para envio em baixo nível (frame) estabelece um "by-pass" da pilha IP. Desta forma, a possibilidade de envio direto torna-se possível, mesmo em redes lógicas diferentes. As aplicações "normais" não são capazes disto pois estariam fazendo um by-pass na camada de rede e transporte. O protocolo ARP carrega os endereços físicos que pertencem à mesma rede física. A questão não está na montagem do frame, mas antes da montagem do datagrama IP para o envio. Assim, dispensar roteadores em redes lógicas diferentes em uma mesma rede física requer "truques" de máscara na inicialização de um sistema. Este "truque" era possível em sistemas mais antigos baseados no BSD4.2. O "truque" consiste na modificação da máscara de rede, em tempo de inicialização do sistema, para um valor tal que as duas redes lógicas diferentes possam ser consideradas uma única rede lógica, e depois, retornar a máscara para os valores "nominais" (padrão). Exemplo: Sejam as redes A e B com da classe C, e Em condições normais as máquinas de uma rede não são capazes de enviar um datagrama IP diretamente para máquinas de outra rede. Porém, modificando a máscara padrão para temporariamente, isto torna possível, pois estas duas redes teriam o mesmo IP de identificação de rede (em caso de dúvida rever item 2) Uma outra forma, bem mais simples, é explorar a capacidade de roteamento encontrado no TCP/IP, definindo a segunda rede lógica na Tabela de Roteamento. Neste caso todas as máquinas usam a capacidade de roteamento (tabelas), embora não possam agir como um roteador. Foi realizado alguns testes de envio direto. O teste consiste em estabelecer a conexão entre máquinas de redes lógicas diferentes que compartilham da mesma rede física em uso e roteadores externos. 108

21 Foram usadas máquinas com hardware semelhantes, compatível com o IBM-PC, executando Windows NT Server 4, Windows NT Workstation 4 (os dois com ServicePack 6a), e Linux (Kernel , distribuição RedHat). Todas as máquinas executavam somente o protocolo de rede TCP/IP. Um mesmo teste foi repetido para as várias combinações de Sistemas Operacionais. As condições de configuração para os testes estão resumidas no anexo deste capítulo. CONCLUSÕES DOS TESTES 1. O ARP não é usado para decisões de roteamento 2. O "envio direto" está sujeito ao procedimento que implementa algum roteamento interno. O envio direto, literalmente, só existe na conexão lógica entre as máquinas quando o roteamento interno contém informação adequada da tabela de rotas, quer seja por rota default ou de rede específica. No envio de um datagrama IP, o roteamento USA a tabela de ARP para a criação do frame, embora isto só ocorra depois de um roteamento interno. No recebimento, a interface reconhece o endereço MAC mas não é capaz de entregar o datagrama IP para a camada de rede. O envio direto sem roteadores (qualquer tipo) não é aplicável em condições normais (sem uso de rotas) ou seja, somente considerando a rede física. O roteamento IP interno existe e é o responsável pelo funcionamento adequado do TCP/IP no envio e recebimento de datagramas IP. Sem ele, o envio direto é impossível, exceto em aplicações especiais que pulam o roteamento IP. Portanto, se EXISTE roteamento interno então existe roteador interno e é usado tanto no recebimento quanto no envio de um datagrama IP (Os detalhes de como isto é implementado será discutido em CAP312), ou seja, qualquer máquina com TCP/IP contém algoritmos de roteamento e agem como um roteador interno. PROPOSTAS: 1) Isto é válido para outras implementações do TCP/IP (outros sistemas operacionais), tipo SunOS, OpenVMS com pilhas TCP/IP UCX e Multinet, AIX, HP-UX? 2) Uma aplicação para o "envio realmente direto", pulando o roteamento teria sucesso? 109

22 5.2 ENVIO INDIRETO O envio indireto resume no fato de exigir a identificação de um roteador para onde o datagrama deverá ser enviado. O roteador, então, redirecionará aquele datagrama para a rede de destino. Neste caso, como um roteador saberá para onde enviar o datagrama? 5.3 ROTEAMENTO IP POR TABELAS Também conhecida como Tabela de Roteamento Internet, este tipo de roteamento consiste na busca da rede de destino em tabelas de rotas, e está presente em hosts e em computadores "normais". Estas tabelas consistem de um número de rotas de, no mínimo, equivalente ao número de redes lógicas conectadas ao roteador. A tabela não armazena "todas as rotas possíveis" (host por host), apenas a parcela de identificação da rede do endereço IP dos nós daquele segmento lógico e as máscaras correspondentes, ou seja (rede por rede). Surge, daí, uma nova questão: Como as tabelas são criadas ou mantidas? A tabela de rotas é mantida manualmente (rota estática) ou através de protocolos especiais: RIP (Routing Information Protocol), BGP (Border Gateway Protocol), GGP (Gateway-To- Gateway Protocol), EGP (Exterior Gateway Protocol), OSPF (Open Shortest Path First); ou mesmo através de protocolo mais simples: ICMP (Internet Control Message Protocol). Cada um desses protocolos são específicos para certas situações. Não vamos entrar em detalhes de cada um destes protocolos. Estudaremos técnicas que permitirão analisar as especificações deles e casos de roteamento, cuja solução pode ser o uso de um ou um conjunto destes protocolos. No envio direto fizemos uma observação sobre o uso de tabelas quando temos duas (ou mais) redes lógicas numa mesma rede física. Conforme a afirmação do Dr. Comer, e os comentários seguintes, o envio direto torna-se possível sem uso de roteadores externos, mas com o uso da capacidade de roteamento embutida no TCP/IP em cada máquina, alimentando a tabela de rotas manualmente e usando o endereço IP da interface existente como gateway. Neste caso não estamos usando "roteadores externos", mas estamos usando o sistema de roteamento interno. Eis um relatório deste teste. 5.4 ROTEAMENTO TIPO "NEXT-HOP" A idéia consiste em enviar o datagrama para o roteadores conectados diretamente naquela rede. 110

23 O roteador R1 trabalha com as seguintes informações: Para alcançar nós na rede Enviar o datagrama para este endereço Enviar direto Enviar direto Ou seja, decidir caminhos usando somente a identificação da rede reduz o tamanho das tabelas e traz algumas conseqüências: 1. Todo o tráfego destinado para uma dada rede usa o mesmo caminho. Num caso onde existe um segundo caminho, eles não podem ser usados concorrentemente, mesmo que existam atrasos ou diferenças de velocidade do meio físico entre tais caminhos. 2. Somente o roteador final é capaz de enviar o datagrama diretamente para o host de destino e verificar se o host está operacional ou não. Neste caso, este roteador deve possuir mecanismos para avisar a origem do datagrama sobre eventuais problemas de conexão (se host de destino não existe ou não está operacional). Como veremos, este mecanismo pode ser estabelecido pelo protocolo ICMP. 3. Na presença de mais de uma rota, e neste caso elas não podem ser concorrentes, podemos ter caminhos diferentes para um datagrama enviado por um host A para um B e um datagrama enviado do host B para o host A. Assim, os roteadores devem garantir a comunicação nos dois sentidos. Olhando para a figura anterior, podemos questionar: Como fica a tabela dos roteadores R2 e R3? As máquinas das redes e apontam para onde? 111

24 5.5 ROTA PADRÃO A idéia é ter um software de roteamento que, primeiro, procure a rede de destino na tabela de rotas. Caso não a encontre, as rotinas de roteamento enviam o datagrama para uma porta do roteador padrão. Este roteador agirá da mesma forma. Ele buscará em suas tabelas de rotas a rede de destino. Caso não encontre o datagrama IP é enviado para o roteador posterior (ou o seu roteador padrão). Isto vai acontecer até que ou o datagrama alcance o seu destino ou seja descartado por algum roteador intermediário. Antes de descartar o datagrama este roteador enviará à origem do datagrama um "recado" dizendo que aquela rede ou nó não foi alcançado. Tal rota pode ser aprendida (propagada) através de protocolos tidos como protocolos de roteamento (RIP, RIP2, OSPF, BGP, etc). 5.6 ROTAS ESPECIFICAS DE HOSTS O uso de rotas baseando "por nó" dá um maior controle administrativo sobre o uso da rede, mas aumenta o tamanho das tabelas. Há alguns casos que este tipo de roteamento torna-se absolutamente necessário. É quando uma máquina (H1) estabelece o roteamento entre a rede física contínua e uma segunda máquina. Neste caso, a tabela de R1 será : 112

25 Para alcançar hosts na rede Enviar o datagrama para este endereço Enviar direto (interf ) Enviar direto (interf ) ROTEAMENTO ENVOLVENDO SUB-REDES E SUPER-REDES Até então, neste estudo de roteamento IP, consideramos as redes seguindo as respectivas classes (A, B, C). Contudo, ao considerar o roteamento entre sub-redes e super-redes, as informações constantes da tabela acima não são suficientes. A informação que falta é, justamente, a máscara da rede. No caso de um roteamento para um Host especifico, usamos a máscara de host ( ). A tabela de rotas deve ser escrita, na forma: Para alcançar hosts na rede Net-IPd Máscara de Rede NETMASK Enviar o datagrama para este endereço (hop) Enviar direto Enviar direto Enviar direto Enviar direto 113

26 Para o roteamento é OBSERVADO o endereço IP do destino. Vamos entender este OBSERVADO. Digamos que uma máquina da rede (M-50-22) queira enviar um datagrama IP para a máquina (M ). Vamos viajar com este pacote para entendermos como isto "funciona". A tabela acima é propagada de alguma forma (protocolo RIP, por exemplo) para todas as redes diretamente conectadas à R-1. A máquina M faz parte da rede , que recebe esta informação e armazena em sua memória. Agora ela quer enviar um pacote para M Ao consultar a tabela, ela reconhece que o datagrama IP deve seguir para o roteador R-1. Imaginemos o seguinte diálogo de laboratório: Qual endereço IP de destino ela vai inserir no datagrama IP? É o endereço de destino do pacote! De M ( ). Como ela enviará para o destino se ela não sabe onde isto fica? Uma das formas, sem ajuda de outros protocolos, é o envio do pacote para a rede (lembram do ARP?) com endereço de broadcast num frame (que carregará aquele datagrama). Ou seja TODAS as máquinas vão ler o frame. Uma oura forma é questionar "quem tem o endereço ethernet de M ?" Neste caso a resposta não será atendida pois a máquina M está muito além dos roteador R-1. Mas R-1 tem uma interface na mesma rede física de M Ele também recebe o datagrama IP encapsulado num frame com endereço ethernet de destino contendo um valor de broadcast. Ele, R-1, não sabe interpretar o Ethernet, mas sim o IP. Então, R-1, leva o pacote para a camada IP e identifica o destino (M ). Será que ele, R-1, possui informações sobre a rede ? Ele consulta sua tabela e lá está ela. No caso no terceiro registro. Para onde ele deve enviar? Pela tabela ele obtém o endereço E R-1 pergunta: " Eu, R-1, tenho a rota para ?". O software de roteamento responde: "Para a máquina não, mas para a rede sim! Pela tabela, basta enviar aquele datagrama diretamente para a interface correspondente à rede ". Caso ele saiba o endereço Ethernet da máquina então está resolvido! Basta inserir o datagrama IP, que veio de M-50-22, num frame contendo o endereço ethernet de destino de e enviar para a rede física (Envio direto). E se R-1 não sabe? Ele pergunta: "Quem tem o endereço de..." e aí ele fica sabendo (via ARP, lembram? está na mesma rede física que uma de suas interfaces). Este frame viaja 114

27 para e lá, em R-2, repete-se o procedimento (perguntas). Só que, agora, R-2 tem uma interface conectada diretamente à rede e a máquina de destino, cujo endereço consta no datagrama IP, faz parte de uma das redes físicas onde R-2 está conectado. Então, numa rede, o ARP de broadcast estará presente enquanto as máquinas que estabelecem uma comunicação não conhecerem TODOS os endereços (IP e MAC) da outra. O que? Isto gera tráfego demais, não? Sim! Gera! Mas reparem que é só para o primeiro datagrama IP. Até ele chegar ao destino pela "primeira vez". Quando houver uma resposta daquele datagrama ou seguir uma nova solicitação nenhuma pergunta será feita, pois são conhecidos os endereços (MAC e IP) dos roteadores e máquinas vizinhas usadas no envio e recebimento dos datagramas. Tudo isto pode ser observado quando usamos aplicações tipo TCPDUMP. Então? Gostaram da viagem? Mais uma perguntinha para não ficar, assim, no "vazio"!!!! E como é o procedimento de busca das rotas no roteamento? 5.8 ALGORITMO DE ROTEAMENTO Considerando tudo o que já foi visto até então, o algoritmo de roteamento IP é: ROTEAMENTOIP(DATAGRAMA, TABELA_DE_ROTAS) 1. EXTRAIR O ENDEREÇO IP DO DESTINATÁRIO, IPD, DO DATAGRAMA. 2. CALCULAR O NETID CORRESPONDENTE, NET-IPD USANDO MÁSCARA PADRÃO. 3. SE NET-IPD É IDENTICO AO ENDEREÇO DE ALGUMA REDE CONECTADA DIRETAMENTE AO ROTEADOR ENTÃO ENVIAR O DATAGRAMA PARA AQUELA REDE (ISTO REPRESENTA TRADUZIR O ENDEREÇO IP PARA O ENDEREÇO FÍSICO, ENCAPSULAR O DATAGRAMA NO FRAME E ENVIAR O FRAME) 4. SE A TABELA CONTÉM UMA ROTA ESPECIFICA PARA IPD ENTÃO ENVIAR O DATAGRAMA PARA O ENDEREÇO IP ESPECIFICADO NA TABELA 5. PARA CADA ENTRADA NA TABELA DE ROTAS FAÇA: I. CALCULAR, IPDM,FUNÇÃO LÓGICA AND ENTRE O IPD E A NETMASK II. SE IPDM É IGUAL AO CAMPO NET-IPD DA TABELA ENTÃO ENVIAR O DATAGRAMA PARA O IP ESPEFICIADO (OU DIRETAMENTE PARA A REDE) 6. SE NÃO FOR ENCONTRADO NENHUMA ROTA ENVIAR PARA A ROTEADOR PADRÃO (ROTA DEFAULT) 7. NÃO EXISTINDO ROTA DEFAULT DECLARAR ERRO DE ROTEAMENTO. Leituras recomendadas: RFC1009, RFC1102, RFC1104, RFC1124 e RFC

28 5.9 EXERCÍCIOS 1) Veja as rotas na tabela de seu computador usando o comando "route" (Unix). No Windows, comande "route print" para ver a tabela de rotas. 2) Faça um teste de roteamento envolvendo duas redes lógicas diferentes compartilhando uma mesma rede física. 6 PROTOCOLO ICMP Será que tudo está funcionando bem? Nenhum sistema funciona bem todo o tempo. Acontecem falhas de processamento, falhas nas linhas de comunicação, tráfego excessivo. etc. 6.1 FINALIDADE O ICMP (Internet Control Message Protocol) é um mecanismo de reportagem de erro que acontece entre uma máquina (nó ou roteador) e o nó de origem que tomará alguma ação corretiva. O ICMP não é considerado um protocolo de transporte, embora use o IP para alcançar um destino (o ICMP está encapsulado no IP), atravessando várias redes físicas. Conforme veremos, ele não apresenta um protocolo de portas, mas se tratarmos os campos TIPO + CÓDIGO como uma "espécie de protocolo de porta" (porta de destino) poderíamos considerá-lo como um protocolo de transporte realizando sua finalidade de suporte ao protocolo IP. O ICMP é necessário para que o IP funcione corretamente. 6.2 FORMATO DA MENSAGEM ICMP O cabeçalho ICMP tem um formato específico para cada tipo de mensagem. Contudo, todo cabeçalho tem os 3 primeiros campos com o mesmo tamanho em bits. Os valores dos dois primeiros campos definem o objetivo da mensagem ICMP. 116

29 CAMPO TIPO: Este campo define o objetivo da mensagem e o formato dos campos: "campo 1", "campo 2" e "campo 3". As RFCs 1122 (atualização) e 792 descrevem, em detalhes, os campos para cada um dos tipos citados. Os diagramas e as descrições serão revistas em detalhes no curso de programação (CAP312). Caramba! Este protocolo é do tipo "macabro"! Só leva/traz noticias ruins! (:((( Não! Nem tudo é terror (quando bem usado, evidentemente!). Através do ICMP é possível atualizar rotas e reconhecer o caminho feito por um datagrama IP até o destino final. Veja a tabela: VALOR DO CAMPO TIPO OBJETIVO DA MENSAGEM VALOR DO CAMPO CÓDIGO 0 Replicar Eco 0 0 Rede Não Alcançável 1 Nó Não Alcançável 2 Protocolo Não Alcançável 3 Porta Não Alcançável 4 É necessário Fragmentação e DF=1 5 Falha na Rota de origem 6 Rede de Destino Desconhecida 7 Nó de Destino Desconhecido 3 Destino Não Alcançável 8 Rota de Origem Isolada 9 Comunicação com a rede de destino está proibida administrativamente 10 Comunicação com o nó de destino está proibida administrativamente 11 Rede Não Alcançável para o TOS informado 12 Nó Não Alcançável para o TOS informado 4 Source Quench 0 (Ver RFC 896 e 1016) 5 Redirecionamento (mudança de rota) 0 Redirecionar Datagrama por Rede (obsoleto) 1 Redirecionar Datagrama por Nó 2 Redirecionar Datagrama por TOS e Rede 3 Redirecionar Datagrama por TOS e Nó 8 Requisitar Eco 0 Tempo do Datagrama 0 Contador TTL excedido 11 Excedeu 1 Tempo de remontagem de fragmento 117

30 excedido 0 O Apontador mostra o problema do 12 Problema de Parâmetros cabeçalho IP no Datagrama 1 Problema desconhecido com o Cabeçalho IP 13 Requisita Timestamp 0 (RFCs: 956, 967 e 1305) 14 Resposta de Timestamp 0 15 Requisita Informação (obsoleto) 16 Resposta de Informação (obsoleto) 17 Requisitar Endereço de Máscara usada 0 ( RFC 950) 18 Resposta da requisição do endereço de máscara 0 7 PROTOCOLO DE PORTAS Quando pressionamos o botão do mouse sobre um ícone numa janela, ou mesmo acionamos um programa digitando seu nome, é como se estivéssemos estabelecendo um canal de comunicação entre o computador e o operador. No caso de um ícone, por exemplo, não é óbvio a identificação do programa (nome do aplicativo) que será executado, mas a finalidade sim. (O objetivo é este!) Temos a impressão de que o ícone da aplicação está ali esperando para ser acionado, como uma porta para aquela aplicação. Em termos de protocolo de transporte TCP/IP, estamos associando "atividades" às portas de serviços, ou seja, estamos usando portas para identificar "um conjunto de atividades" num mesmo protocolo de transporte. Denominamos esta abstração de protocolo de portas. Da mesma forma que em um sistema "janelado" quando abrimos uma aplicação tipo "linha de comando" ela fica aguardando a entrada das instruções pelo teclado, as aplicações TCP/IP, com recursos disponíveis pelo Sistema Operacional, implementam o aceso às portas de forma síncrona. Ou seja, o S.O. bloqueia a execução daquela aplicação até que os pacotes cheguem. Normalmente as portas representam filas ou regiões temporárias de memória (buffers), porém os dados serão perdidos caso cheguem antes que um processo esteja pronto para recebe-los. Para reter tais pacotes, o software envia aqueles dados para uma porta específica (associada àquela uma aplicação) até que eles sejam extraídos. De uma forma mais técnica o protocolo de portas corresponde à filas de execução e cada fila representa uma atividade, ou uma aplicação, que processará os dados daquela fila. Assim, podemos ter 2 aplicações diferentes usando uma mesma porta, mas usando protocolos de transporte diferentes. 118

31 Para que seja possível uma resposta, é preciso conhecer a porta de onde partiu aquele dado, assim como o endereço IP. Assim, para que uma comunicação se estabeleça e a transferencia de dados ocorra, cada mensagem deve carregar as portas de destino e de origem. Os endereços de destino e de origem já estão embutidos no datagrama IP enquanto as portas nos cabeçalhos do protocolo de transporte. Sob um ponto de vista técnico, os protocolos de transporte UDP e TCP implementam o conceito de multiplexação e demultiplexação das aplicações baseado nas portas. Quando o protocolo de transporte (TCP ou UDP) recebe um datagrama, ele verifica se aquele número de porta está em uso (se existe alguma aplicação correspondente associada àquela porta). Caso exista ele envia o datagrama para aquela fila. Caso contrário, ele envia uma mensagem ICMP tipo "porta não alcançável" (port unreachable, ICMP campo=3, código=3) para o remetente e descarta o datagrama. No caso da fila estar cheia o pacote é, simplesmente, descartado. 8 PROTOCOLO UDP O protocolo UDP (User Datagram Protocol) usa o IP para transportar mensagens implementando, apenas, o recurso de portas. Ou seja, uma aplicação que usa UDP aceita toda a responsabilidade para manipular e controlar problemas de confiabilidade de envio, ordenação de pacotes, controle de duplicação, ou perda de conectividade. Normalmente, ao desenvolvermos alguma aplicação que usa o UDP testamo-la em um ambiente de rede local. Uma aplicação UDP aplicável para a grande rede (a Internet), deve implementar os mecanismos de controle e manipulação, caso contrário ela está sujeita à falhas. 8.1 FORMA DAS MENSAGENS UDP As mensagens UDP são denominadas datagramas de usuário (user datagram). Um datagrama UDP consiste de 2 partes: cabeçalho UDP e dados UDP. O cabeçalho UDP contém 4 campos onde são informadas as portas de origem e destino, o tamanho da mensagem e o checksum UDP, conforme a figura abaixo: 119