Resumo

  • A RFC 3307 dava a alocadores por servidor e por host a mesma faixa dinâmica 0x80000000-0xFFFFFFFF, que ainda incluía os Group IDs de Solicited-Node. Dois participantes conformes podiam escolher o mesmo valor.
  • A RFC 10028 criou seis faixas no registro da IANA para MADCAP, espaço não atribuído, alocação SSM por host, uso privado, uso experimental e Solicited-Node. Ela retira a sobreposição normativa, não todas as colisões multicast.
  • Mike McBride é coautor com Nate Karstens e Dino Farinacci. O registro coordena o espaço comum; versões de software, requisitos de SSM, encaminhamento, legitimidade da fonte e autorização dos receptores continuam exigindo prova da rede em operação.

Há falhas em que ninguém desobedece. O servidor segue a sua tabela, o host segue a mesma tabela e ambos chegam ao mesmo número. A conformidade individual não salva uma regra comum que deixou dois direitos de escolha sobrepostos.

Era esse o desenho herdado da RFC 3307 para os 32 bits inferiores de endereços multicast IPv6. Um servidor podia alocar dinamicamente; um host também podia escolher. Os dois usavam de 0x80000000 a 0xFFFFFFFF. A parcela superior, 0xFF000000-0xFFFFFFFF, já tinha função própria nas direções multicast Solicited-Node do Neighbor Discovery.

A RFC 10028, publicada na trilha de padrões do IETF em agosto de 2026, separa essas responsabilidades. Nate Karstens, Dino Farinacci e Mike McBride assinam o texto. A escolha de McBride como personagem não apaga a autoria coletiva nem o transforma em operador da IANA ou controlador de um domínio multicast.

O Datatracker do IETF capturado em 31 de agosto de 2026 o lista como presidente do PIM, delegado no MBONED e no ANIMA, revisor da Routing Area Directorate e autor de nove RFCs. A RFC 10028 registra sua afiliação à Futurewei. Um artigo histórico da Open Networking Foundation oferece contexto profissional em primeira pessoa, datado de 2017. São provas de identidade e trajetória, não de adoção por fabricantes.

Uma colisão criada antes do pacote

O Group ID ocupa os 32 bits inferiores definidos pela RFC 3307. Em Ethernet, esses bits são mapeados diretamente para o endereço multicast da camada de enlace. Repetir o identificador pode, portanto, fazer a interface e o switch lidarem com destinos que deveriam permanecer separados.

O MADCAP, da RFC 2730, usa um servidor: clientes pedem endereços ou concessões multicast. A alocação zeroconf discutida na RFC 10019 parte de outro requisito: o host deve escolher sem depender de servidor. São modelos diferentes e potencialmente compatíveis, desde que não recebam oficialmente o mesmo terreno.

Aleatoriedade não é particionamento. Mesmo que cada lado diminua a probabilidade de selecionar certo valor, o outro mantém o mesmo direito. A sobreposição com Solicited-Node era ainda mais direta, pois uma faixa arquitetural de Neighbor Discovery aparecia dentro do intervalo dinâmico geral.

A RFC 10019 mostra por que a correção do mapa não encerra o trabalho. Redes zeroconf precisam detectar e resolver colisões nas camadas de rede e enlace, conviver com vários aplicativos e reconciliar escolhas feitas durante uma partição temporária. Hardware também pode agrupar vários destinos em tabelas finitas ou buckets de hash.

A RFC 10028 remove a colisão que não precisava existir: a causada pela atribuição da mesma faixa a mecanismos diferentes.

As seis faixas do registro

O registro Dynamic Multicast Group IDs da IANA começa com:

  • 0x80000000-0x8FFFFFFF para MADCAP;
  • 0x90000000-0xEFFFFFFF sem atribuição;
  • 0xF0000000-0xFCFFFFFF para alocação por host de grupos SSM;
  • 0xFD000000-0xFDFFFFFF para uso privado;
  • 0xFE000000-0xFEFFFFFF para uso experimental;
  • 0xFF000000-0xFFFFFFFF para multicast Solicited-Node.

Uma atribuição normal no espaço livre depende de Standards Action. O registro guarda faixa, descrição e referência. Não contém lista de equipamentos, versão implantada, audiência de um fluxo ou política de segurança.

Essa limitação é uma propriedade de bom desenho. Para evitar que MADCAP e um host SSM recebam o mesmo intervalo, a camada comum precisa registrar a fronteira. Ela não precisa decidir o modelo de negócio do aplicativo nem a autorização do receptor.

O mesmo limite impede uma leitura triunfalista. Endereços IPv6 diferentes nos bits superiores ainda podem chegar ao mesmo endereço Ethernet se os bits mapeados coincidirem. Um switch pode sofrer pressão de tabela. Hosts isolados podem selecionar valores incompatíveis e só descobrir depois. Um remetente malicioso pode usar um endereço formalmente válido.

O novo registro elimina a classe “dois allocators autorizados na mesma faixa”. Não elimina a necessidade de detectar as demais. A precisão da correção seria perdida se “uma sobreposição removida” virasse “multicast sem colisões”.

A coordenada de origem de SSM

A faixa do host não é para qualquer multicast; ela é para Source-Specific Multicast. No SSM, o canal é o par (S,G). A RFC 4607 explica que fontes diferentes podem reutilizar o mesmo grupo G, pois o canal completo continua distinto. Isso reduz a coordenação necessária para tornar cada grupo globalmente único.

Mas a origem S não aparece porque o Group ID pertence à faixa correta. O aplicativo precisa conhecê-la. O host precisa das interfaces e do comportamento de IGMPv3 ou MLDv2. O roteador designado e o domínio de roteamento precisam manter a semântica específica de fonte. A RFC 8815 recomenda SSM no interdomínio e, ao mesmo tempo, reconhece que suporte de aplicativos e sistemas é um obstáculo real.

A RFC 10028 afirma que SSM não é universalmente suportado. Escolher 0xF0000000-0xFCFFFFFF em uma rede sem esses requisitos produz um número correto para uma capacidade inexistente. A faixa não configura PIM, não autentica o emissor e não concede permissão ao ouvinte.

Aqui, a especificação inicial mínima e a primazia do código em funcionamento de Heng Lu oferecem uma disciplina útil. A camada comum define só a distinção indispensável à interoperabilidade; atores locais adotam e operam a escolha; evidência de execução determina se a mudança se tornou real. Não é uma equivalência entre um registro de protocolo da IANA e um RIR. É uma recusa em tratar declaração como implantação.

O software MADCAP não muda por decreto

A nova divisão reduz a faixa do MADCAP para um décimo sexto do antigo intervalo. A RFC 10028 diz que os autores conheciam uma implementação e nenhum uso em larga escala. A frase não é um censo mundial. “Não conhecido” preserva a incerteza que um operador deve considerar antes de presumir ausência.

Uma implementação existente precisa adotar a faixa menor ou permanecer isolada de outros protocolos de alocação multicast IPv6. Atualizar a página da IANA não reescreve um binário, não corrige um dispositivo sem suporte e não altera uma configuração esquecida.

O recibo de migração deve ligar identificador e produtor: allocator, versão, mecanismo, configuração, snapshot da regra, hora e observação. Um log que contém só o endereço completo perde a informação necessária para distinguir MADCAP legado, host SSM, compressão no mapeamento, partição ou abuso.

Também há um risco de incentivo. O mecanismo novo costuma ter melhor telemetria e ser a mudança mais visível. Se ele colidir com um servidor antigo, a operação pode desligar o participante conforme e preservar a dívida técnica invisível. Procedência evita que visibilidade seja confundida com culpa.

Cada prova com sua própria jurisdição

O RFC comprova a decisão coletiva do IETF. A página da IANA comprova a tabela pública atual. Um teste comprova que determinada versão restringe seus valores. Uma associação (S,G) e uma captura de tráfego comprovam comportamento em certo caminho e momento. Registros de identidade e acesso comprovam fonte e autorização.

Uma prova não herda as outras.

A linha registral não mede implantação. O endereço SSM não mede capacidade do caminho. O pacote recebido não prova que o remetente estava autorizado. A ausência de colisão em um ensaio não cobre outros escopos, topologias ou limites de hardware.

Um ledger operacional suficiente pode ser enxuto: allocator e versão; mecanismo; Group ID e endereço completo; versão da RFC e do registro; requisitos SSM; detecção e classe da colisão; observação de encaminhamento; validação da fonte; autorização do receptor; responsável por reversão. Cada campo deve dizer somente o que seu observador sabe.

O trabalho conjunto de McBride, Karstens e Farinacci não prometeu que uma tabela faria o multicast funcionar. Ele impediu que a própria especificação continuasse oferecendo o mesmo espaço a duas formas de escolha.

O registro tornou a coexistência possível. A rede ainda precisa torná-la demonstrável.

Fontes