Campo Version (4) do Cabeçalho IPv4

O campo Version (Versão) é o primeiro e mais fundamental campo do cabeçalho do datagrama IPv4. Localizado nos primeiros 4 bits (o "nibble" mais significativo) do primeiro byte do cabeçalho, sua função é identificar inequivocamente o formato e a semântica do datagrama IP que está sendo transmitido.

Embora pareça trivial, este campo é crucial para a interoperabilidade e a evolução da arquitetura da Internet, pois ele instrui o software de processamento (o stack de rede no sistema operacional ou o firmware do roteador) sobre como interpretar o restante dos bits do pacote.

1. Estrutura e Valor Binário

Sendo um campo de 4 bits, ele pode teoricamente conter valores de 0 a 15 (decimal). No contexto do protocolo IPv4, o valor deste campo é fixo e obrigatório:

• Valor Binário: 0100
• Valor Decimal: 4
• Significado: indica que o pacote pertence à versão 4 do Protocolo de Internet (Internet Protocol version 4).

A presença deste valor no início do pacote é o que define o pacote como sendo "IPv4". Se os roteadores ou hosts de destino encontrarem um valor diferente nos primeiros 4 bits, eles devem assumir que o cabeçalho segue uma estrutura diferente e empregar um método de análise (parsing) distinto.

Posicionamento no Cabeçalho

Byte 1:   | Versão (4b) | IHL (4b) | DSCP (6b) | ECN (2b) |
                                    |
                                    +---> primeiros 4 bits do datagrama

Os 4 bits seguintes do mesmo byte formam o campo IHL (Internet Header Length), que indica o tamanho do cabeçalho em palavras de 32 bits (mínimo 5 = 20 bytes; máximo 15 = 60 bytes). A escolha de Version como primeiro campo é deliberada: nenhum outro processamento é possível sem antes identificar a versão do protocolo.

2. Papel no Processamento do Pacote (Parsing)

A função principal do campo Version é servir como um discriminador de formato. Como as diferentes versões do IP não são compatíveis entre si, a informação de versão deve ser lida antes de qualquer outra parte do cabeçalho.

Desambiguação de Protocolos

O cabeçalho do IPv4 é completamente diferente do cabeçalho do IPv6:

• IPv4 (Version 4): endereços de 32 bits; comprimento de cabeçalho variável (20–60 bytes); possui campos de fragmentação, checksum e opções.
• IPv6 (Version 6, binário 0110): endereços de 128 bits; cabeçalho fixo de 40 bytes; sem checksum, sem fragmentação intermediária, com Extension Headers encadeadas.

A leitura dos primeiros 4 bits resolve a ambiguidade. Sem Version, o receptor teria que fazer "adivinhação" baseada em heurísticas — algo impensável em redes de alta velocidade.

Decisão de Pilha (Stack Decision)

Quando o sistema operacional recebe dados da Camada de Enlace (por exemplo, em uma placa de rede Ethernet), o driver lê o campo EtherType do frame (0x0800 para IPv4, 0x86DD para IPv6). Em seguida, o stack de rede:

1. Lê os primeiros 4 bits do payload (campo Version).
2. Se 0100 (4): entrega o pacote ao módulo IPv4 do kernel (net/ipv4/ no Linux).
3. Se 0110 (6): entrega ao módulo IPv6 (net/ipv6/).
4. Qualquer outro valor: o pacote é descartado como malformed e pode gerar log.

Isso permite que ambos os protocolos coexistam simultaneamente na mesma máquina e na mesma rede física (dual-stack, RFC 4213).

3. Por que o Campo Existe?

Compatibilidade Futura (Forward Compatibility)

A RFC 791 (1981) já previa que o IP evoluiria. Reservar 4 bits para versionamento é uma decisão de design de baixo custo (4 bits de overhead por pacote) que garante interoperabilidade por décadas:

• Um roteador IPv4-only ignora silenciosamente pacotes com Version ≠ 4 (não tenta processá-los).
• Um host dual-stack pode identificar a versão e rotear o pacote para a pilha correta.
• Uma futura versão experimental pode ser introduzida sem quebrar a Internet existente — basta atribuir um novo número de versão.

Negociação Implícita em L2/L3

Em redes Ethernet, o campo EtherType (L2) já distingue IPv4 de IPv6. Em redes não-Ethernet (PPP, Frame Relay, X.25), onde a demultiplexação L3 não tem campo equivalente, o Version assume a função completa de discriminação. Mesmo em Ethernet, o Version serve como confirmação defensiva: o receptor valida que o EtherType está coerente com o Version do payload. Se houver divergência, o pacote é descartado — prevenindo ataques ou bugs de configuração.

4. Contexto Histórico e Outras Versões

Embora o valor 4 seja o padrão dominante da Internet atual, a existência deste campo reflete a visão de longo prazo dos criadores do protocolo, definido na RFC 760 (1980) e consolidado na RFC 791 (1981), que previram a necessidade de atualizações futuras:

A escolha do número 6 para o IPv6 foi deliberada: ele foi originalmente designado como IPng (IP Next Generation) em 1994 (RFC 1752) e o número 6 foi selecionado pelo IETF IPng Working Group para enfatizar que era a sexta versão da família IP — embora versões 5, 7, 8 e 9 já houvessem sido tentadas ou reservadas.

5. Análise Prática no Wireshark

Ao capturar um pacote com Wireshark, o campo Version é mostrado como o primeiro item sob a seção "Internet Protocol Version 4":

Frame 1: 74 bytes on wire
Ethernet II, Src: 00:1a:2b:3c:4d:5e, Dst: 00:50:56:c0:00:08
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 8.8.8.8
    0100 .... = Version: 4            ◄--- primeiro nibble
    .... 0101 = Header Length: 5 (20 bytes)
    Differentiated Services Field: 0x00 (DSCP: CS0)
    Total Length: 60
    Identification: 0x1234 (4660)
    Flags: 0x40 (Don't Fragment)
    Time to Live: 64
    Protocol: ICMP (1)
    Header Checksum: 0x5a1c
    Source Address: 192.168.1.10
    Destination Address: 8.8.8.8

O Wireshark faz bitwise AND com 0xF0 e desloca 4 bits à direita para extrair o Version. O outro nibble do mesmo byte (& 0x0F) extrai o IHL.

No tcpdump

tcpdump -ni eth0 -vvv 'ip' 2>&1 | head
# Output:
# 14:23:01.123456 IP (tos 0x0, ttl 64, id 4660, offset 0, flags [DF],
#                  proto ICMP (1), length 60)
#     192.168.1.10 > 8.8.8.8: ICMP echo request

O tcpdump já assume IPv4 quando o filtro é 'ip' — porque o filtro BPF ip compilado corresponde a ether proto 0x0800 em Ethernet, garantindo que o campo Version será lido depois.

6. Comportamento de Roteadores e Stacks Diante de Versões Incomuns

Em Linux (kernel moderno)

O stack net/ipv4/ip_input.c valida estritamente:

if (iph->ihl < 5 || iph->version != 4)
    goto inhdr_error;

Pacotes com Version ≠ 4 recebidos via interface configurada para IPv4 são descartados silenciosamente (sem ICMP) e contados em /proc/net/netstat (InHdrErrors).

Em Roteadores Cisco IOS

*Sep  1 12:34:56.789: %IOSXE-3-PLATFORM: F0: cpp_cp_... :
IP header version 6 != 4 — discarding packet

Roteadores com CEF (Cisco Express Forwarding) fazem a verificação em hardware (ASIC) e descartam pacotes malformados em microssegundos, sem impacto na CPU.

Em IPv6

O campo Version também existe em IPv6 — também nos primeiros 4 bits, com valor 6. A semântica é idêntica: discriminar o formato do datagrama. Roteadores dual-stack examinam esses 4 bits para decidir a pilha.

IPv6 Header (RFC 8200):

+---------+---------+----------------+----------------+
| Version | TC      | Flow Label                     |
| (4 bits)| (8 bits)| (20 bits)                     |
+---------+---------+----------------+----------------+
| Payload Length (16 bits)  | Next Hdr | Hop Limit   |
+---------------------------+----------+--------------+
| Source Address (128 bits)                          |
+-----------------------------------------------------+
| Destination Address (128 bits)                      |
+-----------------------------------------------------+

7. Por Que Apenas 4 Bits?

A escolha de 4 bits para Version foi uma decisão de economia de espaço na década de 1980, quando cada bit era precioso em links de 56 kbps. Com 4 bits, há 16 versões possíveis — suficiente para cobrir todas as versões experimentais atribuídas até hoje (0–9) e ainda deixar 6 valores (10–15) reservados para o futuro distante.

Se 8 bits tivessem sido escolhidos, o overhead de 4 bits extras por pacote seria desprezível em links modernos, mas em 1981 isso representava ~0,3% de um datagrama típico de 576 bytes — desperdício inaceitável para a tecnologia da época.

8. Conclusão

O campo Version é aparentemente trivial, mas é o guardião da interoperabilidade entre gerações da Internet. O valor 4 identifica de forma inequívoca um datagrama IPv4 e instrui o receptor a aplicar a semântica da RFC 791 (com updates). Em IPv6, o mesmo conceito existe com valor 6, permitindo a coexistência das duas versões em dual-stack. A rigidez do valor 4 neste campo é o que impede que um pacote IPv4 seja mal interpretado como outra coisa, garantindo a integridade da comunicação no nível de rede. O Version é, portanto, o primeiro passo defensivo do processamento IP — sem ele, nenhuma outra operação seria possível.