IP - Internet Protocol Histórico O protocolo internet (IP), definido e aprovado pelo DoD (Departamento de Defesa Americano), foi concebido para uso em sistemas de computação interconectados através de comutação de pacotes [RFC791] As primeiras redes a se utilizarem do IP foram a ArpaNET (Rede militar de pesquisa, financiada pela ARPA - Advanced Research Projects Agency) e a NSFNet (Rede acadêmica de pesquisa, financiada pela NSF - National Science Foundation). Como o pricipal objetivo da internet era manter a informação circulando entre os principais centros de conhecimento e os centros militares, mesmo em caso de guerra, o protocolo de rede deveria ser robusto e auto-configurável, garantindo alguma imunidade quanto à destruição das linhas de comunicação e/ou destes centros. A operação descentralizada é muito importante no sistema militar americano e esta característica foi obrigatoriamente incluída na ArpaNet. Por causa destas características desejadas, o método de comunicação na camada de rede escolhido deveria ser não orientado a conexão, e não confiável, refletindo completamente a situação de uma rede física em momentos críticos. A confiabilidade das informações deveria ser provida pelas aplicações ou por protocolos de camadas superiores, como o TCP. O Protocolo Internet criou então três definições importantes: Regras de funcionamento (Unreliable Delivery, etc.) Método de roteamento (Sem conexão) Formato dos dados em um datagrama Formato do Datagrama Falando em formato dos dados em um datagrama, vamos direto ao assunto. A figura abaixo mostra um mapa de bits que compõe o cabeçalho de um datagrama IP. Seu tamanho mínimo é de 20 bytes (5 longwords), mas pode variar em função das opções.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding Version o Identifica a versão do protocolo IP usada no datagrama. o Datagramas recebidos com versões não conhecidas devem ser simplesmente ignorados. o A versão atual é a 4, mas já está em discussão a implementação da versão 6 do IP, o IPNg. IHL o Header Length, comprimento do cabeçalho IP em múltiplos de 4 bytes. o O tamanho variável permite o uso de campos opcionais, mas dificulta o processamento. Por isso, seu uso deve ser evitado. Type of Service o Define a qualidade do serviço (QOS) desejada, mas... o É ignorado na maioria das implementações o Com o uso deste campo é possível escolher as prioridades de serviço para aplicações do tipo interativa, de transferência em massa ou de tempo real. Total Length o Tamanho total, em bytes, do datagrama (ou de um fragmento), incluindo o cabeçalho. o Todos os hosts devem aceitar datagramas de, pelo menos, 576 bytes. O valor máximo a ser usado numa sub-rede pode ser negociado entre os hosts. Identification
Flags Fragment Offset Time to Live o A cada nó (roteador) por onde o datagrama passa, este campo deve ser decrementado de uma unidade. o Os roteadores mais inteligentes podem decidir por decrementar um valor proporcional ao tempo despendido pelo datagrama em seus buffers. o Quando o valor do TTL chega a zero, o datagrama é descartado e uma mensagem enviada ao emissor, através do protocolo ICMP. o O objetivo de toda esta operação é evitar que um erro nas tabelas de roteamento permita que alguns datagramas fiquem circulando eternamente pela rede. Protocol o Identificador do protocolo usado na camada imediatamente acima. o Mais usados na internet: TCP: Stream confiável UDP: Datagrama com endereço de porta para usuário ICMP: Controle o Outros muito comuns: EGP: Roteamento TP4: Transporte classe 4 da ISO RDP: Reliable Datagram Protocol Header Checksum o Garante a integridade do cabeçalho IP. Caso haja erro o datagrama deve ser ignorado. o Não garante a integridade dos dados. Source Address o Endereço de origem do datagrama. Destination Address o Endereço destino do datagrama. Options o Este campo pode ser usado para usar serviços extras. Apesar do nome, todas as implementações de IP devem suportar todas as opções. o Alguns exemplos de opções válidas: Source Routing: Especifica no datagrama qual a rota a ser seguida, retirando esta liberdade do roteador. Em geral é usado para testes de rede. Record Route: Anota a rota por onde o datagrama passou, roteador por roteador. Time Stamps: Além de anotar a rota, anota também o horário em cada ponto. Formato: 32 bits, milisegundos após meia-noite, em relação a GMT.
Usado apenas como referência, uma vez que a sincronização de tempo entre os roteadores é muito difícil de ser realizada. Padding o Complemento sem uso, para garantir que o cabeçalho tem um tamanho múltiplo de 4 bytes. Comentários Analisando o sistema de roteamento IP do ponto de vista de uma estação, temos 3 casos particulares: 1. Loopback: Endereço 127.0.0.1 ou mesmo um dos endereços associados ao próprio emissor. o Neste caso, o datagrama não chega nem mesmo a sair da estação emissora, sendo conduzido internamente pelo sistema operacional. 2. Local: O endereço destino está localizado na mesma sub-rede que o emissor. Esta determinação pode ser feita através de uma comparação do netmask com os endereços envolvidos. o Neste caso, o datagrama deve ser enviado para o endereço físico (MAC Addr, no caso ethernet) do destinatário. 3. Remoto: O endereço deve ser acessado através de um roteador. o Neste caso, o datagrama deve ser enviado para o endereço físico do roteador, sem mexer no endereço lógico (IP Dest Addr), do destinatário. Temos então um problema: Como determinar qual roteador usar nas entregas remotas? Se só existir um roteador, o problema termina: basta mandar tudo que é desconhecido para ele. Este caso é chamado de rota default. Se existir mais de um roteador, então é necessário usar alguma forma de escolha. A mais comum é usar uma tabela de roteamento interna, com pares destinoroteador. A forma de construção desta tabela pode ser estática, através de uma configuração permanente, ou dinâmica, com o uso de um software de roteamento tipo o routed ou o gated. Outro problema existente se refere ao uso de endereços locais. Como determinar qual o endereço físico referente a um endereço lógico? Uma opção é encapsular o endereço físico dentro do endereço lógico. Essa opção é usada pela rede DecNet, da DEC. Outra forma, menos restritiva é usar uma tabela de conversão. Esta tabela de conversão pode ser fixa ou dinâmica. Uma tabela fixa é mais simples de implementar, mas torna proibitiva a interligação de novas máquinas. Cada modificação na rede ou na interface de uma das máquinas exigiria a atualização das bases de dados de todas as outras. Esse é um problema de complexidade exponencial, que deve ser evitado. Já a implementação dinâmica se baseia na determinação do endereço através de negociação entre as máquinas. Para redes com suporte a transmissão em broadcast, como a ethernet, foi criado o protocolo ARP, assunto do próximo capítulo. Copyright 1995 by Jonny
Fragmentação e remontagem Um datagrama IP pode ter um tamanho de até 65535 bytes. Por outro lado, o IP é um protocolo da camada de rede, que deve ser transportado por protocolos das camadas inferiores. O problema é que estes protocolos inferiores podem não suportar o transporte de datagramas deste tamanho. Um exemplo muito conhecido é o caso do IP sobre ethernet cujo quadro tem um tamanho máximo (MTU - Maximum Transmission Unit) de 1500 bytes. Neste caso, um recurso usado pelo IP (e por várias outros protocolos) é o da fragmentação (segmentação) e remontagem. O roteador negocia com os periféricos de rede e com o próximo roteador o tamanho máximo que pode ser usado naquela sub-rede. Datagramas com tamanhos maiores deverão ser então fragmentados. A operação de fragmentação consiste em quebrar os dados do datagrama em unidades transportáveis, copiar o cabeçalho para cada uma delas e finalmente enviar. Para que o receptor possa remontar o datagrama original, os campos Identification, Flags e Fragment Offset são usados. Cada datagrama IP enviado por uma máquina possui um Identification diferente. Quando o datagrama deve ser fragmentado, o valor deste campo se mantém o mesmo em cada fragmento. O campo Flags possui, em especial, 2 bits: o Do not Fragment, que informa que o datagrama não deve ser fragmentado. Se não for possível transportar sem essa operação, deve ser descartado pelo roteador. Essa opção pode ser usada para se determinar o tamanho máximo que pode ser transportado por uma rede. Caso o roteador resolva descartar o datagrama, deve informar o emissor através de ICMP. o More Fragments, que indica a existência de mais fragmentos após a posição deste. Ou seja, se este bit não estiver setado, este é o último fragmento da cadeia. O campo Offset determina a posição relativa deste fragmento em relação ao datagrama original. Como o campo Flags consumiu 3 bits (um é reservado), este campo é utilizado sempre em múltiplos de 8. Com estes dados, é possível, sempre que necessário, se fragmentar um datagrama de tamanho excessivo em pedaços menores, suportados pela rede, e remontá-lo completamente no seu destino. Cabe lembrar que, por motivos de desempenho dos roteadores, é função única e exclusiva do receptor a reconstrução do datagrama. Copyright 1995 by Jonny