Resumo

  • RFC 1326 tratou da encapsulação mútua: uma rede carregava X dentro de Y e outra carregava Y dentro de X. Um loop de roteamento podia acumular as duas camadas antes de qualquer saída.
  • Se o cabeçalho novo não preservasse a contagem anterior de saltos, o pacote interno ganhava repetidamente uma vida externa nova. Ao atingir a MTU, ele se fragmentava e os fragmentos repetiam o processo.
  • Preservar contadores, examinar camadas ou proibir certos aninhamentos tinha limites. A segurança da composição exigia um orçamento que diminuísse em toda fronteira.

A adaptação funcionava no lugar errado

O túnel comum fazia um acordo estreito. Um pacote do protocolo X precisava atravessar um backbone que entendia Y. O roteador de entrada acrescentava um cabeçalho Y, o núcleo entregava o invólucro a uma saída e a saída recuperava X. O mecanismo não afirmava que Y entendia o conteúdo; apenas oferecia transporte.

RFC 1326 observou que a relação podia existir nos dois sentidos em diferentes partes da Internet. Citou IP sobre AppleTalk e AppleTalk sobre IP, num período em que IP, CLNP, IPX, DECNET e protocolos proprietários precisavam conviver. Cada conversão respondia a uma barreira real.

O problema começava quando um loop transitório unia os sentidos. X virava Y<X>. Em vez da saída de Y, chegava a uma entrada que precisava atravessar X e virava X<Y<X>>. Ao retornar ao primeiro tipo de fronteira, recebia outro Y: Y<X<Y<X>>>.

Nenhum registro local precisava ser falso. O roteador podia provar que o próximo enlace exigia sua camada. Mas a capacidade de tornar um enlace utilizável não provava avanço rumo ao destino. A ação correta para a vizinhança tornava-se combustível do erro sistêmico.

Uma vida antiga dentro de uma vida nova

Loops normais são limitados por TTL ou contagem de saltos. O caso construído pelo RFC pressupunha que a encapsulação seguinte não preservava o contador anterior. O valor velho permanecia dentro da carga, enquanto a rede externa lia o valor recém-criado.

O campo visível respondia apenas quanto restava à camada atual. Não dizia quantas vezes o pacote original já passara por entradas de túnel. Se cada camada externa começasse com um orçamento cheio, nenhuma delas media o percurso acumulado.

Traduzir valores entre protocolos tampouco era neutro. RFC 1326 lembrou que X.25 e SMDS não tinham contagem de saltos, e que AppleTalk admitia no máximo 16 enquanto IP podia chegar a 256. Forçar tudo ao intervalo menor poderia interromper o ciclo, mas também produzir buracos negros em caminhos IP legítimos com mais de 16 saltos.

O tamanho virou quantidade

Cada volta acrescentava bytes. Até a MTU, a falha era crescimento de um objeto. Depois dela, o pacote era fragmentado. Os fragmentos continuavam presos à mesma relação de rotas, ganhavam cabeçalhos e podiam fragmentar novamente.

A “explosão exponencial” do texto era essa multiplicação recursiva, não uma explosão física e não uma ocorrência de ataque. O documento era Informational e declarou que não discutia questões de segurança. Sua hipótese técnica não autoriza acrescentar invasor, vítima ou incidente que a fonte não registrou.

O efeito mais grave surgia quando os pacotes em loop saturavam o enlace e faziam atualizações de roteamento ou mensagens de gestão serem descartadas. O tráfego defeituoso removia o feedback de que a rede precisava para corrigir a rota. Recuperação automática e capacidade de dados deixavam de ser problemas separados.

RFC 1326 dizia que os pacotes seriam rapidamente eliminados depois que o loop fosse rompido. Isso não é evidência de uma recuperação observada. Romper a rota, esvaziar o tráfego e restaurar o serviço ao usuário exigem registros distintos.

O inspetor encontrava o limite do próprio conhecimento

Uma solução era levar a contagem de saltos para o novo cabeçalho. Ela dependia de campos compatíveis. Outra era olhar para dentro: ao encontrar X já contido em Y<X>, o roteador evitaria acrescentar outro X.

Mas uma camada desconhecida podia impedir a inspeção. Criptografia podia ocultar o interior. Um protocolo de rede podia ser carregado dentro de um protocolo de transporte. E uma composição legítima podia conter duas camadas da mesma família. Repetição era um indício, não uma sentença universal.

O RFC terminou preferindo cautela combinada: desencorajar encapsulação mútua, vedar sua forma aninhada, preservar contadores e inspecionar quando apropriado. A lista reconhecia que nenhuma autoridade local possuía conhecimento completo sobre todos os invólucros possíveis.

Depois, o aninhamento ganhou seu próprio contador

RFC 2003 especificou IP dentro de IP. Quando encapsular faz parte do encaminhamento, o TTL interno é reduzido uma vez, e um datagrama com TTL zero não pode ser encapsulado. O encapsulador também rejeita casos definidos em que a origem coincide com ele próprio ou com o destino do túnel.

RFC 2473 separou, para túneis IPv6, o hop limit do pacote original do Tunnel Encapsulation Limit. O primeiro acompanha o encaminhamento do original; o segundo diminui a cada camada aninhada. Em zero, nenhum novo túnel pode ser iniciado antes da saída do atual.

O ganho não foi apenas numérico. A nova grandeza passou a medir o evento que criava o risco. Encaminhar e encapsular não eram mais tratados como se produzissem a mesma evidência. O mesmo RFC reafirmou que fragmentar um pacote de túnel já fragmentado dobra o número de fragmentos.

Fontes

As fontes comprovam status documental, mecanismos descritos e respostas posteriores. Não comprovam incidente em 1992, túnel atual, agente malicioso, falha de fabricante, adoção, prejuízo ou reparo bem-sucedido.