Resumo

  • A RFC 3993 permite que um agente de retransmissão DHCP acrescente um Subscriber-ID atribuído pelo provedor, pensado para continuar estável quando o cliente usa outra rota física de acesso.
  • A norma transporta o valor, mas deixa sua atribuição e significado para a configuração do provedor; isso ajuda a manter políticas e também pode facilitar correlações de longo prazo.

A rota mudou; o cadastro não precisava mudar

Um servidor DHCP às vezes precisa decidir sobre um cliente que não enxerga diretamente. Em uma rede de acesso extensa, o agente de retransmissão recebe a difusão local do cliente e a encaminha a um servidor central. Ele pode acrescentar informação sobre o ponto em que a solicitação entrou na rede do provedor. Assim, o servidor atribui endereço e parâmetros sem exigir um servidor local em cada segmento.

O agente de retransmissão é mensageiro e observador. Publicada em 2001, a RFC 3046 criou um recipiente para informações do agente. Entre as primeiras subopções estavam Circuit-ID e Remote-ID: uma podia descrever o circuito de entrada, a outra um modem remoto. Esses valores ajudam a distinguir linhas e equipamentos, mas acompanham a topologia. Quando o cliente muda de rota, o identificador do circuito pode mudar mesmo que o provedor queira manter o mesmo tratamento administrativo.

Em 2005, a RFC 3993 acrescentou Subscriber-ID ao recipiente existente. O valor pode ser independente da estrutura física de acesso e foi pensado para permanecer estável quando o cliente muda de rota ou quando a rede evolui. O provedor pode usá-lo junto com os identificadores de circuito e equipamento, sem obrigar um único campo a representar as duas coisas.

O formato leva o valor; não o interpreta

A contenção da especificação é o ponto central. Subscriber-ID é uma cadeia NVT ASCII, transportada pela subopção 6, com um campo de comprimento de um octeto. Ela precisa ter pelo menos um octeto e não termina em NUL. Essas regras mostram ao receptor onde está o valor na mensagem. Não dizem o que os caracteres querem dizer.

A RFC 3993 deixa claro que o significado é específico do provedor. É ele que atribui o identificador; os mecanismos de atribuição e configuração ficam fora do escopo do documento. O agente pode ser configurado para incluí-lo. Um servidor compatível também pode usá-lo, junto com outros dados do agente e do cliente, ao atribuir endereço ou parâmetros. Nem a presença nem o uso são obrigatórios.

Essa divisão torna a etiqueta transportável, não universal. Um provedor pode associar o valor a uma conta de cobrança; outro pode usá-lo para um perfil de serviço. A RFC não exige nenhum desses modelos nem que a mesma cadeia indique a mesma coisa em outro domínio administrativo. Sozinha, uma mensagem DHCP não comprova a identidade de uma pessoa, aparelho, contrato ou direito de acesso. Essas relações ficam nos registros e nas decisões operacionais do provedor.

A mudança no pacote é pequena, mas a fronteira de controle é relevante. O cliente não se apresenta com uma identidade estável que ele próprio declarou. Um agente operado pelo provedor insere o campo, e um serviço central pode tomar decisões de endereço e configuração a partir dele. A autoridade do valor vem da relação de confiança e do mapeamento do provedor, não da grafia da cadeia.

A confiança torna a conveniência consequente

A opção de informação do agente depende da confiança entre o agente de retransmissão e o servidor. A RFC 3993 alerta que dados falsos podem contribuir para roubo de serviço, esgotamento de endereços escassos, negação de serviço ou configuração inadequada. A RFC 3046 descreve o retorno: o servidor que reconhece a opção a devolve ao agente, que a remove antes de responder ao cliente. É uma troca interna de controle do provedor, não um certificado de identidade entregue ao usuário.

Essa fronteira pode receber proteção adicional. A RFC 3993 menciona defesas de perímetro e recomenda proteção mais profunda por meio da subopção de autenticação do agente de retransmissão ou de IPsec. A RFC 4030 especifica a subopção de autenticação e procedimentos para detectar repetição de mensagens. A autenticação ajuda a confirmar que os dados vieram por um caminho aceito; ela não define o significado específico do provedor que a RFC 3993 deixou em aberto.

A estabilidade também tem um custo de privacidade. Um identificador de circuito pode revelar por onde a mensagem entrou; um identificador de assinante pode acompanhar o mesmo cadastro entre circuitos. A RFC 3993 alerta que o valor pode identificar um aparelho ou usuário se for exposto. A RFC 7819 trata Subscriber-ID como um possível identificador duradouro capaz de ligar atividades ao longo do tempo. A vantagem de reduzir reconfiguração pode ampliar o período em que registros são correlacionáveis.

A RFC 4580 levou ideia semelhante ao DHCPv6. Ela também deixa atribuição e significado fora da especificação e limita a troca prevista a um único domínio administrativo. Essa continuidade mostra um padrão de desenho, não que os identificadores de DHCPv4 e DHCPv6 sejam automaticamente equivalentes.

As RFCs documentam o mecanismo e os riscos que descrevem. Não provam quantos operadores o implantaram, se um cliente realmente mudou de rota com sucesso ou que controles de privacidade um provedor adotou. A história está nessa fronteira: o DHCP podia levar a etiqueta estável do provedor por uma topologia em mudança; o provedor continuava responsável pelo significado e pelas decisões tomadas a partir dela.

Fontes