Implementação do protocolo IPv6 na RedeRio

Escrito por Alexandre Urtado de Assis e Nilton Alves Jr.

3. Formatação do Protocolo IPv6

Nesta versão 6 do protocolo IP, foram feitas algumas mudanças no formato do Datagrama IPv6 e de seu cabeçalho. Também foram criados cabeçalhos de extensão independentes do cabeçalho base, característica que permite que o cabeçalho base possua tamanho fixo. Nesta seção veremos a estrutura do Datagrama IPv6, o formato de seu cabeçalho base e ainda as características de cada cabeçalho de extensão.

3.1. Formato do Datagrama

A forma geral de um Datagrama IPv6 possui o cabeçalho base, seguido por zero ou mais cabeçalhos de extensão e por fim pelos dados.

Datagrama IPv6 – com cabeçalhos de extensão.

Caso não haja nenhum cabeçalho de extensão, o cabeçalho base é diretamente seguido pela área de dados.

Datagrama IPv6 – sem cabeçalhos de extensão.

As estruturas ilustradas acima não estão em escala. Em particular, os cabeçalhos de extensão não têm o mesmo tamanho e podem ser menores ou maiores que o cabeçalho base. Além disso, geralmente a área de dados é muito maior que o conjunto cabeçalho base e cabeçalhos de extensão.

3.2. Formato do cabeçalho base

O cabeçalho base do IPv6 é muito maior que o do IPv4, em decorrência do tamanho dos endereços de origem e de destino, porém, ele é mais simplificado que o cabeçalho IPv4, pois ele possui menos campos e informações. Esta simplificação o torna mais eficiente, pois ajuda a reduzir o processamento nos roteadores. Outra característica importante do cabeçalho base do IPv6 é que ele tem o tamanho fixo de 40 bytes, diferentemente do cabeçalho IPv4 onde seu tamanho não é fixo. Na figura a seguir é mostrada a estrutura do cabeçalho Base IPv6.

Formato do cabeçalho Base IPv6.

O primeiro campo no Cabeçalho Base do IPv6 é o campo VERSION ou versão de protocolo. Este campo possui 4 bits assim como no IPv4 e contém o número 6 para indicar o protocolo IPv6, assim como o número 4 indica o IPv4. Existem outras opções para este campo que podem ser vistas na RFC 1770.

O segundo campo é o TRAFFIC CLASS ou prioridade. Este campo tem 8 bits e é similar ao campo Type of Service – ToS? no IPv4. Esse campo classifica o pacote com uma classe de serviço ou prioridade, que pode ser usado para diferenciar serviços. Sua funcionalidade é similar no IPv4 e no IPv6.

O campo FLOW LABEL não existia no IPv4. Este campo tem 20 bits e foi criado para marcar pacotes de um específico fluxo, com o objetivo de diferenciar esses pacotes na camada de rede. Portanto o campo FLOW LABEL habilita uma identificação de fluxo e um processo por fluxo em cada roteador no caminho do pacote. Com esse rótulo o roteador pode identificar o tipo de fluxo de cada pacote, sem que precise verificar sua aplicação. Esse campo permite que a diferenciação no tráfego seja feita na camada de rede, facilitando a pratica de QoS – Quality of Service.

O campo PAYLOAD LENGTH é similar ao campo TOTAL LENGTH do IPv4. Ele tem 16 bits e indica o tamanho total da área de dados do pacote. No cabeçalho base IPv6 não existe o campo HEADER LENGTH, justamente por que ele tem tamanho fixo.

O campo NEXT HEADER é similar ao campo PROTOCOL do IPv4. Ele tem 8 bits e o valor deste campo indica o tipo de informação que segue o cabeçalho base do IPv6. Essa informação pode ser o protocolo usado na camada de transporte, UDP – User Datagram Protocol ou TCP – Transmission Control Protocol, ou um cabeçalho de extensão.

O campo HOP LIMIT é similar ao campo TTL – TIME TO LIVE do IPv4. Ele tem 8 bits e o valor deste campo especifica o número máximo de roteadores (hops) que um pacote IPv6 pode passar antes de ser descartado. Em cada roteador esse valor é decrementado e por esta razão não existe CHECKSUM (código detector de erro do cabeçalho IP) no cabeçalho IPv6, para que não seja necessário que cada roteador recalcule o valor do CHECKSUM em cada pacote.

Os dois últimos campos SOURCE ADDRESS e DESTINATION ADDRESS, que indicam respectivamente endereços de origem e destino, são similares ao IPv4 a não ser pelo tamanho destes campos. No IPv4 esses campos tinham 32 bits e agora devido ao aumento do tamanho dos endereços do Protocolo IP esses campos possuem 128 bits.

3.3. Cabeçalhos de extensão

Além do cabeçalho Base do IPv6, o datagrama IPv6 pode opcionalmente ser seguido por cabeçalhos de extensão, como mostra a figura 1. Não há um número fixo de cabeçalhos de extensão no datagrama IPv6. Diferentemente do cabeçalho base, os de extensão não tem tamanho fixo, podem variar de acordo com o tipo de cabeçalho de extensão ou um mesmo tipo de cabeçalho pode variar de tamanho. Para isso eles possuem o campo EXTENSION HEADER LENGTH que indica seu tamanho.

O outro campo fixo dos cabeçalhos de extensão é o NEXT HEADER, similar ao do cabeçalho base. Nele é identificado qual o tipo de cabeçalho que o seguirá, através de seu valor. Ao final do último cabeçalho de Extensão, o campo NEXT HEADER indica o protocolo da camada de transporte que é usado neste pacote. Na próxima figura é mostrada a estrutura dos cabeçalhos de extensão.

Formato dos cabeçalhos de Extensão do IPv6.

Existem muitos tipos de cabeçalhos de extensão e cada um deles tem um valor associado. Quando são usados mais de um em um mesmo pacote, eles geralmente respeitam a ordem que segue, porém os nós estão preparados para receber em qualquer ordem:

• HOP BY HOP OPITIONS HEADER (valor = 0): É usado para transportar informação opcional ou adicional que deve ser processada por todos os nós no caminho do pacote. Quando presente ele sempre vem em seguida do cabeçalho base do IPv6.

• DESTINATION OPTIONS HEADER (valor = 60): Esse cabeçalho é usado para transportar informação opcional ou adicional que deve ser analisada somente pelo destino do pacote.Ele geralmente é usado seguindo o cabeçalho de extensão HOP BY HOP OPITIONS HEADER, sendo analisado somente pelo destino.

Os cabeçalhos de HOP-BY-HOP OPTIONS e DESTINATION OPTIONS têm o mesmo formato. Eles foram projetados para reunir várias informações isoladas e simples que não necessitam de mais um cabeçalho de extensão.

Formato dos cabeçalhos de Extensão Hop by Hop Options e Destination Options

A parte do cabeçalho que segue o campo HEADER EXTENSION LENGHT é dividida da seguinte forma, como mostra a tabela abaixo:

Opções dos cabeçalhos de Extensão Hop by Hop Options e Destination Options.

O campo TYPE indica o tipo de opção. Caso essa opção contenha dados, o tamanho dos dados é indicado no campo LENGHT e os dados ficam no campo VALUE. Os 5 bits de mais baixa ordem em TYPE indicam a opção, enquanto o terceiro bit de mais alta ordem indica se os dados dessa opção podem mudar durante o trajeto do pacote. Caso essa opção não seja conhecida por algum nó durante o caminho do pacote, os dois bits de mais alta ordem indicam a ação a ser tomada, conforme é mostrado abaixo:

00 Ignore esta opção, continue o processamento dos cabeçalhos
01 Descarte o datagrama, mas não envie mensagem ICMP
10 Descarte o datagrama e envie mensagem ICMP para a origem
11 Descarte o datagrama e envie mensagem ICMP para a origem somente se o destino não for um endereço multicast

• ROUTING HEADER (valor = 43): Esse cabeçalho é usado pela origem para listar um ou mais nós intermediários que devem ser visitados até o pacote chegar ao destino. Esse tipo de roteamento é utilizado quando existem mais de uma opção de caminho para os pacotes. Desta forma a origem pode traçar um caminho alternativo, mesmo que ele não seja o caminho indicado pelos protocolos de roteamento. Alternativamente esse cabeçalho de Extensão pode ser seguido por um outro do tipo DESTINATION OPTIONS HEADER. Neste caso esse cabeçalho de opções é processado por cada nó intermediário visitado.

O cabeçalho de roteamento contém uma lista de um ou mais nós que devem ser visitados no caminho para o destino. Os cabeçalhos de roteamento sempre começam com um bloco de 32 bits divididos em 4 campos de 8 bits cada, como mostra a figura:

Formato do cabeçalho de Extensão Routing Header.

O campo NEXT HEADER de 8 bits identifica o próximo cabeçalho. O campo HEADER EXTENSION LENGTH de 8 bits indica o tamanho do cabeçalho em unidades de 64 bits. O campo ROUTING TYPE, também de 8 bits, identifica um tipo de roteamento, caso esse tipo de roteamento não seja suportado por algum nó no caminho, o pacote deve ser descartado. SEGMENTS LEFT de 8 bits indica o número de nós intermediá rios, listados explicitamente, que devem ainda ser visitados antes da chegada do pacote ao destino.

O tipo mais comum de ROUTING HEADER é o zero, onde o campo ROUTING TYPE indica “0”. Neste caso além dos 32 bits do cabeçalho de roteamento, esse tipo 0 de cabeçalho de roteamento foi definido com mais 8 bits reservados e 24 bits de STRICT/LOOSE BIT MAP. Esses bits são numerados da esquerda para a direita, sendo que cada um corresponde a um HOP, indicando se o próximo destino deve ser um vizinho deste, 1 = strict, ou não, 0 = loose.

Formato do cabeçalho de Extensão Routing Header tipo 0.

Quando se usa o roteamento de tipo 0, a origem não precisa informar separadamente o destino do datagrama, pois ele é considerado como sendo o último endereço listado no cabeçalho de roteamento, o campo ADDRESS [N] da figura acima, sendo que o cabeçalho base do IPv6 tem como destino o primeiro endereço listado no cabeçalho de roteamento. Até que esse nó seja atingido, o cabeçalho de roteamento não é examinado pelos roteadores do caminho. Quando o nó é alcançado o cabeçalho de roteamento é examinado e o próximo nó listado é colocado no cabeçalho base. O datagrama então é enviado com o campo SEGMENTS LEFT decrementado.

• FRAGMENT HEADER (valor = 44): Esse cabeçalho é usado quando o pacote a ser enviado é maior que o MTU – Maximum Transmission Unit do caminho até o destino. Neste caso é necessário que tal pacote seja fragmentado na origem, pois diferentemente do IPv4, nessa versão os roteadores não suportam fragmentação. Desta forma a origem divide o pacote em diversos fragmentos, sendo que cada fragmento possui um cabeçalho base seguido de pelo menos um de Extensão do tipo FRAGMENT HEADER. Esse cabeçalho de Extensão é somente processado no destino, onde eles são concatenados e transformados no pacote que os originaram.

Para esta operação, a origem realiza um Path MTU discovery, procedimento de descoberta do tamanho máximo de pacote que poderá trafegar entre a origem e o destino, a fim de identificá- lo. Assim, basta fragmentar o datagrama de tal modo que ele passe por todos as redes no caminho até seu destino.

Cada fragmento deve ser múltiplo de 8 octetos e cada FRAGMENT HEADER indica se existem outros fragmentos do mesmo dado ou não. A próxima figura mostra esse cabeçalho.

Formato do cabeçalho de Extensão Fragment Header.

O campo NEXT HEADER de 8 bits indica o próximo cabeçalho. O campo RESERVED de 8 bits e o campo RES de 2 bits são reservados para o futuro. Já o campo FRAGMENT OFFSET de 13 bits indica a posição original deste fragmento no pacote original. O campo mais a direita é o MFLAG de 1 bit e indica se existem mais fragmentos, no caso afirmativo vale “1”, se é o último vale “0”. O campo IDENTIFICATION tem 32 bits e é a identificação do pacote original. Ela deve ser única em toda a Internet enquanto o pacote estiver trafegando.

Um problema gerado por esse tipo de fragmentação fim-a-fim, onde nós intermediários não podem fragmentar, é que se a rota mudar no meio da transmissão e o novo MTU for menor que aquele já descoberto, alguma coisa precisaria ser feita. O que acontece é que o datagrama IPv6 não é modificado, mas um datagrama novo é montado com o outro sendo encarado como dado. Assim, ele pode ser fragmentado e remontado fora da origem, isto é, em um nó entre a origem e o destino.

AUTHENTICATION HEADER (valor = 51): Esse cabeçalho é usado dentro do serviço IPSec - IP Security Protocol para prover autenticação e garantia de integridade aos pacotes IPv6. Esse cabeçalho é idêntico no IPv4 e no IPv6.

A autenticação é provida por um cabeçalho de extensão que suporta a integridade e autenticação dos dados de um pacote IP. Esse cabeçalho de extensão pode ser visto na figura a seguir.

Formato do cabeçalho de Extensão Authentication Header.

O campo NEXT HEADER de 8 bits identifica o próximo cabeçalho. O campo LENGTH de 8 bits indica o tamanho do campo de dados em palavras de 32 bits. O campo RESERVED de 16 bits é reservado para uso futuro. O campo SECURITY PARAMETERS INDEX tem 32 bits e identifica uma associação de segurança. E o campo AUTHENTICATION DATA tem tamanho variável e contêm os dados, em palavras de 32 bits.
O que o campo de dados representará vai depender do algorítmo de autenticação usado, mas no geral este campo é calculado com base em todo o datagrama, excluindo campos que mudem durante sua rota. No cálculo, esses campos são encarados como seqüências de bits “0”. Os cabeçalhos de fragmentação podem ser incluídos nesse cálculo.

• ENCAPSULATING SECURITY PAYLOAD HEADER (valor = 50): Esse cabeçalho é também utilizado dentro do IPSec para providenciar autenticação e garantia de integridade aos pacotes IPv6. Da mesma forma esse cabeçalho é idêntico no IPv4 e no IPv6.

• IPV6 ENCRYPTION HEADER: É usado para providenciar confidencialidade e integridade através da encriptação de dados.

• UPPER-LAYER HEADER: Indica o protocolo da camada de transporte que será usado. Para um pacote com protocolo de camada de transporte TCP, o campo NEXT HEADER do último cabeçalho de extensão recebe o valor 6 e para o protocolo UDP recebe o valor 17.

Última atualização 17/10/2008 21h20

   Licença:  Creative Commons Atribuição 2.5 Brasil (salvo seja especificada outra)     Válido:  XHTML 1.0 -  CSS 3