RFC 3115: cuando el registro venció a dos números impresos

Resumen

RFC 3025 asignó en el texto los tipos 37 y 133 a CVSE y NVSE. IANA registró 38 y 134. Dos meses después, RFC 3115 dejó obsoleto el documento anterior porque las implementaciones vigentes seguían a IANA.
El tipo exterior fijaba el coste de no entender una extensión: por debajo de 128 se descartaba todo el mensaje; desde 128 se podía saltar la extensión desconocida y continuar.

Dos constantes, dos redes posibles

Un fabricante compila 37 en su emisor. Otro ha programado 38 en el receptor. Ambos creen implementar la extensión crítica definida para Mobile IP. Ninguno necesita corromper el paquete para que el intercambio falle: basta con que discrepen sobre el primer octeto.

Ésa fue la situación que RFC 3115 consignó en abril de 2001. RFC 3025, publicado en febrero, había definido dos contenedores para información específica de una empresa u organización. La Critical Vendor/Organization-Specific Extension, CVSE, aparecía como tipo 37. La Normal Vendor/Organization-Specific Extension, NVSE, aparecía como 133. En el repositorio de IANA figuraban 38 y 134.

La nota editorial del nuevo RFC puso las cuatro cifras una frente a otra y explicó por qué sustituía el texto anterior: las implementaciones actuales seguían las asignaciones de IANA. No se conserva en esas fuentes una lista de productos ni un recuento. Tampoco se documenta una caída concreta. Lo que sí queda demostrado es el criterio de resolución. El estándar corrigió su memoria para coincidir con el valor operativo.

Eso evita una lectura demasiado cómoda de la autoridad. RFC 3025 era Standards Track; su publicación no convertía automáticamente cada byte impreso en realidad. IANA poseía la función de asignación. El código desplegado aportaba otra clase de prueba: qué número reconocían máquinas que debían interoperar. RFC 3115 reunió de nuevo esas capas.

La frontera 128 era una política de fallo

RFC 2002 había establecido una regla general para extensiones Mobile IP. Si el receptor encontraba un tipo desconocido entre 0 y 127, debía descartar silenciosamente el mensaje completo. Si el tipo desconocido estaba entre 128 y 255, ignoraba esa extensión, utilizaba su longitud para localizar la siguiente y seguía procesando.

Por eso CVSE quedó en 38 y NVSE en 134. “Crítica” significaba que el mensaje no debía interpretarse sin comprender la extensión. “Normal” significaba que la información privada podía perderse sin anular necesariamente el resto.

La palabra “silenciosamente” tenía una definición precisa. No se procesaba más el datagrama y no se devolvía un error al remitente. Aun así, la implementación debía poder registrar el error, guardar el contenido descartado y contarlo. El silencio era una conducta de red, no una orden de destruir la evidencia local.

Aunque 37 y 38 pertenecían ambos a la mitad crítica, no eran equivalentes. Un parser que esperaba 38 no abría el contenedor cuando veía 37. Lo trataba como un tipo crítico desconocido y el mensaje desaparecía. En la mitad normal, 133 frente a 134 podía producir una avería menos visible: la extensión era omitida y el resto continuaba, quizá sin una configuración o capacidad que el emisor creía haber enviado.

Una métrica de solicitudes aceptadas descubriría mal esa pérdida. Una métrica de rechazos tampoco vería todos los silencios. Había que conservar la decisión exacta del parser.

Primero el contenedor, después el dialecto privado

RFC 3115 no redujo todo desconocimiento a una sola categoría. El receptor podía ignorar el tipo exterior, o podía reconocer CVSE/NVSE y desconocer el número de empresa o el subtipo interno.

En el primer caso, un CVSE externo desconocido caía bajo la regla crítica y se descartaba sin respuesta. En el segundo, el receptor ya sabía recorrer la estructura. Si era una petición con tipo 38 reconocido pero un Vendor/Org-ID o Vendor-CVSE-Type no admitido, debía generar una denegación. Para respuestas, un nodo de tránsito emitía un rechazo hacia el siguiente participante; el destinatario final trataba la respuesta como rechazada.

Con NVSE, un identificador o subtipo interno desconocido hacía que se omitiera esa extensión. El mensaje seguía.

La diferencia importa en un incidente. “Extensión de proveedor desconocida” no dice si el código carecía de la constante exterior, si el registro de empresa no estaba soportado, si el subtipo era nuevo, si la longitud era inválida o si falló el autenticador. Cada condición pertenece a una capa distinta y puede producir una salida distinta.

Un registro útil necesita los octetos originales, el tipo externo, la versión del parser, el resultado de reconocer el contenedor, el Vendor/Org-ID, el subtipo, el rol y dirección del mensaje, la acción tomada y el código que se generó. Sin esa secuencia, una incompatibilidad de versiones puede confundirse con una decisión política.

La empresa administraba el subtipo, no toda la autoridad

CVSE y NVSE llevaban un Vendor/Org-ID de cuatro octetos. El superior era cero y los tres restantes contenían el SMI Private Enterprise Code. Dentro de ese espacio, la organización administraba subtipos de dos octetos y valores privados.

Era una delegación de nombres, no una delegación de todo el protocolo. IANA asignaba los tipos exteriores y los códigos de rechazo. El registro de enterprise numbers anclaba el identificador de la organización. La empresa definía el significado de sus subtipos. El emisor elegía cuáles incorporar. El receptor elegía cuáles implementar. Las asociaciones de seguridad de Mobile IP protegían el intercambio cuando correspondía. La política del operador decidía el servicio.

Un enterprise number no autenticaba por sí mismo al remitente. Un mensaje autenticado no volvía comprensible un subtipo desconocido. Reconocer el subtipo no autorizaba la operación. Aceptar el registro no probaba que el tráfico del usuario terminara funcionando.

La especificación permitía varios TLV críticos o normales después de la parte fija del mensaje. Los nodos intermedios no debían alterar su orden. Ordenar esos campos al guardarlos, aunque facilite una consulta, puede separar la evidencia de los bytes que cubrió el autenticador y de la secuencia que recibió cada parser.

La sección de seguridad afirmaba que RFC 3115 asumía la autenticación definida por Mobile IP y no imponía nuevos requisitos. Esa frase describe el modelo del documento. No prueba que un despliegue concreto autenticara todos los saltos ni que cualquier valor privado fuera seguro. El resultado criptográfico, la semántica privada y la autorización local deben quedar como hechos separados.

Los cuatro errores conservaban la dirección

Los códigos 100 y 101 correspondían al foreign agent. El 100 identificaba un CVSE no admitido enviado por el mobile node al foreign agent; el 101, uno procedente del home agent. Los códigos 140 y 141 pertenecían al home agent y distinguían, respectivamente, datos originados por el mobile node o el foreign agent.

Eran pistas sobre custodia y trayecto. No describían el contenido privado, no demostraban que el nodo móvil hubiera recibido la denegación y no confirmaban el resultado final de la sesión. Si un foreign agent actuaba como tránsito de una respuesta y no comprendía un CVSE, podía convertirla en rechazo antes de entregarla. El home agent podía haber procesado correctamente su parte y, sin embargo, el móvil ver un fracaso.

La topología impide resumir la evidencia en “el servidor rechazó la extensión”. ¿Qué servidor? ¿Al interpretar una petición o una respuesta? ¿Quién originó el CVSE? ¿El rechazo se transmitió o sólo se aplicó localmente? RFC 3115 codificó parte de esas preguntas en los números de error, pero el operador debía conservar la cadena.

Del libro de números al registro vivo

RFC 1700 fue una instantánea de Assigned Numbers publicada en 1994. RFC 3232 explicaría en 2002 que las bases en línea de IANA habían sustituido aquellas instantáneas y que RFC 1700 estaba incompleto y en algunos casos era erróneo. RFC 3115 muestra la transición en marcha.

El registro podía reflejar una asignación viva. El RFC podía explicar campos y estados con profundidad. Cada uno era incompleto sin el otro. IANA sabía que CVSE era 38 y NVSE 134; el registro no contenía por sí solo todo el tratamiento de tránsito, el formato interno ni el modelo de autenticación. RFC 3025 tenía esa semántica, pero fijó números divergentes.

El registro actual de Mobile IPv4 conserva 38, 134 y los códigos 100, 101, 140 y 141, referenciados a RFC 3115. Es prueba del presente. Los RFC congelados prueban el desacuerdo histórico. Una auditoría necesita ambos tipos de fuente.

Usos definidos no equivalen a adopción medida

RFC 4332 utilizó extensiones de Cisco para entregar prefijo de red doméstica, gateway, DNS, DHCP y una URL de configuración. RFC 4784 especificó tres extensiones Verizon Wireless de tipo 38 y enterprise number 12951 para un procedimiento de actualización dinámica de claves en cdma2000.

Esos documentos prueban que hubo usos normativamente definidos. No prueban cuántos equipos los instalaron, cuántos mensajes circularon ni si la experiencia comercial tuvo éxito. La diferencia entre especificar y observar es el mismo límite que permitió entender el conflicto original.

RFC 5612 reservó después el enterprise number 32473 para documentación. Hasta un ejemplo necesitaba un identificador incapaz de invadir el espacio de una empresa real. RFC 6709 generalizó el problema: los espacios privados dan flexibilidad, pero una revisión débil o una conducta ambigua ante lo desconocido puede crear exposición operativa e incompatibilidad.

RFC 3115 había puesto un precio concreto a esa ambigüedad. Ignorar lo crítico eliminaba el mensaje. Ignorar lo normal eliminaba sólo una función. Corregir los dos números era restaurar el acuerdo sobre cuál de esos precios debía pagar el receptor.

La prueba correcta conserva las capas

La historia no autoriza a decir que el código siempre tiene razón. Un binario puede contener errores y un registro puede cambiar. La decisión de 2001 fue más específica: el documento estaba en conflicto con la autoridad de asignación y con los valores que, según RFC 3115, seguían las implementaciones actuales.

Una captura demostraría emisión, no interpretación. Un log de parser demostraría interpretación local, no aceptación de registro. Un código de rechazo demostraría una transición del protocolo, no servicio al usuario. La frase sobre implementaciones demuestra más que una mera intención, pero menos que un censo universal.

Con esas fronteras, el episodio queda nítido. RFC 3025 dijo 37 y 133. IANA registró 38 y 134. Los equipos ya hablaban los números del registro. RFC 3115 corrigió la norma antes de que la página impresa pudiera fragmentar dos redes incompatibles.

El RFC decía 37. Los equipos ya hablaban 38: RFC 3115

Por qué importa

Resumen

Dos constantes, dos redes posibles

La frontera 128 era una política de fallo

Primero el contenedor, después el dialecto privado

La empresa administraba el subtipo, no toda la autoridad

Los cuatro errores conservaban la dirección

Del libro de números al registro vivo

Usos definidos no equivalen a adopción medida

La prueba correcta conserva las capas

Fuentes

Contexto ampliado del perfil

Strategic Circle

Leadership Alliance

Informe de Strategic Circle

Informe de Leadership Alliance