Resumen

  • draft-ietf-spring-sid-as-source-address-00, fechado el 7 de septiembre de 2026, ya es documento de trabajo del grupo SPRING. La adopción no lo convierte en RFC ni valida por sí sola los equipos mencionados.
  • Al poner el SID del servicio en la dirección IPv6 de origen exterior, los dos extremos pueden presentar al cortafuegos un par de direcciones que se invierte de manera coherente.
  • La coincidencia confirma una relación de estado bajo una política concreta. No demuestra qué nodo o cliente originó el paquete, ni que estuviera autorizado a usar ese SID.

La anomalía nace de una práctica habitual. El PE de entrada encapsula tráfico de cliente con su dirección de bucle como origen IPv6 exterior. El servicio VPN remoto aparece como destino final: en la dirección IPv6 cuando no hay SRH, o en el último elemento del encabezado de encaminamiento cuando se aplica una política de segmentos. Un cortafuegos consciente de SRv6 puede extraer ese destino y crear estado.

La dirección contraria no invierte esos valores. El segundo PE usa otra dirección de bucle y el SID de servicio del primer PE pasa a ser el destino final. Para un dispositivo que espera invertir origen y destino dentro de su terna o quíntupla, las dos mitades son flujos distintos. El encaminamiento puede estar sano y, aun así, perder una respuesta o un error ICMP en el filtro.

La propuesta cambia lo que significa el campo. El PE identifica el L3 VPN y escoge el SID de servicio que el PE remoto espera recibir para ese contexto. Lo coloca como origen exterior; el otro extremo hace lo propio. El SID, cuando figura como origen, se trata como una dirección IPv6 normal y no ejecuta allí su función de extremo. El cortafuegos obtiene por fin una relación simétrica.

Esa victoria es limitada. Antes, el origen exterior señalaba al menos al PE de entrada. Ahora señala un servicio elegido por ese PE. Una entrada de sesión puede justificar que el paquete pertenece a un intercambio previamente admitido según el analizador y las reglas vigentes. No identifica necesariamente la caja emisora, el circuito de acceso, el cliente ni el derecho a utilizar el valor.

La elección de granularidad decide cuánta realidad se conserva. Un SID por VRF no exige otra consulta, pero varios CE aparecen como una sola fuente. Un SID por AC distingue cada circuito sin búsqueda adicional. Un SID por prefijo ofrece más detalle, aunque obliga al PE a consultar la dirección de origen del paquete de cliente dentro de la VRF y puede afectar al reenvío. El orden indicado por el borrador —prefijo, AC y, al final, VPN/VRF— es también una jerarquía de coste y trazabilidad.

El propio documento advierte que los locators suelen anunciarse por el dominio. Un nodo interno podría emitir con un SID ajeno y beneficiarse de controles que confundan ese prefijo con confianza. La variación rápida de SIDs, además, puede generar muchas entradas, alterar el envejecimiento y llenar la tabla del cortafuegos. Por eso se requieren controles estrictos sobre los flujos autorizados a usar un SID como origen. La simetría no trae antisuplantación ni presupuesto de memoria incorporados.

ICMP aporta una señal distinta. Un ping SRv6 puede usar un End SID como origen exterior para comprobar el camino de regreso. Un nodo de tránsito puede devolver un error desde el SID cuyo procesamiento falló, ayudando a localizar el punto. En tráfico VPN, el PE de entrada aún debe interpretar el encabezado superior incluido para entregar el ICMP interior al CE. Localización no es autenticación: el valor orienta una investigación, pero no prueba quién generó el informe ni cuál fue la causa raíz.

La compresión puede quebrar incluso la asociación básica. RFC 9800 permite que el último elemento visible no coincida con la dirección que recibe el destino, o que una lista comprimida resida en la dirección sin SRH. El nuevo borrador recomienda dejar sin comprimir el destino final y conservarlo como último elemento del SRH. De lo contrario, el cortafuegos puede reconstruir semánticas distintas en cada sentido aunque ambos PE hayan escogido bien el origen.

La afirmación de implementación también tiene alcance propio. El texto dice que los routers New H3C CR16000 y CR19000 con versión 7.1.119 o posterior cubren todas las secciones y etiqueta la madurez como productiva. La ficha sigue referida al Draft-13 anterior y no aporta experiencia específica. Como exige la disciplina de RFC 7942, el borrador aclara que la IETF no verificó la información suministrada por el contribuyente ni la respalda. Hay una pista de código ejecutable, no una certificación, una prueba de interoperabilidad o una medición de despliegue.

La separación de capas defendida por Heng Lu resulta práctica aquí. Ser documento de grupo es estado de coordinación; la selección del PE es estado configurado; el paquete y la tabla son observación; la entrega y la atribución son resultados. Un hecho no recibe automáticamente la autoridad del siguiente.

La noticia, por tanto, no es que una dirección pase a ser «más correcta». Es que SPRING ha aceptado trabajar sobre una reasignación semántica para evitar falsos rechazos. El recibo operativo debe unir versión de asignación, PE autorizados, granularidad usada, analizador del cortafuegos, entrada de estado, paquete y entrega. Solo así se puede afirmar que la vuelta coincidió sin fingir que el remitente quedó identificado.

Fuentes

  1. IETF Datatracker — SID as source address in SRv6
  2. Borrador de grupo 00
  3. Datatracker — borrador anterior
  4. Revisión 13 del borrador anterior
  5. SRv6 Security Considerations, revisión 16
  6. RFC 8402 — Arquitectura de Segment Routing
  7. RFC 8754 — Encabezado SRH de IPv6
  8. RFC 8986 — Programación de red SRv6
  9. RFC 9252 — Servicios BGP superpuestos sobre SRv6
  10. RFC 9259 — OAM en SRv6
  11. RFC 9800 — Listas comprimidas de segmentos SRv6
  12. RFC 7942 — Secciones de estado de implementación
  13. Heng Lu — Running-Code Primacy
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Reality Layers