Mon blog

Pendant de nombreuses années, le protocole SLIP a été le plus répandu pour l'accès à l'Internet en dehors du réseau local, par exemple via un modem et le RTC. Même si ce RFC se qualifie modestement de « non-norme », il n'en a pas moins été la seule description officielle de SLIP pendant ces années.

Pourtant, SLIP était bien plus ancien que ce RFC. Il a commencé dans les années 1980, dans la mise en œuvre 3com/Unet de TCP/IP. Le terme de « protocole » est d'ailleurs exagéré pour parler de SLIP : c'est uniquement un format de paquet sur une ligne série. Aucune négociation, aucun mécanisme pour distribuer des informations comme les adresses IP. Mais, en contrepartie, la programmation de SLIP est triviale (il y a même un exemple de code en C à la fin du RFC) et il a donc existé un très grand nombre d'implémentations (aujourd'hui, par exemple, celle du noyau Linux est toujours dans drivers/net/slip*).

C'est en 1984, des années avant ce RFC 1055 que Rick Adams a ajouté SLIP à Berkeley Unix et que ce mécanisme a décollé.

Aujourd'hui, l'époque des modems à 1200 b/s, mentionnés par le RFC, semble bien loin et SLIP n'a plus qu'un intérêt historique. Le RFC accuse nettement son âge, notamment lorsqu'il indique (sans donner d'URL, qui n'existaient pas à l'époque) un serveur FTP anonyme pour récupérer le code (ledit serveur n'existe plus), et qu'il ajoute des instructions sur l'utilisation de shar (une horreur en terme de sécurité, inimaginable aujourd'hui).

Donc, en quoi consistait ce « protocole » ? SLIP définissait deux caractères spéciaux, END (valeur 192) et ESC (valeur 219, rien à voir avec le ESC de ASCII). Le END indique la fin du paquet. Si un vrai caractère END (ou ESC) doit être envoyé, on envoie à la place ESC + 220 (ou ESC + 221). Difficile de faire plus simple. Pour copier le noyau Linux :

#define END             0300		/* indicates end of frame	*/
#define ESC             0333		/* indicates byte stuffing	*/
#define ESC_END         0334		/* ESC ESC_END means END 'data'	*/
#define ESC_ESC         0335		/* ESC ESC_ESC means ESC 'data'	*/
...
	while (len-- > 0) {
		switch (c = *s++) {
		case END:
			*ptr++ = ESC;
			*ptr++ = ESC_END;
			break;
		case ESC:
			*ptr++ = ESC;
			*ptr++ = ESC_ESC;
			break;
		default:
			*ptr++ = c;
			break;
		}
	}
	*ptr++ = END;

Il y a quand même quelques petites subtilités. Par exemple, le RFC recommande d'envoyer également un END avant le paquet, pour vider tous les caractères parasites qui seraient en attente (eh oui, les modems n'étaient pas fiables et tout le monde n'avait pas activé V.42). D'autre part, comme SLIP ne définissait pas de MTU, le RFC recommande de se limiter à 1006 octets, taille historique.

Dès le début, les limites de SLIP étaient bien connues et sont listées dans le RFC :

• Pas de mécanisme d'adressage. À part les adresses IP fixes mises à la main, la solution la plus courante (quoi non citée dans le RFC) était de regarder les paquets IP envoyés et de considérer que l'adresse de destination était l'adresse affectée par l'autre bout.
• Pas de multi-protocoles : dans un paquet SLIP, rien n'indique le protocole de couche 3 utilisé et SLIP n'était donc utilisable que pour IP.
• Pas de détection d'erreur. SLIP comptait entièrement sur la ligne ou bien sur IP (dont la somme de contrôle permet de détecter les paquets corrompus).
• Pas de compression (même si des solutions partielles comme le RFC 1144 sont apparues par la suite).

Bref, SLIP était un vrai protocole Internet : simple, qui marche et qui rend service pendant que les comités sont toujours à discuter d'un protocole meilleur.

Dans le monde Internet, SLIP a été largement remplacé par PPP (qui n'existait pas encore à l'époque du RFC 1055).