Summary

  • A RFC 2375 permitiu que um significado permanente aparecesse em vários escopos IPv6, mas afirmou que endereços diferentes apenas no escopo eram grupos distintos e exigiam adesão separada.
  • Uma atribuição resolvia identidade e colisão no espaço comum; não comprovava ouvintes, estado de encaminhamento, fonte aceita nem recebimento pela aplicação.

A lista nasceu provisória

Em 1998, o IPv6 já tinha uma forma para endereços multicast. Ainda faltava uma lista comum para todos os nós, todos os roteadores, protocolos de roteamento, serviço de tempo e sistemas de conferência herdados da experiência com IPv4.

A RFC 2375 publicou uma seleção inicial. Ela adaptou somente as atribuições IPv4 consideradas relevantes, deixou de converter as demais, pediu comentários e reservou tudo que não aparecia na tabela. A escolha não prometia uma taxonomia final; abria uma parte do espaço de maneira controlada.

Esse livro comum evitava que dois protocolos dessem sentidos diferentes ao mesmo valor. Não dizia que o serviço estava implantado nem que havia alguém ouvindo.

O X não queria dizer “um grupo em todo lugar”

Alguns endereços valiam somente num escopo fixo. Outros traziam X no campo de escopo, permitindo combinar o mesmo número permanente com qualquer escopo legal.

A RFC 2375 impôs a distinção decisiva: endereços que mudavam apenas no escopo representavam grupos diferentes. Cada nó precisava ingressar em cada grupo separadamente.

No exemplo de NTP da RFC 2373, o mesmo identificador podia significar servidores no próprio nó, no mesmo enlace, no mesmo site ou no âmbito global. O significado sobrevivia. O conjunto de destinatários não. O número atravessava o limite; a participação não.

O escopo ajudava a formar o destino

Escopo não era uma legenda. Ele limitava a região topológica do grupo, e os roteadores não deviam encaminhar o pacote para além dela. “Todos os roteadores” numa interface, num enlace ou num site designava três públicos diferentes.

Para grupos temporários, a separação era ainda maior. O mesmo endereço num outro site não tinha relação necessária com o primeiro; o mesmo ID em outro escopo e um grupo permanente de número igual também não estabeleciam continuidade.

Semelhança entre bits não era prova de identidade operacional. Era preciso conservar o endereço inteiro, o contexto e o estado em execução.

O registro não continha ouvintes

Uma atribuição permanente produzia um primeiro recibo: certo valor tinha certo significado. Ela não fazia a aplicação pedir recepção, não escolhia a interface e não informava ao roteador vizinho que existia um ouvinte.

A RFC 2710 tornou essa etapa visível com Multicast Listener Discovery. Roteadores descobriam quais endereços interessavam nos enlaces diretamente conectados. Hosts mantinham estado por endereço e interface, respondiam a consultas e relatavam mudanças de adesão.

O registro IANA e o relatório de escuta eram evidências diferentes. O primeiro estabilizava o nome. O segundo demonstrava, num lugar e momento, a existência de interesse. Depois deles ainda vinham rota multicast, política de fonte, chegada do pacote e entrega ao socket.

Permanência tinha objetos diferentes

A RFC 3307 separou endereços multicast permanentes, identificadores permanentes de grupo e endereços dinâmicos. IANA podia reservar um endereço completo; um ID permanente podia nomear o mesmo serviço em vários servidores e escopos; uma alocação dinâmica atendia a uma escolha temporária.

Cada classe organizava colisão e significado. Nenhuma criava membros. Para virar serviço, o ID precisava de um escopo, um endereço completo, uma solicitação de recepção, adesão na interface e estado de encaminhamento.

A RFC 3306 vinculou alguns endereços multicast a prefixos unicast. O escopo multicast não podia exceder o do prefixo embutido, e sua vida útil não deveria ultrapassar a validade desse prefixo. Até uma identidade reutilizável permanecia situada no espaço e no tempo.

O registro vivo não era telemetria

A RFC 4291 preservou o modelo de grupos por escopo. A RFC 7346 definiu depois o valor 3 como Realm-Local e refinou a terminologia. O registro IANA atual ainda separa valores de escopo, endereços fixos, endereços variáveis, IDs baseados em prefixo unicast e IDs dinâmicos.

Essa continuidade mostra que a coordenação continuou evoluindo. Não mostra que cada linha de 1998 ainda transporta tráfego. Um nome pode continuar reservado depois que sua implementação some; um novo serviço pode entrar muitos anos depois.

O registro diz o que pode receber um nome sem conflito. Somente o sistema em execução mostra quem está ouvindo.

Autoridade com limite explícito

A ideia de especificação inicial mínima, de Lu Heng, descreve bem a RFC 2375: abrir apenas o necessário, reservar o restante e permitir correção pela experiência. A primazia do código em execução coloca a autoridade seguinte em adesões, relatórios, tabelas de encaminhamento e pacotes observados.

As camadas de realidade mantêm separados significado registrado, ID, escopo, endereço completo, adesão da interface, estado aprendido pelo roteador, rota, fonte admitida, pacote recebido e resultado da aplicação.

A RFC 2375 deu nomes aos primeiros grupos. Sua cautela mais duradoura foi não fingir que um nome estável trazia consigo os membros.