Resumo

  • A RFC 3319 definiu duas opções DHCPv6 para localizar proxies SIP locais de saída: uma lista ordenada de nomes de domínio e outra de endereços IPv6.
  • Se ambas chegarem, o cliente deve preferir os nomes e aplicar as regras de localização SIP; as opções oferecem destinos candidatos, não comprovam confiança no proxy nem uma chamada completada.

A concessão de rede respondia a uma pergunta menor que a chamada

É fácil descrever errado o problema da RFC 3319. Um cliente SIP pode conhecer o endereço escrito no URI e ainda precisar de um proxy local de saída. Um firewall, o plano local de discagem, serviços de emergência ou outras regras podem tornar esse intermediário necessário. A configuração manual era uma possibilidade; a RFC acrescentou outra: o DHCPv6 poderia informar candidatos para a descoberta.

O limite está no papel do servidor. A RFC 3261 distingue agentes de usuário, proxies, servidores de redirecionamento e registrars. Na RFC 3319, “servidor SIP” significa especificamente o host que executa um proxy de saída. A presença desse host na resposta DHCP não mostra que o usuário se registrou, que o destino foi autorizado, que o diálogo SIP terminou, que a mídia foi negociada ou que a chamada funcionou.

Duas codificações, uma ordem de preferência

A opção 21, OPTION_SIP_SERVER_D, transporta uma lista de nomes de domínio; a opção 22, OPTION_SIP_SERVER_A, uma lista de endereços IPv6. Ambas são ordenadas por preferência, e uma implementação conforme deve oferecer suporte às duas. O cliente pode solicitar uma ou ambas na Option Request Option do DHCPv6. A resposta depende da configuração do servidor e do que foi solicitado. Mesmo diante de um pedido pelas duas, o servidor pode devolver apenas uma e deve favorecer a opção de nomes.

Quando recebe as duas listas, o cliente deve usar primeiro os nomes. A lista de endereços numéricos é uma alternativa condicional: só pode ser tentada quando nenhum nome da primeira lista puder ser resolvido ou alcançado. Isso é diferente de testar todos os endereços indiscriminadamente. O cliente também segue a ordem entre nomes, avançando se a tentativa anterior falhar, se não houver transporte comum ou se uma política local proibir aquele domínio.

Um nome alimentava a localização SIP, sem substituí-la

Os nomes entram no procedimento de localização de servidores SIP da RFC 3263. A RFC 3319 recomenda que apontem para registros NAPTR distintos, em vez de apenas registros A diferentes. Assim, um único servidor DHCP pode indicar proxies operados por provedores diferentes. A lista não substitui NAPTR nem SRV: ela oferece um ponto de partida; os mecanismos de localização e as regras de transporte ainda se aplicam.

Por isso, “alternativa” tem um sentido preciso. Um nome posterior não vira automaticamente reserva só por aparecer no pacote. O cliente chega a ele depois de uma condição de falha definida. Se também houver nomes, a lista numérica de IPv6 fica ainda mais adiante no caminho de preferência. A resposta entrega candidatos e ordem; resolução, transporte e política de uso continuam sob decisão do cliente.

Essa divisão do plano de controle era útil. A rede podia distribuir escolhas de serviço local sem fixar o mesmo proxy em cada cliente. Mas a resposta não dizia que um host listado estava respondendo, aceitava um transporte comum, autorizaria a solicitação daquele usuário ou sustentaria o restante da sessão. “Configurado como preferencial” e “usado com sucesso” são observações diferentes.

O ponto de configuração também pode redirecionar a confiança

A seção de segurança descreve o risco: se alguém modificar ou inserir uma resposta DHCP, o agente de usuário pode ser conduzido a um servidor SIP malicioso. Esse servidor poderia interceptar solicitações ou negar o serviço. Uma resposta adulterada também poderia retirar nomes que levariam a servidores capazes de usar TLS, facilitando a interceptação.

Esse é o modelo de ameaça da RFC, não um relato de incidente. O documento não afirma que qualquer endereço recebido seja autenticado nem que cada nome resolva para um serviço com TLS. A resposta DHCP faz parte da cadeia de confiança porque influencia para onde a aplicação envia a próxima mensagem de sinalização. Proteções, verificação de identidade e política do sistema mais amplo continuam necessárias. Encontrar um servidor não é autenticar sua identidade.

A opção antiga continua nos registros DHCPv6 mais recentes

A especificação geral de DHCPv6 evoluiu: a RFC 9915 substituiu a RFC 8415. Ainda assim, o registro IANA de códigos de opção DHCPv6 mantém os códigos 21 e 22 associados à RFC 3319; mais tarde, a RFC 9243 também fornece grupos YANG para configurar as duas formas de opção SIP. Isso demonstra continuidade em registros administrativos e modelos de dados, não adoção pelos operadores, suporte dos clientes, sucesso do fallback ou chamadas concluídas.

A contribuição da RFC 3319 foi mais estreita — e mais interessante — do que “DHCP encontra um servidor telefônico”. Ela formalizou uma descoberta ordenada de proxies locais de saída: nomes primeiro, endereços como alternativa sob condições específicas. A chamada permanece fora da opção. A descoberta pode apontar para onde enviar a sinalização, mas não certifica o que ocorre depois.

Fontes