• Identification ÉMETTEUR et RÉCEPTEUR:

Adresses MAC (48 bits) et adresse IP (32 bits) de l'émetteur et du récepteur.

• ENCAPSULATION dans les TRAMES :

Les messages ARP sont encapsulés dans des trames de niveau inférieur (Ethernet ou SNAP – CF suite). Les trames contenant des requêtes ARP utilisent l’adresse MAC de broadcast comme adresse de destination. Les réponses s’effectuant en unicast classique.

• MAINTENANCE des TABLES d'ADRESSES :

Chaque équipement utilisant ARP maintient une mémoire cache pour enregistrer les résolutions d'adresses.

Comment s'effectue cette maintenance ?

- Ajout d'une entrée à chaque réception d'une réponse ARP.

- Ajout d'une entrée (adresses de l'émetteur) lorsqu'un équipement doit répondre à une requête ARP.

Optimisation de la maintenance :

- Ajout d'une entrée à chaque réception d'une requête ARP (requête diffusée, donc tous les équipements peuvent enregistrer une entrée correspondant aux adresses de l'émetteur de la requête ARP).

- Lors d'un boot, diffusion d'une requête ARP (très pratique en cas d'ajout d'équipement ou de changement de carte MAC)
« ARP gratuit »

- Suppression autoritaire d'une entrée au bout d'un temps fixé.

• AVANTAGES de FONCTIONNEMENT :

A l'EMISSION d'un DATAGRAMME IP :  

C/ IP sur Ethernet

Ce paragraphe décrit en terme d’encapsulation/démultiplexage le cas du standard IP lorsqu’il s’interface sur le standard DIX Ethernet.

• RAPPEL des CARACTERISTIQUES MAC ETHERNET :

- Ethernet est un protocole LAN standard de fait qui permet la gestion du partage, entre plusieurs équipements connectés, d’un canal de communication à topologie logique de bus. Cette gestion du canal s’opère selon le protocole CSMA/CD.

- Pas de couche LLC au sens IEEE : interfaçage avec le protocole de niveau supérieur directement au niveau MAC

encapsulation directe  

- Format de trame ETHERNET :

- Taille maximale des données = 1500 octets. C’est au niveau supérieur que doit s’opérer l’extraction des bits de bourrage

obligation pour les protocoles de niveau supérieur de disposer d’un champ « longueur de PDU » : c’est le cas de IP.

- Le champ No de Protocole permet, en réception, le démultiplexage des données vers le protocole de niveau supérieur concerné.

Exemples de valeurs possibles (> 1500) :

(Extrait IETF RFC 1700) 

 On retiendra donc une possibilité directe d’encapsulation/démultiplexage entre IP (ARP et IPv6) et le standard ETHERNET.

D/ IP sur IEEE LLC / SNAP

Examinons maintenant le cas où IP est utilisé sur des solutions LANs normalisées par l’IEEE (et l’ISO) ainsi que par l’ANSI dans le cas de FDDI.

• RAPPEL du MODELE IEEE :

- Le modèle IEEE s’architecture sur deux sous-couches : l’une assurant la gestion d l’accès au support de communication (MAC) et l’autre assurant un contrôle de la liaison logique (LLC). Pour rappel :

• RAPPEL des CARACTERISTIQUES MAC IEEE 802.3 CSMA/CD :

Nous rappelons ici les caractéristiques de 802.3 CSMA/CD pour insister sur la différence de format de trames existant avec le standard DIX ETHERNET :

- Gestion du partage d’un canal de communication à topologie logique de bus entre plusieurs équipements connectés selon le protocole CSMA/CD.

- Utilisation obligatoire de la couche LLC : pas d’aiguillage vers le protocole de niveau supérieur directement au niveau MAC

encapsulation dans LLC1

- Format de trame IEEE 802.3 : 

- Le champ Longueur Données permet au récepteur MAC d’opérer l’extraction des bits de bourrage (<= 1500)

• RAPPEL des CARACTERISTIQUES LLC IEEE 802.2 : 

- Au niveau de la sous-couche LLC, trois types de service sont définis :

LLC-1 : mode datagramme

LLC-2 : mode connecté

LLC-3 : mode datagramme avec acquittement

- Le service de type LLC1 n’apporte qu’une fonction d’aiguillage (démultiplexage) des données vers le niveau supérieur (aucun contrôle d’erreur n’est effectué).

  utilisé par la grande majorité des protocoles des réseaux locaux (IEEE, FDDI…).

- Format de trame IEEE 802.2 LLC-1 :

- Les champs DSAP (Destination Service Access Point) et SSAP (Source Service Access Point) désignent respectivement les protocoles de niveau supérieur destinataire et émetteur des données transmises.

-Exemples de valeurs de SAP :

+ Le champ contrôle de par sa valeur (0x03) indique la nature de la trame LLC (UI-LLC1)

• POURQUOI IP N’UTILISE PAS DIRECTEMENT LLC ? :

Historiquement, alors que IP et ETHERNET étaient devenus des standards de facto et que l’encapsulation directe du premier sur le second était possible, l’IEEE était encore en phase de normalisation de ses protocoles. Une fois celui-ci terminé, l’IETF a interdit d’utiliser directement IP sur LLC pour deux raisons essentielles :

• la longueur des trames IEEE MAC+LLC n’est pas un multiple de mots de 32 bits. Or, dans IP un effort a été fait pour aligner les informations sur des mots de cette longueur. La non compatibilité des solutions IEEE avec ce principe pose des problèmes d’extraction des données en terme d’alignement et réduit les performances globales.

Bien qu’un numéro de SAP ait été prévu pour IP dans LLC son utilisation a été bannie par l’IETF.

• Aucun SAP n’a été prévu au niveau LLC pour le protocole ARP.

L’IEEE a donc normalisé une extension à LLC pour régler ce conflit entre deux organismes de standardisation. Cette extension prend la forme du protocole SNAP présenté ci-dessous.

• CARACTERISTIQUES de SNAP :

SNAP : Sub-Network Access Protocol :

- Extension d’en-tête de IEEE LLC 802.2 sur 5 octets

-Aucun traitement des données, simple encapsulation entre la couche de réseau et la sous-couche LLC.

aiguillage vers le protocole de niveau supérieur

- Format des trames de données SNAP :

- Le champ OUI (Organizational Unit Identity) reprend le code vendeur IEEE présent dans les adresses MAC.

En pratique, souvent à zéro. 

- Le champ numéro de protocole représente le numéro du protocole de niveau supérieur (idem ETHERNET)

       démultiplexage possible

Remarques :

- Tous les protocoles MAC IEEE peuvent être encapsulés par LLC/SNAP

démultiplexage possible vers IP

- SNAP peut également avoir d’autres utilisations comme l’encapsulation de paquets de protocoles de circuit virtuel (X.25, FR, ATM…)

universalisation de l’encapsulation ETHERNET 

E/ SYNTHESE

• SYNTHESE DEMULTIPLEXAGE :

Le schéma ci-dessous présente un récapitulatif du démultiplexage des données dans le cas des réseaux locaux quelque soit le protocole utilisé.

• EXEMPLE : IP sur ETHERNET :

Nous déroulons ci-après une illustration du fonctionnement de IP, ARP sur un LAN ETHERNET.

Ø  Le module IP du host H (193.55.221.8) situé sur un LAN Ethernet veut émettre un datagramme à destination d’un host d’adresse 201.1.5.12.

Ø  Illustration : 

Ø   Décision de routage : remise indirecte via le routeur R (CF Table de routage mentionnée)

Ø  Trafic ARP sur ETHERNET (requête et réponse ARP)

Ø    Trafic IP sur ETHERNET (acheminement du datagramme vers le routeur)

• EXEMPLE : IP sur ETHERNET : émission requête ARP

Ø      Illustration de la requête ARP constituée par le module IP du host H (193.55.221.8) :

• EXEMPLE : IP sur ETHERNET : réception requête ARP

Ø    Sur la machine 193.55.221.8 : réception réponse ARP

• EXEMPLE : IP sur ETHERNET : émission datagramme IP

Ø    Sur la machine 193.55.221.8 : émission du datagramme IP à destination du routeur

• EXEMPLE : IP sur ETHERNET : réception datagramme IP

Ø    Sur le routeur 193.55.221.1 : réception du datagramme IP 

Interfaçage IP / Liaisons WANs

A/ Introduction

L’interconnexion de réseaux locaux à réseaux locaux distants, ou encore d’hosts déportés à des réseaux locaux, nécessite l’utilisation de liaisons de télécommunications. Ces liaisons de « large portée » géographique, offres des opérateurs de télécommunications, vont de la simple liaison série analogique à des réseaux à relayage de trames en passant par des liaisons xDSL, RNIS ou des liaisons numériques.

L’objectif de cette section est d’étudier comment IP, en tant que protocole routé, peut être interfacé sur ces liaisons WANs. Il ne s’agit pas de présenter exhaustivement les cas possibles, mais plutôt de montrer que différentes solutions existent, nécessitant ou non, l’utilisation de protocoles intermédiaires. En particulier, la suite de protocoles PPP sera largement abordée car elle constitue une solution adaptable à un grand nombre de cas.

B/ IP sur liaisons série : SLIP

L’objectif initial de faire transiter du trafic IP sur des liaisons série était de pouvoir raccorder de façon économique des utilisateurs déportés à un réseau distant (Internet, réseau de l’entreprise…) via le RTC.

•    Exemple de CONFIGURATION PHYSIQUE :

SLIP : Serial Line IP (RFC 1055)

• ENCAPSULATION :

Ø Le datagramme est directement transmis sur la liaison série,

Ø Pour en indiquer la fin, le caractère spécial  END est rajouté.
- si END  dans les données : substitution par séquence  ESC ESC_END
- si ESC dans les données : substitution par séquence ESC ESC_ESC

• ADRESSAGE et ROUTAGE IP : 

Ø Liaison point-à-point = = > pas d'adressage niveau 2, pas de résolution d'adresse (non ambiguïté du destinataire).

Ø Une liaison série SLIP < = = > un sous-réseau IP.

                        = = > deux adresses IP attribuées aux deux extrémités

Ø Le host "serveur" se comporte comme un routeur.

Ø La configuration client est simple. Le routeur par défaut est le serveur SLIP.

 

• ARCHITECTURE d'une LIAISON SLIP :

Ø piles de protocoles et tables de routage :

Table de routage du serveur 127.0.0.0 127.0.0.1 128. 67.0.0 128.67.60.12 192.168.221.0 192.168.221.60

Table de routage du client 127.0.0.0 127.0.0.1 192.168.221.0 192.168.221.61 default 192.168.221.60

C/ IP sur liaisons point à point  : suite PPP

SLIP présentant de nombreuses limites, mais surtout restant dédié au cas « IP sur liaison série », un nouveau protocole plus général a été spécifié. Il s’agit plutôt d’une suite de protocoles connue sous le nom de PPP. Les caractéristiques générales de PPP montrent l’apport de ce protocole par rapport à la solution SLIP.

PPP : Point to Point Protocol (RFC 1661)

• CARACTÉRISTIQUES GÉNÉRALES :

Protocole plus général que SLIP, donc plus complexe à mettre en oeuvre. Basé sur le modèle Client/Serveur, PPP permet de :

Ø véhiculer des protocoles de niveau 3 autres que IP,

Ø sur des liaisons WAN autres que des liaisons série comme RNIS, X25, Frame Relay, xDSL, SONET/SDH, ATM…

Ø détecter et corriger les erreurs de transmission tout en évitant d'utiliser des caractères interprétables par les modems,

Ø de compresser les en-têtes IP et TCP pour accroître les performances de la liaison,

Ø de gérer un contrôle d'accès au réseau,

Ø de configurer automatiquement le host déporté.

• ARCHITECTURE de la SUITE de PROTOCOLES PPP: 

Plusieurs modules protocolaires concourent à la réalisation de ces fonctionnalités : 

• FONCTIONNEMENT GÉNÉRAL :

Ø LCP (RFC 1661) Link Control Protocol) établit et teste la liaison entre le client (host déporté) et le serveur tout en négociant des paramètres de la connexion :

- Taille maximale des trames reçues (MRU – 1500 Ø par défaut),
- Protocole d'authentification utilisé (PAP ou CHAP),
- Compression de champs PPP et HDLC,
- Technique de bourrage,
- Rappel automatique par le serveur,

Ø PPP peut procéder à une phase d'authentification de l'identité du client en utilisant, suivant la négociation, soit :

• PAP (RFC 1332)Password Authentification Protocol)

- Echange en clair d'un mot de passe, puis vérification.

• CHAP (RFC 1332) (Challenge Authentification Protocol)

- Echange de données cryptées avec système de clés.

Ø La phase suivante consiste à négocier les paramètres du protocole de niveau 3 pour configuration le client.
C'est un module "NCP" (Network Configuration Protocol) qui est utilisé. Il en existe un spécifique à chaque protocole de niveau 3.
Pour IP, il s'agit de IPCP (RFC 1334) (IP Configuration Protocol) qui permet de négocier :

- l'adresse IP du client déporté,"
- la compression des en-têtes TCP/IP (Algorithme de Van Jacobson qui permet de n'émettre qu'un différentiel entre deux entêtes de paquets successifs d'une même connexion TCP. Ce différentiel peut être codé sur un octet)

Ø L'échange de datagrammes peut alors débuter par encapsulation dans des trames PPP.

Ø La fermeture de la connexion point-à-point s'effectue à l'aide d'une requête LCP.

Ø   A noter enfin, un module d’interfaçage entre PPP et la liaison utilisée en dessous. 

•    PPP : FORMAT des TRAMES:

Encapsulation simple : ajout d'un indicateur pour spécifier le protocole client :

Ø  Champ PROTOCOLE : (2 octets – réduit à 1 octet si négocié)

  - Identifie le protocole de niveau supérieur utilisant PPP pour transférer des données.

- Principales valeurs :

- On notera que l’encapsulation PPP s’applique également aux autres protocoles de la suite (LCP, PAP, CHAP et les NCPs).

Ø       Champ DONNÉES : (1500 octets par défaut ou négociée)

- Données de la trame (ex : un datagramme IP).

Ø       Champ BOURRAGE : (16 bits)

- Atteindre la taille souhaitée par le support physique.

• ADAPTATION des trames PPPP au SUPPORT PHYSIQUE :

Les trames PPP doivent être acheminées par des trames de niveau liaison. Puisque l’ambition de PPP est de fonctionner sur des types de liaison différents, une couche d’adaptation au support physique est nécessaire pour préparer l’encapsulation.

Dans le cas d'une liaison série, encapsulation de la trame PPP dans une trame de type HDLC :

• LCP : FORMAT des TRAMES :

L’objectif de LCP est d’établir la liaison, de négocier des paramètres sur le fonctionnement de PPP et enfin de libérer la liaison. Dix types de trame sont définis dans LCP pour supporter ces fonctionnalités. L’en-tête LCP a le format suivant :

Ø   Champ CODE : (1 octet)

- Identifie le type de trame LCP.

- Principales valeurs et phases d’utilisation : 

Ø  Champ IDENTIFICATEUR : (1octet)

- Permet l’association  Requête / Réponse correspondante.

Ø  Champ LONGUEUR : (2 octets)

- Longueur totale de la trame LCP (Elimination bourrage).

Ø  Champ DONNEES : (x octets)

- Format guidé par le champ code : taille variable.

• LCP : les OPTIONS de NEGOCIATION :

La phase de négociation se déroule au début de la connexion, dès que la liaison est établie. Elle est réalisée dans les deux sens : le premier équipement négocie ses paramètres avec le second, puis le second avec le premier.

L’expression des valeurs à négocier, dans une trame de négociation LCP, prend la forme d’options contenues dans le champ données qui sont structurées selon le format suivant :

Ø  Champ TYPE : (1 octet)

- Identifie la nature de l’option négociée.

Ø  Champ LONGUEUR : (1 octet)  

- longueur totale de l’option en nombre d’octets.

Ø  Champ DONNEES : (x octets)

- Données nécessaires à la négociation de l’option.

•   LCP : EXEMPLES d’OPTIONS :

Quelques exemples d’options négociables :

• PAP et CHAP : FORMAT des TRAMES :

Les en-têtes sont semblables à celle de LCP :

PAP : 

Le fonctionnement de ce protocole d’authentification est très simple : il s’agit pour le client de communiquer en clair son identité et un mot de passe et pour le serveur d’acquitter positivement ou négativement la validité de celui-ci. Le tableau suivant récapitule les valeurs du champ code et des données :

CHAP : 

CHAP apporte un niveau de qualité supérieure en terme de sécurité en mettant en place un échange cryptée des données. Les deux entités disposent d’une clé secrète et commune qui sera utilisée de part et d’autre dans un algorithme de cryptage. Le serveur envoie au client une séquence binaire (le « challenge »). Le client, qui veut se connecter, calcule le seau de la séquence, le chiffre avec la clé secrète puis retourne la valeur obtenue au serveur (la « réponse »). Le serveur compare la valeur reçue avec celle qu’il a calculée localement de la même manière : si elles sont égales, l’authentification est réussie et il acquitte positivement au client (« Succès »). Dans le cas contraire un acquittement négatif (« échec ») est retourné. Le tableau suivant récapitule les valeurs du champ code et des données :

• IPCP : FORMAT des TRAMES :

IPCP est un protocole de configuration dynamique de paramètres de niveau réseau (NCP) spécifique à IP. Il s’appuie sur une phase de négociation semblable à celle de LCP :

Les valeurs du champ code reprises de LCP pour IPCP :

• IPCP : les OPTIONS NEGOCIABLES :

Format des deux options négociables :

• ADRESSAGE et ROUTAGE IP :

Généralement :

Ø  utilisation d'un proxy ARP pour intégrer au réseau (ex : LAN de l’organisation, ou réseau du Fournisseur d’Accès Internet – IAP) les équipements déportés :

Le serveur PPP répond aux requêtes ARP concernant les clients PPP en associant sa propre adresse MAC à l'adresse IP d'un client PPP déporté : 

pas de sous-réseau IP dédié nécessaire

Associations ARP sur le "serveur/proxy" :

Ø  Tables de routage classiques.

 

• SERVEURS RADIUS :

RADIUS : Remote Authentification Dial In User Service (RFC 2138-39)

Généralement les organismes importants (grandes entreprises, IAP….) mettent en place un point d’accès (à un réseau local, à Internet) constitué par un pool de modems : cela permet de supporter des accès simultanés par plusieurs clients.

La mise en place d’un serveur RADIUS facilite l’administration en terme de sécurité, de configuration voire de comptabilité.

Le serveur RADIUS gère une base de données unique comportant pour chaque utilisateur des informations d’authentification et de configuration.

• Autres CAS d’UTILISATION de PPP :

Au départ : PPP conçu pour liaisons série (locales, liaisons louées, téléphone…)

D’autres possibilités sur liaisons WAN :

Ø Du moment où une technologie WAN peut offrir une liaison point à point synchrone (orientée bit ou octet), Full Duplex, permanente ou non (commutée), PPP peut être utilisé :

Ø   Aperçu des possibilités :

D/ IP directement sur WANs : exemples de X.25 et Frame Relay

Les équipements d’interconnexion proposent également la possibilité d’utiliser directement (sans passer par PPP) les interfaces WANs. Nous donnons un aperçu sur les cas de X.25 et de Frame Relay.

Encapsulation de IP sur X.25 (niveau 3)(RFC 1356)

• FONCTIONNEMENT GÉNÉRAL :

Ø   IP demande à X.25-3 l'établissement d'une connexion avec l'ETTD distant (ouverture d'un circuit virtuel),

            ( ~ N-CONNECT)

- la "résolution d'adresse se fait par consultation de tables de correspondance "@sse-IP, @sse X.121" remplies manuellement. Il s’agit ici d’un mode "statique (impossibilité d’utiliser ARP car réseau X.25 ne supporte pas la diffusion).

- le paquet d'appel précise dans le champ NPLID la nature des données qui vont être transmises sur le circuit virtuel. La valeur est 0xCC pour IP et 0x8E pour IPv6.

Ø IP transmet le datagramme à l'interface X.25-3 qui l'encapsule dans le champ données d'un paquet ensuite transmis sur le circuit virtuel à l'ETTD distant.
( ~ N-DATA)

Ø    La libération du circuit X.25 s'opère lorsqu'un qu'un temporisateur d'inactivité se déclenche. 
( ~ N-DISCONNECT)

ATTENTION  au type de trafic IP qui doit circuler sur un X.25 public (Transpac) = = > coût parfois élevé
(Eviter les protocoles de routage dynamique comme RIP)

Encapsulation de IP sur FRAME RELAY   (RFC 2427)

• RESOLUTION d’ADRESSES :

Ø statique (idem X.25) : elle s’effectue par consultation de tables de correspondance "@sse-IP, @sse Q.922" remplies manuellement.

Ø  dynamique : dans le cas particulier où il existe plusieurs Circuits Virtuels Permanents (PVCs). On peut alors utiliser le protocole ARP pour récupérer l’adresse Q.922 d’un équipement à l’autre extrémité d’un PVC ayant l’adresse IP recherchée. Les requêtes ARP sont expédiées sur chacun des PVCs pour simuler la diffusion.

(On peut également rencontrer la mise en oeuvre d’un protocole de résolution d’adresse spécifique aux réseaux NBMA, connu sous le nom de NARP (NBMA ARP – RFC 1735)).

Remarque : Dans certaines situations d’autoconfiguration, un équipement A qui connaît l’adresse Q.922 d’un équipement B peut récupérer dynamiquement l’adresse IP de B par une extension du protocole ARP, dénommée Inverse ARP (IARP – RFC 2390).

• ENCAPSULATION de DATAGRAMMES IP :

Ø    Deux types d’encapsulation possibles dans LAPF :

-     Encapsulation directe  :

-     Encapsulation via SNAP  :

Moins performante que la précédente, mais propice à des cas d’interconnexion de LANs

Remarque : ce second type d’encapsulation est utilisé dans le cas de l’utilisation d’ARP et de ses extensions.

E/ Synthèse

Le schéma ci-dessous donne une vision synoptique des différentes possibilités évoquées précédemment :