Résumé

  • Une limite acceptable pour le PC qui établissait lui-même sa session devenait une frontière à gérer lorsque la passerelle recevait des paquets IP de 1500 octets côté réseau local.
  • L’extension de 2006 ne supprime pas les huit octets d’encapsulation : elle suppose qu’Ethernet puisse les transporter en plus de la charge PPP souhaitée.
  • La découverte autorise une négociation plus ambitieuse ; LCP fixe les conditions de réception ; une comparaison entre grandes et petites requêtes peut ensuite imposer un repli pour la session en cours.

Le même protocole, une autre responsabilité

Un changement d’architecture peut transformer un détail connu en problème de raccordement. Le RFC 4638, publié en septembre 2006, décrit précisément ce déplacement. Dans le schéma initial qu’il rappelle, le PC lançait une session PPPoE à travers le réseau d’accès. Sa limite de 1492 octets était généralement acceptable pour ce rôle.

La passerelle résidentielle changeait la répartition du travail. Elle terminait le trafic IP sur Ethernet du réseau local et établissait elle-même PPPoE vers l’équipement d’accès large bande. Du côté domestique arrivaient alors des paquets IP pouvant atteindre 1500 octets ; du côté PPPoE, le plafond habituel demeurait 1492.

Aucun nouvel en-tête n’avait été ajouté pendant ce déménagement. Le coût existant se trouvait simplement entre deux environnements dont les attentes ne coïncidaient plus. La machine qui produisait le paquet n’était plus celle qui négociait la liaison contrainte.

Le document évoque aussi les conversions de PPP sur ATM vers PPPoE et des équipements clients PPPoA alors déployés qui ne savaient pas prendre en charge 1492 octets. Ce constat appartient au contexte de 2006. Il ne constitue ni un recensement actuel, ni une propriété de toutes les implémentations PPPoA.

Un budget dont les postes ne disparaissent pas

Le calcul vient du RFC 2516, daté de février 1999. Sur une charge utile Ethernet maximale de 1500 octets, PPPoE prélève six octets d’en-tête ; l’identifiant de protocole PPP en occupe deux autres. Il reste 1492 octets pour la charge PPP.

Le mot « charge » est décisif. Les 1500 octets ne désignent pas toute la trame sur le fil, avec en-tête Ethernet, contrôle de trame, préambule ou éventuels éléments supplémentaires. Comparer ce chiffre à une taille totale affichée ailleurs revient à changer de comptabilité au milieu du raisonnement.

Pour porter une charge PPP de 1500 octets avec ces six plus deux octets, Ethernet doit donc accepter une charge de 1508 octets. Le RFC 4638 s’appuie sur des systèmes capables de transporter des charges plus grandes, souvent décrites comme des petites trames géantes ou des trames jumbo. Il ne rend pas l’encapsulation gratuite.

Ce résultat arithmétique n’est pas une recette universelle de configuration. Il ne dit pas quel nombre inscrire dans toutes les interfaces de tous les constructeurs, notamment lorsque la manière de compter les champs diffère. La capacité pertinente doit être vérifiée dans le même périmètre que le besoin.

L’autre encapsulation avait elle aussi une borne. Le RFC 2364, de juillet 1998, impose que le MRU de PPP sur AAL5 ne dépasse pas la taille maximale de CPCS-SDU prévue par le contrat de trafic de la connexion virtuelle dans la direction concernée. Passer d’ATM à Ethernet ne consiste donc pas à remplacer une liberté absolue par une contrainte : on change de contrainte inférieure.

Trouver un partenaire n’est pas tester sa route

PPPoE sépare une phase de découverte d’une phase de session PPP. Le client diffuse PADI ; un concentrateur répond par PADO. Après sélection, PADR demande la session et PADS la confirme. Les adresses Ethernet et l’identifiant de session permettent de rattacher la suite des échanges aux participants concernés.

Ce succès établit un contexte de communication. Il ne signifie pas que toutes les étapes PPP, l’authentification éventuelle ou la configuration réseau sont terminées. Il ne prouve pas davantage que des messages sensiblement plus grands traverseront le même réseau.

L’extension utilise cette découverte pour introduire une déclaration explicite. Le client qui veut dépasser 1492 octets doit insérer PPP-Max-Payload dans PADI et dans PADR. Un serveur capable de prendre en charge l’extension et recevant ce marqueur doit le renvoyer dans PADO et PADS.

Le type du marqueur est 0x0120, soit 288 en décimal. Sa valeur binaire tient sur deux octets et indique la charge PPP maximale que le client prend en charge aussi bien à l’émission qu’à la réception. Le nombre 288 identifie le champ ; ce n’est pas une taille de paquet annoncée. Les deux octets de valeur appartiennent à la découverte, pas à un nouvel impôt prélevé sur chaque paquet de session.

L’échange évite une ambiguïté de compatibilité. Un ancien équipement peut ignorer un type de marqueur inconnu. Le silence ne doit donc pas être interprété comme l’acceptation d’un plafond supérieur. Sans indication de prise en charge des deux côtés pendant la découverte, la limite demeure 1492.

Le serveur répète une offre, puis applique ses limites

Le retour du marqueur n’est pas encore le résultat final. Le serveur renvoie celui du client ; il ne le remplace pas systématiquement, à ce stade, par sa propre taille maximale. Les restrictions locales interviennent dans la négociation PPP qui suit.

Le RFC 4638 part d’un plafond de 1492. Si le marqueur existe et propose davantage, le plafond utilisable pour la négociation devient le plus petit de deux nombres : la valeur annoncée et le MTU de l’interface moins huit octets. LCP peut alors négocier selon les règles ordinaires de PPP.

La distinction entre plafond et choix apparaît dans un cas révélateur. Même si PPP-Max-Payload annonce plus de 1500, l’absence de négociation d’un MRU supérieur laisse subsister le défaut ordinaire de PPP, 1500, lorsque les conditions de l’extension sont réunies. Un champ généreux n’ordonne pas à lui seul une taille généreuse. Cela n’autorise évidemment pas à employer 1500 sur une session restée au régime traditionnel de 1492.

Le RFC 1661, de juillet 1994, définit le MRU comme la taille maximale de la partie Information et du bourrage que le récepteur peut accepter. Le champ de protocole et l’encadrement n’en font pas partie. Ce paramètre exprime une capacité de réception ou une demande de paquets plus petits ; il n’oblige pas l’autre extrémité à remplir chaque paquet jusqu’au plafond.

Une lecture correcte conserve ainsi trois nombres possibles : la capacité déclarée pendant la découverte, la borne autorisée par l’interface et la valeur effectivement retenue par LCP. Les fusionner en un unique « MTU négocié » commode fait perdre la raison d’être de l’extension.

Les ponts intermédiaires n’ont rien promis

Les extrémités peuvent se comprendre parfaitement tout en étant reliées par un segment incapable de porter leurs plus gros paquets. Les petits messages de découverte et de contrôle ne forcent pas un pont Ethernet à révéler cette limite.

Le RFC 4638 prévoit donc une possibilité de vérification après ouverture de la session et négociation d’un MRU supérieur à 1492. L’émetteur devrait pouvoir envoyer une ou plusieurs requêtes LCP Echo de la taille du MRU. En l’absence de réponse, il peut recommencer avec des requêtes de 1492 octets. Si celles-ci reçoivent des réponses, il ne doit plus envoyer au-delà de 1492 pour cette session.

La formulation ne prescrit pas une campagne identique partout. Cette fonction devrait être activée par défaut, rester configurable et pouvoir être désactivée lorsque la connaissance du réseau le justifie. Le texte ne fournit ni nombre universel de tentatives ni temporisation obligatoire à inventer après coup.

La comparaison produit un signal utile sans localiser automatiquement la panne. Un petit échange réussi ne démontre pas le passage d’un grand paquet. Deux tailles silencieuses ne démontrent même pas le bon fonctionnement de la petite. L’observation doit rester attachée à sa direction, à sa session et aux dimensions réellement émises.

LCP Echo appartient à l’état Opened selon le RFC 1661. La réponse reprend l’Identifier approprié, mais cela n’autorise pas à affirmer que toute réponse a nécessairement la même taille que la requête. Un aller-retour réussi n’est donc pas une certification permanente de capacité maximale symétrique.

Deux problèmes de chemin, deux périmètres

Le plafond PPPoE ne résume pas le trajet d’un paquet jusqu’à sa destination sur Internet. Le RFC 1191, publié en novembre 1990, traite un autre problème : la découverte du MTU d’un chemin IPv4.

Une source utilise le bit interdisant la fragmentation et ajuste son estimation à partir des messages ICMP signalant qu’un routeur ne peut transmettre sans fragmenter. Le routeur concerné abandonne alors le paquet et signale la difficulté. Un paquet trop grand n’est donc pas, dans tous les cas, simplement découpé et livré.

Le test prévu pour PPPoE concerne la liaison ou la session et ses segments Ethernet intermédiaires. Il ne remplace pas ce travail sur le chemin Internet. Confondre les deux rendrait une réussite locale beaucoup plus ambitieuse que l’expérience effectivement réalisée.

Un registre n’agrandit pas un réseau

Le RFC 4638 est un document informatif, non un Internet Standard. Sa note IESG appelle à la prudence dans le contexte normatif de 2006 concernant les charges Ethernet supérieures à 1500. Cette remarque datée ne doit pas devenir une affirmation sur les normes de 2026.

En juin 2007, le RFC 4937 organise le registre IANA des types de marqueurs PPPoE et y inscrit 288 pour PPP-Max-Payload. Le registre IANA capturé conserve cette association. Il permet aux implémentations de donner le même sens au code, pas de connaître l’état d’une liaison particulière.

La chronologie empêche un récit trop lisse : l’encapsulation de 1999, l’extension de 2006 et la formalisation du registre en 2007 répondent à des besoins distincts. Ni l’allocation d’un numéro ni la publication d’un texte n’ont rétroactivement équipé les ponts intermédiaires.

La migration avait déplacé la frontière. La réponse du protocole fut de rendre explicites l’autorisation de négocier, la contrainte locale et le repli observé. Le coût de huit octets restait physique ; sa gestion devenait mieux distribuée.