CHAPITRE V : Les Réseaux IP
Démarrer son réseau IP
Des architectures viennent d’être élaborées, des réseaux viennent d’être construits, des protocoles sont utilisés. Mais comment tout cela s’imbrique-t-il ? Comment IP, TCP et Ethernet fonctionnent-ils ensemble ?
Ce chapitre est l’occasion d’aller plus loin dans la connaissance de ces protocoles et de votre réseau, et de vous donner par la même occasion une vision plus globale des réseaux. Car, comprendre, c’est pouvoir construire des réseaux de plus en plus complexes comme le requièrent les applications multimédias d’aujourd’hui.
Jusqu’à présent, nous ne nous sommes préoccupés que du matériel mais, avec le spanning tree, introduit au chapitre 3, nous devons désormais nous préoccuper du paramétrage logiciel des équipements réseau.
Comprendre, c’est donc maîtriser le fonctionnement de son réseau.
Deuxième exemple, celui de l’adresse IP que nous avons utilisé sans en bien comprendre les tenants et aboutissants. Cet aspect logiciel doit maintenant être expliqué, car les choix que vous prenez lorsque vous commencez par construire un petit réseau peuvent ensuite peser bien des années plus tard, lorsque celui-ci a pris de l’ampleur.
Comprendre, c’est donc anticiper et faire les bons choix pour l’avenir.
Dans ce chapitre, vous apprendrez ainsi :
Ce chapitre est l’occasion d’aller plus loin dans la connaissance de ces protocoles et de votre réseau, et de vous donner par la même occasion une vision plus globale des réseaux. Car, comprendre, c’est pouvoir construire des réseaux de plus en plus complexes comme le requièrent les applications multimédias d’aujourd’hui.
Jusqu’à présent, nous ne nous sommes préoccupés que du matériel mais, avec le spanning tree, introduit au chapitre 3, nous devons désormais nous préoccuper du paramétrage logiciel des équipements réseau.
Comprendre, c’est donc maîtriser le fonctionnement de son réseau.
Deuxième exemple, celui de l’adresse IP que nous avons utilisé sans en bien comprendre les tenants et aboutissants. Cet aspect logiciel doit maintenant être expliqué, car les choix que vous prenez lorsque vous commencez par construire un petit réseau peuvent ensuite peser bien des années plus tard, lorsque celui-ci a pris de l’ampleur.
Comprendre, c’est donc anticiper et faire les bons choix pour l’avenir.
Dans ce chapitre, vous apprendrez ainsi :
- à définir un plan d’adressage IP ;
- à comprendre l’interaction des protocoles Ethernet et IP ;
- le fonctionnement d’un réseau local ;
- le fonctionnement des protocoles IP, TCP et UDP.
Le plan d’adressage IP
À plusieurs reprises déjà, nous avons parlé d’adresses IP sans vraiment nous en préoccuper. Il est vrai que nous n’en avions pas réellement l’usage ; il suffisait simplement de saisir une adresse unique pour chaque station du réseau.
Mais notre réseau prend de l’ampleur et nous devons désormais organiser l’affectation des adresses. Les ISP ne procèdent pas autrement au sein de l’Internet.
Comme cela a été décrit au chapitre 3, une adresse IP s’écrit avec quatre numéros, compris entre 1 et 255, séparés par des points, par exemple 192.162.0.1. Une partie de cette adresse désigne un réseau, l’autre le numéro de station au sein de ce réseau. Jusqu’à présent, nous nous sommes arrangés pour configurer toutes nos stations dans le même réseau IP.
On peut se poser la question suivante : pourquoi faut-il des adresses IP alors qu’il existe déjà des adresses MAC ? D’abord, Ethernet est un réseau local, qui n’a donc qu’une portée géographique limitée. Ensuite, il existe des dizaines de réseaux de niveau 1 et 2 différents avec chacun un adressage physique qui lui est propre. Or, les PC, même situés sur des réseaux différents, doivent pouvoir communiquer ensemble. Il faut donc un protocole de niveau supérieur, dit de niveau 3 (couche réseau), qui permet de fédérer ces réseaux avec un adressage unique. On trouve ainsi IP sur Ethernet et PPP, mais aussi sur TokenRing, ATM, etc.
------------------------------------------------------------------------------------------------
POURQUOI UN PLAN D’ADRESSAGE ?
L’objectif premier du plan d’adressage est d’éviter la duplication accidentelle des adresses. Pour l’adressage MAC, un plan n’est pas utile car les adresses sont affectées aux cartes par les constructeurs. En revanche, l’affectation des adresses IP relève de votre responsabilité, ou de celle du NIC pour le réseau public Internet.
Le plan d’adressage permet également de contrôler le fonctionnement de votre réseau IP. En effet, l’affectation des adresses IP doit répondre à des règles précises sous peine d’aboutir à des dysfonctionnements (connexions impossibles, voire intermittentes, etc.).
En définitive, le plan d’adressage permet d’organiser l’exploitation de votre intranet.
------------------------------------------------------------------------------------------------
IP permet aussi de partitionner les réseaux. En effet, de nombreux protocoles utilisent abondamment les broadcasts et multicasts, et il est préférable de limiter la diffusion de ces types de trames. Si votre intranet est connecté à l’Internet, il n’est pas envisageable de recevoir des trames multicast et broadcast émises par un employé de la société X.
De plus, l’interconnexion des sites coûte cher compte tenu des distances. Il est donc judicieux de limiter le trafic afin de ne pas surcharger inutilement les liaisons par des broadcasts.
La démarche
Tout d’abord, il est conseillé de retenir un adressage privé, c’est-à-dire complètement séparé de celui de l’Internet, ceci pour des questions de simplicité et de sécurité. Il est toujours possible d’opter pour un adressage public, mais l’obtention de telles adresses est très difficile, car il faut justifier de leur usage auprès des organismes de régulation de l’Internet.
------------------------------------------------------------------------------------------------
L’ADRESSAGE IP V4 (RFC 791)
IP (Internet Protocol) définit un réseau virtuel reposant sur des réseaux physiques de différente nature (Ethernet et PPP, par exemple). Pour ce faire, IP utilise un adressage logique différent de l’adressage
physique (MAC, PPP ou autre).
Une adresse IP est découpée en un numéro de réseau et un numéro de station au sein de ce réseau. Il existe trois classes d’adresses unicast en fonction de la taille du réseau (c’est-à-dire du nombre de stations par réseau). Pour différencier la partie réseau (subnet) de la partie station (host), IP utilise un masque dont tous les bits à 1 représentent la partie réseau.
Deux valeurs sont réservées dans la partie station de l’adresse : 0 pour désigner le réseau lui-même et 255 (tous les bits à 1) pour désigner toutes les stations au sein de ce réseau (broadcast).
Il existe également une classe d’adresses multicast permettant de désigner des groupes de stations.
La classe E (premiers à bits 11110) définit une classe d’adresses expérimentales. Elle n’est jamais utilisée.
L’adresse 255.255.255.255 désigne toutes les stations sur le réseau de l’émetteur du paquet (broadcast IP). ------------------------------------------------------------------------------------------------
Il se peut donc que vous utilisiez des adresses déjà affectées sur l’Internet, mais cela n’a pas d’importance car votre intranet est isolé. Cela ne vous empêchera cependant pas de l’interconnecter avec l’Internet.
La seconde décision concerne le choix de la classe d’adresse IP. Ce choix dépend du nombre de stations présentes sur votre réseau. Si ce nombre dépasse 254, une classe B s’impose. Une classe A n’est pas utile, car une classe B offre 65 534 adresses de stations, ce qui est largement suffisant. De plus, une classe A est limitée à 126 réseaux IP, ce qui, pour les grands réseaux, peut être un handicap.
En résumé, notre choix s’est provisoirement porté sur un plan d’adressage privé de classe B, ce qui nous donne 16 382 réseaux possibles contenant chacun 65 534 stations. Aux sections suivantes, d’autres considérations viendront modifier ce choix.
Les principes de base
L’adressage IP est très souple et permet de faire tout ce que l’on veut. Afin d’éviter toute mauvaise surprise, il est conseillé de suivre les principes suivants :
- Règle 1 : un réseau IP ne doit pas chevaucher plusieurs sites.
- Règle 2 : il peut y avoir plusieurs réseaux IP sur un site.
- Règle 3 : s’il y a plusieurs réseaux IP sur un site, choisir des numéros contigus. Cela simplifiera le routage et permettra aux routeurs d’agréger les routes selon la méthode CIDR (Classless Inter-Domain Routing) expliquée au chapitre 12.
- Règle 4 : limiter le nombre de réseaux IP. Cela simplifiera les connexions à l’Internet.
Le protocole IP impose qu’une station se trouvant dans un réseau IP ne puisse pas communiquer directement avec une station se trouvant dans un autre réseau IP, même si elles sont connectées au même segment Ethernet. Les réseaux sont segmentés de manière logique ; en d’autres termes, ils sont partitionnés.
La solution repose sur l’utilisation d’un routeur dont le rôle est d’interconnecter les réseaux IP, quelle que soit leur localisation géographique. On verra au chapitre 12 qu’il existe un moyen de lever cette contrainte imposée par IP.
De toute façon, l’utilisation d’un routeur s’impose dès que vous devez relier deux sites sur de longues distances. L’Internet comporte des dizaines de milliers de routeurs. Donc, autant prendre en compte cette contrainte dès le début de l’élaboration du plan d’adressage.
------------------------------------------------------------------------------------------------
QU’EST-CE QU’UN ROUTEUR ?
Un routeur est un commutateur de niveau 3, c’est-à-dire qui commute les protocoles de la couche réseau, tels que IP. La commutation des paquets IP est plus complexe que celle des trames Ethernet. On emploiera donc plutôt le terme de routage.
Ce mécanisme consiste à analyser l’adresse de destination du paquet IP et à le transmettre sur le bon port (appelé interface). Il utilise pour cela des algorithmes de routage, tels que OSPF (Open Shortest Path First) qui permettent de calculer les meilleures routes en fonction des numéros de réseau IP.
Comme pour les PC, une interface routeur est associée à au moins un réseau IP. ------------------------------------------------------------------------------------------------
Impact sur l’Internet
Tôt ou tard, l’interconnexion de votre réseau avec l’Internet sera nécessaire. Comment éviter que vos adresses internes entrent en conflit avec celles de l’Internet ?
La solution repose sur l’utilisation de la translation d’adresses (cf. chapitre 17). Cette technique permet de masquer votre plan d’adressage privé vis-à-vis des utilisateurs situés sur l’Internet.
Une solution complémentaire à la première repose sur le non-routage de certaines adresses. La RFC 1918 précise que certaines adresses ont été réservées pour l’adressage privé. Le respect par tous les ISP de cette RFC garantit que ces adresses ne seront jamais routées sur l’Internet.
On peut donc utiliser ces adresses pour notre réseau privé, sans que cela soit pour autant une obligation. L’essentiel d’une interconnexion avec l’Internet repose, en effet, sur la translation d’adresses.
Or, pour les grands réseaux, le nombre de réseaux IP à translater est source de complexité : s’il y a quarante sites mais un seul point de sortie vers l’Internet, le firewall devra prendre en compte quarante réseaux IP dans ses règles de translation d’adresses.
Afin de simplifier cette configuration, il faudrait donc pouvoir ne translater qu’un réseau IP au niveau du firewall (respect de la règle 4) tout en ayant autant de subnets IP que nécessaire pour notre intranet. La solution repose sur la création de sous-réseaux IP.
Les sous-réseaux IP
Le principe des sous-réseaux (subnet) consiste à étendre le nombre de bits désignant la partie réseau. Le nombre de stations par sous-réseau diminue donc d’autant.
La partie station de l’adresse doit comporter au moins 2 bits afin que cette dernière soit valide.
La notation décimale (octet par octet) est rendue difficile lorsque le sous-réseau ne porte pas sur un multiple de 8 bits. C’est pourquoi la notation « / [nombre de bits affectés à la partie réseau] » est plus souvent utilisée.
Notre choix initial portait sur une classe B. Si nous voulons limiter le nombre de réseaux IP et conserver la même souplesse que la classe B, il faut donc retenir une classe A « subnettée » sur une classe B.
Cela nous offrirait 256 sous-réseaux. Si, dans le futur, ce chiffre était dépassé, on pourrait toujours ajouter un autre réseau de classe A (il ne ferait pas partie de la RFC 1918, mais ce n’est pas réellement important) et le « subnetter », ou ajouter une classe B à notre plan d’adressage. Notre but est simplement de limiter le nombre de réseaux IP.
Nous choisissons donc l’adresse de classe A, 10.0.0.0, issue de la RFC 1918. Étant donné le subnet choisi, notre masque sera donc : 255.255.0.0. Mais ce choix est encore provisoire.
Méthode d’affectation des réseaux LAN
Le plus simple est d’affecter les réseaux par site (respect de la règle 1). Au lieu d’affecter séquentiellement le numéro, on peut l’incrémenter de 4 ou 8, ce qui laisse la possibilité d’étendre le subnet affecté au site (respect de la règle 2). L’ajout d’un réseau sur un site se traduira donc par l’affectation du numéro de réseau suivant (respect de la règle 3).
Une première version de notre plan d’adressage serait donc la suivante :
Le plus simple est d’affecter les réseaux par site (respect de la règle 1). Au lieu d’affecter séquentiellement le numéro, on peut l’incrémenter de 4 ou 8, ce qui laisse la possibilité d’étendre le subnet affecté au site (respect de la règle 2). L’ajout d’un réseau sur un site se traduira donc par l’affectation du numéro de réseau suivant (respect de la règle 3).
Une première version de notre plan d’adressage serait donc la suivante :
L’incrément de 4 a été soigneusement choisi, de manière à obtenir des réseaux contigus.
Ainsi, le site de Paris dispose de quatre réseaux : 10.0.0.0, 10.1.0.0, 10.2.0.0 et 10.3.0.0, avec chacun un masque à 255.255.0.0. Mais cette manière de découper les réseaux est quelque peu rigide, car la région de Paris peut comprendre à la fois des petits sites et des gros sites.
Une autre façon de voir les choses est de considérer le réseau 10.0.0.0 avec le masque 255.252.0.0 (soit 10.0.0.0/14), ce qui offre 262 142 adresses (65 536 × 4 –2) pour le subnet 10.0.0.0 affecté à Paris (de 10.0.0.0 à 10.3.255.255).
En définitive, notre plan d’adressage se présente en réalité sous la forme suivante :
Au sein de ce réseau, il est alors possible de créer d’autres subnets dont la taille varie en fonction de l’importance du site. En faisant varier la longueur du masque on crée ainsi des subnets variables (RFC 1219).
Par exemple, au sein de la plage d’adresses affectée à la région parisienne, on peut réserver le subnet suivant à un site de moyenne importance : 10.0.0.0/20 (masque égal à 255.255.240.0), soit 4 094 adresses (16 × 256 –2), de 10.0.0.1 à 10.15.255.254.
Au sein de ce site, il peut ensuite être nécessaire de créer des réseaux de différentes tailles, par exemple un réseau principal et de nombreux petits sous-réseaux dédiés connectés, par exemple, à un firewall.
(*) Si le réseau principal est étendu, il suffit de changer le masque qui devient 255.255.248.0, ce qui donne le réseau 10.0.0.0/21.
Le réseau 10.0.10.0/23 peut également être découpé en deux subnets de classe C (masque de 24 bits) 10.0.10.0 et 10.0.11.0.
Les subnets de classe C ainsi créés (10.0.8.0, 10.0.9.0, etc.) peuvent à leur tour être découpés en de très petits réseaux, juste assez grands pour connecter un routeur et quelques machines.
Une autre manière d’appréhender la subtilité du subnetting qui vient d’être opéré est de considérer la grille de découpage suivante.
Les plages réservées permettront d’étendre les plages déjà affectées si le nombre de stations devient plus important que prévu. Ainsi, le réseau « Serveurs publics » pourra être étendu en diminuant le masque de 1 bit, afin de donner le subnet 10.0.8.0/26 (255.255.255.192).
Il est à noter que la création d’un sous-réseau fait perdre chaque fois deux adresses.
La technique du subnetting permet de gérer la pénurie d’adresses publiques sur l’Internet.
En effet, la création de réseaux IP taillés sur mesure évite le gaspillage d’adresses ; par exemple, le réseau 10.0.0.0/16 offre 65 534 adresses qui seront loin d’être toutes utilisées.
Sur votre réseau privé, vous avez cependant plus de latitude. Mais attention aux évolutions qui peuvent être rapides, par exemple lors de la fusion de deux sociétés.
Méthode d’affectation des réseaux WAN
L’interconnexion des réseaux (abordée aux chapitres suivants) nécessite également des adresses, mais en moins grand nombre que pour les réseaux LAN.
Par exemple, sur une liaison point à point, seules deux adresses sont nécessaires, une pour chaque extrémité. Le subnetting sur 30 bits, qui offre deux adresses, permet de créer un réseau juste dimensionné pour ce besoin.
Nous pourrions utiliser une des plages de notre réseau 10, mais il est cependant plus intéressant d’utiliser un autre réseau IP, et cela pour plusieurs raisons :
- Les adresses des réseaux WAN ne sont pas diffusées sur l’ensemble du réseau ; elles ne sont connues qu’entre routeurs adjacents.
- Les adresses n’ont donc pas besoin d’être connues des réseaux utilisateurs.
- Utiliser une plage d’adresses distincte permet de mieux identifier les liaisons WAN.
Bien que cela ne soit pas une obligation, nous préférons donc utiliser une autre plage d’adresses de la RFC 1918. Une classe B suffira amplement.
Nous pouvons donc réserver une plage de notre réseau 172.16.0.0/16, que nous « subnetterons » comme suit :
Pour les interconnexions multipoints, il suffira de réduire le masque d’autant de bits que nécessaires pour les subnets considérés. En général, les réseaux multipoints WAN sont rares et comprennent peu d’adresses en comparaison des LAN.
Méthode d’affectation des stations au sein des réseaux
Chaque nœud IP doit posséder une adresse IP. Cela concerne les PC et les Macintosh, les serveurs (NT, Unix, etc.), les imprimantes, les routeurs, les concentrateurs et commutateurs administrables (pour les agents SNMP), etc.
Il est tentant de découper la plage d’adresses en autant de parties qu’il y a de types de matériels. Cela n’apporterait cependant rien ni sur un plan technique, ni sur un plan organisationnel.
L’expérience montre, de plus, qu’une telle pratique n’est pas pérenne : soit la taille de la plage que l’on avait réservée est insuffisante (davantage de PC que prévu, par exemple), soit, à la longue, personne ne respecte une marche à suivre qui est trop contraignante (par exemple, s’il faut installer un PC en urgence, on prend la première adresse disponible).
Il est, en revanche, intéressant de prévoir un découpage simple entre les équipements terminaux (PC, serveurs, imprimantes, etc.) et les équipements réseau (les routeurs, les agents SNMP des concentrateurs et des commutateurs, etc.). Cela permet de mieux contrôler les flux du réseau. Dans le cas d’un subnet de classe B, on peut se risquer à créer une troisième plage réservée aux serveurs.
Dans le cas d’un subnet sur une classe C, le plus simple est de ne pas affecter de plage d’adresses par type d’équipement, car la probabilité de collision est encore plus forte qu’avec une classe B. L’affectation des adresses pour les équipements réseau et serveur peut commencer par le bas de la plage et s’incrémenter ensuite, tandis que celle pour les PC peut commencer par le haut de la plage et se décrémenter ensuite.
On peut constater que le plan d’adressage doit prendre en compte de nombreux paramètres liés à des notions qui n’ont pas été introduites : routage, translation d’adresse, affectation dynamique, connexion à l’Internet et contrôle de flux. Les chapitres suivants vous permettront de juger de la pertinence ou non du plan d’adressage qui vous est proposé.
L’encapsulation des protocoles
Il existe différents supports de transmission (câbles en cuivre ou en fibre optique, faisceaux hertziens) et différents moyens d’accéder à ces supports (accès partagé par détection de collision, par jeton, par partage fixe de bande passante, etc.). Cela implique l’utilisation de nombreux protocoles de niveau 1 (couche physique) adaptés à chaque situation.
La couche liaison, telle que PPP, permet de masquer aux couches supérieures les particularités du niveau physique et ses contraintes. Mais il arrive qu’une norme spécifie les couches 1 et 2 : c’est le cas d’Ethernet et d’ATM (Asynchronous Transfert Mode).
La couche de niveau 3 (couche réseau), telle que IP, peut donc utiliser différents réseaux en recourant aux services de PPP ou en s’adaptant directement sur une autre couche liaison.
On peut établir l’analogie suivante : le paquet IP est une voiture ; les pneus et les suspensions sont les protocoles de niveau 2 qui réalisent l’adaptation aux routes que sont les réseaux physiques. Vous roulez ainsi sur un chemin de terre (le RTC), puis sur une nationale (Ethernet) et enfin sur une autoroute (ATM), mais toujours avec la même voiture. Éventuellement, vous changez de pneus ou de suspensions, afin de vous adapter au terrain. De même, le paquet IP peut emprunter le RTC (avec une trame PPP), un réseau Ethernet (avec une trame Ethernet) ou un réseau ATM (avec une cellule ATM).
------------------------------------------------------------------------------------------------
L’ENCAPSULATION D’IP DANS ETHERNET (RFC 894 ET 1042)
Il existe deux formats de trames : Ethernet v2, également appelée DIX (du nom des constructeurs Digital, Intel et Xerox), et Ethernet IEE 802.3. Il y a donc deux façons d’envoyer un paquet IP sur Ethernet : directement dans une trame Ethernet v2 (RFC 894) ou dans une trame 802.3 via un en-tête LLC/SNAP (RFC 1042).
Si la valeur du champ “ Type de protocole/Longueur ” est supérieure à 1 500 (correspondant au nombre maximal d’octets pour le champ contenant le paquet IP), il s’agit d’une trame Ethernet v2 (le champ a alors la signification “ Type de protocole ”). Dans le cas contraire, il s’agit d’une trame Ethernet 802.3 (le champ a alors la signification “ Longueur ”).
Il existe différents types de trames LLC (IEEE 802.2) impliquant différents modes de fonctionnement. Pour IP, seule la trame de type Unnumbered Information (type 03) est utilisée (trame simple sans acquittement).
Elle est également utilisée pour transporter IP dans ATM (Classical IP), Token-Ring et FDDI.
La couche SNAP (Sub Network Access Protocol) est nécessaire, car la trame LLC (Logical Link Control) ne contient pas de champ équivalent au champ “ Type ” de la trame Ethernet v2. Le SAP (Service Access Point) utilisé pour transporter SNAP est 170 (0xAA). On retrouve ce principe d’adaptation avec d’autres protocoles comme Frame-Relay ou ATM (voir chapitre 11).
Dans le dernier champ de l’en-tête SNAP, on retrouve enfin le type de protocole (ethertype) utilisé dont les valeurs sont identiques à celles du champ de même nom de la trame Ethernet v2 (0x0800 pour IP, 0806 pour ARP, etc.).
Il est à noter que le MTU (Maximum Transfert Unit), c’est-à-dire les données utiles transportées dans la trame Ethernet, est plus important avec Ethernet v2, l’encapsulation 802.3 faisant perdre 8 octets. ------------------------------------------------------------------------------------------------
L’adressage
Toutes les couches réseau, de la couche physique à l’application en passant par les couches liaison, réseau et transport, utilisent des adresses afin d’identifier l’émetteur et le destinataire. Chaque couche utilise un système d’adressage spécifique qui répond à un besoin précis.
L’adressage de niveau 2 est géographiquement limité à un réseau local ou à une liaison point à point d’un réseau étendu.
L’adressage de la couche 3 permet d’identifier les stations à un niveau supérieur. Il assure la continuité entre des réseaux physiques qui utilisent différents systèmes d’adressage.
Enfin l’adressage de niveau 4 permet d’identifier les applications qu’utilisent les services de la couche transport.
Le multiplexage
Chaque couche réseau dispose d’un champ pour identifier le type de protocole encapsulé dans le champ de données. Ethernet identifie ainsi qu’il transporte un paquet IP, IP identifie qu’il transporte des données TCP, et TCP identifie l’application qui a rempli son champ de données.
Les champs « Type », « Protocole » et « Port » permettent à chaque couche de savoir à quelle couche supérieure remettre les données reçues. Le site www.iana.org/numbers.html recense ainsi toutes les valeurs affectées aux protocoles de la famille TCP/IP ou à ceux qui utilisent IP.
Il est ainsi possible d’envisager toutes les combinaisons d’encapsulation, telles que celle spécifiée par le protocole STUN (Serial Tunneling) qui permet de transporter dans un paquet IP une trame SDLC (Synchronous Dala Link Control) qui est un protocole de niveau 2 utilisé dans les réseaux SNA d’IBM. On pourra ainsi trouver l’encapsulation : « SDLC → TCP → IP → SNAP → LLC → Ethernet 802.3 ».
En théorie, tout protocole peut donc être encapsulé dans n’importe quel autre protocole.
Dans la pratique, on utilise cette facilité pour répondre à une contrainte particulière, telle que le transport des flux SNA dans un réseau IP.
Dans le cas d’une navigation sur le web, l’empilement des protocoles est : « segment HTTP → TCP (port 80) → IP (protocole 6) », puis toutes sortes de réseaux de transport, tels que PPP, Frame-Relay, ATM, etc.
Sur votre réseau, l’encapsulation sera : « IP → SNAP (protocole 2048) → LLC (SAP 170) → Ethernet 802.3 ».
Par défaut, Windows 2000 encapsule les paquets IP dans les trames Ethernet v2. Il est possible d’activer l’encapsulation LLC/SNAP en ajoutant le paramètre « ArpUseEtherSNAP » de type REG_DWORD à la clé de registre « HKEY_local_machine\System\CurrentControlSet\Services\Tcpip\Parameters », et en fixant sa valeur à 1.
Ce modèle en couches simplifie la programmation des protocoles en leur assignant des rôles précis, et offre plus de souplesse par le jeu des encapsulations possibles.
L’échange de paquets IP
Une carte réseau ne se préoccupe que des adresses MAC pour envoyer et recevoir des données. En revanche, une application telle que Telnet ne connaît que l’adresse IP qui est purement logique : une pile IP recevant un paquet IP ne le prendra en compte que si l’adresse de destination du paquet correspond à l’adresse IP qui a été paramétrée dans le PC. Dans le cas contraire, il sera ignoré.
Par ailleurs, l’adresse MAC de la station changera si la carte réseau est changée (en cas de panne, par exemple). De même, son adresse IP peut être modifiée à tout moment à l’aide des outils de configuration Windows (en cas de déménagement, par exemple).
L’exemple précédent montrait un paquet IP envoyé dans une trame de broadcast. Ce moyen d’opérer est pratique mais très consommateur de bande passante puisque la trame est propagée à travers tout le réseau. Sauf quand cela est nécessaire, un paquet IP est envoyé dans une trame unicast, c’est-à-dire directement au PC concerné. Mais comment connaître l’adresse MAC de la carte du PC destinataire alors que vous ne connaissez que l’adresse IP de sa pile IP ?
Cela est, par exemple, le cas lorsque vous lancez la commande suivante, qui permet de vous connecter à un serveur Unix :
Telnet 192.50.10.1
L’application Telnet va demander à la couche TCP d’ouvrir une connexion avec l’adresse IP indiquée, et va transmettre son paquet à la couche IP (avec l’adresse de destination indiquée). Cette dernière va encapsuler le segment TCP dans un paquet IP, puis l’envoyer à la carte. Mais la carte ne sait pas quoi faire d’une adresse IP ; elle ne sait gérer que des adresses MAC : une trame Ethernet ne contient qu’une adresse MAC qui permet aux autres cartes de la prendre ou non en compte.
La solution repose sur un mécanisme qui réalise la correspondance entre l’adresse MAC du PC destinataire et son adresse IP.
On pourrait utiliser une table de correspondance statique Adresse MAC ↔ Adresse IP. Mais cela serait fastidieux, car il faudrait relever les adresses MAC des stations ainsi que les adresse IP, et paramétrer la table sur tous les PC. Cela est inimaginable étant donné le nombre important de PC et les nombreux changements d’adresses qui interviennent. On perdrait en plus l’avantage de dissocier l’adresse physique de l’adresse logique. En outre, un PC peut être configuré avec plusieurs adresses IP.
------------------------------------------------------------------------------------------------
LE POINT SUR IPV4 (RFC 791)
IP (Internet Protocol) est un protocole de niveau 3 (couche réseau) qui découpe les réseaux locaux en réseaux logiques indépendamment de leur implémentation physique. Ce protocole permet donc d’envoyer des données à travers un réseau logique reposant sur des réseaux physiques de différente nature (Ethernet et PPP, par exemple). Pour ce faire, IP utilise un adressage logique différent de l’adressage physique (MAC, PPP ou autre).
Cette couche se contente de router (c’est-à-dire acheminer) le paquet à travers un réseau IP : les paquets peuvent être perdus (pas de garantie d’acheminement), contenir des erreurs (sauf sur l’en-tête, qui est contrôlé) ou arriver dans le désordre. IP fragmente les paquets dont la taille excède celle des trames (le MTU, Maximum Transfer Unit). Les fragments sont routés indépendamment les uns des autres comme autant de paquets, mais IP assemble dans le bon ordre les fragments d’un même paquet original. Le bit “ M ” positionné à “ 0 ” indique que ce paquet est le dernier fragment d’une série lorsque le bit “ DF ” est positionné à “ 0 ”.
Le bit “ DF ” positionné à “ 1 ” indique que l’émetteur ne souhaite pas fragmenter les paquets. Dans cas, si un routeur reçoit un paquet dépassant le MTU, il envoie à l’émetteur un message icmp_destination unreachable type 4 lui indiquant le MTU. Il est alors de la responsabilité de l’émetteur d’ajuster la taille de ces paquets ou d’autoriser la fragmentation.
Le champ TTL est décrémenté de 1 chaque fois que le paquet passe par un routeur. Si la valeur atteint zéro, le routeur détruit le paquet. Ce mécanisme évite aux paquets de rester trop longtemps sur le réseau, soit parce qu’ils tournent en boucle (suite à une erreur de routage), soit parce qu’ils traversent trop de routeurs.
La valeur initiale du TTL est fixée par la station émettrice (de 32 à 128, en général).
Le champ TOS n'existe plus en tant que tel. Il a été redéfini par les RFC 2474 (DiffServ) et 3168 (ECN) qui sont détaillées au chapitre 14.
La résolution d’adresse
La seule solution est donc une résolution d’adresse automatique, c’est-à-dire un mécanisme permettant de trouver l’adresse MAC en connaissant uniquement l’adresse IP. C’est le rôle du protocole ARP (Address Resolution Protocol) lié à la couche IP. Ce protocole gère une table de correspondance dynamique Adresse MAC ↔ Adresse IP, appelée cache ARP.
Vous pouvez en visualiser le contenu à l’aide de la commande Windows suivante : arp –a 00:40:0b:4b:25:d2 190.50.1.253
Si vous n’avez pas communiqué récemment avec un autre PC, la table sera vide : les entrées sont, en effet, effacées au bout d’un certain temps. Sous Windows, une entrée ARP (adresse MAC / adresse IP) est supprimée au bout de deux minutes si le PC n’a pas dialogué avec la station cible (selon le mécanisme TTL, Time To Live). Dans tous les cas, l’entrée reste au maximum dix minutes en mémoire, puis elle est supprimée.
Si l’adresse IP recherchée n’est pas dans le cache, ARP va alors envoyer un paquet de requête encapsulé dans une trame Ethernet de broadcast. Cette dernière va donc être lue par toutes les cartes réseau.
------------------------------------------------------------------------------------------------
LE POINT SUR ARP (RFC 826)
Pour obtenir l’adresse MAC d'une station ne connaissant que son adresse IP, la pile TCP/IP émet une requête ARP (Address Resolution Protocol) dans une trame Ethernet de broadcast dont le champ « Type »
contient la valeur 0x0806.
Chaque pile IP recevant un tel paquet compare alors son adresse avec celle figurant dans le champ « Adresse protocole destination ».
S'il y a correspondance, la couche ARP envoie un paquet de réponse en remplissant le champ « Adresse physique destination » avec l’adresse MAC de sa carte. Dans le cas contraire, le paquet est ignoré.
Donc, seule la station dont l’adresse IP correspond à celle demandée par la requête envoie en réponse un paquet contenant sa propre adresse MAC.
La résolution inverse, c’est-à-dire l’obtention de l’adresse IP à partir de l’adresse MAC, est réalisée par le protocole RARP (Reverse ARP – RFC 903). ------------------------------------------------------------------------------------------------
Seule la station configurée avec l’adresse IP recherchée va répondre en renvoyant son adresse MAC.
Une fois l’adresse résolue, le paquet IP peut être envoyé dans une trame MAC unicast dont l’adresse de destination est celle de la station cible.
L’échange de données entre applications
Une application utilise les services de la couche transport avec qui elle échange des données à travers une interface de programmation livrée avec la pile TCP/IP. Sous Unix, il s’agit des Sockets ; sous Windows de Winsock.
La couche transport est soit TCP (Transport Control Protocol) soit UDP (User Datagram Protocol), qui est une version allégée de TCP.
Le protocole TCP agit en mode connecté, ce qui implique que le client demande l’ouverture d’une connexion préalablement à tout échange. Par exemple, lorsque vous entrez la commande Windows « Telnet 192.50.10.1 », le programme client Telnet demande à TCP d’ouvrir une connexion à un serveur Telnet qui est en attente, c’est-à-dire à l’écoute du port TCP 23.
Inversement, UDP agit en mode non connecté, ce qui permet à deux machines d’échanger des données à tout moment, sans entrer dans une phase de connexion. Par exemple, lorsque vous voulez vous connecter à un serveur de fichiers Windows NT, votre PC émet une demande de résolution de nom à destination d’un serveur WINS qui est à l’écoute sur le port UDP 137.
La couche transport est soit TCP (Transport Control Protocol) soit UDP (User Datagram Protocol), qui est une version allégée de TCP.
Le protocole TCP agit en mode connecté, ce qui implique que le client demande l’ouverture d’une connexion préalablement à tout échange. Par exemple, lorsque vous entrez la commande Windows « Telnet 192.50.10.1 », le programme client Telnet demande à TCP d’ouvrir une connexion à un serveur Telnet qui est en attente, c’est-à-dire à l’écoute du port TCP 23.
Inversement, UDP agit en mode non connecté, ce qui permet à deux machines d’échanger des données à tout moment, sans entrer dans une phase de connexion. Par exemple, lorsque vous voulez vous connecter à un serveur de fichiers Windows NT, votre PC émet une demande de résolution de nom à destination d’un serveur WINS qui est à l’écoute sur le port UDP 137.
La pile TCP/UDP du client choisit généralement un port source supérieur à 1023, et incrémente cette valeur à chaque nouvelle session ouverte simultanément à d’autres déjà actives.
------------------------------------------------------------------------------------------------
LE POINT SUR UDP (RFC 768)
UDP (User Datagram Protocol) permet simplement à une application d’avoir accès au réseau IP. Ce protocole n’offre aucune garantie d’acheminement, aucun mécanisme de reprise sur erreur, ni de contrôle de
flux, et ne vérifie pas la duplication des paquets. Tous ces contrôles doivent être opérés par les autres couches réseau. En revanche, les paquets remis à l’application le sont sans erreur.
Les champs port source et port destination servent à identifier une application (par exemple, 23 pour Telnet). Ces valeurs sont réservées et enregistrées par l’IANA (www.iana.org/assignments/port-numbers).
------------------------------------------------------------------------------------------------
Les clients et les serveurs manipulent des noms (une machine Unix, un serveur de fichiers NT) et s’échangent des données à travers des ports qui leur sont réservés par l’IANA (voir en annexe « La gestion de l’Internet »). Sur l’Internet, le service DNS permet de convertir les noms en adresses IP (voir chapitre 7), tandis que, dans le monde Microsoft, on utilise encore le service WINS pour convertir des noms Netbios en adresses IP.
On peut considérer que ce protocole est situé au niveau de la couche 5 (couche session) : il permet, en effet, d’établir et de gérer des sessions entre applications. Dans le monde Internet, les applications comme Telnet, votre navigateur Web, FTP, etc.) gèrent elles-mêmes tous les mécanismes situés au-dessus de la couche transport, c’est-à-dire TCP et UDP.
À l’origine, Netbios circulait nativement dans des trames Ethernet, mais de nos jours, il est encapsulé dans IP (RFC 1001 et 1002).
Par exemple, le partage de fichiers et la messagerie Exchange utilisent le protocole Netbios sur le port TCP 139. Par ailleurs, les serveurs WINS s’échangent des données sur le port TCP 42.
Les clients et les serveurs manipulent des noms (une machine Unix, un serveur de fichiers NT) et s’échangent des données à travers des ports qui leur sont réservés par l’IANA (voir en annexe « La gestion de l’Internet »). Sur l’Internet, le service DNS permet de convertir les noms en adresses IP (voir chapitre 7), tandis que, dans le monde Microsoft, on utilise encore le service WINS pour convertir des noms Netbios en adresses IP.
On peut considérer que ce protocole est situé au niveau de la couche 5 (couche session) : il permet, en effet, d’établir et de gérer des sessions entre applications. Dans le monde Internet, les applications comme Telnet, votre navigateur Web, FTP, etc.) gèrent elles-mêmes tous les mécanismes situés au-dessus de la couche transport, c’est-à-dire TCP et UDP.
À l’origine, Netbios circulait nativement dans des trames Ethernet, mais de nos jours, il est encapsulé dans IP (RFC 1001 et 1002).
Par exemple, le partage de fichiers et la messagerie Exchange utilisent le protocole Netbios sur le port TCP 139. Par ailleurs, les serveurs WINS s’échangent des données sur le port TCP 42.
------------------------------------------------------------------------------------------------
LE POINT SUR TCP (RFC 793)
TCP (Transport Control Protocol) est un protocole de niveau 4 (couche transport) qui permet à deux applications (un client et un serveur) d’échanger des données en leur masquant les mécanismes réseau. Les segments TCP sont transportés dans des paquets IP de type 6 (champ protocole = 6).
TCP offre un service de bout en bout (entre deux entités, quelle que soit leur localisation) en mode connecté (un client doit se connecter à une application serveur). Il utilise pour cela un adressage applicatif basé sur des ports TCP. Chaque application est identifiée par un numéro de port réservé (well known port).
Généralement, le client choisit un numéro de port aléatoire supérieur à 1023 comme port source. Le serveur lui répond sur ce port.
Les bits de contrôle ont la signification suivante :
Des options peuvent être négociées entre entités TCP (champ “ Option ”), par exemple la taille maximale des segments transportés.
La couche TCP assure le contrôle d’erreur et le séquencement des segments (les segments sont remis dans le même ordre que lors de leur émission). La taille de la fenêtre d’émission indique au récepteur le nombre d’octets qu’il pourra à son tour envoyer sans attendre d’acquittement. Elle permet également de demander la retransmission à partir du premier segment en erreur (manquant ou erroné).
La couche TCP mesure le temps écoulé entre l’émission d’un segment et la réception de l’accusé de réception correspondant, et calcule ainsi une moyenne glissante du temps de réponse (Round Trip Time). Elle
utilise l’algorithme de Karn pour déduire la valeur de ses temporisateurs. Ainsi, plus le temps de réponse est long, plus TCP attendra longtemps l’accusé de réception avant de retransmettre. De même, TCP estime le nombre de segments perdus : plus celui-ci augmente, plus la fenêtre d’émission est réduite. Ces mécanismes permettent à TCP de contrôler le flux de données en fonction de l’état du réseau (perte de segments et débits) et donc d’éviter une surcharge du réseau par un nombre croissant de retransmissions devenues inutiles.
Une connexion TCP s’effectue par l’échange des trois segments suivants (three ways handshake) :
Pour gérer la fenêtre glissante, chaque extrémité gère deux fenêtres par connexion, une pour l’émission (cf. schéma ci-dessous) et une autre pour la réception.
L’acquittement TCP est cumulatif : un acquittement de numéro de séquence N signifie que les octets précédents ont bien été reçus.
Nombre d’applications se contentent d’envoyer peu d’octets, voire un seul octet par segment TCP, comme cela est le cas de Telnet (cf. chapitre 10). Sur un réseau non encombré et/ou à haut débit, on peut se permettre d’encapsuler un octet dans un segment TCP puis dans un paquet IP (overhead de 40 octets), de procéder à la même opération pour le caractère en écho, puis de générer deux acquittements, un pour le caractère envoyé et un autre pour le caractère en écho. Mais dans des conditions inverses, cet overhead n’est pas supportable. Ainsi, lorsque TCP constate que les temps de réponse sont longs, il active l’algorithme de Nagle, qui consiste à accumuler les octets pour les envoyer dans un même segment, plutôt que d’envoyer chaque caractère dans des segments individuels. ------------------------------------------------------------------------------------------------
Aucun commentaire:
Enregistrer un commentaire