Resumen

  • RFC 9798 permite un Receiver RLOC multicast solo cuando el núcleo LISP soporta transporte IP multicast, pero deja al ETR la elección local de un grupo que pueda unir.
  • El ITR raíz asigna una entrada de interfaz de salida por cada mapping de underlay único; si necesita saber qué ETR enviaron joins, usa la IP origen del mensaje, que debe ser un RLOC de ETR.
  • Autenticar el Join/Prune reduce la duda sobre origen e integridad, no sobre asignación del grupo, capacidad de la red, membresía o entrega.

El error empieza con una columna llamada “receptor”

Imagine un registro operativo con una fila: Transport=0, Receiver RLOC=un grupo multicast, estado=aceptado. Una lectura apresurada convierte la fila en prueba de una audiencia. Sin embargo, el grupo expresa dónde quiere recibir el ETR; no enumera a los ETR, y mucho menos a los hosts detrás de ellos.

RFC 9798 prescribe otro dato para el seguimiento. Cuando el ITR necesita mantener la lista de ETR de los que recibió PIM joins, debe usar la dirección IP origen del Join/Prune. Esa dirección debe ser un RLOC del ETR. La identidad del solicitante y la dirección multicast solicitada son superficies distintas aunque viajen en el mismo mensaje.

El documento apareció en junio de 2025 con categoría Experimental y actualiza RFC 8059. La modificación no redefine el formato ni el significado del atributo Transport: se limita a Transport=0. La novedad está en el Receiver RLOC. La dirección unicast sigue sirviendo a flujos encapsulados unicast; una dirección multicast puede servir a flujos encapsulados multicast, únicamente cuando el underlay del núcleo LISP admite ese transporte.

Nada de eso es una declaración de despliegue. Tampoco define una prueba remota de capacidad. El ETR decide localmente usar el underlay multicast, elige un grupo que puede unir, identifica el sitio LISP aguas arriba donde debe enraizarse el árbol y compone el mensaje conforme a RFC 8059. Para auditar “puede unir” hacen falta la política local, su versión y la observación que la sustentó.

Tres mappings, tres repartos de coste

La base de RFC 6831 transforma el tráfico (S-EID,G) del sitio en estado y paquetes (S-RLOC,G) en el núcleo. Así se desplaza la réplica desde la cabecera unicast hacia un árbol multicast del underlay. Pero el enlace entre ambos espacios no tiene una cardinalidad obligatoria.

RFC 9798 contempla muchas conexiones overlay sobre un flujo underlay, un flujo overlay repartido sobre varios flujos underlay, o una correspondencia única. En many-to-one, menos árboles del núcleo pueden transportar más fuentes. El precio aparece cuando un sitio recibe tráfico encapsulado de una fuente que no pidió; RFC 6831 explica que el ETR lo descarta tras mirar su estado interno. En one-to-many, las restricciones de los xTR quedan aisladas, pero la raíz puede hacer más copias. En one-to-one aumentan el aislamiento y el consumo de estado.

La obligación del ITR es concreta: crear una entrada nueva en su lista de interfaces de salida por cada mapping multicast del underlay que sea único. El ITR puede aplicar una política local para limitar cuántas copias hará. RFC 9798 no fija la cuota ni decide qué solicitud prevalece. Por eso el informe de capacidad debe conservar mapping, OIF, copias solicitadas, copias admitidas y motivo de limitación.

Los grupos tampoco son intercambiables en todas las fronteras. Un PxTR puede necesitar una gama para el árbol del sitio y otra para el núcleo LISP externo. Un ASIC o una plataforma con recursos acotados puede admitir solo parte del espacio multicast. Esas restricciones son parte de la configuración vigente, no propiedades visibles en el valor del grupo.

Una codificación comprendida no demuestra un camino disponible

RFC 5384 creó la envoltura TLV de los PIM Join Attributes. Como pueden cambiar la construcción del árbol, advierte que resultan útiles en dominios cooperantes donde se conoce de antemano que los routers entienden la codificación. El PIM convencional anuncia esa capacidad mediante una opción Hello.

RFC 8059 marca una excepción operativa: los xTR LISP no intercambian PIM Hellos, no hay una opción para negociar estos atributos y se supone que los sistemas con réplica unicast en cabecera los soportan. Tanto Transport como Receiver RLOC son no transitivos. RFC 9798 amplía el uso al underlay multicast sin convertir esa suposición en descubrimiento dinámico.

De ahí que el recibo tenga que conservar las capas. Los bytes y el resultado del parser acreditan la representación. La política de rango acredita la intención local. El OIF acredita estado de control. Las tablas multicast y los contadores acreditan comportamiento en ejecución. La decapsulación y la recepción de la aplicación acreditan el resultado. Ninguna capa puede declarar retrospectivamente las demás.

Autenticación y autorización no son sinónimos

RFC 8059 deja claro que los atributos no mejoran por sí mismos la autenticidad del paquete PIM. RFC 9798 observa que numerosos joins con grupos diferentes o superpuestos pueden interferir con tráfico legítimo o agotar recursos de réplica. Plantea que la autenticación PIM de RFC 5796 podría validar solicitudes y que una implementación podría fijar un máximo de grupos por RLOC origen.

La formulación no impone una autoridad mundial. RFC 5796 protege mensajes PIM-SM de enlace local mediante IPsec y describe asociaciones de seguridad, claves y autenticación de pares. Si esas piezas están configuradas y registradas, ayudan a acreditar quién envió un mensaje sin alteración. No asignan el grupo, no miden el soporte de los saltos y no muestran qué receptor obtuvo datos.

Una cadena suficiente une los bytes del Join/Prune, atributos analizados, resultado criptográfico, RLOC origen, decisión del ETR, mapping, entrada OIF, límite de copias, estado del núcleo, contadores, decapsulación y resultado receptor. Debe ser posible señalar exactamente dónde dejó de coincidir la promesa con la ejecución.

Fuentes