Resumo

  • A IEEE Registration Authority atribui EtherTypes e LSAPs e entregou à IANA o OUI 00-00-5E; a IANA só administra os subespaços definidos sob essa delegação.
  • Um número de protocolo de dois bytes depois do OUI da IANA não é um EtherType. Portador, OUI e valor interno formam uma única identidade auditável.
  • A RFC 9542 separa registro, política de aprovação, especificação, implementação, pacote observado e resultado da aplicação.

O dado incorreto não parecia incorreto. Tinha valor hexadecimal, descrição e link para uma página oficial. Faltava apenas aquilo que determinava a autoridade: os bytes anteriores.

Na sequência 88-B7-00-00-5E-00-42, 0x88B7 é o OUI Extended EtherType atribuído pela IEEE Registration Authority. 00-00-5E é o OUI que a IEEE concedeu à IANA. 0x0042 é um número de protocolo dentro desse OUI, reservado pela IANA para exemplos em documentação. Transformar o último par em “EtherType 0042” não resume o pacote; muda sua proveniência.

A RFC 9542 foi publicada em abril de 2024 como BCP 141 e tornou obsoleta a RFC 7042. Não criou registros IANA novos e não alterou atribuições existentes. Seu trabalho mais importante é demarcar um limite: administrar um subespaço recebido não equivale a controlar o campo inteiro que o transporta.

A posição vem antes do nome

EtherType é um identificador de 16 bits com valor igual ou superior a 0x0600. No Ethernet II simples, aparece depois dos endereços MAC, embora tags possam acrescentar outros campos. A IEEE RA é a autoridade de atribuição.

O formato LLC usa um campo de comprimento seguido por dois LSAPs de oito bits. No SNAP, AA-AA-03 antecede um OUI de três bytes e um número de protocolo de dois bytes. Quem possui o OUI decide o significado desse número interno.

O EtherType 0x88B7 oferece outro invólucro: depois dele vêm OUI e número de protocolo. Em 88-B7-00-00-5E-qq-qq, a IEEE atribuiu o portador e o OUI; a IANA administra qq-qq porque é a titular daquele OUI. O tamanho idêntico dos campos externos e internos não unifica os livros de registro.

No SNAP, um OUI todo zero permite transportar um EtherType arbitrário. Ali, os dois bytes finais realmente são o EtherType. Com 00-00-5E, eles são um número sob a IANA. Uma base que descarta o OUI perde a informação necessária para escolher entre essas interpretações.

A página que exibe não é sempre a entidade que atribui

O grupo “IANA OUI Ethernet Numbers” reúne os números que a IANA atribui sob seu OUI. O registro SNAP nele contido marca 0x0042 como valor de documentação. É uma declaração dentro da competência da IANA.

O site também publica “IEEE 802 Numbers”. A seção de EtherTypes afirma que eles não são atribuídos pela IANA, descreve a lista como informação contribuída e não verificada e aponta para a IEEE RA. Hospedar uma visão histórica ou conveniente não transfere a autoridade de emissão.

Esse aviso some facilmente na automação. Um coletor extrai as linhas, ignora a nota, usa o domínio como proprietário e produz um catálogo tecnicamente bem formado. Assinatura, hash e controle de versão comprovam integridade depois da captura, mas não corrigem a leitura errada do mandato.

Se o catálogo alimenta políticas de segurança, a confusão passa a executar. Um exemplo documental pode ser aceito como protocolo padronizado; um EtherType experimental pode ganhar alcance global; uma entrada histórica pode sobrepor a fonte atual. O tipo de responsabilidade da página precisa ser um campo obrigatório.

A política de atribuição limita a delegação

Um novo número sob o OUI da IANA deve servir a um padrão IETF ou relacionado ao trabalho da IETF. Precisa ser documentado em Internet-Draft ou RFC e incluir um campo de versão em posição fixa, ou mecanismo equivalente que permita a versões antigas reconhecer versões futuras.

A aprovação normal ocorre por Expert Review. 0x0000 e 0xFFFF ficam reservados e exigem IESG Ratification. Além disso, um protocolo que já possua EtherType não pode receber outro número no OUI da IANA para a mesma finalidade. Ele usa o EtherType diretamente ou atrás do OUI zero no SNAP.

Essa vedação impede duas cadeias de autoridade para um único propósito. Sem ela, cada registro poderia evoluir em ritmo diferente, e o operador teria de descobrir qual identificador continuava válido sob qual procedimento.

As atribuições de endereços MAC sob 00-00-5E seguem o mesmo raciocínio. Devem atender a padrões, usar blocos alinhados em potências de dois e não servir para que fabricantes evitem obter seus próprios blocos da IEEE. A delegação resolve necessidades delimitadas; não transforma IANA numa IEEE paralela.

Valor de documentação não é valor de experimento

0x0042 no OUI da IANA existe para documentação. Em outros parâmetros organizacionalmente específicos, o adicional 0x42 também serve como exemplo. Assim, manuais e RFCs mostram bytes concretos sem colidir com uso real.

A IEEE reservou 0x88B5 e 0x88B6 como EtherTypes de uso experimental local. Eles pertencem a outro registro e carregam outra política. Chamar 00-00-5E-00-42 de “EtherType experimental” mistura o portador, o namespace e a finalidade.

A diferença interessa quando exemplos viram configuração. Um valor documental pode permanecer em produção; um experimento local pode atravessar um domínio administrativo. Guardar escopo, responsável e prazo junto com o valor evita que uma conveniência temporária vire dependência sem dono.

O registro não comprova a execução

A linha autoritativa mostra que um valor foi reservado ou atribuído em certo namespace. Não demonstra que um equipamento o interpretou corretamente, que a carga correspondeu ao rótulo nem que uma aplicação recebeu o efeito esperado.

Primeiro vêm os bytes, offsets, tags e comprimento. Depois, o portador e o OUI. O registro da IEEE ou da IANA comprova a atribuição; a revisão e a especificação comprovam as condições. Versão e configuração comprovam a implementação. A captura comprova um evento observado. O endpoint comprova o resultado.

Quando esses recibos são fundidos, a coordenação de unicidade vira uma falsa garantia operacional. Separá-los preserva a utilidade de cada ator. A autoridade de registro não precisa responder por todo parser, e o fabricante não pode usar o nome do registro para encobrir seu comportamento.

Um inventário que sobreviva à investigação

O inventário deve reter bytes brutos, posição, tags, portador, OUI completo, valor interno, proprietário do registro, fonte, data, classe de aprovação, documento, versão do parser e resultado. O nome amigável é um índice, não a prova principal.

Com isso, divergências ficam localizáveis. Uma lista informativa pode estar atrasada em relação à IEEE RA. Um número IANA válido pode receber rótulo errado no analisador. Um valor de documentação pode aparecer no tráfego real. Cada caso tem remediação própria e nenhum se resolve escolhendo a página mais conhecida.

O RFC não tenta criar um soberano dos números. Ele preserva uma topologia de responsabilidades. A IEEE controla o espaço direto; a IANA coordena o subespaço recebido; o código em funcionamento continua obrigado a demonstrar seu resultado. Só o identificador completo mantém essa fronteira visível.

Fontes