Resumen

  • RFC 3147 cubrió la dirección inversa que faltaba en una transición: IP dentro de GRE y el paquete GRE como carga de CLNP para atravesar una red CLNS instalada.
  • El N-SEL 47 sugerido entregaba la carga al manejador GRE; el Protocol Type de GRE identificaba IPv4 o IPv6. Ninguno confirmaba que el elemento administrado hubiese actuado.
  • La coexistencia convertía a la red antigua en dependencia temporal de la nueva, de modo que retirarla exigía demostrar rutas alternativas, tamaños útiles, seguridad, retorno y estado del dispositivo.

El destino cambió antes que el trayecto

Los sistemas de gestión de SONET y SDH ya habían cristalizado alrededor de CLNS. Bellcore GR-253-CORE e ITU-T G.784 habían exigido ese entorno, y los operadores habían desplegado redes extensas para atenderlo. Cuando los fabricantes empezaron a ofrecer elementos gestionados por IP, el cambio no rehízo automáticamente la infraestructura situada entre el centro de operación y el equipo.

Aparecieron dos islas simétricas. Un elemento CLNS antiguo detrás de una red IP nueva podía recibir CLNP encapsulado con GRE sobre IP. Pero un elemento IP nuevo detrás de la red CLNS antigua necesitaba el puente contrario. El primer mecanismo no servía: ahora IP era la carga y CLNS era el único medio con alcance.

RFC 3147 puso IPv4 o IPv6 en GRE y el paquete GRE completo en los datos de un PDU CLNP. El dominio CLNS transportaba ese PDU hasta un extremo de túnel. Allí se retiraban ambas envolturas antes de continuar hacia el elemento IP.

No hubo conversión del núcleo CLNS en red IP ni actualización automática de los equipos viejos. Existió un paso acotado entre extremos. La diferencia separa continuidad operativa de migración terminada.

Tres cabeceras, tres hechos

La cabecera IP interior describía la conversación de gestión. GRE declaraba qué protocolo de red contenían sus bytes. CLNP daba direcciones y encaminamiento dentro del dominio que realmente transportaba el paquete. Cada capa respondía una pregunta diferente.

Recibir el PDU CLNP confirmaba que el portador llegó al extremo. Validar GRE confirmaba cómo interpretar la carga. Emitir el paquete IPv6 confirmaba la desencapsulación. Todavía faltaba demostrar entrega a la aplicación, aceptación de la orden y cambio observable en el equipo correcto.

También las identidades eran distintas. NSAP nombraba el extremo CLNS; la dirección IP pertenecía al plano IP; la identidad operacional podía depender de inventario, certificado, bastidor o número de serie. Reducirlas a una dirección mutable convertía una comodidad de base de datos en una afirmación histórica falsa.

Una cadena de evidencia útil conserva intención, paquete interior, sobre GRE, portador CLNP, observación de reenvío, desencapsulación, respuesta y estado real. El éxito de un eslabón no autoriza a completar los demás por inferencia.

El selector 47 no nombraba la carga final

El último octeto de un NSAP, N-selector o N-SEL, permitía a CLNS distinguir usuarios del servicio de red. Los extremos necesitaban acordar una cifra que enviara los datos CLNP al manejador GRE. RFC 3147 sugirió 47 decimal, el número asignado a GRE en el espacio de protocolos IP.

La coincidencia era práctica, no una fusión semántica. N-SEL 47 seleccionaba GRE en el extremo CLNS. Luego el Protocol Type de GRE distinguía IPv4, IPv6 u otro protocolo. Un sistema que etiquetara todos los paquetes con N-SEL 47 como IPv4 borraría el dato que debía leer a continuación.

La palabra “sugirió” limita la afirmación. Compartir el selector hacía posible la interoperabilidad entre fabricantes. No demostraba que todos lo adoptaran, que coincidieran en opciones GRE o que una instalación real hubiese funcionado.

Por eso el recibo debe guardar NSAP de origen y destino, N-SEL, versión y flags GRE, Protocol Type, direcciones interiores, huella y hora. “Túnel activo” no identifica qué tráfico cruzó ni cómo fue interpretado.

La prueba pequeña podía ocultar el agujero negro

Cada envoltura añadía longitud. Un enlace CLNS interior podía aceptar un PDU menor que otro tramo sin que el origen IP conociera el límite. RFC 3147 recomendó activar Segmentation Permitted. Si se prohibía segmentar y el PDU excedía el máximo, CLNS podía descartarlo sin devolver una explicación útil al emisor interior.

Así, un ping o consulta breve pasaba y una transferencia de configuración desaparecía. La primera prueba declaraba “alcanzable” al equipo; el segundo fallo parecía problema de aplicación. En realidad, la ruta sólo servía bajo una condición de tamaño.

En la entrada intervenía además Path MTU Discovery. Con DF desactivado, un datagrama IPv4 grande podía fragmentarse antes del túnel. Con DF activado debía descartarse y generarse el ICMP de fragmentación necesaria. Ese ICMP necesitaba su propio camino de vuelta.

Longitud, DF, sobrecarga, permiso de segmentación, máximo del enlace, fragmentos, ICMP y punto de observación forman una sola prueba. Sin ellos, el agujero negro de tamaño se disfraza de intermitencia.

Ninguna envoltura autenticaba al operador

RFC 3147 declaró que CLNS y GRE no aportaban seguridad. Si era necesaria, el contenido debía protegerse por otro método antes de entrar en GRE sobre CLNS. Encapsular no autenticaba al equipo, no cifraba la orden y no autorizaba a quien la enviaba.

Un paquete podía ser correcto en las tres capas y seguir siendo una orden prohibida. El extremo podía reproducir exactamente los bytes y la aplicación rechazarlos. Una respuesta tampoco acreditaba por sí sola la identidad del aparato.

Extensiones GRE posteriores o mecanismos actuales pueden completar una implantación; no son propiedades retroactivas del documento de julio de 2001. La historia debe conservar la fecha y el mecanismo realmente observado.

Lo transitorio también crea dependencia

Cuando el equipo IP nuevo dependió del túnel, la red CLNS antigua dejó de ser sólo un coste heredado: se convirtió en parte de su camino operativo. Retirarla antes de tiempo podía aislar precisamente los dispositivos usados para justificar la modernización.

Eso no hacía eterna a CLNS. Convertía su retirada en una decisión probatoria. Cada elemento necesitaba otra ruta comprobada; había que ensayar distintos tamaños y la protección; el retorno debía existir; y el estado del dispositivo tenía que coincidir con los acuses después del cambio.

El operador CLNS controlaba rutas y NSAP; el operador IP, el nuevo alcance; el fabricante, la conducta de la gestión; el responsable de servicio, el riesgo. IETF normalizó el punto de unión sin otorgar a uno autoridad sobre todos.

La imagen histórica es una coexistencia cruzada. CLNP sobre IP mantenía equipos antiguos detrás de la red nueva; IP sobre CLNS mantenía equipos nuevos detrás de la antigua. La especificación mínima resolvía el paso, no el programa entero de sustitución.

El código en ejecución conservaba el recurso de apelación. Si llegaban todas las envolturas y el estado no cambiaba, la gestión había fallado. Si sólo pasaban paquetes pequeños, el camino no era plenamente utilizable. Si CLNS seguía siendo el único retorno, la transición no había concluido. El túnel compraba tiempo; no emitía el certificado final.

Fuentes