Resumo
- RFC 10028 substitui a faixa dinâmica sobreposta do RFC 3307 por blocos distintos para MADCAP, alocação SSM pelo host, uso privado, uso experimental e endereços Solicited-Node.
- A tabela só evita conflito quando todos os alocadores no mesmo escopo executam a regra atual. Estar na faixa certa não prova quem alocou, se houve duplicidade, se o receptor aderiu ou se o caminho entregou o fluxo
(S,G)pretendido.
Uma equipe integra uma célula industrial antiga a uma rede maior. No lado novo, o host escolhe 0xF0000020 para um canal SSM, dentro da faixa criada por RFC 10028. No lado legado, um servidor MADCAP continua configurado para usar todo o intervalo 0x800000000xFFFFFFFF, como permitia RFC 3307.
Enquanto os segmentos estavam isolados, os dois podiam funcionar. Depois da integração, o servidor entrega o mesmo ID a outro processo. A validação do host novo passa. A validação do controlador velho também. O enlace recebe dois significados para os mesmos 32 bits inferiores.
RFC 10028, publicado na trilha de padrões do IETF em agosto de 2026, elimina esse compartilhamento na especificação. Ele não consegue alterar sozinho uma imagem de firmware, um servidor de contingência ou uma configuração copiada anos atrás. A autoridade do registro termina onde começa a necessidade de provar adoção.
A regra antiga criava o conflito
RFC 3307 chama os 32 bits inferiores de um endereço multicast IPv6 de ID de grupo e os relaciona ao endereço de camada de enlace. Para alocação dinâmica, servidor e host utilizavam a mesma faixa. O trecho superior ainda coincidia com os IDs Solicited-Node.
Assim, dois mecanismos independentes podiam escolher o mesmo número sem descumprir sua lógica local. O endereço final não revelava sua procedência.
RFC 10028 levou a nova divisão ao registro IPv6 Multicast Address Space da IANA:
0x800000000x8FFFFFFF: MADCAP;0x900000000xEFFFFFFF: não atribuído;0xF00000000xFCFFFFFF: alocação de grupos SSM pelo host;0xFD0000000xFDFFFFFF: Private Use;0xFE0000000xFEFFFFFF: Experimental Use;0xFF0000000xFFFFFFFF: Solicited-Node.
Novas atribuições no bloco livre exigem Standards Action. RFC 8126 fornece a política de registro e de controle de mudanças. A tabela cria um acordo mínimo sobre qual classe pode usar qual território.
Ela não aloca um grupo vivo. IANA não escolhe o ID do aplicativo, não inspeciona o pool local e não confirma a retirada de um lease antigo. A entrada responde à classificação; a execução responde à realidade.
Para MADCAP, a decisão é atualizar ou isolar
RFC 10028 reduz o espaço de MADCAP e recomenda que as implementações adotem a nova faixa. Um ambiente legado deve usar software atualizado ou operar sem outro protocolo de alocação multicast IPv6 coexistente.
No momento da redação, o RFC registrou uma implementação MADCAP conhecida e nenhum grande deployment conhecido. É uma observação limitada àquele momento, não um inventário atual de produto. Equipamentos incorporados, backups frios e sistemas de longa vida não desaparecem porque não aparecem em pesquisas públicas.
RFC 2730 define MADCAP como mecanismo cliente-servidor. O cliente descobre, solicita e recebe OFFER, ACK ou NAK; o administrador configura a política local. Um ACK prova a decisão do servidor. Não prova que o pool respeita o limite atual.
A migração precisa registrar software, build, hash de configuração, limites efetivos do pool, cliente, escopo, lease, início, renovação e expiração. A checagem deve incluir instâncias passivas e imagens de recuperação.
Os bits inferiores chegam ao switch
RFC 4291 define formato, escopo e ID dos endereços multicast IPv6. Um grupo transitório tem significado dentro de um escopo. Unir dois domínios antes separados muda as condições de unicidade.
No Ethernet, RFC 2464 usa 33:33 seguido pelos quatro últimos octetos do destino IPv6. O ID escolhido alimenta filtros de interface e tabelas de encaminhamento. Um mapeamento correto pode continuar duplicado.
RFC 10019 descreve efeitos em redes zeroconf: tráfego indesejado filtrado por software, perda do benefício de snooping, sobrecarga de links lentos e pressão sobre tabelas limitadas. Partições de rede também podem escolher o mesmo endereço e só descobrir o conflito quando se reconectam.
O documento exige que uma solução descentralizada futura detecte e resolva a colisão. Ele não entrega o alocador. RFC 10028 reserva uma faixa para que essa solução possa coexistir com MADCAP e métodos manuais.
SSM reduz a necessidade de coordenar G
RFC 4607 identifica um canal SSM pela dupla (S,G). Fontes diferentes podem reutilizar o mesmo grupo. RFC 8815 destaca que G não precisa ser globalmente único na faixa SSM.
Isso não elimina a fonte, a adesão e o plano de encaminhamento. RFC 10028 observa que SSM não tem suporte universal. Alguns switches econômicos só mantêm estado por MAC de destino. RFC 4541 mostra que diferenças de versão e capacidade de IGMP/MLD snooping podem podar o fluxo necessário ou inundar portas com tráfego não registrado.
Um endereço SSM correto precisa ser ligado à fonte S, ao relatório de adesão, à entrada de snooping, ao estado de roteamento e a um canário de conteúdo. Nenhum desses fatos pode ser deduzido da faixa.
Privado e experimental também precisam de limites
Private Use permite alocação manual em ambiente isolado. Como não há coordenação central, dois ambientes podem escolher o mesmo valor. Aquisições, interligações temporárias e restauração de redundância devem disparar uma revisão de colisão.
Experimental Use permite testar novos protocolos e RFC 10028 não restringe o experimento a uma rede fechada. O rótulo não garante segurança, autorização ou compatibilidade. É preciso ter responsável, escopo, validade e remoção verificável.
Espaço não atribuído espera ação futura; não é estoque local. Solicited-Node tem função arquitetural; não é sobra para alocação dinâmica.
Guardar a geração da regra
Cada registro deve conter revisão normativa, classe e versão do alocador, hash de configuração e evento de seleção. Acrescentar endereço IPv6, escopo, ID, destino Ethernet, aplicação, stream e ciclo do lease. Em SSM, a fonte faz parte da identidade.
Depois, ligar o registro a outros alocadores no escopo, sondas de conflito, adesão MLD/IGMP, snooping, encaminhamento, primeiro e último pacote, tráfego inesperado, renumeração e retirada do estado antigo.
São fatos diferentes: pertencer à faixa; ter sido emitido por um alocador identificado; não colidir; ter receptor inscrito; ser encaminhado; chegar como o fluxo certo. Uma tela verde não deve fundi-los.
A primazia do código em execução de Heng Lu coloca a prova nessa cadeia. Sua especificação inicial mínima com decisões futuras localizadas explica por que a divisão comum deve ser estreita e a adoção, local. A distinção entre controle formal e prático dos dados mostra por que IETF e IANA definem o espaço sem controlar o executável e o pacote.
O mapa já mudou. A operação precisa provar que seus alocadores também mudaram.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
