{"id":456,"date":"2013-05-30T05:09:03","date_gmt":"2013-05-30T08:09:03","guid":{"rendered":"http:\/\/www.viazap.com.br\/?p=456"},"modified":"2013-05-30T05:09:03","modified_gmt":"2013-05-30T08:09:03","slug":"datagramas-ip-protocolo-internet","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=456","title":{"rendered":"Datagramas IP (Protocolo Internet)"},"content":{"rendered":"\n\n\n\n\n
Datagrama IPv4<\/b><\/p>\n
Um datagrama IP, consiste de duas partes: cabe\u00e7alho e o campo de dados que transporta o IP de origem e o IP de destino.<\/p>\n

O cabe\u00e7alho possui uma parte fixa de 20 bytes e um campo “Options” de tamanho vari\u00e1vel. O formato do datagrama IPv4 \u00e9 mostrado na figura abaixo:<\/p>\n

\"\"<\/div>\n

O campo “Version”, armazena a vers\u00e3o do protocolo a que o datagrama pertence, na vers\u00e3o 4 possui tamanho de 4 bits (0100).<\/p>\n

O segundo campo, de quatro bits, \u00e9 o “IHL” (acr\u00f4nimo para Internet Header Length, ou seja, Comprimento do Cabe\u00e7alho da Internet), com o n\u00famero de palavras de 32 bits no cabe\u00e7alho IPv4.<\/p>\n

Como o cabe\u00e7alho IPv4 pode conter um n\u00famero vari\u00e1vel de op\u00e7\u00f5es, este campo essencialmente especifica o offset<\/em> para a por\u00e7\u00e3o de dados de um datagrama IPv4.<\/p>\n

O campo “Type of service”, representa os 8 bits seguintes. A inten\u00e7\u00e3o original era para um n\u00f3 (roteador) especificar uma prefer\u00eancia para como os datagramas poderiam ser manuseados assim que circulariam pela rede. Na pr\u00e1tica, o campo ToS n\u00e3o foi largamente implementado.<\/p>\n

O campo “Total Length” \u00e9 o campo seguinte de dezesseis bits do IPv4, define todo o tamanho do datagrama, incluindo cabe\u00e7alho e dados, em bytes de oito bits. O datagrama de tamanho m\u00ednimo \u00e9 de vinte bytes, e o m\u00e1ximo \u00e9 64 Kb.<\/p>\n

O tamanho m\u00e1ximo do datagrama que qualquer n\u00f3 requer para estar apto para manusear s\u00e3o 576 bytes, mas os roteadores mais modernos manuseiam pacotes bem maiores.<\/p>\n

O campo “Identification” \u00e9 um campo de identifica\u00e7\u00e3o de 16 bits. Este campo \u00e9 usado principalmente para identificar fragmentos identificativos do datagrama IP original.<\/p>\n

Flags<\/em> \u2192 O campo \u00e9 utilizado para identificar e controlar fragmentos, o campo \u00e9 composto por tr\u00eas (3) bits.<\/p>\n

Offset<\/em> \u2192 O campo \u00e9 constitu\u00eddo por 13 (treze) bits, o offset permite que o receptor do datagrama determine o local do fragmento do pacote IP original.<\/p>\n

TTL<\/em> \u2192 O campo (time to live) ou tempo de vida do pacote, \u00e9 composto por oito (8 bits), o campo tem a funcionalidade de evitar que o pacote fique percorrendo em loop sem encontrar o destino final, evitando que o datagrama IP persista. Sem o campo TTL, ter\u00edamos muitas requisi\u00e7\u00f5es na rede mundial (Internet), o que causaria uma enorme lentid\u00e3o da rede (delay), ou at\u00e9 mesmo, o travamento de alguns dispositivos de borda (roteadores ). O campo TTL limita a vida \u00fatil do pacote em segundos, onde cada roteador que o datagrama atravessa, \u00e9 decrementado o valor do TTL que se inicia no n\u00famero cento e vinte e oito (128), quando o valor chega a 0 (zero), o pacote \u00e9 descartado, o TTL \u00e9 considerado como uma contagem de hops (saltos).<\/p>\n

Protocol<\/em> \u2192 O campo \u00e9 constitu\u00eddo por oito (8) bits, \u00e9 neste campo que \u00e9 realizado a defini\u00e7\u00e3o de qual \u00e9 o protocolo usado na por\u00e7\u00e3o de dados de um pacote IP. Existe a possibilidade de ser o TCP, mas h\u00e1 tamb\u00e9m o UDP e outros. A numera\u00e7\u00e3o que se aplica a todos protocolos da Internet \u00e9 definida na RFC 1700.<\/p>\n

Checksum<\/em> \u2192 O campo \u00e9 respons\u00e1vel por detectar inconsist\u00eancia no datagrama IP, realizando uma checagem c\u00edclica de todos os campos de um datagrama e identificar se nos HOPS (saltos), onde o datagrama percorreu, se n\u00e3o houve nenhuma falha.<\/p>\n

Um pacote em tr\u00e2nsito \u00e9 alterado por cada ponto (roteador) na rede por onde passa, e um destes pontos pode comprometer a integridade do pacote e o campo checksum \u00e9 uma forma mais simples de detectar falhas no pacote IPv4.<\/p>\n

Endere\u00e7o de origem e destino<\/em> \u2192 O campo \u00e9 respons\u00e1vel em trafegar os endere\u00e7os IPv4 de origem e destino composto por 32 bits cada, segmentado em quatro octetos de oito bits. No caso do IPv6, o campo \u00e9 composto por 128 bits cada endere\u00e7o.<\/p>\n

A seguir, mostrarei as especifica\u00e7\u00f5es do novo datagrama IPv6 e comentar as mudan\u00e7as.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n

Datagrama IPv6<\/b><\/p>\n
Como vimos, o cabe\u00e7alho IPv4 \u00e9 composto por 12 campos fixos, respons\u00e1veis por fazer com que o tamanho varie de 20 a 60 Bytes. Nesta se\u00e7\u00e3o, veremos as novas especifica\u00e7\u00f5es do datagrama vers\u00e3o 6, que possui um total de apenas oito campos (incluindo source e destination address) e um valor fixo de 40 bytes para o cabe\u00e7alho.<\/p>\n

Sendo assim, ele ficou mais flex\u00edvel e eficiente com a adi\u00e7\u00e3o de cabe\u00e7alhos de extens\u00e3o que n\u00e3o precisam ser processados por roteadores intermedi\u00e1rios. A nova vers\u00e3o do datagrama IPv6 ficou assim:<\/p>\n

\"\"<\/a><\/div>\n

Assim, o cabe\u00e7alho IPv6 ficou dividido nos seguintes campos:<\/p>\n

* O campo “Vers\u00e3o”, possui 4 bits representando a vers\u00e3o do datagrama 0110.<\/p>\n

    \n
  • Traffic Class (8 bits) \u2192 Esse campo \u00e9 respons\u00e1vel por distinguir os pacotes que podem ter o controle de fluxo alterado. Na pr\u00e1tica, funcionaria da seguinte forma: os campos com valores menores teriam a sua velocidade mais reduzida, ou seja, sofreriam um maior retardo diante de um congestionamento do que os datagramas com valores maiores que s\u00e3o destinados ao tr\u00e1fego em tempo real. O \u00e1udio e video fazem parte dessa \u00faltima categoria.<\/li>\n
  • Flow label (24 bits) \u2192 Permite com que se realize um fluxo de pacotes entre dois hosts com caracter\u00edsticas especiais, utilizando um identificador atribu\u00eddo a ele. Em termos pr\u00e1ticos, seria conseguir realizar uma pseudo-conex\u00e3o baseada em circuitos virtuais.<\/li>\n
  • Payload Length (16 bits) \u2192 Tamanho, em bytes do datagrama com exce\u00e7\u00e3o do cabe\u00e7alho que possui 40 bytes, ou seja, o tamanho total do bloco de dados (source address e destination address). Lembrando que os cabe\u00e7alhos de extens\u00e3o, quando inseridos no datagrama, fazem parte dessa contagem.<\/li>\n
  • Next Header (8 bits) \u2192 Caso seja o \u00faltimo cabe\u00e7alho, identifica qual o protocolo da camada de transporte ser\u00e1 utilizado para transmiss\u00e3o dos pacotes (TCP\/UDP e outros), caso contr\u00e1rio, qual dos seis cabe\u00e7alhos de extens\u00e3o ser\u00e3o anexados ao datagrama.<\/li>\n
  • Hop Limit (8 bits) \u2192 N\u00famero m\u00e1ximo de saltos (roteadores) que um pacote pode ter para caso haja algum erro nas tabelas de roteamento, por exemplo. A cada hop (salto), o valor desse campo vai ser subtra\u00eddo por 1 bit, caso atinja o valor 0 (zero), ser\u00e1 descartado.<\/li>\n
  • Source Address (128 bits) \u2192 Endere\u00e7o de origem do datagrama.<\/li>\n
  • Destination Address (128 bits) \u2192 Endere\u00e7o de destino do datagrama.<\/li>\n<\/ul>\n

    Gostaria de enfatizar algumas funcionalidades dos campos Traffic Class e Flow Label.<\/p>\n

    \u201c Os campos Priority (Traffic Class) e Flow Label, t\u00eam por finalidade, a facilita\u00e7\u00e3o de implementa\u00e7\u00e3o de aplica\u00e7\u00f5es em tempo real e com Qualidade de Servi\u00e7o (QoS).<\/p>\n

    O primeiro determina a prioridade que um pacote ou grupo destes deve receber. Deve-se utilizar valores de 0 a 7 para aqueles que podem sofrer atraso, como por exemplo, aplica\u00e7\u00f5es de FTP e HTTP; e valores de 8 a 15 para aqueles com tr\u00e1fico em tempo real, que n\u00e3o devem ser atrasados, como aplica\u00e7\u00f5es de v\u00eddeo e sons.<\/p>\n

    J\u00e1 o segundo campo, ainda em fase experimental, permitir\u00e1 que dois hosts estabele\u00e7am uma pseudo-conex\u00e3o (circuitos virtuais) com caracter\u00edsticas espec\u00edficas. Esta conex\u00e3o ser\u00e1 unicamente identificada pelos endere\u00e7os IP de envio e destino e pelo valor do campo Flow Label.<\/p>\n

    Deste modo, ser\u00e1 poss\u00edvel prover tratamento diferenciado para diferentes fluxos, de acordo com as necessidades de cada um. \u201d<\/p><\/blockquote>\n

    [Tanenbaum, 1997]<\/p>\n

    Cabe\u00e7alhos de extens\u00e3o<\/h1>\n

    Diferente do IPv4, que inclui no cabe\u00e7alho base todas as informa\u00e7\u00f5es opcionais, o IPv6 trata essas informa\u00e7\u00f5es atrav\u00e9s dos cabe\u00e7alhos de extens\u00e3o.<\/p>\n

    As novas especifica\u00e7\u00f5es do IPv6 definem seis cabe\u00e7alhos de extens\u00e3o:<\/p>\n

      \n
    1. Hop-by-Hop Options<\/li>\n
    2. Destination Options<\/li>\n
    3. Routing<\/li>\n
    4. Fragmentation<\/li>\n
    5. Authentication Header<\/li>\n
    6. Encapsulating Security Payload<\/li>\n<\/ol>\n

      A cria\u00e7\u00e3o dos cabe\u00e7alhos de extens\u00e3o do IPv6, teve a finalidade de aumentar a velocidade de processamento nos roteadores. De acordo com a necessidade, novos tipos de cabe\u00e7alho de extens\u00e3o podem ser criados, permitindo assim, maior flexibilidade na adi\u00e7\u00e3o de mais op\u00e7\u00f5es no futuro. Isto permitir\u00e1 que o protocolo evolua, dentro de certos limites, \u00e0 medida que haja necessidade.<\/p>\n

      Na pr\u00f3xima se\u00e7\u00e3o, veremos mais detalhes com rela\u00e7\u00e3o aos cabe\u00e7alhos de extens\u00e3o.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n

Cabe\u00e7alhos de extens\u00e3o<\/b><\/p>\n
Antes de iniciarmos a se\u00e7\u00e3o sobre cabe\u00e7alhos de extens\u00e3o, \u00e9 importante analisarmos o formato e a l\u00f3gica com que eles foram organizados.<\/p>\n

Primeiramente, estes cabe\u00e7alhos devem ser transportados segundo uma ordem com o objetivo de evitar que os n\u00f3s (roteadores) intermedi\u00e1rios tenham que analisar toda a cadeia de cabe\u00e7alhos, para decidir quais cabe\u00e7alhos devem processar.<\/p>\n

Desta forma, os cabe\u00e7alhos mais importantes para o roteamento (n\u00f3s intermedi\u00e1rios), devem ser colocados antes daqueles cabe\u00e7alhos que s\u00e3o importantes apenas para os destinat\u00e1rios.<\/p>\n

A grande vantagem em termos de desempenho, \u00e9 que os roteadores intermedi\u00e1rios podem parar de processar os cabe\u00e7alhos do datagrama assim que encontrar algum cabe\u00e7alho de extens\u00e3o encaminhado ao destinat\u00e1rio, com exce\u00e7\u00e3o das informa\u00e7\u00f5es do cabe\u00e7alho de extens\u00e3o hop-by- hop<\/em>, que como veremos a seguir, devem ser analisados por todos roteadores intermedi\u00e1rios, caso este cabe\u00e7alho de extens\u00e3o esteja presente.<\/p>\n

Atualmente, h\u00e1 seis tipos de cabe\u00e7alhos de extens\u00e3o, todos eles s\u00e3o opcionais, mas, se houver mais de um deles, eles aparecer\u00e3o imediatamente depois do cabe\u00e7alho fixo e, na ordem listada:<\/p>\n