Resumen

  • Un nodo podía conservar legítimamente su dirección de origen y aun así incumplir las restricciones sobre las direcciones fuente admitidas desde la red visitada.
  • El túnel inverso enviaba primero los datos al agente de origen, dentro de un paquete cuya cabecera exterior correspondía al trayecto entre agentes.
  • Aceptar el registro, admitir una modalidad de entrega y permitir el paso de los datos eran decisiones distintas. Renunciar al túnel podía resolver la primera y dejar intacto el problema de las demás.

Un éxito demasiado pequeño

El RFC 3024, de enero de 2001, contiene una advertencia que sigue siendo útil para leer sistemas distribuidos: si una petición de túnel inverso es rechazada, el nodo puede intentar registrarse sin ella. Es posible que entonces lo consiga. Sin embargo, en una red que necesita ese túnel para aceptar el tráfico, el resultado puede no servir para transmitir datos.

No es que la respuesta mienta. Acepta unas condiciones diferentes. El error aparece cuando el observador convierte esa aceptación limitada en una promesa sobre toda la comunicación. La negociación ha terminado con éxito; la ruta que hacía falta quizá ni siquiera se ha solicitado ya.

Para entender por qué importaba tanto una opción de registro, hay que volver a la separación entre dirección y ubicación que proponía Mobile IPv4. El RFC 2002, de octubre de 1996, permitía a un nodo mantener su dirección de origen al cambiar de subred. Un agente en la red de origen reenviaba los paquetes hacia una dirección que representaba la ubicación actual.

Así, el interlocutor podía seguir usando la misma dirección aunque el nodo estuviera en otro lugar. El trabajo de seguir el desplazamiento recaía en agentes, registros y túneles. No era una explicación de cualquier forma de telefonía móvil, sino un modelo concreto de movilidad entre subredes IP.

Lo que el trayecto de ida daba por supuesto

La dirección temporal, conocida en el protocolo como care-of address, podía ser la de un agente extranjero compartido por varios nodos. También podía pertenecer al propio nodo, que terminaba entonces el túnel por sí mismo. Confundir ambos casos haría parecer necesario que cada visitante obtuviera una dirección IPv4 exclusiva de la red local.

En el caso con agente extranjero, el tráfico recibido podía viajar desde el agente de origen hasta ese agente visitante. El tráfico saliente, en cambio, no tenía por qué volver primero a casa. El modelo de 1996 suponía que el encaminamiento dependía de la dirección de destino, no de la de origen. El nodo podía emitir hacia su interlocutor manteniendo como fuente su dirección habitual.

Ese supuesto dejaba fuera una pregunta que los operadores tenían motivos para hacer: ¿debería aparecer esta dirección fuente por esta conexión? Una ruta válida hacia el destino no responde a esa pregunta.

El RFC 2827, publicado en mayo de 2000 como BCP 38, proponía limitar las direcciones fuente admitidas desde redes conectadas a un proveedor. Restringirlas a los prefijos apropiados reducía el espacio de suplantación. No demostraba la identidad de cada emisor, porque aún cabía falsificar una dirección dentro del rango permitido, pero sí excluía fuentes incompatibles con ese punto de entrada.

El móvil podía ser precisamente una de esas fuentes incompatibles sin haber usurpado nada. Su dirección pertenecía a la red de origen, no a la red desde la que estaba enviando. El documento reconocía expresamente el conflicto con Mobile IP y señalaba el túnel inverso. La solución no exigía declarar equivocada a la movilidad ni retirar toda comprobación de origen.

Volver antes de seguir

El RFC 2344, de mayo de 1998, definió la extensión que después revisaría el RFC 3024. El túnel era inverso respecto del que llevaba los datos desde el agente de origen hasta el nodo desplazado. Ahora el tráfico del nodo también podía dirigirse primero al agente de origen y continuar desde allí hacia el interlocutor.

El cambio decisivo estaba en la cabecera exterior. La encapsulación descrita en el RFC 2003 permite que un paquete conserve dentro las direcciones de la comunicación y viaje con otras direcciones que identifican los extremos del túnel. Desde el agente extranjero hacia el agente de origen, la fuente exterior es la dirección care-of del primero. Dentro permanece la dirección de origen del nodo.

La red visitada recibe así un paquete exterior cuya fuente encaja con ese trayecto. No se ha convertido la dirección interior en una dirección local, ni se ha cambiado la identidad que ve el interlocutor. Se ha separado la información que cada tramo necesita utilizar.

El procedimiento tiene límites. Encapsular no equivale a cifrar. Tampoco permite afirmar que todos los bits interiores permanecen idénticos, pues el reenvío puede modificar campos como el TTL. Y que los extremos de los túneles sean simétricos no obliga a que ambos sentidos recorran los mismos enlaces físicos.

Dos maneras de pedir el regreso

La entrega directa parte de un gesto corriente: el nodo utiliza al agente extranjero como encaminador predeterminado y le envía el paquete sin una envoltura adicional. El agente lo identifica y lo encapsula hacia el agente de origen. Esta modalidad permite el túnel inverso de unicast, pero no la selección de qué tráfico debe utilizarlo.

La entrega encapsulada añade una decisión explícita en el nodo. Este envuelve primero el paquete para el agente extranjero; el agente elimina esa envoltura y crea la que lo llevará al agente de origen. En el primer tramo, la fuente exterior sigue siendo la dirección de origen del móvil. Solo al salir del agente extranjero la fuente exterior pasa a ser la dirección care-of.

Esa diferencia entre los dos tramos importa tanto para explicar como para diagnosticar. El móvil no toma prestada sin más la dirección del agente para presentarse en la red local. Cada envoltura corresponde al emisor y al destinatario de una operación distinta.

Tras negociar la entrega encapsulada, los paquetes que el móvil entregue sin encapsular no deben meterse en el túnel inverso. Se encaminan normalmente. Eso permite intentar acceder a recursos locales, como una impresora, sin llevar cada intercambio hasta la red de origen. La posibilidad sigue dependiendo de las rutas y permisos locales: seleccionar otro tratamiento no garantiza que el recurso acepte la comunicación.

La entrega encapsulada es también necesaria para transportar difusión y multicast en sentido inverso a través del agente extranjero. Por tanto, las modalidades no son dos redacciones equivalentes de la misma función. Cambian el alcance del servicio y la capacidad del nodo para escoger.

El bit no es el servicio entero

En el anuncio del agente, el bit T comunica disponibilidad del túnel inverso. En la solicitud de registro, T expresa que el nodo lo pide. Para solicitar entrega encapsulada se añade una extensión de tipo 130 y longitud cero; si falta, se solicita entrega directa. No corresponde añadirla cuando T está desactivado.

La extensión tiene una posición definida entre elementos de autenticación y la procesa el agente extranjero, que no la reenvía al agente de origen. Su significado está acotado a la entrega que se está acordando. No representa el consentimiento de todas las redes intermedias.

Además, las obligaciones de implementación cambiaron. El RFC 2344 exigía ambas modalidades al agente que anunciara soporte del túnel inverso. El RFC 3024 mantuvo obligatoria la directa y pasó a recomendar la encapsulada. El código 79 permitió rechazar específicamente una modalidad no admitida.

El registro Mobile IP de IANA confirma esa asignación. Una nota antigua que quedó en una sección del RFC 3024 dice que 79 aún no estaba asignado; no debe usarse para describir el registro vigente. El propio apartado de asignaciones y el resumen de cambios del documento ya reflejan la asignación. La lectura histórica requiere contrastar esos lugares, no elegir la frase más conveniente.

Una dirección correcta tampoco autentica el paquete

El túnel inverso abre un servicio de tránsito y, con él, la posibilidad de que alguien intente utilizarlo bajo una identidad ajena. La solicitud de registro debe salir con TTL 255 y el agente extranjero comprueba ese valor. Un encaminador IP atravesado lo reduce, de modo que la prueba limita ciertas peticiones que llegan desde fuera del enlace.

La comprobación no identifica al vecino que envía la petición. Un atacante presente en el mismo enlace sigue siendo un problema diferente. Las asociaciones de seguridad y la autenticación no pueden sustituirse por un valor alto de TTL, ni las técnicas criptográficas de un documento histórico deben presentarse automáticamente como recomendaciones actuales.

En el agente de origen, la comprobación de la asociación debe estar implementada y se recomienda activarla por defecto. La fuente exterior tiene que corresponder a la dirección care-of registrada; la fuente interior, a la dirección de origen del nodo; y la encapsulación, a la acordada. Si no hay asociación adecuada o la modalidad es incorrecta, el paquete se descarta.

Esto limita lo que el agente acepta reenviar. No demuestra por sí mismo la autenticidad criptográfica del contenido. Incluso el mensaje que modifica la asociación merece precisión: el erratum técnico verificado del RFC 3024 corrige una referencia a la respuesta de registro para que diga solicitud de registro. Invertir esos términos alteraría la explicación de cuándo se cambia el estado.

La frontera que el túnel no prometía borrar

El RFC 3024 parte, en su cuerpo principal, de un espacio común de direcciones y excluye una solución general para atravesar cortafuegos. Su apéndice examina algunos casos de espacios distintos, pero exige condiciones: los agentes deben poder alcanzarse en el espacio del trayecto exterior y las direcciones interiores deben tener significado en los ámbitos pertinentes.

La reutilización de direcciones privadas detrás de agentes de origen distintos exige conservar contexto. Para entregar al nodo correcto también hace falta una asociación local segura; la sección correspondiente exige identificación fiable de enlace y desaconseja un Ethernet compartido sin autenticar. El túnel no convierte una dirección privada repetida en un identificador universal.

En noviembre de 2010, el RFC 5944 seguía remitiendo al túnel inverso al tratar el filtrado de entrada. La continuidad de esa referencia documenta una necesidad arquitectónica, no una cifra de adopción.

La lección histórica queda en la diferencia inicial. Un registro puede establecer una asociación válida, un túnel puede dar a un tramo una fuente apropiada y una red puede aun así rechazar el paquete por otra razón. La comunicación útil depende de que esas condiciones se encuentren; ninguna respuesta de éxito aislada las contiene todas.