Resumo

  • A RFC 3378 registrou EtherIP, que colocava um cabeçalho de 16 bits diante de um quadro Ethernet e o carregava em IPv4 com o protocolo 97.
  • O formato não oferecia autenticação, integridade interna, sequência, controle do túnel ou prevenção de laços. Decapsular provava chegada ao gateway, não uma LAN segura de ponta a ponta.

Uma LAN é mais do que os bytes do quadro. Cabos, switches, administração e a suposição de vizinhança tornam aceitáveis certas decisões locais. EtherIP preservava a embalagem enquanto removia sua localidade.

Publicada em setembro de 2002 como Informational, a RFC 3378 documentou um protocolo de 1991–1992 e a história do número IP 97. Ela recomendou o trabalho posterior de túneis de camada 2 e pseudowires para novos projetos.

Após IPv4 vinham quatro bits de versão três e doze bits reservados a zero. Depois seguia o quadro Ethernet ou IEEE 802.3 sem FCS. O receptor descartava valores errados, extraía o quadro, calculava um FCS novo e o enviava na LAN remota.

Isso verificava sintaxe, não confiança. O cabeçalho não identificava o emissor, autorizava a MAC ou justificava a travessia. Não havia sessão, sequência, negociação ou controle próprio da carga.

O FCS original terminava na entrada. A RFC avisou que o checksum IPv4 não protegia o quadro interno e esperava integridade de um protocolo superior. Um novo FCS válido na saída comprovava apenas o último enlace, mesmo se a carga tivesse mudado antes.

Uma estação podia selecionar quadros próprios. Um equipamento semelhante a ponte podia ouvir promiscuamente e aplicar regras sobre MAC, EtherType ou VLAN. Também precisava mapear a MAC destino ao IP do EtherIP remoto. Seleção e mapeamento eram configuração externa, não informação nos 16 bits.

Pontes criavam o risco de laço infinito. Gateways poderiam capturar e reinjetar o mesmo broadcast ou multicast sem fim. A RFC exigia topologia em árvore, mas deixou sua construção à pessoa que configurava as estações. Não havia spanning tree nem hop count para corrigir o erro.

Cada regra podia estar certa isoladamente e a composição ainda devolver o quadro ao segmento anterior. Contadores altos mostravam atividade, não progresso.

Permitir EtherIP em um firewall também podia abrir comunicações arbitrárias. Uma proteção fraca tolerada entre vizinhos locais ganhava alcance remoto. A RFC citou VRRP e sugeriu IPsec para o exterior.

RFC 2401 e sua sucessora RFC 4301 explicam IPsec. Ele pode autenticar pares e proteger trânsito, mas não valida a regra de captura, a árvore, a reinjeção ou o resultado da aplicação.

RFC 2003 e RFC 2784 oferecem comparações com IP-em-IP e GRE. RFC 3931, RFC 3985 e RFC 4448 mostram controles posteriores de L2TPv3 e pseudowire. Não são recursos retroativos nem prova de implantação de EtherIP.

RFC 2119 limita o sentido de MUST aos campos e descartes definidos. O registro IANA torna 97 interpretável, não autorizado ou popular. Pela lente de especificação mínima de Lu Heng, poucos bits podiam iniciar interoperabilidade; pelas camadas da realidade, seleção, encapsulamento, par, rota, integridade, saída e recepção exigem recibos separados.

EtherIP movia o envelope. A LAN continuava sendo topologia, autoridade, confiança e efeito físico. O caminho IP não carregava esses elementos automaticamente.

Fontes