Resumo

  • A RFC 9762 põe no PIO uma preferência positiva e específica por prefixo: um cliente compatível deve tentar DHCPv6 Prefix Delegation antes de formar novos endereços individuais de um prefixo compartilhado que também permite SLAAC.
  • P=1 não é uma concessão. Uma conclusão defensável precisa separar RA recebido, decisão do cliente, Reply do DHCP, adequação do prefixo, binding e rota do relay, filtro, seleção de origem e primeiro salto, tráfego e resultado da aplicação.
  • A ausência de P não significa que DHCPv6-PD esteja indisponível. A presença do bit, por sua vez, herda o limite de confiança dos Router Advertisements e pode ser abusada para atrasar configuração ou provocar REBIND repetido.

O servidor DHCPv6 respondeu com um prefixo. O cliente aceitou o IAPREFIX e criou um endereço. No painel de endereçamento, todas as etapas estavam verdes. Mesmo assim, nenhum pacote de retorno chegava ao host.

No primeiro roteador, a rota para o prefixo delegado não havia sido instalada.

Esse incidente hipotético separa duas autoridades que RFC 9762 nunca uniu. O bit P diz ao cliente qual mecanismo tentar antes de criar um endereço difícil de retirar. A resposta DHCP concede estado ao cliente. O relay e o primeiro salto ainda precisam projetar esse estado no encaminhamento. Uma etapa não assina a seguinte.

O nome “DHCPv6-PD Preferred Flag” favorece uma abreviação perigosa. Um monitor lê P=1 e mostra “delegação disponível”. Outro importa essa condição como “prefixo entregue”. Um terceiro presume conectividade. O fato observado na rede é menor: uma interface recebeu um RA, um PIO específico continha P, e um cliente que implementa PD ganhou uma razão para iniciar o protocolo.

O sinal precisa chegar antes do endereço

O posicionamento no PIO resolve um problema de tempo. Se o host formar endereços SLAAC do prefixo compartilhado primeiro, aplicações podem usá-los imediatamente. Quando um prefixo exclusivo chegar mais tarde, manter os dois conjuntos reduz o benefício de escala. Remover os endereços iniciais pode interromper conexões vivas.

Por isso, P=1 permite que o operador manifeste a preferência antes dessa bifurcação. Para clientes capazes, o alvo é o modelo por dispositivo descrito na RFC 9663: o host pede um prefixo próprio em vez de apenas mais um endereço do prefixo on-link. A preferência pertence ao PIO. Um prefixo global pode preferir PD e um ULA no mesmo RA pode continuar servindo SLAAC. Em multihoming, cada provedor pode anunciar uma escolha diferente.

P é independente dos bits M e O do RA. Alguns equipamentos mais antigos só iniciam DHCPv6-PD quando M ou O está ativo; uma rede que queira atendê-los pode precisar manter um desses sinais. O roteador também deve permitir configurar P separadamente do bit Autonomous A. Ativar ou retirar P não pode alterar A automaticamente.

Essa independência preserva a saída de emergência. P e A podem estar ativos ao mesmo tempo. Enquanto respeita P, o cliente trata A como não definido e evita novos endereços SLAAC daquele PIO. Se não conseguir um prefixo adequado, pode desativar o processamento de P na interface e voltar a SLAAC ou IA_NA, se a política local permitir. A RFC 4862 fornece as regras de autoconfiguração alteradas; a RFC 4861 fornece o contexto de Neighbor Discovery e RA. O novo bit modifica uma escolha, não substitui esses sistemas.

A preferência existe numa lista com relógio

Um cliente compatível mantém, por interface, uma lista de todos os prefixos recebidos em PIOs com P=1 e preferred lifetime diferente de zero. Quando a lista cresce de zero para um, ele deve começar a pedir prefixos, salvo se já estiver fazendo isso. Quando a vida preferida expira ou chega um PIO com vida preferida zero, a entrada sai da lista.

O movimento contrário é condicionado. Se a lista fica vazia, o cliente deve parar de pedir ou renovar somente quando não houver outro motivo para executar PD. As vidas dos prefixos já obtidos não mudam. O emissor do RA pode retirar a preferência; não pode cancelar por esse meio um lease ainda válido.

Quando a lista muda e já existem delegações, o cliente normalmente trata a alteração como nova informação de configuração e executa REBIND, exceto quando a lista passou a zero. A RFC 8415 define essa máquina de estados. Rebind, Reply, servidor, transaction ID, IA_PD e status são novos registros, e não propriedades ocultas do RA anterior.

O primeiro ledger operacional deve registrar origem do RA, interface, PIO, P/A/L, preferred e valid lifetime e geração da lista. Outro registro mostra se o cliente realmente enviou Solicit ou Rebind e qual política local tomou a decisão. Guardar apenas o valor corrente de P apaga a diferença entre expiração, retirada explícita, oscilação e perda de anúncios.

Uma Reply pode não oferecer um prefixo utilizável

O cliente deve enviar uma dica de comprimento curta o bastante para formar endereços por SLAAC. A resposta ainda pode ser inadequada. Um prefixo longo demais para SLAAC deve ser ignorado. Um prefixo mais curto pode ser aceito e dividido em prefixos mais longos de tamanho apropriado.

Nada no RA garante esse resultado. O servidor pode estar inacessível, o pool pode estar esgotado, uma política pode rejeitar o cliente ou a Reply pode trazer erro. Comprimento e lifetimes podem não servir. Após uma tentativa delimitada sem delegação adequada, o cliente pode deixar de processar P naquela interface e recorrer ao mecanismo alternativo.

Portanto, a prova de delegação liga o request e sua dica de comprimento ao servidor ou relay escolhido, à Reply, ao IAPREFIX, às vidas preferida e válida e à decisão de aceitação. “P foi visto” e “prefixo utilizável foi aceito” pertencem a registros diferentes.

A ausência também não concede uma conclusão inversa. P é um indicador puramente positivo. Um CE router descrito na RFC 7084, ou um host configurado para executar PD por padrão, não deve parar só porque nenhum PIO contém P. Falta de convite não é prova de falta de serviço.

O binding ainda precisa virar rota e filtro

No modelo da RFC 9663, o servidor delega e o primeiro roteador instala uma rota para o prefixo apontando para o endereço link-local do cliente. Para a infraestrutura, o prefixo é off-link. Isso permite manter uma rota por dispositivo, enquanto o host usa vários endereços ou entrega espaço a VMs, containers e interfaces internas.

Essa projeção depende de outro componente. A RFC 8987 exige que um delegating relay mantenha leases, next hops, rotas locais e filtros de ingresso, atualize-os com os tempos do DHCP, preserve ou retire estado segundo eventos definidos e exponha dados de troubleshooting. A Reply vista no host não prova que o relay instalou a rota. Uma rota em um roteador não prova que o par redundante conhece o binding. Uma entrada na RIB não prova entrega no data plane.

O cliente também tem obrigações. O prefixo delegado é off-link na interface pela qual foi recebido. O host não pode enviar de volta por essa interface um pacote destinado ao próprio prefixo, pois criaria loop. Uma rota de descarte de métrica alta é uma proteção possível. Para selecionar origem segundo a RFC 6724, os endereços formados devem ser tratados como associados à interface que recebeu a delegação.

Em multihoming, o cliente deve associar o prefixo ao endereço link-local do servidor ou relay que respondeu. Respostas redundantes com o mesmo prefixo podem exigir várias associações. A RFC 8028 mostra por que prefixo de origem e primeiro salto precisam permanecer compatíveis. Um endereço correto encaminhado ao upstream errado ainda falha.

A cadeia completa contém, portanto: RA recebido; geração da lista P; request DHCP; Reply aceito; lease; binding do relay; rota e filtro ativos; endereço formado; origem e primeiro salto escolhidos; pacote entregue; operação da aplicação concluída. A proximidade entre etapas não transfere autoridade.

Até o tráfego no mesmo link muda de forma

Com um prefixo exclusivo por cliente, o endereço global de outro cliente passa a ser off-link. O primeiro pacote entre dois dispositivos do mesmo domínio de broadcast vai ao roteador default. Um ICMPv6 Redirect pode indicar caminho direto; a RFC 9762 recomenda que hosts compatíveis processem Redirect salvo configuração contrária. Sem isso, o tráfego local pode ganhar latência.

Um teste para a Internet não cobre esse caminho. Delegação e upstream podem funcionar enquanto comunicação peer-to-peer, descoberta local ou tráfego lateral sujeito a ACL percorre uma rota inesperada. A validação precisa separar tráfego externo, tráfego entre clientes, ida e retorno.

O custo de infraestrutura também se desloca. A RFC 9663 troca mais espaço de prefixos e rotas por cliente por menos estado ND por endereço e fate sharing por dispositivo. A troca pode ser valiosa numa grande rede Wi-Fi e inviável numa residência que recebeu poucos /64. P expressa a preferência pela arquitetura; não comprova que o pool e o relay foram dimensionados.

O registro do bit não autentica o anunciante

O registro IANA dos bits do Prefix Information Option reserva o bit 3 para P e aponta para a RFC 9762. Isso resolve a sintaxe comum. Não demonstra que o emissor de um RA numa porta era autorizado.

Sem a proteção da RFC 6105, um atacante local pode emitir um PIO semelhante, definir P e fazer clientes compatíveis ignorarem A. Sem infraestrutura PD funcional, o host pode ficar sem endereço ou atrasar a configuração. A RFC 7113 mostra ainda que o rótulo “RA-Guard habilitado” não prova que fragmentação e extension headers não permitam evasão.

DHCP tem outro limite. Sem DHCPv6-Shield da RFC 7610, um servidor falso pode fornecer prefixos ou parâmetros inválidos. Mesmo quando RA e DHCP pertencem ao mesmo operador, são mensagens e pontos de execução distintos. A confiança numa não autentica a outra por associação.

Uma configuração defeituosa também pode alternar P. Cada mudança na lista pode causar REBIND e elevar carga. O rate limiting da RFC 8415 limita transmissão do cliente, mas não prova impacto zero. Eventos recebidos, transições locais e trabalho downstream devem ter contadores separados.

A autoridade pequena é uma propriedade, não um defeito

O valor de P está em resolver a ordem da decisão sem centralizar alocação, routing, filtros, fallback e resultado. A ideia de Heng Lu sobre especificação inicial mínima, decisão futura localizada e adoção voluntária descreve bem essa superfície comum estreita. A primazia do código em execução exige verificar o que cada componente fez. As camadas da realidade impedem que semântica, pacote, lease, rota e experiência sejam achatados numa única afirmação.

O bit continua útil quando a conclusão permanece do tamanho de sua autoridade.