Les familles de protocoles TCP/IP fonctionnent sur une grande variété de supports : les réseaux locaux IEEE 802.3 (Ethernet) et 802.5 (Token Ring), les lignes X25, les liaisons satellites et série. La plupart des transmissions de données se font via des interfaces séries. Une interface série est juste une interface qui envoie les données comme une série de bits sur un "seul fil" en opposition à une interface parallèle qui envoie cette série de bits sur "plusieurs fils" simultanément. Cette description d'une interface série convient pour la plupart des interfaces de communications (y compris Ethernet), mais ce terme désigne habituellement une interface qui est liée à une ligne téléphonique au travers d'un modem.
Dans le monde TCP/IP , les liaisons séries sont utilisées pour créer des WAN (Réseaux longue distance). Malheureusement, un protocole standard au niveau de la couche physique pour les lignes séries n'a pas toujours existé concernant cette famille de protocoles TCP/IP. En raison de cette carence, beaucoup de responsables informatiques ont choisi une même marque de routeurs pour leur WAN afin d'assurer la communication au niveau de la couche physique.
La croissance des réseaux longue distance avec TCP/IP a ensuite suscité un vif intérêt pour la standardisation des communications sur liaisons séries afin d'être indépendant de tout fournisseur. De même, l'arrivée de petits systèmes abordables fonctionnant avec TCP/IP ainsi que des modems à haute vitesse ont appuyé cette demande.
Le besoin d'une standardisation pour les communications dans les WAN et celui d'accès TCP/IP par le RTC , ont abouti à la création de deux protocoles de transmission sur ligne série : Serial Line IP et Point-to-Point Protocol (PPP).
A. Généralités
Bien plus qu’un standard d’encapsulation de datagramme, les liaisons PPP résolvent certains problèmes des protocoles réseaux, tel qu’assigner et gérer des adresses (IP, X.25 et autres..) qui est particulièrement difficile à travers un réseau commuté.
Parallèlement, PPP permet l’encapsulation de trames asynchrone et synchrone orienté bit, de configurer la liaison série, de tester la qualité de la liaison, de multiplexer les différentes couches réseau, détecter les erreurs, et de ‘’ négocier ‘’ les options avec le site distant, tel que la compression de donnée, la vitesse de transfert...
PPP résout tout cela à travers un protocole de contrôle de liaison (LCP) et une famille de protocoles de contrôle de réseaux pour ‘’négocier’’ les paramètres optionnels de la configuration.
PPP est composé de trois parties principales :
1 - Une méthode pour encapsuler les datagrammes sur la liaison série. PPP utilise le format de trame HDLC ( Hight Data Level Control ) de l’ISO ( International Standartization Organisation ).
2 - Un protocole de contrôle de liaison (LCP - Link Control Protocol ) pour établir, configurer et tester la connexion de liaison de données.
3 - Plusieurs protocoles de contrôle de réseaux (NCPs - Network Control Protocol ) pour établir configurer les différents protocoles de couche réseau.
PPP est recommandé pour l'utilisation simultanée de plusieurs protocoles de couche réseau. En effet, sa structure permet d’utiliser différents NCP simultanément et donc de multiplexer simultanément différents protocoles de couche réseau.
"Liaison morte"
Toute liaison commence et finit obligatoirement par cette phase. Lorsqu'un événement externe indique que la couche Physique est prête, PPP passe à la phase suivante, établissement de la liaison.
Par exemple, une liaison retournera à cette phase après la déconnexion d'un modem.
"Etablissement de la liaison"
Le protocole de contrôle de données (LCP) est utilisé pour établir la connexion à travers l'échange d’options de configuration jusqu'à ce qu'un des hôtes modifie une des options pendant la phase.
De plus, seules les options qui sont indépendantes de tout type de réseau, telles que l'élimination du champ Fanion de la trame PPP, sont configurées par le LCP (voir annexes pour LCP).
"Authentification"
Il est possible qu'un hôte doive s'authentifier avant tout envoi de messages. Celle-ci n'est pas obligatoire, et doit être demandée dans la phase précédente, établissement de la liaison.
Elle doit se faire le plus rapidement possible après l'établissement de la connexion. Le passage à la phase suivante, Protocole réseau, n'est possible qu'à la fin de l'authentification, en cas d'échec, passage à la phase Terminaison de liaison.
"Protocole réseau"
Une fois les phases précédentes effectuées par PPP, chaque protocole réseau doit être configuré séparément par le protocole de contrôle de réseau (NCP) approprié. En effet, PPP supporte plusieurs protocoles sur la même liaison de données.
Le transfert de données est alors possible. Tant que la liaison est "ouverte", les NCPs (voir annexes pour explication) peuvent ouvrir et fermer des connexions réseau.
"Terminaison de liaison"
PPP peut clore une liaison à tout moment, ceci peut être dû à une authentification qui a échoué, une mauvaise qualité de la ligne...
Le LCP est utilisé pour la fermeture de la connexion à travers l'échange de paquets de terminaison.
Lorsque la liaison est close, PPP doit alors en informer les NCPs.
B. Le protocole de contrôle de liaison (LCP)
PPP utilise le LCP pour négocier une importante liste d'options de configuration dans une large variété d'environnements. Ainsi, il est possible d'utiliser PPP entre des hôtes que les administrateurs réseau ont configuré différemment. LCP négociera automatiquement les options de configuration.
Le protocole de contrôle de liaison de donnée (LCP - Link Control Protocol) fournit les informations concernant la liaison série. Il est utilisé pour établir, négocier les paramètres de configuration, vérifier la qualité de liaison et terminer une connexion point à point. LCP a été développé spécifiquement pour PPP.
LCP fonctionne à travers 4 phases distinctes :
Phase 1 : Etablissement et configuration de la liaison
Avant que les datagrammes de la couche réseau soit échangés, LCP doit d’abord confirmer l’ouverture de la connexion par envoi et réception de paquets. Ces paquets sont émis par chacun des deux sites. Si ces échanges sont effectués sans aucun problème - réception de l’acquittement de configuration (Configure-Ack) - LCP accepte la connexion, sinon celle-ci est refusée.
Il est important de noter que LCP accepte la configuration de la liaison et non celle de la couche réseau - effectuée par le protocole NCP . En effet, tous les paramètres indépendants de la couche réseau sont configurés et testés à travers LCP. En cas d’erreur ou de mésentente sur les options, celles-ci prennent une valeur par défaut.
Phase 2 : Détermination de la qualité de la liaison
Cette phase n’est pas obligatoire. Dans cette phase la liaison est testée afin de déterminer si la qualité - débit par exemple - est suffisante pour assurer le transport des datagrammes de la couche réseau correspondante. LCP peut retarder la transmission des paquets tant que cette phase n'est pas complètement terminée.
La procédure pour déterminer la qualité n’est pas spécifiée et peut varier d’une implémentation à l’autre, de plus elle dépend des souhaits de l’utilisateur. Une méthode est d’utiliser les paquets LCP Echo-Request et Echo-Reply. Cette phase n’étant pas obligatoire, il est nécessaire de fixer un temps maximum afin de ne pas bloquer la connexion.
Phase 3 : Négociation de la configuration du protocole de la couche réseau
Une fois que LCP a terminé les deux phases précédentes, le protocole de couche réseau est configuré séparément par le protocole de contrôle de réseau approprié (NCPs), et peut être interrompu à n’importe quel moment. Si LCP interrompt la connexion, il informe NCP qui pourra effectuer des actions appropriées.
Phase 4 : Fin de la liaison
LCP peut interrompre la liaison à n’importe quel moment, sur un temps de réponse trop élevé, un événement physique, par exemple, ou bien tout simplement par l’utilisateur.
Informations complémentaires sur LCP
Format des paquets
Les paquets LCP sont encapsulés dans le champs information de la trame PPP ou le champs Protocole de la trame a pour valeur le type indiquant des datagrammes LCP c’est à dire la valeur C021.
Il existe trois classes distinctes de paquets LCP :
1. Les paquets de configuration de liaison, utilisées pour établir la connexion.
2. Les paquets de terminaison de liaison, utilisées pour clore une connexion.
3. Les paquets de maintenance de liaison, utilisées pour maintenir et résoudre certains problèmes sur la ligne.
Le champs Code est sur un octet et identifie le type du paquet LCP.
Les différentes valeur de ce champs :
1 - Configure-Request
2 - Configure-Ack
3 - Configure-Nack
4 - Configure-Reject
5 - Terminate-Request
6 - Terminate-Ack
7 - Code-Reject
8 - Protocol-Reject
9 - Echo-Request
10 - Echo-Reply
11 - Discard-Request
Le champs Identifiant est sur un octet. Son rôle est de faciliter la reconnaissance des réponse associer à la requête correspondante.
Le champs Longueur est sur deux octets . Son rôle est indiquer la longueur du paquet LCP correspond en fait à la longueur du champs information de la trame principale PPP (vu précédemment) sans les bits de bourrage.
Le champs Data contient les données demandées par les différentes requêtes. Sa taille peut être nulle .Son format est déterminé par la valeur du champs Code.
Il contient les différentes Options qui peuvent être négocier en réponse a certain paquet tel que Configure-Request ,Echo-Request,Terminate-Request ...
Par exemple, avec le paquet Code-Reject (Code ayant la valeur 7) , Il contient le paquet LCP rejeter.
Les paquets de configuration
Ils servent à établir et configurer la liaison PPP. Ils sont au nombre de quatre : Configure-Request, Configure-Ack, Configure-Nak, et Configure-Reject.
Pour ouvrir une connexion PPP, un paquet Configure-Request doit être envoyé. Le champ Data contient une liste des options de configuration désirées.
Lorsqu'un hôte reçoit le paquet, il doit obligatoirement émettre une réponse. Si toutes les options sont acceptées, le récepteur envoie un acquittement, paquet Configure-Ack. Le champ Data contient alors une copie exacte des options de configuration demandées.
En revanche, si certaines des options désirées ne sont pas acceptables, le récepteur envoie un acquittement négatif, paquet Configure-Nak. Le champ Data contient uniquement les options inacceptables.
En somme, l'hôte qui reçoit un Configure-Request peut demander des options supplémentaires quand il envoie le Configure-Nak.
Les hôtes continuent d'envoyer des Configure-Request et Configure-Nak jusqu'à ce qu'ils se mettent d'accord sur les mêmes options.
Si un hôte reçoit un paquet qui contient des options inconnues, il doit envoyer un Configure-Reject, dont le champ Data contiendra uniquement les options rejetées.
La différence entre les options des paquets Configure-Nak et Configure-Reject, c'est que les options rejetées ne sont pas négociables.
Les options de configuration seront étudiés ultérieurement.
Les paquets de terminaison
Pour négocier la fermeture d'une liaison PPP, il existe deux paquets :
Terminate-Request, et Terminate-Ack, dont le champ Data est inutilisé.
Dès qu'un hôte reçoit un Terminate-Request, il doit envoyer un Terminate-Ack.
Des paquets Terminate-Request doivent être transmis tant qu'un des trois événements suivants ne s'est pas produit :
- l'émetteur reçoit un Terminate-Ack,
- la couche inférieure n'est plus prête pour communiquer,
- l'émetteur a envoyé un certain nombre de Terminate-Request non acquittés.
Les paquets de maintenance
Ils servent à maintenir et résoudre certains problèmes sur la liaison. Il en existe cinq : Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, Discard-Request.
Quand un hôte reçoit un paquet LCP avec une valeur inconnue dans le champ Code, il doit transmettre un paquet Code-Reject, dont le champ de données Rejected-Packet contient une copie du paquet rejeté, mais uniquement la partie données du champ Information de la trame PPP, pas les entêtes ni le FCS.
De même, un paquet Protocol-Reject est envoyé en réponse à une valeur inconnue dans le champ Protocol, et inclut les champs Rejected-Protocol, qui contient la valeur inconnue du protocole, et Rejected-Information (similaire au Rejected-Packet du paquet Code-Reject).
Les paquets Echo-Request et Echo-Reply sont utilisés pour surveiller la liaison de données PPP, dans les deux sens. Quand un hôte reçoit un Echo-Request, il doit transmettre un paquet Echo-Reply.
Le paquet Discard-Request sert à surveiller la liaison dans un sens seulement (hôte local vers hôte distant).
Dans ces trois paquets, la zone de données contient un champ Magic Number, option LCP négociable, qui sert à détecter les cycles dans les liaisons de données.
Les options de configuration de LCP
Les options de configurations LCP identifient les caractéristiques négociables de la liaison point à point . Chaque option a une valeur par défaut.
PPP utilise la valeur par défaut quand un paquet Configure-Request n’inclut pas d’option durant la phase d’établissement de liaison.
Dans une trame Configure-Request , on peut envoyer plusieurs options à négocier avec le site distant . Les options n’étant pas inclus dans cette trame, ne sont pas négociées et leur valeur par défaut leur sont affectées.
Format général d’une option
Le champs Longueur indique la taille totale de l’option de configuration. Les champs Type, Longueur et Data étant inclus.
Le format et le contenu du champs Data est spécifique à chaque option de configuration.
Le champs Type identifie le type de l’option de configuration à négocier .
Les Différentes valeur de ce champs sont :
0 - Réservé
1 - Maximum Receive Unit
3 - authentication Protocol
4 - Quality Protocol
5 - Magic Number
7 - Protocol Field Compression
Maximum Receive Unit (MRU)
Cette option permet de négocier la taille maximum d’un paquet .Sa valeur par défaut est de 1500 octets.
Les sites distant peuvent négocier des tailles plus grandes ou plus petites que la taille par défaut. Il n’est pas nécessaire que les serveurs ajoutent des octets de bourrages pour atteindre la valeur du MRU, ils peuvent toujours envoyer des paquets de longueur inférieur.
Le champs Longueur a toujours pour valeur 4.
Le champs MRU indique le nombre maximum d’octet du champs Information de la trame PPP. La taille du MRU n’inclut donc pas les autres champs de la trame PPP.
Authentication Protocol
Les clients peuvent utiliser cette option pour négocier l’utilisation d’un protocole d’authentification particulier, car certains réseaux incluent des protocoles d’authentification au niveau réseau.
Par défaut , celle-ci n’est pas nécessaire . Quand un hôte émet un paquet Configure-Request avec l’option Authentication Protocol, il veut que le récepteur "s'authentifie". Quand le récepteur envoie la réponse Configure-Ack avec l'option Authentication Protocol, il accepte l'authentification, en utilisant le protocole d'authentification spécifié.
Ces hôtes peuvent ne pas utiliser les mêmes protocoles d'authentification dans les deux sens. Ils peuvent négocier l'utilisation de protocoles différents pour chaque sens.
Le format de cette option est similaire a l'option précédente. A la place du champs MRU, cette option inclut les champs Authentication Protocol, et Data qui peut contenir des informations supplémentaires sur le protocole d’authentification demandé.
Quality Protocol
PPP fournit la possibilité de contrôler la qualité de la liaison . Cette option permet aux hôtes de négocier l'utilisation d'un protocole spécifique qui sert à contrôler la quantité de données perdues sur la liaison.
De même que pour l'option précédente, les hôtes peuvent négocier l'utilisation de différents protocoles de qualité dans chaque sens. L'option inclut aussi un champs Data qui peut contenir des informations supplémentaire sur le protocole de qualité demandé.
Magic Number
Elle est utilisée pour détecter les éventuelles anomalies sur la liaison de données et les cycles de rebouclage. Par défaut, cette option n'est pas négociée. A la place, un 0 est inséré dans le champ Magic Number.
Quand un hôte reçoit un paquet Configure-Request avec l'option Magic Number, il le compare au Magic Number du dernier paquet Configure-Request. Si les deux nombres diffèrent, il n'y a pas de rebouclage. Sinon il est possible qu'il y ait un rebouclage : l'hôte reçoit ses propres transmissions. Donc, pour lever le doute, un paquet Configure-Nak doit être envoyé indiquant qu'il faut un autre Magic Number.
Si le Magic Number du Configure-Nak est différent de celui envoyé dans le dernier Configure-Nak, il n'y a pas de cycle, et ce nombre est bien unique. Sinon il y a bien bouclage, et un nouveau Magic Number doit être déterminé.
Toutes les mises en oeuvre de PPP peuvent détecter les cycles. Cependant, le procédé que chaque application utilise pour y remédier est spécifique à chacune.
Protocol Field Compression
Dans certains cas, les deux octets du champ Protocol peuvent être compressés et réduits à un octet. Cette option permet aux hôtes de négocier la compression du champ Protocol de la trame PPP.
Quand un hôte envoie un paquet Configure-Request avec l'option Protocol Field Compression et reçoit un paquet Configure-Ack en réponse, les deux hôtes peuvent utiliser un octet pour le champ Protocol.
Dans tous les cas, les applications PPP doivent toujours accepter le champ Protocol avec deux octets, même si l'option a été négociée. Le FCS est alors calculé sur la trame compressée.
Address and Control Field Compression.
Puisque dans une trame PPP, les champs Address et Control ont des valeurs constantes, ils peuvent être compressés. Cette option permet à un hôte de négocier la compression de ces deux champs.
Le FCS est alors calculé sur la trame compressée.
Les protocoles de controle réseau (NCPs)
Les protocoles de contrôle réseau (NCPs - Network Control Protocols) sont des protocoles séparés qui fournissent les informations de configuration et de contrôle destinées aux protocoles de la couche réseau. PPP est conçu pour transmettre des données pour une multitude de protocoles réseau. NCP autorise la personnalisation de PPP de manière à exécuter uniquement cette tache. Chaque protocole de réseau (DECnet, IP, OSI, etc. ...) possède son propre protocole NCP.
Description
Le protocole de contrôle pour le protocole Internet (IPCP - IP Control Protocol ) se charge de configurer, d’autoriser ou non l’utilisation de datagramme IP (Internet Protocol ) sur la liaison point à point . Semblable au protocole LCP, cette phase s’effectue en échangeant des paquets. Les paquets IPCP ne seront échangés seulement si le protocole LCP autorise la phase de négociation de configuration de la couche réseau. De même, les datagrammes IP ne seront pas échangés tant que IPCP n’accepte pas la connexion.
Fonctionnement de IPCP
Le protocole IPCP est très semblable au protocole LCP, à quelques exceptions près :
- Le Paquet IP est encapsulé dans le champ Information de la trame de couche de liaison de donnée ou le champ protocole a la valeur hexadécimale 8021.
- Le champ Code utilise seulement un code parmi les sept disponible (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack et Code-Reject). Les autres codes sont traités comme des paquets inconnus et sont retournés au site distant - Paquet Code-Reject.
La longueur maximum d'un paquet IP transmis sur une liaison PPP est la même que la longueur maximum du champ Information de la trame PPP. Les datagrammes de longueur plus importante devront être fragmentés. Le rassemblement des datagrammes devra être assuré par la couche transport du système. Il est possible de limiter la longueur de la trame IP à l'aide l'option Maximum Segment Size de la couche TCP, Cette option favorisera la transmission puisque le rassemblement des paquets n'est plus nécessaire.
Les adresses IP
Une option de configuration permet de négocier l'adressage IP de chaque site. Par défaut aucune adresse n'est assignée. Une adresse désignée par la valeur zéro peut être négociée comme une requête du site distant pour que celui-ci spécifie son adresse IP.
Type de compression
Cette option fournit un moyen de négocier le protocole de compression des paquets IP. Par défaut, cette option n'est pas activée.
Le champ Type de compression contient une valeur correspondant à l'algorithme de compression à utiliser. Pour la compression des entêtes TCP/IP de Van-Jacobson cette valeur correspond à 0037 en hexadécimal.
Informations complémentaires sur NCP
PAP -Password Authentication Protocol
Le protocole d'authentification par mot de passe (PAP) est une méthode simple pour établir l'identité du site distant. Elle est semblable à la procédure login d'une session sur un serveur. Ceci est effectué seulement après que la liaison ait été établie.
Après que le protocole LCP , ait accepté la liaison au site distant. Le client s'authentifie auprès du serveur en lui envoyant un paquet Authentication-Request contenant l'identité du client et le mot de passe associé. Le serveur compare ces données à celle contenu dans son fichier d'authentification.
L'inconvénient de cette technique est que le mot de passe transit "en clair" sur la liaison.
Exemple de fichier sur un site de type UNIX :
# /etc/ppp/pap-secrets
#
# User Server Secret Adresse
Vlager-pap c3po cresspahl vlager.vbrev.com
c3po vlager DonaldGNU c3po.lucas.com
Les deux premiers champs contiennent toujours l'adresse de l'utilisateur et du serveur associé. Le troisième champs correspond au secret - Mot de passe - associe de façon unique à un utilisateur ou à un groupe d'utilisateur. La première ligne est utilisé pour authentifie le serveur contenant ce fichier auprès du serveur c3po. La seconde ligne décrit comment un utilisateur distant nomme c3po sera authentifié avec ce serveur. Le quatrième est optionnelle , il contient l'adresse IP du client.
CHAP - Challenge-Handshake Authentification Protocole
Si on veut éviter l'envoi de paquets contenant le mot de passe sur la liaison point à point, l'utilisation du protocole d'authentification CHAP est plus que recommandé. Celui-ci permet ainsi d'accroître la sécurité du site.
Avec ce protocole le serveur envoi au client un paquet contenant un challenge - mot de 16 bits définit aléatoirement - et son nom. Le client récupère dans sa table définit localement, à l'aide du nom du serveur, le secret correspondant. Le client combine le secret approprié avec le challenge, crypte ce résultat. Le résultat du cryptage est retourné au serveur avec le nom du client. Le serveur effectue les même opérations. Si les deux résultats sont identiques la connexion du client est accepté.
Exemple de fichier sur un site de type UNIX :
Le format de fichier contenant les mot de passe pour le protocole CHAP est semblable a pap-secret vu-cidessus.
# /etc/ppp/chap-secrets
#
CHAP permet d'effectuer l'authentification a n'importe quelle moment durant la liaison afin d'être sur que le client n'a pas était remplacé par un intrus.
L'implémentation des algorithmes de cryptage doit bien sur être identique sur les deux serveurs distant . Il est possible a l'aide des options de configuration de LCP de choisir des algorithme spécifique paquet - Authentication Protocol .
Remarque: Les datagrammes transmis après la procédure d'authentification ne sont pas cryptés . Il est donc possible par écoute de la ligne de voir ces données . La sécurité n'est donc , sur une liaison point à point, pas totale .
Si on désire crypter les données à transmettre, le cryptage s'effectue au niveau des datagrammes et doit être assurer par la couche réseau.
L'authentification du site distant
Par soucis de sécurité, afin de permettre un accès privilégié à des données " sensibles" ou à des services payants , il est nécessaire de connaître l'identité du site distant.
Le protocole PPP contient deux protocoles d’authentification, PAP et CHAP, qui sont négociés à l’aide du protocole de couche liaison LCP. L’authentification auprès d’un site est, bien sûr, optionnelle.
L'authentification est effectuée, après que LCP a terminé la configuration des options. En cas d'échec - l'identité du site distant non reconnue - la connexion est tout simplement interrompue.
L'authentification est demandée, soit par le demandeur de connexion (client), soit par l'offreur de connexion (serveur).
Les détails sur l’authentification se trouvent dans les annexes.
Remarque sur PPP
PPP s'avère un protocole nettement plus puissant que SLIP. Les options de configurations étant nombreuses, sa mise en œuvre est plus délicate ; Il est moins souvent utilisé. Cependant les avantages résultant de l'utilisation de PPP en font le protocole de ligne série de l'avenir et le choix probable des distributeurs de routeurs à la recherche d'un mécanisme standard de transmission sur des lignes série.
Conclusion
Nombre d'administrateurs réseau débattent du choix du meilleur protocole série. En réalité, l'utilisation du "meilleur protocole" ne constitue pas toujours le choix correct ; il s'agirait plutôt de sélectionner le "protocole approprié" à une situation particulière.
PPP constitue un meilleur choix puisqu'il permet le transport de datagrammes de nombreux protocoles de couche réseau. Par conséquent, il assure l'interopérabilité entre les systèmes commercialisés par une large palette de distributeurs. De plus, PPP possède plus d'options et est plus puissant que le protocole SLIP. Compte tenu de ces éléments PPP constitue le choix approprié comme protocole non-propriétaire pour assurer la connexion des routeurs sur les lignes série. Etant donné que SLIP a été le premier protocole série IP largement répandu, il est par conséquent disponible pour un plus grand nombre de types de matériel que PPP.
L'accès commuté constitue l'une des applications les plus utilisées pour IP sur les lignes série. Le protocole SLIP est plus souvent utilisé à cette fin que le protocole PPP, puisque nombre de système qui proposent l'accès commuté supportent uniquement SLIP. SLIP est disponible pour la plupart des serveurs et dans majorité des mises en œuvre PC de TCP/IP.
SLIP et PPP ne peuvent échanger des informations, il s'agit de protocole complètement différent. Dés lors, si vos serveurs utilisent uniquement SLIP, les hôtes à distance, interconnectés au travers de ces serveurs doivent aussi utiliser SLIP. Etant donné le nombre de protocoles SLIP, celui-ci sera encore présent de nombreuses années.
