Resumen

  • RFC 5149 define una opción de selección de servicio para Binding Updates de Mobile IPv6.
  • El identificador nombra el servicio que se quiere autorizar, pero no otorga autorización.
  • Solo puede aparecer una opción y debe preceder a opciones de autorización o autenticación.
  • El tipo 20 lleva entre 1 y 255 octetos UTF-8 normalizados con NFKC.
  • La unicidad solo abarca los home agents donde ese nodo puede registrarse.
  • El home agent autentica al nodo y consulta aparte si la suscripción permite el servicio.
  • El rechazo usa el estado 151, SERVICE_AUTHORIZATION_FAILED.
  • Cambiar de servicio obliga a reautorizar y puede borrar el binding existente.
  • La selección puede cambiar dirección, prefijo, ruta, cortafuegos, seguridad, política y QoS.
  • Un correspondent node sin conocimiento compartido debe ignorar la opción.
  • ESP puede ocultar el identificador sin demostrar que el catálogo o la autorización sean correctos.
  • Registro, política efectiva, acceso entre dominios y servicio de usuario son resultados separados.

Normalizar texto no normaliza significado

La opción admite identificadores internacionales codificados en UTF-8 y formateados con NFKC. La restricción reduce variantes de representación, pero la semántica continúa en el catálogo del operador. Su unicidad mínima se limita a los home agents donde el nodo está autorizado; no crea un espacio de nombres universal.

Por eso una coincidencia de bytes es apenas el primer recibo. Hay que registrar revisión de catálogo, perfil de suscripción, decisión del home agent y versión del sistema que compila políticas. Un nombre parecido a dominio no prueba delegación ni control de esa organización.

El selector formula la pregunta de autorización

El home agent autentica al nodo y, si soporta la extensión, verifica que el servicio figure en su perfil. La opción ayuda a identificar qué autorización se pide. No contiene el derecho. El código 151 separa un rechazo específico de otros errores de registro.

La colocación antes de opciones de protección permite cubrir la selección. Un mensaje íntegro solo prueba lo que la protección declara: que esos octetos llegaron bajo ese mecanismo. No prueba que la base de suscriptores estuviera actualizada.

Si no hay opción, se solicita el servicio predeterminado de Internet ordinario. La RFC recomienda permitirlo, pero no obliga a autorizarlo a todos. Ausencia de selector tampoco es recibo de conectividad.

Cambiar puede eliminar antes de reemplazar

Una nueva selección exige reautorización. Servicios diferentes pueden requerir direcciones o prefijos diferentes. Si la autorización falla, el home agent niega el registro y elimina el binding existente asociado; el nodo también debe eliminarlo al recibir el estado 151.

Esta conducta convierte el cambio en migración. Debe conservarse evidencia del binding previo, política de rollback, asignación nueva y pruebas de datos. Una interfaz que diga “servicio no autorizado” puede ocultar que el camino anterior ya desapareció.

La aceptación no recorre todos los dominios

La selección puede modificar enrutamiento saliente, cortafuegos y QoS del home agent. Son superficies posibles, no efectos probados. Un correspondent node suele carecer del mismo catálogo y debe ignorar la opción. Incluso dentro de un dominio compartido, revisiones y puntos de aplicación pueden diferir.

La RFC advierte además que elegir un servicio puede restringir otros. Redes externas pueden filtrar tráfico en ambas direcciones. Una Binding Acknowledgement positiva no valida retorno, DNS, aplicación, cobro o coexistencia de servicios.

Confidencialidad y resultado no son lo mismo

ESP con cifrado no nulo protege la selección cuando su revelación sería sensible. No concede derecho ni instala políticas. A la inversa, una autorización correcta no demuestra que la cadena fuera confidencial en tránsito.

Los códigos IANA prueban coordinación documental. Las referencias posteriores prueban linaje. Ninguno prueba soporte actual o resultado operativo.

Sources

  1. RFC 5149, HTML
  2. RFC 5149, texto
  3. Registro RFC Editor
  4. IETF Datatracker
  5. Historial
  6. Referencias
  7. Errata
  8. RFC 3775
  9. RFC 6275
  10. RFC 4877
  11. RFC 4283
  12. RFC 6089
  13. RFC 5778
  14. RFC 5779
  15. RFC 6097
  16. RFC 7222
  17. Minimum Initial Specification
  18. On Reality Layers
  19. Running-Code Primacy