Resumo

  • O relato de setembro explica trabalho incorporado ao FreeBSD em março; não anuncia uma nova versão nem apresenta medição independente de desempenho.
  • Uma alteração posterior separa a contabilização e a retenção dos anúncios GRAND das respostas adiadas. A mesma estrutura de fila não torna as mensagens equivalentes.

Uma fila não é apenas um lugar onde mensagens esperam. Ela também decide qual trabalho continua necessário, qual pode ser substituído e qual consome uma cota. Essas decisões ficam mais importantes quando uma otimização nova passa a usar a infraestrutura de um protocolo antigo.

É esse o ponto mais revelador do relato sobre GRAND publicado em 4 de setembro por Seyed Pouria Mousavizadeh Tehrani. Gratuitous Neighbor Discovery permite que um host avise seus roteadores sobre um novo endereço IPv6 antes de receber tráfego de volta. No FreeBSD, acomodar o aviso exigiu trabalho de agendamento, além da emissão de pacotes.

O problema que motiva a mudança tem dois lados. O host já conhece o endereço de enlace de seu roteador e consegue enviar tráfego para fora da rede local. O roteador talvez ainda não tenha o mapeamento do novo endereço global desse host. Quando a resposta chega, precisa resolver o vizinho e manter pacotes aguardando em um espaço limitado. A conexão pode começar com atraso ou perda.

Atualizar um anúncio não é quitar uma solicitação

A implementação inicial foi incorporada em 5 de março. Ela adicionou mecanismos ligados ao término da detecção de endereço duplicado, a mudanças do endereço de enlace e ao enfileiramento de anúncios. O ajuste incorporado em 19 de março explicitou a separação entre GRAND e respostas solicitadas com envio adiado. Setembro é a data da explicação, não dessas alterações.

O segundo registro descreve a intenção de cancelar um anúncio GRAND anterior ainda pendente para o mesmo endereço de interface e reutilizar seu armazenamento. Também distingue o tempo de retenção: uma resposta não-GRAND não mantém a espera adicional associada ao anúncio. Ao calcular a cota GRAND, a alteração ignora os itens não-GRAND.

Não se trata de conceder recursos infinitos às respostas nem de prometer prioridade absoluta. Trata-se de limitar o alcance de uma regra. Um novo aviso pode substituir informação anterior; uma resposta diferente pode continuar devida a outro solicitante. Contar tudo da mesma forma esconde essa diferença. Essa é uma análise do desenho, não a comprovação de um incidente ou de todos os comportamentos concorrentes possíveis no código citado.

O pacote emitido ainda não é um resultado

O RFC 9131, de 2021, requer a colaboração do receptor. O host anuncia o novo endereço; o roteador que recebe um anúncio válido com as informações de enlace necessárias cria a entrada que faltava, no estado STALE. Isso fornece um mapeamento utilizável sem declarar que a alcançabilidade já foi confirmada. As regras para entradas existentes não são descartadas em conjunto.

Entre habilitar o recurso e reduzir a espera há vários acontecimentos: o aviso sair, atravessar o enlace, ser aceito e deixar uma entrada ainda presente quando o tráfego chegar. As repetições precisam ser espaçadas e são destinadas aos roteadores do primeiro salto. Não há entrega garantida.

O RFC 4861 já trata do espaçamento de múltiplos anúncios e dos atrasos em respostas anycast e de proxy. Enviar tudo imediatamente pode aumentar a disputa pelo meio. Por isso, controlar anúncios proativos e manter o atendimento de solicitações são questões relacionadas, mas distintas.

O aviso inicial tampouco resolve um cache apagado depois de sua chegada ou uma entrada removida durante longa inatividade. O RFC 9131 reconhece esses limites. A descoberta normal, o armazenamento temporário e a verificação posterior continuam necessários.

Uma avaliação de adoção deveria combinar novos endereços, respostas adiadas e remoção de endereços com trabalho pendente. Deveria observar também um aviso perdido, um cache limpo e múltiplos roteadores quando aplicável. São verificações propostas neste artigo, não testes realizados. Não instalamos nem compilamos FreeBSD, não capturamos pacotes e não demonstramos economia de latência ou presença do recurso em toda versão suportada. O valor do relato é tornar examinável a integração, não substituir a avaliação da rede que pretende adotá-la.