Résumé

  • RFC 1226 place une trame AX.25 dans un datagramme IP, retire les fanions HDLC et le bourrage par zéros, conserve le FCS CRC-CCITT de 16 bits et utilise le protocole IP 93.
  • Le datagramme fournit ses propres limites ; le contenu encapsulé préserve donc une représentation choisie de la trame, non la totalité de son passage éventuel sur une liaison radio.
  • Observer le protocole 93 établit au mieux la présence de certains octets à un point IP, pas l'émission RF, l'identité d'une station, le réassemblage, la livraison ni une action.

Le nouveau contenant remplace l'ancienne ponctuation

Publié en mai 1991, RFC 1226 propose une méthode expérimentale pour transporter dans IP des trames AX.25, le protocole de liaison de la radio par paquets amateur. La fiche du RFC Editor le classe aujourd'hui dans le flux historique Legacy. Le Datatracker précise qu'il n'a ni approbation de l'IETF ni statut formel dans son processus de normalisation. Ce texte décrit un format, pas son adoption.

Sa règle paraît simple : une trame AX.25 par datagramme IP. Mais le transfert n'est pas une copie bit à bit de ce qu'une interface HDLC aurait envoyé. Les fanions délimitent une trame sur la liaison série ; le bourrage par zéros empêche le motif réservé d'apparaître au milieu des données. RFC 1226 les enlève tous deux, parce que la longueur et les limites du datagramme IP rendent cette ponctuation redondante.

En revanche, la séquence de contrôle CRC-CCITT de 16 bits est incluse. Le reste de la trame AX.25 est annoncé comme inchangé. La frontière est donc explicite : les mécanismes de cadrage du support disparaissent, la valeur de contrôle subsiste, et les autres octets de la trame passent dans la nouvelle enveloppe.

Cette frontière empêche une conclusion trop large. Une capture IP peut montrer un objet conforme à cette représentation. Elle ne montre pas les fanions ou les zéros retirés. Elle ne révèle pas si une antenne a rayonné, si un récepteur a capté un signal, si un modem a validé une trame, ni quel équipement a produit le FCS conservé.

Le contrôle d'erreur n'est pas le journal de son origine

Parce qu'il est associé au matériel HDLC, le FCS peut sembler être la trace physique qui aurait survécu au tunnel. Or RFC 1226 ne lui donne pas cette autorité. La valeur peut provenir d'une réception, avoir été calculée avant une émission future, être recalculée en logiciel ou avoir été copiée avec le reste des octets. Sa présence autorise une comparaison bornée ; elle ne raconte pas sa provenance.

Même une séquence correcte n'identifie pas un radioamateur, n'établit pas une licence, n'authentifie pas un point terminal et ne prouve pas que le contenu décrit un fait réel. Le RFC indique d'ailleurs que les questions de sécurité ne sont pas traitées. L'identité, l'autorisation, la protection contre la répétition et la confiance doivent venir d'autres registres.

Le numéro de protocole remplit une fonction tout aussi limitée. Le registre IANA des numéros de protocole associe toujours la valeur décimale 93 aux trames AX.25 et rappelle que le champ Protocol d'IPv4 désigne le protocole de niveau suivant. Un numéro commun permet au destinataire de choisir un traitement. Il ne valide ni les octets, ni l'auteur, ni le trajet annoncé.

Une unité à l'entrée peut devenir plusieurs observations

RFC 1226 estime qu'une trame AX.25 ne dépasse normalement pas 330 octets. Dans ce cas, la fragmentation IP ne devrait pas être nécessaire. Le texte prévoit pourtant des essais avec des trames plus grandes et renvoie alors aux procédures ordinaires de fragmentation et de réassemblage.

RFC 791 situe cette opération dans IP : un datagramme trop grand pour un réseau du trajet peut être fragmenté, puis réassemblé à destination. RFC 1122 exige des hôtes Internet qu'ils prennent en charge le réassemblage. Il peut donc exister une trame par datagramme au point d'encapsulation, plusieurs fragments sur le chemin et aucun datagramme complet au point d'arrivée.

La formule « une trame, un datagramme » décrit la construction initiale. Pour affirmer que l'unité a été retrouvée, il faut le résultat du réassemblage. Pour affirmer qu'elle a été remise à AX.25, il faut le journal du décapsuleur. Pour affirmer un effet opérationnel, il faut encore une observation distincte.

L'histoire fiable garde la carte des couches

HDLC délimitait la transmission série. L'encapsuleur décidait quels éléments retirer et quels octets conserver. IPv4 portait, classait, routait et pouvait fragmenter. L'hôte destinataire réassemblait. Le consommateur interprétait ensuite la trame reconstruite. Chaque étape possède sa propre autorité et ses propres absences.

Le mot « inchangé » de RFC 1226 n'efface pas cette architecture : il vaut après deux exclusions nommées. Conserver ces exceptions est essentiel. Sans elles, un paquet de tunnel finit par être présenté comme la reproduction d'un événement radio, alors que le format n'a jamais été conçu pour certifier cet événement.

Sources