Formato de Cabeçalho IPv6: Estrutura, Campos e Cabeçalhos de Extensão

Por Que o IPv6 Mudou o Cabeçalho#

O cabeçalho do IPv4 cresceu organicamente ao longo de décadas. Opções foram adicionadas, campos foram reaproveitados, e no final você tinha um cabeçalho de comprimento variável com 14 campos diferentes (alguns opcionais) e uma estrutura complexa que roteadores tinham que fazer parse cuidadosamente em cada hop.

O IPv6 adotou uma abordagem diferente: comprimento fixo, simplificado e otimizado para encaminhamento rápido. O cabeçalho base é sempre exatamente 40 bytes, com 8 campos bem definidos. Sem opções de comprimento variável, sem checksum de cabeçalho, sem campos de fragmentação no cabeçalho principal.

O resultado é um cabeçalho que roteadores podem processar mais rápido, que é mais fácil de implementar em hardware e que suporta extensão sem quebrar compatibilidade retroativa. Entender o cabeçalho IPv6 significa entender por que ele é construído dessa forma e quais trade-offs os designers fizeram.

O Cabeçalho Base de 40 Bytes#

Todo pacote IPv6 começa com exatamente 40 bytes neste formato:

 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| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tamanho fixo. Sem opções no cabeçalho base. Todo roteador sabe exatamente onde cada campo está sem fazer parsing.

Os Oito Campos#

Vamos examinar cada campo na ordem que roteadores tipicamente os processam.

1. Version (4 bits)#

Sempre 6 para pacotes IPv6. Sempre 4 para pacotes IPv4. É assim que dispositivos distinguem IPv6 de IPv4 no fio.

Implicação prática: Sistemas dual-stack olham esses 4 bits primeiro para determinar como fazer parse do resto do pacote.

Version = 6 (binário: 0110)

Simples, imutável e crítico para identificação de protocolo.

2. Traffic Class (8 bits)#

Anteriormente chamado de «Priority» nas especificações iniciais do IPv6, este campo marca pacotes para tratamento de Qualidade de Serviço (QoS). Serve o mesmo propósito que o Type of Service (ToS) ou Differentiated Services Code Point (DSCP) do IPv4.

Estrutura:

• Bits 0-5: DSCP (Differentiated Services Code Point)
• Bits 6-7: ECN (Explicit Congestion Notification)

Valores DSCP comuns:

ECN permite que roteadores sinalizem congestionamento sem descartar pacotes. É usado por implementações modernas de TCP para melhor controle de congestionamento.

Exemplo:

Traffic Class = 46 (EF) = 0b10111000
  DSCP = 46 (Expedited Forwarding)
  ECN = 0 (Não capaz de ECN)

Roteadores que suportam QoS examinam este campo para priorizar pacotes. VoIP recebe prioridade mais alta que downloads de arquivos. Vídeo em tempo real recebe melhor tratamento que email.

3. Flow Label (20 bits)#

Uma das características mais interessantes mas subutilizadas do IPv6. O Flow Label identifica pacotes que pertencem ao mesmo fluxo e devem receber tratamento de roteamento idêntico.

Propósito:

• Permitir que roteadores identifiquem pacotes relacionados sem examinar cabeçalhos de camadas superiores
• Suportar encaminhamento fast-path para fluxos conhecidos
• Fornecer uma handle para QoS por fluxo

Especificação (RFC 6437):

• Valor 0: Pacote não faz parte de um fluxo
• Valor 1-0xFFFFF: Identificador de fluxo (escolhido aleatoriamente pela origem)
• Deve ser consistente para todos pacotes em um fluxo
• Deve ser pseudo-aleatório para permitir hashing de roteadores

O que constitui um fluxo:

• Origem + Destino + Flow Label o identifica unicamente
• Todos pacotes em uma conexão TCP podem usar o mesmo Flow Label
• Ou cada stream de vídeo pode receber um label único

Uso prático:

Muitas implementações definem Flow Label como 0 porque:

• Hardware necessário para hash/encaminhamento baseado em Flow Label não é universal
• Suporte de aplicações é limitado
• É opcional, e zero funciona bem

Mas quando usado corretamente, Flow Label habilita:

• Balanceamento de carga através de rotas ECMP (Equal Cost Multi-Path)
• Engenharia de tráfego por fluxo
• Encaminhamento fast-path em hardware

Exemplo de configuração de Flow Label (Linux):

# Habilitar labels de fluxo automáticos
sysctl -w net.ipv6.auto_flowlabels=1
 
# Flow labels serão definidos baseados em hash de 5-tupla

Linux gera flow labels automaticamente para conexões TCP quando habilitado, usando um hash de endereços origem/destino e portas.

4. Payload Length (16 bits)#

Comprimento da carga útil do pacote em bytes, excluindo o cabeçalho base de 40 bytes.

Faixa: 0 a 65.535 bytes

Detalhes importantes:

• Inclui cabeçalhos de extensão (se houver) mais dados de camada superior
• NÃO inclui o cabeçalho IPv6 base de 40 bytes
• Valor máximo 65.535 significa tamanho máximo de pacote é 65.575 bytes (65.535 + 40)

Caso especial: Jumbograms

Para pacotes maiores que 65.535 bytes, Payload Length é definido como 0 e um cabeçalho de extensão Hop-by-Hop com a opção Jumbogram carrega o comprimento real (até 4.294.967.295 bytes).

Jumbograms são raros. São usados em redes de alto desempenho especializadas com suporte a jumbo frames, tipicamente sobre links de 10 Gbps+.

Exemplo:

Payload Length = 1440 bytes
  Cabeçalho IPv6 de 40 bytes (não contado)
  Carga de 1440 bytes (cabeçalho TCP + dados)
  Pacote total = 1480 bytes

5. Next Header (8 bits)#

Identifica o tipo de cabeçalho imediatamente seguindo o cabeçalho IPv6. É assim que cabeçalhos de extensão e protocolos de camada superior são especificados.

Valores comuns:

Como funciona o encadeamento:

Cada cabeçalho de extensão contém seu próprio campo Next Header, formando uma cadeia:

Cabeçalho IPv6 (Next Header = 0)
  -> Hop-by-Hop Options (Next Header = 43)
    -> Cabeçalho de Roteamento (Next Header = 6)
      -> Cabeçalho TCP
        -> Dados

O host receptor processa cabeçalhos em ordem até alcançar o protocolo de transporte (TCP/UDP) ou dados.

Exemplo sem cabeçalhos de extensão:

Next Header = 6 (TCP)
  Cabeçalho IPv6 diretamente seguido por cabeçalho TCP

Exemplo com cabeçalhos de extensão:

Next Header = 44 (Fragment)
  Cabeçalho IPv6 seguido por cabeçalho Fragment (Next Header = 6)
    Cabeçalho Fragment seguido por cabeçalho TCP

6. Hop Limit (8 bits)#

O número de hops de roteador restantes antes que o pacote seja descartado. Cada roteador decrementa isso em 1. Quando alcança 0, o roteador descarta o pacote e envia uma mensagem ICMPv6 Time Exceeded.

Faixa: 0-255

Este é o equivalente do IPv6 ao campo TTL (Time To Live) do IPv4, mas o nome é mais preciso — ele conta hops, não tempo.

Valores iniciais comuns:

Por que valores diferentes importam para fingerprinting:

Você pode adivinhar o OS de origem olhando o Hop Limit em pacotes recebidos:

Hop Limit Recebido: 56
  56 + 8 hops = 64 (provável Linux/BSD)
 
Hop Limit Recebido: 117
  117 + 11 hops = 128 (provável Windows)

Traceroute usa Hop Limit:

Traceroute funciona enviando pacotes com valores Hop Limit incrementais:

• Hop Limit 1: Primeiro roteador responde com Time Exceeded
• Hop Limit 2: Segundo roteador responde com Time Exceeded
• Hop Limit 3: Terceiro roteador responde com Time Exceeded
• ...até destino alcançado

Consideração de segurança:

Alguns ataques usam Hop Limits baixos para fazer pacotes expirarem antes de alcançar sistemas IDS/IPS. Firewalls às vezes impõem valores Hop Limit mínimos para tráfego de entrada.

Exemplo:

Hop Limit = 64
  Roteador 1 recebe, decrementa para 63, encaminha
  Roteador 2 recebe, decrementa para 62, encaminha
  ...
  Roteador 64 recebe, decrementa para 0, descarta e envia ICMPv6 Type 3

7. Source Address (128 bits)#

O endereço IPv6 do remetente do pacote. Sempre 128 bits, sem exceções.

Formato: Notação de endereço IPv6 padrão

2001:db8:1234:5678:9abc:def0:1234:5678

Considerações especiais:

Endereço não especificado (::) é válido apenas em casos específicos:

• Duplicate Address Detection (DAD)
• Solicitações DHCP antes de atribuição de endereço
• Certas mensagens ICMPv6

Endereços link-local (fe80::/10) são endereços de origem válidos mas apenas no link local. Roteadores não encaminham pacotes com origens link-local.

Endereços multicast nunca são endereços de origem válidos. Um pacote com origem multicast deve ser descartado imediatamente.

Problema prático: seleção de endereço de origem

Quando um host tem múltiplos endereços IPv6 (comum com SLAAC, DHCPv6 e extensões de privacidade), ele deve escolher qual usar como origem. RFC 6724 define o algoritmo de seleção, preferindo:

1. Mesmo escopo de endereço que destino
2. Endereços com prefixo mais longo correspondente
3. Endereços não depreciados
4. Endereços com preferência mais alta

8. Destination Address (128 bits)#

O endereço IPv6 do destinatário pretendido do pacote. Como Source Address, sempre 128 bits.

Formato: Notação de endereço IPv6 padrão

2001:4860:4860::8888

Decisão de roteamento:

Roteadores examinam este campo para determinar para onde encaminhar o pacote. Diferente do IPv4 onde NAT pode reescrever endereços, endereços de destino IPv6 tipicamente permanecem inalterados end-to-end.

Endereços especiais:

Loopback (::1) nunca deve aparecer em um pacote no fio. Pacotes para ::1 são manipulados internamente.

Endereços multicast (ff00::/8) indicam que o pacote deve ser entregue a múltiplos destinatários:

• ff02::1 - Todos nós no link local
• ff02::2 - Todos roteadores no link local
• ff02::1:ff00:0/104 - Multicast solicited-node (para Neighbor Discovery)

Modificação de cabeçalho de roteamento:

Quando um cabeçalho de extensão Routing está presente, nós intermediários podem processar o endereço de destino diferentemente, mas isso é incomum em redes modernas devido a preocupações de segurança.

Comparação Cabeçalho IPv6 vs IPv4#

Entender o que mudou ajuda a apreciar as decisões de design.

O Que Foi Removido e Por Quê#

Checksum de cabeçalho: Roteadores IPv4 recomputam o checksum em cada hop porque TTL muda. Isso adiciona overhead de CPU. IPv6 elimina porque:

• Camada de enlace (Ethernet) tem seu próprio checksum
• Camada de transporte (TCP/UDP) tem seu próprio checksum
• Roteadores não precisam verificar integridade de pacote — endpoints fazem isso
• Erros são raros: Redes modernas têm baixas taxas de erro de bit. Checksums capturam menos erros do que nos anos 1980 quando IPv4 foi projetado.

Campo Header Length: IPv4 precisa disso porque opções tornam o cabeçalho de comprimento variável. O cabeçalho fixo de 40 bytes do IPv6 torna este campo desnecessário.

Campos de fragmentação: IPv4 permite que qualquer roteador fragmente pacotes. IPv6 requer que a origem realize fragmentação usando Path MTU Discovery. Isso move complexidade para os endpoints e melhora o desempenho do roteador.

Opções: Opções do IPv4 são raramente usadas mas forçam roteadores a fazer parse de cabeçalhos de comprimento variável. IPv6 move opções para cabeçalhos de extensão, mantendo o cabeçalho base simples.

Cabeçalhos de Extensão Explicados#

Cabeçalhos de extensão são a forma do IPv6 de adicionar funcionalidade sem complicar o cabeçalho base. Eles aparecem entre o cabeçalho IPv6 e a camada de transporte (TCP/UDP), formando uma cadeia.

Como Funcionam os Cabeçalhos de Extensão#

Cada cabeçalho de extensão contém um campo Next Header que aponta para o próximo cabeçalho na cadeia:

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | Hop-by | NH=43 | Routing| NH=6  | TCP |
| Header |       | -Hop   |       | Header |       |     |
+--------+-------+--------+-------+--------+-------+-----+

Hosts processam cabeçalhos de extensão em ordem. Roteadores tipicamente apenas processam Hop-by-Hop Options; outros cabeçalhos são examinados apenas pelo destino.

Cabeçalhos de Extensão Padrão#

RFC 8200 define a ordem recomendada quando múltiplos cabeçalhos de extensão estão presentes:

1. Hop-by-Hop Options (0)
2. Destination Options (para destinos intermediários quando cabeçalho Routing está presente)
3. Routing (43)
4. Fragment (44)
5. Authentication Header (51)
6. Encapsulating Security Payload (50)
7. Destination Options (60) (para destino final)
8. Upper Layer (TCP=6, UDP=17, ICMPv6=58)

Cabeçalho Hop-by-Hop Options (Type 0)#

Carrega opções que devem ser examinadas por todo roteador ao longo do caminho.

Formato:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Opções comuns:

Pad1 e PadN: Padding para alinhamento

Router Alert (Type 5): Diz aos roteadores para examinar o pacote mais cuidadosamente. Usado por protocolos como MLD (Multicast Listener Discovery).

Jumbogram (Type 194): Para pacotes maiores que 65.535 bytes.

Deve ser primeiro: Se presente, Hop-by-Hop Options deve seguir imediatamente o cabeçalho IPv6. RFC 8200 requer essa ordenação estrita.

Preocupação de segurança: Muitos roteadores descartam pacotes com cabeçalhos Hop-by-Hop que não reconhecem, ou os limitam fortemente. Na prática, este cabeçalho de extensão é incomum fora de protocolos específicos (MLD, jumbograms).

Cabeçalho Routing (Type 43)#

Especifica nós intermediários que o pacote deve visitar antes de alcançar seu destino final.

Formato:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                     Type-specific data                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tipos de Roteamento:

Type 0 (Deprecated): Roteamento loose source original. Depreciado pela RFC 5095 devido a problemas de segurança (ataques de amplificação).

Type 2: Usado por Mobile IPv6 para roteamento para nós móveis. Caso de uso limitado.

Type 3: Segment Routing Header (SRH) para SRv6. Caso de uso moderno para engenharia de tráfego e encadeamento de serviços em redes de operadoras.

Segurança: Cabeçalhos Routing Type 0 permitiam que atacantes roteassem pacotes através de nós arbitrários, criando ataques de amplificação. A maioria das redes descarta Type 0. Type 3 (SRv6) é projetado mais cuidadosamente mas ainda levanta preocupações de segurança na Internet pública.

Cabeçalho Fragment (Type 44)#

Usado quando a origem fragmenta um pacote que é grande demais para o path MTU.

Formato:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Campos:

• Next Header: Protocolo dos dados fragmentados (TCP, UDP, etc.)
• Fragment Offset: Offset deste fragmento no pacote original (em unidades de 8 bytes)
• M flag: More Fragments (1 = mais vindo, 0 = último fragmento)
• Identification: ID único para remontagem (mesmo para todos fragmentos de um pacote)

Como funciona a fragmentação:

1. Origem tenta enviar pacote grande
2. Recebe mensagem ICMPv6 Packet Too Big
3. Fragmenta pacote em pedaços menores
4. Adiciona cabeçalho Fragment a cada pedaço
5. Destino remonta baseado no campo Identification

Exemplo:

Pacote original de 2000 bytes, MTU 1280:

Fragmento 1:
  Cabeçalho IPv6 (40 bytes)
  Cabeçalho Fragment (8 bytes) [M=1, Offset=0, ID=12345]
  Dados (1232 bytes)
  Total: 1280 bytes
 
Fragmento 2:
  Cabeçalho IPv6 (40 bytes)
  Cabeçalho Fragment (8 bytes) [M=0, Offset=154, ID=12345]
  Dados (768 bytes)
  Total: 816 bytes

MTU mínimo: IPv6 requer que todos links suportem pelo menos 1280 bytes. Origens podem enviar pacotes de 1280 bytes sem fragmentação em qualquer rede IPv6 conforme.

Preocupações de segurança: Fragmentação habilita ataques:

• Fragmentos sobrepostos (ofuscar payload de IDS)
• Floods de fragmentos (esgotar recursos de remontagem)
• Fragmentos minúsculos (desperdiçar tempo de processamento)

Muitos firewalls descartam pacotes fragmentados ou os remontam antes da inspeção.

Cabeçalho Destination Options (Type 60)#

Carrega opções apenas para o nó de destino. Roteadores intermediários não o processam.

Formato: Mesmo que Hop-by-Hop Options, mas examinado apenas no destino.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Casos de uso:

• Padding para alinhamento
• Opções específicas de aplicação
• Extensões futuras sem mudar cabeçalho base

Pode aparecer duas vezes na cadeia de cabeçalhos:

1. Antes do cabeçalho Routing (processado por destinos intermediários)
2. Após cabeçalhos ESP/AH (processado por destino final)

Authentication Header (Type 51) e ESP (Type 50)#

Cabeçalhos IPsec fornecendo autenticação e criptografia.

AH (51): Fornece autenticação e integridade mas não confidencialidade. Raramente usado porque ESP pode fazer o mesmo mais criptografia.

ESP (50): Fornece confidencialidade, autenticação e integridade. Padrão para VPNs e comunicação criptografada.

IPsec é um tópico grande além da estrutura de cabeçalhos. Ponto chave: esses cabeçalhos são parte do design do IPv6 desde o início, diferente do IPv4 onde IPsec foi encaixado depois.

Processando Cabeçalhos de Extensão#

Hosts devem:

• Processar todos cabeçalhos de extensão em ordem
• Suportar todos cabeçalhos de extensão padrão
• Manipular cabeçalhos desconhecidos de acordo com valor Next Header

Roteadores tipicamente:

• Apenas examinam Hop-by-Hop Options
• Encaminham outros cabeçalhos de extensão sem processar
• Podem limitar ou descartar pacotes com certos cabeçalhos por segurança

Considerações de firewall:

Cabeçalhos de extensão complicam firewalls porque:

• Cabeçalho de transporte (TCP/UDP) pode estar profundo no pacote
• Devem fazer parse de cadeia inteira para encontrar portas para filtragem
• Atacantes podem ofuscar payloads com cadeias de cabeçalhos complexas

Melhores práticas:

• Limitar comprimento de cadeia de cabeçalhos de extensão
• Descartar pacotes com cabeçalhos depreciados (Type 0 Routing)
• Remontar fragmentos antes da inspeção
• Limitar pacotes com opções Hop-by-Hop

Por Que Sem Checksum?#

IPv4 inclui um checksum de cabeçalho que roteadores devem recomputar em cada hop (porque TTL muda). IPv6 deliberadamente omite isso.

Raciocínio:

1. Camada de enlace já faz checksum: Ethernet tem CRC32. Wi-Fi tem checksums. Camadas de enlace modernas são confiáveis.

2. Camada de transporte faz checksums: TCP e UDP incluem checksums cobrindo dados e cabeçalhos. Verificação end-to-end acontece de qualquer forma.

3. Desempenho do roteador: Recomputar checksums em cada hop desperdiça ciclos de CPU. Roteadores de alta velocidade encaminham bilhões de pacotes por segundo — eliminar cálculo de checksum ajuda.

4. Erros são raros: Redes modernas têm baixas taxas de erro de bit. Checksums capturam menos erros do que nos anos 1980 quando IPv4 foi projetado.

E quanto à corrupção?

Se um bit muda em um cabeçalho IPv6:

• Endereço de destino errado: Pacote vai para lugar errado ou é descartado, TCP retransmite
• Hop limit errado: Pacote pode morrer cedo ou tarde, impacto marginal
• Next header errado: Destino não consegue fazer parse, TCP detecta dados faltando e retransmite

O princípio end-to-end diz que endpoints devem detectar e manipular erros. Roteadores intermediários apenas encaminham pacotes rápido.

Implicações Práticas#

Para Engenheiros de Redes#

Configuração de firewall:

• Devem fazer parse de cadeias de cabeçalhos de extensão para encontrar cabeçalhos de transporte
• Devem limitar profundidade de cadeia para prevenir abuso
• Descartar cabeçalhos depreciados (Type 0 Routing)

Ajuste de desempenho:

• Sem checksum de cabeçalho significa encaminhamento mais rápido em hardware
• Tamanho fixo de cabeçalho habilita melhor pipelining em roteadores
• Cabeçalhos de extensão podem acionar processamento slow-path

Troubleshooting:

• tcpdump mostra todos cabeçalhos: tcpdump -i eth0 -vv ip6
• Wireshark faz parse de cabeçalhos de extensão claramente
• Verifique cabeçalhos de extensão inesperados causando drops

Para Desenvolvedores#

Programação de sockets:

• Sockets IPv6 podem receber cabeçalhos de extensão via dados ancilares
• Aplicações raramente precisam construir cabeçalhos de extensão manualmente
• OS manipula fragmentação automaticamente

Construção de pacotes:

• Defina Traffic Class para aplicações sensíveis a QoS (VoIP, vídeo)
• Habilite geração automática de Flow Label para melhor balanceamento de carga ECMP
• Não assuma que você pode fragmentar — use PMTUD adequadamente

Segurança:

• Valide endereços de origem (rejeite origens multicast, etc.)
• Manipule pacotes fragmentados cuidadosamente ou rejeite-os
• Esteja ciente que middleboxes podem descartar cabeçalhos de extensão

Para Administradores de Sistemas#

Configuração MTU:

• Garanta que MTU seja pelo menos 1280 bytes em todos links
• MTUs maiores melhoram desempenho (1500 padrão, 9000 para jumbo frames)
• Permita ICMPv6 Packet Too Big através de firewalls

Configuração QoS:

• Configure roteadores para honrar marcações Traffic Class
• Mapeie tráfego de aplicação para valores DSCP apropriados
• Monitore que políticas QoS funcionam corretamente

IPsec/VPN:

• AH e ESP são cabeçalhos de extensão — firewalls devem permitir
• IPsec adiciona overhead — considere isso em cálculos MTU
• Considere impacto de modo transporte vs modo túnel em cabeçalhos

Examinando Cabeçalhos com Ferramentas#

tcpdump#

Capture e exiba cabeçalhos IPv6:

# Captura básica de pacote IPv6
sudo tcpdump -i eth0 -n ip6
 
# Saída verbose mostrando todos campos de cabeçalho
sudo tcpdump -i eth0 -vv ip6
 
# Mostre apenas pacotes com cabeçalhos de extensão
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'
 
# Capture pacotes fragmentados
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

Exemplo de saída:

12:34:56.789012 IP6 2001:db8::10 > 2001:db8::20: DSTOPT (TCP)
  2001:db8::10.54321 > 2001:db8::20.80: Flags [S], seq 123456789, win 65535
 
Análise:
- Origem: 2001:db8::10, porta 54321
- Destino: 2001:db8::20, porta 80
- Cabeçalho de extensão: Destination Options (DSTOPT)
- Transporte: TCP SYN

Wireshark#

Wireshark fornece análise detalhada de cabeçalhos:

Filtros:

# Todo tráfego IPv6
ipv6
 
# Pacotes com cabeçalhos de extensão específicos
ipv6.nxt == 0    # Hop-by-Hop
ipv6.nxt == 43   # Routing
ipv6.nxt == 44   # Fragment
ipv6.nxt == 60   # Destination Options
 
# Pacotes fragmentados
ipv6.fragment
 
# Traffic Class específico
ipv6.tclass == 46  # Expedited Forwarding

Inspeção de cabeçalhos:

1. Expanda «Internet Protocol Version 6» em detalhes de pacote
2. Veja todos 8 campos claramente rotulados
3. Cabeçalhos de extensão aparecem como camadas separadas
4. Clique direito em campos para filtragem

Scapy (Python)#

Construa e analise pacotes IPv6 programaticamente:

from scapy.all import *
 
# Crie pacote IPv6
pkt = IPv6(src="2001:db8::10", dst="2001:db8::20", tc=46, fl=12345)
pkt = pkt/TCP(sport=54321, dport=80, flags="S")
 
# Mostre estrutura de pacote
pkt.show()
 
# Saída:
# ###[ IPv6 ]###
#   version= 6
#   tc= 46
#   fl= 12345
#   plen= None
#   nh= TCP
#   hlim= 64
#   src= 2001:db8::10
#   dst= 2001:db8::20
# ###[ TCP ]###
#   sport= 54321
#   dport= http
 
# Adicione cabeçalho de extensão
pkt = IPv6(dst="2001:db8::20")/IPv6ExtHdrDestOpt()/TCP(dport=80)
pkt.show()

Configurações Erradas Comuns#

Bloqueando Cabeçalhos de Extensão Inteiramente#

Problema: Firewall descarta todos pacotes com cabeçalhos de extensão.

Impacto:

• Fragmentação não funciona (type 44 bloqueado)
• VPNs IPsec falham (types 50/51 bloqueados)
• Algum tráfego legítimo é descartado

Solução: Permita cabeçalhos necessários (Fragment, AH, ESP), bloqueie depreciados (Type 0 Routing).

# iptables: Permita fragmentos, descarte roteamento Type 0
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Ignorando Traffic Class#

Problema: Roteadores configurados sem QoS, todos pacotes recebem tratamento best-effort.

Impacto:

• Qualidade VoIP sofre
• Streams de vídeo têm buffer
• Tráfego sensível a tempo compete com transferências bulk

Solução: Configure políticas QoS baseadas em Traffic Class/DSCP.

! Exemplo Cisco IOS
class-map match-any VOICE
  match dscp ef
!
policy-map WAN-QOS
  class VOICE
    priority percent 20
  class class-default
    fair-queue
!
interface GigabitEthernet0/1
  service-policy output WAN-QOS

Incompatibilidades MTU#

Problema: Links com MTU < 1280 ou firewalls bloqueando ICMPv6 Packet Too Big.

Impacto:

• Conexões travam
• Transferências grandes falham
• PMTUD não funciona

Solução: Garanta MTU mínimo de 1280 em todo lugar, permita ICMPv6 type 2.

# Defina MTU
ip link set dev eth0 mtu 1500
 
# Verifique
ip -6 link show eth0
 
# Permita Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

Artigos Relacionados#

• Fundamentos de IPv6 - Entenda endereçamento básico IPv6 e conceitos antes de mergulhar em cabeçalhos.
• ICMPv6 Explicado - Aprenda sobre ICMPv6, que usa valor Next Header 58 e é crítico para IPv6.
• Configuração de Firewall IPv6 - Configure firewalls para manipular cabeçalhos IPv6 e cabeçalhos de extensão corretamente.

Perguntas Frequentes#