Resumen

  • Los 1508 bytes necesarios para alojar una carga PPP de 1500 son carga útil Ethernet bajo la cuenta de seis más dos bytes, no una medida universal de la trama completa en el cable.
  • La pasarela residencial heredó una diferencia que el ordenador antes negociaba directamente: 1500 en la red local frente a 1492 en el tramo PPPoE tradicional.
  • PPP-Max-Payload permitió declarar una capacidad mayor; LCP la sujetó a límites locales y una prueba de tamaños pudo restringir el envío a 1492 durante la sesión.

El número correcto puede contar el objeto equivocado

Para transportar 1500 bytes de carga PPP, la ampliación de PPPoE necesitaba 1508 bytes de carga Ethernet. La cuenta es sencilla. El error comienza cuando se presenta el resultado como tamaño total de cualquier trama o como una instrucción que sirve sin cambios para todos los equipos.

El RFC 2516, de febrero de 1999, partía de una carga Ethernet máxima de 1500 bytes. El encabezado PPPoE consumía seis; PPP Protocol-ID, otros dos. Quedaban 1492 para PPP. Encabezado Ethernet, comprobación de trama, preámbulo y otros elementos no formaban parte de esos 1500.

El RFC 4638, publicado en septiembre de 2006, no eliminó ninguno de los ocho bytes. Su propuesta dependía de sistemas Ethernet capaces de transportar cargas mayores. La capacidad inferior debía aumentar para conservar arriba el tamaño deseado.

Esta diferencia contable importa en una migración. Una interfaz puede mostrar el límite de un objeto distinto del que aparece en otra. Sin precisar qué campos se incluyen, comparar cifras no permite demostrar compatibilidad. Un número aparentemente suficiente puede estar midiendo otra cosa.

La historia de la extensión se entiende mejor desde ahí: no fue un permiso para ignorar la encapsulación, sino un procedimiento para separar lo anunciado, lo negociable y lo observado.

La resta ya existía; el punto de entrega cambió

El RFC 4638 describe un acceso inicial en el que el propio ordenador comenzaba la sesión PPPoE. Según ese relato, el límite de 1492 solía resultar aceptable. El equipo que producía tráfico participaba directamente en la negociación de la conexión limitada.

La pasarela residencial alteró esa relación. Recibía IP sobre Ethernet desde la red local y establecía PPPoE hacia el acceso de banda ancha. Del lado local podía llegar un paquete IP de 1500 bytes; del otro lado permanecía el presupuesto tradicional de 1492.

No había aparecido una nueva cabecera. Había cambiado quién debía conciliar dos expectativas. El ordenador dejaba de ser el extremo PPP de ese tramo y la pasarela asumía la diferencia entre la comodidad local y las condiciones del acceso.

El documento también menciona conversiones de PPPoA a PPPoE y equipos de cliente PPPoA entonces desplegados que no admitían 1492. Es una observación histórica de 2006, no una afirmación sobre todos los equipos ni una fotografía del parque actual.

PPP sobre ATM tampoco carecía de límites. El RFC 2364, de julio de 1998, exigía que la MRU sobre AAL5 no superase la CPCS-SDU máxima del contrato de tráfico de la conexión virtual para la dirección correspondiente. Migrar significaba cambiar de condiciones inferiores, no pasar de un medio ilimitado a otro arbitrariamente limitado.

Una sesión encontrada no es una sesión probada

PPPoE divide el establecimiento en descubrimiento y sesión PPP. El cliente emite PADI, recibe ofertas PADO, selecciona un concentrador y envía PADR; PADS confirma la sesión. Las direcciones Ethernet y el identificador de sesión permiten asociar los intercambios posteriores.

Completar esa secuencia no termina todas las fases de PPP. La configuración del enlace, la autenticación cuando corresponda y la preparación de la capa de red siguen teniendo funciones propias. Tampoco el paso de pequeños mensajes de control demuestra que vaya a pasar un paquete mayor.

La extensión incorpora PPP-Max-Payload durante el descubrimiento. El cliente que desea superar 1492 debe incluirlo tanto en PADI como en PADR. Un servidor que soporte la extensión y reciba el campo debe devolver la etiqueta del cliente en PADO y PADS.

El tipo de etiqueta es 0x0120, decimal 288. Su valor binario ocupa dos bytes y expresa la carga PPP máxima que el cliente soporta al enviar y al recibir. El 288 identifica la etiqueta; no concede una carga de 288 bytes. Los dos bytes del valor pertenecen al descubrimiento, no a un cargo adicional en cada paquete de sesión.

Si ambas partes no indican soporte durante esa etapa, permanece 1492. Los equipos antiguos pueden ignorar etiquetas desconocidas; ignorar no equivale a consentir una ampliación. Tampoco un valor anunciado de 1492 o menos permite deducir un techo superior.

El eco de la propuesta no fija el resultado

El servidor devuelve la etiqueta recibida. No está obligado a reescribir en ella su propio límite final. Su capacidad local interviene en la negociación PPP posterior.

El procedimiento empieza con un máximo de 1492. Si existe una etiqueta con un valor mayor, el máximo negociable pasa a ser el menor entre ese valor y la MTU de la interfaz menos ocho. A partir de ahí, el LCP negocia de la forma habitual.

Por eso una captura puede mostrar una etiqueta alta devuelta por el servidor y un resultado posterior más bajo sin que exista incoherencia. Se han observado dos decisiones: reconocer la extensión y elegir lo que permiten las condiciones locales.

El RFC 1661, de julio de 1994, define MRU como unidad máxima de recepción para Information y Padding. No incluye el campo de protocolo ni el entramado externo. Anunciar esa capacidad no obliga al otro extremo a llenar todos los paquetes hasta el máximo.

El PPP ordinario usa 1500 como valor por defecto, pero ese valor general no anula el límite específico de PPPoE. Dentro de un intercambio válido de la extensión, incluso una etiqueta superior a 1500 deja el valor ordinario en 1500 si no se negocia una MRU mayor. Anuncio, techo autorizado y elección efectiva siguen siendo magnitudes separadas.

Los puentes no participaron en el acuerdo

Entre los extremos podía haber equipos Ethernet que transportasen el descubrimiento y los mensajes de LCP, pero no las tramas mayores. La negociación no recogía una declaración de cada puente del recorrido.

El RFC 4638 prevé por ello una comprobación después de abrir la sesión y negociar una MRU superior a 1492. El emisor debería disponer de la opción de enviar una o más LCP Echo-Requests con el tamaño de la MRU. Si no recibe respuestas, puede repetir con 1492. Si las peticiones pequeñas sí obtienen respuesta, no debe enviar por encima de 1492 durante esa sesión.

La gradación es importante. La función debería estar activada de manera predeterminada y ser configurable; un conocimiento previo de la red puede justificar desactivarla. El texto no impone una cantidad universal de intentos ni un temporizador idéntico para todos.

El resultado tampoco identifica por sí solo al responsable. Un intento grande sin respuesta seguido de uno pequeño con respuesta justifica la restricción indicada. Dos tamaños sin respuesta no demuestran que el pequeño funcione. Una respuesta a un paquete pequeño no certifica el transporte de uno grande.

Según el RFC 1661, Echo-Request y Echo-Reply pertenecen al estado LCP Opened y la respuesta conserva el Identifier correspondiente. No se desprende de ello que toda respuesta deba tener el mismo tamaño que la petición. Ni siquiera un intercambio satisfactorio garantiza permanentemente la capacidad máxima en ambas direcciones.

Se necesita registrar lo que efectivamente se envió y recibió. Un indicador de «prueba correcta» sin dimensiones ni dirección borra parte de la evidencia que hacía útil la comparación.

La salida a Internet sigue teniendo otro recorrido

Esta prueba de PPPoE no sustituye el descubrimiento de MTU del camino IP. El RFC 1191, publicado en noviembre de 1990, describe un origen IPv4 que usa el bit de no fragmentar y reduce su estimación cuando un router comunica por ICMP que no puede reenviar sin fragmentación.

En ese caso el router descarta el paquete y avisa. No todo paquete excesivo se fragmenta automáticamente para llegar a destino. La presencia de DF cambia la respuesta al problema de tamaño.

La comprobación de la sesión observa el acceso y el manejo Ethernet intermedio. Puede funcionar aunque más adelante exista otra limitación hasta el destino remoto. Convertirla en una garantía de extremo a extremo atribuiría a la medición un alcance que no tiene.

El interés de la prueba local no disminuye al reconocer ese límite. Al contrario: una evidencia útil es aquella cuya conclusión permanece dentro de lo que se ha observado.

Una asignación no es una ampliación física

RFC 4638 es Informational, no un Internet Standard. Su nota del IESG pide cautela en el contexto normativo de 2006 respecto a cargas Ethernet superiores a 1500. No debe reciclarse como descripción de las normas vigentes en 2026.

En junio de 2007, el RFC 4937 organizó el registro IANA de los tipos de etiqueta PPPoE de 16 bits e incluyó PPP-Max-Payload bajo el valor 288. El registro de parámetros PPPoE de IANA consultado conserva esa asociación.

El registro proporciona un vocabulario común a implementaciones independientes. No certifica la capacidad de una red, ni establece una fecha de adopción universal. La encapsulación de 1999, la propuesta de ampliación de 2006 y la organización del registro de 2007 no son un único acontecimiento.

Lo que quedó fue una disciplina de comprobación: el descubrimiento indica entendimiento mutuo, LCP decide dentro de condiciones locales y la observación puede restringir la sesión. La resta original sigue siendo real. Los extremos coordinan su conducta, pero no negocian la desaparición de ocho bytes.