Resumo

  • O mesmo endereço IPv6 de escopo limitado pode existir em zonas diferentes. Um host conectado a mais de uma delas fornece um zone index separado do endereço e usa esse valor somente para a decisão local de interface.
  • O RFC 6874 tentou colocar o ZoneID em URIs em 2013. O RFC 9844 tornou essa solução obsoleta em 2025 e passou a exigir que a interface de usuário receba, valide e converta a zona sem transformá-la em identidade portátil.

O erro que pede uma interface

Considere um notebook ligado à rede de manutenção por cabo e, ao mesmo tempo, a uma segunda rede isolada. Ambas podem conter fe80::1. Quando um utilitário pede a interface, ele não está solicitando parte ausente do endereço. Está perguntando qual instância local do alcance link-local o operador quer usar.

O RFC 4291 define que um endereço link-local vale em um único enlace. Roteadores não podem encaminhar para outro enlace pacotes cujo endereço de origem ou destino seja link-local. A repetição do valor em dois enlaces é compatível com essa fronteira.

Em 2005, o RFC 4007 separou scope de zone. Scope descreve o tamanho da região topológica; zone é uma instância concreta de uma região daquele tamanho. Há um conceito de alcance link-local, mas cada enlace conectado ao host é uma zona distinta.

O endereço não codifica a qual zona pertence. Se o nó participa de várias zonas do mesmo scope, ele cria índices próprios para diferenciá-las. Os índices são estritamente locais e não precisam coincidir nem mesmo entre vizinhos no mesmo enlace.

Assim, a pergunta “por onde sair?” só pode ser respondida no ponto de execução. Um inventário remoto pode conhecer a intenção, mas é o sistema local que conhece as interfaces presentes e a relação atual entre nomes, números e enlaces.

Uma string local ainda é entrada hostil

O RFC 4007 deixou conjunto de caracteres, comprimento e significado de identificadores não numéricos a cargo das implementações. Essa abertura acomoda sistemas diferentes, mas torna a validação responsabilidade de cada ferramenta.

O RFC 9844 recomenda um limite de tamanho apropriado e a rejeição de entradas perigosas como NUL. O erratum held 8553 do RFC 4007 registra a falta de restrições e aponta para a orientação nova.

O dado pode atravessar shell, formulário, arquivo de configuração, parser de URI, logger e API do sistema. Decodificação duplicada, truncamento ou normalização diferente pode fazer a interface exibida divergir do índice utilizado. Separar campos reduz a chance de uma camada interpretar endereço, delimitador e nome como uma única linguagem ambígua.

Uma operação bem-sucedida com %eth0 comprova apenas que, naquele host e naquele momento, o nome foi mapeado e a operação funcionou pelo caminho selecionado. Não autentica o equipamento remoto, não prova propriedade, não cria alcance global e não torna o nome reutilizável em outro host.

O seletor sempre esteve fora dos 128 bits

O RFC 3493, de fevereiro de 2003, mostra a divisão no formato da API. sockaddr_in6 contém sin6_addr para o endereço e sin6_scope_id para um seletor de 32 bits. O segundo campo não altera o primeiro; ambos são entregues separadamente ao kernel.

O mesmo documento define a conversão de nomes de interface em índices. if_nametoindex() consulta o host onde o processo está rodando. Um nome desconhecido retorna falha. Não existe resolução global para eth0, nem protocolo que peça ao destino para adotar a nomenclatura da origem.

Para uso humano, o RFC 4007 recomenda <address>%<zone_id>. Implementações devem aceitar números decimais não negativos e podem aceitar strings locais, como nomes de interface. A parte do endereço já revela o scope; o sufixo precisa apenas escolher uma zona daquele scope.

O texto também limita o uso. A forma não faz sentido para endereços globais e não deve ser usada com loopback. Ela deve permanecer dentro de um nó e não pode ser enviada pela rede, salvo acordo prévio entre todos os intérpretes sobre a semântica.

O zone identifier é consumido antes do pacote partir. Ele ajuda o remetente a construir a operação, mas não oferece ao receptor uma informação interoperável.

A volta ao ponto de controle correto

O RFC 9844, de agosto de 2025, tornou o RFC 6874 completamente obsoleto. Implementadores de navegadores consideraram a proposta impraticável. O novo documento também reverteu a atualização do RFC 3986; o erratum verificado 8552 registra a correção.

A obrigação atual recai sobre a UI. Uma interface que aceita endereço diferente de global unicast deve permitir que o usuário informe ou escolha o zone identifier. A forma completa com % é preferida, mas campos separados, listas, outros delimitadores e parâmetros independentes são alternativas válidas.

A aplicação mantém endereço e zona separados, converte a zona para um índice local e deve informar identificadores inválidos. POSIX inet_pton() não processa sozinho fe80::1%eth0. É necessário usar getaddrinfo() ou dividir a string e combinar inet_pton() com if_nametoindex().

O RFC 9844 exclui a semântica de URIs buscados por navegadores. Ele não redefine HTTP origin e não promete URLs link-local portáteis. Exige uma entrada local utilizável e segura, mantendo o zone identifier fora do endereço e fora do fio.

A revisão, portanto, preservou o recurso que o operador precisava e abandonou a identidade que o sufixo não podia sustentar.

Um default não transforma contexto em endereço

O RFC 4007 recomenda zonas padrão e normalmente usa zero para o default. Isso pode permitir que uma aplicação omita o seletor em ambientes simples. Mas o RFC 9844 registra que nem todo sistema oferece um default utilizável e cita Linux.

O sucesso sem sufixo não prova que o endereço bastava. Prova somente que, naquela execução, alguma regra local escolheu por ele. A mudança de plataforma, namespace de rede ou conjunto de interfaces pode retirar essa suposição.

Algo parecido ocorre com a forma textual. O RFC 5952 padronizou em 2010 escolhas de compressão de zeros, caixa de letras e uso de colchetes com portas. Isso reduz representações equivalentes do endereço.

O RFC 9844 observa, porém, que o RFC 5952 não cobre a extensão de zona. Canonizar fe80::1 não canoniza %eth0. Nomes e índices continuam pertencendo ao estado do host. Uma chave de banco de dados que concatena as duas partes mistura um valor de protocolo com uma referência operacional temporária.

Uma trilha útil preserva as camadas: endereço, identificador fornecido, índice resolvido, host executor e instante. Sem esses campos, não é possível saber se uma falha posterior veio do vizinho, da interface ou de uma antiga associação local.

O desvio pelo URI

O encontro com URIs criou um choque entre alcances. O RFC 3986, publicado em janeiro de 2005, organiza URIs como identificadores de alcance global, embora ações possam depender do contexto do usuário. Ele também reserva % para percent-encoding; o caractere percentual literal vira %25.

Em 2013, o RFC 6874 propôs, na parte entre colchetes de um URI HTTP, a forma [fe80::a%25en1]. O %25 representa o separador %, seguido do ZoneID. A intenção era permitir que navegadores e ferramentas baseadas em URI alcançassem dispositivos link-local.

O próprio RFC dizia que o ZoneID só era significativo no nó de origem e deveria ser removido antes de aparecer numa requisição HTTP enviada. Uma parte visível do URI precisava desaparecer quando a comunicação efetivamente cruzasse a rede.

Essa ambiguidade afetava mais do que parsing. O sufixo participaria de origin? Ficaria em favoritos e histórico? Seria enviado a proxy? Qual camada decodificaria %25, e quantas vezes? Um argumento local foi inserido numa estrutura que costuma ser persistida, comparada e compartilhada.

Trocar o delimitador não resolveria a diferença de autoridade. A interface e o kernel da origem entendem a zona; o servidor, a infraestrutura intermediária e outro host não compartilham necessariamente esse entendimento.

O percurso da intenção ao pacote

O zone identifier passa por uma cadeia curta. O operador expressa intenção; a UI valida; o sistema traduz para índice; o socket leva a escolha ao kernel; a camada IP aplica o limite de escopo. O pacote cruza a interface sem carregar o nome local.

Cada etapa deve produzir evidência proporcional. Aceitar texto não significa resolvê-lo. Resolver um índice não significa que a interface esteja ativa. Enviar um pacote não autentica quem respondeu. A simplicidade vem de manter essas afirmações separadas, não de resumi-las como “endereço correto”.

O endereço precisava saber por onde sair, mas essa informação nunca precisou viajar com ele. Deixar a escolha no host evitou coordenar nomes de interface pela Internet e permitiu que cada nó ajustasse sua topologia. O erro da ferramenta, ao pedir uma interface, era uma forma de honestidade arquitetural.

Fontes