Resumo

  • A RFC 3361 deu à opção 120 do DHCPv4 duas codificações mutuamente exclusivas: uma lista preferencial de nomes DNS ou uma lista ordenada de endereços IPv4 para proxies SIP de saída.
  • O nome podia delegar ao DNS transporte, porta, instância e substituição; o endereço congelava uma ordem de hosts. Nenhuma concessão, por si, demonstrava a transação SIP ou o caminho completo da chamada.

Configuração chega antes da experiência do usuário e, por isso, costuma receber crédito pelo que ocorre depois. Um terminal obtém sua concessão, encontra um proxy SIP local e parece pronto. Ainda faltam resolver o nome, escolher o transporte, alcançar o proxy, preservar o estado da transação, atravessar os próximos saltos, negociar a sessão e fazer a mídia passar.

Publicada no Standards Track em agosto de 2002, a RFC 3361 definiu a opção 120 do DHCPv4 para localizar um proxy SIP de saída local. Em certas redes o cliente podia contatar diretamente o destino de um URI SIP. Em outras, inclusive com firewalls, precisava usar um servidor local para solicitações externas. DHCP era uma das soluções; configuração manual continuava possível.

Depois do código e do comprimento vinha um byte de codificação. Zero indicava uma sequência de nomes de domínio. Um indicava um ou mais endereços IPv4 binários. Todas as implementações tinham de aceitar os dois formatos, embora o documento preferisse nomes.

Não eram representações equivalentes. Um domínio acionava o procedimento de localização da RFC 3263. NAPTR podia anunciar transportes; SRV podia identificar instâncias, portas, prioridades e pesos; A ou AAAA entregava endereços ou servia de fallback. O cliente cruzava a oferta do domínio com as próprias capacidades e política. O nome delegava escolhas posteriores a um grafo de serviço que podia mudar.

A lista IPv4 carregava menos contexto. Os endereços vinham por ordem de preferência, mas a opção não incluía serviço NAPTR, porta SRV, prioridade, peso ou metadado de transporte. Era uma sequência congelada de hosts candidatos. Alterá-la exigia mudar a configuração DHCP e redistribuí-la.

A forma escolhida decidia onde ficava o poder de alteração. Com domínio, o administrador DNS podia mover instâncias ou ajustar registros sem renovar a concessão. Com literais, o administrador DHCP controlava mais diretamente os candidatos. Nenhum controlava sozinho versão do cliente, cache, transportes, política ou condição real do proxy.

A RFC 3361 também deu função específica a vários nomes. Eles deveriam indicar domínios NAPTR diferentes, inclusive fornecedores distintos, em vez de substituir vários registros A do mesmo domínio. O cliente os tentava na ordem entregue e só avançava se o contato falhasse, não houvesse transporte comum ou sua política proibisse aquele domínio.

Assim surgiam ordens encaixadas. DHCP ordenava fornecedores. NAPTR selecionava serviços de transporte. SRV aplicava prioridade e peso às instâncias. A resolução fornecia endereços. Capacidade e política do cliente retiravam opções. O host final comprimia decisões tomadas em várias superfícies administrativas.

A RFC 3263 demarcava quando a escolha devia parar. Após contato bem-sucedido com um servidor numa transação SIP, retransmissões, CANCEL e ACK de resposta final não 2xx precisavam voltar ao mesmo servidor. A descoberta podia variar antes do contato; a afinidade protegia o estado depois.

O formato criou ainda uma proibição semântica. O servidor não podia misturar nomes e endereços numa mensagem, mesmo usando duas ocorrências da opção 120. O processamento DHCP concatena ocorrências repetidas antes de interpretar seu conteúdo. Fragmentos válidos em gramáticas diferentes virariam um único valor incorreto.

A RFC 3396 definiu depois a ordem dessa concatenação e permitiu repartir opções longas entre ocorrências e campos sobrecarregados. Registrou também que muitos agentes DHCP implantados não remontavam opções partidas. O emissor podia obedecer ao padrão e ainda encontrar um cliente incapaz de reconstruir o valor.

A própria RFC 3361 exigia esse mecanismo para uma lista de domínios maior que uma ocorrência. Antes da primeira consulta DNS, uma lista longa já dependia da ordem de fragmentos, da sobrecarga de campos e da implementação do receptor. Provar que o servidor enviou todos os bytes não provava que o cliente leu a mesma lista.

A RFC 3319 adotou outra arquitetura para DHCPv6 no ano seguinte. Criou dois códigos, um para domínios e outro para endereços IPv6. Explicou que o DHCPv6 não sofria falta de códigos, portanto podia retirar o byte de codificação. As opções ficaram menores, mais simples, melhor alinhadas, e o cliente podia solicitar a forma desejada. Escassez no registro DHCPv4 havia virado complexidade em cada mensagem.

O formato de nomes usava rótulos da RFC 1035 e exigia compressão DNS, em parte para acomodar futuros mecanismos internacionalizados. Abaixo dele, SRV da RFC 2782 e NAPTR formalizado pela RFC 3403 realizavam seleção de serviço. A opção pequena apontava para mecanismos maiores e independentes.

Essa indireção ampliava flexibilidade e confiança. A RFC 3361 alertou que uma resposta DHCP inserida ou modificada poderia enviar o agente a um proxy malicioso, interceptar pedidos ou negar serviço. Também poderia omitir nomes que resolveriam para servidores SIP com TLS. A mensagem não transportava a chamada, mas podia escolher a primeira porta da sinalização e retirar alternativas seguras antes da escolha.

O registro atual da IANA ainda associa o código 120 à SIP Servers DHCP Option. A linha prova coordenação do número, não uso atual, suporte do cliente, entrega na rede ou disponibilidade do proxy.

Uma concessão observada também tem alcance limitado. A captura prova bytes e formato. Não prova respostas DNS, interseção de transportes, conexão, aceitação da transação, roteamento posterior, negociação nem mídia. Cada camada precisa de recibo próprio.

No DHCP, preservar servidor, relay, bytes, forma, ordem e vigência. Para nomes, preservar NAPTR, SRV, A/AAAA, TTL e escolha filtrada. Para endereços, preservar tentativas, porta e transporte. Depois registrar separadamente contato do proxy, resposta SIP, salto seguinte, descrição de sessão e fluxo de mídia.

Dois textos de Lu Heng são lentes editoriais declaradas. “Minimum Initial Specification” ajuda a entender o valor de uma opção comum estreita que deixa fornecedor, DNS e implantação para decisões locais. “Reality Layers” separa código registrado, configuração entregue, serviço resolvido, implementação em execução e resultado da chamada. Não são alegações sobre autoria ou intenção da RFC 3361.

A opção 120 criava um encontro, não uma conclusão. Seu byte escolhia entre delegar decisões ao sistema de nomes ou fixá-las parcialmente numa fila de endereços. A concessão dizia onde a sinalização começava. As provas seguintes diziam se ela continuava.

Fontes