Resumo

  • A RFC 3956 usou prefixo e identificador dentro do endereço de grupo para que roteadores derivassem o mesmo Rendezvous Point de PIM-SM sem uma distribuição separada de mapeamento.
  • Como qualquer usuário podia fornecer o grupo, um resultado válido ainda não comprovava RP existente, rota funcional, autoridade, estado de origem nem dados recebidos.

A configuração chegou junto com o grupo

Uma aplicação entrega ao host um endereço multicast obtido em configuração, diretório ou página. A RFC 3956 deu a uma faixa desses endereços uma função adicional: conter a receita do RP usado por PIM Sparse Mode.

O objetivo era facilitar ASM IPv6 entre domínios sem MSDP e enquanto SSM não cobria todas as necessidades imediatas. Se o endereço bastasse para calcular o RP, os domínios não precisariam distribuir uma escolha paralela.

A decisão ficou mais simples e mais exposta à origem da entrada. Quem oferecia o grupo influenciava onde o plano de controle tentaria criar estado.

O formato comprimiu o RP

Não havia espaço para um RP IPv6 completo e ainda manter a identidade do grupo. A solução reutilizou a estrutura de prefixo unicast da RFC 3306: uma flag distinguia embedded-RP, plen indicava o prefixo e um RIID de quatro bits completava um endereço sob regras restritas.

RIID zero era reservado. Valores não zero podiam selecionar RPs diferentes sob o mesmo prefixo, mas cada grupo completo resultava em um candidato. A unicidade do Group ID era responsabilidade externa. Concordância de cálculo não significava coordenação de alocação.

Para a faixa especial, a correspondência embutida tinha prioridade de longest match. Isso impedia mecanismos concorrentes de escolher respostas incompatíveis. Era uma regra de desempate, não uma garantia de disponibilidade.

A entrada não confiável direcionava Join e Register

O receptor emitia MLD e o roteador designado iniciava Join em direção ao RP calculado. Do lado da fonte, o DR podia encapsular tráfego inicial em Register para o mesmo destino. A string de endereço recebida pela aplicação tinha efeitos concretos sobre estado de roteador.

RFC 3956 declara a origem não confiável: qualquer usuário na Internet pode fornecer o grupo. O RP derivado deveria passar pelos mesmos testes de validade de um RP aprendido de outra forma. O texto exige excluir pelo menos fe80::/10, ::/16 e ff00::/8.

Passar no teste tornava o endereço elegível. Não autenticava fornecedor, operador do prefixo, fonte ou receptor; tampouco concedia permissão para criar, enviar ou aderir. O endereço era entrada de roteamento, não credencial.

A existência continuava sem prova

PIM-SM espera RP alcançável no domínio. A RFC reconhece que isso não pode ser provado em geral e que um RP estrangeiro embutido pode nem existir.

Uma rota demonstra um próximo salto, não um processo PIM atendendo. Join demonstra estado intermediário, não fonte registrada. Um cache demonstra cálculo passado, não saúde atual. Register aceito ainda não demonstra árvore funcional ou receptor com dados.

Expor o RP no grupo também o torna ponto de falha mais visível. Visibilidade ajuda operação e ataque, mas não é monitoramento. Ocultar anúncios já era obscuridade; embedded-RP continuava dependente de escopo e política explícita.

Os recibos permaneceram distribuídos

A RFC 4601 detalhou depois PIM-SM, e a RFC 3810 definiu MLDv2. Filiação local, Join, Register, estado no RP e pacote recebido são etapas diferentes.

A RFC 4607 descreveu SSM, que elimina RP ao nomear fonte e grupo. RFC 3956 não o tratava como substituto imediato universal. Mesmo uma intenção mais específica não comprova execução.

A RFC 7371 atualizou posteriormente a arquitetura de endereços multicast. Os metadados e as erratas documentam a norma, não uma implantação específica.

O ganho histórico foi tornar o candidato reproduzível. Isso reduzia configuração e localizava falhas. Ainda assim, a direção escrita no grupo era só o lugar onde tentar. Rota, PIM, estado, contadores e observação do receptor respondiam pelo restante.

Fontes