Resumo

  • RFC 3678 preservou as chamadas existentes de associação multicast para manter compatibilidade de código-fonte e binária. Em vez de alterar a interface antiga, acrescentou opções e funções para filtrar origens.
  • Uma chamada incremental muda uma origem do filtro vigente. A chamada de estado completo substitui, de uma vez, o modo e a lista; RFC 3678 diz que ela é necessária para mudar entre INCLUDE e EXCLUDE sem sair do grupo e é útil para listas grandes, pois permite uma atualização atômica.

A chamada existente não podia ser ampliada

A primeira restrição não vinha do roteador, mas dos programas que já usavam o socket. Antes do filtro por origem, um receptor multicast podia entrar em um grupo e, se necessário, escolher uma interface local. Isso declarava a associação, não quais remetentes a aplicação queria aceitar. Alterar a chamada existente para inserir essa informação ameaçaria a compatibilidade binária. RFC 3678 diz que essas interfaces não podiam mudar sem quebrar programas antigos.

Por isso, o documento escolheu acrescentar em vez de substituir. As novas APIs deveriam preservar a compatibilidade de código-fonte — o código anterior continuaria compilando e funcionando — e a compatibilidade binária — um executável já existente continuaria rodando em um sistema que implementasse a extensão. Também recomendou mudanças pequenas e uma maneira de a aplicação detectar quando as novas opções não estavam disponíveis, para então reagir adequadamente. É um memorando informativo de desenho de API, não prova de que todo sistema operacional tenha implementado as mesmas chamadas. RFC 3678

Uma origem por chamada

A interface incremental altera o filtro em etapas. Na associação multicast de qualquer origem, o receptor começa aceitando fontes de modo geral; bloquear ou desbloquear muda o tratamento de um remetente. No multicast de origem específica, a aplicação inclui ou remove uma origem da lista desejada. O estado anterior à chamada importa: o RFC distingue combinações inválidas de associação e opção de casos como bloquear uma origem já bloqueada ou deixar uma origem à qual o socket não se associou.

Essa gramática é simples quando o aplicativo tem uma mudança pequena a fazer. Ele pode dizer “bloqueie esta origem” ou “entre nesta origem” sem reenviar o restante da lista. Mas o significado depende do filtro e da associação atuais. É um delta, não uma declaração completa do estado que deve restar depois. O documento define opções IPv4 como IP_ADD_SOURCE_MEMBERSHIP e opções independentes do protocolo, como MCAST_JOIN_SOURCE_GROUP. RFC 3678

Ou substituir o estado inteiro

A API de estado completo resolve outro problema. O aplicativo informa o modo — MCAST_INCLUDE ou MCAST_EXCLUDE — e toda a lista de origens a incluir ou excluir. A chamada substitui o filtro anterior em vez de aplicar uma modificação pontual sobre ele.

RFC 3678 destaca dois casos em que a diferença importa. Para mudar de INCLUDE para EXCLUDE sem sair do grupo, o aplicativo deve usar a API de estado completo. Ela também é recomendada para listas grandes porque a alteração pode ser feita atomicamente em uma operação. Uma sequência de deltas talvez chegue ao mesmo conjunto, mas expõe uma série de estados intermediários, não uma única substituição.

A leitura tem seu próprio contrato: o aplicativo pode estimar o tamanho do buffer, receber o número total de origens e repetir a consulta se o espaço era insuficiente. Se a implementação impuser um limite máximo, excedê-lo pode gerar ENOBUFS. “Substituir tudo” é uma maneira de administrar o estado, não uma promessa de capacidade sem limite. RFC 3678

Um grupo, duas famílias de endereços

O memorando manteve estruturas e opções específicas de IPv4 para reduzir mudanças em aplicações IPv4 existentes. Também criou formas independentes do protocolo. Elas transportam grupo e origem em estruturas de socket capazes de representar famílias diferentes e identificam a interface local separadamente por índice de interface. RFC 3493 fornecia boa parte da interface socket para IPv6, mas ainda não definia operações multicast de entrada e saída independentes do protocolo; RFC 3678 completou essa lacuna. RFC 3493

Ao ler uma assinatura de função, é fácil confundir três coisas: o endereço do grupo aponta para o destino multicast, o endereço de origem identifica o remetente e o índice de interface limita a operação ao ponto local de conexão. A errata técnica verificada 2524 corrigiu a descrição do argumento de getsourcefilter na seção 5.2.2: onde se lia “endereço IP local da interface”, deveria constar “índice da interface”, como já dizia a função de configuração na seção anterior. Uma segunda errata verificada corrigiu uma referência cruzada a uma seção de erro que não existia. Nenhuma altera o modelo de filtro; ambas esclarecem o significado dos argumentos. Erratas de RFC 3678

Filtrar aqui não é filtrar em toda parte

O sistema operacional pode aplicar o filtro local mesmo quando os roteadores não dão suporte a IGMPv3 ou MLDv2. Assim, o aplicativo pode obter um efeito no host sem demonstrar que os pacotes indesejados deixaram de atravessar o enlace local. Os protocolos levam informações do filtro até o roteador; esse é um mecanismo de rede separado da chamada socket, com estado e caminho próprios. RFC 3376, RFC 3810 e RFC 4604 descrevem partes desse comportamento no lado da rede. RFC 3376 RFC 3810 RFC 4604

O filtro também não autentica quem envia. RFC 3678 alerta que, sozinho, ele não impede um pacote cujo endereço de origem foi falsificado para parecer permitido; verificações de caminho reverso podem ajudar em certas topologias, mas não garantem proteção. O sucesso de uma chamada socket comprova uma operação de API, não o estado do roteador, redução de banda, autenticidade do tráfego, chegada dos pacotes ou resultado no aplicativo. RFC 3678

RFC 3678 é Informational e afirma que não especifica um padrão da Internet; também remete à especificação oficial da API de sockets. Sua contribuição histórica é mais precisa: preservar as chamadas antigas de associação, manter simples a alteração de uma origem e permitir que o filtro inteiro seja substituído de uma vez quando o estado ou a escala exigirem. As Notas 64 e 65 de Lu Heng, escritas décadas depois, são apenas lentes analíticas sobre compatibilidade e adoção local; não são autoria, endosso nem causa do memorando de 2004. Status de RFC 3678 Nota 64 Nota 65

Fontes