Resumen

  • RFC 1888 recomendó primero rehacer de forma nativa el plan IPv6 y después definió cuatro mecanismos opcionales de compatibilidad con direcciones NSAP.
  • La equivalencia de bytes no resolvía que una zona OSI abarcara varios enlaces, que los prefijos no se agregaran o que una identidad de sistema no indicara una interfaz IPv6.
  • RFC 4048 retiró la familia aparentemente no usada, pero aisló dos errores del mapeo inverso; RFC 4548 corrigió solo ese uso de la numeración ICP.

Llegar a la zona no era llegar al sistema

El RFC 1888, publicado como Experimental en agosto de 1996, describió maneras de relacionar direcciones OSI NSAP con IPv6. No era un estándar de Internet. De hecho, su consejo inicial era evitar la compatibilidad cuando fuera viable: quienes tuvieran un plan OSI debían diseñar un plan IPv6 nativo y trasladar conscientemente la topología local.

La cautela respondía a tres diferencias. Una Area de IS-IS podía cubrir varios enlaces físicos, mientras que una subred IPv6 se entendía como un solo enlace. Reutilizar el número de Area como número de subred eliminaba una distinción que el reenvío necesitaba. Además, el encaminamiento a gran escala requería un prefijo común; las direcciones IPv6 normales y las NSAPA restringidas no se resumían juntas por el mero hecho de convivir. Finalmente, varias NSAP podían identificar un sistema completo, pero IPv6 exigía direcciones únicas por interfaz.

RFC 1888 tampoco migraba ES-IS, IS-IS ni su infraestructura. Por tanto, la receta podía emitir una cadena sintácticamente válida sin instalar los protocolos que descubrían el vecino final o propagaban su alcance.

La identidad completa viajaba por otro carril

El primer mecanismo insertaba una NSAPA restringida de formato ICD o DCC en dieciséis octetos IPv6 con prefijo 0x02. Era reversible dentro de su subconjunto, pero el propio documento anticipaba rutas ineficientes y la necesidad de una solución adicional cuando una Area contuviera varias subredes físicas.

El segundo usaba 0x03 y truncaba la NSAPA. Conservaba suficiente jerarquía para aproximarse a una Area, no para identificar por sí sola el destino. El paquete debía incluir una opción de destino con la NSAPA completa o encapsular CLNP. Al recibirlo, una implementación debía decidir si reenviaba, desencapsulaba o descartaba. La resolución automática final quedaba fuera del texto; solo se mencionaban mapeos estáticos o un mecanismo futuro parecido a ES-IS.

Esa separación hacía frágil la prueba de fallo. La autoconfiguración habitual no funcionaba sin cambios, una NSAPA completa no cabía en el encabezado de encaminamiento IPv6 y una respuesta ICMP dirigida a una fuente truncada podía perderse. El sistema no solo podía fallar: podía perder la dirección necesaria para devolver el diagnóstico correcto.

El tercer mecanismo partía de IPv6 normal y agregaba la NSAPA completa en una opción de origen o destino. Los nodos que no utilizaran la función no tenían obligación de implementarla. La opción en una captura demostraba emisión, no soporte, política habilitada ni acción del receptor.

El cuarto colocaba IPv6 dentro de una NSAPA de veinte octetos bajo AFI 35 e ICP cero. Se prohibía la inclusión recursiva para no crear anomalías o bucles, un peligro relacionado con el RFC 1326. El RFC 1629 aporta contexto sobre NSAP en ATM y el RFC 3513 sobre la arquitectura IPv6; ninguno prueba que el mapeo se ejecutara.

Dos motivos distintos para revisar el experimento

En 2005, el RFC 4048 afirmó que, hasta donde sabía el IETF, los mapeos de NSAP dentro de IPv6 nunca habían sido usados seriamente y no estaban soportados por implementaciones IPv6. La formulación es una evaluación atribuida, no una inspección de todo software privado. Sirvió para recomendar el estado Historic y devolver a Reserved el prefijo antes destinado a ese uso.

El camino inverso había despertado interés reciente, incluido un posible empleo con ATM, y presentaba dos errores concretos. El ICP ocupaba dieciséis bits —dos octetos—, no solo el tercero. Además, el IDI de cuatro dígitos decimales se codificaba en dos octetos BCD, no como un número binario sin esa restricción.

El RFC 4548 reemplazó únicamente la sección 6. Bajo AFI 35, el ICP decimal 0 identifica IPv6 y el 1 identifica IPv4; los valores 2 a 9999 requieren un formato definido y publicado y consenso del IETF. El registro OSI NSAPA de IANA conserva hoy esas asignaciones. Registra significado, no actividad.

Las fichas del RFC Editor para RFC 1888, RFC 4048 y RFC 4548 documentan el cambio de estado y el reemplazo parcial. La secuencia no rehabilitó los mecanismos de NSAP truncada o restringida dentro de IPv6. Separó una necesidad de numeración aún defendible de una arquitectura que ya no debía presentarse como vigente.

La evidencia queda así ordenada. Un documento puede definir un mapeo; la operación puede ser reversible; IANA puede registrar un código; un programa puede interpretarlo; la política puede habilitarlo; el encaminamiento puede entregar; el receptor puede actuar; y solo la observación puede demostrar uso. Saltar cualquiera de esos escalones fabrica una conclusión.