Resumen

  • La RFC 2516 limitó el MTU PPP de PPPoE a 1.492 bytes: seis bytes de cabecera PPPoE y dos del identificador de protocolo PPP ocupaban el resto de la carga Ethernet de 1.500.
  • La RFC 4638 convirtió un MTU/MRU mayor en una negociación opcional. El cliente, el concentrador de acceso, la configuración local y los segmentos Ethernet intermedios debían poder transportarlo.

El límite cabía en una resta

Una carga Ethernet de 1.500 bytes parece espacio suficiente para un paquete IP del mismo tamaño. PPPoE consumía ocho antes de que el paquete llegara al cable: seis en su propia cabecera y dos en el identificador PPP. En febrero de 1999, la RFC 2516 fijó el MTU de PPP en 1.492 bytes sobre Ethernet estándar.

La resta era sencilla. La decisión de diseño era menos obvia: ¿por qué conservar PPP cuando el nuevo dispositivo de acceso del abonado hablaba Ethernet?

La banda ancha quería Ethernet y una sesión

La RFC 2516 respondió en términos de operación. Ethernet era una forma barata de conectar varios equipos detrás de un puente en casa. PPP conservaba el control de acceso, la facturación y el servicio por usuario. El hogar compartía el medio local; el proveedor mantenía una sesión distinta para cada abonado.

Ese acuerdo incluyó ocho bytes en cada paquete. El proveedor conservó la frontera de la sesión y el paquete IP del abonado dispuso de ocho menos dentro de la carga Ethernet convencional de 1.500 bytes. La RFC 2516 fijó el límite en lugar de dejar que cada equipo adivinara si el siguiente enlace tenía espacio.

La diferencia importaba cuando un extremo esperaba una unidad PPP de 1.500 bytes y otro negociaba 1.492. La introducción de la RFC 4638, publicada en 2006, describe la fragmentación que podían producir esas rutas mixtas de banda ancha. La extensión buscaba reducirla en redes de nueva generación.

Los ocho bytes pasaron a ser una capacidad negociable

La RFC 4638 no hizo que todas las sesiones PPPoE superaran los 1.492. Para los diseños de banda ancha de nueva generación que describe, exige que un BRAS que actúe como servidor PPPoE admita negociaciones por encima de ese valor; la etiqueta opcional PPP-Max-Payload determina si un cliente y un servidor concretos pueden usarlo. Su valor de dos bytes indica la carga PPP máxima que admite el cliente en ambos sentidos. Para solicitar más de 1.492, el cliente la incluye en PADI y PADR. Si el servidor puede atender la solicitud, la devuelve en PADO y PADS.

El servidor conserva su propio límite. La RFC 4638 permite negociar un MRU mayor según la configuración local y el máximo que anuncia el cliente. La regla selecciona el menor valor entre la etiqueta y el MTU de la interfaz del servidor menos ocho bytes. La etiqueta inicia la negociación; no amplía la interfaz ni los ajustes de un segmento intermedio.

El tamaño se convierte así en una cadena de decisiones. El cliente puede pedirlo. El concentrador solo confirma lo que admite. La interfaz local debe dejar sitio para la encapsulación. Cada segmento Ethernet de la ruta debe llevar el paquete resultante. El número que aparece en la pantalla del abonado no es un recibo de todos los switches entre la casa y el concentrador.

La ruta podía responder

Tras abrir la sesión, la RFC 4638 describe una prueba: el emisor puede mandar una solicitud Echo del tamaño del MRU al receptor a través de los equipos Ethernet intermedios. Si la solicitud grande no recibe Echo-Reply, pero la de 1.492 bytes sí, el emisor debe dejar de enviar paquetes mayores en esa sesión.

El retroceso importa. Si falta la etiqueta o alguno de los dos extremos no está configurado para admitir más, sigue vigente el límite de 1.492 de la RFC 2516. Si la prueba falla, la sesión puede volver a ese tamaño. La extensión mantuvo el acuerdo anterior como suelo de compatibilidad y permitió negociar más en las rutas que estaban preparadas.

Una opción publicada no cambió la norma Ethernet

La RFC 4638 es informativa. Su nota del IESG señala que, al publicarse, ninguna norma IEEE vigente admitía tramas jumbo por encima de un MTU de 1.500 bytes y advierte sobre la interoperabilidad de las extensiones no normalizadas. El RFC permitió a los pares PPPoE pedir más; cada puerto Ethernet aún tenía que admitirlo.

La historia no se reduce a «1.492 pasó a ser 1.500». El límite de 1999 permanece cuando la ruta lo necesita; la extensión define la capacidad que hay que intercambiar y cómo probar un tamaño mayor. El protocolo describe la oferta. Los participantes y la ruta deciden si funciona.

Los RFC documentan el diseño y el objetivo de reducir la fragmentación, no qué redes activaron la etiqueta; una configuración fechada del concentrador o una captura de descubrimiento acreditaría su uso en una red concreta.

La pregunta útil es quién puede solicitar la extensión, quién debe responder y qué sistemas compatibles deciden ponerla en funcionamiento. Un protocolo puede publicar la opción; solo el equipo en servicio convierte esa posibilidad en una ruta operativa.

Fuentes