Résumé

  • La RFC 2516 a plafonné le MTU PPP de PPPoE à 1 492 octets : six octets d’en-tête PPPoE et deux octets de Protocol ID PPP occupaient le reste d’une charge Ethernet de 1 500 octets.
  • La RFC 4638 a rendu possible un MTU/MRU supérieur par échange facultatif. Le client, le concentrateur d’accès, la configuration locale et les segments Ethernet intermédiaires devaient pouvoir le transporter.

Le plafond tenait en une soustraction

Une charge Ethernet de 1 500 octets paraît assez grande pour un paquet IP de 1 500 octets. PPPoE en consommait huit avant même que le paquet arrive sur le câble : six pour son en-tête et deux pour l’identifiant de protocole PPP. En février 1999, la RFC 2516 a fixé le MTU PPP à 1 492 octets sur un segment Ethernet classique.

La soustraction était simple. Le choix derrière l’encapsulation l’était moins : pourquoi conserver PPP quand le nouvel équipement d’accès de l’abonné parlait Ethernet ?

Le haut débit voulait Ethernet et la session PPP

La RFC 2516 répondait en termes d’exploitation. Ethernet reliait à faible coût plusieurs hôtes derrière un pont chez l’abonné. PPP conservait le contrôle d’accès, la facturation et le modèle de service par utilisateur. Le foyer partageait un support local ; le fournisseur gardait une session distincte pour chaque abonné.

Cet arrangement inscrivait huit octets dans chaque paquet. Le fournisseur gardait la frontière de session, tandis que le paquet IP de l’abonné disposait de huit octets de moins dans la charge Ethernet conventionnelle de 1 500 octets. La RFC 2516 a donné une limite explicite au lieu de laisser les équipements deviner si le prochain lien avait de la place.

La différence comptait lorsqu’un côté attendait une unité PPP de 1 500 octets et l’autre négociait 1 492. Dans son introduction de 2006, la RFC 4638 décrit les fragments nombreux que ces chemins haut débit mixtes pouvaient produire. L’extension visait à réduire cette fragmentation dans les réseaux haut débit de nouvelle génération.

Les huit octets sont devenus une capacité à négocier

La RFC 4638 n’a pas fait dépasser 1 492 à chaque session PPPoE. Pour les architectures haut débit de nouvelle génération qu’elle décrit, elle exige qu’un BRAS jouant le rôle de serveur PPPoE sache négocier au-delà de cette valeur ; la balise facultative PPP-Max-Payload détermine si un client et un serveur donnés peuvent l’utiliser. Sa valeur de deux octets indique la charge PPP maximale que le client prend en charge dans les deux sens. Pour demander plus de 1 492, le client place la balise dans PADI et PADR. Un serveur capable de répondre la renvoie dans PADO et PADS.

Le serveur garde sa propre limite. La RFC 4638 lui permet de négocier un MRU supérieur selon sa configuration locale et la valeur annoncée par le client. La règle de sélection retient la plus petite valeur entre la balise et le MTU de l’interface du serveur moins huit octets. Une balise ouvre la négociation ; elle n’agrandit ni l’interface ni les paramètres d’un segment traversé.

La taille devient ainsi une chaîne de décisions. Le client peut la demander. Le concentrateur ne peut confirmer que ce qu’il prend en charge. L’interface locale doit laisser de la place à l’encapsulation. Chaque segment Ethernet du chemin doit transporter le paquet final. Le nombre affiché chez l’abonné n’est pas un reçu de tous les commutateurs entre le domicile et le concentrateur.

Le chemin pouvait répondre

Après l’ouverture de la session, la RFC 4638 décrit un test : l’émetteur peut envoyer une requête Echo de taille MRU vers le destinataire, à travers les équipements Ethernet intermédiaires. Si la grande requête ne reçoit aucun Echo-Reply, mais que celle de 1 492 octets en reçoit un, l’émetteur doit cesser d’envoyer des paquets plus grands sur cette session.

Le repli compte. Sans balise ou sans configuration supérieure chez l’un des deux pairs, la règle de 1 492 octets de la RFC 2516 reste applicable. Si le test échoue, la session peut revenir à cette limite. L’extension a conservé l’ancien accord comme seuil de compatibilité tout en autorisant les chemins prêts à négocier davantage.

Une option publiée ne changeait pas la norme Ethernet

La RFC 4638 est un RFC informatif. À sa publication, la note de l’IESG indiquait qu’aucune norme IEEE alors en vigueur ne prenait en charge les trames jumbo au-delà d’un MTU de 1 500 octets et signalait le risque d’interopérabilité des extensions non normalisées. Le RFC donnait aux pairs PPPoE un moyen de demander davantage ; chaque port Ethernet devait encore l’accepter.

La chronologie ne se résume donc pas à « 1 492 est devenu 1 500 ». La limite de 1999 demeure là où le chemin en a besoin ; l’extension nomme les capacités à échanger et la façon de tester la taille supérieure. Le protocole décrit l’offre. Les participants et le chemin décident si elle fonctionne.

Les RFC décrivent la conception et l’objectif de réduction de la fragmentation, pas les réseaux qui ont activé la balise ; une configuration datée de concentrateur ou une capture de découverte établirait l’adoption sur un réseau précis.

La bonne question est de savoir qui peut demander l’extension, qui doit répondre et quels systèmes compatibles choisissent de la faire fonctionner. Un protocole peut publier l’option ; seuls les équipements en service peuvent en faire un chemin opérationnel.

Sources