Nesta seção, serão apresentadas as principais características do IPv6 a começar pela análise das mudanças ocorridas na estrutura de seu cabeçalho, seguido da explicitação das diferenças entre os cabeçalhos de ambas as versões, resaltando o que foi aprimorado no funcionamento do protocolo. Também, será detalhada o a utilização dos cabeçalhos de extensão e, o porquê dela melhorar o desempenho dos roteadores.
Cabeçalho IPv4
O cabeçalho IPv4 é composto por 12 campos fixos, que podem ou não conter opções responsáveis por fazer com que o tamanho varie de 20 a 60 Bytes. Estes campos são destinados transmitir informações sobre:
- a versão do protocolo;
- o tamanho do cabeçalho e dos dados;
- a fragmentação dos pacotes;
- o tipo dos dados sendo enviados;
- o tempo de vida do pacote;
- o protocolo da camada seguinte (TCP, UDP, ICMP);
- a integridade dos dados;
- a origem e destino do pacote.
Cabeçalho IPv6
Algumas mudanças foram realizadas no formato do cabeçalho base do IPv6 de modo a torná-lo mais simples. O número de campos foi reduzido para apenas oito e o tamanho foi fixado de 40 Bytes. Além disso, ele ficou mais flexível e eficiente com a adição de cabeçalhos de extensão que não precisam ser processados por roteadores intermediários. Tais alterações permitiram que, mesmo com um espaço de endereçamento quatro vezes maior que o do IPv4, o tamanho total do cabeçalho IPv6 fosse apenas duas vezes.
Dentre essas mudanças, destaca-se a remoção de seis dos campos existentes cabeçalho IPv4, como resultado tanto da inutilização de suas funções quanto de sua reimplentação com o uso de cabeçalhos de extensão. A figura a seguir identifica esses campos.
A primeira remoção foi a do campo “Tamanho do Cabeçalho” que tornou-se desnecessário uma vez que seu valor foi fixado. A seguir, os campos “Identificação”, “Flags”, “Deslocamento do Fragmento” e “Opções e Complementos” passaram a ter suas informações indicadas em cabeçalhos de extensão apropriados. Por fim, o campo ”Soma de Verificação” foi descartado com o objetivo de deixar o protocolo mais eficiente já que outras validações são realizadas pelos protocolos das camadas superiores da rede.
Outra alteração realizada com o intuito de agilizar o processamento foi a renomeação e reposicionamento de quatro campos conforme a tabela abaixo:
| IPv4 | IPv6 |
| Tipo de Serviço | Classe de Serviço |
| Tamanho Total | Tamanho dos Dados |
| Tempo de Vida (TTL) | Limite de encaminhamento |
| Protocolo | Próximo Cabeçalho |
Além disso, o campo “Identificador de Fluxo” foi adicionado para possibilitar o funcionamento de um mecanismo extra de suporte a QoS (Quality of Service). Mais detalhes sobre este campo e mecanismo serão apresentados nas próximas seções.
Por fim, os campos “Versão”, “Endereço de Origem” e “Endereço de Destino” foram mantidos e apenas tiveram seus tamanhos alterados.
2.1. Campos do Cabeçalho IPv6
Conforme a observado na figura acima, o cabeçalho do IPv6 está dividido nos seguintes campos:
- Versão (4 bits) - Identifica a versão do protocolo utilizado. No caso, o valor desse campo é 6.
- Classe de Tráfego (8 bits) – Identifica os pacotes por classes de serviços ou prioridade. Ele provê as mesmas funcionalidades e definições do campo “Tipo de Serviço do IPv4″.
- Identificador de Fluxo (20 bits) – Identifica pacotes do mesmo fluxo de comunicação. Idealmente esse campo é configurado pelo endereço de destino para separar os fluxos de cada uma das aplicações e os nós intermediários de rede podem utiliza-lo de forma agregada com os endereços de origem e destino para realização de tratamento específico dos pacotes.
- Tamanho do Dados (16 bits) – Indica o tamanho, em Bytes, apenas dos dados enviados junto ao cabeçalho IPv6. Substituiu o campo Tamanho Total do IPv4, que indicava o tamanho do cabeçalho mais o tamanho dos dados transmitidos. Contudo, o tamnho dos cabeçalhos de extensão também são somado nesse novo campo.
- Próximo Cabeçalho (8 bits) – Identifica o cabeçalho de extensão que segue o atual. Ele foi renomeado (no IPv4 chamava-se Protocolo) para refletir a nova organização dos pacotes IPv6, uma vez que ele deixou de conter os valores referentes a outros protocolos, para indicar os tipos dos cabeçalhos de extensão.
- Limite de Encaminhamento (8 bits) – Esse campo é decrementado a cada salto de roteamento e indica o número máximo de roteadores pelos quais o pacote pode passar antes de ser descartado. Ele padronizou o modo como o campo Tempo de Vida (TTL) do IPv4 vinha sendo utilizado, o qual diferia significativamente da descrição original que o definia como o tempo, em segundos, para o pacote ser descartado caso não chegasse à seu destino.
- Endereço de origem (128 bits) – Indica o endereço de origem do pacote.
- Endereço de Destino (128 bits) – Indica o endereço de destino do pacote.
Cabeçalhos de extensão
Diferente do IPv4, que inclui no cabeçalho base todas as informações opcionais, o IPv6 trata essas informações através de cabeçalhos de extensão. Estes, localizam-se entre o cabeçalho base e o cabeçalho da camada de imediatamente acima e, não possuem quantidade ou tamanho fixo. Caso existam múltiplos cabeçalhos de extensão no mesmo pacote, eles serão adicionados em série formando uma “cadeia de cabeçalhos”. A figura abaixo exemplifica essa situação.
As especificações do IPv6 definem seis cabeçalhos de extensão: Hop-by-Hop Options, Destination Options, Routing, Fragmentation, Authentication Header e Encapsulating Security Payload.
A criação dos cabeçalhos de extensão do IPv6 teve a finalidade de aumentar a velocidade de processamento nos roteadores, visto que o único que deve ser processado em cada roteador é o Hop-by-Hop, enquanto que os demais são tratados apenas pelo nó de destino. Além disso, novos cabeçalhos podem ser definidos no protocolo sem a necessidade alterações no cabeçalho base. O esquema abaixo mostra o template de um cabeçalho de extensão.
Hop-by-Hop
Identificado pelo valor 00 no campo Próximo Cabeçalho, o cabeçalho de extensão Hop-by-Hop deve ser colocado imediatamente após o cabeçalho base IPv6. Suas informações devem ser examinadas por todos os nós intermediários do caminho do pacote até o destino. E, em sua ausência, os roteadores não precisam processar nada além do cabeçalho base, o que agiliza o encaminhamento de pacotes.
Os seguintes campos estão presentes nesse cabeçalho:
- Próximo Cabeçalho (1 Byte): Identifica o tipo de cabeçalho que segue ao Hop-by-Hop.
- Tamanho do Cabeçalho (1 Byte): Indica o tamanho seu tamanho (em unidades de 8 Bytes) excluídos o oito primeiros bits.
- Opções: Contem uma ou mais opções e seu tamanho é variável. Neste campo, o primeiro Byte contém informações sobre como estas opções devem ser tratadas caso o nó que as esteja processando, não as reconheça. Desse byte, o valor dos primeiros dois bits especifica qual das seguintes ações a devem ser tomadas:
- 00: ignorar e continuar o processamento.
- 01: descartar o pacote.
- 10: descartar o pacote e enviar uma mensagem ICMP Parameter Problem para o endereço de origem do pacote.
- 11: descartar o pacote e enviar uma mensagem ICMP Parameter Problem para o endereço de origem do pacote, apenas se o destino não for um endereço de multicast.
O terceiro bit indica se a informação opcional pode mudar de rota (valor 1) ou não (valor 0).
Até o momento existem dois tipos definidos para o cabeçalho Hop-by-Hop: Router Alert e Jumbogram:
- Router Alert: Utilizado para informar aos nós intermediários que a mensagem a ser encaminhada exige tratamento especial. Está opção é utilizada pelos protocols MLD (Multicast Listener Discovery) e RSVP (Resource Reservation Protocol).
- Jumbogram: Utilizado para informa que o tamanho do pacote IPv6 é maior do que 64KB.
Mais informações
RFC 2711 – IPv6 Router Alert Option
Destination Options
Identificado pelo valor 60 no campo Próximo Cabeçalho, o cabeçalho de extensão Destination Options deve ser processado apenas pelo nó de destino do pacote. A definição de seus campos é igual as do cabeçalho Hop-by-Hop.
Ele é utilizado no suporte ao mecanismo de mobilidade do IPv6 através da opção Home Address, que contém o Endereço de Origem do Nó Móvel quando este está em transito.
Routing
Identificado pelo valor 43 no campo Próximo Cabeçalho, o cabeçalho de extensão Routing foi desenvolvido inicialmente para listar um ou mais nós intermediários que deveriam ser visitados até o pacote chegar ao destino, de forma semelhante às opções Loose Source e Record Route do IPv4. No entanto, esta função tornou-se obsoleta pela RFC5095 devido a problemas de segurança.
Um novo cabeçalho Routing, Type 2, foi definido para ser utilizado como parte do mecanismo de suporte a mobilidade do IPv6. Segundo essa nova definição, ele deve carregar o Endereço de Origem do Nó Móvel em pacotes enviados pelo Nó Correspondente.
As definições de cada campo desse cabeçalho são as seguintes:
- Próximo Cabeçalho (1 Byte): Identifica o tipo de cabeçalho que segue ao cabeçalho Routing.
- Tamanho do Cabeçalho (1 Byte): Indica o tamanho seu tamanho (em unidades de 8 Bytes) excluídos o oito primeiros bits.
- Routing Type (1 Byte): Identifica o tipo de cabeçalho Routing. Atualmente apenas o Type 2 está especificado.
- Saltos restantes: Definido para ser utilizado com o Routing Type 0, indica o número de saltos a serem visitados antes do pacote atingir seu destino final.
- Endereço de Origem: Carrega o Endereço de Origem de um Nó Móvel.
Mais informações
RFC 3775 – Mobility Support in IPv6 – 6.4. Type 2 Routing Header
RFC 5095 – Deprecation of Type 0 Routing Headers in IPv6
Fragmentation
Identificado pelo valor 44 no campo Próximo Cabeçalho, o cabeçalho de extensão Fragmentation é utilizado quando o pacote IPv6 a ser enviado é maior que o Path MTU.
As definições de cada campo do cabeçalho são as seguintes:
- Próximo Cabeçalho (1 Byte): Identifica o tipo de cabeçalho que segue ao cabeçalho Fragmentation.
- Deslocamento do Fragmento (13 bits): Indica, em unidades de oito Bytes, a posição dos dados transportados pelo fragmento atual em relação ao início do pacote original.
- Flag M (1 bit): Se marcado com o valor 1, indica que há mais fragmentos. Se marcado com o valor 0, indica que é o fragmento final.
- Identificação (4 Bytes): Valor único gerado pelo nó de origem, para identificar o pacote original. É utilizado para detectar os fragmentos de um mesmo pacote.
O processo de fragmentação é definido na seção de Funcionalidades Básicas.
Authentication Header e Encapsulating Security Payload
Os cabeçalhos de extensão Authentication Header (AH) e Encapsulating Security Payload (ESP), indicados respectivamente pelos valores 51 e 52 no campo Próximo Cabeçalho, fazem parte do cabeçalho IPSec.
Embora as funcionalidades do IPSec sejam idênticas tanto no IPv4 quanto no IPv6, sua utilização com IPv6 é facilitada pelo fato de seus principais elementos integrarem essa nova versão do protocolo. Outros aspectos que também facilitam sua utilização são a inexistência de NAT IPv6 e o detalhamento dos cabeçalhos AH e ESP.
Aspectos dos cabeçalhos de extensão
Alguns aspectos sobre os cabeçalhos de extensão devem ser observados. Primeiramente, estes cabeçalhos devem ser enviados segundo uma determinada ordem com o intuito de evitar que os nós intermediários tenham que processar toda a cadeia de cabeçalhos para decidir quais eles deverão tratar. Assim, os cabeçalhos importantes para todos os nós envolvidos no roteamento devem ser colocados em antes daqueles que são relevantes apenas para o destinatário final. A vantagem, é que um nó pode parar de analisar cabeçalhos assim que encontrar algum dedicado ao destino. Isso, melhora significativamente o desempenho dos roteadores pacotes, porque, em geral, apenas o processamento do cabeçalho base é necessário. Deste modo, a sequência a ser seguida é:
- Hop-by-Hop Options
- Routing
- Fragmentation
- Authentication Header
- Encapsulating Security Payload
- Destination Options
Vale também observar que, se um pacote for enviado para um endereço multicast, os cabeçalhos de extensão serão examinados por todos os nós do grupo.
Em relação à flexibilidade oferecida pelos cabeçalhos de extensão, merece destaque o desenvolvimento do cabeçalho Mobility, que é utilizado por nós com suporte ao mecanismo de mobilidade IPv6.
Recursos Adicionais
Curso e-learning
Apostilas
.
Antônio, e quanto a este questionamento, é passível de resposta?
Bom, então se entendi direito, o CERT irá administrar o repasse de classes de rede, tanto para endereços GLOBAIS, quanto para endereços ULA, correto?
Não havendo, no mundo, nenhuma rede igual, mesmo no escopo Interno, certo?
Abraço e fique com DEUS!!!
O CERT.br é a equipe de segurança para a Internet brasileira do NIC.br. Não administra a distribuição dos IPs.
O departamento que faz isso no NIC.br é o Registro.br, que além de distribuir os IPs, administra também os nomes de domínio “.br”.
Os endereços ULA não são gerenciados. Os prefixos são gerados de forma pseudo aleatória, segundo as regras definidas na http://tools.ietf.org/html/rfc4193. Há chance de colisão, mas ela é extremamente baixa.
Os endereços IPv6 globais são gerenciados, únicos na Internet, como os IPv4 válidos. Não há possibilidade de colisão.
um pacote ipv6 pode ter mais de um jumbogram?
Veja a http://tools.ietf.org/html/rfc2675, Beto.
O campo que especifica o tamanho dos dados num pacote IPv6 é de 16bits, logo os dados podem ter até 65535 bytes. O jumbograma é uma forma de enviar num único pacote IPv6 mais do que 65535 bytes e para isso ele utiliza uma opção especificada no cabeçalho hop-by-hop, que permite definir o tamanho do payload usando 32bits. Um único jumbograma IPv6 pode enviar 4Gbytes de dados.
Cada pacote IPv6 corresponde a um único jumbograma, portanto.
Os jumbogramas só fazem sentido caso o MTU da rede utilizada seja maior do que 65575 bytes (65535 dos dados + 40 bytes do cabeçalho) e as atuais implementações do TCP e do UDP não o suportam ainda.
Bom, então se entendi direito, o CERT irá administrar o repasse de classes de rede, tanto para endereços GLOBAIS, quanto para endereços ULA, correto?
Não havendo, no mundo, nenhuma rede igual, mesmo no escopo Interno, certo?
Abraço e fique com DEUS!!!
Ah outra coisa, suponha o seguinte cenário:
ESCOPO
10 redes, utilizando IPv4, onde todos fazem uso da classe A, são de empresas diferentes e interligados por meio de links dedicados (ponto a ponto).
No IPv4 resolveríamos facilmente alguns problemas simplesmente utilizando um NAT, na origem por exemplo, colocando um endereço da classe B.
QUESTIONAMENTOS
Como ficaria este mesmo cenário no IPv6?
Não existiria conflitos de rede?
Como se resolveria a questão do Cliente A, possuir o mesmo escopo do Cliente B na Rede Interna?
Abraço e fique com DEUS!!!
Classe A? Você quer dizer IPs da faixa 10.0.0.0/8, certo? Essa história de classes é algo que foi abolido com o uso do CIDR, há quase duas décadas.
No IPv6 há duas formas de resolver isso:
(1) Se todas as empresas estiverem na Internet, cada uma terá seu próprio bloco de endereços globais (/48 no mínimo), suficientes para todos e cada um de seus hosts, e não haverá conflitos.
(2) Se não estamos falando de Internet, e sim de uma rede privada entre essas 10 empresas, cada uma criará para si seu próprio prefixo de endereços ULA (/48), de forma que terá também um bloco único, diferente das demais, e não haverá conflitos.
Muito obrigado por me corrigir quanto à não utilização de Classe A, B e C. Apesar disto ter sido abolido, como mencionado, é comum para o meu dia-a-dia, mas aproveitarei sua deixa e não utilizarei mais.
Bom, então se entendi direito, o CERT irá administrar o repasse de classes de rede, tanto para endereços GLOBAIS, quanto para endereços ULA, correto?
Não havendo, no mundo, nenhuma rede igual, mesmo no escopo Interno, certo?
Ola Antonio, primeiramente, muito obrigado pelas explanações.
“E não é um nat de 1:N, mas sim de N:N”
Como ficará neste caso o acesso à Internet, e as interligações entre N redes de clientes Corporativos? Por exemplo:
Em uma rede Corporativa, todos os equipamentos da rede terão IPs roteáveis na Internet IPv6? Pelo que entendi não! Mas me exclareça por favor.
Sim, todos os equipamentos terão IPs roteáveis. No IPv6 o nome mais correto é “IP global”.
O mais próximo a IPs privados é o que no IPv6 chamamos de Unique Local Addresses (ULAs). Estes podem ser usados em equipamentos que não precisam acessar a Internet Global, ou ser acessíveis à partir dela, e são usados apenas na rede privada da empresa, por exemplo, em impressoras. Mas nada impede que usemos IPs globais também nesses casos.
No IPv6, não se faz necessário NATs, até ai tudo bem; mas é possível utilizar NAT? – Pois entendi que não é possível sua utilização:
“Outros aspectos que também facilitam sua utilização são a inexistência de NAT IPv6 e o detalhamento dos cabeçalhos AH e ESP.”
Abraço e fique com DEUS!!!
Até pouco tempo não era realmente possível. Atualmente, sim, é. O NAT66 foi padronizado há pouco tempo e há algumas implementações. No entanto são pouquíssimos os casos em que seu uso é realmente justificado. E não é um nat de 1:N, mas sim de N:N (cada endereço privado é mapeado num endereço global único).
Como há a necessidade do envio ordenado dos cabeçalhos de extensão, para que não haja o processamento por parte dos roteadores intermediários. Não seria possível, causar um DDOS, caso os pacotes não fossem nesta ordem, “obrigando” os roteadores intermediários ao processamento?
Esta ordem é passível de manipulação?
O envio numa ordem determinada é apenas uma recomendação. Apenas o hop-by-hop tem realmente uma ordem realmente obrigatória: quando estiver presente, tem de ser o primeiro. Os outros cabeçalhos de extensão normalmente não são tratados pelos roteadores intermediários, a menos que configurados para suportar funcionalidades específicas, como a mobilidade IPv6.
Esse artigo da Cisco explica isso de uma forma muito didática: http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html