Resumo

  • O RFC 9685 permite que nós 6LoWPAN assinem endereços multicast ou anycast por meio de Neighbor Discovery e peçam que esse estado seja redistribuído por RPL.
  • Uma reinicialização pode apagar registros não persistidos; até que uma atualização ou renovação os reconstrua, a assinatura anteriormente aceita não prova alcance atual.
  • A evidência operacional deve separar admissão, validação, estado por origem, rota agregada, propagação, transmissão no enlace e confirmação da aplicação.

Às 09h12, o nó recebeu uma Neighbor Advertisement bem-sucedida. Às 09h19, o roteador reiniciou. Às 09h23, o painel ainda mostrava a assinatura como vigente porque seu prazo nominal terminaria apenas muito mais tarde. O primeiro pacote multicast depois da reinicialização, porém, nunca chegou ao ouvinte.

Não é necessário imaginar uma falha do padrão para explicar a sequência. O RFC 9685 define como um nó de rede restrita assina um endereço multicast ou anycast, como um roteador guarda os registros e como pode anunciar o endereço em RPL. Ele também reconhece que uma reinicialização pode eliminar estado não persistido e prevê pedidos assíncronos de atualização. O que ele não oferece é uma equivalência entre a validade temporal de um recibo passado e a existência presente de todas as estruturas que fazem o pacote chegar.

Essa diferença muda o modo correto de investigar. Se a organização começa pelo último status verde, ela tenta provar o presente com um evento histórico. Se começa pela cadeia de estado, pergunta qual roteador reiniciou, o que foi restaurado, qual origem renovou, quando a rota reapareceu e qual pacote foi efetivamente recebido.

O recibo de assinatura responde a uma pergunta estreita

O RFC 8505 criou o Extended Address Registration Option para registro de endereços em redes 6LoWPAN. O RFC 9685 usa uma forma especial desse mecanismo, chamada assinatura, porque vários nós podem legitimamente escutar o mesmo endereço multicast ou aceitar o mesmo endereço anycast. Não se trata de declarar propriedade unicast exclusiva.

No EARO, o campo P distingue multicast e anycast; o indicador R, separado, solicita comportamento de alcance. O identificador de transação, o tempo de vida e o Registration Ownership Verifier ajudam a amarrar a operação à origem correta. Quando necessário, EDAR e EDAC levam a validação ao 6LoWPAN Border Router. A proteção derivada do RFC 8928 reduz a possibilidade de outro nó corromper a identidade do registro.

Esse conjunto pode demonstrar que determinado pedido foi admitido. Não demonstra que o roteador ainda mantém o registro depois de uma falha de energia, que uma DAO já propagou o destino, que o Root replicou o pacote, que um rádio alcançou um nó adormecido ou que a aplicação processou o datagrama. Também não substitui uma autorização comercial de grupo: provar a continuidade de uma identidade de registro não decide a política do serviço.

Por isso, “assinatura ativa” é um rótulo grande demais quando a base é apenas a última NA(EARO). O registro exportável precisa guardar endereço, P, R, TID, ROVR, prazo solicitado, resultado EDAR/EDAC, status retornado, instante do aceite e identidade do roteador que manteve o estado.

A reinicialização abre uma lacuna entre prazo e presença

O tempo de vida define quando um registro deve expirar se nada mais acontecer. Ele não obriga um equipamento reiniciado a lembrar um estado que nunca foi persistido. Um sistema de observabilidade que calcula “ainda válido” a partir do instante de aceite e do prazo solicitado pode exibir coerência aritmética enquanto descreve um estado inexistente.

O RFC 9685 permite que um roteador que possa ter perdido ou deixado de aprender registros envie uma solicitação assíncrona de atualização. Essa é uma ação de recuperação, não uma confirmação retroativa. Se o pedido não for emitido ou não alcançar o nó, a reconstrução pode esperar a renovação periódica. Nesse intervalo, a última aceitação continua verdadeira como fato histórico e falsa como evidência de alcance atual.

O intervalo também não deve ser tratado como uma única indisponibilidade abstrata. Há pelo menos quatro relógios: a reinicialização do roteador, a descoberta de que o estado está ausente, a nova assinatura recebida e a reinjeção da rota. Medir somente o último pacote perdido apaga onde a recuperação parou.

Uma política de persistência traz outro limite. Restaurar uma cópia local depois do boot não prova que o restante do DODAG continua coerente com ela. A geração anterior pode ter expirado em outro salto, uma origem pode ter mudado de ligação ou um Root pode ter reconstruído sua tabela por uma sequência diferente. Persistência ajuda a continuidade; ela não elimina a necessidade de reconciliação.

Uma rota compartilhada não preserva a história de cada assinante

Vários assinantes podem apresentar o mesmo endereço. O roteador conserva estado por parte ou origem, mas funde os anúncios e injeta uma única rota. Para o plano de controle, essa compressão é econômica. Para auditoria, ela é um ponto de perda se os registros por origem forem descartados.

O problema aparece claramente nos tempos de vida. Quando há pedidos de alcance para o mesmo endereço, a injeção usa o maior prazo ainda ativo. Um assinante pode desaparecer, expirar ou não se recuperar depois da reinicialização enquanto outro, com prazo maior, mantém a rota agregada. Ver a rota depois do boot não comprova que o ouvinte investigado voltou.

Também vale o inverso. A aceitação do novo registro e a injeção da rota são assíncronas. A NA pode chegar primeiro; a DAO e o estado correspondente, depois. Um operador que exige simultaneidade inventa uma garantia que o protocolo não fez. Um operador que nunca mede a defasagem aceita um ponto cego evitável.

O registro mínimo de recuperação precisa preservar cada origem, seu tempo restante antes da falha, o que foi restaurado ou reaprendido, o conjunto fundido depois do boot, o maior prazo efetivo e os instantes de retirada e nova injeção. Uma linha por endereço não basta para reconstituir qual ouvinte sustentava qual decisão.

Storing e Non-Storing recuperam cadeias diferentes

No modo Storing de RPL, as DAO formam estado ao longo de pais preferenciais. Para multicast, os roteadores marcam uma árvore e enviam quadros MAC unicast individuais pelos ramos, exceto de volta ao vizinho de origem. Depois de uma reinicialização intermediária, uma entrada no Root não comprova que todos os ramos voltaram a existir.

No novo modo multicast Non-Storing, o Root faz replicação na entrada e encapsula cópias rumo aos 6LR de trânsito, usando o mecanismo de roteamento pela origem associado ao RFC 9008. Nesse desenho, a recuperação precisa provar que o Root reaprendeu o destino e que o 6LR final recuperou o assinante. Um desses fatos não substitui o outro.

Anycast toma outra decisão: entre várias assinaturas, um pacote segue para apenas um filho ou nó anunciado. Depois da recuperação, uma seleção bem-sucedida de outro candidato pode manter o serviço agregado enquanto o assinante originalmente esperado permanece ausente. “O endereço respondeu” não identifica quem foi escolhido nem a política que fez a escolha.

O RFC 6553 fornece comportamento de opções RPL, e o RFC 9010 integra registros e RPL em 6LoWPAN. Nenhum deles transforma uma entrada de controle em recibo de aplicação. Da mesma forma, MLDv2 no RFC 3810 e MPL no RFC 7731 têm estados próprios; sua presença no ambiente não autoriza misturar evidências de máquinas diferentes.

O último salto continua sendo uma fronteira

Mesmo com a rota reconstruída, a entrega ainda depende do enlace. Broadcast MAC direto pode ser pouco confiável, e broadcast assíncrono pode obrigar um ouvinte adormecido a permanecer acordado. O RFC 9685 orienta o 6LR, quando possível, a enviar quadros MAC unicast individuais aos nós assinantes.

Uma orientação de encaminhamento não é uma observação. O roteador pode enfileirar o quadro enquanto o nó dorme, esgotar tentativas ou receber uma confirmação de enlace sem que a camada de aplicação aceite o conteúdo. O pacote pode alcançar a interface correta e ser descartado por filtro superior. A aplicação pode recebê-lo e não produzir o efeito de negócio que a liderança chama de “entrega”.

A cadeia probatória deve, portanto, continuar depois da DAO: escolha anycast ou conjunto de replicação multicast, próximo salto, transmissão, confirmação de enlace quando disponível, recepção IP, confirmação da aplicação e resultado do serviço. Se um desses recibos falta, o relatório deve mostrar a lacuna em vez de preencher tudo com o status da assinatura.

Migração e escopo não curam estado perdido

O RFC 7346 fornece a linguagem de escopo multicast. No RFC 9685, Realm-Local pode corresponder a um DODAG; Admin-Local cobre o caso de instâncias federadas. O escopo correto restringe onde o pacote deve circular, mas não prova que cada roteador necessário restaurou estado.

O MOP 5 também não pode ser ligado em uma instância viva como simples opção. É preciso criar outra instância e migrar nós. Em ambiente existente, multicast e anycast podem usar uma instância enquanto unicast legado permanece em outra. Se a organização trata a mudança como atualização local, ela ignora simultaneamente capacidade do dispositivo, densidade de 6LR compatíveis, limites de múltiplas instâncias e evidência de migração.

Essa disciplina conversa com a especificação inicial mínima: o protocolo comum deve permitir interoperabilidade sem fingir decidir cada implantação. As camadas da realidade impedem que “aceito”, “anunciado” e “recebido” virem uma só palavra administrativa. A primazia do código em execução recoloca a observação no caminho que realmente encaminhou o pacote.

O valor do RFC 9685 está justamente em reduzir autoridade desnecessária: uma RPL-Unaware Leaf pode solicitar serviço sem passar a injetar mensagens RPL. A governança deve manter a mesma separação. Neighbor Discovery admite a assinatura. RPL redistribui alcance. O enlace tenta entregar. A aplicação confirma o resultado. Uma reinicialização mostra por que nenhum desses verbos pode falar pelos demais.

Fontes