Resumen

  • RFC 3678 preservó las llamadas de pertenencia multicast existentes para mantener la compatibilidad de código fuente y binaria; añadió opciones y funciones de filtro en vez de alterar la interfaz anterior.
  • Una operación incremental cambia una fuente del filtro vigente. La operación de estado completo reemplaza conjuntamente el modo y la lista; RFC 3678 la considera necesaria para cambiar de modo sin abandonar el grupo y útil en listas grandes porque permite una sustitución atómica.

La llamada antigua no podía ampliarse

La primera restricción no venía de un router, sino del programa que ya utilizaba el socket. Antes del filtrado por fuente, un receptor multicast podía unirse a un grupo y, si lo necesitaba, indicar una interfaz local. Eso expresaba la pertenencia, pero no permitía decir de qué emisores quería recibir. Cambiar la llamada establecida para añadir esa información habría puesto en riesgo la compatibilidad binaria: RFC 3678 dice que esas interfaces no podían modificarse sin romper programas existentes.

Por eso el documento optó por ampliar, no sustituir. Pidió que las API nuevas conservaran la compatibilidad de código fuente —que el código antiguo siguiera compilando y funcionando— y la compatibilidad binaria —que un ejecutable previo siguiera corriendo en un sistema compatible con la extensión—. También pidió cambios pequeños y un modo para que la aplicación detectara si las nuevas opciones no estaban disponibles y reaccionara con elegancia. Es un memorando informativo de diseño de API, no una prueba de que todos los sistemas operativos implementaran las mismas llamadas. RFC 3678

Una fuente cada vez

La interfaz incremental cambia el filtro por pasos. En una pertenencia multicast de cualquier origen, el receptor acepta inicialmente las fuentes en general; una operación de bloqueo o desbloqueo cambia el tratamiento de un emisor. En multicast de fuente específica, se incorpora o elimina una dirección de la lista deseada. El estado previo importa: el RFC distingue las combinaciones inválidas de opciones y pertenencias de casos como bloquear una fuente ya bloqueada o abandonar una fuente que nunca se unió.

Esta gramática es económica cuando la aplicación solo necesita un cambio pequeño. Puede pedir “bloquea esta fuente” o “únete a esta fuente” sin volver a enviar la lista entera. Pero su significado depende del filtro y la pertenencia actuales: es un delta, no una declaración completa del estado que debería quedar al terminar la llamada. El texto define opciones específicas de IPv4, como IP_ADD_SOURCE_MEMBERSHIP, y otras independientes del protocolo, como MCAST_JOIN_SOURCE_GROUP. RFC 3678

O reemplazar todo el estado

La API de estado completo resuelve otro problema. La aplicación entrega el modo —MCAST_INCLUDE o MCAST_EXCLUDE— y la lista entera que se incluirá o excluirá. La llamada sustituye el filtro anterior; no aplica una modificación individual sobre él.

RFC 3678 señala dos situaciones en las que la diferencia es importante. Para cambiar entre INCLUDE y EXCLUDE sin salir del grupo, la aplicación debe usar la API de estado completo. También se recomienda cuando hay una lista extensa, porque el filtro puede cambiarse atómicamente en una llamada. Una secuencia de deltas podría llegar al mismo conjunto, pero representaría varias modificaciones intermedias, no una sustitución única.

La lectura tiene su propio contrato: la aplicación puede estimar el tamaño del búfer, recibir el recuento total de fuentes y repetir la operación si no había reservado espacio suficiente. Si la implementación establece un máximo, superar ese límite puede producir ENOBUFS. “Reemplazar todo” es una herramienta para gestionar estado, no una promesa de capacidad ilimitada. RFC 3678

Un grupo y dos familias de direcciones

El memorando conservó estructuras y opciones específicas de IPv4 para reducir los cambios en aplicaciones IPv4 existentes. También definió variantes independientes del protocolo. Estas transportan el grupo y la fuente en estructuras de socket aptas para varias familias de direcciones, y especifican por separado el índice de la interfaz local. RFC 3493 había establecido buena parte del vocabulario socket para IPv6, pero no operaciones de unión y salida multicast independientes del protocolo; RFC 3678 completó esa parte. RFC 3493

La distinción se puede perder al leer una firma de función: la dirección del grupo nombra el destino multicast, la dirección de fuente nombra al emisor y el índice de interfaz limita la operación a una conexión local. La errata técnica verificada 2524 corrigió después la descripción del argumento de getsourcefilter en la sección 5.2.2: donde decía “dirección IP local” debía decir “índice de interfaz”, como ya indicaba la función de escritura anterior. Otra errata verificada arregló una referencia cruzada a una sección de errores inexistente. Ninguna cambia el modelo del filtro; sí ayudan a preservar el significado de los argumentos. Erratas de RFC 3678

Filtrar aquí no es filtrar en todas partes

El sistema operativo puede aplicar un filtro local aunque los routers no admitan IGMPv3 o MLDv2. La aplicación puede obtener un efecto en el host sin demostrar que los paquetes no deseados dejaron de circular por el enlace local. Los protocolos comunican información del filtro hacia un router: ese mecanismo de red es distinto de la llamada socket y tiene su propio estado y recorrido. RFC 3376, RFC 3810 y RFC 4604 describen partes de ese comportamiento de red. RFC 3376 RFC 3810 RFC 4604

El filtrado tampoco autentica al emisor. RFC 3678 advierte que por sí solo no frena un paquete cuya dirección de origen se falsifica para parecer permitida; la validación de ruta inversa puede ayudar en ciertas configuraciones, pero no ofrece garantías. Que la llamada socket tenga éxito acredita una operación de API, no el estado del router, una reducción de ancho de banda, tráfico autenticado, recepción de paquetes ni el resultado de la aplicación. RFC 3678

El documento es Informational y aclara que no constituye un estándar de Internet; también remite a la especificación oficial de sockets. Su aporte histórico es más acotado: proteger las llamadas antiguas de pertenencia, hacer barato un cambio sobre una fuente y permitir que el filtro entero se sustituya en una sola operación cuando el estado o la escala lo exigen. Las Notas 64 y 65 de Lu Heng, escritas mucho después, sirven aquí como lentes sobre compatibilidad y adopción local; no son autoría, aprobación ni causa del memorando de 2004. Estado de RFC 3678 Nota 64 Nota 65

Fuentes