Resumen

  • La RFC 2516 separó el descubrimiento, sin estado de sesión, de la sesión PPP punto a punto; ambos extremos asignaban recursos de interfaz virtual solo después de establecerla.
  • Una AC-Cookie opcional permitía al concentrador comprobar que la dirección de origen podía devolver un valor que había recibido. Host-Uniq y Relay-Session-Id atendían correlaciones distintas, propias del host y del relé.
  • Esos tokens transportaban contexto limitado de paquetes. Ninguno autenticaba a una persona ni demostraba que después hubiera configuración PPP, tráfico o servicio comercial.

Difusión sin tabla de sesiones

En febrero de 1999, la RFC 2516 describió cómo transportar PPP sobre una Ethernet compartida por varios hosts y concentradores de acceso. El host difundía un PADI; los concentradores capaces de atenderlo podían responder con PADO. El host elegía una oferta y enviaba un PADR unicast al concentrador seleccionado. El PADS confirmaba el servicio aceptado y asignaba un identificador de sesión. La RFC separó Descubrimiento y Sesión PPP: el descubrimiento seguía sin estado de sesión hasta que se establecía la sesión. En ese momento, tanto el host como el concentrador debían asignar recursos para una interfaz PPP virtual.

La distinción evitaba que cada solicitud visible en una red compartida se convirtiera en un compromiso duradero. “Sin estado” no significaba que procesar paquetes no consumiera nada; describía el límite previo a reservar el estado más persistente de una sesión PPP ya elegida.

El valor tenía que volver

El concentrador podía incluir una etiqueta AC-Cookie opcional en PADO. El host debía devolverla sin cambios en PADR y no interpretaba sus bytes. La RFC recomendaba que el concentrador pudiera regenerar el valor a partir de la dirección de origen del PADR. Así podía comprobar que una dirección que recibió la oferta era alcanzable de vuelta y limitar las sesiones simultáneas para esa dirección.

La especificación citaba como ejemplo un HMAC de la dirección MAC del host con una clave conocida solo por el concentrador. No imponía ese algoritmo ni prometía protección universal: advertía expresamente que la cookie no evitaba todos los ataques de denegación de servicio. Su función era aplazar el compromiso de recursos hasta ver regresar el valor, no identificar a la persona detrás de una dirección.

Los otros tokens tenían propietarios distintos. Host-Uniq, elegido por el host, asociaba una respuesta con su solicitud; el concentrador lo reflejaba sin interpretarlo. Relay-Session-Id, que podía insertar un relé intermedio, era opaco para ambos extremos y debía volver intacto. Correlacionar paquetes no equivale a establecer identidad.

PADS cambia el estado de recursos

Un PADS aceptado incluía un SESSION_ID no nulo y el servicio aceptado; un rechazo usaba identificador cero y una etiqueta de error. La sesión se definía mediante la dirección MAC de origen, la de destino y SESSION_ID en conjunto. El número de 16 bits, aislado, no bastaba.

PADS abría la etapa de Sesión PPP, pero no realizaba la negociación LCP, la autenticación opcional ni la configuración de protocolos de control de red que describe la RFC 1661. Este artículo no vuelve sobre los límites de carga útil ni los 1492 bytes de la RFC 4638, ya cubiertos en una pieza vecina. Se centra en la asignación de recursos y el alcance de tres etiquetas, no en si luego se entregó el servicio.

La RFC documenta una decisión de diseño y los límites que declara; no mide memoria ahorrada, uso actual ni el éxito de una autenticación o entrega concreta.

Fuentes: RFC 2516; RFC 1661; RFC 2104; RFC 4638 (límite de carga útil vecino, excluido aquí).