Resumo

  • O rascunho ROLL de 28 de outubro solicita 0x0B para Response Spreading e 0x0C para DIO Option Request. O registro vigente da IANA já atribui esses valores, na mesma família de opções, a RREQ e RREP do RFC 9854. A revisão 02 fazia o mesmo pedido: o desencontro foi carregado adiante.
  • A marca N pretende trocar a redefinição dos temporizadores Trickle por uma resposta DIO explícita e única. O próprio rascunho reconhece que solicitações repetidas, restrições maliciosas e roteadores antigos ainda podem consumir bateria, tempo de rádio e processamento.

Duas ordens para o mesmo byte

O número de uma opção RPL diz ao destinatário como interpretar os bytes seguintes. No RFC 9854, 0x0B identifica RREQ e 0x0C, RREP; a tabela RPL Control Message Options da IANA confirma as atribuições. A seção 7.2 do novo texto pede os mesmos números para dois mecanismos diferentes. O rascunho avisa que os valores dependem de confirmação pela IANA. Esse aviso não produz um espaço extra no registro. Para um único campo, a implementação precisa de um único significado.

O conflito observado está entre documentos e registro, não em um pacote de produção demonstradamente decodificado de forma errada. A próxima revisão precisa de códigos livres ou de outra decisão explícita de codificação. A revisão 02 já pedia 0x0B e 0x0C. Portanto, a revisão 03 manteve uma falha existente em vez de criá-la.

Vale corrigir isso porque a economia proposta responde a um custo real. Pelo RFC 6550, um nó sem informação suficiente pode enviar por multicast uma DODAG Information Solicitation, a DIS. Roteadores vizinhos compatíveis tratam o pedido como inconsistência e redefinem seus temporizadores Trickle. Os DODAG Information Objects, ou DIOs, passam a ser emitidos com mais frequência por algum tempo. O solicitante obtém uma rota; outros aparelhos arcam com mais transmissões e recepção de rádio. Numa rede de baixa potência, a cortesia tem preço.

A marca No Inconsistency, N, muda o contrato. Ao receber uma DIS multicast com N, o roteador mantém os temporizadores Trickle correspondentes e manda uma DIO explícita. Uma resposta pontual deixa de provocar uma temporada de anúncios acelerados. A marca T pode direcionar a resposta por unicast. Response Spreading distribui as respostas no tempo, evitando que todos falem juntos. A marca R e DIO Option Request especificam as opções desejadas. Cada detalhe reduz o raio da pergunta.

Uma resposta única pode ser pedida cem vezes

O capítulo de segurança oferece a ressalva operacional concreta. Quem envia DIS repetidas pode continuar gastando energia, canal e CPU dos vizinhos. Restrições fabricadas para excluir todos podem atrasar a entrada na rede. Roteadores antigos podem continuar a redefinir Trickle pelo comportamento do RFC 6550. A proposta não acrescenta autenticação nem integridade; recomenda as proteções RPL existentes, validação de opções, limites de recursos e atenção à limitação de frequência.

O solicitante escolhe a pergunta, mas não paga toda a resposta. Essa assimetria explica tanto o projeto da marca N quanto o seu limite. O Datatracker classifica a revisão 03 como Internet-Draft ativo de grupo de trabalho, ainda não RFC. Códigos corrigidos e medições com nós novos e antigos sob solicitações repetidas mostrariam o tamanho da economia real.

Fontes