Résumé

  • RFC 1055 décrit SLIP comme un encadrement minimal de datagrammes IP sur ligne série : END ferme la trame et ESC évite que deux valeurs de données ne soient prises pour des contrôles.
  • L’END initial suggéré par Phil Karn sacrifie un paquet vide dans le cas normal afin d’écarter, dans le cas bruité, les octets qui auraient pu se greffer à la prochaine trame.
  • Retrouver une frontière, vérifier un contenu et réaligner un décodeur à état sont trois opérations distinctes. Le contraste avec RFC 1144 et RFC 1662 rend cette séparation observable.

Une convention qui annonçait ses limites

RFC 1055 n’essaie pas de faire passer SLIP pour une couche complète. Le texte de 1988 le qualifie de convention de fait pour TCP/IP point à point sur lignes série, et précise qu’il ne s’agit pas d’une norme Internet. Sa formule la plus utile est la plus sèche : SLIP n’est qu’un protocole de cadrage de paquets.

Ce « que » est une information d’architecture. Le document énumère ce que SLIP ne fournit pas : ni adressage, ni identification du type de paquet, ni détection ou correction d’erreur, ni compression. Deux machines doivent disposer autrement de leurs adresses IP. Une même liaison ne peut pas distinguer plusieurs protocoles grâce à un champ de type SLIP. Un flot de bits abîmé ne reçoit pas, du seul fait du cadrage, un jugement d’intégrité.

Cette modestie explique une part de son succès historique. Sur une liaison lente, une règle que les deux extrémités peuvent exécuter localement vaut souvent mieux qu’une promesse vague de tout résoudre. Il faut toutefois lui laisser exactement cette portée. La bonne lecture n’est pas celle d’un PPP incomplet ou d’une sécurité embryonnaire. C’est celle d’un mécanisme qui répond à une question précise : où finit, dans un flux continu, le datagramme que je viens de lire ?

Pour répondre, RFC 1055 réserve deux octets. END, octal 0300 (décimal 192), marque la fin; ESC, octal 0333 (décimal 219), introduit le bourrage. Une donnée égale à END devient ESC suivi de l’octal 0334; une donnée égale à ESC devient ESC suivi de l’octal 0335. Après les données ainsi protégées, l’émetteur envoie END. Le lecteur inverse les deux remplacements avant de livrer la suite d’octets comme datagramme.

Cette règle ne confère aucun statut universel à END. Dans un analyseur SLIP déjà engagé dans la lecture d’une trame, il agit comme frontière. Dans le contenu, la même valeur est protégée afin de rester une donnée. ESC ne commande que les deux substitutions définies. La grammaire ne décide ni de la valeur métier du datagramme, ni de l’identité du correspondant, ni de sa validité cryptographique. Elle empêche une collision entre le séparateur local et le contenu local.

Le petit coût de la première frontière

Le détail qui donne à SLIP sa force analytique est la recommandation de Phil Karn : commencer également chaque paquet par END. RFC 1055 explique que cela « purge » les octets erronés qui ont pu s’accumuler au récepteur à cause du bruit de ligne.

Une ligne saine voit alors deux END consécutifs : le dernier de la trame précédente et le premier de la suivante. Ce n’est pas une erreur cachée; c’est un coût accepté. Le document indique qu’ils produisent un paquet IP vide ou mauvais, que l’implémentation IP rejettera. Le récepteur donné en exemple ignore directement un END lorsqu’il n’a encore recueilli aucune donnée. Un paquet vide devient le prix visible de la prudence.

Après du bruit, le même premier END prend une autre fonction. Il clôt l’accumulation indéterminée avant que les données de la nouvelle trame arrivent. Les octets parasites cessent ainsi d’être candidats au début du prochain datagramme. Le geste ne répare pas ces octets et ne les déclare pas faux au sens physique; il refuse simplement de leur donner une autorité de préfixe dans la trame suivante.

Cette nuance est l’histoire entière. Un délimiteur peut dire « recommence ici » sans pouvoir dire « ce qui suit est intact ». Il peut rétablir la compétence du parseur après une frontière sans savoir si le contenu a subi une altération. Il peut rendre le démarrage de la lecture déterministe sans réconcilier un état mémorisé à une couche supérieure.

Le code de réception de RFC 1055 confirme la prudence. Il ne retourne une trame qu’à la rencontre de END après au moins une donnée; il ignore les paquets vides issus d’END doublés. S’il voit ESC suivi d’une valeur non prévue, il désigne une violation de protocole et conserve l’octet tel quel. Nous ne sommes pas devant une machine de validation générale. Nous sommes devant un lecteur de frontière, avec deux protections minimales de transparence.

Une trame retrouvée n’est pas un état retrouvé

RFC 1144, sur la compression d’en-têtes TCP/IP pour liaisons série lentes, interdit une lecture paresseuse de SLIP. Son schéma traite le paquet IP dans un compresseur, puis le livre à un encadreur. Pour les paquets compressibles, le compresseur conserve des en-têtes précédents associés à des connexions sur la ligne série et transmet des différences.

Le découpage des octets ne restaure donc pas, à lui seul, le contexte qui donne un sens à ces différences. RFC 1144 distingue explicitement la détection d’erreur au niveau du framing de la réaction du décompresseur : ce dernier doit savoir qu’un paquet a été reçu avec erreur pour le jeter et éviter de propager une divergence. END n’est pas cette indication. Il n’a jamais été conçu pour l’être.

Il faut tenir quatre questions séparées : où une trame commence-t-elle ou finit-elle ? Les octets de cette trame sont-ils intacts ? Le décodeur possède-t-il l’état antérieur requis ? L’application peut-elle employer le résultat ? Une frontière répond à la première. Les autres appellent d’autres preuves, d’autres couches, parfois d’autres décisions de rejet.

RFC 1662 permet une comparaison plus tardive sans téléologie. Le cadrage PPP de type HDLC définit une séquence de fanion pour début ou fin, un bourrage d’octets, une FCS et un traitement des trames invalides. Il observe aussi que partager un fanion entre la fin d’une trame et le début de la suivante économise un octet mais peut diminuer la fiabilité après une période inactive : du bruit peut être ajouté à la trame suivante si un nouveau fanion ouvrant n’est pas envoyé. Ici encore, la frontière et l’intégrité sont nommées séparément.

PPP n’est pas la sentence qui rendrait SLIP fautif. C’est un autre contrat, plus large, avec davantage de responsabilités explicites. La leçon de SLIP reste la même : une règle commune peut être utile parce qu’elle est étroite, à condition de ne pas prétendre qu’elle a pris en charge les obligations qu’elle laisse ailleurs.

Faire expirer l’autorité du marqueur

Les Notes 64 et 65 de Heng Lu fournissent une discipline de lecture : partir de la plus petite fonction déterministe que les systèmes exécutent réellement, puis ne pas l’élever en pouvoir général. Dans SLIP, END ordonne seulement de clore ou de réinitialiser la recherche d’une trame. ESC ne modifie que les deux valeurs réservées. Dès que la frontière est reconnue, elle ne peut certifier le contenu qui la suit.

Pour enquêter sur une reprise de flux, il faut donc conserver séparément les octets avant le marqueur, le marqueur observé, la trame reconstituée, le verdict d’intégrité et, s’il existe, l’état utilisé par un décodeur dépendant du passé. Dire simplement qu’un système a « récupéré un paquet » mélange des faits dont chacun peut être vrai ou faux indépendamment.

Sources et limites des preuves

Le dossier de preuve est constitué de RFC 1055, RFC 1144 et RFC 1662. Il établit le rôle de END et ESC, la raison de l’END initial, les limites assumées de SLIP, la séparation compresseur/encadreur et le contraste PPP. Il n’établit ni une adoption universelle de SLIP, ni le comportement d’un équipement contemporain, ni un taux mesuré de bruit, ni un résultat de sécurité.