Resumen

  • Source-Specific Multicast selecciona un canal mediante el par de fuente y grupo (S,G).
  • Dos emisores privados pueden utilizar el mismo grupo sin confundirse porque sus direcciones fuente son distintas.
  • Al salir, el NAT sustituye cada dirección fuente privada por una dirección exterior y conserva el grupo multicast.
  • Si ambos emisores reciben la misma fuente pública, sus pares privados distintos se reducen a un solo par público.
  • RFC 5135 advierte que el tráfico deja de ser identificable de forma única y puede mezclarse en el receptor.
  • Endpoint-Independent Mapping estabiliza la regla de traducción frente al destino, no la unicidad pública de cada fuente privada.
  • Paired address pooling mantiene coherencia para un endpoint interno; tampoco promete separar endpoints diferentes.
  • El proxy IGMP agrega correctamente los estados privados para evitar secuencias de reporte inválidas, pero no deshace la reescritura de la fuente.
  • Las barreras de ámbito y el TTL deciden hasta dónde viaja el paquete, no a quién representa al llegar.
  • Permitir otro grupo SSM es una salida provisional que exige señalización y adopción verificadas en todos los receptores.
  • SSRC, CNAME u otra identidad de aplicación pueden ayudar únicamente si el receptor demuestra que los usó correctamente.
  • El criterio de éxito debe seguir cada identidad desde el emisor privado hasta el resultado que el receptor seleccionó y presentó.

La promesa exacta de un mapeo independiente del destino

La palabra “independiente” invita a exagerar. En el contexto de NAT, Endpoint-Independent Mapping significa que un mismo endpoint interno conserva el mapeo al comunicarse con destinos diferentes, sean unicast o multicast. Es una regla sobre cómo se elige y reutiliza una traducción. Reduce el comportamiento dependiente del destino y facilita que las respuestas encuentren el camino esperado.

No significa que cada fuente privada del sistema obtenga una identidad pública exclusiva. Tampoco garantiza que el dato semántico usado por una aplicación para seleccionar una fuente sobreviva. Un NAT puede cumplir la regla para cada endpoint y, por limitación de su espacio exterior o por su modelo de traducción, presentar varios emisores bajo la misma dirección pública.

RFC 5135 añade paired address pooling cuando el dispositivo dispone de varias direcciones exteriores: un endpoint interno debería conservar la misma dirección pública. Esta coherencia evita que una sola entidad cambie de cara pública sin necesidad. Sin embargo, la recomendación sigue estando formulada desde un endpoint hacia su mapping. No convierte el conjunto de direcciones exteriores en un registro uno-a-uno de todas las fuentes multicast privadas.

La consecuencia es incómoda para la observabilidad. Una tabla de mapping estable puede parecer una prueba de continuidad. En realidad, confirma que la transformación siguió una regla persistente. Para afirmar continuidad de identidad hace falta comparar cuántas fuentes distinguibles existían antes, qué representación tuvo cada una después y qué criterio aplicó el receptor para separarlas.

El par que SSM necesita puede colapsar

SSM no identifica un canal sólo por el grupo. Lo identifica por la fuente S y el grupo G. Dos emisores privados, A y B, pueden escoger G y seguir siendo diferentes: (A,G) no es (B,G). Un receptor situado donde A y B son visibles puede solicitar exactamente la fuente deseada.

El límite aparece al traducir. RFC 5135 exige reescribir la dirección fuente del tráfico multicast que sale desde el interior. El destino multicast y su puerto no se traducen. Si tanto A como B se representan mediante la dirección exterior N, el lado público recibe paquetes que pertenecen al mismo (N,G). La distinción privada se ha perdido en el nivel IP.

El apéndice del RFC lo expresa como un problema de identificabilidad: los flujos pueden quedar entremezclados. No dice que el NAT haya dejado de reenviar. Tampoco dice que toda aplicación sea incapaz de recuperarse. Dice algo más preciso: la pareja pública que usa SSM ya no contiene el hecho que distinguía a las dos fuentes privadas.

Por eso no basta con observar paquetes en la interfaz exterior. Esa captura prueba que el dispositivo emitió tráfico con N y G. Si no se conserva la relación con A y B, ya no permite asignar cada paquete a su origen privado. Un contador elevado puede representar una fuente sana, dos fuentes mezcladas o duplicados de una arquitectura multihomed.

Lo que el NAT debe hacer, sin convertirlo en una garantía de servicio

RFC 5135, publicado como BCP 135 en febrero de 2008, trata NAT y NAPT IPv4 con proxy IGMP para ASM y SSM. Excluye PIM-SM e IPv6. Sus requisitos crean una base interoperable, no una certificación de la experiencia de cada aplicación.

En el sentido exterior-interior, la dirección y el puerto de destino multicast deben conservarse, y el UDP multicast debe llegar a los receptores internos suscritos. En el sentido interior-exterior, la fuente se traduce. NAPT puede traducir también el puerto fuente y debe crear un mapping si se esperan respuestas. Estas obligaciones describen el movimiento y la traducción de paquetes.

El tráfico UDP multicast originado dentro debe poder salir, pero tiene que existir una opción para desactivarlo. La razón incluye el riesgo de que una red multihomed emita el mismo tráfico por más de un traductor. Ese duplicado de camino es diferente del alias de identidad. El primero repite un flujo; el segundo hace que dos flujos distintos parezcan uno.

El documento también impone fronteras de ámbito. Por defecto, 239.0.0.0/8 no debe cruzar hacia fuera y 224.0.0.0/24 no debe exportarse. Un TTL de uno puede detener el paquete en el router local. Cada control responde a una decisión espacial. Ninguno revela por sí solo qué fuente privada está representada por la dirección pública de un paquete permitido.

Un proxy sano no rellena la información que falta

IGMP no se trata como un simple flujo que atraviesa el dispositivo. El proxy recibe estados de membresía privados, calcula una representación conjunta y genera reportes hacia arriba. RFC 5135 admite IGMPv1 de forma opcional, exige IGMPv2 y recomienda IGMPv3. Cuando implementa IGMPv3, debe soportar SSM y las semánticas de filtrado por fuente.

La agregación evita que los cambios independientes de varios hosts se mezclen en una secuencia inválida para el reportero exterior. Si un host entra mientras otro sale, retransmitir los mensajes sin cálculo puede producir un blackhole temporal. El estado agregado demuestra que el proxy resolvió correctamente esa simultaneidad.

Pero el filtro exterior sólo conoce la dirección fuente visible allí. No conserva un canal secreto hacia las direcciones privadas anteriores. Si dos fuentes ya han sido representadas como N, un reporte correcto referido a N no vuelve a separarlas. La salud del control plane y la conservación de identidad en el data plane son propiedades distintas.

Cambiar de grupo transfiere la coordinación

Como medida provisional, RFC 5135 recomienda que las aplicaciones de SSM permitan modificar el grupo. Con grupos G1 y G2, una misma fuente pública N puede formar pares distintos: (N,G1) y (N,G2). Es una forma práctica de reintroducir variedad en el par después de que la fuente pública haya convergido.

La solución general queda expresamente para estudio futuro. La medida provisional impone trabajo local: detectar el choque, elegir un grupo adecuado, actualizar la descripción de sesión, distribuirla, renovar filtros y autorizaciones, retirar el canal anterior y confirmar que cada receptor se suscribió al nuevo. Si un cliente conserva G, seguirá consumiendo el lugar ambiguo aunque el panel del emisor muestre G2.

La evidencia relevante es generacional. Hay que saber qué configuración estuvo vigente, cuándo cambió, quién recibió la publicidad, qué solicitud hizo y qué paquetes aceptó. La mera existencia de un campo editable no prueba que la coordinación haya sucedido.

Una segunda identidad sólo vale si llega al resultado

RTP puede transportar SSRC y CNAME. RFC 5135 subraya la conveniencia de generar CNAME correctamente porque las redes privadas reutilizan los mismos rangos de RFC 1918. Una aplicación que compruebe esos identificadores puede distinguir participantes aun cuando compartan una dirección traducida.

Pero la posibilidad no sustituye a la prueba. El emisor debe producir un identificador apropiado, el camino debe conservarlo, el receptor debe aplicar las reglas de colisión y la aplicación debe vincularlo con el participante esperado. Además, una colisión SSRC y una fusión SSM son mecanismos distintos; uno no debe utilizarse para explicar automáticamente el otro.

En ASM con RTP aparece otro límite: la caducidad del mapping puede cambiar la dirección de transporte traducida y activar la lógica de colisión. El RFC recomienda 60 minutos y eliminación al abandonar el grupo, con reducción bajo presión de recursos sin vulnerar el mínimo de RFC 4787. Ese temporizador demuestra cuánto persiste el estado del NAT, no cuánto persiste el significado percibido por el receptor.

La auditoría debe seguir la transformación

Antes del NAT, registre la identidad operativa del emisor, la dirección privada, el grupo, la generación de configuración y el intervalo. En la frontera, conserve mapping, dirección pública, puerto traducido, decisión de pooling, creación y caducidad. Mantenga aparte la versión IGMP, las membresías, los filtros y el agregado.

Después del NAT, compare el (S,G) anunciado por la señalización con el solicitado y el observado. Detecte si varias fuentes internas aportan tráfico al mismo par. Si la aplicación dispone de SSRC, CNAME u otro identificador, registre la asociación y la decisión de colisión. No permita que un único indicador “multicast activo” compacte todas estas realidades.

El último recibo pertenece al receptor: fuente lógica seleccionada, paquetes aceptados, descartes, mezcla, cumplimiento temporal y salida mostrada o procesada. Hasta ese punto, un mapping estable sólo prueba estabilidad de mapping. Esa precisión no debilita la norma; evita usarla como sustituto de una medición que nunca prometió realizar.

Fuentes

  1. RFC 5135 en HTML
  2. RFC 5135 en texto
  3. Ficha de RFC 5135
  4. RFC 5135 en IETF Datatracker
  5. Historial de RFC 5135
  6. Búsqueda de erratas
  7. RFC 4787
  8. RFC 4605
  9. RFC 3376
  10. RFC 4607
  11. RFC 5760
  12. RFC 3550
  13. RFC 2365
  14. RFC 5771
  15. RFC 1918
  16. RFC 8085
  17. Registro IANA de direcciones multicast
  18. Registro IANA en XML
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary