Resumen

  • RFC 2042 reservó el valor de tipo 255 para desarrollar nuevos atributos BGP. Antes del uso real en Internet, el atributo debía documentarse en un RFC, recibir de IANA un código único y actualizar tanto la documentación como el código.
  • El documento descartó dividir el espacio en zonas públicas y privadas o en zonas Internet y OSI. Ver 255 no acredita una extensión propietaria, interoperabilidad, despliegue, adopción, seguridad, compatibilidad ni autorización.

Una transición de protocolo puede resumirse en un cambio de octeto y, aun así, fracasar en cinco lugares distintos. RFC 2042 identificó ese punto de cambio con una claridad poco habitual: 255 pertenece al desarrollo; la identidad pública requiere otro número.

El memo apareció en enero de 1997 como RFC informativo. Hoy el RFC Editor lo sitúa en el flujo Legacy, y el IETF Datatracker advierte que no está avalado por el IETF ni tiene posición formal en su proceso de estándares. Su valor es histórico y preciso: muestra cómo se pretendía evitar que los experimentos locales confundieran el espacio común de tipos de atributo.

Un número compartido a propósito

RFC 1771 describía entonces BGP-4 y sus atributos de camino. El nuevo problema era práctico: un desarrollador necesitaba probar otro atributo antes de disponer de una identidad pública estable. RFC 2042 reservó para ese trabajo el valor de un octeto 255.

La reserva no convertía a 255 en un identificador privado. Varios experimentos podían utilizarlo simultáneamente. Cada uno podía definir flags, longitud y contenido distintos. Dentro de un laboratorio, la configuración y el acuerdo previo identificaban el formato. Fuera de él, el número era ambiguo por diseño.

Por eso un paquete observado con 255 solo prueba que el emisor produjo ese valor en ese punto. Sin el build, el esquema de prueba, el conjunto de pares y el momento de la captura, no demuestra qué experimento era. Tampoco demuestra que el receptor compartiera la interpretación.

La ambigüedad servía a una finalidad: evitar la ocupación de códigos públicos por prototipos que podían cambiar o desaparecer. A cambio, el desarrollador debía contener el tráfico experimental y reconocer que 255 no sobrevivía como identidad de producción.

La salida exigía tres cambios coordinados

Para el uso real en Internet, RFC 2042 pedía documentar el atributo en un RFC y conseguir de IANA un type code único. Después de la asignación, debían actualizarse la documentación y la base de código con el valor autorizado.

Cada paso resuelve un problema diferente. El RFC fija un significado consultable. La asignación evita que dos significados públicos reclamen el mismo código. El cambio de software hace que el ejecutable emita la identidad registrada. Ninguno demuestra que los demás se hayan completado ni que dos implementaciones interoperen.

Una especificación que ya muestra el nuevo código mientras el binario sigue enviando 255 produce una divergencia documental. Un emisor actualizado frente a pares antiguos puede provocar rechazo. Un analizador de paquetes con tablas desfasadas puede convertir una transición correcta en un falso incidente. La prueba del cambio necesita registro, versión de documento, commit, build, vectores de prueba y observación operativa.

RFC 2042 además rechazó expresamente segmentar los códigos entre público y privado, o entre Internet, OSI y otras familias. Esta frase impide presentar 255 como número de extensión de fabricante. Era un marcador común y temporal, no un territorio reservado a propietarios concretos.

La tabla actual conserva el límite

El registro vigente de IANA para BGP Path Attributes mantiene 255 como “Reserved for development” y cita RFC 2042. No contiene un rango Private Use. Dentro de la colección BGP Parameters existen otras tablas con políticas vendor-specific o private-use, pero la política pertenece siempre a la tabla nombrada. No se puede trasladar de un subregistro a otro por compartir la palabra BGP.

La tabla actual señala también Standards Action como procedimiento y cita RFC 4271, la especificación Standards Track que sucedió a RFC 1771. RFC 8126 define la terminología contemporánea de las políticas de registro. Es contexto actual, no lenguaje que deba atribuirse al documento de 1997.

IANA puede demostrar que un código tiene un significado registrado bajo el procedimiento aplicable. No demuestra que exista una implementación, que esté desplegada, que el mercado la adopte o que un operador autorice su uso. El registro elimina una clase de colisión; no elimina los fallos del software ni sustituye la evidencia de red.

Esta separación coincide con la lectura editorial de Heng Lu sobre el código en funcionamiento, sin convertirla en una norma del IETF. El documento y la asignación pertenecen a la coordinación institucional; el build pertenece a la realidad ejecutable; el comportamiento de pares y redes pertenece a la realidad operativa. Una afirmación rigurosa llega solo hasta la capa observada.

Una errata que no altera el mecanismo

La errata oficial 3681 corrige una referencia bibliográfica: el documento sobre BGP Route Reflection era RFC 1966, no RFC 1998. Está clasificada como Editorial y retenida para una futura actualización del documento. No cambia el propósito de 255 ni el proceso de asignación.

La errata tampoco se refiere a la falta ortográfica visible en la palabra inglesa “documentation”. Registrar esa diferencia evita que una corrección obvia pero no verificada suplante al expediente oficial.

El valor de una identidad débil

El marcador de desarrollo funcionaba porque no pretendía ser exclusivo. Permitía probar y descartar ideas sin convertir cada rama en un compromiso del registro común. Su seguridad conceptual dependía de no confundirlo con un derecho privado y de retirarlo antes de cruzar el ámbito del acuerdo local.

La lección de RFC 2042 es una secuencia de modestia técnica. El experimento recibe un marcador temporal. La propuesta pública recibe documentación. El registro le asigna una identidad única. El software adopta esa identidad. El despliegue y la interoperabilidad se verifican después, con pruebas propias.

IANA puede decir qué número nombra públicamente un atributo. No puede decir si funciona. Y el 255, precisamente porque era compartido, ni siquiera podía decir qué experimento nombraba.

Fuentes