Resumen

  • La opción Network Resource lleva un NRP Selector ID de cuatro octetos; un nodo compatible lo traduce a recursos locales y uno incompatible puede ignorarlo sin interrumpir el reenvío.
  • La revisión 16 reconoce que observar el ID puede revelar la clase del servicio y alterarlo puede cambiar de cola, degradar un SLA o romper el aislamiento.
  • El informe del shepherd publicado el 6 de septiembre documenta consenso de grupo, pero dice que no existe un estado de implementación registrado.

Conviene empezar por S=0. Si el identificador no coincide con recursos provisionados, el nodo reenvía con el conjunto predeterminado como si la opción no existiera. El paquete llega y la aplicación puede celebrar. Sin embargo, la llegada sólo prueba conectividad; no prueba el tratamiento solicitado.

Con S=1, un nodo que reconoce la opción debe descartar ante esa misma falta de coincidencia. La revisión 16 recomienda el modo estricto como política habitual del NRP y lo propone para OAM. Pero la condición sigue siendo local: primero el equipo tiene que procesar la cabecera Hop-by-Hop y conocer la opción. Quien no la conoce puede saltarla por los bits de acción 00 y seguir según la dirección IPv6.

El mecanismo distribuye la decisión. En el ingreso, una regla clasifica el tráfico, elige un NRP, encapsula y escribe el selector. En cada salto capaz, la dirección decide interfaz y siguiente salto, mientras el ID elige una parte de ancho de banda, búfer o cola. El mismo número sólo coordina si las tablas y capacidades de todos esos equipos coinciden.

La revisión 15 no describía el riesgo con esa precisión. La fuente XML actual añade que el ID puede delatar necesidades de baja latencia o alto caudal y facilitar ataques selectivos. También admite que modificarlo puede cambiar el trato aplicado. “Dominio de confianza” y filtrado son controles administrativos y perimetrales; el formato no incorpora autor, MAC criptográfico ni recibo por salto.

El nuevo acontecimiento está en el proceso. El registro Datatracker y su historial muestran que el 6 de septiembre se asignó shepherd y se publicó el write-up. Once participantes apoyaron el texto; una persona planteó seis asuntos; se exploró un segundo formato y los presidentes cerraron el consenso sin incorporarlo. Una respuesta de última llamada insinuó despliegue, pero el write-up conserva la frase decisiva: no hay estado de implementación registrado.

RFC 8200, RFC 7045, RFC 9098, RFC 9099 y RFC 9673 explican por qué el procesamiento de extensiones no es uniforme. RFC 9543, RFC 9732 y el análisis de escalabilidad NRP aportan el contexto. El registro IPv6 de IANA es la superficie futura; el código sigue siendo TBA en el borrador.

La especificación inicial mínima deja el formato común y devuelve asignación, filtros y recursos al operador. Las capas de realidad impiden que un ID se haga pasar por una cola servida. La primacía del código en ejecución exige observar versiones y efectos. El selector pide; la ruta todavía debe demostrar.