Resumen

  • Un enlace puede devolver una trama sin alterar sus bits. La integridad de la trama y la participación de otro extremo son hechos distintos.
  • Magic-Number utiliza elecciones locales y una negociación que intenta separar dos valores inicialmente iguales; la igualdad por sí sola no identifica un bucle.
  • El tipo de mensaje, su dirección y el estado negociado delimitan la prueba. La recuperación sigue siendo una decisión de la implementación, y la autenticación requiere otro mecanismo.

Una copia demasiado buena

La trama sale y vuelve. Los bits están en orden; el valor de comprobación también. A primera vista, el enlace parece funcionar. Sin embargo, hay una explicación menos tranquilizadora: la propia línea ha devuelto lo transmitido y ningún interlocutor independiente ha elaborado una respuesta.

No se trata de que el control de integridad haya fallado. En la encapsulación de PPP descrita por RFC 1662, de julio de 1994, el FCS comprueba los campos de la trama incluidos en su cálculo. Por defecto ocupa dos octetos, aunque existe una variante de cuatro. Una trama que regresa sin cambios puede conservar un FCS válido.

El resultado correcto corresponde a una pregunta limitada. No demuestra que al otro lado haya una máquina distinta, que esa máquina sea la prevista ni que una aplicación funcione. Para reconocer un enlace replegado sobre sí mismo hacía falta observar una decisión que no procediera del emisor original.

Magic-Number se ocupó de esa necesidad. Su pequeño valor no describía el contenido transportado. Permitía comparar estados de los extremos y buscar una diferencia que una simple copia no produciría.

PPP separó el enlace de lo que iba a transportar

En noviembre de 1989, RFC 1134 presentó PPP como tres elementos: una encapsulación, un protocolo extensible de control del enlace, LCP, y una familia de protocolos NCP para configurar las distintas capas de red.

Esta división evitaba atribuir al mero transporte de bits todas las condiciones necesarias para comunicar. Primero se establecía y examinaba el enlace; después se configuraban los protocolos de red correspondientes. La preparación de la línea no equivalía todavía al éxito de todo lo que circularía por ella.

Los formatos Echo y Discard de aquel documento ya reservaban cuatro octetos para Magic-Number. Sin una opción que modificase el comportamiento, debían enviarse a cero e ignorarse al recibirlos. El uso adicional de ese campo quedaba fuera de la explicación en ese punto.

Por tanto, el campo no nació de golpe en 1994. RFC 1172, publicado en julio de 1990 por D. Perkins y R. Hobby, detalló las opciones iniciales y el procedimiento del número mágico. RFC 1331, de mayo de 1992, mantuvo el mecanismo. RFC 1661, de julio de 1994, lo recogió en su sección 6.4.

La trayectoria muestra cómo una posición reservada adquirió reglas de uso compartidas. No permite suponer que todos los equipos instalados adoptaran esas reglas al publicarse el documento.

Un número de cada extremo, no un número para el mundo

Antes de proponer Magic-Number, cada implementación elige su valor. Lo deseable es que difiera, con probabilidad muy alta, del elegido al otro extremo. No tiene que obtener una identidad única para toda Internet.

La opción completa mide seis octetos: tipo, longitud y cuatro octetos de valor. El registro PPP de IANA asigna el tipo 5 a Magic-Number. Ese 5 identifica la clase de opción, no una máquina. El registro tampoco entrega los valores particulares que las máquinas van eligiendo.

La distinción reduce la coordinación necesaria. Dos extremos pueden formar una referencia local sin consultar un servicio mundial de nombres. A cambio, las implementaciones deben producir valores suficientemente distintos y conservar el estado que permite interpretarlos.

La simplicidad del campo no elimina esa responsabilidad. La desplaza al lugar donde se genera y se usa la evidencia.

La primera igualdad todavía admite dos historias

Cuando llega un Configure-Request con Magic-Number, su valor se compara con el del último Configure-Request enviado localmente. Si son distintos, el modelo previsto descarta que se trate de la mera devolución de esa petición. Si coinciden, aún no se sabe cuál de dos cosas ha ocurrido.

Puede haber un enlace en bucle. Pero también puede existir un interlocutor real que, por casualidad, haya elegido el mismo valor. La negociación no debe convertir la segunda posibilidad en una avería segura.

Ante la coincidencia, se envía un Configure-Nak con otro valor. El siguiente Configure-Request no se adelanta arbitrariamente: debe surgir del procesamiento normal, como la recepción de un Nak o el vencimiento del temporizador de reinicio.

Después se compara el valor de un Nak recibido con el del último Nak enviado por la propia máquina. Es una referencia diferente de la comparación entre peticiones. Otra igualdad aumenta la sospecha y obliga a elegir un nuevo número. Una diferencia aporta, dentro del comportamiento especificado, la decisión independiente que se buscaba. La nueva petición lleva el nuevo valor.

En un enlace realmente replegado, tanto las peticiones como las propuestas de cambio pueden regresar a su autor. Dos extremos independientes deberían separarse en sus elecciones. El mecanismo no consiste en castigar una igualdad, sino en provocar una oportunidad controlada de distinguir sus causas.

Cambiar el nombre del paquete cambia la lectura

El mismo valor puede ser obligatorio en otro mensaje. Un Configure-Ack válido debe reproducir las opciones de la petición sin modificarlas ni cambiar su orden, con el Identifier correspondiente.

Por ello, recibir el propio número dentro de ese acuse es normal. Recibirlo como propuesta del otro extremo en un Configure-Request es lo que inicia la comprobación de colisión. Un detector que solo busque igualdad entre enteros confundiría una negociación correcta con una línea reflejada.

Tampoco Echo significa que todos sus campos deban copiarse. Echo-Reply conserva el Identifier de la petición para relacionar ambos mensajes, pero utiliza el Magic-Number negociado de quien envía la respuesta. La correlación del intercambio y la marca local del emisor tienen funciones distintas.

Estas reglas impiden leer el número como si fuera una etiqueta autónoma. Hace falta saber qué acción representa, quién la ejecuta y qué ocurrió antes. La evidencia útil es el número situado en su conversación, no el número extraído de ella.

El azar tiene condiciones de funcionamiento

Los textos históricos ofrecen un modelo ideal de elecciones uniformes sobre 32 bits. Una coincidencia tendría una probabilidad aproximada de 2,3 × 10^-10. La cifra explica la intuición, pero no constituye una medición de fallos en equipos reales.

Si dos generadores arrancan desde el mismo estado y siguen el mismo cálculo, sus resultados pueden continuar siendo iguales. Volver a recibir una copia del mismo paquete tampoco equivale a realizar otra prueba independiente. Las probabilidades sucesivas requieren elecciones nuevas e independientes, no simplemente más líneas de registro.

Además, el cero está prohibido como valor propuesto de la opción, por lo que un selector uniforme entre valores legales no nulos tiene un espacio ligeramente distinto del modelo de 32 bits completo. No hace falta exagerar esa diferencia matemática; sí hace falta evitar una exactitud aparente que el despliegue no ha demostrado.

Los RFC recomiendan no ofrecer la opción cuando faltan buenas fuentes de singularidad o aleatoriedad. En ese caso pueden aceptarse o rechazarse las propuestas del interlocutor, pero la detección local fiable se reduce. El otro extremo podría conservar su propia capacidad de detección.

Es una decisión honesta sobre capacidad, no una avería del protocolo. Lo problemático sería presentar una secuencia correlacionada como si aportara independencia.

Un rechazo que no podía venir de uno mismo

Magic-Number incluye una obligación de reciprocidad. La implementación que propone la opción no puede rechazar esa misma opción cuando la propone su interlocutor.

De ahí surge una deducción peculiar. Si llega un Configure-Reject a la oferta local, una implementación conforme sabe que no habría generado ese rechazo ante su propia petición reflejada. El mensaje indica otro comportamiento, no la mera vuelta del suyo.

RFC 1661 permite seguir como si la negociación hubiera tenido éxito, reconociendo que el interlocutor no utilizará Magic-Numbers. Esto no significa que ambos extremos hayan negociado idéntica capacidad. El rechazo aporta una diferencia útil mientras mantiene la ausencia de la función en la otra dirección.

Tampoco constituye autenticación. La inferencia depende del modelo de comportamiento conforme, y un atacante no tiene por qué respetarlo. Un «no» puede demostrar algo acerca de una conversación sin demostrar quién lo ha pronunciado.

Dos significados del cero

En los campos de diagnóstico correspondientes, mientras no se haya negociado correctamente Magic-Number se transmite cero. Un interlocutor que no negoció su propio valor dispone así de un comportamiento definido.

Otra cosa es proponer cero dentro de la opción. Ese valor es ilegal y requiere un Nak, salvo que se rechace la opción. La misma representación binaria puede ser un estado predeterminado válido o una propuesta inválida, según dónde aparezca.

Durante el funcionamiento, recibir el valor local negociado indica reflexión en el modelo del protocolo. Recibir el valor esperado del interlocutor, o su cero válido cuando no negoció uno, es el caso ordinario. Un tercer valor sugiere comunicación con un extremo diferente.

Los mensajes también tienen límites de estado. Echo-Request y Echo-Reply solo se envían con LCP en Opened; una petición recibida en ese estado exige respuesta. No son sondas generales anteriores a la negociación. Discard-Request, por su parte, recibe y descarta datos sin emitir una contestación.

Detectar no es identificar, ni ordenar la reparación

La autenticación tiene una base distinta. RFC 1994, publicado en agosto de 1996, describe CHAP mediante un desafío y una respuesta calculada con un secreto compartido. Magic-Number no incorpora esa prueba dependiente de un secreto.

El contraste sirve para separar responsabilidades históricas, no para recomendar hoy un algoritmo antiguo. Un valor visible puede ayudar a reconocer una reflexión sin acreditar la identidad administrativa del emisor. Una trama válida puede ser auténtica como secuencia de bits y equivocada como evidencia de interlocución.

RFC 1661 tampoco fija una única recuperación. Describe, entre otras posibilidades, tratar el enlace como Down y abrirlo de nuevo, o utilizar Echo en el estado apropiado para observar el final del bucle. No establece un número de reintentos o un tiempo de espera universal.

La regla común llega hasta una conclusión limitada. El coste de interrumpir, esperar o reabrir pertenece a la implementación y a su operación. La trama que volvió intacta enseñaba precisamente eso: obtener una observación correcta no autoriza cualquier conclusión que resulte cómoda.