Resumo

  • draft-ietf-snac-simple-12 automatiza a ligação de uma rede stub IPv6 à infraestrutura adjacente, com funções distintas para endereço, alcance e descoberta.
  • Em uma troca de roteador, um prefixo novo pode coexistir com endereços e rotas antigos ainda válidos; uma RA recente não prova a continuidade da aplicação.
  • Um recibo de transição deve guardar causa, estado, tempos de vida, rota vista pelo host, descoberta e transação feita com o endereço realmente escolhido.

Um único indicador para estados diferentes

O roteador SNAC existe para conectar redes de dispositivos restritos a links Ethernet ou Wi-Fi sem exigir que tecnologias incompatíveis virem uma só rede de camada dois. A revisão 12 combina Neighbor Discovery, prefixos on-link, RIO, DNS-SD, DHCPv6-PD e, quando necessário, NAT64.

O conjunto é automático, mas não atômico. Endereçabilidade significa que o host tem endereço útil. Alcançabilidade exige próximo salto e rota de retorno. Descoberta exige que nomes e serviços apareçam. A ação do usuário só termina depois que a aplicação conclui sua transação.

O prefixo adequado tem uma fonte que pode falhar

Na interface de infraestrutura, o roteador executa descoberta segundo o RFC 4861. Um prefixo adequado leva a STATE-SUITABLE; a ausência leva a STATE-BEGIN-ADVERTISING.

Adequação combina dois testes. Uma RA com idade superior a STALE_RA_TIME, dez minutos por padrão, deixa de valer como evidência. O vizinho que a enviou também precisa permanecer alcançável; sessenta segundos é o máximo padrão antes da verificação ativa.

Os testes cobrem panes diferentes. Um roteador pode responder como vizinho e parar de renovar RA. Uma RA pode ser nova e seu emissor cair logo depois. O conteúdo válido da mensagem não herda a vida operacional da origem.

Deprecar cria uma janela útil e perigosa

Ao fornecer o próprio prefixo, o SNAC anuncia vidas preferida e válida de trinta minutos. Se surge alternativa melhor, entra em STATE-DEPRECATING: mantém o prefixo, zera sua preferência e reduz sua validade. Se a alternativa desaparece, retoma o anúncio anterior.

Esse caminho reversível evita cortes desnecessários. Ele também garante que por algum tempo exista mais de uma verdade válida. Hosts receberam RAs em momentos diferentes, perderam multicasts diferentes e escolhem endereços de modo local. O estado do roteador não informa qual endereço cada sessão usa.

O RFC 8978 descreve a renumeração repentina na qual o novo prefixo chega sem retirada confiável do antigo. Seus valores de sete e trinta dias são do SLAAC geral, não os trinta minutos padrão do SNAC. O ponto comum é outro: validade temporal não equivale a caminho operacional.

O antigo proprietário volta como observador

Com dois roteadores, A pode sair depois de anunciar um prefixo e B assumir com outro. Quando A retorna, vê o prefixo adequado de B e não volta a anunciar o antigo. Mas alguns hosts ainda mantêm endereços de A.

Pacotes para esses endereços podem chegar a A, que já não considera o prefixo on-link. Ele pode enviá-los ao gateway padrão ou descartá-los. O rascunho associa o intervalo a perda temporária de controle de IoT e falha de automações.

Não é correto dizer que todo reboot renumera. O prefixo autogerado deveria persistir, e DHCPv6-PD costuma devolver o mesmo bloco. Renumeração frequente aponta para perda de persistência, ausência longa, instabilidade do AIL, concessão curta ou diferente, ou partição e cura da malha.

Um /64 comum, como o derivado do Extended PAN ID no Thread, reduz a mudança. Ainda depende de não reiniciar ao mesmo tempo todos os roteadores que sustentam a rede stub.

OSNR mantém rotas para o passado

O prefixo OSNR pode vir de DHCPv6-PD do RFC 9915 ou de ULA do RFC 4193. Se o anunciante some, os pares podem manter a rota antiga. A coordenação para preservar o mesmo prefixo fica fora do escopo.

Outro roteador pode acabar anunciando OSNR próprio, enquanto quem se lembra do antigo publica RIO até a expiração. A sobreposição protege tráfego em curso; não diz qual endereço uma conexão nova usou nem se o destino está na partição correta.

Descoberta verde, rota ausente

Se RA Guard filtra as RAs do SNAC, mDNS pode continuar exibindo serviços. Sem o RIO do RFC 4191, o host de infraestrutura não instala rota ao OSNR. NAT64 ainda pode manter parte do tráfego de saída.

O diagnóstico compara o anúncio registrado no roteador, a rota presente no host e a aplicação. RFC 6762 e RFC 6763 comprovam descoberta, não encaminhamento.

Um recibo que preserve o desacordo

A especificação recomenda registrar renumerações, depreciações, invalidações, troca do provedor de prefixo e perda ou volta da rota padrão. O recibo mínimo acrescenta identidade do boot, papel do prefixo, estados anterior e novo, RA e idade, vizinhança, vidas, início da depreciação, RIO, rota observada, descoberta e transação com endereço selecionado.

O formato comum não é registro central. Retenção, acesso e correção continuam locais. A Minimum Initial Specification de Lu Heng pede apenas o suficiente para comparar resultados. Reality Layers impede que mensagem, estado, rota e resultado emprestem autoridade uns aos outros.

Fontes

  1. SNAC revisão 12
  2. Histórico
  3. HTML da revisão 12
  4. Texto da revisão 12
  5. Diff oficial 11–12
  6. RFC 4861
  7. RFC 4191
  8. RFC 4193
  9. RFC 8978
  10. RFC 6762
  11. RFC 6763
  12. RFC 7084
  13. RFC 6146
  14. RFC 7050
  15. RFC 9915
  16. Lu Heng — Minimum Initial Specification
  17. Lu Heng — On Reality Layers
  18. Lu Heng — Running Code Primary