Resumo

  • O sucesso de IPV6_ADDR_PREFERENCES registra o desejo da aplicação, não a existência nem a seleção de um endereço com o atributo desejado.
  • Quando o atributo é obrigatório, a aplicação precisa provocar a seleção, ler o endereço, validá-lo e abortar se necessário; envio, caminho e conclusão continuam sendo fatos independentes.

Um chamado de conformidade é encerrado assim que setsockopt() retorna zero. O campo diz “origem temporária”. Ninguém verifica se havia uma origem temporária entre os candidatos.

O RFC 5014 foi desenhado justamente para manter a escolha flexível. Em vez de obrigar cada aplicação a reproduzir todas as regras de seleção IPv6, ele permite alterar algumas preferências e deixar o restante com a pilha. A opção IPV6_ADDR_PREFERENCES vale por socket e possui indicadores equivalentes para getaddrinfo().

Há três pares: home e care-of, temporário e público, CGA e não-CGA. A aplicação pode combinar eixos diferentes. Pedir os dois lados do mesmo eixo é contraditório: a opção retorna EINVAL, e a extensão de resolução retorna EAI_BADEXTFLAGS. Isso elimina uma instrução impossível, mas não cria o endereço solicitado.

O documento escolhe deliberadamente preferência, não requisito rígido. Se uma origem temporária não estiver disponível, uma pública pode ser escolhida. Se parte de uma combinação não existir, o atributo disponível ainda influencia a decisão e o padrão do sistema cobre o restante. Preferências sem suporte devem ser ignoradas silenciosamente. Um retorno positivo não revela se houve atendimento ou recuo.

O resolvedor compõe a mesma decisão. Como a origem esperada pode alterar a ordem dos destinos, a aplicação deve usar indicadores semanticamente iguais em getaddrinfo() e no socket. Valores diferentes tornam o comportamento indefinido. Guardar só o evento do socket perde a ordenação que antecedeu a conexão.

Uma origem explícita também vence. Se bind() ou IPV6_PKTINFO fixa um endereço, essa escolha tem precedência sobre a preferência. A configuração continua registrada, mas deixou de ser a autoridade efetiva.

Para uma exigência que não admite recuo, RFC 5014 define outra sequência. A aplicação repete os mesmos indicadores no resolvedor e no socket, manda a pilha escolher, lê a origem com getsockname(), verifica os atributos por inet6_is_srcaddr() e encerra a comunicação se o resultado não satisfizer a regra.

Nem toda chamada de seleção é neutra. Em TCP, connect() pode enviar um SYN antes da verificação. bind2addrsel() existe para vincular o endereço que seria escolhido para o destino sem emitir esse primeiro pacote. Em UDP, connect() pode efetuar a escolha local sem mandar um datagrama. Selecionado e transmitido são estados diferentes.

A validação retorna 1, 0 ou -1: endereço local que satisfaz todos os indicadores, endereço que não satisfaz, ou endereço/entrada inválidos. Mesmo o 1 não prova caminho remoto. O atributo home pode ser verdadeiro em um host sem Mobile IPv6 ou em um nó móvel que esteja em casa. Não é uma prova de localização física.

Os outros atributos também têm limites. O RFC 8981 reduz a janela de correlação simples baseada no mesmo endereço; não promete anonimato nas demais camadas. O RFC 3972 permite verificar a ligação entre CGA e material de chave, mas uma CGA não é uma identidade certificada. Preferir CGA não é validar assinatura ou autorização.

Há ainda o tempo histórico. RFC 5014 usava o RFC 3484, cuja regra favorecia origem pública. O RFC 6724 o substituiu e passou a favorecer a temporária nessa comparação. A evidência operacional deve registrar a política e os candidatos do host naquele instante.

Um comprovante robusto registra aplicação e socket, indicadores e valor anterior, consulta de resolução e ordem de destinos, capacidades ignoradas, candidatos, revisão da política, qualquer origem explícita, chamada de seleção, risco de envio prévio, leitura com getsockname(), resultado ternário da validação, decisão de avançar ou abortar e, separadamente, tráfego de saída, resposta e conclusão da aplicação.

Essa é uma recomendação de governança, não uma exigência oculta do RFC. Ela segue a disciplina de camadas de realidade de Heng Lu: intenção, escolha local, propriedade validada, rede e resultado de negócio não viram um único fato por conveniência do painel.

Fontes