Resumen
- ATMP dejaba que un cliente PPP o SLIP usara una dirección de su red de origen mientras un NAS remoto y un agente local sostenían el túnel sin que el cliente lo supiera.
- Registro, reto con secreto compartido al estilo CHAP, Tunnel ID local al par de agentes y GRE producían la apariencia operativa de conexión local para IP o IPX.
- Dirección, respuesta positiva y clave GRE demostraban estado acotado del protocolo, no ubicación física, identidad humana, autorización de aplicaciones, entrega ni consenso del IETF.
«Casa» era una decisión de encaminamiento
En 1997 un usuario podía llamar por módem a un servidor de acceso distante y aun así presentar una dirección de su red de origen. El cable terminaba en otro lugar; el encaminamiento decía que estaba en casa.
Esa contradicción define ATMP. El protocolo no movía la estación. Un agente foráneo dentro del NAS registraba al cliente ante un agente local de la red de origen. Entre ambos transportaban el tráfico por un túnel y permitían que los demás sistemas actuaran como si el cliente estuviera conectado allí.
El cliente no ejecutaba ATMP: bastaban PPP o SLIP ordinarios. El NAS y el agente local conservaban toda la maquinaria. La sencillez del borde se pagaba concentrando criterio de encaminamiento en la frontera.
La dirección podía venir configurada en el cliente, asociada a un identificador de usuario o tomada de un pool. RFC 2107 dejaba fuera de alcance tanto la asignación como la decisión del NAS de invocar ATMP. Podía transportar la dirección elegida, pero no demostrar quién autorizó la elección ni si todavía correspondía al usuario correcto.
El registro fabricaba la conexión
La movilidad se representaba como la asociación entre dirección de origen, IP del agente foráneo y Tunnel ID. No era una afirmación geográfica, sino una instrucción compacta de encaminamiento.
El agente foráneo obtenía por configuración la dirección del agente local y un secreto compartido. Enviaba una solicitud de registro cada dos segundos; después de diez intentos sin reto, registraba el fallo y desconectaba al cliente.
El agente local enviaba un autenticador. El agente foráneo lo concatenaba con el secreto y devolvía un resumen MD5. El agente local repetía el cálculo. Una coincidencia permitía aceptar; un fallo o falta de recursos generaba un resultado distinto de cero.
La prueba autenticaba una relación configurada entre agentes. No identificaba a la persona ante el módem, no autorizaba una operación de aplicación y no cifraba la carga. Decir que el mecanismo era parecido a CHAP describía su forma, no aumentaba lo que podía probar.
Tunnel ID convertía estado en camino
Tras aceptar el reto, el agente local asignaba un identificador único solo dentro del par FA–HA. Creaba un bloque de control que relacionaba ese valor con la información de ruta; el agente foráneo lo guardaba con la sesión del cliente.
Los datos viajaban entonces en GRE y el identificador ocupaba el campo Key. El agente local recuperaba el contexto de ruta; el foráneo separaba los paquetes para cada cliente activo. Una clave desconocida provocaba una notificación de error y el descarte silencioso.
Así se veía el traslado de autoridad. El cliente originaba el tráfico, pero los agentes elegían el contexto de origen, nombraban el estado y decidían si la conexión seguía viva. La dirección parecía estable porque los bloques de control absorbían el cambio físico.
IPX mostraba el coste adicional. La gestión del túnel seguía necesitando IP. Cada agente local debía tener un número de red IPX empresarial distinto de sus LAN; los clientes compartían ese número pero conservaban nodos únicos. Hacer portátil una capa exigía nueva coordinación en otra.
El cierre también era verdad operativa
La presencia virtual solo existía mientras ambos extremos coincidían en el ciclo de vida. El agente foráneo repetía la baja cada dos segundos. Una respuesta válida eliminaba la asociación y liberaba el Tunnel ID. Tras diez fallos, se anotaba el error y se desconectaba al cliente de todos modos.
Por ello, el cliente podía haber desaparecido localmente mientras el estado remoto aún no se había confirmado como eliminado. Después de un reinicio, un identificador podía ser válido en un extremo e inexistente en el otro. La verdad era la coincidencia entre dos bloques de control, historial de reintentos, conexión actual y tratamiento real del paquete, no un único campo.
Protocolo privado, lección histórica pública
La nota del IESG fue explícita: RFC 2107 documentaba un protocolo privado, no producido por un grupo de trabajo ni situado en la vía de estándares. Datatracker lo clasifica hoy como Legacy y sin posición formal en el proceso del IETF.
Eso no le resta valor. Conserva cómo una arquitectura propietaria anterior a L2TP hizo portátil la ubicación de red: centralizó estado entre acceso y hogar, autenticó esa frontera, asignó un nombre local al túnel y mantuvo ignorante al cliente. Mobile IP cubría movilidad más amplia; L2F y L2TP separaron acceso y terminación de enlace; GRE dio el sobre. ATMP ensambló un subconjunto para productos concretos. Publicar el diseño no convirtió su uso en consenso.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
