Les modles
Le modle TCP/IP
1 - Introduction
2 - Description du modle
2.1 - Un modle en 4 couches
2.2 - La couche hte rseau
2.3 - La couche internet
2.4 - La couche transport
2.5 - La couche application
3 - Comparaison avec le modle OSI et critique
3.1 - Comparaison avec le modle OSI
3.2 - Critique
4 - Discussion autour de la documentation
5 - Suivi du document
1 - Introduction
TCP/IP dsigne communment une architecture rseau, mais cet acronyme dsigne en fait 2 protocoles troitement
lis : un protocole de transport, TCP (Transmission Control Protocol) qu'on utilise "par-dessus" un protocole
rseau, IP (Internet Protocol). Ce qu'on entend par "modle TCP/IP", c'est en fait une architecture rseau en 4 couches
dans laquelle les protocoles TCP et IP jouent un rle prdominant, car ils en constituent l'implmentation la plus
courante. Par abus de langage, TCP/IP peut donc dsigner deux choses : le modle TCP/IP et la suite de deux
protocoles
TCP
et
IP.
Le modle TCP/IP, comme nous le verrons plus bas, s'est progressivement impos comme modle de rfrence en lieu
et place du modle OSI. Cela tient tout simplement son histoire. En effet, contrairement au modle OSI, le modle
TCP/IP est n d'une implmentation ; la normalisation est venue ensuite. Cet historique fait toute la particularit de ce
modle,
ses
avantages
et
ses
inconvnients.
L'origine de TCP/IP remonte au rseau ARPANET. ARPANET est un rseau de tlcommunication conu par l'ARPA
(Advanced Research Projects Agency), l'agence de recherche du ministre amricain de la dfense (le DOD :
Department of Defense). Outre la possibilit de connecter des rseaux htrognes, ce rseau devait rsister une
ventuelle guerre nuclaire, contrairement au rseau tlphonique habituellement utilis pour les tlcommunications
mais considr trop vulnrable. Il a alors t convenu qu'ARPANET utiliserait la technologie de commutation par paquet
(mode datagramme), une technologie mergeante promettante. C'est donc dans cet objectif et ce choix technique que
les protocoles TCP et IP furent invents en 1974. L'ARPA signa alors plusieurs contrats avec les constructeurs (BBN
principalement) et l'universit de Berkeley qui dveloppait un Unix pour imposer ce standard, ce qui fut fait.
2 - Description du modle
2.1 - Un modle en 4 couches
Le
modle
TCP/IP
peut
en
effet
tre
dcrit
comme
une
architecture
rseau
couches :
Le modle OSI a t mis ct pour faciliter la comparaison entre les deux modles.
2.2 - La couche hte rseau
Cette couche est assez "trange". En effet, elle semble "regrouper" les couches physique et liaison de donnes du
modle OSI. En fait, cette couche n'a pas vraiment t spcifie ; la seule contrainte de cette couche, c'est de
permettre un hte d'envoyer des paquets IP sur le rseau. L'implmentation de cette couche est laisse libre. De
manire plus concrte, cette implmentation est typique de la technologie utilise sur le rseau local. Par
exemple, beaucoup de rseaux locaux utilisent Ethernet ; Ethernet est une implmentation de la couche hterseau.
2.3 - La couche internet
Cette couche est la cl de vote de l'architecture. Cette couche ralise l'interconnexion des rseaux (htrognes)
distants sans connexion. Son rle est de permettre l'injection de paquets dans n'importe quel rseau et
l'acheminement des ces paquets indpendamment les uns des autres jusqu' destination. Comme aucune
connexion n'est tablie au pralable, les paquets peuvent arriver dans le dsordre ; le contrle de l'ordre de
remise
est
ventuellement
la
tche
des
couches
suprieures.
Du fait du rle imminent de cette couche dans l'acheminement des paquets, le point critique de cette couche est
le routage. C'est en ce sens que l'on peut se permettre de comparer cette couche avec la couche rseau du
modle
OSI.
La
couche
internet
possde
une
implmentation
officielle :
le protocole
IP (Internet
Protocol).
Remarquons que le nom de la couche ("internet") est crit avec un i minuscule, pour la simple et bonne raison
que le mot internet est pris ici au sens large (littralement, "interconnexion de rseaux"), mme si l'Internet
(avec un grand I) utilise cette couche.
2.4 - La couche transport
Son rle est le mme que celui de la couche transport du modle OSI : permettre des entits paires de soutenir
une
conversation.
Officiellement, cette couche n'a que deux implmentations : le protocole TCP (Transmission Control Protocol) et
le protocole UDP (User Datagram Protocol). TCP est un protocole fiable, orient connexion, qui permet
l'acheminement sans erreur de paquets issus d'une machine d'un internet une autre machine du mme internet.
Son rle est de fragmenter le message transmettre de manire pouvoir le faire passer sur la couche internet.
A l'inverse, sur la machine destination, TCP replace dans l'ordre les fragments transmis sur la couche internet
pour reconstruire le message initial. TCP s'occupe galement du contrle de flux de la connexion.
UDP est en revanche un protocole plus simple que TCP : il est non fiable et sans connexion. Son utilisation
prsuppose que l'on n'a pas besoin ni du contrle de flux, ni de la conservation de l'ordre de remise des paquets.
Par exemple, on l'utilise lorsque la couche application se charge de la remise en ordre des messages. On se
souvient que dans le modle OSI, plusieurs couches ont charge la vrification de l'ordre de remise des
messages. C'est l une avantage du modle TCP/IP sur le modle OSI, mais nous y reviendrons plus tard. Une
autre utilisation d'UDP : la transmission de la voix. En effet, l'inversion de 2 phonmes ne gne en rien la
comprhension du message final. De manire plus gnrale, UDP intervient lorsque le temps de remise des
paquets est prdominant.
2.5 - La couche application
Contrairement au modle OSI, c'est la couche immdiatement suprieure la couche transport, tout simplement
parce que les couches prsentation et session sont apparues inutiles. On s'est en effet aperu avec l'usage que les
logiciels rseau n'utilisent que trs rarement ces 2 couches, et finalement, le modle OSI dpouill de ces 2
couches
ressemble
fortement
au
modle
TCP/IP.
Cette couche contient tous les protocoles de haut niveau, comme par exemple Telnet, TFTP (trivial File Transfer
Protocol), SMTP (Simple Mail Transfer Protocol), HTTP (HyperText Transfer Protocol). Le point important pour
cette couche est le choix du protocole de transport utiliser. Par exemple, TFTP (surtout utilis sur rseaux
locaux) utilisera UDP, car on part du principe que les liaisons physiques sont suffisamment fiables et les temps de
transmission suffisamment courts pour qu'il n'y ait pas d'inversion de paquets l'arrive. Ce choix rend TFTP plus
rapide que le protocole FTP qui utilise TCP. A l'inverse, SMTP utilise TCP, car pour la remise du courrier
lectronique, on veut que tous les messages parviennent intgralement et sans erreurs.
Modle
hybride
de
rfrence
C'est finalement ce modle qui sert vritablement de rfrence dans le monde de l'Internet. On a ainsi gard la
plupart des couches de l'OSI (toutes, sauf les couches session et prsentation) car correctement spcifies. En
revanche, ses protocoles n'ont pas eu de succs et on a du coup gard ceux de TCP/IP.
Le modle OSI
1 - Introduction
2 - Les diffrentes couches du modle
2.1 - Les 7 couches
2.2 - La couche physique
2.3 - La couche liaison de donnes
2.4 - La couche rseau
2.5 - Couche transport
2.6 - La couche session
2.7 - La couche prsentation
2.8 - La couche application
3 - Transmission de donnes au travers du modle OSI
4 - Critique du modle OSI
4.1 - Ce n'tait pas le bon moment
4.2 - Ce n'tait pas la bonne technologie
4.3 - Ce n'tait pas la bonne implmentation
4.4 - Ce n'tait pas la bonne politique
5 - L'avenir d'OSI
6 - Discussion autour de la documentation
7 - Suivi du document
1 - Introduction
Les constructeurs informatiques ont propos des architectures rseaux propres leurs quipements. Par exemple, IBM
a propos SNA, DEC a propos DNA... Ces architectures ont toutes le mme dfaut : du fait de leur caractre
propritaire, il n'est pas facile des les interconnecter, moins d'un accord entre constructeurs. Aussi, pour viter la
multiplication des solutions d'interconnexion d'architectures htrognes, l'ISO (International Standards Organisation),
organisme dpendant de l'ONU et compos de 140 organismes nationaux de normalisation, a dvelopp un modle de
rfrence appel modle OSI (Open Systems Interconnection). Ce modle dcrit les concepts utiliss et la dmarche
suivie pour normaliser l'interconnexion de systmes ouverts (un rseau est compos de systmes ouverts lorsque la
modification, l'adjonction ou la suppression d'un de ces systmes ne modifie pas le comportement global du rseau).
Au moment de la conception de ce modle, la prise en compte de l'htrognit des quipements tait fondamentale.
En effet, ce modle devait permettre l'interconnexion avec des systmes htrognes pour des raisons historiques et
conomiques. Il ne devait en outre pas favoriser un fournisseur particulier. Enfin, il devait permettre de s'adapter
l'volution des flux d'informations traiter sans remettre en cause les investissements antrieurs. Cette prise en
compte de l'htrognit ncessite donc l'adoption de rgles communes de communication et de coopration entre les
quipements, c'est dire que ce modle devait logiquement mener une normalisation internationale des protocoles.
Le modle OSI n'est pas une vritable architecture de rseau, car il ne prcise pas rellement les services et les
protocoles utiliser pour chaque couche. Il dcrit plutt ce que doivent faire les couches. Nanmoins, l'ISO a crit ses
propres normes pour chaque couche, et ceci de manire indpendante au modle, i.e. comme le fait tout constructeur.
Les premiers travaux portant sur le modle OSI datent de 1977. Ils ont t bass sur l'exprience acquise en matire
de grands rseaux et de rseaux privs plus petits ; le modle devait en effet tre valable pour tous les types de
rseaux. En 1978, l'ISO propose ce modle sous la norme ISO IS7498. En 1984, 12 constructeurs europens, rejoints
en 1985 par les grands constructeurs amricains, adoptent le standard.
Les
modle
principes
qui
OSI
ont
conduit
comporte
ces
couches
sont
couches :
les
suivants :
une
couche
doit
tre
cre
lorsqu'un
nouveau
niveau
d'abstraction
est
ncessaire,
chaque
couche
a
des
fonctions
bien
dfinies,
- les fonctions de chaque couche doivent tre choisies dans l'objectif de la normalisation internationale des
protocoles,
- les frontires entre couches doivent tre choisies de manire minimiser le flux d'information aux interfaces,
- le nombre de couches doit tre tel qu'il n'y ait pas cohabitation de fonctions trs diffrentes au sein d'une mme
couche
et
que
l'architecture
ne
soit
pas
trop
difficile
matriser.
Les couches basses (1, 2, 3 et 4) sont ncessaires l'acheminement des informations entre les extrmits
concernes et dpendent du support physique. Les couches hautes (5, 6 et 7) sont responsables du traitement de
l'information relative la gestion des changes entre systmes informatiques. Par ailleurs, les couches 1 3
interviennent entre machines voisines, et non entre les machines d'extrmit qui peuvent tre spares par
plusieurs routeurs. Les couches 4 7 sont au contraire des couches qui n'interviennent qu'entre htes distants.
2.2 - La couche physique
La couche physique s'occupe de la transmission des bits de faon brute sur un canal de communication. Cette
couche doit garantir la parfaite transmission des donnes (un bit 1 envoy doit bien tre reu comme bit valant
1). Concrtement, cette couche doit normaliser les caractristiques lectriques (un bit 1 doit tre reprsent par
une tension de 5 V, par exemple), les caractristiques mcaniques (forme des connecteurs, de la topologie...), les
caractristiques fonctionnelles des circuits de donnes et les procdures d'tablissement, de maintien et de
libration
du
circuit
de
donnes.
L'unit d'information typique de cette couche est le bit, reprsent par une certaine diffrence de potentiel.
2.3 - La couche liaison de donnes
Son rle est un rle de "liant" : elle va transformer la couche physique en une liaison a priori exempte d'erreurs
de transmission pour la couche rseau. Elle fractionne les donnes d'entre de l'metteur en trames, transmet ces
trames en squence et gre les trames d'acquittement renvoyes par le rcepteur. Rappelons que pour la couche
physique, les donnes n'ont aucune signification particulire. La couche liaison de donnes doit donc tre capable
de reconnatre les frontires des trames. Cela peut poser quelques problmes, puisque les squences de bits
utilises
pour
cette
reconnaissance
peuvent
apparatre
dans
les
donnes.
La couche liaison de donnes doit tre capable de renvoyer une trame lorsqu'il y a eu un problme sur la ligne de
transmission. De manire gnrale, un rle important de cette couche est la dtection et la correction d'erreurs
intervenues sur la couche physique. Cette couche intgre galement une fonction de contrle de flux pour viter
l'engorgement
du
rcepteur.
L'unit d'information de la couche liaison de donnes est la trame qui est composes de quelques centaines
quelques milliers d'octets maximum.
2.4 - La couche rseau
C'est la couche qui permet de grer le sous-rseau, i.e. le routage des paquets sur ce sous-rseau et
l'interconnexion des diffrents sous-rseaux entre eux. Au moment de sa conception, il faut bien dterminer le
mcanisme de routage et de calcul des tables de routage (tables statiques ou dynamiques...).
La couche rseau contrle galement l'engorgement du sous-rseau. On peut galement y intgrer des fonctions
de
comptabilit
pour
la
facturation
au
volume,
mais
cela
peut
tre
dlicat.
L'unit d'information de la couche rseau est le paquet.
2.5 - Couche transport
Cette couche est responsable du bon acheminement des messages complets au destinataire. Le rle principal de
la couche transport est de prendre les messages de la couche session, de les dcouper s'il le faut en units plus
petites et de les passer la couche rseau, tout en s'assurant que les morceaux arrivent correctement de l'autre
ct. Cette couche effectue donc aussi le rassemblage du message la rception des morceaux.
Cette couche est galement responsable de l'optimisation des ressources du rseau : en toute rigueur, la couche
transport cre une connexion rseau par connexion de transport requise par la couche session, mais cette couche
est capable de crer plusieurs connexions rseau par processus de la couche session pour rpartir les donnes,
par exemple pour amliorer le dbit. A l'inverse, cette couche est capable d'utiliser une seule connexion rseau
pour transporter plusieurs messages la fois grce au multiplexage. Dans tous les cas, tout ceci doit tre
transparent
pour
la
couche
session.
Cette couche est galement responsable du type de service fournir la couche session, et finalement aux
utilisateurs du rseau : service en mode connect ou non, avec ou sans garantie d'ordre de dlivrance, diffusion
du message plusieurs destinataires la fois... Cette couche est donc galement responsable de l'tablissement
et
du
relchement
des
connexions
sur
le
rseau.
Un
des
tous
derniers
rles
voquer
est
le
contrle
de
flux.
C'est l'une des couches les plus importantes, car c'est elle qui fournit le service de base l'utilisateur, et c'est par
ailleurs elle qui gre l'ensemble du processus de connexion, avec toutes les contraintes qui y sont lies.
L'unit d'information de la couche rseau est le message.
2.6 - La couche session
Cette couche organise et synchronise les changes entre tches distantes. Elle ralise le lien entre les adresses
logiques et les adresses physiques des tches rparties. Elle tablit galement une liaison entre deux programmes
d'application devant cooprer et commande leur dialogue (qui doit parler, qui parle...). Dans ce dernier cas, ce
service d'organisation s'appelle la gestion du jeton. La couche session permet aussi d'insrer des points de reprise
dans le flot de donnes de manire pouvoir reprendre le dialogue aprs une panne.
2.7 - La couche prsentation
Cette couche s'intresse la syntaxe et la smantique des donnes transmises : c'est elle qui traite
l'information de manire la rendre compatible entre tches communicantes. Elle va assurer l'indpendance entre
l'utilisateur
et
le
transport
de
l'information.
Typiquement, cette couche peut convertir les donnes, les reformater, les crypter et les compresser.
2.8 - La couche application
Cette couche est le point de contact entre l'utilisateur et le rseau. C'est donc elle qui va apporter l'utilisateur
les services de base offerts par le rseau, comme par exemple le transfert de fichier, la messagerie...
la
couche
session
et
le
mme
processus
recommence.
Les donnes atteignent alors la couche physique qui va effectivement transmettre les donnes au destinataire. A la
rception, le message va remonter les couches et les en-ttes sont progressivement retirs jusqu' atteindre le
processus
rcepteur :
Le concept important est le suivant : il faut considrer que chaque couche est programme comme si elle tait
vraiment horizontale, c'est dire qu'elle dialoguait directement avec sa couche paire rceptrice. Au moment de
dialoguer avec sa couche paire, chaque couche rajoute un en-tte et l'envoie (virtuellement, grce la couche sousjacente) sa couche paire.
David Clark du MIT a mis la thorie suivant quant l'art et la manire de publier une norme au bon moment.
Pour lui, dans le cycle de vie d'une norme, il y a 2 pics principaux d'activit : la recherche effectue dans le
domaine couvert par la norme, et les investissements des industriels pour l'implmentation et la mise en place de
la norme. Ces deux pics sont spars par un creux d'activit qui apparat tre en fait le moment idal pour la
publication de la norme : il n'est ni trop tt par rapport la recherche et on peut donc assurer une certaine
matrise, et il n'est ni trop tard pour les investissements et les industriels sont prts utiliser des capitaux pour
l'implmenter.
Le modle OSI tait idalement plac par rapport la recherche, mais hlas, le modle TCP/IP tait dj en phase
d'investissement prononc (lorsque le modle OSI est sorti, les universits amricaines utilisaient dj largement
TCP/IP avec un certain succs) et les industriels n'ont pas ressenti le besoin d'investir dessus.
4.2 - Ce n'tait pas la bonne technologie
Le modle OSI est peut-tre trop complet et trop complexe. La distance entre l'utilisation concrte
(l'implmentation) et le modle est parfois importante. En effet, peu de programmes peuvent utiliser ou utilisent
mal l'ensemble des 7 couches du modle : les couches session et prsentation sont fort peu utilises et l'inverse
les couches liaison de donnes et rseau sont trs souvent dcoupes en sous-couches tant elles sont complexes.
OSI est en fait trop complexe pour pouvoir tre proprement et efficacement implment. Le comit rdacteur de
la norme a mme du laisser de ct certains points techniques, comme le la scurit et le codage, tant il tait
dlicat de conserver un rle bien dtermin chaque couche ainsi complte. Ce modle est galement redondant
(le contrle de flux et le contrle d'erreur apparaissent pratiquement dans chaque couche). Au niveau de
l'implmentation,
TCP/IP
est
beaucoup
plus
optimis
et
efficace.
La plus grosse critique que l'on peut faire au modle est qu'il n'est pas du tout adapt aux applications de
tlcommunication sur ordinateur ! Certains choix effectus sont en dsaccord avec la faon dont les ordinateurs
et les logiciels communiquent. La norme a en fait fait le choix d'un "systme d'interruptions" pour signaler les
vnements, et sur des langages de programmation de haut niveau, cela est peu ralisable.
4.3 - Ce n'tait pas la bonne implmentation
Cela tient tout simplement du fait que le modle est relativement complexe, et que du coup les premires
implmentations furent relativement lourdes et lentes. A l'inverse, la premire implmentation de TCP/IP dans
l'Unix de l'universit de Berkeley (BSD) tait gratuite et relativement efficace. Historiquement, les gens ont donc
eu une tendance naturelle utiliser TCP/IP.
4.4 - Ce n'tait pas la bonne politique
Le modle OSI a en fait souffert de sa trop forte normalisation. Les efforts d'implmentation du modle taient
surtout
"bureaucratiques"
et
les
gens
ont
peut-tre
vu
a
d'un
mauvaise
oeil.
A l'inverse, TCP/IP est venu d'Unix et a t tout de suite utilis, qui plus est par des centres de recherches et les
universits, c'est--dire les premiers a avoir utilis les rseaux de manire pousse. Le manque de normalisation
de TCP/IP a t contre-balanc par une implmentation rapide et efficace, et une utilisation dans un milieu
propice sa propagation.
5 - L'avenir d'OSI
Au niveau de son utilisation et implmentation, et ce malgr une mise jour du modle en 1994, OSI a clairement
perdu la guerre face TCP/IP. Seuls quelques grands constructeurs dominant conservent le modle mais il est amen
disparatre
d'autant
plus
vite
qu'Internet
(et
donc
TCP/IP)
explose.
Le modle OSI restera cependant encore longtemps dans les mmoires pour plusieurs raisons. C'est d'abord l'un des
premiers grands efforts en matire de normalisation du monde des rseaux. Les constructeurs ont maintenant
tendance faire avec TCP/IP, mais aussi le WAP, l'UMTS etc. ce qu'il devait faire avec OSI, savoir proposer des
normalisations ds le dpart. OSI marquera aussi les mmoires pour une autre raison : mme si c'est TCP/IP qui est
concrtement utilis, les gens ont tendance et utilisent OSI comme le modle rseau de rfrence actuel. En fait,
TCP/IP et OSI ont des structures trs proches, et c'est surtout l'effort de normalisation d'OSI qui a impos cette
"confusion" gnrale entre les 2 modles. On a communment tendance considrer TCP/IP comme l'implmentation
relle de OSI.
Les Rfc
Les Rfc (Requests for Comments) sont des documents officiels spcifiant les diffrentes implmentations,
standardisations, normalisations reprsentant alors la dfinition de TcpIp. Ces documents sont utiliss par Ietf
(Internet Engineering Task Force) ainsi que d'autre organismes de normalisation. Depuis 1969, plus de 3500
documents ont t rdigs. Les Rfc sont classes, selon cinq classifications qui sont obligatoire, recommand,
facultatif, limite, non recommand ainsi que trois niveaux de maturit qui sont standard propos, standard brouillon,
standard internet. Lorsqu'un document est publi, un numro de Rfc lui est attribu et en cas d'volution, un nouveau
document
sera
publi
sous
une
autre
rfrence.
Une Rfc trs intressante relate les divers fonctionnement de toute cette partie administrative. La Rfc 3160 nomm Tao
de l'Ietf traite des sujets tels que le processus de standardisation des Rfcs, les rles des diffrentes organisations, le
fonctionnement
interne
de
l'Ietf
et
etc.
Voici la liste des diffrentes Rfc rfrences sur le site FrameIP.
TAO
Rfc 3160
Rfc 3160-fr
RFC : Un guide pour la participation aux travaux de l'Internet Engineering Task Force
ATM
Rfc 1483
Rfc 2684
Ethernet
Rfc 894
RFC : Un Standard pour la Transmission des Datagrammes IP sur les Rseaux Ethernet
Rfc 894-err
Rfc 3580
RFC : IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
Rfc 3748
PPP
Rfc 1661
Rfc 2153
PPPOE
Rfc 2516
Rfc 2516-fr
PPTP
Rfc 2637
Rfc 2637-fr
IP
Rfc 791
Rfc 791 fr
Rfc 815
Rfc 1071
Rfc 1340
Rfc 1700
Rfc 1349
Rfc 1517
RFC : Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)
Rfc 1518
Rfc 1519
RFC : Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
Rfc 1631
Rfc 1878
Rfc 1918
IPv6
Rfc 2460
Rfc 4302
Rfc 4303
ARP/RARP
Rfc 826
Rfc 5227
Rfc 903
IGMP
Rfc 1112
Rfc 2236
ICMP
Rfc 792
Rfc 792-fr
Rfc 1256
TCP
Rfc 793
Rfc 793-fr
Rfc 896
Rfc 1071
Rfc 1340
Rfc 1323
Rfc 2018
UDP
Rfc 768
Rfc 768-fr
Rfc 1071
Rfc 1340
DHCP
Rfc 951
Rfc 951-fr
Rfc 1497
Rfc 1541
Rfc 1542
Rfc 2131
Rfc 2131-fr
Rfc 2132
Rfc 2132-fr
IPSEC
Rfc 2401
Rfc 2401-fr
Rfc 2402
Rfc 2406
Rfc 2408
Rfc 2409
Rfc 3095
L2TP
Rfc 2661
DNS
Rfc 1033
Rfc 1034
Rfc 1034-fr
Rfc 1035
Rfc 1591
rfc 5358
SIP
Rfc 3261
Rfc 3265
Rfc 3853
S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)
Rfc 4320
Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
Rfc 4916
Rfc 5393
Rfc 2327
RTP
Rfc 3550
Rfc 2032
Rfc 3711
MPLS
Rfc 2547
NNTP
Rfc 977
NTP
Rfc 868
Rfc 1059
Rfc 1119
Rfc 1305
Rfc 4330
SNMP
Rfc 1155
Rfc 1441
Rfc 1901
Rfc 3411
Rfc 3826
RFC : The Advanced Encryption Standard (AES) in the SNMP User-based Security Model
SSL - TLS
draft xxx
draft 302
Rfc 2246
Rfc 3546
Rfc 4366
STUN
Rfc 3489
RFC : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators
(NATs)
Rfc 5389
FTP
Rfc 959
HTTP
Rfc 2616
Rfc 2109
HSRP
Rfc 2281
Divers
Rfc 822
Les enttes
Entte Ethernet
1
2
3
4
5
L'histoire
Dfinition du protocole
CSMA/CD
Structure de l'entte
Dfinition des diffrents champs
5.1 - Prambule
5.2 - SFD
5.3 - Adresse destination
5.4 - Adresse source
5.5 - Ether Type
5.6 - 802.1Q
5.6.1 - Priorit
5.6.2 - CFI
5.6.3 - VLAN ID
5.6.4 - EtherType
5.7 - Donnes
5.8 - FCS
6 - Les types d'quipements
6.1 - Le rpteur (Repeater)
6.2 - Le HUB (Concentrateur)
6.3 - Le commutateur (Switch)
6.4 - Le pont (Bridge)
6.5 - Le routeur (Gateway)
6.6 - Synthse des quipements
7 - Discussion autour de la documentation
8 - Suivi du document
1 - L'histoire
Le premier LAN Ethernet fut conu au milieu des annes 1970 par Robert Metcalfe et son assistant David Boggs. Le
dbit original tait de 2,94 Mbps. Robert Metcalfe tait un membre de la direction de recherche pour Xerox. Il travaillait
au centre de recherche Palo Alto au USA (PARC : Palo Alto Research Center) o certains des premiers PC ont t
construits. Il quitta Xerox en 1979 pour promouvoir l'utilisation du PC (personal computer) et du LAN (Local Areas
Network). Il a russit convaincre les entreprises Digital Equipment, Intel et Xerox de travailler ensemble pour
promouvoir l'Ethernet comme un standard.
Jusqu'au dbut des annes 1990, Ethernet n'tait qu'une technologie parmi d'autres bien d'autres tel que Token Ring
(IEEE 802.5), FDDI (802.7), ATM et etc. La technologie Ethernet a conquis depuis la majeure partie du march. Cela
grce aux point suivants :
Premire
technologie
LAN
haut
dbit
grand
public
Les
autres
technologies
sont
sensiblement
plus
complexes
- Usage d'un protocol entirement dcentralis (CSMA/CD) synonyme de simplicit. Toutes les stations sont
gales
vis--vis
du
rseau,
il
n'y
a
pas
d'quipement
matre
de
contrle
du
rseau
- il est possible de connecter ou retirer une machine du rseau sans perturber le fonctionnement de l'ensemble
- Un cot de l'quipement beaucoup plus faible que ses technologies concurrentes
De plus, Ethernet parat tre en bonne position pour conserver son statut de technologie prdominante pendant encore
de nombreuses annes.
Une RFC spcifique a t crite spcialement pour l'interaction entre Ethernet et un datagramme IP. (Un Erratumest
paru)
2 - Dfinition du protocole
La technologie Ethernet se dcline dans de nombreuses variantes tel que :
Deux
topologies
diffrentes
qui
sont
bus
et
toile
- Multi supports permettant d'tre capable de faire usage de cbles coaxiaux, de fils en cuivre paires torsades
ou
de
fibres
optiques.
- Une Offre d'une large gamme de dbit avec 10 Mbps, 100 Mbps, 1 Gbps et 10 Gbps
L'Ethernet est bas sur un principe de dialogue sans connexion et donc sans fiabilit. Les trames sont envoyes par
l'adaptateur sans aucune procdure de type handshake avec l'adaptateur destinataire. Le service sans connexion
d'Ethernet est galement non-fiable, ce qui signifie qu'aucun acquittement, positif ou ngatif, n'est mis lorsqu'une
trame passe le contrle CRC avec succs ou lorsque celle-ci choue. Cette absence de fiabilit constitue sans doute la
cl de la simplicit et des cots modrs des systmes Ethernet. Ce service de couche 2 du modle OSI est similaire au
service en mode datagramme de couche 3 assur par IP et au service sans connexion de couche 4 d'UDP.
3 - CSMA/CD
Les noeuds d'un rseau LAN Ethernet sont relis les uns aux autres par un canal diffusion. Lorsqu'un adaptateur
transmet une trame, tous les autres adaptateurs la reoivent. Ethernet repose sur un algorithme d'accs multiple
CSMA/CD, signifiant Carrier Sense Multiple Access with Collision Detection C'est un protocole permettant la discussion
sur un rseau de type Ethernet.
Voici les rgles schmatiques du protocole de discussion CSMA/CD :
Les
adaptateurs
peuvent
commencer
transmettre
n'importe
quel
moment
Les
adaptateurs
ne
transmettent
jamais
lorsqu'ils
dtectent
une
activit
sur
le
canal
- Les adaptateurs interrompent leur transmission ds qu'ils dtectent l'activit d'un autre adaptateur au sein du
canal
(dtection
de
collisions)
- Avant de procder la retransmission d'une trame, les adaptateurs patientent pendant une dure alatoire
relativement courte
Voici le fonctionnement dtaill tape par tape du dialogue sur un rseau Ethernet :
1- L'adaptateur Ethernet obtient un datagramme de la couche Rseau. Il prpare alors une trame en ajoutant les
enttes Ethernet avant et aprs ce datagramme. Puis il place cette trame Ethernet dans sa mmoire tampon
2 - Si l'adaptateur Ethernet ne dtecte aucune activit sur le mdia physique, il commence transmettre la trame
prpare. Si le mdia est occup, il se met en attente jusqu' la fin du signal d'nergie (plus 96 fois la dure d'un
bit)
et
commence
alors
la
transmission
de
la
trame
3 - Pendant la transmission, l'adaptateur continu de surveiller qu'il n'y a aucun autre signal en provenance d'un
autre adaptateur. Si c'est le cas, il poursuit la transmission de la trame jusqu'au bout
4 - Si l'adaptateur Ethernet dtecte le dbut d'une autre transmission, il interrompt la sienne et envoie un signal
de
brouillage
de
48
bits
5 - Aprs cette interruption, l'adaptateur entre dans une phase d'attente exponentielle appele "exponential
backoff phase". Aprs la nime collision conscutive au cours de la transmission d'une trame, un adaptateur
choisit de faon alatoire une valeur K dans l'ensemble {0, 1, 2,..., 2m-1}, dans lequel m=min(n,10). Il attend
ensuite K x 512 fois la dure d'un bit, puis revient l'tape 2. Ce tirage alatoire permet d'viter que les deux
adaptateurs transmettent de nouveau ensemble.
Voici les astuces et avantages employs par le protocole CSMA/CD :
- Le rle des signaux de brouillage est d'informer tous les autres adaptateurs des collisions qui se produisent sur
le
mdia
- La norme Ethernet impose des limites la distance entre 2 stations au sein d'un LAN. Cette limite permet de
garantir que si un adaptateur choisit une valeur de K infrieure celle de tous les autres adaptateurs impliqus
dans
une
collision,
il
pourra
transmettre
sa
trame
sans
risquer
une
nouvelle
collision
- L'avantage d'une attente exponentielle est que cela permet de s'adapter au nombre d'adaptateurs impliqus
dans une collision
4 - Structure de l'entte
Voici un exemple d'une trame Ethernet saisie avec Ethereal. Vous trouverez ci-dessous sa structure bas sur 14 octets.
Voici un exemple d'une trame Ethernet 802.1Q saisie avec Ethereal. Vous trouverez ci-dessous sa structure bas sur
18 octets.
- Les trois premiers octets dsignent le constructeur. C'est le l'organisation OUI (Organizationally Unique
Identifier)
grer
par
l'IEEE,
qui
rfrence
ces
correspondances.
- Les trois derniers octets dsignent le numro d'identifiant de la carte, dont la valeur est laisse l'initiative
du constructeur qui possde le prfixe
L'association de l'IEEE et du constructeur assure ainsi l'unicit de l'attribution des numros d'adresse MAC.
5.4 - Adresse source
Ce champ est cod sur 6 octets et reprsente l'adresse MAC (Medium Access Control) de l'adaptateur metteur.
Cette adresse est ce que l'on appelle l'adresse physique d'une carte Ethernet (Hardware address). En fait cette
adresse est divise en deux parties gales :
- Les trois premiers octets dsignent le constructeur. C'est le l'organisation OUI (Organizationally Unique
Identifier)
grer
par
l'IEEE,
qui
rfrence
ces
correspondances.
- Les trois derniers octets dsignent le numro d'identifiant de la carte, dont la valeur est laisse l'initiative
du constructeur qui possde le prfixe
L'association de l'IEEE et du constructeur assure ainsi l'unicit de l'attribution des numros d'adresse MAC.
5.5 - Ether Type
Ce champ est cod sur 2 octets et indique le type de protocole insr dans le champ donne. Voici un extrait des
diffrentes correspondances :
0x6000
0x0609
0x0600
0x0800
0x0806
0x8019
0x8035
0x809B
0x8100
0x86DD - IPv6
DEC
DEC
XNS
IPv4
ARP
Domain
RARP
AppleTalk
802.1Q
Dans le cadre d'une trame VLAN tagg 802.1Q, ce champs doit tre 0x8100 afin de spcifier l'ajout des 4 octets
suivants.
5.6 - 802.1Q
5.6.1 - Priorit
Ce champ est cod sur 3 bits et reprsente une information sur la priorit de la trame. Il y a donc 8 niveaux
o 000 reprsente une priorit basse et 111 une haute.
5.6.2 - CFI
Ce champ est cod sur 1 bit et doit tre marqu 0. CFI (canonical format indicator) est utilis pour des
raisons de compatibilit entre les rseaux Ethernet et les rseaux de type Token ring.
5.6.3 - VLAN ID
Ce champ est cod sur 12 bits et reprsente le numro du VLAN. Il est donc possible d'intgrer la trame dans
1 VLAN parmi 4096 possibilits. La valeur 0 indique qu'il n'y a pas de VLAN, c'est souvent utilise dans le cas
o l'on dsire appliquer une priorit sans avoir besoin de la notion de VLAN.
5.6.4 - EtherType
Ce champ est cod sur 2 octets et indique le type de protocole insr dans le champ donne. Voici un extrait
des diffrentes correspondances :
0x6000
0x0609
DEC
DEC
0x0600
0x0800
0x0806
0x8019
0x8035
0x809B
0x86DD - IPv6
XNS
IPv4
ARP
Domain
RARP
AppleTalk
5.7 - Donnes
Ce champ est cod entre 46 et 1500 octets et contient les donnes de la couche 3. Dans le cas de TCP/IP, c'est ici
que vient se loger le datagramme IP. L'unit de transfert maximale est le MTU (Maximale Transfer Unit) et sa
valeur est classiquement de 1500 octets. Si la taille des donnes est infrieure 46 octets, alors elle devra tre
complte avec des octets de bourrage (padding) et c'est la couche rseau qui sera charge de les liminer.
5.8 - FCS
Ce champ est cod sur 4 octets et reprsente la squence de contrle de trame. Il permet l'adaptateur qui
rceptionnera
cette
trame
de
dtecter
toute
erreur pouvant s'tre glisse au sein de la trame.
Les erreurs binaires sont principalement cres par les variations d'affaiblissement du signal et l'induction
lectromagntique parasite dans les cbles Ethernet ou les cartes d'interface. La valeur de FCS (Frame Check
Sequence) est le rsultat d'un calcul polynomial appel CRC (Cyclic Redundancy Code). A la rception de la trame,
la couche liaison effectue le mme calcul et compare les deux rsultats qui doivent tre gaux afin de valider la
conformit de la trame reue.
Cet quipement agt au niveau 1 du modle OSI. Sa fonction est de rpter un signal lectrique en le rgnrant.
L'avantage est de pouvoir augmenter la distance physique, cependant, l'inconvnient est qu'il rpte aussi le bruit
du fait qu'il n'applique aucun filtre ni contrle.
6.2 - Le HUB (Concentrateur)
Cet quipement agt au niveau 1 du modle OSI. Sa fonction est d'interconnecter plusieurs cartes d'interfaces
ensembles. Ainsi, chaque signal lectrique reu est rediffus sur tous les autres ports du HUB.
Dans le cadre d'un HUB 100Mbps, on obtient un dbit partag de 100Mbps pour l'ensemble de quipement
Ethernet raccord.
6.3 - Le commutateur (Switch)
Cet quipement agt au niveau 2 du modle OSI. Identiquement un HUB, sa fonction est d'interconnecter
plusieurs cartes d'interfaces ensembles. Cependant, lorsqu'il rceptionne une trame, il compare l'adresse MAC de
destination avec sa table de correspondance. Ainsi, il ne diffuse cette trame uniquement sur le port physique
concern.
Dans le cadre d'un Switch 100Mbps, on obtient un dbit ddi de 100Mbps par quipement Ethernet raccord. les
caractristiques principales vrifier lors de la slection d'un Switch sont :
Le
nombre
d'adresse
MAC
maximum
qui
peuvent
mise
- Le nombre de paquet par seconde (PPS) que la matrice de fond de panier peux commuter
en
mmoire
Cet quipement agt au niveau 2 du modle OSI. Il permet d'interconnecter deux rseaux de Liaison diffrente.
Par exemple, on trouvera frquemment des ponts permettant de relier des rseaux :
- Ethernet et Token Ring
Ethernet
et
WIFI
Cet quipement agt au niveau 3 du modle OSI. Il permet de relier plusieurs rseau IP diffrents. Pour cela,
lorsqu'il reoit une trame, il compare l'adresse IP destination du datagramme avec sa table de routage et route ce
datagramme sur l'interface de sortie correspondante.
6.6 - Synthse des quipements
Voici une synthse comparative des diffrents quipements Ethernet :
Entte IP
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Dfinition des diffrents champs
3.1 - Vers
3.2 - IHL
3.3 - Service
3.4 - Longueur totale
3.5 - Identification
3.6 - Flags
3.7 - Position fragment
3.8 - TTL
3.9 - Protocole
3.10 - Checksum
3.11 - Adresse IP source
3.12 - Adresse IP destination
3.13 - Options
3.14 - Bourrage
4 - Discussion autour de la documentation
5 - Suivi du document
1 - Dfinition du protocole IP
IP signifie "Internet Protocol", protocole Internet. Il reprsente le protocole rseau le plus rpandu. Il permet de
dcouper l'information transmettre en paquets, de les adresser, de les transporter indpendamment les uns des
autres et de recomposer le message initial l'arrive. Ce protocole utilise ainsi une technique dite de commutation de
paquets. Il apporte, en comparaison Ipx/Spx et Netbeui, l'adressage en couche 3 qui permet, par exemple, la
fonction
principale
de
routage.
Il est souvent associ un protocole de contrle de la transmission des donnes appel TCP, on parle ainsi du
protocole TCP/IP. Cependant, TCP/IP est un ensemble de protocole dont voici les plus connu.
IP
Internet
Protocol
Couche
3
IP
natif.
- ARP - Address Resolution Protocol - Couche 3 - Rsolution d'adresse IP en adresse MAC.
- RARP - Reverse Address Resolution Protocol - Couche 3 - Rsolution d'adresse MAC en adresse IP.
- ICMP - Internet Control Message Protocol - Couche 3 - Gestion des messages du protocole IP.
- IGMP - Internet Group Management Protocol - Couche 3 - Protocole de gestion de groupe.
TCP
Transmission
Control
Protocol
Couche
4
Transport
en
mode
connect.
UDP
User
Datagram
Protocol
Couche
4
Transport
en
mode
non
connect.
Vous trouverez tous les dtails du protocole IP dans la Rfc 791.
2 - Structure de l'entte
Voici la structure de l'entte IP bas sur 20 octets.
la
liste
des
00 -
01
02
03
04
Non
Non
Non
-
05
06
07
08
09
10
IP
Datagram
IP
Non
Non
Non
Non
ST
-
11 12
diffrent
Non
-
Non
codes.
Rserv
assign
assign
assign
V4
Mode
V6
assign
assign
assign
assign
assign
assign
- 15 - Rserv
13
14
Non
Non
assign
assign
3.2 - IHL
IHL signifie "Internet header lengh". ce champ est cod sur 4 bits et reprsente la longueur en mots de 32 bits de
l'entte IP. Par dfaut, il est gal 5 (20 octets), cependant, avec les options de l'entte IP, il peut tre compris
entre
6
et
15.
Le fait que le codage soit sur 4 bits, la taille maximum de l'entte IP est donc de 15*32bits = 60 octets
3.3 - Service
Le champs service "Type Of Service" est cod sur 8 bits, il permet la gestion d'une qualit de service traite
directement en couche 3 du modle OSI. Cependant, la plupart des quipements de Backbone, ne tiennent pas
compte
de
ce
champ
et
mme
certain
le
rinitialise
0.
Voici
la
composition
du
champ
Service
Vous trouverez tous les dtails du champ Service TOS "Type Of Service" dans la Rfc 1349.
3.3.1 - Priorit
Le champ Priorit "Precedence" est cod sur 3 bits. Il indique la priorit que possde la paquet. Voici les
correspondances
des
diffrentes
combinaisons
:
0
1
2
3
4
5
6
- 7 - 111 - Supervision rseau
000
001
010
011
100
Trs
Supervision
101
110
Routine
Prioritaire
Immdiat
Urgent
urgent
Critique
interconnexion
3.3.2 - Dlai
Le champ Dlai "Delay" est cod sur 1 bit. Il indique l'importance du dlai d'acheminement du paquet. Voici
les
correspondances
des
diffrentes
combinaisons
:
- 1 - Bas
Normal
3.3.3 - Dbit
Le champ Dbit "Throughput" est cod sur 1 bit. Il indique l'importance du dbit achemin. Voici les
correspondances
des
diffrentes
combinaisons
:
- 1 - Haut
Normal
3.3.4 - Fiabilit
Le champ Fiabilit "Reliability" est cod sur 1 bit. Il indique l'importance de la qualit du paquet. Voici les
correspondances
des
diffrentes
combinaisons
:
- 1 - Haute
Normal
3.3.5 - Cot
Le champ Cot "Cost" est cod sur 1 bit. Il indique le cot du paquet. Voici les correspondances des
diffrentes
combinaisons
:
- 1 - Faible
Normal
3.3.6 - MBZ
Le champ MBZ "Must Be Zero" est cod sur 1 bit. Comme son nom l'indique, il doit tre mis 0.
3.4 - Longueur totale
Le champ Longueur totale est cod sur 16 bits et reprsente la longueur du paquet incluant l'entte IP et les Data
associes. La longueur totale est exprime en octets, ceci permettant de spcifier une taille maximum de 2 16 =
65535 octets. La longueur des Data est obtenu par la combinaison des champs IHL et Longueur totale :
Longueur_des_data = Longueur_totale - ( IHL * 4 );
3.5 - Identification
Le champ Identification est cod sur 16 bits et constitue l'identification utilise pour reconstituer les diffrents
fragments. Chaque fragment possde le mme numro d'identification, les enttes IP des fragments sont
identiques
l'exception
des
champs Longueur
totale, Checksum et Position
fragment.
Vous trouverez tous les dtails des mcanismes de fragmentation et de rassemblage dans la Rfc 815.
3.6 - Flags
Le champ Flags est cod sur 3 bits et indique l'tat de la fragmentation. Voici le dtail des diffrents bits
constituant ce champ.
3.6.1 - Reserved
Le premier bit est rserv et positionn 0.
3.6.2 - DF
Appel DF "Don't Fragment", le second bit permet d'indiqu si la fragmentation est autorise. Si un
Datagramme devant tre fragment possde le flag DF 1, alors, il sera alors dtruit.
3.6.3 - MF
Appel MF "More Fragments", le troisime bit indique s'il est 1 que le fragment n'est pas le dernier.
3.7 - Position fragment
Le champ Position fragment est cod sur 13 bits et indique la position du fragment par rapport la premire
trame. Le premier fragment possde donc le champ Position fragment 0.
3.8 - TTL
Le champ TTL (Time To Live) est cod sur 8 bits et indique la dure de vie maximale du paquet. Il reprsente la
dure de vie en seconde du paquet. Si le TTL arrive 0, alors l'quipement qui possde le paquet, le dtruira.
Attention, chaque passage d'un routeur le paquet se verra dcrment de une seconde. De plus, si le paquet
reste en file d'attente d'un routeur plus d'une seconde, alors la dcrmentation sera plus leve. Elle sera gale
au nombre de seconde pass dans cette mme file d'attente. Par dfaut, si les temps de rponse sont corrects,
alors on peut, entre guillemet, en conclure que le Time To Live reprsente le nombre de saut maximum du niveau.
Le but du champ TTL est d'viter de faire circuler des trames en boucle infinie.
3.9 - Protocole
Le champ Protocole est cod sur 8 bits et reprsente le type de Data qui se trouve derrire l'entte IP.
Vous trouverez tous les dtails des types de protocole dans la Rfc 1700 qui remplace dsormais la Rfc 1340.
Voici
la
liste
des
01
02
06
- 17 - 10001 - UDP
protocoles
les
plus
00001
00010
00110
connu
-
:
ICMP
IGMP
TCP
3.10 - Checksum
Le champ Checksum est cod sur 16 bits et reprsente la validit du paquet de la couche 3. Pour pouvoir calculer
le Checksum, il faut positionner le champ du checksum a 0 et ne considrer que l'entte IP. Donc par exemple, si
deux trames ont la mme entte IP (y compris le champ length) et deux enttes ICMP et Data diffrentes (mais
de
mme
longueur),
le
checksum
IP
sera
alors
le
mme.
Voici un exemple de fonction permettant le calcul du checksum IP
unsigned short calcul_du_checksum(bool liberation, unsigned short *data, int taille)
{
unsigned long checksum=0;
// ********************************************************
// Complment 1 de la somme des complment 1 sur 16 bits
// ********************************************************
while(taille>1)
{
if (liberation==TRUE)
liberation_du_jeton(); // Rend la main la fentre principale
checksum=checksum+*data++;
taille=taille-sizeof(unsigned short);
}
if(taille)
checksum=checksum+*(unsigned char*)data;
checksum=(checksum>>16)+(checksum&0xffff);
checksum=checksum+(checksum>>16);
return (unsigned short)(~checksum);
}
Vous
trouverez
tous
les
dtails
du
Checksum
IP
dans
la Rfc
1071.
Tous les quipements de niveau 3, tel que les routeurs, devront recalculer le Checksum, car il dcrmente le
champs TTL. De plus, toutes les fonctions de niveau 3 7, tel que la NAT, le PAT, modifiant le contenu de l'entte
IP ou des Data, devront recalculer le Checksum.
3.11 - Adresse IP source
Le champ IP source est cod sur 32 bits et reprsente l'adresse IP source ou de rponse. Il est cod sur 4 octets
qui forme l'adresse A.B.C.D.
3.13.1 - Copie
Le champ Copie est cod sur 1 bit et indique comment les options doivent tre traites lors de la
fragmentation. Cela signifie que lorsqu'il est positionn 1, il faut recopier les options dans chaque paquet
fragment.
3.13.2 - Classe
Le champ Classe est cod sur 2 bits et indique les diffrentes catgorie d'options existantes. Voici la liste des
diffrentes
classe
possible
:
0
1
2
- 3 - 11 - Non utilis
00
-
01
10
Supervision
Debug
de
Non
et
rseau
utilis
mesures
3.13.3 - Numro
Le champ Numro est cod sur 5 bits et indique les diffrentes options existantes. Voici la liste des diffrents
numros
possibles
par
Classe
:
Classe
- 0 - 00000 - Fin de liste d'option. Utilis si les options ne se terminent pas la fin de l'en-tte
- 1 - 00001 - Pas d'opration. Utilis pour aligner les octets dans une liste
- 2 - 00010 - Restriction de scurit et de gestion. Destin aux applications
3
00011
Routage
lche
dfini
par
la
7
00111
Enregistrement
de
8
01000
Identificateur
de
9
01001
Routage
strict
dfini
par
la
Classe
- 4 - 00100 - Horodatage dans l'Internet.
0,
(bourrage).
d'options.
militaires.
source.
route.
connexion.
source.
2,
3.14 - Bourrage
Le champ Bourrage est de taille variable comprise entre 0 et 7 bits. Il permet de combler le champ option afin
d'obtenir une entte IP multiple de 32 bits. La valeur des bits de bourrage est 0.
Entte Arp
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Dfinition des diffrents champs
3.1 - Hardware type
3.2 - Protocol type
3.3 - Hardware Address Length
3.4 - Protocol Address Length
3.5 - Operation
3.6 - Sender Hardware Address
3.7 - Sender Internet Address
3.8 - Target Hardware Address
3.9 - Target Internet Address
4 - Fonctionnement
4.1 - Arp Request
4.2 - Arp Reply
4.3 - Le cache
4.3.1 - Le cache des htes
4.3.2 - Le cache dans la Rfc
5 - Discussion autour de la documentation
6 - Suivi du document
1 - Dfinition du protocole
Le protocole Arp, signifiant Address Resolution Protocol, fonctionne en couche Internet du modle TCP/IPcorrespondant
la couche 3 du modle Osi. L'objectif de Arp est de permettre la rsolution d'une adresse physique par l'intermdiaire
de l'adresse IP correspondante d'un host distant. Le protocole Arp apporte un mcanisme de translation pour
rsoudre
ce
besoin.
Vous trouverez tous les dtails du protocole Arp dans la RFC 826 "An Ethernet Address Resolution Protocol". Un
complment est sortie en juillet 2008 avec la RFC 5227 "IPv4 Address Conflict Detection".
2 - Structure de l'entte
Voici
l'entte
du
protocole
ARP
dans
le
cadre
spcifique
d'Ip
sur
Ethernet.
01
Ethernet
(10Mb)
[JBP]
Experimental
Ethernet
(3Mb)
[JBP]
Amateur
Radio
AX.25
[PXK]
Proteon
ProNET
Token
Ring
[Doria]
05
Chaos
[GXP]
06
IEEE
802
Networks
[JBP]
07
ARCNET
[JBP]
08
Hyperchannel
[JBP]
09
Lanstar
[TU]
10
Autonet
Short
Address
[MXB1]
11
LocalTalk
[JKR1]
12
LocalNet
(IBM
PCNet
or
SYTEK
LocalNET)
[JXM]
13
Ultra
link
[RXD2]
14
SMDS
[GXC1]
15
Frame
Relay
[AGM]
16
Asynchronous
Transmission
Mode
(ATM)
[JXB2]
17
HDLC
[JBP]
18
Fibre
Channel
[Yakov
Rekhter]
19
Asynchronous
Transmission
Mode
(ATM)
[RFC2225]
20
Serial
Line
[JBP]
21
Asynchronous
Transmission
Mode
(ATM)
[MXB1]
22
MIL-STD-188-220
[Jensen]
23
Metricom
[Stone]
24
IEEE
1394.1995
[Hattig]
25
MAPOS
[Maruyama]
26
Twinaxial
[Pitts]
27
EUI-64
[Fujisawa]
28
HIPARP
[JMP]
29
IP
and
ARP
over
ISO
7816-3
[Guthery]
30
ARPSec
[Etienne]
31
IPsec
tunnel
[RFC3456]
32
InfiniBand
(TM)
[Kashyap]
33
TIA-102
Project
25
Common
Air
Interface
(CAI)
[Anderson]
02
03
04
On remarquera tout particulirement que le numro 1 qui le plus frquents. En effet ces architectures sont
principalement utilises dans les rseaux d'entreprises, Wifi, et Metro.
3.2 - Protocol type
Ce champs indique quel est le type de protocole couche 3 qui utilise Arp. Voici la valeur propre Ip.
- 0x0800 - IP
3.3 - Hardware Address Length
Ce champ correspond la longueur de l'adresse physique. La longueur doit tre prise en octets. Voici des
exemples
de
valeurs
courantes.
- 06 - Ethernet
01
Token
Ring
04
IP
v4
3.5 - Operation
Ce champ permet de connatre la fonction du message et donc son objectif. Voici les diffrentes valeurs possibles.
01
- 02 - Reply [RFC 826]
Request
[RFC
826]
4 - Fonctionnement
Pour envisager une discussion entre deux Host se situant dans le mme Lan, les deux hosts doivent avoir connaissance
des adresses physiques des machines avec lesquelles elles discutent. De ce mcanisme dcoule une table de
conversion contenant la fois les adresses Ip et Mac. L'alimentation de cette table peut s'effectuer de deux manires,
automatique via Arp ou manuelle via l'administrateur. Considrons que ces deux hosts n'ont jamais discut ensemble.
Voici la rponse suite la commande arp -a correspondante ces deux hosts montrant le contenu du cache local.
La machine source ne connaissant pas l'adresse physique de la machine destinatrice, celle-ci va mettre une trame
Broadcast de niveau 2 s'adressant toutes les htes du rseau, comportant sa propre adresse physique et la question
demande. Puis, l'hte de destination va se reconnatre et rpondre en Unicast.
4.1 - Arp Request
La question de type Arp Request se prsente sous cette forme : "Je suis l'hte 00 08 54 0b 21 77, Est-ce que
l'hte possdant l'adresse Ip 192.168.0.1 peut me retourner son adresse physique ?". Voici la traduction de cette
requte
saisie
grce
Ethereal.
Ethereal.
4.3 - Le cache
Voici
la
table
Arp
de
la
machine
192.168.0.1.
l'encontre
de
la
scurit.
La troisime rfrence concerne aussi la rception. Elle se trouve dans le chapitre "An Example:" dont voici
un extrait :
An Example:
----------Let there exist machines X and Y that are on the same 10Mbit
Ethernet cable. They have Ethernet address EA(X) and EA(Y) and
DOD Internet addresses IPA(X) and IPA(Y) . Let the Ethernet type
of Internet be ET(IP). Machine X has just been started, and
sooner or later wants to send an Internet packet to machine Y on
the same cable. X knows that it wants to send to IPA(Y) and
tells the hardware driver (here an Ethernet driver) IPA(Y). The
driver consults the Address Resolution module to convert <ET(IP),
IPA(Y)> into a 48.bit Ethernet address, but because X was just
started, it does not have this information. It throws the
Internet packet away and instead creates an ADDRESS RESOLUTION
packet with
(ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op) = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = don't care
(ar$tpa) = IPA(Y)
and broadcasts this packet to everybody on the cable.
Machine Y gets this packet, and determines that it understands
the hardware type (Ethernet), that it speaks the indicated
protocol (Internet) and that the packet is for it
((ar$tpa)=IPA(Y)). It enters (probably replacing any existing
entry) the information that <ET(IP), IPA(X)> maps to EA(X).
Cette exemple confirme bien la mise en cache systmatique quelque soit l'tat du cache actuel. Traduction
mot mot de la dernire phrase : "Elle crit (remplaant probablement toute entre existante) l'information
qui < ET(ip), des cartes d'cIpa(x) > EA(x)."
Entte Rarp
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Dfinition des diffrents champs
3.1 - Hardware type
3.2 - Protocol type
3.3 - Hardware Address Length
3.4 - Protocol Address Length
3.5 - Operation
3.6 - Sender Hardware Address
3.7 - Sender Internet Address
4
5
6
7
1 - Dfinition du protocole
Le protocole Rarp, signifiant Reverse Address Resolution Protocol, fonctionne en couche Internet du modle
TCP/IPcorrespondant la couche 3 du modle Osi. L'objectif de Rarp est de permettre de rsoudre une adresse IP par
l'intermdiaire de l'adresse physique correspondante d'un host distant. Le protocole Rarp apporte un mcanisme de
translation
pour
rsoudre
ce
besoin.
Vous trouverez tous les dtails du protocole Rarp dans la RFC 903 "A Reverse Address Resolution Protocol".
2 - Structure de l'entte
Voici
l'entte
du
protocole
ARP
dans
le
cadre
spcifique
d'Ip
sur
Ethernet.
Ce champs est plac en premier afin d'indiquer quel est le format de l'entte Arp. Voici les diffrentes valeurs
possibles.
01
Ethernet
(10Mb)
[JBP]
02
Experimental
Ethernet
(3Mb)
[JBP]
03
Amateur
Radio
AX.25
[PXK]
04
Proteon
ProNET
Token
Ring
[Doria]
05
Chaos
[GXP]
06
IEEE
802
Networks
[JBP]
07
ARCNET
[JBP]
08
Hyperchannel
[JBP]
09
Lanstar
[TU]
10
Autonet
Short
Address
[MXB1]
11
LocalTalk
[JKR1]
12
LocalNet
(IBM
PCNet
or
SYTEK
LocalNET)
[JXM]
13
Ultra
link
[RXD2]
14
SMDS
[GXC1]
15
Frame
Relay
[AGM]
16
Asynchronous
Transmission
Mode
(ATM)
[JXB2]
17
HDLC
[JBP]
18
Fibre
Channel
[Yakov
Rekhter]
19
Asynchronous
Transmission
Mode
(ATM)
[RFC2225]
20
Serial
Line
[JBP]
21
Asynchronous
Transmission
Mode
(ATM)
[MXB1]
22
MIL-STD-188-220
[Jensen]
23
Metricom
[Stone]
24
IEEE
1394.1995
[Hattig]
25
MAPOS
[Maruyama]
26
Twinaxial
[Pitts]
27
EUI-64
[Fujisawa]
- 28 - HIPARP [JMP]
3.2 - Protocol type
Ce champs indique quel est le type de protocole couche 3 qui utilise Rarp. Voici la valeur propre Ip.
- 0x0800 - IP
3.3 - Hardware Address Length
Ce champ correspond la longueur de l'adresse physique. La longueur doit tre prise en octets. Voici des
exemples
de
valeurs
courantes.
- 06 - Ethernet
01
Token
Ring
04
IP
v4
3.5 - Operation
Ce champ permet de connatre la fonction du message et donc son objectif. Voici les diffrentes valeurs possibles.
"There
are
two
opcodes:
3
('request
reverse')
and
4
('reply
reverse')."
03
- 04 - Reply [RFC 903]
Request
[RFC
903]
Ce champ indique l'adresse rseau de l'metteur. Dans le cadre spcifique de TCP/IP, cela reprsente l'adresse Ip
de source.
3.8 - Target Hardware Address
Ce champ indique l'adresse physique du destinataire. Dans le cadre spcifique d'Ethernet, cela reprsente
l'adresse Mac destination. Si c'est une demande Arp, alors, ne connaissant justement pas cette adresse, le
champs sera mis 0.
3.9 - Target Internet Address
Ce champ indique l'adresse rseau du destinataire. Dans le cadre spcifique de TCP/IP, cela reprsente l'adresse
Ip de destination.
4 - Fonctionnement
Rarp tant un protocole de niveau 3, il s'appui sur une entte Ethernet 14 octets. On y retrouvera spcifiquement le
flag
"type
de
protocole"
gale
0x8035.
(0x0806
pour
ARP)
5 - Serveur Rarp
Voici RARPD 1.15 qui est un serveur RARP. Fonctionnant sous NT/Win2K. En plus de l'exe, vous y trouverez la source
en C.
/*
RARPD.CPP:
Free software Copyright (c) 1999-2003 Lew Perin
*/
/*
Revision History:
Version Date
Reason
------- -------1.00
10/31/99 Forked from billgpc.cpp.
1.01
11/27/99 Lazy automatic reinitialization of the RARP table when
it has been changed on disk, removal of lots of chatter
from the log and main window.
1.02
1/17/00 Faster retrieval of IP address via qsort/bsearch.
1.03
6/3/00 Bugs in automatic reinitialization, handle usage,
error messages fixed; thanks, Ury Jamshy!
1.04
8/12/00 Fixed recognition of directory with embedded spaces
from command line; thanks, Jiri Medlen!
1.05
9/17/00 Fixed TCP Registry navigation for Windows 2000.
1.06
1/15/01 Made some minor type/constness changes to satisfy
modern C++ compilers. Fixed bug that could
destroy adapterName when excluding subnets.
1.07
5/17/01 In Win2K we now probe devices to see if they're
really there.
1.08
6/18/01 Minor debug logging changes.
1.09
7/23/01 Fixed bug recognizing Registry key for adapter
where one adapter is good and a subsequent one is
*almost* OK.
1.10
12/18/01 In Win2K/XP we now no longer check first for direct
connection to Tcpip in checking for a useful adapter.
1.10.1
3/3/02 We no longer assume a ("useless" non-physical) adapter
will have an Ndi\Interfaces subkey. Temporarily, we
ignore whether a 2K/XP adapter is connected to Tcpip.
1.10.2 3/20/02 Now using new driver version for 2K/XP compatibility.
Delay response slightly in loopback testing.
1.11
4/13/03 Logic for subnet exclusion now considers DHCP-based
Registry subnet parameters too.
1.12
4/20/03 Cleaned up logic for when checkStack() fails.
1.13
4/29/03 Fixed getValue() length bug in getSubnetMask().
1.14
6/6/03 Now require driver version 1.02
1.15
10/12/03 Compute our IP address the Winsock way if the Registry
fails us.
*/
<windows.h>
<process.h>
<wincon.h>
<ctype.h>
<limits.h>
<stdio.h>
<iostream.h>
<strstrea.h>
<fstream.h>
<iomanip.h>
<string.h>
<stdlib.h>
<winioctl.h>
<winsock.h>
<time.h>
"shared.h"
"resource.h"
/*
This class will create a list of pseudo-IP addresses for subnets from a
RARPD command line and return them one by one with the overloaded array
indexing operator, returning zero if you've gone beyond the last one.
*/
class SubnetHolder {
size_t count;
long* subnets;
public:
SubnetHolder() { count = 0; }
~SubnetHolder() { if (count) delete[] subnets; }
void init(char* acmdLine);
long operator[] (size_t a) { return (a < count) ? subnets[a] : 0; }
};
void SubnetHolder::init(char* acmdLine)
{
const char* sentinel = "/XS";
if (count) {
delete[] subnets;
count = 0;
}
for (char* next = acmdLine;
(next = strstr(next, sentinel)) != NULL;
count++) {
next += strlen(sentinel);
long* newSubnets = new long[count + 1];
newSubnets[count] = inet_addr(next);
if (count) {
memcpy(newSubnets, subnets, count * sizeof(long));
delete[] subnets;
}
subnets = newSubnets;
}
}
/*
What OS are we running on? Only NT's acceptable.
*/
enum OSType { W95, WNT };
OSType os = W95;
DWORD osMajorVersion, osMinorVersion;
UINT mbType = MB_APPLMODAL;
HDESK mainWindowDesktop = NULL; // used in NT desktop switching
/*
Navigating the registry:
*/
// Table listing info on legal root keys:
struct {
char* name;
HKEY handle;
} rootKeys[] = {
{ "HKEY_CLASSES_ROOT", HKEY_CLASSES_ROOT },
{ "HKEY_CURRENT_USER", HKEY_CURRENT_USER },
{ "HKEY_LOCAL_MACHINE", HKEY_LOCAL_MACHINE },
{ "HKEY_USERS", HKEY_USERS },
{ "HKEY_DYN_DATA", HKEY_DYN_DATA },
{ NULL, NULL }
};
/*
These are the names of the registry keys we use the most:
*/
char* tcpKeyName = "";
// filled in by configureForOS()
/*
We'll often need to know if a key is a root key because if so we'd better
not close its handle.
*/
BOOL isRootKey(HKEY h)
{
for (int i = 0; rootKeys[i].name != NULL; i++) {
if (rootKeys[i].handle == h) return TRUE;
}
return FALSE;
}
/*
It's impossible to get a handle for a non-root key; you have to start
with its root key and work outward.
*/
HKEY getRootKey(const char* apath)
{
for (int i = 0; rootKeys[i].name != NULL; i++) {
size_t rkiLen = strlen(rootKeys[i].name);
if (!strncmp(apath, rootKeys[i].name, rkiLen)) {
if ((apath[rkiLen] == '\0') || (apath[rkiLen] == '\\')) {
return rootKeys[i].handle;
}
}
}
return NULL;
}
ofstream outFile;
enum {
logLineLen = 500,
// Use this in ostrstreams for listbox string.
msgLen = 500,
// Use this for message boxes.
ObjectNameLen = logLineLen / 2 // Use this for desktop names.
};
/*
If we have two handles to NT desktops, the objects may be the same even
if the handles are different. That's what we test here.
*/
available when things get bad enough for us to put up a message box. So
we devised a scheme that allowed us to switch desktops temporarily back
to the one our main window lives in, and then restore the current input
desktop once the message box is dismissed. If this seems bizarre, consider
that the situation really does arise when the following events
transpire:
- rarpd is launched by its service before anyone logs on and puts its
main window where it can be seen, i.e. in the Winlogon desktop;
- someone logs on before rarpd finishes, so the Default desktop becomes
current and rarpc's main window becomes invisible;
- rarpd learns of something that requires the user's attention and wants
to put up a message box anchored by the main window.
By the way, there's plenty of time for the second event in this sequence
to interpose itself between the first and third when the third is a rarp
failure, i.e. a timeout.
*/
int ourMessageBox(HWND hwnd, char* amsg, UINT atype)
{
int result;
ShowWindow(hwnd, SW_RESTORE);
if (os == WNT) {
HDESK newDesktop = OpenInputDesktop(0, FALSE, DESKTOP_SWITCHDESKTOP);
if (!newDesktop) logLastError(hwnd, "Can't open input desktop");
if (differentObjects(mainWindowDesktop,
GetThreadDesktop(GetCurrentThreadId()))) {
if (!SetThreadDesktop(mainWindowDesktop)) {
logLastError(hwnd, "SetThreadDesktop for main window");
}
}
if ((mainWindowDesktop && newDesktop) &&
differentObjects(mainWindowDesktop, newDesktop)) {
if (SwitchDesktop(mainWindowDesktop)) {
result = MessageBox(hwnd, amsg, "rarpd", atype);
if (!result) logLastError(hwnd, "MessageBox");
if (!SwitchDesktop(newDesktop)) {
logLastError(hwnd, "Couldn't switch back to new desktop");
}
return result;
}
else logLastError(hwnd, "Couldn't switch to old desktop");
} // else fall through
} // end of NT-specific logic
result = MessageBox(hwnd, amsg, "rarpd", atype);
if (!result) logLastError(hwnd, "MessageBox");
return result;
}
/*
Two functions, alert() and fail(), centralize our error messages
and ensure that when an error message goes up on the screen the listbox
is visible so the user has some context for the message. A third,
yesOrNo(), does something similar when the user must decide. These
functions also make sure messages and responses get logged.
*/
/*
Here we've reached a point where we can't go on. This is a convenience
function removing some Windows GUI clutter. For those cases in which
we think it's OK without alarming the user, there's an optional Boolean
allowing this.
*/
void fail(HWND amainWindow, char* amsg, BOOL asilent = FALSE)
{
if (!asilent) ourMessageBox(amainWindow, amsg, MB_ICONSTOP);
logLine(amainWindow, "**Fatal error:");
logLine(amainWindow, amsg);
if (amainWindow) SendMessage(amainWindow, WM_CLOSE, 0, 0);
else exit(-1);
}
/*
Here we need to alert the user to something that might not be fatal.
*/
void alert(HWND amainWindow, char* amsg)
{
ourMessageBox(amainWindow, amsg, MB_ICONEXCLAMATION);
logLine(amainWindow, amsg);
}
/*
Here we need to ask the user a yes-or-no question.
*/
int yesOrNo(HWND amainWindow, char* amsg)
{
int result;
result = ourMessageBox(amainWindow, amsg, MB_YESNO);
logLine(amainWindow, "**Query:");
logLine(amainWindow, amsg);
logLine(amainWindow, ((result == IDYES) ? "[yes]" : "[no]"));
return result;
}
/*
This class will create a list RARP table entries from rarpd.tbl
and return pointers to them one by one with the overloaded array
indexing operator, returning NULL if you've gone beyond the last one.
*/
struct RarpTblEntry {
UCHAR macAddress[MacAddressSize];
UINT ipAddress;
};
int rarpTblEntryCmp(const void* aleft, const void* aright)
{
const RarpTblEntry* left = (const RarpTblEntry*)aleft;
const RarpTblEntry* right = (const RarpTblEntry*)aright;
return memcmp(left->macAddress, right->macAddress, MacAddressSize);
}
/*
Our RARP table class encapsulates a lazy reinitialization behavior in
response to the table having changed on disk. We only consider
reinitializing the table when the caller is accessing the first entry
in the table; then we check the file only if it has been at least a
minute since the last check. We reinitialize then if the file has been
written since the last initialization.
*/
class RarpTbl {
size_t count;
RarpTblEntry* entries;
HWND mainWindow;
time_t timeOfLastFileCheck;
FILETIME timeOfLastInit;
void considerInit();
public:
RarpTbl(HWND amainWindow) : mainWindow(amainWindow), count(0),
timeOfLastFileCheck(0) {
timeOfLastInit.dwLowDateTime = timeOfLastInit.dwHighDateTime = 0;
init();
}
~RarpTbl() { if (count) delete[] entries; }
void init();
RarpTblEntry* operator[] (size_t a) {
if (a == 0) considerInit();
return (a < count) ? &entries[a] : NULL;
}
RarpTblEntry* find(const unsigned char* akey) {
considerInit();
return (RarpTblEntry*)bsearch(akey, entries, count, sizeof(RarpTblEntry),
rarpTblEntryCmp);
}
};
void RarpTbl::considerInit()
{
time_t now = time(NULL);
if (UINT(now - timeOfLastFileCheck) > 60) {
timeOfLastFileCheck = now;
HANDLE fh = CreateFile("RARPD.TBL", GENERIC_READ,
0, // Not interested if it's being edited
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (fh != INVALID_HANDLE_VALUE) {
FILETIME timeLastWritten;
BOOL gotFileTime = GetFileTime(fh, NULL, NULL, &timeLastWritten);
CloseHandle(fh);
if (gotFileTime) {
if (CompareFileTime(&timeOfLastInit, &timeLastWritten) < 0) init();
}
}
}
}
void RarpTbl::init()
{
GetSystemTimeAsFileTime(&timeOfLastInit);
ifstream inFile("RARPD.TBL", ios::in | ios::nocreate);
logLine(mainWindow, "Initializing RARP table");
if (!inFile.ipfx()) fail(mainWindow, "Can't open RARPD.TBL");
if (count) {
delete[] entries;
count = 0;
}
char buf[200];
for (size_t lineNo = 1; inFile.ipfx(); lineNo++) {
RarpTblEntry next;
next.ipAddress = INADDR_NONE;
inFile.getline(buf, sizeof(buf));
// logLine(mainWindow, buf);
if (!isalnum(buf[0])) continue;
char ipAddr[200];
int digits[MacAddressSize];
if (sscanf(buf, "%02x.%02x.%02x.%02x.%02x.%02x %s",
digits, digits + 1, digits + 2, digits + 3, digits + 4,
digits + 5, ipAddr) == 7) {
for (size_t byteNo = 0; byteNo < MacAddressSize; byteNo++) {
next.macAddress[byteNo] = UCHAR(digits[byteNo]);
}
next.ipAddress = inet_addr(ipAddr);
}
if (next.ipAddress == INADDR_NONE){
strcat(buf, ": bad");
logLine(mainWindow, buf);
continue;
}
RarpTblEntry* newEntries = new RarpTblEntry[count + 1];
memcpy(&newEntries[count], &next, sizeof(RarpTblEntry));
if (count) {
memcpy(newEntries, entries, count * sizeof(RarpTblEntry));
delete[] entries;
}
entries = newEntries;
count++;
}
qsort(entries, count, sizeof(RarpTblEntry), rarpTblEntryCmp);
}
/*
Here, since we know we're running on NT, we do what's necessary to make
ourselves useful should we be running launched by a service before logon.
(This is after all the best way to run rarpd on NT.) We see if we're
already running on the input desktop and, if not, try to seize it. If
we do switch desktops we make sure our window won't be minimized, because
in our experience a minimized window on the NT Winlogon desktop is a dead
duck.
*/
CloseServiceHandle(removeHandle);
}
CloseServiceHandle(srvHandle);
}
if (scmHandle != NULL) CloseServiceHandle(scmHandle);
}
void shutdown()
{
if (os == WNT) disconnectFromNTDriver();
char dateStr[80], timeStr[80];
GetDateFormat(LOCALE_USER_DEFAULT, 0, NULL,
"yyyy'-'MM'-'dd", dateStr, sizeof(dateStr));
GetTimeFormat(LOCALE_USER_DEFAULT, TIME_FORCE24HOURFORMAT, NULL,
"HH':'mm':'ss", timeStr, sizeof(timeStr));
outFile << "rarpd finished " << dateStr << " " << timeStr << endl;
outFile.close();
}
BOOL ctrlHandler(DWORD actrlChar)
{
switch(actrlChar)
{
case CTRL_SHUTDOWN_EVENT:
case CTRL_LOGOFF_EVENT:
shutdown();
return FALSE;
// Quit the program.
default:
break;
}
return TRUE;
// Don't quit.
}
/*
Since we run under two different operating systems, there are some things
we need to set up depending on which one it is. We keep an enumerator
for the OSes we tolerate.
*/
DWORD transportValueType = REG_SZ;
char* subnetMaskString = "IPMask";
char* dhcpSubnetMaskString = "DhcpIPMask";
void configureForOS(int& acmdShow)
{
char* msgBuf = new char[logLineLen];
ostrstream msgOss(msgBuf, logLineLen);
char* osString = "";
OSVERSIONINFO vinfo;
vinfo.dwOSVersionInfoSize = sizeof(vinfo);
GetVersionEx(&vinfo);
osMajorVersion = vinfo.dwMajorVersion;
osMinorVersion = vinfo.dwMinorVersion;
switch(vinfo.dwPlatformId) {
case VER_PLATFORM_WIN32_NT:
os = WNT;
osString = "NT";
tcpKeyName = "HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\"
"Services\\Tcpip\\Parameters";
transportValueType = REG_MULTI_SZ;
subnetMaskString = "SubnetMask";
dhcpSubnetMaskString = "DhcpSubnetMask";
setNTDesktop(acmdShow, vinfo);
#if 0 // Control handler doesn't get called at system shutdown: why??
if (!SetConsoleCtrlHandler((PHANDLER_ROUTINE)ctrlHandler, TRUE)) {
fail(0, "Can't install shutdown handler");
}
#endif
connectToNTDriver();
break;
default:
fail(0, "This program requires Windows NT");
break;
}
msgOss << "Running under Windows " << osString << " "
<< osMajorVersion << "." << osMinorVersion << "." << ends;
logLine(0, msgBuf);
}
/*
Here we can't proceed because a registry key we need doesn't exist.
*/
void abortOnBadKey(const char* apath, HWND amainWindow)
{
char* msgBuf = new char[logLineLen];
ostrstream msgOss(msgBuf, logLineLen);
msgOss << "Can't find key" << endl
<< " " << apath << endl
<< "in registry.\n"
<< "Make sure Microsoft TCP/IP is properly installed"
<< " and that you have Registry write access for IP."
<< ends;
fail(amainWindow, msgBuf);
}
/*
As we navigate outward from the root to the key we seek, we make sure to
close all intermediate keys. While navigating we ask only read access
but at our destination we want to be able to modify things.
*/
HKEY getKey(const char* apath, HWND amainWindow, BOOL asilent = FALSE)
{
HKEY thisKeyHandle = getRootKey(apath);
if (thisKeyHandle == NULL) abortOnBadKey(apath, amainWindow);
char subKeyName[80];
const char* separatorP = apath + strcspn(apath, "\\");
while (*separatorP) {
const char* nextSubKeyP = separatorP + 1;
size_t subKeyLen = strcspn(nextSubKeyP, "\\");
memcpy(subKeyName, nextSubKeyP, subKeyLen);
subKeyName[subKeyLen] = '\0';
separatorP = nextSubKeyP + subKeyLen;
HKEY nextKeyHandle;
if (RegOpenKeyEx(thisKeyHandle, subKeyName, 0,
KEY_READ,
&nextKeyHandle)!= ERROR_SUCCESS) {
if (!asilent) {
char* msgBuf = new char[logLineLen];
ostrstream msgOss(msgBuf, logLineLen);
msgOss << "Failure on " << apath << " at subkey: " << subKeyName <<
" with read access." << ends;
logLine(amainWindow, msgBuf);
}
RegCloseKey(thisKeyHandle);
return NULL;
}
RegCloseKey(nextKeyHandle);
if (RegOpenKeyEx(thisKeyHandle, subKeyName, 0,
KEY_READ | KEY_SET_VALUE,
&nextKeyHandle)!= ERROR_SUCCESS) {
if (!asilent) {
char* msgBuf = new char[logLineLen];
ostrstream msgOss(msgBuf, logLineLen);
msgOss << "Failure on " << apath << " at subkey: " << subKeyName <<
" with full access." << ends;
logLine(amainWindow, msgBuf);
}
RegCloseKey(thisKeyHandle);
return NULL;
}
if (!isRootKey(thisKeyHandle)) RegCloseKey(thisKeyHandle);
thisKeyHandle = nextKeyHandle;
}
return thisKeyHandle;
}
/*
Sometimes we just need to know if a Registry key exists...
*/
BOOL keyExists(const char* apath, HWND amainWindow)
{
BOOL result = FALSE;
HKEY keyHandle = getKey(apath, amainWindow, TRUE);
if (keyHandle != NULL) {
RegCloseKey(keyHandle);
result = TRUE;
}
return result;
}
/*
If we can find a value corresponding to the key name and expected name,
return TRUE and stow its length. The argument "alength" is used a la
Microsoft, i.e. both as input and output. We don't leave a non-root
key handle open.
*/
BOOL getValue(const char* akeyName, char* anexpectedName, BYTE* abuf,
DWORD& alength, DWORD atype, HWND amainWindow)
{
HKEY keyHandle = getKey(akeyName, amainWindow);
BOOL result = FALSE;
DWORD regType;
// value's type
if (keyHandle == NULL) abortOnBadKey(akeyName, amainWindow);
if (RegQueryValueEx(keyHandle, anexpectedName, NULL,
®Type, abuf, &alength) == ERROR_SUCCESS) {
if (regType == atype) result = TRUE;
else {
size_t bufLen = strlen(anexpectedName) + strlen(akeyName) + 100;
char* msgBuf = new char[bufLen];
ostrstream msgOss(msgBuf, bufLen);
msgOss << "Unexpected value type in registry for" << endl
<< " key: " << akeyName << endl
<< " value name: " << anexpectedName << ends;
alert(amainWindow, msgBuf);
}
}
if (!isRootKey(keyHandle)) RegCloseKey(keyHandle);
return result;
}
/*
The timeout that the receiver thread itself uses to quit on a read from
RARP is made shorter than the one the worker thread uses to kill the
receiver thread by the initialization of ReceiverParams.
*/
struct ReceiverParams {
HWND mainWindow;
DWORD timeout;
UINT ourIpAddress;
BOOL& quiescing;
UCHAR ourMacAddress[MacAddressSize];
USHORT ourHwType;
UCHAR ourHwLen;
RarpTbl& tbl;
ReceiverParams(HWND amainWindow, DWORD atimeout, RarpTbl& atbl,
UINT anipAddress, BOOL& aquiescing) :
mainWindow(amainWindow),
timeout((atimeout > 2000) ? (atimeout - 2000) : 1000 ),
tbl(atbl), ourIpAddress(anipAddress), quiescing(aquiescing) { }
BOOL getntRarpHardwareAddress();
};
struct WorkerParams {
HWND mainWindow;
BOOL dumpDriver;
// dump the driver?
SubnetHolder& excludedSubnets; // Subnets we ignore searching for netcard
DWORD rxTimeout;
// how long we wait for reply (msec.)
char* transportKeyName;
// card-specific TCP transport key name
char* adapterName;
// e.g. "Elnk31"
WorkerParams(HWND amainWindow,
txBuf.ap.hwLen = params.ourHwLen;
txBuf.ap.protLen = 4;
txBuf.ap.op = htons(RarpOpReply);
memcpy(txBuf.ap.senderMacAddress, params.ourMacAddress, MacAddressSize);
txBuf.ap.senderProtAddress = params.ourIpAddress;
while (!params.quiescing) {
OVERLAPPED ovrlp = {0,0,0,0,0};
DWORD bytesReturned;
BOOL gotIt = FALSE;
if ((ovrlp.hEvent = CreateEvent(0, FALSE, 0, NULL)) == 0) {
fail(params.mainWindow, "Windows is out of resources.");
}
else if (ReadFile(ntRarpHandle, &rxBuf, sizeof(RarpBuf),
&bytesReturned, &ovrlp)) gotIt = TRUE;
else if (GetLastError() == ERROR_IO_PENDING) {
while (!gotIt && !params.quiescing) {
if (WaitForSingleObject(ovrlp.hEvent, params.timeout)
== WAIT_OBJECT_0) {
GetOverlappedResult(ntRarpHandle, &ovrlp, &bytesReturned, FALSE);
gotIt = TRUE;
}
}
}
else {
logLastError(params.mainWindow, "Can't read from RARP");
CloseHandle(ovrlp.hEvent);
break;
}
if (gotIt) {
// It's for us.
if (ntohs(rxBuf.ap.op) == RarpOpRequest) {
memcpy(txBuf.ap.targetMacAddress, rxBuf.ap.targetMacAddress,
MacAddressSize);
RarpTblEntry* entryP = params.tbl.find(rxBuf.ap.targetMacAddress);
if (entryP) {
txBuf.ap.targetProtAddress = entryP->ipAddress;
memcpy(txBuf.remoteMacAddress, rxBuf.remoteMacAddress,
MacAddressSize);
if (memcmp(params.ourMacAddress, rxBuf.remoteMacAddress,
MacAddressSize) == 0) { // loopback testing!
Sleep(50);
// Give client time to dump its own request.
}
OVERLAPPED txOvrlp = { 0 };
DWORD bytesSent;
if ((txOvrlp.hEvent = CreateEvent(0, FALSE, 0, NULL)) == 0) {
fail(params.mainWindow, "Can't create event for WriteFile");
}
else if (!WriteFile(ntRarpHandle, &txBuf, sizeof(txBuf),
&bytesSent, &txOvrlp)) {
if (GetLastError() == ERROR_IO_PENDING) {
GetOverlappedResult(ntRarpHandle, &txOvrlp, &bytesSent, TRUE);
}
else logLastError(params.mainWindow, "WriteFile");
}
CloseHandle(txOvrlp.hEvent);
}
}
else if (ntohs(rxBuf.ap.op) != RarpOpReply) {
dump(params.mainWindow, bytesReturned, (UCHAR*)&rxBuf,
"Buffer but not a RARP request");
}
}
CloseHandle(ovrlp.hEvent);
}
_endthread();
}
/*
This function returns the last segments of a Registry key, starting with
the character after the backslash, if there is a backslash. Usually we
just want the last one segment, but we may want more than that.
*/
char* keyNameTail(char* akeyName, int atailSegments = 1)
{
char* p;
for (p = akeyName + strlen(akeyName) - 1; ; p--) {
if (p == akeyName) return p; // no backslash; simple keyname
if ((*p == '\\') && (--atailSegments <= 0)) break;
}
return (p + 1);
}
/*
Here we log everything we wrote to the listbox.
*/
void writeLog(HWND hDlg)
{
enum { lineBufLen = 500 };
char* lineBuf = new char[lineBufLen];
LRESULT lineLen;
for (USHORT lineNo = 0;
(lineLen = SendDlgItemMessage(hDlg, IDC_LOGBOX, LB_GETTEXTLEN,
lineNo, 0)) != LB_ERR;
lineNo++) {
if (lineLen < lineBufLen) {
SendDlgItemMessage(hDlg, IDC_LOGBOX, LB_GETTEXT, lineNo,
(LPARAM)lineBuf);
lineBuf[lineLen] = '\0';
outFile << lineBuf << endl;
}
else outFile << "**Listbox line too long: " << lineLen << endl;
}
delete lineBuf;
}
void WorkerParams::openntRarp()
{
enum { SYSVersionMin = 102, SYSVersionMax = 102 };
if (srvHandle != NULL) {
// Service exists
char rarpDeviceName[80];
wsprintf(rarpDeviceName, "\\\\.\\RARP%s", adapterName);
char openMsg[120];
wsprintf(openMsg, "Opening %s", rarpDeviceName);
logLine(mainWindow, openMsg);
ntRarpHandle = CreateFile(rarpDeviceName,
GENERIC_READ | GENERIC_WRITE, 0, NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED,
NULL);
if (ntRarpHandle != INVALID_HANDLE_VALUE) {
logLine(mainWindow, "Opened RARP device");
UINT sysVersion;
DWORD bytesReturned;
if (DeviceIoControl(ntRarpHandle, DIOC_RarpGetVersion,
NULL, 0, &sysVersion, sizeof(sysVersion),
&bytesReturned, NULL)) {
if ((sysVersion < SYSVersionMin) || (sysVersion > SYSVersionMax)) {
logLine(mainWindow, "Wrong version of RARP.SYS");
CloseHandle(ntRarpHandle);
ntRarpHandle = INVALID_HANDLE_VALUE;
}
else {
char* msgBuf = new char[logLineLen];
ostrstream msgOss(msgBuf, logLineLen);
msgOss << "Using RARP.SYS version " <<
(sysVersion / 100) << "." << setw(2) << setfill('0') <<
(sysVersion % 100) << ends;
logLine(mainWindow, msgBuf);
}
}
else {
logLine(mainWindow, "Can't get version of RARP.SYS");
CloseHandle(ntRarpHandle);
ntRarpHandle = INVALID_HANDLE_VALUE;
}
}
else logLastError(mainWindow, "Opening RARP device");
}
}
/*
Can we find the subnet for this TCP parameters key among those excluded?
*/
long getSubnetMask(char* atcpParamsKeyName, HWND amainWindow)
{
char buf[80];
long addr;
long result = 0;
DWORD addrLength = sizeof(buf), maskLength = sizeof(buf);
if (!getValue(atcpParamsKeyName, "IPAddress", (BYTE*)buf, addrLength,
REG_MULTI_SZ, amainWindow)) {
fail(amainWindow, "No IPAddr for TCP params key");
}
addr = inet_addr(buf);
if (addr != 0) {
// static or BOOTP
logLine(amainWindow, "...static IP"); // ***temp
if (!getValue(atcpParamsKeyName, subnetMaskString, (BYTE*)buf, maskLength,
REG_MULTI_SZ, amainWindow)) {
fail(amainWindow, "No Subnet Mask for TCP params key");
}
result = inet_addr(buf) & addr;
}
else {
// DHCP
addrLength = sizeof(buf);
if (getValue(atcpParamsKeyName, "DhcpIPAddress", (BYTE*)buf, addrLength,
REG_SZ, amainWindow)) {
addr = inet_addr(buf);
logLine(amainWindow, "...DHCP IP"); // ***temp
maskLength = sizeof(buf);
if (!getValue(atcpParamsKeyName, dhcpSubnetMaskString,
(BYTE*)buf, maskLength, REG_SZ, amainWindow)) {
fail(amainWindow, "No DHCP Subnet Mask for TCP params key");
}
result = inet_addr(buf) & addr;
}
}
char maskMsg[80];
// ***temp
in_addr mask;
// ***temp
mask.S_un.S_addr = result; // ***temp
sprintf(maskMsg, "...mask = %s", inet_ntoa(mask)); // ***temp
logLine(amainWindow, maskMsg); // ***temp
return result;
}
BOOL WorkerParams::isSubnetExcluded(char* atcpParamsKeyName)
{
long mask = getSubnetMask(atcpParamsKeyName, mainWindow);
for (size_t subnetNo = 0;
(excludedSubnets[subnetNo]) != 0;
subnetNo++) {
if (excludedSubnets[subnetNo] == mask) {
logLine(mainWindow, "...excluded");
return TRUE;
}
}
return FALSE;
}
/*
Windows NT TCP Registry navigation, pre-NT 5:
The "Bind" value of the Tcpip Linkage key has a series of strings of the
form \Device\adaptername, where if adaptername begins with "NdisWan" it's
a Dial-up pseudo-adapter. We want one entry to remain. If so, that
adapter's Parameters\Tcpip key name is what we return.
While we're at it we also allocate and fill adapterName so we can find
the MAC address later.
The string we return is the caller's responsibility to delete.
*/
char* WorkerParams::findNT4NetcardTCPParams()
{
char* tcpLinkageKeyName = "HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\"
"Services\\Tcpip\\Linkage";
char* srvKeyPrefix = "HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\"
"Services\\";
char* tcpParamSuffix = "\\Parameters\\Tcpip";
DWORD bindBufLen = 1000;
char* bindBuf = new char[bindBufLen];
if (!getValue(tcpLinkageKeyName, "Bind", (BYTE*)bindBuf, bindBufLen,
REG_MULTI_SZ, mainWindow)){
fail(mainWindow, "Registry failure");
}
size_t nTCPKeys = 0;
// Want to end up with 1
char* result = "";
for (CHAR* thisValue = bindBuf;
*thisValue;
thisValue += (strlen(thisValue) + 1)) {
if (strstr(thisValue, "NdisWan")) continue; // Not interested in Dial-up!
char* resultSave = result;
result = new char[strlen(srvKeyPrefix) + strlen(keyNameTail(thisValue)) +
strlen(tcpParamSuffix) + 1];
strcpy(result, srvKeyPrefix);
strcat(result, keyNameTail(thisValue));
strcat(result, tcpParamSuffix);
if (isSubnetExcluded(result)) {
delete[] result;
result = resultSave;
continue;
}
else if (++nTCPKeys > 1) break; // Bail out if more than one!
else {
adapterName = new char[strlen(keyNameTail(thisValue)) + 1];
strcpy(adapterName, keyNameTail(thisValue));
}
}
if (nTCPKeys > 1) fail(mainWindow,
"No unique Registry key for TCP/IP over LAN");
else if (nTCPKeys == 0) fail(mainWindow,
"Can't find Registry key for LAN TCP/IP");
else openntRarp();
delete bindBuf;
return result;
}
/*
In Windows 2000 we resort to the overkill of issuing the MACADDR ioctl
against the actual device because our Registry navigation still can't
eliminate some ghost devices. Probably the poorly documented Setup
API will get us out of that; Win2K ipconfig appears to use it.
*/
BOOL WorkerParams::probeAdapter(char* anadapterName)
{
char queryResult[512];
char deviceName[80];
BOOL result = FALSE;
BOOL createdDevice = FALSE; // resorted to DefineDosDevice?
BOOL foundDevice = BOOL(QueryDosDevice(anadapterName, queryResult,
sizeof(queryResult)));
if ((!foundDevice) && (GetLastError() == ERROR_FILE_NOT_FOUND)) {
strcpy(deviceName, "\\Device\\");
strcat(deviceName, anadapterName);
createdDevice = DefineDosDevice(DDD_RAW_TARGET_PATH, anadapterName,
deviceName);
}
if (foundDevice || createdDevice) {
char macFileName[80];
strcpy(macFileName, "\\\\.\\");
strcat(macFileName, anadapterName);
HANDLE hMAC = CreateFile(macFileName, GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, 0, INVALID_HANDLE_VALUE);
if (hMAC != INVALID_HANDLE_VALUE) {
UCHAR addrData[80];
ULONG ethAddrCode = 0x01010102;
ULONG trAddrCode = 0x02010102;
DWORD returnedCount = DWORD(-1); // impossible value
BOOL ioctlOK = FALSE;
// assume failure
DWORD queryIoctl = CTL_CODE(FILE_DEVICE_PHYSICAL_NETCARD, 0,
METHOD_OUT_DIRECT, FILE_ANY_ACCESS);
if (DeviceIoControl(hMAC, queryIoctl /* IOCTL_NDIS_QUERY_GLOBAL_STATS */,
ðAddrCode, sizeof(ethAddrCode), addrData,
sizeof(addrData), &returnedCount, NULL)) {
ioctlOK = TRUE;
}
else if (DeviceIoControl(hMAC, queryIoctl,
&trAddrCode, sizeof(trAddrCode), addrData,
sizeof(addrData), &returnedCount, NULL)) {
ioctlOK = TRUE;
}
if (ioctlOK && (returnedCount == 6)) result = TRUE;
else logLine(mainWindow, "... couldn't ioctl device"); // ***temp**
if (createdDevice) {
// Get rid of it!
DefineDosDevice(DDD_RAW_TARGET_PATH | DDD_REMOVE_DEFINITION |
DDD_EXACT_MATCH_ON_REMOVE, anadapterName, deviceName);
}
CloseHandle(hMAC);
}
}
else logLine(mainWindow, "... couldn't query or define device"); // ***temp**
if (result) logLine(mainWindow, "...probed OK"); // ***temp***
return result;
}
/*
Windows NT TCP Registry navigation, NT 5:
We're interested in the network adapters enumerated below the key for
the network adapter class, which in NT 5 involves a GUID. For each one,
we're only interested if it's bound above to TCP/IP and below to Ethernet
or Token Ring, and we're only interested if there's one and only one
meeting our criteria. Then computing the keyname is easy after we open
the corresponding RARP device.
*/
char* WorkerParams::findNT5NetcardTCPParams()
{
char* result = "";
char* netcardClassKeyName =
"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\"
"{4D36E972-E325-11CE-BFC1-08002BE10318}";
char* tcpParamsPrefix =
"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\"
"Parameters\\Interfaces\\";
enum { KeyNameBufLen = 1000, ValueBufLen = 1000 };
DWORD valueBufLen;
char* valueBuf = new char[ValueBufLen];
char* keyNameBuf = new char[KeyNameBufLen];
size_t nTCPKeys = 0;
// Want to end up with 1
HKEY netcardClassHandle = getKey(netcardClassKeyName, mainWindow);
if (netcardClassHandle == NULL) {
abortOnBadKey(netcardClassKeyName, mainWindow);
}
for (DWORD adapterNo = 0; ; adapterNo++) {
char netcardSubKeyName[80]; // e.g. "0001"
DWORD netcardSubKeyNameSize = sizeof(netcardSubKeyName);
FILETIME lastUpdate;
LONG rc = RegEnumKeyEx(netcardClassHandle, adapterNo, netcardSubKeyName,
&netcardSubKeyNameSize, NULL, NULL, NULL,
&lastUpdate);
if (rc != ERROR_SUCCESS) break; // No more subkeys.
strcpy(keyNameBuf, netcardClassKeyName);
strcat(keyNameBuf, "\\");
strcat(keyNameBuf, netcardSubKeyName); // e.g. "0000"
logLine(mainWindow, keyNameBuf); // ***temp***
char hostName[200];
if (gethostname(hostName, sizeof(hostName)) == 0) {
struct hostent *phe = gethostbyname(hostName);
if (phe != NULL) {
for (int i = 0; result == 0 && phe->h_addr_list[i] != 0; ++i) {
struct in_addr& ipAddr =
*((struct in_addr*)phe->h_addr_list[i]);
result = ipAddr.s_addr;
}
}
}
WSACleanup();
}
return result;
}
UINT WorkerParams::ourIpAddress()
{
UINT result = 0;
char valueBuf[80];
DWORD valueBufLen1 = sizeof(valueBuf), valueBufLen2 = sizeof(valueBuf);
if (getValue(transportKeyName, "IPAddress", (BYTE*)valueBuf, valueBufLen1,
transportValueType, mainWindow)) {
if ((strlen(valueBuf) != 0) && strcmp(valueBuf, "0.0.0.0")) {
result = inet_addr(valueBuf);
}
}
else if (getValue(transportKeyName, "DhcpIPAddress", (BYTE*)valueBuf,
valueBufLen2, transportValueType, mainWindow)) {
if ((strlen(valueBuf) != 0) && strcmp(valueBuf, "0.0.0.0")) {
result = inet_addr(valueBuf);
}
}
return (result ? result : getWinsockLocalIp()); // 10/12/03
}
/*
Here we check if the machine we're running on really uses the Microsoft
IP stack. We also make sure it isn't set up for DHCP.
*/
BOOL WorkerParams::checkStack()
{
transportKeyName = ((osMajorVersion < 5) ? findNT4NetcardTCPParams() :
findNT5NetcardTCPParams());
return BOOL(transportKeyName[0] != '\0');
}
/*
Diagnostic dump of the driver
*/
void WorkerParams::dumpDriverMemory()
{
if (os == WNT) {
if (ntRarpHandle == INVALID_HANDLE_VALUE) {
fail(mainWindow, "Driver dump requires RARP.SYS");
}
else {
enum { BufSize = 2000 };
BYTE* buf = new BYTE[BufSize];
DWORD bytesReturned;
if (DeviceIoControl(ntRarpHandle, DIOC_RarpDumpDriver,
NULL, 0, buf, BufSize,
&bytesReturned, NULL)) {
dump(mainWindow, bytesReturned, buf, "Driver context:");
}
else logLine(mainWindow, "Can't dump RARP.SYS");
delete buf;
}
}
_endthread();
}
enum { ThreadStackSize = 8192 };
/*
We use _beginthread() and _endthread() rather than the nicer CreateThread()
etc. because Microsoft says using the latter in a program perverse enough
to use the C runtime library causes a memory leak. Whether or not that's
a bug, to ignore the hint would be to punish Microsoft for its
candor. Wouldn't that be the wrong thing to punish them for?
*/
void worker(void* aparams)
{
WorkerParams& params = *((WorkerParams*)aparams);
RarpTbl rarpTbl(params.mainWindow);
if (params.checkStack()) {
if (params.dumpDriver) params.dumpDriverMemory();
ReceiverParams receiverParams(params.mainWindow, params.rxTimeout,
rarpTbl,
params.ourIpAddress(), quiescing);
HANDLE receiverHandle =
HANDLE(_beginthread(rarpReceiver, ThreadStackSize, &receiverParams));
while (!quiescing) Sleep(1000);
logLine(params.mainWindow, "Quiescing...");
WaitForSingleObject(receiverHandle, INFINITE);
}
SendMessage(params.mainWindow, WM_REALLY_CLOSE, 0, 0);
_endthread();
}
int APIENTRY mainDialogProc(HWND hDlg, UINT message, UINT wParam,
LONG lParam)
{
switch (message)
{
case WM_CLOSE:
quiescing = TRUE;
return 1;
case WM_REALLY_CLOSE:
writeLog(hDlg);
EndDialog (hDlg, 0);
DestroyWindow(hDlg);
PostQuitMessage(0);
return 1;
default:
break;
}
return DefWindowProc (hDlg, message, wParam, lParam);
}
/*
Here we set up the GUI. The use of ShowWindow() is probably inept, but
it's the only way I could figure out that would allow the nCmdShow arg
to WinMain() to coerce this program into running minimized if the user
wants it that way. The problem seems to be that nCmdShow is always
the same (SW_SHOWDEFAULT == decimal 10) no matter what the Win95 Shortcut
Run property is. Am I missing something or what?
Another idisyncrasy here is that we disable the Close item on the control
menu if we're running under NT with the NT driver. This is because we
want to be sure any outstanding read gets successfully canceled so the
driver can be dismissed. This isn't appropriate, though, in case we want
the user to see the window and dismiss it only after he's seen enough,
so we make it an option.
*/
BOOL initGUI(HINSTANCE hInstance, HWND& amainWindow, int nCmdShow,
BOOL allowClose)
{
static char appName[] = "RARPD";
WNDCLASS wndclass;
wndclass.style = CS_HREDRAW | CS_VREDRAW;
wndclass.lpfnWndProc = (WNDPROC)mainDialogProc;
wndclass.cbClsExtra = 0;
wndclass.cbWndExtra = DLGWINDOWEXTRA;
wndclass.hInstance = hInstance;
wndclass.hIcon = LoadIcon(hInstance, "ICON_3");
outFile.open("RARPD.LOG",ios::out | ios::app);
}
else outFile.open("RARPD.LOG", ios::out | ios::trunc);
char dateStr[80], timeStr[80];
GetDateFormat(LOCALE_USER_DEFAULT, 0, NULL,
"yyyy'-'MM'-'dd", dateStr, sizeof(dateStr));
GetTimeFormat(LOCALE_USER_DEFAULT, TIME_FORCE24HOURFORMAT, NULL,
"HH':'mm':'ss", timeStr, sizeof(timeStr));
outFile << "rarpd " VERSION " started " << dateStr << " " << timeStr
<< endl;
outFile << "Command line: " << cmdLine << endl;
}
/*
Here we marshall the options entered from the command line. We also
set the current directory to be the one from which the program was loaded.
Originally we set the current directory so we could find the VxD even if
we'd been started from the Registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
This reason became obsolete when RARP.vxd became an NDIS protocol
installed so that it gets loaded by the OS from the system directory,
but we left the logic in because it made rarpd.log much easier to
find when a remote user sent email complaining that the program didn't
work.
*/
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR /* lpCmdLine */, int nCmdShow)
{
ourInstance = hInstance;
HWND mainWindow = 0;
// our main window; 0 means not yet ready
BOOL dumpDriver = FALSE;
// dump the driver?
SubnetHolder excludedSubnets;
char* cmdLine = GetCommandLine();
if ((cmdLine != NULL) && (*cmdLine != '\0')) {
openLog(cmdLine);
strupr(cmdLine);
dumpDriver = BOOL(strstr(cmdLine, "/D") != NULL);
excludedSubnets.init(cmdLine);
}
else {
MessageBox(0, "Can't get command line", "rarpd", MB_ICONSTOP);
exit(-1);
}
configureForOS(nCmdShow); // Do this before any screen I/O!
if ((!hPrevInstance) &&
initGUI(hInstance, mainWindow, nCmdShow, dumpDriver)) {
logLine(mainWindow, "RARPD Version " VERSION);
logLine(mainWindow, "Free software copyright (C) 1996-2003 Lew Perin");
WorkerParams workerParams(mainWindow, dumpDriver,
getTimeout(cmdLine),
excludedSubnets);
_beginthread(worker, ThreadStackSize, &workerParams);
MSG msg;
while (GetMessage(&msg, NULL, 0, 0)) {
if (!IsDialogMessage(mainWindow, &msg)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
}
shutdown();
return 0;
}
Entte ICMP
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Dfinition des diffrents champs
1 - Dfinition du protocole
Le protocole ICMP (Internet Control Message Protocol) permet de grer les informations relatives aux erreurs du
protocole IP. Il ne permet pas de corriger ces erreurs, mais d'en informer les diffrents metteurs des Datagrammes
en erreurs. Chaque pile IP, que ce soit des routeurs ou des stations de travail, grent ICMP par dfaut.
Ce protocole est considr comme faisant partie de l'ensemble des protocoles TCP/IP. Cependant, contrairement TCP
et UDP, il se situe en couche 3 et donc, il est encapsul dans IP. Le mot "Encapsulation" relate clairement la confusion
du
placement
d'ICMP
dans
les
7
couches
OSI.
Les messages d'erreur ICMP sont transports sur le rseau sous forme de Datagramme, comme n'importe quelle
donne. Ainsi, les messages d'erreurs peuvent eux-mmes tre sujet aux erreurs. Toutefois, en cas d'erreur sur un
message ICMP, aucune trame d'erreur n'est dlivre pour viter un effet "boule de neige".
Vous trouverez tous les dtails du protocole ICMP dans la Rfc 792.
2 - Structure de l'entte
Voici
la
structure
de
l'entte
ICMP
bas
sur
octets.
Les deux champs Identifiant et Numro de squence ne sont prsent que dans le cas d'un paquet de type Ping sinon
les champs reste prsent mais en tant que bourrage et donc non utiliss.
Type
Code
Description
Rseau inaccessible
Hte inaccessible
Protocole inaccessible
Port inaccessible
10
11
12
13
14
15
Demande d'cho
Avertissement routeur
10
Sollicitation routeur
11
11
12
En-tte IP invalide
12
12
Mauvaise longueur
13
14
15
16
17
18
{
if (liberation==TRUE)
liberation_du_jeton(); // Rend la main la fentre principale
checksum=checksum+*data++;
taille=taille-sizeof(unsigned short);
}
if(taille)
checksum=checksum+*(unsigned char*)data;
checksum=(checksum>>16)+(checksum&0xffff);
checksum=checksum+(checksum>>16);
return (unsigned short)(~checksum);
}
unsigned short calcul_du_checksum_icmp(bool liberation, struct icmp icmp_tampon,char data_tampon[65535])
{
char tampon[65535];
unsigned short checksum;
// ********************************************************
// Initialisation du checksum
// ********************************************************
icmp_tampon.checksum=0; // Doit tre 0 pour le calcul
// ********************************************************
// Calcul du ICMP
// ********************************************************
memcpy(tampon,(unsigned short *)&icmp_tampon,sizeof(struct icmp));
memcpy(tampon+sizeof(struct icmp),data_tampon,strlen(data_tampon));
checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(struct icmp)+strlen(data_tampon));
return(checksum);
}
3.3 - Identifiant
Le champ identifiant est cod sur 16 bits et dfinit l'identifiant de l'metteur. Pour cela, il est conseill d'assigner
le numro du processus assign (PID) l'application lors de l'excution. Cela permet de le rendre unique inter
application. Cela ressemble beaucoup aux numros de port pour les protocole TCP et UDP.
3.4 - Numro de squence
Le champ Squence est cod sur 16 bits et permet au rcepteur, d'identifier si il manque un paquet. Le plus
classique tant une incrmentation linaire de 1. Ainsi, si le rcepteur reoit la squence 1 puis 3, il peut en
dterminer une perte d'un paquet. Nanmoins, ce n'est pas normalis, donc personne n' la garantie que
l'metteur utilisera cette mthode. Cela peut aussi permettre l'metteur d'envoyer multiples paquets et de
pouvoir distinguer les retours.
Entte IGMP
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Dfinition des diffrents champs
3.1 - Type
3.2 - Temps de rponse max
3.3 - Checksum
3.4 - Adresse du groupe
4 - Discussion autour de la documentation
5 - Suivi du document
1 - Dfinition du protocole
Le protocole IGMP (Internet Group Management Protocol) permet de grer les dclarations d'appartenance un ou
plusieurs groupes auprs des routeurs Multicast. Les inscriptions sont soit spontanes soit aprs requte du routeur.
Pour cela, l'hte envoi une trame IGMP destines ce ou ces groupes. Il existe 2 version du protocole IGMP.
Vous
trouverez
tous
les
dtails
du
protocole
IGMP
version
dans
la Rfc
1112.
Vous trouverez tous les dtails du protocole IGMP version 2 dans la Rfc 2236.
2 - Structure de l'entte
Voici
la
structure
de
l'entte
IGMP
V2
bas
sur
octets.
De la mme manire qu'ICMP, IGMP est un protocole de couche 3. Il est encapsul dans IP afin d'tre vhicul sur un
rseau IP. Le terme "Encapsul" relate pourquoi ce protocole est en couche 3 et non pas en niveau 4.
if (liberation==TRUE)
liberation_du_jeton(); // Rend la main la fentre principale
checksum=checksum+*data++;
taille=taille-sizeof(unsigned short);
}
if(taille)
checksum=checksum+*(unsigned char*)data;
checksum=(checksum>>16)+(checksum&0xffff);
checksum=checksum+(checksum>>16);
return (unsigned short)(~checksum);
}
unsigned short calcul_du_checksum_igmp(bool liberation, struct igmp igmp_tampon,char data_tampon[65535])
{
char tampon[65535];
unsigned short checksum;
// ********************************************************
// Initialisation du checksum
// ********************************************************
igmp_tampon.checksum=0; // Doit tre 0 pour le calcul
// ********************************************************
// Calcul du IGMP
// ********************************************************
memcpy(tampon,(unsigned short *)&igmp_tampon,sizeof(struct igmp));
memcpy(tampon+sizeof(struct igmp),data_tampon,strlen(data_tampon));
checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(struct igmp)+strlen(data_tampon));
return(checksum);
}
3.4 - Adresse du groupe
Le champ Adresse du groupe est cod sur 32 bits et contient une adresse IP. Celle ci reprsente l'adresse du
groupe d'appartenance ou 0 si l'inscription n'a pas encore eu lieu. Le type 11 place ce champ 0 et les autres
types marquent l'IP.
Entte TCP
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Mode de transfert
3.1 - Ouverture de session
3.2 - Transfert des donnes
3.3 - Fermeture de session
3.4 - Fermeture brutale de connexion
4 - La fentre coulissante
5 - Dfinition des diffrents champs
5.1 - Port source
5.2 - Port destination
5.3 - Numro de squence
5.4 - Numro de l'accus de rception
5.5 - Offset
5.6 - Rserv
5.7 - Flags
5.8 - Fentre
5.9 - Checksum
5.10 - Pointeur de donne urgente
5.11 - Options
5.12 - Bourrage
6 - Discussion autour de la documentation
7 - Suivi du document
1 - Dfinition du protocole
Le protocole TCP est bas en couche 4. Il ouvre une session et effectue lui-mme le control d'erreur. Il est alors
appel "mode connect". Vous trouverez tous les dtails du protocole TCP dans la Rfc 793.
2 - Structure de l'entte
Voici
la
structure
de
l'entte
TCP
bas
sur
20
octets.
Voici le complment de l'entte TCP qui est optionnelle bas sur 4 octets.
3 - Mode de transfert
Voici les diffrents types de communication bass sur le mode connect de TCP :
3.1 - Ouverture de session
==>
SYN=1
ACK=0
<==
SYN=1
ACK=1
==> SYN=0 - ACK=1 - SeqNum=101 - AckNum=301
3.2 - Transfert des donnes
SeqNum=100
SeqNum=300
AckNum=xxx
AckNum=101
==>
ACK=1
SeqNum=101
AckNum=301
<==
ACK=1
SeqNum=301
AckNum=131
==>
ACK=1
SeqNum=131
AckNum=311
<== ACK=1 - SeqNum=311 - AckNum=136 - Data=10 octets
Data=30
Data=10
Data=5
octets
octets
octets
SeqNum=321
AckNum=136
cas
==>
<==
ACK=1
ACK=0
2nd
possible
RST=0
RST=1
SeqNum=200
SeqNum=400
cas
<==
ACK=0
RST=0
==> ACK=0 - RST=1 - SeqNum=230 - Data=xxx
:
-
AckNum=400
ACKNum=xxx
possible
-
SeqNum=200
:
-
Data=30
octets
4 - La fentre coulissante
La fentre coulissante, plus connue sous le nom de "Sliding Windows" est employe pour transfrer des donnes entre
les htes. La fentre dfinit le volume de donnes susceptibles d'tre passes via une connexion TCP, avant que le
rcepteur n'envoie un accus de rception. Chaque ordinateur comporte une fentre d'mission et une fentre de
rception qu'il utilise pour buffriser les donnes en continu, sans devoir attendre un accus de rception pour chaque
paquet. Cela permet au rcepteur de recevoir les paquets dans le dsordre et de profiter des dlais d'attente pour
rorganiser les paquets. La fentre mettrice contrle les donnes mises, si elle ne reoit pas d'accus de rception
au bout d'un certain temps, elle retransmet le paquet.
Considrations sur le dbit :
TCP a t conu pour offrir des performances optimales en prsence de conditions de liaison varies et les systmes
d'exploitations comportent des amliorations telles que celles prenant en charge la RFC 1323. Le dbit rel d'une
liaison dpend d'un certain nombre de variables, mais les facteurs les plus importants sont les suivants :
Voici
considrations
fondamentales
sur
le
calcul
du
dbit
TCP
La capacit d'un canal de communication est gale la bande passante multiplie par le temps de transmission allerretour. Elle est connue sous le nom de produit bande passante-retard. Si la liaison est fiable, pour obtenir des
performances optimales, la dimension de la fentre doit tre suprieure ou gale la capacit du canal de
communication, de manire permettre la pile d'envoi de le remplir. La plus grande dimension de fentre pouvant
tre spcifie, en raison du champ de 16 bits de l'en-tte TCP, est de 65535. Des fentres plus larges peuvent toutefois
tre ngocies grce au redimensionnement des fentres.
Le dbit ne peut jamais excder la taille de la fentre divise par le temps de transmission aller-retour. Si la liaison
n'est pas fiable ou est encombre et que des paquets sont perdus, l'utilisation fentre de taille suprieure ne garantit
pas ncessairement un meilleur dbit. Windows 2000 prend en charge non seulement le dimensionnement des
fentres, mais galement les accuss de rception slectifs (SACK, dcrits dans la RFC 2018) pour amliorer les
performances au sein d'environnements qui prsentent des pertes de paquets. Il prend galement en charge
l'horodatage (dcrit dans la RFC 1323) pour une meilleure valuation RTT.
Le retard de propagation dpend de la vitesse de la lumire, des latences de l'quipement de transmission, etc. Le
retard de transmission dpend donc de la vitesse du support.
Pour un parcours spcifique, le retard de propagation est fixe, mais le retard de transmission dpend de la taille du
paquet. des vitesses rduites, le retard de transmission constitue un facteur limitatif. des vitesses leves, le
retard de propagation peut devenir un facteur de limitation.
En rsum, les piles TCP/IP peuvent s'adapter la plupart des conditions de rseau et fournir dynamiquement le
meilleur dbit et la meilleure fiabilit possibles pour chaque connexion. Les essais de mise au point manuelle sont
souvent contre-productifs, sauf lorsqu'un ingnieur rseau qualifi procde pralablement une tude prcise du flux
de donnes.
0.
Le Checksum couvre de plus, une pseudo en-tte de 96 bits prfixe l'en-tte TCP. Cette pseudo en-tte
comporte les adresses Internet sources et destinataires, le type de protocole et la longueur du message TCP
(incluant
la
data).
Ceci
protge
TCP
contre
les
erreurs
de
routage.
La longueur TCP compte le nombre d'octets de l'en-tte TCP et des donnes du message, en excluant les 12
octets
de
la
pseudo
en-tte.
Voici un exemple de fonction permettant le calcul du checksum TCP. Elle est identique celle de UDP.
struct pseudo_entete
{
unsigned long ip_source; // Adresse ip source
unsigned long ip_destination; // Adresse ip destination
char mbz; // Champs 0
char type; // Type de protocole (6->TCP et 17->UDP)
unsigned short length; // htons( Taille de l'entete Pseudo + Entete TCP ou UDP + Data )
};
unsigned short calcul_du_checksum(bool liberation, unsigned short *data, int taille)
{
unsigned long checksum=0;
// ********************************************************
// Complment 1 de la somme des complment 1 sur 16 bits
// ********************************************************
while(taille>1)
{
if (liberation==TRUE)
liberation_du_jeton(); // Rend la main la fentre principale
checksum=checksum+*data++;
taille=taille-sizeof(unsigned short);
}
if(taille)
checksum=checksum+*(unsigned char*)data;
checksum=(checksum>>16)+(checksum&0xffff);
checksum=checksum+(checksum>>16);
return (unsigned short)(~checksum);
}
unsigned short calcul_du_checksum_tcp(bool liberation, unsigned long ip_source_tampon, unsigned long
ip_destination_tampon, struct tcp tcp_tampon, char data_tampon[65535])
{
struct pseudo_entete pseudo_tcp;
char tampon[65535];
unsigned short checksum;
// ********************************************************
// Initialisation du checksum
// ********************************************************
tcp_tampon.checksum=0; // Doit tre 0 pour le calcul
// ********************************************************
// Le calcul du Checksum TCP (Idem UDP)
// ********************************************************
// Le calcul passe par une pseudo entete TCP + l'entete TCP + les Data
pseudo_tcp.ip_source=ip_source_tampon;
pseudo_tcp.ip_destination=ip_destination_tampon;
pseudo_tcp.mbz=0;
pseudo_tcp.type=IPPROTO_TCP;
pseudo_tcp.length=htons((unsigned short)(sizeof(struct tcp)+strlen(data_tampon)));
memcpy(tampon,&pseudo_tcp,sizeof(pseudo_tcp));
memcpy(tampon+sizeof(pseudo_tcp),&tcp_tampon,sizeof(struct tcp));
memcpy(tampon+sizeof(pseudo_tcp)+sizeof(struct tcp),data_tampon,strlen(data_tampon));
checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(pseudo_tcp)+sizeof(struct
tcp)+strlen(data_tampon));
return(checksum);
}
5.10 - Pointeur de donne urgente
Le champ Pointeur de donne urgente est cod sur 16 bits et communique la position d'une donne urgente en
donnant son dcalage par rapport au numro de squence. Le pointeur doit pointer sur l'octet suivant la donne
urgente. Ce champ n'est interprt que lorsque le Flag URG est marqu 1. Ds que cet octet est reu, la pile
TCP doit envoyer les donnes l'application.
5.11 - Options
Les champs d'options peuvent occuper un espace de taille variable la fin de l'en-tte TCP. Ils formeront toujours
un multiple de 8 bits. Toutes les options sont prises en compte par le Checksum. Un paramtre d'option
commence toujours sur un nouvel octet. Il est dfini deux formats types pour les options:
-
Cas
Cas
Octet
de
type
1
d'option,
octet
de
longueur
Option
d'option, octet
de
mono-octet.
valeur d'option.
La longueur d'option prend en compte l'octet de type, l'octet de longueur lui-mme et tous les octets de valeur et
est
exprime
en
octet.
La liste d'option peut tre plus courte que ce que l'offset de donnes pourrait le faire supposer. Un octet de
remplissage "Bourrage" devra tre dans ce cas rajout aprs le code de fin d'options.
5.12 - Bourrage
Le champ Bourrage est de taille variable comprise entre 0 et 7 bits. Il permet de combler le champ option afin
d'obtenir une entte TCP multiple de 32 bits. La valeur des bits de bourrage est 0.
Entte UDP
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Dfinition des diffrents champs
3.1 - Port source
3.2 - Port destination
3.3 - Longueur
3.4 - Checksum
4 - Discussion autour de la documentation
5 - Suivi du document
1 - Dfinition du protocole
Le protocole UDP est bas en couche 4. Il n'ouvre pas de session et n'effectue pas de control d'erreur. Il est alors
appel "mode non connect". Il est donc peut fiable, cependant, il permet aux applications d'accder directement un
service
de
transmission
de
Datagrammes
rapide.
UDP est utilis pour transmettre de faibles quantits de donnes o le cot de la cration de connexions et du
maintient de transmissions fiables s'avrent suprieur aux donnes mettre. UDP peut galement tre utilis pour les
applications satisfaisant un modle de type "interrogation rponse". La rponse tant utilise comme un accus de
rception l'interrogation. On y trouve classiquement Snmp et Dns. UDP est aussi utilis dans un second cas, tel que
la voix sur IP. L'envoi en temps rel est primordiale, donc si une trame n'arrivait pas, la retransmission serait inutile
Vous trouverez tous les dtails du protocole UDP dans la Rfc 768.
2 - Structure de l'entte
Voici
la
structure
de
l'entte
UDP
bas
sur
octets.
0.
Le Checksum couvre de plus, une pseudo en-tte de 96 bits prfixe l'en-tte UDP. Cette pseudo en-tte
comporte les adresses Internet source et destinataires, le type de protocole et la longueur du message UDP. Ceci
protge
UDP
contre
les
erreurs
de
routage.
La longueur UDP compte le nombre d'octets de l'en-tte UDP et des donnes du message, en excluant les 12
octets
de
la
pseudo
en-tte.
Voici un exemple de fonction permettant le calcul du checksum UDP. Elle est identique celle de TCP.
struct pseudo_entete
{
unsigned long ip_source; // Adresse ip source
unsigned long ip_destination; // Adresse ip destination
char mbz; // Champs 0
char type; // Type de protocole (6->TCP et 17->UDP)
unsigned short length; // htons( Taille de l'entete Pseudo + Entete TCP ou UDP + Data )
};
unsigned short calcul_du_checksum(bool liberation, unsigned short *data, int taille)
{
unsigned long checksum=0;
// ********************************************************
// Complment 1 de la somme des complment 1 sur 16 bits
// ********************************************************
while(taille>1)
{
if (liberation==TRUE)
liberation_du_jeton(); // Rend la main la fentre principale
checksum=checksum+*data++;
taille=taille-sizeof(unsigned short);
}
if(taille)
checksum=checksum+*(unsigned char*)data;
checksum=(checksum>>16)+(checksum&0xffff);
checksum=checksum+(checksum>>16);
return (unsigned short)(~checksum);
}
unsigned short calcul_du_checksum_udp(bool liberation, unsigned long ip_source_tampon, unsigned long
ip_destination_tampon, struct udp udp_tampon, char data_tampon[65535])
{
struct pseudo_entete pseudo_udp;
char tampon[65535];
unsigned short checksum;
// ********************************************************
// Initialisation du checksum
// ********************************************************
udp_tampon.checksum=0; // Doit tre 0 pour le calcul
// ********************************************************
Entte IPv6
1 - Dfinition du protocole
2 - Structure de l'entte
3 - Dfinition des diffrents champs
3.1 - Version (Version)
3.2 - Classe (Traffic Class)
3.3 - Label (Flow Label)
3.4 - Longueur (Payload Length)
3.5 - Entte suivante (Next Header)
3.6 - Saut maximum (Hop Limit)
3.7 - Adresse source (Source Address)
3.8 - Adresse destination (Destination Address)
4 - Structure des options de l'entte
4.1 - Sauts aprs sauts (Hop-by-Hop)
4.2 - Routage (Routing)
4.3 - Fragmentation (Fragment)
4.4 - Destination (Destination)
4.5 - AH (Authentication)
4.6 - ESP (Encapsulating Security Payload)
5 - Dfinition des diffrentes champs des Options
5.1 - Sauts aprs sauts (Hop-by-Hop)
5.2 - Routage (Routing)
5.3 - Fragmentation (Fragment)
5.4 - Destination (Destination)
5.5 - AH (Authentication)
5.6 - ESP (Encapsulating Security Payload)
6 - Discussion autour de la documentation
7 - Suivi du document
1 - Dfinition du protocole
Lorsque le protocole Internet IPv4 a t lanc, Internet tait minuscule est relativement priv. Il semblait inimaginable
d'atteindre les prs de 4.300.000 adresses disponibles. Aujourd'hui, Internet est victime de son succs et l'espace
d'adressage d'IPv4 est incapable de rpondre la forte demande d'adresse travers le monde. En effet, personne
n'imaginait l'poque d'utiliser un jour une adresse IP pour tlphoner, jouer, naviguer sur Internet avec un tlphone
portable ou bien un assistant personnel. On compte aujourd'hui plus d'objets intelligents connects que d'tre humain
sur Terre.
C'est cette pnurie d'adresses que doivent faire face aujourd'hui les RIR. Bien sr des solutions ont t dvelopp, ce
qui considrablement ralentit le dploiement industrielle d'IPv6. Voici la liste de ces solutions :
DHCP, Dynamic Host Configuration Protocol, permet d'allouer dynamiquement les adresses seulement quand
les machines sont connectes.
HTTP 1.1, permettant, principalement, d'hberger plusieurs site web avec une seule adresse IP.
NAT, Network Address Translation, permet de rduire le nombre d'adresses publiques utilises en proposant
de raliser grce une fonction de routeur, la translation des adresses prives d'un site.
Cet emploi gnralis des NAT a conduit une complexification de la gestion des rseaux et un alourdissement des
mcanismes de routage. Cela nuit galement au dveloppement d'application Peer to Peer temps rel comme la VoIP.
De plus, associ la scurit et la mobilit, ces services sont des raisons supplmentaires au besoin d'IPv6.
2 - Structure de l'entte
Voici la structure de l'entte IP bas sur 40 octets.
00 -
01
02
03
04
05
Non
Non
Non
-
ST
IP
Datagram
Rserv
assign
assign
assign
V4
Mode
- 15 - Rserv
06
07
08
09
10
IP
V6
assign
assign
assign
assign
assign
assign
assign
assign
Non
Non
Non
Non
11 -
Non
12
13
14
Non
Non
Non
la
- 58 - 00111010 -
liste
des
01
02
06
17
ICMPV6
protocoles
les
plus
connu
00000001
00000010
00000110
00010001
:
ICMP
IGMP
TCP
UDP
60
43
44
51
Option
-
Sauts
Option
Option
Option
Option
aprs
sauts
Destination
Routage
Fragmentation
AH
4.5 - AH (Authentication)
Voici la structure de cette option base sur N octets.
Entte IPv6
Option Sauts aprs sauts
Option Destination
Option Routage
Option Fragmentation
Option AH
Option ESP
Option Destination
Entte de couche suprieure
L'option "Sauts aprs sauts" est utilise pour transporter des informations optionnelles qui doivent tre examines
par chaque noeud le long du chemin emprunt par le paquet. Cette Option est cod 0 et est dfinie par la RFC
2460.
5.1.1 - Entte suivante (Next Header)
Le champ "Entte suivante" est cod sur 8 bits. Il identifie le type de la Data ou de l'option qui se trouve
derrire cette option de l'entte IPv6. tous les dtails sont dans la dfinition du champ "Entte suivante" de
l'entte IPv6 en paragraphe 3.5.
5.1.2 - Longueur (Hdr Ext Len)
Le champ "Longueur" est cod sur 8 bits. Il reprsente la taille de cette Option "Sauts aprs sauts". L'unit
de mesure est les mots de 8 octets sans compter les 8 premiers octets.
5.1.3 - Options (Options)
Le champ "Options" est cod sur N bits. Il contient le contenu de l'option spcifier.
5.2 - Routage (Routing)
L'option de "Routage" est utilise par une source IPv6 pour lister au moins un noeud intermdiaire aller voir sur
le chemin emprunt par le paquet vers la destination. Cette fonction est trs similaire aux options de "Loose
Source" ou "Record Route" de l'entte IPV4. Cette Option est cod 43 et est dfinie par la RFC 2460.
5.2.1 - Entte suivante (Next Header)
Le champ "Entte suivante" est cod sur 8 bits. Il identifie le type de la Data ou de l'option qui se trouve
derrire cette option de l'entte IPv6. tous les dtails sont dans la dfinition du champ "Entte suivante" de
l'entte IPv6 en paragraphe 3.5.
5.2.2 - Longueur (Hdr Ext Len)
Le champ "Longueur" est cod sur 8 bits. Il reprsente la taille de cette Option "Routage". L'unit de mesure
est les mots de 8 octets sans compter les 8 premiers octets.
5.2.3 - Type (Routing Type)
Le champ "Type" est cod sur 8 bits. Il identifie la variante particulire de l'entte de routage.
5.2.4 - Segment (Segments Left)
Le champ "segment" est cod sur 8 bits. Il indique le nombre de segments de chemin restant. C'est dire le
nombre de noeuds intermdiaires lists explicitement qu'il reste traverser avant d'atteindre la destination
finale.
5.1.5 - Donnes (type-specific data)
Le champ "Donnes" est cod sur N bits. Il contient le contenu de l'option spcifier.
5.3 - Fragmentation (Fragment)
L'option de "Fragmentation" est utilise par une source IPv6 pour envoyer un paquet plus large que celui qui
tiendrait dans le MTU vers la destination. Attention, contrairement l'entte IPV4, la fragmentation dans IPv6
n'est ralise que par les noeuds sources et non par les routeurs le long d'un chemin emprunt par le paquet.
Cette Option est cod 44 et est dfinie par la RFC 2460.
5.2.1 - Entte suivante (Next Header)
Le champ "Entte suivante" est cod sur 8 bits. Il identifie le type de la Data ou de l'option qui se trouve
derrire cette option de l'entte IPv6. tous les dtails sont dans la dfinition du champ "Entte suivante" de
l'entte IPv6 en paragraphe 3.5.
Le fonctionnement
La Nat
1 - Introduction
1.1 - Objet de ce cours
1.2 - Rutilisation de ce cours
1.3 - Dcharge
1.4 - Votre travail
2 - Dfinitions
2.1 - L'identification des machines
2.2 - L'adressage IP
2.3 - Qu'est-ce que la NAT ?
3 - La NAT statique
3.1 - Le principe
3.2 - Pourquoi je ne peux pas accder Internet avec une adresse prive ?
3.3 - Le fonctionnement de la NAT statique
3.4 - Avantages et inconvnients de la NAT statique
3.5 - Problmes de routage lis l'utilisation de la NAT statique (proxy ARP)
3.6 - Problmes de routage lis l'utilisation de la NAT statique (routage sur la passerelle)
4 - La NAT dynamique
4.1 - Le principe
4.2 - Le fonctionnement de la NAT dynamique
4.3 - Avantages et inconvnients de la NAT dynamique
4.4 - Problmes lis la NAT dynamique (ICMP)
4.5 - Problmes lis la NAT dynamique (FTP)
5 - Statique ou dynamique ?
5.1 - Quand faire de la NAT statique ?
5.2 - Quand faire de la NAT dynamique ?
5.3 - Puis-je combiner ces deux mthodes ?
6 - Comment rendre joignables les machines de mon rseau local alors que je n'ai qu'une seule adresse publique ?
6.1 - Explication du problme
6.2 - Le port forwarding, qu'est-ce que c'est ?
6.3 - Le port mapping, qu'est-ce que c'est ?
6.4 - Les limites du port forwarding
7 - Les proxys
7.1 - Qu'est-ce qu'un proxy ?
7.2 - Qu'est-ce qu'un proxy n'est pas ?
8 - Vaut-il mieux faire de la NAT ou avoir un proxy ?
8.1 - Avantages du proxy
8.2 - Avantages de la NAT
8.3 - Alors ? NAT ou proxy ?
9 - La scurit et la NAT
9.1 - La NAT dynamique permet-elle d'amliorer ma scurit ?
9.2 - Est-ce utile pour la scurit d'utiliser un proxy ?
9.3 - La NAT est elle compatible avec IPSEC ?
10 - Utilitaires pour faire de la NAT
10.1 - Sous windows
10.2 - Sous Unix
11 - Mini lexique
11.1 - Modle OSI
11.2 - IP
11.3 - TCP
11.4 - SNAT ou Source NAT
11.5 - DNAT ou Destination NAT
12 - Annexes
12.1 - Ressources utilises
12.2 - Remerciements
13 - Conclusion
14 - Discussion autour de la documentation
15 - Suivi du document
1 - Introduction
2 - Dfinitions
2.1 - L'identification des machines
Pour envoyer du courrier un ami, vous utilisez son adresse postale. Ainsi vous tes sr que le paquet que vous
envoyez arrivera la bonne personne. Et bien pour les ordinateurs, c'est pareil. Quand vous connectez votre
ordinateur un rseau (Internet par exemple), il possde une adresse qui l'identifie d'une faon unique pour que
les autres ordinateurs du rseau puissent lui envoyer des informations.
2.2 - L'adressage IP
Nous avons parl d'adresses pour les machines, il est temps maintenant de dfinir ces adresses. On parle
d'adresse IP (Internet protocol), car il s'agit du protocole qui permet d'identifier les machines et de router les
informations sur Internet. Ces adresses sont codes sur 4 octets, soit 32 bits. Ce qui nous permet d'avoir 2^32
adresses disponibles (un peu plus de 4 milliards d'adresses). Mme si ce chiffre dpasse de loin le nombre de
machines prsentes sur Internet, nous allons bientt manquer d'adresses disponibles, notamment parce qu'un
grand nombre de ces adresses sont gches. En attendant un nouveau standard d'adressage qui permette d'avoir
plus d'adresses disponibles (IPv6), il a fallu trouver des solutions temporaires. La NAT a notamment t une
rponse cette future pnurie d'adresses. Nous allons voir en quoi elle consiste, et quels sont ses avantages et
inconvnients.
2.3 - Qu'est-ce que la NAT ?
Le terme barbare NAT reprsente les initiales de "Network Address Translation", ou "Traduction d'Adresse
rticulaire" en franais. Mais il est souvent utilis pour reprsenter diffrents concepts que nous allons
diffrencier, notamment NAT statique, NAT dynamique, PAT, IP masquerading... Si l'on s'en tient intrinsquement
la dfinition du terme NAT, cela reprsente la modification des adresses IP dans l'en-tte d'un datagramme IP
effectue par un routeur. On verra par la suite quelles sont les diffrentes applications possibles. On parlera de
SNAT quand c'est l'adresse source du paquet qui est modifie, et de DNAT quand il s'agit de l'adresse destination.
3 - La NAT statique
3.1 - Le principe
La NAT statique, se base sur l'association de n adresses avec n adresses. C'est dire qu' une adresse IP interne,
on associe une adresse IP externe. Dans ce cas, la seule action qui sera effectue par le routeur sera de
remplacer l'adresse source ou destination par l'adresse correspondante.
3.2 - Pourquoi je ne peux pas accder Internet avec une adresse prive ?
On
prend
l'exemple
Machine
Interface
1
interne
Interface
suivant:
-
routeur
externe
routeur
10.0.0.1/24
|
|
10.0.0.254/24
<ROUTEUR>
193.22.35.42/24
|
|
Internet
La machine 1 veut envoyer un paquet sur Internet, vers www.ohmforce.com, par exemple. Donc dans l'en-tte IP,
l'adresse en destination est celle de www.ohmforce.com, et en source c'est 10.0.0.1. Si jamais il n'y avait pas
de translation d'adresse, le paquet arriverait bien a la machine www.ohmforce.com, mais celle-ci essaierait de
renvoyer sa rponse a 10.0.0.1 qui n'est pas une adresse route sur Internet !! (Elle fait partie d'une classe
d'adresses rserves pour les rseaux privs). Et notre machine 1 n'obtiendrait jamais de rponse... Ainsi, une
machine ayant une adresse prive ne pourra pas recevoir de rponse ses requtes sans un mcanisme
supplmentaire.
3.3 - Le fonctionnement de la NAT statique
Nous avons vu qu'une machine ayant une adresse prive ne pouvait pas dialoguer sur Internet avec celle-ci, donc
pour rsoudre ce problme, on va lui donner une adresse publique virtuelle qui va lui permettre d'accder
Internet. Ainsi, un routeur (la plupart du temps la passerelle d'accs Internet) va modifier dans l'en-tte IP du
paquet l'adresse source 10.0.0.1 pour mettre une adresse valide sur Internet 193.22.35.43 (dans notre exemple).
Le paquet va donc arriver sa destination, et celle-ci va pouvoir le renvoyer 193.22.35.43 qui est une adresse
valide sur Internet. Le paquet va arriver jusqu'au routeur qui a fait l'association entre 193.22.35.43 et 10.0.0.1, il
va donc modifier l'adresse destination 193.22.35.43 et mettre la place 10.0.0.1, et renvoyer le paquet sur le
rseau local. Ainsi, la machine 1 est vue de l'Internet avec l'adresse 193.22.35.43. S'il s'agit d'un serveur web, il
suffit
d'envoyer
une
requte
HTTP
vers
cette
adresse
pour
obtenir
le
site
web.
La NAT statique nous a permis de rendre une machine accessible sur Internet alors qu'elle possdait une adresse
prive. On a simplement fait une association entre une adresse prive et une adresse publique: 10.0.0.1 <-->
193.22.35.43
3.4 - Avantages et inconvnients de la NAT statique
En associant une adresse IP publique une adresse IP prive, nous avons pu rendre une machine accessible sur
Internet. Par contre, on remarque qu'avec ce principe, on est oblig d'avoir une adresse publique par machine
voulant accder Internet. Cela ne va pas rgler notre problme de pnurie d'adresses IP... D'autre part, tant
qu' donner une adresse publique par machine, pourquoi ne pas leur donner cette adresse directement plutt que
de passer par un intermdiaire ? A cette question, on peut apporter plusieurs lments de rponse. D'une part, il
est souvent prfrable de garder un adressage uniforme en interne et de ne pas mler les adresses publiques aux
adresses prives. Ainsi, si on doit faire des modifications, changements, interventions sur le rseau local, on peut
facilement changer la correspondance entre les adresse prives et les adresses publiques pour rediriger les
requtes vers un serveur en tat de marche. D'autre part, on gche un certain nombre d'adresses lorsqu'on
dcoupe un rseau en sous-rseaux (adresse de rseau, adresse de broadcast...), comme lorsqu'on veut crer
une DMZ pour rendre ses serveurs publiques disponibles. Avec la NAT statique, on vite de perdre ces adresses.
Malgr ces quelques avantages, le problme de pnurie d'adresses n'a toujours pas t rgl. Pour cela, on va se
pencher sur la NAT dynamique (Pour ceux qui ne veulent pas rentrer dans les dtails techniques, vous pouvez
directement passer au paragraphe 4)
3.5 - Problmes de routage lis l'utilisation de la NAT statique (proxy ARP)
Les problmes montrs ne sont pas toujours rencontrs lors de l'implmentation de la NAT statique. Si celle-ci est
bien faite, tous les mcanismes dcrits devraient tre implments de faon transparente pour l'utilisateur. Ce qui
va suivre demande d'avoir quelques notions sur le fonctionnement de la pile TCP/IP. Un premier problme
rencontr est celui de la redirection d'un paquet vers l'adresse virtuelle de la NAT statique. On considrera
l'exemple
prcdent
auquel
on
ajoute
le
premier
routeur
rencontr
sur
Internet.
Machine
Interface
1
interne
routeur
10.0.0.1/24
|
|
10.0.0.254/24
Interface
externe
Interface
routeur
<ROUTEUR>
193.22.35.42/24
|
|
193.22.35.254/24
Internet>
externe
|
|
Internet
interne
<Routeur
Interface
La machine 1 fait une requte vers le site www.ohmforce.com. Le paquet est NAT au niveau du routeur avec
comme adresse source 193.22.35.43, ainsi, le site web www.ohmforce.com renvoie sa rponse vers cette
adresse. Le paquet est rout sur Internet et arrive sur le routeur Internet (celui qui prcde le routeur de
l'entreprise ou du particulier). Celui-ci regarde l'adresse de destination et observe qu'elle se situe sur le mme
rseau qu'une de ses interfaces. Ainsi, elle a maintenant besoin de l'adresse MAC de la machine 193.22.35.43
pour lui envoyer le paquet. Elle fait donc une requte ARP en demandant "Quelle est l'adresse MAC de la machine
ayant 193.22.35.43 comme adresse IP ?". Or, sur ce rseau, aucune machine n'a cette adresse puisqu'il s'agit
d'une adresse virtuelle. Il faut donc que le routeur (193.22.35.42) rponde lui-mme cette requte ARP. C'est
ce que l'on appelle faire proxy ARP. Quand vous faites de la NAT statique, le proxy ARP est souvent
automatiquement implment, cependant, il est bon de connatre ce mcanisme si ce n'est pas le cas.
Il y a plusieurs faon de pallier ce problme. Soit mettre en place soit mme un mcanisme de proxy ARP sur la
machine
faisant
la
NAT
statique.
- Soit ajouter une entre statique dans la table ARP du routeur Internet (pas le routeur faisant la NAT, mais
le premier
routeur
rencontr
aprs
celui-ci
sur
Internet).
Commande
arp
sous
windows
:
arp
-s
193.22.35.43
@MAC_routeur
- Soit ajouter une route host statique pour chacune
Route add -p 193.22.35.43 mask 255.255.255.255 193.22.35.42
des
adresses
virtuelles.
Sous
windows:
3.6 - Problmes de routage lis l'utilisation de la NAT statique (routage sur la passerelle)
Un second problme peur survenir sur l'quipement qui fait la NAT. Revenons l'exemple prcdent. Le routeur
Internet envoie le paquet au routeur de l'entreprise. Celui-ci reoit la trame Ethernet, voit que c'est son adresse
MAC qui est en destination, il envoie donc le contenu des donnes la couche IP. Celle-ci voit que c'est l'adresse
192.22.35.43 (l'adresse virtuelle de notre machine) qui est en destination. Il va voir dans la table de routage, et
l, il peut y avoir un problme... Soit une route spcifique existe pour cette adresse pour rediriger le paquet vers
le rseau interne, soit ce n'est pas le cas, et il sera renvoy sur l'interface externe du routeur, vu que l'adresse de
destination appartient au mme rseau que son interface externe 193.22.35.42 !! Pour que la NAT fonctionne, il
faut
donc
qu'il
y
ait
une
route
spcifique
vers
le
rseau
interne.
Dans
notre
cas:
Route
add
-p
193.22.35.43
mask
255.255.255.255
10.0.0.1
Ainsi, quand le routeur recevra un paquet destination de l'adresse virtuelle 193.22.35.43, il le redirigera bien
vers l'adresse relle de la machine, 10.0.0.1. Et hop, a marchera ;-)
4 - La NAT dynamique
4.1 - Le principe
La NAT dynamique est aussi appele IP masquerading. Contrairement la NAT statique, la NAT dynamique
associe une seule adresse n adresses (ou pour tre plus prcis, M adresses N adresses, les adresses pour
sortir tant choisies dans un pool). Ainsi, on peut associer une adresse publique n adresses prives et permettre
ainsi un grand nombre de machines ayant des adresses prives d'accder Internet !! Par contre, nous verrons
que cette mthode possde quelques inconvnients. Et contrairement la NAT statique, le routeur qui effectue la
NAT devra la fois modifier les adresses IP mais aussi les ports TCP/UDP (que l'on appelle PAT, Port Address
Translation).
4.2 - Le fonctionnement de la NAT dynamique
Le fonctionnement est un peu diffrent de celui de la NAT statique. Nous allons notamment voir pourquoi il faut
faire de la PAT et non pas une simple traduction des adresses IP. Reprenons l'exemple prcdent:
Machine
Interface
Interface
interne
externe
1routeur
routeur
10.0.0.1/24
|
|
10.0.0.254/24
<ROUTEUR>
193.22.35.42/24
|
|
Internet
Cette fois, c'est l'adresse publique de l'interface externe du routeur 193.22.35.42 qui va tre utilise pour sortir.
Ainsi, lorsque le paquet arrive la machine de destination, www.ohmforce.com par exemple, celle-ci le renvoie
vers l'adresse 193.22.35.42. Le routeur reoit donc ce paquet et voit que l'adresse de destination est lui-mme !!
Comment peut-il alors savoir si le paquet est pour lui ou une machine en interne ?
C'est grce aux ports TCP/UDP qu'il va pouvoir faire la diffrence. Ainsi, si une machine en interne fait une
requte avec comme port TCP source 2356, le routeur pourra savoir que lorsqu'il recevra un paquet avec comme
port destination 2356, il faut le rediriger vers la machine en interne qui a initialis la connexion. Mais je vois dj
pointer les questions: "oui, mais si deux machines du rseau interne initialisent des connexions avec le mme port
TCP/UDP ?hein ? alors ? comment qu'on fait pour savoir qui est qui ? hein ? alors ?"
Et vous auriez raison de vous les poser ! Mais tout a t prvu pour pallier ce problme. En fait, le routeur
remplace le port TCP/UDP source par un nouveau qu'il choisit lui-mme. Ainsi, comme c'est lui qui les choisit, il
n'en choisira pas deux identiques, et pourra identifier chacune des connexions, magisme... On reprend donc
depuis
le
dbut
le
fonctionnement.
La machine 10.0.0.1 veut se connecter au site www.ohmforce.com, elle envoie donc un paquet avec comme
adresse source la sienne, 10.0.0.1, et comme port source un port quelconque suprieur 1024, soit par exemple
5987. Le paquet arrive au routeur qui fait la NAT, il remplace donc l'adresse IP source par la sienne 193.22.35.42,
et la PAT en remplaant le port TCP/UDP source 5987 par un de son choix, 10000 par exemple. Il garde ces
informations de correspondance bien au chaud dans une table NAT. Le paquet arrive a www.ohmforce.com qui le
renvoie a 193.22.35.42. Le paquet arrive au routeur, il voit que l'adresse destination est lui-mme, il regarde
donc le port destination TCP/UDP qui est 10000. Il va regarder dans la table NAT pour avoir la correspondance, et
bingo !! il sait qu'il faut envoyer ce paquet 10.0.0.1, tout en ayant modifi le port destination 10000 en 5987 qui
est
le
port
sur
lequel
10.0.0.1
a
initialis
la
connexion.
Et voil. On peut ainsi masquer autant de machines que l'on veut derrire une seule adresse publique !
4.3 - Avantages et inconvnients de la NAT dynamique
Comme nous l'avons vu, la NAT dynamique permet des machines ayant des adresses prives d'accder
Internet. Cependant, contrairement la NAT statique, elle ne permet pas d'tre joint par une machine de
l'Internet. Effectivement, si la NAT dynamique marche, c'est parce que le routeur qui fait la NAT reoit les
informations de la machine en interne (Adresse IP, port TCP/UDP). Par contre, il n'aura aucune de ces
informations si la connexion est initialise de l'extrieur... Le paquet arrivera avec comme adresse de destination
le
routeur,
et
le
routeur
ne
saura
pas
vers
qui
rediriger
la
requte
en
interne.
La NAT dynamique ne permet donc que de sortir sur Internet, et non pas d'tre joignable. Elle est donc utile pour
partager un accs Internet, mais pas pour rendre un serveur accessible. De plus, tant donn que l'on peut
"cacher" un grand nombre de machines derrire une seule adresse publique, cela permet de rpondre notre
problme
de
pnurie
d'adresses.
Par contre, les machines n'tant pas accessibles de l'extrieur, cela donne un petit plus au niveau de la scurit ;)
4.4 - Problmes lis la NAT dynamique (ICMP)
La NAT dynamique demande l'utilisation des ports TCP/UDP, cependant, tous les protocoles utiliss sur un rseau
n'utilisent pas obligatoirement ces ports, notamment les protocoles ICMP, PPTP, Netbios... Prenons par exemple le
protocole ICMP. Se limitant la couche 3 il n'utilise pas de ports TCP ou UDP. Il n'est donc pas possible de faire de
la
NAT
dynamique
de
faon
classique.
Une mthode spcifique doit tre implmente pour permettre la NAT du trafic ICMP. Pour cela, au lieu de se
baser sur les ports TCP/UDP, on peut se baser sur l'identifiant ICMP prsent dans l'en-tte du message ICMP.
Ainsi, le mcanisme est exactement le mme, mis part que l'on utilise cet identifiant, plutt que les ports
TCP/UDP. Il faut donc implmenter spcifiquement ce type de NAT pour le protocole ICMP. Par ailleurs, certains
paquets ICMP contiennent dans leur payload des informations concernant les datagrammes IP qui ont caus
l'erreur. Le routeur faisant la NAT doit donc aussi modifier les informations contenues dans le payload pour que
l'information apporte la machine mettrice soit pertinente.
4.5 - Problmes lis la NAT dynamique (FTP)
Le protocole ftp a un fonctionnement un peu particulier. Il utilise deux connexions en parallle. L'une pour le
contrle de la connexion, l'autre pour le transfert des donnes. Le ftp peut fonctionner selon deux modes
diffrents, actif ou passif. En mode passif, pas de problme, les connexions sont initialises de l'intrieur pour
chacun de ces deux canaux. Par contre, pour le mode actif, la connexion de contrle est d abord initialise de l
intrieur, et quand des donnes sont demandes, c'est le serveur qui initialise la connexion de donnes partir de
l'extrieur. Et comme nous le savons, il n'est pas possible d'initialiser de connexions partir de l'extrieur du
rseau avec de la NAT dynamique. Un autre problme du protocole ftp est qu'il contient des donnes se
rapportant aux adresses des machines. Ainsi quand les adresses sont NATes, cela pose problme... Donc pour
que le ftp puisse fonctionner, on est obligs d'utiliser un module qui soit capable de lire les informations contenues
dans les donnes ftp. Pour faire cela, on utilise un proxy (Voir paragraphe 7) qui sera capable de suivre la
connexion
et
de
modifier
les
donnes
ftp
pour
la
rendre
possible.
Dans un cas comme celui-ci, ce n'est plus un simple module NAT ajouter, mais un proxy part entire.
5 - Statique ou dynamique ?
5.1 - Quand faire de la NAT statique ?
Nous avons vu que la NAT statique permettait de rendre disponible une machine sur Internet, mais qu'il fallait par
contre une adresse IP pour que ce serveur soit joignable. Il est donc utile d'utiliser la NAT statique quand vous
voulez rendre une application disponible sur Internet, comme un serveur web, mail ou un serveur FTP.
5.2 - Quand faire de la NAT dynamique ?
La NAT dynamique permet d'une part de donner un accs Internet des machines possdant des adresses
prives, et d'autre part d'apporter un petit plus en terme de scurit. Elle est donc utile pour conomiser les
adresse IP, donner un accs Internet des machines qui n'ont pas besoin d'tre joignables de l'extrieur
(comme la plupart des utilisateurs). D'autre part, mme quand on possde assez d'adresses IP, il est souvent
prfrable de faire de la NAT dynamique pour rendre les machines injoignables directement de l'extrieur. Par
exemple, pour un usage personnel de partage de l'ADSL ou du cble, on utilise souvent la NAT dynamique pour
partager sont accs, tant donn que les machines n'ont pas besoin d'tre jointes de l'extrieur.
5.3 - Puis-je combiner ces deux mthodes ?
Oui, et c'est mme souvent la meilleure solution lorsque l'on a la fois des machines offrant un service, et
d'autres qui n'ont besoin que de se connecter Internet. Ainsi, on conomisera les adresses IP grce aux
machines NATes dynamiquement, et on utilisera exactement le bon nombre d'adresses IP publiques dont on a
besoin. Il est donc trs intressant de combiner ces deux mthodes.
6 - Comment rendre joignables les machines de mon rseau local alors que je n'ai qu'une
seule adresse publique ?
6.1 - Explication du problme
Nous avons vu que dans le cas de la NAT dynamique, les machines du rseau local ne pouvaient pas tre jointes
de l'extrieur. Cela est plutt un plus pour la scurit, mais si on doit offrir des services comme un serveur FTP ou
web, a devient problmatique. C'est notamment le cas quand on possde un accs ADSL ou cble, une seule
adresse publique vous est fournie, et il devient alors compliqu de rendre disponibles plusieurs serveurs du rseau
local.
Une solution ce problme est le port forwarding.
6.2 - Le port forwarding, qu'est-ce que c'est ?
Le port forwarding consiste rediriger un paquet vers une machine prcise en fonction du port de destination de
ce paquet. Ainsi, lorsque l'on n'a qu'une seule adresse publique avec plusieurs machines derrire en adressage
priv. On peut initialiser une connexion de l'extrieur vers l'une de ses machines (une seule par port TCP/UDP).
Prenons l'exemple prcdent et disons que la machine 10.0.0.1 possde un serveur FTP. Maintenant, on configure
le routeur pour qu'il redirige les connexions arrivant sur le port 21 vers la machine 10.0.0.1. Et hop, on rend notre
machine
ayant
une
adresse
prive
disponible
depuis
l'extrieur
!!
Ainsi, le port forwarding nous a permis de rendre nos machines du rseau local joignables d'Internet, mme si l'on
ne possde qu'une seule adresse IP publique !!
6.3 - Le port mapping, qu'est-ce que c'est ?
Le port mapping est un peu quivalent au port forwarding. Il consiste simplement rediriger la requte sur un
port diffrent que celui demand. Par exemple, si on fait tourner un serveur web sur le rseau local sur le port
8080 et qu'on veut le rendre accessible pour les internautes. On redirige le port 80 vers notre serveur sur le port
8080. Ainsi, les clients externes auront l'impression de s'adresser un serveur sur le port usuel pour le web, 80.
6.4 - Les limites du port forwarding
H oui, le port forwarding ne peut pas non plus rpondre parfaitement toutes les questions qu'amne la NAT
dynamique. Ainsi, on a vu que l'on ne pouvait associer qu'une adresse de machine un port donn. Si l'on
possde plusieurs serveurs FTP en local et que l'on veut les rendre accessibles, il faudra trouver une autre
astuce...
7 - Les proxys
7.1 - Qu'est-ce qu'un proxy ?
Un proxy est un mandataire pour une application donne. C'est dire qu'il sert d'intermdiaire dans une
connexion entre le client et le serveur pour relayer la requte qui est faite. Ainsi, le client s'adresse toujours au
proxy, et c'est lui qui s'adresse ensuite au serveur. Une proxy fonctionne pour une application donne, http, ftp,
smtp, etc. Il peut donc modifier les informations envoyer au serveur, ainsi que celles renvoyes par celui-ci. La
contrepartie est qu'il faut un proxy par application. Cependant, beaucoup de proxys sont en fait des multiproxys qui sont capables de comprendre la plupart des applications courantes.
7.2 - Qu'est-ce qu'un proxy n'est pas ?
Un amalgame est souvent fait entre les fonctionnalits qu'on peut apporter un proxy, et au proxy lui-mme.
Ainsi, on pense souvent qu'un proxy doit faire de la NAT, ou serveur de cache, mais ce ne sont que des
fonctionnalits ajoutes. Effectivement, il est souvent utile d'ajouter des fonctions de cache un proxy vu que
c'est lui qui centralise l'accs au web. Ainsi, si 15 personnes demandent le mme site web, il ne sera charg
qu'une fois puis gard dans le cache du proxy. D'autre part, la NAT est elle aussi souvent indispensable pour
qu'un proxy fonctionne, vu qu'il est cens tre un intermdiaire, il faudra qu'il modifie l'adresse source du paquet
pour que la rponse passe par lui. Cependant, mme si c'est ce qui est le plus souvent utilis, ce n'est pas
obligatoire. Si ces fonctionnalits sont souvent utiles et utilises, ce n'est pas pour autant qu'il faut penser qu'elles
sont synonymes de proxy.
9 - La scurit et la NAT
9.1 - La NAT dynamique permet-elle d'amliorer ma scurit ?
La NAT dynamique permet de rendre les machines d'un rseau local inaccessibles directement de l'extrieur, on
peut donc voir cela comme une scurit supplmentaire. Mais cela n'est pas suffisant et il est indispensable
d'utiliser un filtrage si l'on veut obtenir un bon niveau de scurit. La NAT dynamique seule ne peut pas tre
considre comme une scurit suffisante.
9.2 - Est-ce utile pour la scurit d'utiliser un proxy ?
Un proxy travaille au niveau 7 du modle OSI, c'est dire qu'il est capable d'interprter et de modifier les
informations du protocole sur lequel il travaille. Ainsi, il peut vrifier le contenu de ce qui est reu de la part du
serveur et en interdire ou modifier le contenu selon la politique choisie. L'utilisation d'un proxy pour des
protocoles critiques est donc souvent utile si on veut avoir une bonne vision de ce qui se passe.
9.3 - La NAT est elle compatible avec IPSEC ?
Si on veut tre prcis, la rponse est oui. Cependant, la norme IPSEC ayant diffrentes implmentations, ce n'est
pas toujours le cas. D'ailleurs la plupart des constructeurs ont cr leur propres solutions IPSEC pour traverser de
la NAT. Le problme vient de l'encryption de l'en-tte IP par les participants au tunnel IPSEC. Si l'adresse IP est
modifie pendant le trajet du paquet, elle ne sera pas la mme l'arrive que celle qui a t encrypte au dpart,
et aprs comparaison, le paquet sera dtruit. Cependant, en se plaant en mode ESP et en faisant du tunneling,
c'est la totalit du paquet qui est encrypte, et une nouvelle en-tte est ajoute celui-ci. Ainsi, la comparaison
ne se fera pas sur l'en-tte modifie, mais sur celle contenue dans les donnes du paquet. Mais cette solution
n'est
pas
toujours
possible.
Je ne crois pas qu'il existe de norme pour rsoudre ce problme, mais une solution semble apporter une relle
satisfaction au problme cit. Elle est aujourd'hui utilise par beaucoup de constructeurs, la NAT traversal ou NATT. Il s'agit d'encapsuler les donnes dans un tunnel UDP. Ainsi, de la mme faon qu'en mode tunnel et ESP, l'entte modifie par la NAT ne sera pas utilise pour le test d'authentification. Ainsi, il est souvent possible de mettre
en place un VPN IPSEC, mme si on utilise de la NAT.
11 - Mini lexique
11.1 - Modle OSI
Le modle OSI a t cr dans le but d'uniformiser les rseaux et de permettre l'interoprabilit entre systmes
htrognes. Il dfinit sept couches ayant chacune un rle spcifique. Ces couches permettent donc de rendre un
service les unes par rapport aux autres, tout en tant chacune indpendante des autres.
11.2 - IP
IP est un protocole de couche 3 qui permet principalement d'identifier les machines l'aide d'adresses et de
router les informations entre rseaux logiques. Il permet aussi de faire de la fragmentation de paquets.
11.3 - TCP
TCP est un protocole de couche 4 qui permet d'identifier et de contrler les connexions entre machines. La gestion
des flux et des erreurs est aussi intgre ce protocole.
11.4 - SNAT ou Source NAT
Le Source NAT correspond la modification de l'adresse source dans un paquet translat. Il est notamment utilis
pour la NAT dynamique, mais aussi pour la NAT statique lorsqu'on veut sortir du rseau local.
11.5 - DNAT ou Destination NAT
Le Destination NAT correspond la modification de l'adresse destination dans un paquet translat. Il est utilis
pour la NAT statique, lorsqu'on veut accder un serveur sur un rseau local.
12 - Annexes
12.1 - Ressources utilises
Je n'ai pas utilis beaucoup de documents aussi bien en ligne que sur papier. Les rponses et connaissances
apportes proviennent en majeure partie des informations que j'ai pu glaner en furetant sur le net, et notamment
sur
les
newgroups
fr.comp.reseaux.ip
et
fr.comp.reseaux.ethernet.
Je me suis quand mme inspir de la RFC 1631. Et notamment de l'excellente faq sur les firewalls de Stphane
Catteau
dont
je
me
suis
inspir
pour
http://fr.comp.securite.free.fr/firewall.txt
N'hsitez pas la consulter, on y apprend plein de choses.
la
mise
en
forme.
Disponible
sur:
12.2 - Remerciements
Je remercie notamment les personnes suivantes pour leur lecture assidue de la faq durant sa ralisation et leurs
conseils prcieux. Diane Guinnepain, Pep, Ifragu, Cdric Blancher.
13 - Conclusion
La NAT est aujourd'hui un lment important en rseau tant donn son norme dploiement travers le monde suite
l'annonce de la pnurie d'adresses IPv4. J'ai essay de rendre la comprhension de cette technique la plus accessible
possible. Cependant, il faut imprativement avoir quelques notions en rseau pour pouvoir bien comprendre les points
dlicats qu'elle engendre. Il y a et il y aura srement encore beaucoup de choses dire sur le sujet. Vos remarques
sont donc encore et toujours les bienvenues, aussi bien pour y ajouter des ides, que pour enlever le superflu.
Maintenant, si je revois passer des questions sur la NAT, j'aurai au minimum un droit de flagellation sur les personnes
incrimines ;-)
Le routage
1 - Introduction
1.1 - Objet de ce cours
1.2 - Pr requis
1.3 - Rutilisation de ce cours
1.4 - Dcharge
1.5 - Votre travail
2 - Une communication, comment a marche ?
2.1 - Que faut-il pour dialoguer ?
2.2 - Analogie de la parole
2.3 - Et Internet dans tout a ?
3 - Dfinitions
3.1 - Le modle OSI
3.2 - L'encapsulation
3.3 - Retour Internet
4 - La couche physique (couche 1)
4.1 - Le rle de la couche 1
5 - La couche liaison de donnes (couche 2)
5.1 - Les rles de la couche 2
5.2 - L'adressage des machines
5.3 - Le protocole Ethernet
5.4 - Format d'une trame Ethernet
5.5 - Dialogue entre deux machines
6 - La couche rseau (couche 3)
6.1 - Les rles de la couche 3
6.2 - Quelles adresses pour la couche 3 ?
6.3 - Pourquoi encore une adresse alors que nous avons dj l'adresse MAC ?
6.4 - Comment dterminer qu'une machine est sur mon rseau ?
6.5 - Qu'est ce que la table de routage ?
6.6 - Qu'est-ce qu'une route par dfaut ?
6.7 - Mais si l'on met une route par dfaut, peut-on en mettre plusieurs ?
6.8 - Puis-je mettre l'adresse d'un routeur n'tant pas sur mon rseau comme passerelle ?
6.9 - Vu que ma machine a plusieurs interfaces, dois-je avoir plusieurs tables de routage ?
6.10 - Format d'un datagramme IP
6.11 - Cas particulier des liaisons point point
7 - Les interactions entre les couches 2 et 3
7.1 - Trame et datagramme, qu'est-ce qui circule sur le rseau ?
7.2 - L'organisation de l'encapsulation
7.3 - Qu'est-ce que le protocole ARP ?
8 - Dialogue entre deux machines distantes
8.1 - Prsentation du dialogue
8.2 - Emission du message par A
8.3 - Rception du message par le routeur 1 intermdiaire
8.4 - Rception du message par la machine B
8.5 - Quelques remarques
9 - Mini lexique
9.1 - Adresse IP
9.2 - Rseau logique
9.3 - Connexion/interconnexion
9.4 - Sous-rseau
9.5 - ARP
10 - Annexes
10.1 - Ressources utilises
10.2 - Remerciements
11 - Conclusion
12 - Discussion autour de la documentation
13 - Suivi du document
1 - Introduction
1.1 - Objet de ce cours
Le but de ce document est de vous prsenter comment les informations peuvent transiter d'un ordinateur l'autre
sur Internet. Nous nous limiterons aux aspects rseau du dialogue. Tous les aspects applicatifs seront donc mis de
cot (gestion des noms de machines, protocoles applicatifs, etc.) L'tude se limitera donc aux couches 2 et 3
du modle OSI, soit Ethernet et IPv4 dans notre cas. Oups... ces mots sont du charabia pour vous, je vous invite
alors continuer la lecture du document qui vous prsentera plus en dtail chacun de ces concepts voqus.
1.2 - Pr requis
Pour une meilleure comprhension de ce cour, il sera ncessaire d'avoir quelques bases en ce qui concerne
l'adressage IPv4 et les sous-rseaux. Pour cela, je vous conseillerai la lecture de la faq sur les masques de sous
rseau
1.3 - Rutilisation de ce cours
Vous tes libre d'utiliser de courts extraits de ce cours, dans la mesure o vous incluez un lien permettant d'avoir
accs l'ensemble du document. Ceci dans le but de permettre vos lecteurs d'obtenir facilement un complment
d'information. De mme, vous tes libre de copier ce cours dans son intgralit, condition cependant d'en
avertir l'auteur, et que cette utilisation soit exempte de tout caractre commercial (bannires publicitaires
incluses). Cette restriction tant principalement due au plus lmentaire des respects : celui du temps que j'ai
consacr la rdaction de ce cours. Toute autre utilisation devra faire l'objet d'un accord pralable avec l'auteur.
1.4 - Dcharge
L'auteur dcline toute responsabilit concernant la mauvaise utilisation ou comprhension du document qui
engendrerait l'croulement de votre rseau ;-)
1.5 - Votre travail
La seule et unique tche que je vous demanderai d'accomplir sera de corriger mes erreurs (aussi bien dans la
cohrence des lments avancs que pour l'orthographe), me donner des conseils sur ce qui est mal expliqu
pour le rendre plus accessible, ajouter des lments qui ont trait aux masques et rendent l'expos plus complet,
combler tout manque pour amliorer ce cours. Mais maintenant, entrons dans le vif du sujet...
L'metteur sera les cordes vocales. Le rcepteur le tympan. Le moyen de transmission sera les ondes sonores. Le
support de transmission sera l'air. Il faudra aussi se mettre d'accord sur une langue utiliser, qui elle-mme sera
rgie
par
des
rgles,
etc.
Nous voyons donc qu'il est ncessaire de mettre en place tout un nombre de normes pour communiquer.
2.3 - Et Internet dans tout a ?
Effectivement, vous ne voyez peut-tre toujours pas le rapport que tout cela peut avoir avec Internet ? Et bien de
la mme faon que nous communiquons par la parole, nous souhaitons faire communiquer des machines par
Internet. Si l'on suit le mme raisonnement que prcdemment, il apparat ncessaire de mettre en place des
normes permettant de dcrire la faon dont les ordinateurs vont communiquer entre eux.
Et effectivement, lors de la cration d'Internet, un modle dcrivant les normes mettre en place a t choisi, il
s'agit du modle OSI (open systems interconnection)
3 - Dfinitions
Ce chapitre va nous permettre de prsenter plusieurs notions qu'il sera ncessaire de bien comprendre pour pouvoir
poursuivre la lecture du cours sans problmes.
3.1 - Le modle OSI
En se basant sur les observations prcdentes, on voit que chacun des lments en jeu (tympans, cordes vocales,
etc,.) remplit une tche particulire. Le modle OSI est bas sur ce principe. Il part de l'observation des tches
que nous avons accomplir et associe ces tches des couches. Le modle est organis en sept couches ayant
chacune
un
ou
plusieurs
rles
prcis.
Reprsentation:
Couche
Couche
Couche
Couche
Couche
Couche
Couche
7:
6:
5:
4:
3:
Liaison
1:
2:
Application
Prsentation
Session
Transport
Rseau
donnes
Physique
de
Chaque couche a donc un rle prcis spar des autres. Les couches peuvent communiquer avec les couches
directement adjacentes (la couche 2 pourra avoir des changes avec les couches 1 et 3). Ainsi, l'utilisation de
l'ensemble de ces couches permet de raliser une suite de tches qui, regroupes, permettent la communication.
Un message envoyer parcourt les couches de la couche 7 la couche 1 qui reprsente le support de
transmission. L'analogie avec la parole serait le cerveau qui cre le message de la couche 7, jusqu'au support de
transmission qui est l'air et qui reprsente la couche 1. Tout cela en passant par les couches intermdiaires
reprsentes
par
les
nerfs,
les
cordes
vocales,
les
ondes,
etc.
Chacune des couches formate donc bien le message et l'envoi la couche suivante (du cerveau aux nerfs, des
nerfs aux cordes vocales, etc.)
3.2 - L'encapsulation
Au cours de son passage par chacune des couches, des informations relatives chacune d'entre elles sont
ajoutes pour lui permettre d'effectuer la tche qui lui incombe, on appelle cela l'en-tte. Cela permet d'avoir un
certain nombre d'informations ncessaires chaque couche pour effectuer son travail, et que ces informations
circulent
avec
le
message
transmettre.
++++++++++++++++++++++
couche
7
|
++++++++++++++++++++++
Info
+++++++++++++++++++++++++++++++++++++++++
couche
6
|
en-tte
couche
6
|
+++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++
couche
5
|
en-tte
5
|
en-tte
6
|
++++++++++++++++++++++++++++++++++++++++++++++
...
et
ainsi
de
suite
...
++++++++++++++++++++++++++++++++++++++++++++++
transmettre
Info
Info
jusqu'au
transmettre
transmettre
paquet
|
final
Couche
1
|
en-tte
1
|
...
|
e-t
5
|
++++++++++++++++++++++++++++++++++++++++++++++
en-tte
Info
Chaque couche ajoute donc sa propre en-tte l'information d'origine. Ce procd s'appelle l'encapsulation. Ces
notions seront prsentes plus en dtail par la suite. Lorsqu'une machine reoit le message, il parcourt les
couches dans le sens inverse, de la couche 1 la couche 7 qui reprsente l'application qui doit recevoir le
message. De la mme faon que lors de la rception d'un message auditif (ondes transportes par l'air, qui font
vibrer les tympans, les tympans envoient l'information reue par l'intermdiaire des nerfs au cerveau).
3.3 - Retour Internet
Maintenant que nous connaissons le modle en couche et les principes qu'il reprsente, nous allons pouvoir nous
pencher sur l'implmentation de ce modle en couches pour la communication de machines sur Internet. Dans ce
document, nous prsenterons les couches 2 et 3 qui permettent d'acheminer les donnes d'un ordinateur
un autre. La couche 2 permet deux machines directement connectes de dialoguer, on dit alors que les
machines sont sur un mme rseau (avec la dfinition de rseau prsente dans le lexique) La couche 3 permet le
dialogue entre rseaux, ce que l'on appelle le routage. On remarque ainsi que deux machines sur un mme
rseau pourront dialoguer directement, mais pour parler une machine situe sur un rseau distant, il faudra
passer par des machines intermdiaires qui feront la liaison entre les rseaux (on appellera ces machines
intermdiaires des routeurs).
la
couche
2,
ce
sont
les
adresses
MAC.
Les adresses MAC sont codes sur 6 octets, soit 48 bits donc 2^48 = ... plusieurs milliers de milliards d'adresses
possibles ! Elles sont la plupart du temps crites par octet sous forme hexadcimale, spars par le caractre ":"
Ce qui donne par exemple 3C:AB:35:48:FF:D2 qui est une adresse MAC. Nous pouvons ainsi identifier chaque
interface de machine individuellement. Il nous faut maintenant dfinir les rgles qui permettront aux machines de
dialoguer. Pour cela nous allons dfinir un protocole.
5.3 - Le protocole Ethernet
Le protocole Ethernet dfinit le
trame. La trame est compose
L'en-tte Ethernet contient les
permettre la transmission des
participant au dialogue.
format des messages changs. Le message de base utilis par Ethernet est la
d'une en-tte et d'une "charge utile" contenant les informations transmettre.
informations ncessaires au bon fonctionnement de la couche 2 qui pourront
informations. Nous y retrouvons notamment les adresses MAC des machines
transporter.
Trame
++++++++++++++++++++----------------------------|
En-tte
Ethernet
|
Informations
++++++++++++++++++++----------------------------Nous
allons
voir
plus
en
dtail
ce
Ethernet
que
contient
En-tte
++++++++++++++++++++++++++++++++++++++++++++++++++++
|
@
MAC
source
|
@
MAC
destination
|
++++++++++++++++++++++++++++++++++++++++++++++++++++
transporter
l'en-tte
|
Ethernet.
Ethernet
Protocole
sup
L'adresse
MAC
source
est
l'adresse
de
la
machine
qui
envoi
la
trame.
L'adresse MAC destination est celle de la machine qui doit recevoir la trame (jusqu'ici ce n'est pas bien sorcier :-)
Le protocole sup est le protocole utilis par la couche suprieure (la couche 3 dans notre cas puisque Ethernet est
un protocole de couche 2) Ceci est utile car quand la couche 2 reoit le message, elle doit savoir quel protocole
de couche 3 envoyer les informations reues (il est possible sur une machine d'utiliser plusieurs protocoles pour
une mme couche).
5.5 - Dialogue entre deux machines
Prenons l'exemple d'une machine A qui veut envoyer le message "Bonjour" une machine B situe sur le mme
rseau. Il lui suffit de connatre l'adresse MAC de B pour lui envoyer le message. Ainsi, en lui envoyant la trame
suivante,
elle
devrait
pouvoir
lui
envoyer
le
message:
++++++++++++++++++++++++++++++++++-----------------|
@MAC
A|
@MAC
B
|
protocole
sup
++++++++++++++++++++++++++++++++++------------------
XXXXX
Bonjour
B reoit la trame et voit que c'est son adresse MAC qui est en destination, elle lit donc le reste des informations. Il
s'agit des informations des couches suprieures (XXXXX), et enfin, du message "Bonjour".
Nous avons donc russi grce la couche 2 faire dialoguer deux machines connectes sur un mme rseau.
Nous allons maintenant voir comment faire communiquer deux machines appartenant des rseaux diffrents.
un
autre.
La
couche
rseau
d'autres
fonctionnalits
Principe
Machine
|
---------|Rseau
----------
auxquelles
nous
ne
nous
intresserons
de
A
ici.
fonctionnement:
Machine
---------1|--Routeur1--|Rseau
pas
2|--Routeur2--|Rseau
----------
B
|
---------3|
----------
Lorsque la machine A veut envoyer un message B, le paquet va d'abord passer par le rseau 1. Puis le routeur 1
qui est connect ce rseau va le rcuprer pour le renvoyer vers le rseau 2, et ainsi de suite jusqu'au rseau 3
o la machine B va pouvoir le recevoir. Cela est bien joli, mais comment a marche ? Comment le routeur 1 sait-il
qu'il faut envoyer le paquet sur le rseau 2 pour qu'il puisse atteindre B ??? Et puis on sait maintenant envoyer
une trame d'une machine une autre sur un mme rseau, mais sur deux rseaux diffrents ? Nous allons
essayer de rpondre ces questions dans les paragraphes suivant.
6.2 - Quelles adresses pour la couche 3 ?
Je vous invite lire le paragraphe 2.2 de la faq sur les masques pour comprendre l'intrt de l'adresse IP et du
masque qui lui est associ. Une adresse IP est donc code sur 4 octets. Elle s'crit en dcimal spars par des
points. Par exemple, 192.168.0.1 est une adresse IP.
6.3 - Pourquoi encore une adresse alors que nous avons dj l'adresse MAC ?
Il est ncessaire de diffrencier les adresses de couche 2 et de couche 3, car l'adressage au niveau de chacune de
ces
couches
n'a
pas
le
mme
rle.
L'adressage
MAC
en
couche
2
permet
d'identifier
les
machines
SUR
UN
MEME
RESEAU.
L'adressage IP en couche 3 permet d'adresser les machines SUR DES RESEAUX DISTINCTS.
Peut-on alors utiliser pour ces deux couches une seule de ces deux adresses ? La rponse est malheureusement
non. Les adresses de couche 2 sont en rapport avec le matriel rseau utilis (le protocole de couche 2 est gr
au niveau de la carte connecte au rseau et non pas par le systme d'exploitation comme les couches
suprieures) il est donc difficile de modifier les adresses MAC qui sont censes tre codes directement sur la
carte rseau. Cela est notamment du au fait que chaque adresse MAC doit tre unique sous peine de conflit
matriel, et que cette adresse doit tre accessible trs tt lors du boot d'une machine. Les adresses de couche 3
quant elles demandent une certaine souplesse d'utilisation car on ne connat pas priori l'adresse du rseau sur
lequel une machine va se trouver. Il y a donc une incompatibilit d'utilisation d'une adresse de couche 2 pour une
adresse
de
couche
3,
et
vice
versa.
Enfin, les protocoles rseau voluant au fil du temps, il est ncessaire que chaque couche soit indpendante des
autres. Il y a d'autres raisons qui nous obligent utiliser des adresses diffrentes pour des couches diffrentes,
mais ceci n'tant pas partie intgrante du sujet, nous ne nous y attarderons pas ici, d'autant plus que les
arguments prsents devraient vous avoir convaincus :-)
6.4 - Comment dterminer qu'une machine est sur mon rseau ?
Si vous avez compris la faq sur les masques de sous rseau, vous savez que le masque permet notamment une
machine de savoir quelles sont les autres machines de son rseau. Ainsi, quand une machine veut dialoguer avec
une autre, elle va d'abord regarder si cette machine est sur son propre rseau, ou si elle va devoir passer par des
routeurs intermdiaires pour lui envoyer son paquet. Ceci va tre possible grce la table de routage.
6.5 - Qu'est ce que la table de routage ?
La table de routage est un regroupement d'informations permettant de dterminer le prochain routeur utiliser
pour accder un rseau prcis sur lequel se trouvera la machine avec laquelle nous souhaitons dialoguer. Ainsi,
si l'on reprend l'exemple du 6.1, le routeur 1 doit savoir que pour atteindre le rseau 1, il devra envoyer les
informations sur son interface de gauche sur le schma, que pour atteindre le rseau 2, il devra envoyer les
informations sur son interface de droite, et enfin, pour atteindre le rseau 3, il devra envoyer les informations sur
son interface de droite vers le routeur 2. La table de routage doit pouvoir regrouper toutes ces informations. Elle
les
regroupe
par
ligne
en
indiquant
pour
un
rseau
donn
par
o
il
faut
passer.
Pour
vers
vers
vers
le
routeur
rseau
rseau
rseau
3
par
exemple,
1
2
->
->
->
utiliser
sa
table
de
routage
utiliser
utiliser
interface
droite
interface
interface
vers
doit
routeur
tre:
gauche
droite
2
En fait, la ralit est un peu plus prcise. Les interfaces peuvent tre identifis par leurs adresses ou leur type, et
les
rseaux
sont
identifis
par
l'adresse
du
rseau
et
le
masque
associ.
Ainsi,
Rseau
192.168.0.0
172.16.0.0
10.0.0.0
cela
Masque
255.255.255.0
255.255.0.0
255.0.0.0
se
ethernet
ethernet
ethernet
traduit
Interface
1
2
en:
ethernet
ethernet
Passerelle
1
2
172.16.0.254
la
poubelle
:-(
En indiquant en plus une route par dfaut, cela aurait permis ma machine d'avoir une destination, mme quand
aucune entre de la table de routage ne correspondait l'adresse demande. J'aurais donc envoy mon paquet
vers ma route par dfaut, en fait vers le prochain routeur utiliser, et c'est ce prochain routeur qui se serait
occup de continuer router le paquet. Si lui non plus n'avait pas eu de route spcifie pour l'adresse de
destination demande, il aurait envoy le paquet son propre routeur par dfaut, et ainsi de suite jusqu' tomber
sur
un
routeur
connaissant
la
route
!
Cela peut sembler un peu alatoire comme stratgie, mais aujourd'hui, Internet est fait de telle faon que les
routeurs qui le composent connaissent les routes vers toutes les destinations. Cela est mis en place grce des
protocoles volus permettant d'changer des informations de routage en temps rel ! Mais ceci sort un peu de
notre
objectif
:-)
La
table
de
Rseau
192.168.0.0
172.16.0.0
10.0.0.0
dfaut
Cette
0.0.0.0
routage
pour
Masque
255.255.255.0
255.255.0.0
255.0.0.0
0.0.0.0
ligne
peut
0.0.0.0
le
ethernet
ethernet
ethernet
ethernet
parfois
ethernet
routeur
Interface
1
2
devient
ethernet
ethernet
2
2
tre
aussi
2
alors:
Passerelle
1
2
172.16.0.254
172.16.0.254
crite:
172.16.0.254
NB: On peut se rendre compte dans notre exemple que la route vers le rseau 10.0.0.0 n'est plus ncessaire, vu
que la route par dfaut pointe vers le mme routeur.
6.7 - Mais si l'on met une route par dfaut, peut-on en mettre plusieurs ?
Cela n'a pas d'intrt dans l'absolu, et sera trait diffremment selon les systmes. Disons qu'une table de
routage normale ne devrait avoir qu'une route par dfaut.
6.8 - Puis-je mettre l'adresse d'un routeur n'tant pas sur mon rseau comme passerelle ?
Non ! Et d'ailleurs, cela n'aurait pas de sens, puisqu'une passerelle est cense nous indiquer un chemin pour sortir
de notre rseau. Si on indique l'adresse d'une machine en dehors de notre rseau, c'est que l'on en est dj sorti !
La consquence est que les passerelles indiques dans une table de routage devront toujours appartenir mon
propre rseau, ou du moins, l'un des rseaux auxquels appartiennent mes interfaces, si j'en ai plusieurs.
6.9 - Vu que ma machine a plusieurs interfaces, dois-je avoir plusieurs tables de routage ?
L encore la rponse est non. La table de routage est cense contenir toutes les informations de routage pour
votre machine (ou routeur) quel que soient le nombre d'interfaces. D'ailleurs, vous avez pu voir dans la table de
routage du routeur 1 que les routes contenaient des informations sur ses deux interfaces. Il existe cependant des
fonctions avances de routage avec plusieurs table, mais nous n'en sommes pas l ;-)
Mais maintenant que nous savons comment une machine fait pour aiguiller un paquet, il nous reste savoir
quelles informations de couche 3 ce paquet devra contenir pour que le routage puisse tre effectu. Le message
de base utilis par IP est le datagramme.
6.10 - Format d'un datagramme IP
De la mme faon qu'avec Ethernet, la couche IP (couche 3) va ncessiter un certain nombre d'informations pour
pouvoir effectuer les tches qui lui incombent comme le routage. A la manire de la trame Ethernet, le
datagramme IP se compose d'une en-tte IP, et d'un payload contenant les informations transporter.
Datagramme
********************----------------------------|
En-tte
IP
|
********************-----------------------------
IP
Informations
transporter
Nous allons voir plus en dtail ce que contient l'en-tte IP, mme si nous ne dcrivons pas l'ensemble de l'en-tte,
mais
juste
les
informations
qui
nous
intressent.
En-tte
****************************************************
|
@
IP
source
|
@
IP
destination
****************************************************
IP
|
Protocole
sup
Celle-ci ressemble fort ce que nous avons vu prcdemment pour Ethernet, nous ne dtaillerons donc pas son
contenu. Maintenant que nous avons dcrit la couche 3, nous allons pouvoir voir plus en dtail comment se fait
l'interface avec la couche 2.
la
rponse
semble
tre:
ni
l'un
ni
l'autre...
Ou
plutt:
l'un
et
l'autre
Effectivement, nous avons parl au 3.2 d'encapsulation des informations. C'est exactement le principe qui va
tre utilis ici. Les informations de couche 2 et 3 vont tre mises ensemble avec les informations transmettre.
Le paquet ainsi form contiendra ainsi l'ensemble des informations ncessaires au transport de l'information. C'est
donc une trame qui circulera sur le rseau, et cette trame Ethernet contiendra le datagramme IP.
++++++++++++++++++++++++++++++++++++++++++++++
|
en-tte
2
|
e-t
3
|
...
|
en-tte
++++++++++++++++++++++++++++++++++++++++++++++
<--------Datagramme
IP
<-------------Trame
Ethernet
Info
-------->
-------------->
Maintenant, comment est organise cette encapsulation pour que chaque couche retrouve facilement ses
informations ?
7.2 - L'organisation de l'encapsulation
Comme nous l'avons vu au 3.2, lors de l'mission d'une information, chaque couche ajoute son en-tte. Le
paquet final ainsi form contient donc les informations de toutes les couches, ainsi que l'information d'origine. La
dernire couche ayant apport son en-tte est la couche 2 (la couche 1 n'a pas besoin d'apporter de l'information,
ou du moins, cela est transparent pour nous). Ainsi, quand le paquet arrive sa destination, ce sont les
informations de couche 2 qui sont accessibles en premier, et a tombe bien puisque ce sont elles dont nous avons
besoin
en
premier
pour
recevoir
le
message
!
La
La
rception
carte
rseau
d'un
de
message
ma
se
machine
passe
reoit
++++++++++++++++++++++++++++++++++++++++++++++
Couche
2
|
en-tte
2
|
e-t
3
|
...
|
++++++++++++++++++++++++++++++++++++++++++++++
la
en-tte
donc
ainsi:
trame
suivante
Info
La couche 2 regarde l'adresse MAC de destination et si cela correspond bien notre machine, elle envoi les
informations la couche 3 en prenant soin d'enlever l'en-tte Ethernet, qui ne servira plus.
++++++++++++++++++++++++++++++++++++++++++++++
Couche
3
|
en-tte
3
|
e-t
4
|
...
|
++++++++++++++++++++++++++++++++++++++++++++++
en-tte
Info
De la mme faon, la couche 3 regarde l'adresse IP de destination, et si cela correspond bien UNE DES adresses
IP de notre machines, elle envoi les informations la couche 4, et ainsi de suite. Si par contre, le datagramme est
destination d'une autre adresse IP, notre machine va router ce paquet vers sa vraie destination (cela n'est vrai
que si le routage est activ sur la machine, mais c'est normalement le cas pour un routeur :-) En fin de chane,
l'application
implique
dans
le
dialogue
va
recevoir
les
informations
qu'elle
attend:
++++++++++++++++++++++
couche
7
|
++++++++++++++++++++++
Info
transmettre
Tout cela semble marcher parfaitement comme une machine bien huile. Cependant, il nous manque encore
quelques informations pour pouvoir avoir une comprhension globale du fonctionnement du routage. Par exemple,
nous savons dterminer l'adresse IP du prochain routeur utiliser, mais c'est de l'adresse MAC dont nous avons
besoin pour dialoguer avec lui directement sur notre rseau... Il faut donc pouvoir rcuprer une adresse MAC en
fonction d'une adresse IP. Pour cela, nous allons devoir utiliser un protocole particulier, ddi cette fonction, que
l'on appelle ARP.
7.3 - Qu'est-ce que le protocole ARP ?
Le
protocole
ARP
permet
d'obtenir
une
adresse
MAC
en
fonction
d'une
adresse
IP.
Reprenons
notre
problme.
Le routeur 1 veut envoyer un paquet vers l'adresse 10.0.0.45 du rseau 3. Comme nous l'avons vu
prcdemment, le routeur regarde dans sa table de routage pour savoir o il va devoir envoyer le paquet. La table
de routage lui dit que pour atteindre le rseau 10.0.0.0/255.0.0.0 qui contient l'adresse 10.0.0.45, il faut passer
par le routeur dont l'une des adresses d'interface est 172.16.0.254. Le nouveau travail du routeur est donc
d'envoyer le paquet vers 172.16.0.254. Cette adresse IP tant sur son propre rseau (notre routeur a une
interface dans le rseau 172.16.0.0./255.255.0.0), il faut connatre son adresse MAC pour pouvoir lui envoyer le
paquet. Pour connatre son adresse MAC, l'idal serait de lui demander, mais pour lui demander, il faudrait
connatre
son
adresse
MAC
!!!
Et on tourne en rond :-( Vu qu'aucune autre machine du rseau n'est cense connatre l'adresse MAC de
172.16.0.254, nous ne pouvons pas non plus leur demander. Il faut donc trouver un moyen de s'adresser
l'adresse
MAC
de
172.16.0.254
sans
la
connatre
!
Et si vous vous rappelez bien du cours sur les masques de sous rseau, vous avez peut-tre devin que nous
avons un mcanisme notre disposition nous permettant de faire cela... Il s'agit du principe de broadcast ! En
envoyant ma question tout le monde, je suis sr que la machine 172.16.0.254 va le recevoir.
Je
peux
donc
envoyer
tout
le
Qui
a
l'adresse
IP
172.16.0.254
?
Toutes
les
machines
reoivent
cette
question,
Je
suis
172.16.0.254
et
mon
monde
ma
requte
et
quelle
est
son
mais
seule
172.16.0.254
adresse
MAC
est
ARP
demandant:
adresse
MAC
?
va
me
rpondre:
04:CF:65:84:C5:E2
J'ai ainsi pu rcuprer l'adresse MAC de 172.16.0.254, et je peux dsormais lui envoyer le paquet transmettre.
Nous avons ainsi russi faire la liaison souhaite entre l'adresse IP connue et l'adresse MAC recherche :-)
Une question se pose quand mme, car si toutes les machines doivent envoyer des messages tout le monde
chaque
fois
qu'elles
souhaitent
communiquer,
on
va
vite
encombrer
le
rseau...
Pour rpondre ce problme, ARP utilise une solution de cache local. C'est dire que lorsqu'une requte ARP va
tre effectue, la rponse cette requte va tre garde pendant un certain temps pour pouvoir tre rutilise.
Ce temps est paramtrable, et est souvent de l'ordre de quelques minutes. Ainsi, si mes machines continuent de
dialoguer ensemble, il n'y aura plus besoin de faire des broadcasts ARP, il suffira d'aller chercher dans le cache
ARP l'information. D'ailleurs, le fonctionnement de ARP veut que le systme aille d'abord regarder dans le cache
ARP si l'information s'y trouve, avant de faire le broadcast ARP (ce qui semble normal :-)
Bon, et bien nous avons maintenant en notre possession toutes les connaissances devant nous permettre de
comprendre en partie le dialogue entre deux machines distantes. Allons-y !
une
machine
B
sur
Internet.
Machine
|
---------|Rseau
----------
(193.25.25.25/24)
(232.32.32.32)
---------1|--Routeur1--|Internet|--Routeur2--|Rseau
----------
Machine
B
|
---------3|
----------
Interface
gauche
routeur
1:
193.25.25.254/24
Interface
droite
routeur
1:
140.40.40.14/28
La partie Internet n'est pas mise en dtail mais reprsente quelques de routeurs successifs avant le routeur 2.
NB: Comme petit exercice, vous pouvez vous demander pourquoi je n'ai pas prcis le masque de sous rseau
pour la machine B ?
8.2 - Emission du message par A
La machine A veut envoyer le message "bonjour" B. Comme nous l'avons vu travers le modle OSI, ce
message va traverser les diffrentes couches du modle pour que chacune y apporte l'information ncessaire
l'accomplissement de sa tche. Dans le modle TCP/IP utilis sur Internet, les couches 5 et 6 ne sont pas utilises
(on peut en dduire que les fonction effectues par ces couches ne sont pas ncessaires, ou qu'elles sont prises
en charge par une autre couche) Le message passe donc par la couche 4 qui, une fois son en-tte ajoute, envoi
le
paquet
la
couche
3.
La couche 3 reoit le paquet (segment TCP) et l'adresse de destination 232.32.32.32. Elle va voir dans sa table de
routage (celle de la machine sur laquelle on est, cad A) qui envoyer les informations.
Table
de
Rseau
193.25.25.0
dfaut
routage
Masque
255.255.255.0
0.0.0.0
ethernet
ethernet
de
Interface
1
A:
ethernet
Passerelle
1
193.25.25.254
Elle n'a pas de route spcifique pour l'adresse 232.32.32.32, ce sera donc la route par dfaut qui sera utilise.A
doit donc maintenant envoyer le paquet l'interface 193.25.25.254 du routeur 1. A retourne voir dans sa table de
routage par quel interface sortir pour envoyer le datagramme 193.25.25.254.Elle doit maintenant connatre
l'adresse MAC de l'interface 193.25.25.254. Pour cela, elle va voir dans son cache ARP si elle ne trouve pas
l'information. Si c'est le cas, elle connat l'adresse MAC, sinon, il faut qu'elle fasse un broadcast ARP pour la
trouver.Maintenant que la couche 3 connat l'adresse MAC destination, elle peut envoyer le datagramme IP (entte
IP
+
segment
TCP)
et
l'adresse
MAC
destination
la
couche
2.
En-tte
**************************************************-------|
IP
SRC
193.25.25.25
|
IP
DST
232.32.32.32
**************************************************-------<----------------------Datagramme
IP
|
ps
infos
IP--------------------->
La couche 2 reoit le datagramme et y ajoute son en-tte Ethernet. La trame est maintenant prte tre envoye
sur
le
rseau.
En-tte
++++++++++++++++++++++++++++++++++++++++++++++++-------|
MACSRC
MAC
A
|
MACDST
MAC
193.25.25.254
|
++++++++++++++++++++++++++++++++++++++++++++++++-------<---------------------Trame
Ethernet
ps
infos
Ethernet------------------->
La trame circule sur le rseau jusqu' sa destination qui est l'adresse MAC de 193.25.25.254.
8.3 - Rception du message par le routeur 1 intermdiaire
Le routeur 1 intermdiaire reoit la trame. La couche 2 regarde l'adresse MAC en destination, et comme c'est
l'adresse MAC de l'interface 193.25.25.254, le datagramme IP est envoy la couche 3.
La couche 3 reoit le datagramme et regarde l'adresse IP de destination. Ce n'est l'adresse d'aucune des
interfaces du routeur 1, donc le paquet devra tre rout vers sa destination. Le routeur va donc voir sa table de
routage
pour
voir
vers
qui
renvoyer
le
paquet.
Table
Rseau
193.25.25.0
140.40.40.0
dfaut
de
routage
Masque
255.255.255.0
255.255.255.240
0.0.0.0
du
ethernet
ethernet
ethernet
routeur
Interface
1
2
ethernet
ethernet
2
1:
Passerelle
1
2
140.40.40.13
Il n'y a pas de route spcifique pour l'adresse 232.32.32.32. C'est donc la route par dfaut qui sera utilise. La
prochaine machine qui envoyer le paquet est donc 140.40.40.13. Le routeur retourne voir dans sa table de
routage par quel interface sortir pour atteindre 140.40.40.13. C'est la seconde ligne de la table qui contient
l'information et l'interface utiliser est l'interface 2.De la mme faon que prcdemment, il faut trouver son
adresse MAC pour lui envoyer la trame contenant les informations ncessaires. On la trouve facilement grce aux
mcanismes ARP. Le routeur 1 peut donc envoyer la trame vers le prochain routeur. Nous n'allons pas dtailler la
suite,
le
passage
par
chaque
routeur
tant
identique
celui-ci.
Les informations arrivent donc jusqu'au routeur 2 grce aux mcanismes de routage d'Internet :-) Celui-ci va
comme prcdemment renvoyer le paquet qui ne lui est pas destin vers la machine B qui est sur son rseau.
8.4 - Rception du message par la machine B
La trame arrive donc sur l'interface de la machine B. L'adresse MAC en destination est bien celle de cette interface
(Cette adresse MAC aura t trouve grce au mcanisme ARP mis en oeuvre par le routeur 2, vous suivez bien ?)
La couche 2 renvoi donc le datagramme IP la couche 3 IP. La couche 3 reoit le datagramme et regarde
l'adresse IP de destination. C'est bien l'adresse d'une des interfaces de la machine ! La couche 3 va donc pouvoir
envoyer les informations la couche 4, qui enverra elle-mme le message "bonjour" la couche 7 applicative. Et
hop, nous avons russi ainsi envoyer le message "bonjour" de la machine A la machine B !!! Magisme...
Bien sr, certains points n'ont pas t dtaills et demandent des connaissances plus pousses pour pouvoir tre
expliqus. Mais cela fera l'objet d'un autre cours ;-)
8.5 - Quelques remarques
Et bien oui, mme si tout s'est bien droul dans notre dialogue, et que vous avez tout parfaitement compris, il
est
bon
de
mettre
en
valeur
certains
aspects
de
la
communication.
-
Les
adresses
MAC
source
et
destination
sont
modifies
chaque
passage
par
un
routeur
Oui, et c'est normal. Ces adresses MAC sont relatives la couche 2 dont le rle principal est le dialogue sur un
rseau local. Donc les adresses MAC utilises dans une trame doivent tre en relation avec le rseau sur lequel on
se
situe,
pas
celui
d'
cot
;-)
Que se passerait-il si une adresse MAC de destination tait celle d'une interface tant sur un autre rseau ? Ca ne
marcherait plus :-( car la trame serait envoye sur le rseau local (en couche 2) et ne trouverait pas de machine
ayant
cette
adresse
MAC.
La
trame
serait
donc
perdue.
Les adresses MAC contenues dans une trame Ethernet doivent donc toujours tre en rapport avec le rseau local.
C'est ce qui explique qu'elles doivent tre modifies chaque passage sur un nouveau rseau.
- Par contre, les adresses IP source et destination n'ont pas t modifies durant le transport de A B
Oui, et cela est encore normal ! La couche 3 concerne les informations de routage, donc sur des adresses
appartenant des rseaux distants. Ces adresses reprsentent donc les deux extrmits du dialogue et ne
doivent
pas
tre
modifies.
Que se serait-il pass si on avait modifi les adresses IP source et destination chaque passage d'un routeur ? Ici
encore, nous aurions eu des problmes. Le datagramme IP serait bien arriv jusqu'au routeur 1, et lui l'aurait
renvoy vers le prochain routeur sur Internet en mettant comme adresse IP destination 140.40.40.13. Le routeur
ayant cette adresse 140.40.40.13 aurait bien reu le datagramme, mais voyant que c'tait lui l'adresse IP de
destination, il aurait pris le paquet pour lui et la communication se serait arrte l (la couche 4 n'aurait pas
reconnu ce paquet comme appartenant une connexion valide) et badaboum... Il est donc impratif de ne pas
modifier les adresses IP lors du transport du datagramme. Le dialogue IP se fait de bout en bout entre les rseaux
distants, alors que le dialogue Ethernet se fait de proche en proche sur chacun des rseaux traverss.
Voici
un
petit
dessin
Machine
|
---------|Rseau
---------<---------------<--DE
Avec
pour
schmatiser
les
deux
principes
que
Machine
---------1|--Routeur1--|Internet|--Routeur2--|Rseau
---------Dialogue
IP
---><-------DE
---------><--DE
Dialogue
nous
venons
d'voquer.
B
|
---------3|
------------------------->
DE
--->
Ethernet
NB: Il est cependant possible que les adresses IP source et destination soient modifies dans le cas de la
traduction d'adresse. Ceci ne faisant pas partie intgrante du sujet, je vous invite lire la faq sur la nat(traduction
d'adresse)
- Une autre remarque que nous pouvons faire, est la foultitude d'tapes qui ont t utilises pour un simple envoi
de
"bonjour"
Et encore, ce n'est rien, en rentrant plus dans le dtail, il y a encore bon nombre d'autres communications que
nous n'avons pas dtailles qui sont ncessaires au dialogue. Et dire que tout cela se fait en quelques
millisecondes et est compltement transparent pour l'utilisateur final... C'est quand mme b Internet :-))
9 - Mini lexique
9.1 - Adresse IP
L'adresse IP est un numro cod sur 4 octets permettant d'identifier une machine de faon unique sur le rseau.
9.2 - Rseau logique
On appelle rseau logique un ensemble d'adresses IP appartenant une mme plage d'adresses. Cette plage est
notamment dfinie par l'adresse de rseau et le masque associ.
9.3 - Connexion/interconnexion
Ces deux termes sont souvent employs indiffremment, tort ! On parle de connexion de machines au sein d'un
mme rseau, et d'interconnexion de rseaux entre eux. La connexion se rapporte alors une notion de couche 2,
alors que l'interconnexion est une notion de couche 3.
9.4 - Sous-rseau
On dfinit un sous-rseau comme un sous-ensemble d'une plage d'adresses rseau. C'est grce au masque que
l'on peut dfinir un sous-rseau au sein d'un rseau, et ainsi dcouper un rseau en plusieurs sous-rseaux.
9.5 - ARP
ARP est un protocole permettant de dterminer une adresse MAC en fonction d'une adresse IP.
10 - Annexes
10.1 - Ressources utilises
Je me suis inspir des connaissances que j'ai pu glaner un peu partout depuis que je fais du rseau, sans
m'appuyer sur un document en particulier. Je dois cependant avouer que j'en ai beaucoup appris depuis que je
donne des cours en cole d'ingnieur et qu'il faut rpondre aux multiples questions de ces petites ttes blondes :) Ca m'a permis de me remettre en question et d'approfondir des sujets que je pensais matriser. La route vers le
savoir
est
encore
longue
!
:-)
Pour aller plus loin sur le sujet, je vous conseillerai la lecture du livre de Richard Stevens "Le TCP/IP illustr" qui
est
une
mine
d'or
pour
comprendre
les
mcanismes
TCP/IP.
Et sans oublier l'excellente faq sur les firewalls de Stphane Catteau dont je me suis inspir pour la mise en
forme.
Disponible
sur:
http://fr.comp.securite.free.fr/firewall.txt
N'hsitez pas la consulter, on y apprend plein de choses.
10.2 - Remerciements
Je remercie notamment les personnes suivantes pour leur lecture assidue du cours durant sa ralisation et leurs
conseils
prcieux.
David Blevin, Eric Belhomme, Annie D.
11 - Conclusion
Arf...
je
vois
le
bout
du
tunnel...
Je dois bien avouer que j'ai du tourner le problme dans tous les sens afin de trouver une faon cohrente d'aborder
les principes de routage. J'espre que le rsultat est la hauteur de mes attentes, et surtout qu'il vous aura permis de
comprendre un peu mieux le fonctionnement d'un des principes majeur d'Internet. La comprhension en profondeur du
routage n'est vraiment pas une chose aise. D'ailleurs, il me reste un bon nombre de questions en suspend auxquelles
je vais essayer de rpondre. Peut tre dans une suite du cours :-) En tout cas, je compte sur vous pour me faire un
retour efficace sur ce document. Je manipule beaucoup des concepts abords tous les jour. Mon oeil sur le sujet n'est
donc pas trs neuf, et il est probable que je n'explique pas bien certaines notions. Si des lments ne vous semblent
pas clair lors de la lecture du document, je vous invite me contacter l'adresse spcifie dans l'en-tte du document
pour me faire part de vos remarques. Ne ngligez pas vos remarques, elles me sont extrmement utiles pour amliorer
ce document, ainsi que ma comprhension personnelle. Merci de votre attention, vous pouvez teindre votre
ordinateur.
1 - Introduction
1.1 - Objet de ce cours
1.2 - Rutilisation de ce cours
1.3 - Dcharge
1.4 - Votre travail
2 - Dfinitions
2.1 - L'identification des machines
2.2 - La segmentation des rseaux
2.3 - Une seule adresse pour le prix de deux
2.4 - Dfinition empirique du masque
2.5 - Pourquoi matriser les masques ?
3 - Adresse IP et masque
3.1 - L'adressage IP
3.2 - Nombre de machines
3.3 - La sparation grce au masque
3.4 - Le couple adresse IP et masque
4 - Le codage
4.1 - Le codage binaire
4.2 - Pourquoi un codage binaire pour les ordinateurs ?
4.3 - Qu'est-ce qu'un octet ?
4.4 - Ecriture binaire de l'adresse IP
5 - Les masques
5.1 - Rcapitulatif
5.2 - Comment reprsente-t-on un masque ?
5.3 - Comment le masque et l'adresse IP sont ils associs ?
5.4 - Adresses spcifiques (rseau, broadcast)
5.5 - Les bits 1 et 0 doivent ils tre contigus ?
5.6 - Quelles adresses pour les masques ?
5.7 - Faire fi de l'criture
5.8 - Quelle est cette notation avec un /, comme /24 ?
6 - Comment bien choisir son masque ?
6.1 - Partir de l'existant
6.2 - En fonction du nombre de machines
6.3 - Comment dterminer la plage d'adresses partir du masque et d'une adresse ?
6.4 - Une mthode simple pour trouver les adresses de rseau possibles
6.5 - Comment dfinir une plage rseau quelconque comme somme de plusieurs plages ?
6.6 - Plages rserves (RFC 1918)
7 - Comment dcouper une plage d'adresses en plusieurs sous-rseaux ?
7.1 - Comment Dterminer les masques pour chacun des sous-rseaux ?
7.2 - Comment dterminer les plages d'adresses des sous-rseau ?
7.3 - Le rsultat
8 - Que sont les classes d'adresses A, B, C, D... ?
8.1 - Historique
8.2 - Dfinition
8.3 - Y a-t-il un pnurie d'adresses IPv4 ?
8.4 - Le systme d'adressage par classes est-il viable ?
8.5 - Qu'est-ce que l'adressage CIDR ?
9 - Trucs et astuces avec les masques
9.1 - Comment dterminer qu'une machine appartient mon rseau ?
9.2 - Des machines sur un mme rseau peuvent elles avoir des masques diffrents ?
9.3 - Puis-je utiliser un outil qui calcule pour moi ?
9.4 - Tout a c'est bien, mais quand est ce que je l'utilise ce masque moi ?
10 - Mini lexique
10.1 - Adresse IP
10.2 - Rseau logique
10.3 - sous-rseau
10.4 - Le ET logique
11 - Annexes
11.1 - Ressources utilises
11.2 - Remerciements
12 - Conclusion
13 - Discussion autour de la documentation
14 - Suivi du document
1 - Introduction
1.1 - Objet de ce cours
Dans le monde des rseaux, on utilise souvent des termes inintelligibles pour le commun des mortels n'ayant pas
une formation informatique pousse. Les masques en font partie, d'autant plus que leur comprhension et leur
utilisation n'est pas toujours simple (au dpart ;-) ) Le but de ce cours est de prsenter de faon la plus
comprhensible possible ce que sont les masques, quoi ils servent, comment bien les utiliser et se familiariser
avec. Pour cela, nous traiterons aussi quelques sujets annexes qui nous permettront de mieux comprendre l'utilit
des masques, comme les rseaux logiques, quelques notions de routage, etc.
1.2 - Rutilisation de ce cours
Vous tes libre d'utiliser de courts extraits de ce cours, dans la mesure o vous incluez un lien permettant d'avoir
accs l'ensemble du document. Ceci dans le but de permettre vos lecteurs d'obtenir facilement un complment
d'information. De mme, vous tes libre de copier ce cours dans son intgralit, condition cependant d'en
avertir l'auteur, et que cette utilisation soit exempte de tout caractre commercial (bannires publicitaires
incluses). Cette restriction tant principalement due au plus lmentaire des respects : celui du temps que j'ai
consacr la rdaction de ce cours. Toute autre utilisation devra faire l'objet d'un accord pralable avec l'auteur.
1.3 - Dcharge
L'auteur dcline toute responsabilit concernant la mauvaise utilisation ou comprhension du document qui
engendrerait l'croulement de votre rseau ;-)
1.4 - Votre travail
La seule et unique tche que je vous demanderai d'accomplir sera de corriger mes erreurs (aussi bien dans la
cohrence des lments avancs que pour l'orthographe), me donner des conseils sur ce qui est mal expliqu
pour le rendre plus accessible, ajouter des lments qui ont trait aux masques et rendent l'expos plus complet,
combler tout manque pour amliorer ce cours.
2 - Dfinitions
2.1 - L'identification des machines
Pour envoyer du courrier un ami, vous utilisez son adresse postale. Ainsi vous tes sr que le paquet que vous
envoyez arrivera la bonne personne. Et bien pour les ordinateurs, c'est pareil. Quand vous connectez votre
ordinateur un rseau (Internet par exemple), il possde une adresse qui l'identifie d'une faon unique pour que
les autres ordinateurs du rseau puissent lui envoyer des informations.
2.2 - La segmentation des rseaux
Imaginez un norme rseau comme Internet o chacune des machines serait oblige de connatre l'ensemble des
millions d'autres machines (et notamment leurs adresses) et de savoir comment y accder. Cela obligerait nos
pauvres ordinateurs avoir des tables normes contenant l'ensemble de ces informations. Cela induirait aussi des
temps
de
rponses
trs
grands
pour
parcourir
cette
table.
Pour rpondre cette problmatique, on a segment cet norme rseau en diffrents petits rseaux. Et c'est au
sein de ces petits rseaux que l'on donne des adresses aux machines pour leur envoyer l'information. Ainsi, il
suffit de connatre l'adresse du rseau pour envoyer l'information une machine de celui-ci, et c'est l'intrieur
de
ce
rseau
que
l'information
sera
redirige
vers
la
bonne
machine.
C'est exactement comme lorsque vous envoyez un paquet par la poste, vous mettez le nom de la ville, le paquet
arrive la poste de la ville, et c'est elle qui distribue le paquet la bonne adresse.
2.3 - Une seule adresse pour le prix de deux
Comme vous l'avez compris, il nous faut deux adresses pour identifier une machine, une pour le rseau et une
pour la machine elle-mme. Cependant, l'adressage qui a t choisi pour les machines ne dfinit qu'une seule
adresse. Vous me direz que ce n'est pas suffisant. Et bien si ! Il suffit de segmenter cette adresse en deux parties
distinctes, l'une pour le rseau, et l'autre pour la machine. C'est l o le masque entre en jeu, c'est lui qui joue le
rle de sparateur entre ces deux adresses.
2.4 - Dfinition empirique du masque
Le masque est un sparateur entre la partie rseau et la partie machine d'une adresse IP.
2.5 - Pourquoi matriser les masques ?
L'utilisation et la matrise des masques doivent pouvoir vous permettre d'une part, de savoir ce que vous
manipulez, et d'autre part d'optimiser le fonctionnement de votre rseau. Effectivement, l'utilisation des masques
vous permettra de segmenter de la faon la plus correcte l'adressage de votre rseau, et ainsi de sparer les
machines sensibles du reste du rseau, limiter les congestions, et prvoir l'volution de votre rseau, etc.
Malheureusement, la sparation d'un rseau en plusieurs sous-rseaux n'a pas que des avantages. L'un des
inconvnients majeurs est notamment la complexification des tables de routage tant donn le plus grand nombre
de rseaux router.
3 - Adresse IP et masque
3.1 - L'adressage IP
Nous avons parl d'adresses pour les machines, il est temps maintenant de dfinir ces adresses. On parle
d'adresse IP (Internet protocol), car il s'agit du protocole qui permet d'identifier les machines et de router les
informations sur Internet. Ces adresses sont codes sur 4 octets (voir chapitre 4 sur le codage binaire) et sont la
plupart du temps crites en numrotation dcimale en sparant les octets par des points. Ca donne quelque chose
comme a: 192.168.132.24
4 - Le codage
4.1 - Le codage binaire
Nous utilisons tous les jours un systme de numration dcimale. Avec donc 10 symboles (0123456789) qui nous
permettent d'numrer toute sorte de nombres en les plaant dans un certain ordre. Cette place est primordiale
puisqu'elle reprsente le passage aux dizaines, centaines, milliers, etc. Ainsi, tout nombre peut se dcomposer en
puissances
de
10,
par
exemple:
324
300
20
+4
3*10^2
2*10^1
4*10^0
Cependant, il existe d'autres modes selon la base dans laquelle on se place. Lorsque l'on utilise la base 2, on se
place en numration binaire o seuls deux symboles sont utiliss (01) On peut, de la mme faon, dcomposer
tout
nombre
en
puissance
de
2.
324
=
256
=
1*2^8
+
0*2^7
+ 0*2^3 + 1*2^2 + 0*2^1 + 0*2^0
+
1*2^6
64
+
+
+
0*2^5
4
0*2^4
adresse
peut
11000000.10101000.00011001.10000100
192 .
168
aussi
.
bien
s'crire
25
en
.
binaire:
132
Nous verrons par la suite pourquoi il est utile de revenir cette notation pour bien comprendre le fonctionnement
des masques.
5 - Les masques
5.1 - Rcapitulatif
Nous avons dj vu plusieurs aspects importants des masques qu'il faudra toujours essayer de garder l'esprit:
Cods
sur
4
octets,
soit
32
bits,
- Ils permettent de faire la sparation entre la partie rseau et la partie machine de l'adresse IP,
- La partie rseau est reprsente par des bits 1, et la partie machine par des bits 0,
- Le masque ne reprsente rien sans l'adresse IP laquelle il est associ.
5.2 - Comment reprsente-t-on un masque ?
Comme
le
masque
est
cod
32
bits,
voici
__________Rseau__________
|
|
Ce
sur
qui
s'crit
un
exemple
possible
de
masque:
_Machine
|
|
11111111.11111111.11111111.00000000
en
dcimal
255.255.255.0
Maintenant, plusieurs questions peuvent se poser. Jusqu'ici je comprends, mais comment je peux associer ce
masque une adresse IP, et quel sera le rsultat ? Pourquoi les bits 1 sont spars de ceux 0 ?
5.3 - Comment le masque et l'adresse IP sont-ils associs ?
Prenons par exemple une machine qui a pour adresse IP 192.168.25.147. Il nous faut lui associer un masque pour
savoir quelle partie de cette adresse reprsente le rseau. Associons-lui le masque prcdent 255.255.255.0. On
remarque que les bits des trois premiers octets sont 1, ils reprsentent donc la partie rseau de l'adresse, soit
192.168.25, le 147 permettant d'identifier la machine au sein de ce rseau. Dans cet exemple, on remarque qu'un
octet a t rserv pour l'adresse machine, ce qui nous donne 2^8 = 256 adresses disponibles pour les machines
sur
le
rseau 192.168.25.
Les
adresses
disponibles
pour
les
machines
seront
donc:
192.168.25.0
192.168.25.1
...
192.168.25.254
192.168.25.255
(rserve
pour
(rserve
pour
le
le
rseau,
voir
broadcast,
voir
5.4)
5.4)
On observe donc que c'est le masque qui dtermine le nombre de machines d'un rseau. Ainsi, on verra par la
suite qu'on choisira le masque en fonction du nombre de machines que l'on veut installer.
5.4 - Adresses spcifiques (rseau, broadcast)
Il existe des adresses spcifiques au sein d'un rseau. La premire adresse d'une plage ainsi que la dernire ont
un rle particulier. La premire adresse d'une plage reprsente l'adresse du rseau. Celle-ci est trs importante
car c'est grce elle qu'on peut identifier les rseaux et router les informations d'un rseau un autre. La
dernire adresse d'une plage reprsente ce que l'on appelle l'adresse de broadcast. Cette adresse est celle
qui permet de faire de la diffusion toutes les machines du rseau. Ainsi, quand on veut envoyer une information
toutes
les
machines,
on
utilise
cette
adresse.
Dans notre exemple, l'adresse de rseau sera donc 192.168.25.0, et l'adresse de broadcast 192.168.25.255. On
remarque donc qu'il ne nous reste plus que 254 adresses pour identifier nos machines. Ainsi, chaque fois que
l'on choisira un masque en fonction du nombre de machines que l'on veut adresser, il faudra tenir compte de ces
deux adresses...
5.5 - Les bits 1 et 0 doivent ils tre contigus ?
Dans l'exemple de masque que nous avons choisi, nous avons vu que les bits 0 et 1 taient regroups. Cela
n'est pas une obligation, mais cela facilite normment l'exploitation du rseau. En conservant la contigut des
bits, les adresses de nos machines au sein du rseau se suivent. Ce ne serait pas le cas si l'on avait choisi un
masque
avec
des
bits
non
contigus.
Exemple,
si
on
choisit
le
masque
suivant:
11111111.11111111.11111110.00000001
Ici, on a comme prcdemment 8 bits qui reprsentent la partie machine, par contre, ils ne sont plus la mme
place. Cela se traduit en dcimal par le masque suivant 255.255.254.1. On voit donc que les adresses dont le
dernier bit est a 1 ne seront pas dans le mme rseau que celles dont le dernier bit est a 0. Ce qui veut dire que
les adresses dont le dernier octet est impair ne seront pas dans le mme rseau que les adresses paires. Dans cet
exemple, cela reste encore facile de diffrencier les adresses paires et impaires, mais lorsque l'on fait des
mlanges plus compliqus entre les bits significatifs, cela devient trs vite inextricable. On conservera donc
toujours la contigut des bits significatifs !!!
5.6 - Quelles adresses pour les masques ?
Etant donn que l'on conserve la contigut des bits, on va toujours rencontrer les mmes nombres pour les octets
du
masque.
Ce
sont
les
suivants:
11111111
11111110
11111100
...
10000000
00000000
Soit
255,
en
254,
252,
248,
dcimal:
240,
224,
192,
128,
et
0.
Ainsi, on peut tout de suite dire si un masque semble valide au premier coup d'oeil. Un masque en 255.255.224.0
sera correct alors qu'un masque en 255.255.232.0 ne le sera pas ( moins de ne pas vouloir respecter la
contigut
des
bits)
Vous pouvez aller voir tous les masques possibles dans la RFC suivante: Rfc 1878
5.7 - Faire fi de l'criture par octets
L'criture de l'adresse IP selon 4 octets spars par un point est facile utiliser. Mais quand on se penche sur le
problme d'un peu plus prs, on se rend compte qu'elle n'est pas trs adapte... Elle a deux dfauts principaux:
-
Ecriture
en
Sparation
dcimal
des
alors
que
octets
l'on
raisonne
par
en
des
binaire
points
Ainsi, lorsqu'on utilise des masques o la sparation rseau/machine se fait sur un octet (tous les bits des octets
sont soit 1, soit 0) cela est simple. Prenons par exemple le rseau 192.168.25.0/255.255.255.0. Toutes les
machines commenant par 192.168.25 appartiendront ce rseau. Si l'on prend le rseau
192.168.25.32/255.255.255.248 et je vous demande si la machine 192.168.25.47 appartient ce rseau ? a
devient
plus
compliqu...
Pour bien comprendre, il faut alors revenir en binaire. Etant donn que les trois premiers octets du masque ont
tous leurs bits 1, c'est sur le quatrime que va se faire la diffrentiation. Il s'crit 248, soit 11111000 en binaire.
Donc
les
5
premiers
bits
de
cet
octet
reprsenteront
la
partie
rseau.
Pour notre rseau, le dernier octet vaut 32, soit 00100000, pour notre machine, il vaut 47, soit 00101111. On voit
que les 5 premiers bits de ces deux octets ne sont pas identiques (00100 != 00101) et donc que ces deux
adresses n'appartiennent pas au mme rseau. Cela peut sembler trs compliqu, mais on verra par la suite des
mthodes simples pour dterminer rapidement l'appartenance un rseau.
5.8 - Quelle est cette notation avec un /, comme /24 ?
Une autre notation est souvent utilise pour reprsenter les masques. On la rencontre souvent car elle est plus
rapide crire. Dans celle-ci, on note directement le nombre de bits significatifs en dcimal, en considrant que la
contigut est respecte. Ainsi, pour notre exemple 192.168.25.0/255.255.255.0, on peut aussi crire
192.168.25.0/24,
car
24
bits
sont
significatifs
de
la
partie
rseau
de
l'adresse.
De
mme,
les
10.0.0.0/255.0.0.0
192.168.25.32/255.255.255.248
critures
suivantes
=
=
sont
quivalentes:
10.0.0.0/8
192.168.25.32/29
Etant donn que le masque dtermine le nombre de machines qu'il pourra y avoir sur un rseau, c'est souvent de
cette information que l'on part pour choisir le masque. Etant donn que l'on travail en binaire, le nombre de
machines possible au sein d'un rseau sera une puissance de 2. Pour un nombre de machines donn, il faudra
donc choisir la puissance de 2 suprieure pour pouvoir adresser les machines. De plus, il faudra prvoir un certain
nombre
d'adresses
supplmentaires
pour
accueillir
de
nouvelles
machines.
Ainsi, disons que l'on possde le rseau 193.225.34.0/255.255.255.0 et que l'on veut faire un rseau de 60
machines au sein de celui-ci. On veut 60 machines, il faut ajouter deux adresses pour le rseau et le broadcast, ce
qui fait 62 adresses au total. La puissance de 2 suprieure 62 est 64, mais cela ne nous laisserait que 2
adresses pour voluer, ce qui est un peu juste. On prfrera donc un rseau de 128 adresses. Pour identifier 128
adresses, il nous faut 7 bits (128 = 2^7) Donc dans notre masque, 7 bits seront 0 pour identifier la partie
machine,
et
les
25
bits
restants
seront
1.
Ce
qui
donne:
11111111.11111111.11111111.10000000
et en dcimal 255.255.255.128.
1.
Ce
qui
donne:
11111111.11111111.11111111.10000000
et en dcimal 255.255.255.128
6.3 - Comment dterminer la plage d'adresses partir du masque et d'une adresse ?
Nous avons vu prcdemment que le masque devait tre associ une adresse IP pour avoir une valeur. Le choix
de la plage d'adresses sur laquelle il s'applique est donc tout aussi important !! Nous avons choisi un masque qui
nous permettra d'identifier 128 machines. Mais nous possdons une plage de 256 adresses. O faut-il placer nos
128
adresses
dans
cette
plage
?
Peut-on
les
placer
n'importe
o
?
La rponse est bien sr non. Nous n'avons que deux possibilits pour choisir notre plage, les adresses de 0 127,
et les adresses de 128 255. Choisir une plage de 32 160 serait une erreur, et le rseau ne fonctionnerait pas.
Voici
l'explication:
La diffrenciation du rseau va se faire sur le premier bit du dernier octet (vu que nos trois premiers octets sont
fixs 193.225.34) Si ce bit est 0, cela correspond aux adresses de 0 127. S'il est 1, cela correspond aux
adresses de 128 255. Ainsi, si l'on choisit une plage d'adresses de 32 160, les adresses de 32 127 auront le
premier bit de leur dernier octet 0, alors que les adresses de 128 160 auront ce mme bit 1, elles seront
alors
considres
comme
tant
dans
deux
rseaux
diffrents
!!!
Ainsi, quel que soit le nombre de machines placer dans une plage, on ne peut pas choisir l'adressage n'importe
comment.
PS: Dans notre cas, les deux choix possibles sont identiques, mais l'on verra par la suite que ce n'est pas toujours
le cas pour des plages plus petites...
6.4 - Une mthode simple pour trouver les adresses de rseau possible
Il n'est pas toujours vident de savoir si une adresse correspond bien celle d'un rseau selon le masque que l'on
a choisi. Avec la mthode suivante, vous devriez pouvoir vous en sortir. Il faut avant tout que vous ayez
dtermin le masque selon le nombre de machines dont vous avez besoin. Ensuite, selon l'octet significatif (qui
n'est pas 0 ou 255) faites 256-cet_octet=X. L'adresse de rseau devra alors tre un multiple de X. Un petit
exemple pour tre un peu plus clair. On veut par exemple 50 machines, on choisit donc un masque en
255.255.255.192. C'est le dernier octet qui est significatif, on fait donc 256-192=64. Il faut donc que le dernier
octet de l'adresse de rseau soit un multiple de 64. Si on prend la plage 10.0.0.0/255.255.255.0, on pourra
choisir
les
adresses
de
rseau
suivantes:
10.0.0.0,
10.0.0.64,
10.0.0.128,
10.0.0.192.
6.5 - Comment dcouper une plage rseau quelconque comme somme de plusieurs plages ?
Nous avons vu qu'une plage rseau ne pouvait pas tre choisie n'importe comment. Etant donn que les masques
et les adresses IP se basent sur un codage binaire, les chiffres utiliss dans les adresses rsultantes ne pourront
tre que des multiples de puissances de 2 en accord avec le masque. Ainsi, une plage 70.0.0.0 ne pourra pas
avoir un masque qui dfinisse plus de deux chiffres sur le premier octet, car 70 est un multiple de 2, mais pas de
4.
Ce n'est pas clair ? un exemple devrait vous aider mieux comprendre.Disons que l'on veut dcrire la plage
d'adresses
allant
de
69.0.0.0
79.255.255.255.
La question est de savoir quel masque associ quelle adresse de rseau nous permettra de dfinir cette plage.
Le premier octet varie de 69 79. Il prend donc 11 valeurs. 11 n'tant pas une puissance de 2, on sait d'ores et
dj que l'on ne pourra pas dfinir cette plage avec un seul rseau, mais qu'il va falloir la dcouper en une somme
de plusieurs rseaux. Le but est cependant d'optimiser cette somme de rseaux pour en avoir le moins possible.
On pourrait simplement utiliser 11 rseaux avec des masques 255.0.0.0, mais on doit srement pouvoir faire plus
propre
et
regrouper
plusieurs
de
ces
rseaux
en
un
seul.
La premire puissance de 2 infrieure 11 est 8. Il faut maintenant savoir si l'on peut placer un rseau, dont le
premier octet dcrira 8 valeurs, dans cette plage. Le seul multiple de 8 de cette plage est 72. On dcrirait alors un
rseau dont le premier octet varierait de 72 79, ce qui est bien compris dans notre plage d'origine. Le rseau
72.0.0.0/248.0.0.0 est donc bien adapt pour dcrire notre plage, mais il reste encore dcrire les adresses de
69.0.0.0
71.255.255.255.
On effectue le mme raisonnement. (Ici le premier octet prend 3 valeurs, la puissance de 2 infrieure 3 est 2, et
le
multiple
de
2
de
cette
plage
est
70)
On
trouve
donc
le
rseau
70.0.0.0/254.0.0.0
Il ne nous reste plus qu' dcrire la plage 69.0.0.0 69.255.255.255 qui peut tre dfinie par 69.0.0.0/255.0.0.0.
Et voil !! Nous avons dcoup notre plage d'origine qui allait de 69.0.0.0 79.255.255.255 en trois sousrseaux:
69.0.0.0/255.0.0.0
70.0.0.0/254.0.0.0
et 72.0.0.0/248.0.0.0
6.6 - Plages rserves (Rfc 1918)
Certaines plages d'adresses ont t rserves pour une utilisation locale. Ainsi, pour configurer un rseau local
quand on n'a pas de plage d'adresses publiques disposition, on doit utiliser ces plages d'adresses prives. Si
vous voulez avoir plusieurs rseaux, c'est vous de faire le dcoupage au sein de ces plages comme bon vous
semble.
Voici
10.0.0.0/255.0.0.0
192.168.0.0/255.255.0.0
172.16.0.0/255.240.0.0
ces
soit
plages
plus
soit
soit
de
prs
plus
16
de
d'un
d'adresses:
millions
65000
million
d'adresses
adresses
d'adresses
Si aprs vous ne trouvez pas votre bonheur, c'est que vous avez un sacrment grand rseau, ou que vous vous y
prenez
mal...
Rfc 1918
la
fin
qu'ils
sont
incompatibles...
Ainsi nous allons encore partir du nombre de machines dans chacun des rseaux. Prenons l'exemple prcdent du
rseau 193.225.34.0/255.255.255.0. On dsire comme prcdemment faire un sous-rseau de 60 machines, mais
aussi un rseaux de 44 machines et un dernier de 20 machines. De la mme faon que nous l'avons vu
prcdemment, pour 44 machines, il faudra rserver 64 adresses, soit un masque 255.255.255.192. Pour 20
machines, il faudra rserver 32 adresses, soit un masque 255.255.255.224.
7.2 - Dtermination des plages rseau
Nous allons donc devoir placer trois plages de 128, 64 et 32 adresses dans une plage de 256 adresses, cela ne
devrait
pas
poser
de
problme.
On commence par la plage la plus grande de 128 adresses. Si on commenait par la plus petite et qu'on la plaait
n'importe o, cela pourrait poser problme. Imaginons que l'on place la plage de 32 adresses de 0 31, et celle
de 64 adresses de 128 192, il ne nous resterai plus de place pour la plage de 128 adresses !!! On a donc deux
choix pour cette plage de 128 adresses, soit les adresses de 0 127, soit de 128 255. A priori, les deux choix
sont possibles et non dterminants. On choisit de 0 127. Ainsi, notre sous-rseau sera caractris par
193.225.34.0/255.255.255.128.
Pour la seconde plage de 64 adresses, il nous reste deux plages d'adresses possibles, de 128 191, et de 192
255. L encore le choix n'est pas dterminant. On choisit de 128 191. Ainsi, notre sous-rseau sera caractris
par
193.225.34.128/255.255.255.192
(ici, la premire adresse de notre plage (l adresse du rseau)est celle en 128 et le dernier octet du masque en
192
nous
indique
que
ce
sous-rseau
contient
64
adresses)
Enfin, pour la dernire plage de 32 adresses, il nous reste encore deux possibilits de 192 223 ou de 224 255.
On choisit de 192 223. Ainsi, notre sous-rseau sera caractris par 193.225.34.192/255.255.255.224
7.3 - Le rsultat
Nous
avons
donc
dcoup
notre
rseau
d'origine
193.225.34.0/255.255.255.0
en
trois
sous-rseaux
193.225.34.0/255.255.255.128
193.225.34.128/255.255.255.192
193.225.34.192/255.255.255.224
Il nous reste mme une plage de 32 adresses non utilises de 224 255.
126.255.255.255
soit
16
777
214
adresses
par
rseau
de
classe
A
Classe B: Deux premiers bits de l'adresse 10 (1 et 0), et masque de sous-rseau en 255.255.0.0. Ce qui donne
la plage d'adresse 128.0.0.0 191.255.255.255 soit 65 534 adresses par rseau de classe B
Classe C: Trois premiers bits de l'adresse 110, et masque de sous-rseau en 255.255.255.0. Ce qui donne la
plage
d'adresse
192.0.0.0
223.255.255.255
soit
255
adresses
par
rseau
de
classe
C
Classe D: Quatre premiers bits de l'adresse 1110, et masque de sous-rseau en 255.255.255.240. Ce qui donne
la plage d'adresse 224.0.0.0 239.255.255.255 soit 255 adresses par rseau de classe D
Classe E: Quatre premiers bits de l'adresse 1111, et masque de sous-rseau en 255.255.255.240. Ce qui donne
la
plage
d'adresse
240.0.0.0
255.255.255.255
Les classes A, B et C, sont rserves pour les utilisateurs d'Internet (entreprises, administrations, fournisseurs
d'accs, etc) La classe D est rserve pour les flux multicast et la classe E n'est pas utilise aujourd'hui (du moins,
je
n'en
ai
pas
connaissance...)
Ainsi, une entreprise demandant 80 000 adresses se voyait attribuer un rseau de classe A, et gchait par la
mme occasion (16 777 214 - 80 000=) 16 697 214 adresses !!! Inutile alors de vous montrer combien
d'adresses taient perdues de la sorte...
rponse
est
non.
Il n'y a pas aujourd'hui de pnurie d'adresses IP. Cependant, il est certain qu'tant donn le dveloppement
rapide d'Internet, on va vite arriver une situation critique. C'est aussi pour cela qu'une nouvelle version d'IP a
t cre et sera bientt dploye.
8.4 - Le systme d'adressage par classes est-il viable ?
La rponse est encore non, et a dj t depuis bien longtemps tudi et transform. Nous avons vu qu'en se
basant sur ce systme de classes, nous risquons de gcher un trs grand nombre d'adresses. Les classes
d'adresses globales se sont donc rapidement avres obsoltes et on a du crer un nouveau modle, l'adressage
CIDR
8.5 - Qu'est-ce que l'adressage CIDR ?
Etant donn que l'adressage par classes s'est avr incompatible avec l'volution d'Internet, il a fallu imaginer un
nouveau modle qui simplifie la fois le routage et permette un adressage plus fin. Pour cela, on a cr
l'adressage CIDR (Classless Inter-Domain Routing). Cet adressage ne tient pas compte des classes globales et
autorise l'utilisation de sous-rseaux au sein de toutes les classes d'adresses. Ainsi, une entreprise dsirant 80
000 adresses ne se verra plus attribuer une classe A complte, mais un sous-rseau de cette classe A. Par
exemple, on lui fournira non plus 16 millions d'adresses, mais 130 000 (la puissance de deux suprieure 80
000) Ainsi les 16 millions d'adresses restantes pourront tre utilises pour d'autres entits.
L'adressage CIDR ne tient donc plus du tout compte des masques associs aux classes d'adresses globales. On
s'affranchit ainsi du dcoupage arbitraire et peu flexible en classes. On peut trs bien trouver un rseau de classe
B avec un masque de classe C, par exemple 164.23.0.0/255.255.255.0.
mme
192.168.0.128
avec
les
deux
autres
adresses
192.168.0.20
255.255.255.128
-------------------
192.168.0.0
et
ET
Pour
pour
192.168.0.185
255.255.255.128
------------------192.168.0.128
On voit ainsi que les nombres obtenus sont les mmes pour ma machine et B. On en dduit donc que B est sur le
mme rseau, et que A est sur un rseau diffrent.
9.2 - Des machines sur un mme rseau peuvent-elles avoir des masques diffrents ?
A priori, la rponse est non. Cependant, il peut y avoir des cas dans lesquels une telle configuration peut tre
utile.
Pour comprendre cela, il faut comprendre ce qui se passe au niveau de la communication entre machines, et
notamment sur le fonctionnement du modle TCP/IP. Celui-ci ne faisant pas partie de l'objet du cours, nous ne
ferons
que
survoler
le
sujet.
En fait, ce ne sont pas les mmes mcanismes qui grent une communication entre deux machines sur un mme
rseau, et deux machines sur deux rseaux distincts. Une communication a lieu dans les deux sens, c'est dire
que pour communiquer ensemble, une machine A doit voir une machine B _ET_ la machine B doit voir la machine
A.
Prenons l'exemple de trois machines A, B et C et de la plage d'adresses 192.168.0.0/24. A doit pouvoir
communiquer avec B et C, mais B ne doit pas pouvoir communiquer avec C. Pour cela, on peut jouer sur les
masques
des
machines
et
les
plages
d'adresses
rseau
auxquelles
elles
appartiennent.
Grce aux masques, on peut dcouper cette plage en deux, et on obtient ainsi, non plus une plage d'adresses...
mais
trois
!
La
La
La
1ere: 192.168.0.0/255.255.255.0
2ieme:
3ieme:
soit
de
192.168.0.0
192.168.0.0/255.255.255.128
soit
de
192.168.0.0
192.168.0.128/255.255.255.128
soit
de
192.168.0.128
192.168.0.255
192.168.0.127
192.168.0.255
En fait, la premire plage englobe les deux autres, ainsi, une machine de la premire plage pourra voir toutes les
autres machines des autres plages, mais une machine de la seconde plage ne pourra pas voir toutes les machines
de
la
premire
plage
(seulement
la
moiti
des
adresses...)
Ce
On
n'est
donne
pas
les
clair
adresses
?
suivantes
A:
192.168.0.129/255.255.255.0
B:
192.168.0.130/255.255.255.128
C:
192.168.0.1/255.255.255.0
regardons
aux
alors
machines
un
A,
Plage
Plage
Plage
exemple:
B
et
C.
1
2
1
D'aprs ce que l'on a vu prcdemment, la plage 2 sera englobe dans la plage 1, et donc A et C considreront
que la machine B est sur leur rseau. A ayant une adresse dans la mme plage que B (plage 2), B verra A comme
tant aussi dans son rseau. Par contre, B ne considrera pas que C est dans rseau car l'adresse de C
n'appartient pas la plage 2. Ainsi, C peut envoyer un paquet B (C voit bien B comme tant dans son rseau)
mais B ne pourra pas lui rpondre. Cette configuration correspond donc bien ce que l'on cherchait faire.
Cependant, une telle configuration n'est pas conseille et ne doit tre utilise que s'il n'y a pas d'autres solutions.
En dehors de cas exotiques comme celui expos, on ne doit jamais avoir deux machines appartenant un mme
rseau ayant des masques diffrents !
9.3 - Puis-je utiliser un outil qui calcule pour moi ?
Non !!! Enfin si, mais bon, vous me dcevriez beaucoup ;-) Car aprs ce que nous avons vu, vous devriez tre
capable de calculer n'importe quel masque correct aussi vite qu'une machine. Et il est toujours mieux de bien
matriser ce qu'on utilise. force d'utiliser des automates, on perd les notions de ce que l'on manipule.
D'autre part, un logiciel ne corrigera pas vos erreurs ! La plupart des logiciels de calcul de masque ne font qu'un
calcul bte et mchant qui peut s'avrer faux. Prenons l'exemple du 6.3, ou l'on veut une plage commenant en
192.168.0.32,
et
une
centaine
de
machines.
Un
mauvais
logiciel
vous
sortira
le
rseau
192.168.0.32/255.255.255.128, et hop, a marchera pas...
9.4 - Tout a c'est bien, mais quand est ce que je l'utilise ce masque moi ?
Effectivement, quand vous allez sur Internet, vous utilisez un masque sans le savoir. Sous Windows, que vous
soyez connect un rseau local, ou directement par un modem, vous pourrez voir les proprits de vos
interfaces rseau en allant dans une fentre DOS et en entrant la commande "ipconfig /all" Vous pouvez aussi
modifier ces proprits en allant dans les proprits de votre carte rseau, puis proprits TCP/IP, et l, vous
devriez voir votre adresse IP, ainsi que le masque associ, et votre passerelle par dfaut. Vous pouvez modifier
ces informations, mais votre rseau risque de ne plus fonctionner (et en plus il faudra rebooter sous 98..) donc
attention
!!
Le masque dfinit donc les machines (ou plus prcisment, les interfaces) appartenant un mme rseau. Pour
dialoguer avec ces machines, vous utiliserez un des mcanismes de couche 2 du modle OSI, alors que pour
dialoguer avec les machines d'un autre rseau, vous aurez besoin d'utiliser des mcanismes de couche 3
qui permettent notamment de faire du routage... Il est donc primordial de ne pas se tromper dans le choix du
masque.
Mais a, a ne fait pas partie intgrante du sujet ;-)
10 - Mini lexique
10.1 - Adresse IP
L'adresse IP est un numro cod sur 4 octets permettant d'identifier une machine de faon unique sur le rseau.
10.2 - Rseau logique
On appelle rseau logique un ensemble d'adresses IP appartenant une mme plage d'adresses. Cette plage est
notamment dfinie par l'adresse de rseau et le masque associ.
10.3 - sous-rseau
On dfinit un sous-rseau comme un sous-ensemble d'une plage d'adresses rseau. C'est grce au masque que
l'on peut dfinir un sous-rseau au sein d'un rseau, et ainsi dcouper un rseau en plusieurs sous-rseaux.
10.4 - Le ET logique
La fonction de ET logiques est souvent utilise dans les masques. Elle se base en binaire sur le principe suivant:
0
1
0
1
ET
ET
ET
ET
0
0
1
1
=
=
=
=
0
0
0
1
On peut donc en dduire au niveau des masques 192.168.0.140 ET 255.255.255.128 dcompos en:
11000000.10101000.00000000.10001100
11111111.11111111.11111111.10000000
-----------------------------------------------11000000.10101000.00000000.10000000
ET
=
soit
192
168
128
Ici, on voit que les trois premiers octets du masque ont tous leurs bits 1, donc les trois premiers octets du
rsultat ne seront pas modifis par rapport l'adresse d'origine, et on obtient facilement 192.168.0. Pour le
dernier octet, il faut regarder plus en dtail.
11 - Annexes
11.1 - Ressources utilises
Je n'ai pas utilis beaucoup de documents aussi bien en ligne que sur papier. Les rponses et connaissances
apportes proviennent en majeure partie des informations que j'ai pu glaner en furetant sur le net, et notamment
sur
les
newgroups
fr.comp.reseaux.ip
et
fr.comp.reseaux.ethernet.
Je
Les
Le
me
RFCs
suis
943
quand
(remplac
mme
en
1992
inspir
de
quelques
documents:
par
la Rfc
1340), 1517, 1518, 1519, 1878.
site http://www.captage.com/tajan/articles/ip.htm
Et l'excellente faq sur les firewalls de Stphane Catteau dont je me suis inspir pour la mise en forme. Disponible
sur: http://fr.comp.securite.free.fr/firewall.txt N'hsitez pas la consulter, on y apprend plein de choses.
11.2 - Remerciements
Je remercie notamment les personnes suivantes pour leur lecture assidue du cours durant sa ralisation et leurs
conseils
prcieux.
Jad Chantiri, Pierrick Vodoz, Laurent de Soras, Stphane Catteau, Cdric Blancher, Ohmforce, Franck Bacquet,
Olivier Lamer, Diane Guinnepain, JC, Alain Winestel, thierry Bellemare, Alex A, Hubert Quarantel-Colombani,
Tony.
12 - Conclusion
J'ai fait de mon mieux pour rendre la notion de masques la plus abordable possible et traiter le sujet de la meilleure
faon. Je me rends compte que ce cours est assez fourni en information et pas toujours facile digrer. Vos remarques
sont donc encore et toujours les bienvenues, aussi bien pour y ajouter des ides, que pour enlever le superflu.
Maintenant, si je revois passer des questions sur les masques, j'aurai au minimum un droit de flagellation sur les
personnes incrimines ;-)
IP sur BlueTooth
1 - Introduction
1.1 - Historique
1.2 - Prsentation de bluetooth
2 - Prsentation de Bluetooth du point de vue technique
2.1 - Bluetooth Radio et Baseband / Link Controller
2.1.1 - Liaison connexion synchrone oriente (SCO)
2.1.2 - Liaison connexion asynchrone (ACL)
2.2 - L2CAP
2.3 - SDP (Service discovery Protocol)
2.3.1 - Mode de dtection
2.3.2 - Stockage des informations
2.3.3 - Contrle des erreurs
3 - GAP profile
4 - Bluetooth IP
4.1 - RFCOMM
4.2 - Utilisation de BNEP
4.3 - Poste mobile esclave
4.4 - Poste mobile matre
4.5 - Adaptation de la couche IP pour priphriques mobiles
4.6 - Adaptation de la couche IP pour la station de base
5 - Rfrences
6 - Discussion autour de la documentation
7 - Suivi du document
1 - Introduction
1.1 - Historique
Fvrier 1998 : Cration du Bluetooth SIG, les principaux constructeurs prsents dans ce groupe sont
Ericsson, IBM, Intel, Nokia, Toshiba
Mai 1998 : Annonce publique du Bluetooth SIG
Juillet 1999 : Le groupe Bluetooth SIG publie la spcification 1.0A
Dcembre 1999 : Sortie de la version 1.0B
Dcembre 1999 : Le groupe Bluetooth SIG compte maintenant 9 socit aprs que 3COM, Lucent,
Microsoft, Motorola les ai rejoint.
En 2004 : Le groupe Bluetooth SIG compte maintenant plus de 2000 socits.
1.2 - Prsentation de bluetooth
Prsentation
du
domaine
d'application
de
Bluetooth
en
informatique
Bluetooth voit aussi son application pour la tlvision et galement dans d'autres domaines o les cbles sont trs
utiliss. La suite de ce document sera surtout ax sur l'utilisation de Bluetooth dans l'informatique.
Buts et caractristiques de cette technologie :
Il s'agit d'une technologie destine remplacer les cbles.
Dans sa version 1 le dbit ne dpasse pas 1Mb/s (La version 2 fonctionnera 10Mb/s).
La porte est de l'ordre de 10m dans la version 1 (Le version 2 prvoie des distances de 100m).
Pourquoi ne pas utiliser Wi-fi tant donnes les performances de Bluetooth : Bluetooth offre l'avantage de la
consommation, en effet la connexion sans fil est surtout utilise pour les appareils mobiles, et donc n'tant pas
relis directement au secteur. Bluetooth est plus faible consommation que Wi-fi. Le second avantage de cette
technologie est le prix. La cration de Bluetooth SIG ( ) en 1998 regroupait les plus grands constructeurs Ericsson,
IBM, Intel, Nokia, Toshiba. En 2004 on peut compter plus de 2000 socits qui participent au Bluetooth SIG. Au
lancement, le pari de cette technologie tait de russir produire des puce Bluetooth moins de 5$.
des
couches
Bluetooth
Dans cette partie, je vais expliquer les diffrentes couches qui composent Bluetooth.
2.1 - Bluetooth Radio et Baseband / Link Controller
La couche Bluetooth radio est une couche totalement matrielles. L'avantage de Bluetooth en terme radio par
rapport aux autres technologies est l'adaptation qu'il peut raliser en effectuant des sauts de frquences 1600 fois
par seconde. La bande Bluetooth s'tend de 2.402 GHz 2.480GHz. Cela reprsente 79 canaux d'une largeur de
1MHz. En France il est possible d'utiliser uniquement 23 canaux. Ces sauts de frquences permettent de limiter les
collisions. Un rseau Bluetooth est compos d'un Matre et de plusieurs esclaves. Un matre peut avoir jusqu'a 7
esclaves. Pour permettre la cration de grands rseaux, un matre peut tre esclave d'un autre rseau. Dans la
norme
Bluetooth
un
matre
et
ses
esclaves
sont
appels
piconet.
Reprsentation
des
piconets
Les lments Bluetooth d'un mme piconet utilisent le mme canal. Pour permettre la discussion de tous les
lments du piconet, il y a une rpartition en time slots de 625 micro secondes. Chronogramme d'une discussion
entre
lments
Bluetooth
:
de
l'architecture.
Pour faciliter la dcouverte d'lments Bluetooth, les oprations de dcouvertes sont faites entre serveurs de
clients. Un lment Bluetooth peut tre la fois client et serveur. Un client va donc contacter un serveur
Bluetooth et ce serveur Bluetooth va lui envoyer la liste des lments Bluetooth qu'il connat avec les
services dcouverts.
2.3.2 - Stockage des informations
3 - GAP profile
Tout priphrique Bluetooth est obligatoirement plac dans un profil. Les profiles ont t mis en place pour faciliter les
connexions et l'interoprabilit entre les matriels. Un profil va dfinir les couches qui vont tre utilises (RFCOMM,
BNEP,
TCS,...)
Il existe 13 profiles, GAP (Generic Access Profile) qui permet de dtecter des produits Bluetooth, et le SDAP (Service
Discovery Access Profile ) qui a pour but de connatre les services disponibles dans les produits qui ont t dtects par
le GAP. Citons les autres rapidement :
Cordless Telephony Profile
Intercom Profil
Serial Port Profile
Headset Profile
Dial-up Networking Profile
Fax Profile
LAN Access Profile
Generic Object Exchange Profile (GOEP)
Object Push Profile
File Transfer Profile
Synchronisation Profile
Structure des services dcouverts par le GAP :
Son adresse BD_ADDR
Son nom
Sa clef (Bluetooth PIN)
Sa class et son priphrique
4 - Bluetooth IP
IP peut fonctionner au dessus de deux couches : soit au dessus de PPP, cela sous-entend que nous utilisons RFCOMM
en dessous, soit avec BNEP, dans ce cas l BNEP repose directement sur L2CAP
4.1 - RFCOMM
Il s'agit d'une couche de transport. Cette couche ralise le rle d'mulation et de multiplexage d'un port srie
(RS232)
sur
la
couche
L2CAP.
Cette
couche
mule
tous
les
signaux
du
port
RS232
(TD,RD,RTS,CTS,DSR,DTR,DCD,RI). Cette couche va assigner chaque application un numro logique qui
correspondra l'mulation d'un port srie. L'utilisation des couches suprieures va dpendre des applications que
l'on souhaite faire fonctionner au-dessus de Bluetooth. Prsentation du spectre o se situe bluetooth. La bande de
frquence rserve Bluetooth en France est de 2.44.65 2.4835. Schma des paquets :
Dans ce cas prcis, la station de base est esclave d'autant de Mobile. Station de base esclave :
de
Bluetooth
IP
pour
l'lments
mobile
Il faut aussi grer la perte de lien. Pour dtecter cela, la spcification Bluetooth propose "Link supervision timer".
Ce compteur est fix une certaine valeur et est remis sa valeur initiale chaque rception de paquet. Si aucun
paquet n'est arriv avant l'arrive 0 de ce timer, une alerte est dclenche. Cette valeur est fixe par dfaut
20 minutes, il faut choisir une bonne valeur pour ce timer car une trop faible valeur peut provoquer beaucoup
d'erreurs, et donc une perte de temps en reconnexion. Une valeur trop grande va laisser trop de Mobiles
connects alors qu'ils ne sont plus dans la zone, ou autre.
4.6 - Adaptation de la couche IP pour la station de base
La couche pour la station de base est plus simple que pour le Mobile (figure suivante). De ce ct on retrouve
uniquement deux tats. Son but principal est de maintenir la connexion. Cette couche a aussi pour but de
dcouvrir de nouveaux lments Bluetooth
Configuration : Cet tat a pour but de configurer et d'tablir la connexion. Durant cette phase, la station de
base est matre et le nouvel lment est esclave. A la fin de cet tat, suivant la configuration dcide, la
station de base peut passer esclave. Durant cette phase de configuration, le canal L2CAP est cr et
configur. La configuration du canal est initie par la station de base. Comme expliqu prcdemment, la
station de base va donner sa MTU. La station de base passera ensuite dans l'tat connect aprs
confirmation de cette MTU.
Connected : On retrouve une base de correspondance entre le numro de canal au niveau de L2CAP avec
l'IP associ.
Etats
de
Bluetooth
IP
pour
la
station
de
base
5 - Rfrences
STMicroelectronics, Technical Note Bluetooth Tutorial[en ligne], 2001. Disponible sur :
://www.st.com/stonline/prodpres/dedicate/bluetoot/document/tutorial.pdf> (consult le 24.04.2004).
<http
Simon Baatz, Matthias Frank, Rolf Gpffarth et al , Handoff Support for Mobility with IP Bluetooth[en ligne],
2000. Disponible sur : <http ://web.informatik.uni-bonn.de/IV/Mitarbeiter/baatz/LCN2000_rp.pdf> (consult le
24.04.2004).
ATMEL Corporation, The Bluetooth Wireless Technology White Paper, 2000. Disponible sur : <http
://www.atmel.com/dyn/resources/prod_documents/DOC1991.PDF>(consult le 24.04.2004).
David Kammer, Gordon McNutt, Brian Senese, Bluetooth Application Developer's Guide. Syngress Media, Janvier
2002. 520 Pages. ISBN 1928994423.
Michael Miller, Discovering Bluetooth. Sybex, Juillet 2001. 304 Pages. ISBN : 0-7821-2972-2.
Les services
Dhcp
1 - Dfinition
2 - Rfrences
3
4
5
6
7
Fonctionnement
Les baux
Dynamique ou pas ?
Les requtes et les messages DHCP
Les messages DHCP
7.1 - Dialogue avec le serveur
7.2 - Format de la trame BOOTP/DHCP
7.3 - Passage d'options
8 - Le serveur Dhcp
8.1 - O trouver un serveur DHCP ?
8.2 - Compilation du serveur
8.3 - Le fichier dhcpd.conf
8.3.1 - Les paramtres globaux
8.3.2 - shared-network
8.3.3 - subnet
8.3.4 - host
8.3.5 - group
8.3.6 - Les options
8.3.7 - Exemple de fichier dhcpd.conf
8.4 - Lancer le dmon dhcpd
8.5 - Excuter le dmon chaque dmarrage (pour Linux)
8.6 - Documentation
9 - Configuration des clients
9.1 - Tout pour contrler, rparer etc
9.2 - Windows 95/98
9.2.1 - Configuration
9.2.2 - Vrification
9.3 - Windows NT4/2000/XP
9.3.1 - Configuration
9.3.2 - Vrification
9.4 - Linux
9.4.1 - Configuration
9.4.2 - Vrifiez l'tat de votre connexion
9.4.3 - Particularits du client DHClient
10 - Savoir "Sniffer"
10.1 - En-ttes de trames
10.2 - Dtail des trames
10.2.1 - Le DHCP Discover
10.2.2 - Un petit ping...
10.2.3 - Offre d'un nouveau bail
10.2.4 - Demande du Bail de la part du client
10.2.5 - Le serveur est d'accord
10.3 - Notes supplmentaires
10.3.1 - Duplication d'adresse
10.3.2 - Pas de rponse
10.4 - Renouvellement d'un bail en cours de validit
10.4.1 - Quand a se passe bien...
10.4.2 - Et quand a se passe mal
11 - Discussion autour de la documentation
12 - Suivi du document
1 - Dfinition
DHCP signifie Dynamic Host Configuration Protocol. Il s'agit d'un protocole qui permet un ordinateur qui se connecte
sur un rseau local d'obtenir dynamiquement et automatiquement sa configuration IP. Le but principal tant la
simplification de l'administration d'un rseau. On voit gnralement le protocole DHCP comme distribuant des adresses
IP, mais il a t conu au dpart comme complment au protocole BOOTP (Bootstrap Protocol) qui est utilis par
exemple lorsque l'on installe une machine travers un rseau (on peut effectivement installer compltement un
ordinateur, et c'est beaucoup plus rapide que de le faire en la main). Cette dernire possibilit est trs intressante
pour la maintenance de gros parcs machines. Les versions actuelles des serveurs DHCP fonctionne pour IPv4 (adresses
IP sur 4 octets). Une spcification pour IPv6 (adresses IP sur 16 octets) est en cours de dveloppement par l'IETF.
2 - Rfrences
Les
incontournables
- RFC951 :
- RFC1497 :
Options
- RFC1541 :
Dfinition
- RFC1542 :
Interaction
entre
- RFC2131 :
Complment
- RFC2132 :
Complment
aux
Spcifications
et
RFCs :
vendor
du
protocole
Bootp
la
options
API
et
Rfc
vendor
Bootp
extensions
Dhcp
Dhcp
1541
extensions
Java : dhcp.org
Le
site
de
Le site de Microsoft : BOOTP, DHCP, DNS servers (en anglais)
l'ISC : http://www.isc.org
3 - Fonctionnement
DHCP fonctionne sur le modle client-serveur : un serveur, qui dtient la politique d'attribution des configurations IP,
envoie une configuration donne pour une dure donne un client donn (typiquement, une machine qui vient de
dmarrer). Le serveur va servir de base pour toutes les requtes DHCP (il les reoit et y rpond), aussi doit-il avoir une
configuration IP fixe. Dans un rseau, on peut donc n'avoir qu'une seule machine avec adresse IP fixe : le serveur
DHCP. Le protocole DHCP s'appuie entirement sur BOOTP : il en reprend le mcanisme de base (ordre des requtes,
mais
aussi
le format
des
messages).
DHCP
est
une
extension
de
BOOTP.
Quand une machine vient de dmarrer, elle n'a pas de configuration rseau (mme pas de configuration par dfaut), et
pourtant, elle doit arriver mettre un message sur le rseau pour qu'on lui donne une vraie configuration. La
technique utilise est le broadcast : pour trouver et dialoguer avec un serveur DHCP, la machine va simplement
mettre un paquet spcial, dit de broadcast, sur l'adresse IP 255.255.255.255 et sur le rseau local. Ce paquet
particulier va tre reu par toutes les machines connectes au rseau (particularit du broadcast). Lorsque le serveur
DHCP reoit ce paquet, il rpond par un autre paquet de broadcast contenant toutes les informations requises pour la
configuration. Si le client accepte la configuration, il renvoit un paquet pour informer le serveur qu'il garde les
paramtres,
sinon,
il
fait
une
nouvelle
demande.
Les choses se passent de la mme faon si le client a dj une adresse IP (ngociation et validation de la
configuration), sauf que le dialogue ne s'tablit plus avec du broadcast.
4 - Les baux
Pour des raisons d'optimisation des ressources rseau, les adresses IP sont dlivres pour une dure limite. C'est ce
qu'on appelle un bail (lease en anglais). Un client qui voit son bail arriver terme peut demander au serveur un
renouvellement du bail. De mme, lorsque le serveur verra un bail arriv terme, il mettra un paquet pour demander
au client s'il veut prolonger son bail. Si le serveur ne reoit pas de rponse valide, il rend disponible l'adresse IP. C'est
toute la subtilit du DHCP : on peut optimiser l'attribution des adresses IP en jouant sur la dure des baux. Le
problme est l : si toutes les adresses sont alloues et si aucune n'est libre au bout d'un certain temps, plus aucune
requte
ne
pourra
tre
satisfaite.
Sur un rseau o beaucoup d'ordinateurs se connectent et se dconnectent souvent (rseau d'cole ou de locaux
commerciaux par exemple), il est intressant de proposer des baux de courte dure. A l'inverse, sur un rseau
constitu en majorit de machines fixes, trs peu souvent rebootes, des baux de longues dures suffisent. N'oubliez
pas que le DHCP marche principalement par broadcast, et que cela peut bloquer de la bande passante sur des petits
rseaux fortement sollicits.
5 - Dynamique ou pas ?
Un serveur DHCP est cens fournir des adresses dynamiques (un mme ordinateur peut recevoir successivement 2
adresses diffrentes), mais il peut fournir une adresse IP fixe un client bien particulier. Ceci ne doit tre utilis que de
manire modre, sinon, le serveur DHCP ne sert peu prs plus rien, mais cela peut se rvler utile pour fournir
l'adresse IP au serveur TFTP qui va servir pour le boot distance des machines.
La valeur entre parenthses est utilises pour identifier ces requtes dans les messages DHCP. Voir les options DHCP.
La premire requte mise par le client est un message DHCPDISCOVER. Le serveur rpond par un DHCPOFFER, en
particulier pour soumettre une adresse IP au client. Le client tablit sa configuration, demande ventuellement d'autres
paramtres, puis fait un DHCPREQUEST pour valider son adresse IP. Le serveur rpond simplement par un DHCPACK
avec l'adresse IP pour confirmation de l'attribution. Normalement, c'est suffisant pour qu'un client obtienne une
configuration rseau efficace, mais cela peut tre plus ou moins long selon que le client accepte ou non l'adresse IP ou
demande
des
infos
complmentaires...
Pour
demander
une
nouvelle
adresse,
le
chronogramme-type
est
le
suivant :
Pour
renouveler
une
adresse,
le
fonctionnement
est
le
suivant
(les
serveurs
connaissent
le
client) :
op :
vaut
pour
BOOTREQUEST
(requte
client),
pour
BOOTREPLY
(rponse
serveur)
htype :
type
de
l'adresse
hardware
(adresse
MAC,
par
exemple.
Voir Rfc
1340)
hlen : longueur de l'adresse hardware (en octet). C'est 6 pour une adresse MAC
hops :
peut
tre
utilis
par
des
relais
DHCP
- xid : nombre alatoire choisi par le client et qui est utilis pour reconnatre le client
- secs : le temps coul (en secondes) depuis que le client a commenc sa requte
flags :
flags
divers
ciaddr :
adresse
IP
du
client,
lorsqu'il
en
a
dj
une
yiaddr :
la
(future ?)
adresse
IP
du
client
siaddr :
adresse
IP
du
(prochain)
serveur
utiliser
- giaddr : adresse IP du relais (passerelle par exemple) lorsque la connexion directe client/serveur n'est pas
possible
chaddr :
adresse
hardware
du
client
sname :
champ
optionnel.
Nom
du
serveur
ile :
nom
du
fichier
utiliser
pour
le
boot
- options : Champs rserv pour les options (voir Rfc 2132). Dans une prcdente RFC, la taille de ce champ
tait limite (limit 64 octets par exemple pour la premire version de Bootp) ; maintenant, il n'y a plus de
limitation. Dans tous les cas, un client DHCP doit tre prt recevoir au minimum 576 octets, mais la possibilit
lui est offerte de demander au serveur de restreindre la taille de ses messages.
7.3 - Passage d'options
Le passage de paramtres (nom de la machine...) se fait par l'intermdiaires d'options. Les options sont
documentes dans la Rfc 2132. Elles portent toutes un numro qui les identifie. Par exemple, l'option 15 est celle
qui permet de donner au client le nom de domaine du rseau. Il est bien entendu possible d'envoyer plusieurs
options dans le mme message DHCP ; dans tous les cas, que l'on ne transmette qu'une seule option utile ou
plusieurs, on doit toujours finir la zone d'options par une option 255 (end). Le format des options est le suivant :
Le numro de l'option n'est cod que sur 1 octet, donc il ne peut y avoir que 256 options possibles. L'octet 2 code
la longueur du champ de donnes qui suit. Il ne tient donc pas compte des 2 octets de code d'option et de
longueur.
Certaines options ne comportent pas de donnes complmentaires, comme l'option 255. Dans ce cas, il n'y a ni
champ de longueur ni champ de donnes. Les messages DHCP vus dans le chapitre prcdent (DHCPACK...) sont
tout simplement une option ! Il s'agit de l'option 53 qui comporte un champ de donnes de longueur 1 contenant
le numro identifiant la requte (1 pour DHCPDISCOVER...). Les 4 premiers octets du champ d'options doivent
tre initialiss respectivement avec les valeurs 99, 130, 83 et 99 (valeurs en dcimal). Cette squence est appele
le
"magic
cookie"
(gateau
magique
en
franais).
Le client DHCP a la possibilit d'imposer au serveur DHCP une taille maxi pour le champ d'options (option 57). La
consquence d'une telle limitation est que le serveur peut manquer de place pour envoyer toutes les options
souhaites. Pour rpondre ce problme, le serveur est autoris utiliser les champs sname et filepour finir son
envoi. Le client est averti de cet usage par un option 52 dans la zone d'options.
8 - Le serveur Dhcp
8.1 - O trouver un serveur DHCP ?
L'Internet Software Consortium dveloppe un serveur DHCP pour le monde du logiciel libre. C'est le serveur DHCP
le plus rpandu, et celui qui "suit" au mieux les Rfcs. La dernire version en date est la 3.0 et elle est encore en
version bta. Les versions antrieures marchent toutefois trs bien, bien que l'ISC sortent beaucoup de patchs.
L'une des principales innovations de la version 3 est la possibilit de mettre jour un DNSdynamiquement en
fonction des adresses IP fournies par le serveur DHCP. Pour information, le premire draft sur le DNS dynamique
date de mars 1996... Microsoft a bien entendu son propre serveur DHCP pour Windows. Seule la version pour
Windows 2000 Server permet de mettre jour les DNS dynamiquement avec DHCP. Le reste de cette section
traite de l'installation et de la configuration d'un serveur DHCP sous systme Unix. L'exemple pris est celui d'un
serveur fourni par l'ISC.
8.2 - Compilation du serveur
La premire tape de la ralisation d'un serveur DHCP est bien entendu sa compilation. Allez sur le site de l'ISC et
tlchargez une version d'un serveur DHCP ou tlchargez simplement ma version qui, bien que vieille, prend en
charge
la
mise
a
jour
de
DNS.
Copier
le
fichier
dans
un
rpertoire.
Dcompressez
l'archive :
tar
xzf
dhcp-2.0b1pl6.tar.gz
Dplacez-vous
dans
le
rpertoire
(commande
cd),
et
tapez :
./configure
Cela va gnrer les fichiers Makefile correspondant votre systme. Tapez ensuite make pour compiler le serveur
et
enfin
make
install
pour
installer
le
serveur.
Avant de faire le ./configure, il est hautement recommand de lire le fichier README qui explique comment
installer correctement le serveur. Par exemple, pour ma version, tapez ./configure --with-nsupdate pour compiler
le serveur avec le support Dynamic DNS update. make install copiera les fichiers perl dans le rpertoire
/usr/local/DHCP-DNS-0.52mdn.
8.3 - Le fichier dhcpd.conf
Ce fichier est la base de la configuration du serveur. Par dfaut, il se trouve dans le rpertoire /etc/, mais vous
pouvez le mettre n'importe o. il est compos de plusieurs sections, chacune limite par des accolades { et } :
-
des
paramtres
globaux
qui
s'appliquent
tout
le
fichier,
shared-network,
subnet,
host,
group.
Chaque section peut contenir des paramtres et des options. Une section group peut contenir des sections host.
Au dbut du fichier, on peut placer des paramtres globaux, comme par exemple la dure des baux, les adresses
des DNS... Chaque ligne du fichier de configuration doit se terminer par un ;, sauf lorsqu'il y a une accolade. Les
commentaires sont possibles en ajoutant un # en dbut de ligne.
8.3.1 - Les paramtres globaux
Ils peuvent tre un peu tout et n'importe quoi, pourvu qu'ils aient une signification applicable toutes les
dclarations du fichier. Par exemple, on peut redfinir la dure des baux (max-lease-time et default-leasetime), empcher le serveur de rpondre des requtes venant d'htes non dclars (deny unknownclients;), indiquer le nom de domaine que les machines doivent utiliser, les serveurs DNS... Voir un exemple.
8.3.2 - shared-network
Ce paramtre est utilis pour regrouper plusieurs zones subnet lorsque ceux-ci concerne le mme rseau
physique. Les paramtres rentrs en dbut de zone seront utiliss pour le boot des clients provenant des
sous-rseaux dclars, moins de spcifier pour certains htes de ne pas booter (zone host). Son utilisation
se rapproche de celle de host ; il faut toutefois l'utiliser systmatiquement que le rseau est divis en
diffrents
sous-rseaux
administrs
par
le
serveur
DHCP.
Syntaxe :
shared-network
FOO-BAR
{
"boot";
filename
subnet
192.168.2.0
netmask
range
subnet
255.255.255.224
{
192.168.2.30;
}
192.168.2.10
192.168.2.32
range
netmask
255.255.255.224
{
192.168.2.50;
}
192.168.2.40
}
8.3.3 - subnet
subnet permet de dfinir les sous-rseaux sur lesquels le serveur DHCP doit intervenir. C'est la partie la plus
importante du fichier de configuration du serveur DHCP ; sans a, votre serveur ne marchera jamais.
La
syntaxe
exacte
subnet
pour
cette
numero_sous-reseau
[
paramtres
[
zone
est
netmask
globaux...
dclarations...
comme
suit :
netmask
{
]
]
}
numero_sous-reseau et netmask sont donns sous format adresse IP pointes. Un exemple se trouve juste
au
dessus,
dans
la
partie
dcrivant
la
zone
shared-network.
On peut bien entendu commencer la zone par des paramtres globaux qui ne seront appliqus que pour les
ordinateurs de ce sous-rseau. Par exemple, le nom de domaine appliquer sur ce sous-rseau (option
domain-name). Ensuite, on peut ajouter des dclarations d'htes. Le paramtre global indispensable est :
range [ dynamic-bootp ] adresse_inferieure [ adresse_superieure ] qui dfinit la zone d'adresses IP (limite
par adresse_inferieure et adresse_superieure) que le DHCP peut distribuer. Plusieurs range peuvent se
suivre. On peut ne pas spcifier d'adresse suprieure, cela revient ne considrer qu'une seule adresse IP
distribuable (celle indique, bien sr). dynamic-bootp doit tre mis pour indiquer que le DHCP doit rpondre
aux requtes BOOTP en donnant une adresse de cette plage.
8.3.4 - host
Ce mot permet de dclarer des machines que le DHCP doit connatre et leur appliquer une configuration
particulire. Vous n'tes pas oblig d'utiliser cette zone, mais elle est par exemple indispensable lorsque vous
avez dclar deny unknown-clients; en dbut de fichier pour empcher le serveur DHCP de rpondre des
requtes
provenant
d'htes
non
dclars.
host
est
utilis
de
la
host
faon
suivante :
nom
{
paramtres...
}
Un hte peut tre reconnu de deux faons : en utilisant son nom (le nom qui suit le mot cl host) ou en
utilisant son adresse hardware (ethernet ou token-ring). Dans ce dernier cas, il faut ajouter une ligne dans la
dclaration host : hardware ethernet|token-ring adresse-hardware;. Il est fortement recommand
d'authentifier les ordinateurs partir de leur adresse hardware plutt que leur nom, surtout qu'il sont
supposs ne pas possder de vritable nom Internet et que l'on peut redfinir ce nom.
Un point important : c'est dans une dclaration host que l'on dcide d'attribuer une adresse fixe ou non un
hte. Il suffit alors d'utiliser une ligne comme celle-ci : fixed-address 192.168.2.4;. ATTENTION ! Toute
adresse IP attribue de manire fixe ne doit pas faire partie des zones d'adresses IP dclares avec range...
(zone subnet).
8.3.5 - group
Cette zone est simplement utilise pour rassembler plusieurs dclarations (de toute sorte, y compris d'autres
dclarations
group)
pour
leur
appliquer
des
diffrents
paramtres.
Exemple :
group
option
option
domain-name
routers
{
"bar.org";
192.168.1.254;
host
foo1
{
...
}
host
foo2
{
...
}
}
8.3.6 - Les options
Les paramtres qui doivent commencer avec option sont les options dfinies dans la Rfc 2132. Il y en a
environ 60 dfinies dans la Rfc, mais le serveur peut en grer jusqu' 254 (les options 0 et 255 sont
rserves). Pour trouver les options possibles et leur nom, vous pouvez consulter le fichier common/tables.c
des sources du serveur. ATTENTION ! les noms des options peut varier d'une version de serveur une autre.
Le format des valeurs des options est donn dans ce mme fichier au dbut ("format codes:"). Les options
plus
utiles
sont
les
suivantes :
-
utiliser,
- domain-name-servers (option 6) qui indique les DNS utiliser. On peut aussi bien donner le nom que
l'adresse
IP
(!)
- host-name (option 12) qui indique au client quel nom d'hte il doit prendre,
- domain-name (option 15) qui fournit au client le nom du domaine arpa dans lequel il se trouve,
- broadcast-address (option 28) qui indique l'adresse de broadcast en vigueur sur le rseau,
- dhcp-lease-time (option 51) qui indique au client la dure de validit du bail.
- D'autres options (60 en particulier) permettent de personnaliser les messages DHCP circulant sur le
rseau.
8.3.7 - Exemple de fichier dhcpd.conf
-
option
subnet
max-lease-time
default-lease-time
deny
option
domain-name
domain-name-servers
foo1.bar.com,
192.168.1.0
netmask
range
range
option
240;
240;
unknown-clients;
"bar.com";
foo2.bar.com;
255.255.255.0
{
192.168.1.100;
192.168.1.254;
192.168.1.255;
}
192.168.1.2
192.168.1.110
broadcast-address
group
option
{
192.168.2.101;
routers
host
hardware
option
foo3
{
00:c0:c3:11:90:23;
pc3;
}
ethernet
host-name
host
hardware
foo4
{
00:c0:c3:cc:0a:8f;
192.168.1.105;
}
ethernet
fixed-address
}
host
hardware
foo5
{
00:c0:c3:2a:34:f5;
"bootp.bar.com";
"boot";
}
ethernet
server-name
filename
Explications :
Les cinq premires lignes dfinissent les paramtres globaux. Les 2 premiers concernent les baux (leases).
La ligne suivante dit au serveur de ne pas rpondre aux requtes DHCP venant d'htes qu'il ne connat pas
(i.e. non dfinis dans dhcpd.conf). On dfinit enfin les paramtres du domaine du rseau (nom de domaine et
serveurs
DNS).
On dfinit ensuite le sous-rseau sur lequel le serveur DHCP est cens intervenir : c'est la ligne "subnet...".
Dans ce sous-rseau, on dit au serveur de ne fournir des adresses IP que dans les plages d'adresses dfinies
par les lignes "range...". la dernire ligne de la section dfinit l'adresse de broadcast utiliser sur le sousrseau.
On cre ensuite un groupe dont le but est uniquement de fournir des adresses de passerelles des machines
bien dtermines (par leur adresse MAC). On remarque que foo4.bar.com obtiendra une adresse IP fixe.
foo5, enfin, sera une machine qui bootera travers le rseau, en se connectant au serveur TFTP
bootp.bar.com, et booter avec le fichier boot.
8.4 - Lancer le dmon dhcpd
Pour lancer le serveur, il faut d'abord tre root sur le systme. Il suffit ensuite de taper la commande suivante :
dhcpd
-lf
fichier_de_leases
-cf
fichier_de_config
adpateur1
adapteur2...
le serveur DHCP va alors se lancer sur les adaptateurs rseau adapteur1, adapteur2..., en trouvant sa
configuration dans le fichier fichier_de_config et en utilisant le fichier fichier_de_leases pour stocker ses baux.
Sans tous les arguments, le serveur DHCP va aller chercher ses fichiers dans des emplacements dtermins au
moment de la compilation, dans le fichier includes/dhcpd.h et utiliser eth0 comme interface par dfaut. Vous
pouvez bien entendu modifier tout a.
8.5 - Excuter le dmon chaque dmarrage (pour Linux)
Pour lancer le dmon au dmarrage de votre machine, il faut d'abord placer un script shell de lancement du
dmon dans le rpertoire /etc/rc.d/init.d/. Ce script va en fait grer le dmarrage et l'arrt de dhcpd. Ce fichier
n'est hlas par fourni avec les archives de l'ISC. Vous pouvez le crer vous mme en vous inspirant des autres
scripts
figurant
dans
le
rpertoire
ou
simplement
reprendre:
#
.
Source
#
[
networking
Check
${NETWORKING}
[
[
[
-f
-f
-f
#
case
start)
#
echo
daemon
touch
;;
stop)
#
echo
killproc
echo
rm
;;
restart)
$0
$0
;;
status)
status
;;
*)
echo
exit
esac
that
=
See
networking
]
"no"
/usr/sbin/dhcpd
/etc/dhcpd.conf
/var/dhcpd/dhcpd.leases
configuration.
/etc/sysconfig/network
]
]
]
exit
||
||
touch
||
how
is
&&
we
exit
0
exit
0
/var/dhcpd/dhcpd.leases
were
called.
in
"$1"
-n
/usr/sbin/dhcpd
-lf
Start
"Starting
/var/dhcpd/dhcpd.leases
-cf
daemons.
dhcpd:
"
/etc/dhcpd.conf
eth0
/var/lock/subsys/dhcpd
Stop
-n
"Shutting
up.
0
down
dhcpd:
-f
daemons.
"
dhcpd
/var/lock/subsys/dhcpd
stop
start
dhcpd
"Usage:
dhcpd
{start|stop|restart|status}"
1
exit
Faites
un
chmod
755
dhcpd
pour
mettre
les
bons
droits.
Il faut maintenant dire GNU/Linux d'excuter ce script au dmarrage. Cela se fait en crant des liens
symboliques dans les rpertoires /etc/rc.d/rcx.d/ avec x un entier correspondant au runlevel auquel le dmon doit
tre lanc. Faites simplement chkconfig --add dhcpd, cela va crer les liens symboliques pour vous.
Vous pouvez maintenant redmarrer votre ordinateur, le serveur DHCP sera lanc automatiquement.
ATTENTION ! Il se peut que linuxconf prenne le contrle du serveur DHCP. Si vous voulez garder indprendante la
gestion de votre serveur DHCP (comme c'est par exemple le cas pour moi car j'ai modifi la script
/etc/rc.d/init.d/dhcpd), dsactivez la prise en charge de dhcpd dans linuxconf.
8.6 - Documentation
La commande make install a d installer sur votre systme les manuels du serveur. Pour y accder, tapez
simplement :
-
man
dhcpd
pour
connatre
le
fonctionnement
du
dmon
dhcpd,
man
dhcpd.conf
pour
savoir
comment
crire
et
configurer
le
fichier
dhcpd.conf,
man
dhcpd.leases
pour
avoir
des
informations
sur
les
baux
du
serveur
DHCP.
Cette doc n'est toutefois ni trs simple ni complte. Les options ne sont par exemple pas dtailles. La meilleure
documentation est finalement de loin la Rfc qui pour une fois a la bonne ide d'tre claire et concise.
cette
partie
nous
verrons,
suivant
le
systme
- Windows
- Windows
- Linux
employ,
95/98
NT4/2000/Xp
9)
(Mandrake
quels sont les outils pour contrler l'tat du client DHCP. Je demande aux utilisateurs de Be/OS, de MAC/OS et de
tous ceux que j'oublie, de bien vouloir m'excuser de ne pas leur apporter mon soutien. J'ai dj dans mon petit
bureau (4 M2) trois PC dont un sur lequel sont installs trois systmes, je n'ai plus de place...
9.2 - Windows 95/98
9.2.1 - Configuration
Par le panneau de configuration, icne "rseau", cliquez sur "TCP/IP -> <votre carte rseau>. L'adresse IP
doit tre configure dynamiquement, c'est d'ailleurs le choix par dfaut l'installation.
9.2.2 - Vrification
Si vous avez un bail en cours de validit, la commande "winipcfg" vous affiche les choses suivantes:
ATTENTION! Windows 95 et 98 installent galement le client PPP dont nous n'avons rien faire... Ce client
apparat
galement
dans
la
liste
des
interfaces
rseau.
Vrifiez bien que vous pointez sur votre carte Ethernet et pas sur le client PPP...
Si
vous
cliquez
sur
le
bouton
"Plus
d'info>>":
Ici, c'est le bouton "Renouveler" qui sera votre seul secours en cas de problmes. Notez que les rubriques
"Bail obtenu" et "Expiration du bail" contiennent des valeurs calcules par votre machine. Le serveur DHCP
ne donne que la dure.
9.3 - Windows NT4/2000/XP
9.3.1 - Configuration
La configuration se fait dans le panneau de configuration, icne "rseau", onglet "protocoles", puis
"proprits" de TCP/IP. L, vous avez indiqu que la carte doit recevoir une adresse IP dynamiquement.
9.3.2 - Vrification
Tapez
dans
une
console,
la
commande
"ipconfig"
Votre adresse doit tre affiche. Si vous voulez tous les dtails, utilisez la commande "ipconfig /all":
La
commande
-
De
De
"ipconfig"
rsilier
renouveler
le
le
permet
bail:
bail:
galement:
"ipconfig
"ipconfig
/release"
/renew"
C'est cette commande qui est utiliser pour essayer de rcuprer une adresse IP lorsque vous avez des
problmes.
Notes.
- Les rubriques "Bail obtenu" et "Expiration du bail" contiennent des valeurs calcules par votre machine.
serveur
DHCP
ne
donne
que
la
dure.
- La commande en mode graphique "winipcfg" n'existe pas nativement sous Windows NT mais vous
pouvez la rcuprer dans le kit de ressources techniques (tlchargeable sur le site MS en cherchant bien :-).
N'essayez pas d'utiliser celle de Windows 95/98, les dll winsock32 utilises ici ne sont pas compatibles.
Le
9.4 - Linux
9.4.1 - Configuration
Avec cet OS c'est beaucoup plus compliqu, parce qu'il y a beaucoup plus de configurations possibles. La
configuration
utilise
dans
l'expos
est
la
suivante:
-
Un
portable
Eth0
Compaq
et
quip
d'une
MANDRAKE
configure
carte
rseau
avec
D-LINK
PCMCIA
8.2
DHClient.
Notez que DHClient n'est pas le seul client possible. Vous pouvez parfaitement le remplacer par PUMP,
DHCPXD ou par DHCPCD. Tous ces clients sont disponibles dans la distribution Mandrake, qui installe
d'ailleurs
DHCPCD
par
dfaut,
et
non
pas
celui
que
j'utilise.
- DHCPCD semble avoir la prfrence du distributeur. Je n'ai jamais rencontr de problmes avec, mais je
ne l'utilise normalement pas pour la raison suivante: Son paramtrage ne se fait que par la ligne de
commande, ce qui oblige aller modifier des scripts pas toujours faciles trouver si l'on veut par exemple
utiliser
son
propre DNS
la
place
de
celui
propos
dans
le
bail.
- PUMP Fonctionne galement sans problmes, il dispose d'un fichier de configuration /etc/pump.conf dans
le quel on peut par exemple spcifier trs simplement que l'on ne veut pas modifier le paramtrage du DNS
avec l'information rcupre par DHCP. (Le ou les DNS sont inscrits dans le fichier /etc/resolv.conf).
- Je n'ai pas vraiment tudi DHCPXD qui fonctionne lui aussi sans difficults. Il dispose d'un rpertoire
/etc/dhcpxd dans lequel vous trouverez quelques fichiers qui vous donneront toutes les indications sur le bail
en
cours.
DHCLIENT a ma prfrence. Il est crit par ISC (les auteurs de BIND le fameux DNS et DHCPD lque nous
utilisons ici, c'est dire qu'ils savent de quoi ils parlent :). Ce client cumule mon sens tous les avantages:
- Un fichier de configuration /etc/dhclient.conf, sans doute encore plus performant que celui de PUMP.
Notez que ce fichier n'existe pas dans la distribution Mandrake, il vous faudra ventuellement le crer si vous
ne
voulez
pas
vous
contenter
du
fonctionnement
par
dfaut.
- Des scripts optionnels excuts automatiquement avant l'obtention du bail et aprs l'obtention du bail,
avec disposition des variables contenant toutes les informations recueillies par le client auprs du serveur.
Trs pratique par exemple pour vous envoyer par mail l'adresse courante de votre machine si celle-ci
change; dans le cas par exemple o vous avez besoin de vous y connecter distance par telnet ou ssh.
- Il tient un historique des baux obtenus dans le fichier /var/lib/dhcp/dhclient.leases
Son seul inconvnient est sa richesse. Il n'est pas le plus facile mettre en oeuvre.
9.4.2 - Vrifiez l'tat de votre connexion
Dans /etc/sysconfig/network-scripts, il y a un fichier intitul : ifcfg-eth0. Il doit contenir au moins ces lignes :
DEVICE="eth0"
BOOTPROTO="dhcp"
IPADDR=""
NETMASK=""
ONBOOT="yes"
C'est
La
Si
assez
commande
rien
parlant
"ifconfig
n'apparat,
c'est
pour
eth0"
que
ne
devrait
votre
pas
vous
interface
ncessiter
donner
n'est
pas
d'explications
quelque
active.
chose
Essayez
particulires.
comme
alors
ifup
ceci
eth0
Cette commande affiche l'tat de Eth0, mais elle ne donne pas toutes les informations que l'on obtient sous
Windows avec winipcfg ou ipconfig. Si vous voulez tout savoir, il faut aller dans le rpertoire "/var/lib/dhcp"
et
regarder le fichier
dhclient.leases.
Celui-ci
contient l'historique
des dialogues DHCP :
lease
interface
fixed-address
option
option
option
option
option
option
option
renew
rebind
expire
2
2
2
subnet-mask
routers
dhcp-lease-time
dhcp-message-type
domain-name-servers
dhcp-server-identifier
domain-name
2002/12/10
2002/12/10
2002/12/10
{
"eth0";
192.168.0.8;
255.255.255.0;
192.168.0.253;
3600;
5;
192.168.0.253;
192.168.0.253;
"maison.mrs";
08:49:42;
09:14:05;
09:21:35;
}
Notez que ce fichier peut tre beaucoup plus long. Cherchez dedans le dernier bail obtenu. Constatez que
vous avez bien la trace de toutes les informations que notre serveur DHCP est capable d'envoyer ses
clients.
9.4.3 - Particularits du client DHClient
Grce aux informations conserves dans ce fichier dhclient.leases, ce client adopte un comportement un peu
particulier,
que
l'on
ne
retrouve
pas
dans
celui
de
Microsoft,
par
exemple.
Lorsqu'un hte a obtenu un premier bail de la part du DHCP, l'adresse du serveur DHCP est conserve et,
mme aprs extinction et redmarrage de l'hte au bout d'un temps bien suprieur la dure de son bail, le
client commencera par envoyer directement un DHCP request au serveur qu'il connat. Cette particularit
peut drouter lorsque l'on espionne les dialogues DHCP sur le rseau.
10 - Savoir "Sniffer"
Un "sniffer" n'est pas un outil pour se "shooter", mais pour analyser les donnes qui se trimbalent sur le rseau. C'est
un outil d'administrateur, qui est capable du meilleur comme du pire. Si vous voulez jouer avec, il en existe un tout
fait convenable et gratuit, aussi bien en version Linux que Windows, c'est Ethereal. Il ncessite l'installation de la
librairie
libpcap,
disponible
elle
aussi
sous
Linux
comme
sous
Windows.
Nous allons juste ici analyser une capture de trames correspondant au dialogue DHCP, et constater que, lorsque a va
bien,
a
se
passe
comme
c'est
dit
dans
les
livres,
ce
qui
est
un
peu
rconfortant.
La manipulation est faite avec un client sous Windows XP.
10.1 - En-ttes de trames
1 - Notre client se rveille, il n'a pas d'IP et utilise 0.0.0.0 pour faire un "broadcast gnral (255.255.255.255)".
C'est
le
DHCP
Discover.
2 - Notre serveur DHCP, qui a l'intention d'offrir ce client l'IP 192.168.0.9, fait un ping sur cette adresse, histoire
de
voir
si
elle
est
rellement
disponible
sur
le
rseau.
3 - Comme il ne reoit pas de rponse son ping, il offre cette adresse au client.
4
Le
client
fait
alors
un
DHCP
Request
5
Le
serveur
accepte
6 - Le client fait un broadcast ARP pour vrifier de son ct que l'IP 192.168.0.9 n'est pas duplique sur le
rseau.
7
idem
8
idem
9
L,
commence
le
verbiage
propre
aux
rseaux
Microsoft...
Note
propos
du
ping.
Ce ping fait "perdre" une seconde au processus d'attribution d'un bail. En effet, le serveur attend pendant une
seconde une ventuelle rponse. Si vous tes absolument sr de votre rseau, vous pouvez dsactiver ce ping
dans le fichier de configuration de DHCPd, mais je ne vous le conseille pas.
10.2 - Dtail des trames
Ce qui suit reprsente l'interprtation exhaustive des trames par le "sniffer". Il est vident qu'en lecture directe
sur le rseau, on ne verrait qu'une suite d'octets difficilement interprtable par l'esprit humain.
La lecture en est certes un peu fastidieuse, mais elle est riche d'enseignements... Les points les plus importants
sont marqus en gras.
C'est presque fini, il ne reste plus au serveur qu' confirmer l'attribution de ce bail.
Pas besoin de regarder de prs ce qu'il se passe dans les broadcasts ARP que le client fait par la suite.
10.3 - Notes supplmentaires
10.3.1 - Duplication d'adresse
Que se serait-il pass, si l'adresse propose par le serveur (ici 192.168.0.9) avait t dj utilise par un
autre
noeud
du
rseau
?
Je ne vous assommerai pas encore une fois avec un sniff, croyez-moi sur parole, j'ai fait la manip pour
vrifier.
Dans ce cas, le serveur recevra un "echo reply" de la part du noeud utilisant cette IP et ne rpondra pas au
Discover. Le client, ne recevant pas de rponse, enverra un nouveau discover et le serveur lui proposera une
autre IP.
10.3.2 - Pas de rponse
Et
si
le
client
qui
pris
l'IP
192.168.0.9
ne
rpond
pas
aux
pings
Ce sera la catastrophe annonce. Le bail sera allou et il y aura une duplication de l'IP sur le rseau. Mais les
broadcast ARP fait par le client qui a reu l'IP duplique mettra jour cette duplication et la configuration
chouera.
Cette situation ne devrait pas se produire sur un rseau proprement configur. Elle ne devrait apparatre que
s'il y a un utilisateur malveillant sur le rseau, qui force une configuration statique quand il ne le faut pas et
qui
bloque
volontairement
les
chos
ICMP.
Pour ceux qui n'ont pas peur de se plonger dans les Rfcs, vous trouverez celle qui traite du protocole Dhcp
la Rfc 2131.
10.4 - Renouvellement d'un bail en cours de validit
Lorsque la dure du bail est infrieure " l'uptime" du client, autrement dit, si votre client reste connect plus
longtemps
que
la
dure
de
validit
de
son
bail,
il
va
devoir
le
renouveler.
Pour visualiser cette procdure, nous faisons un petit test, en diminuant la dure de vie du bail quatre minutes,
et nous sniffons :
10.4.1 - Quand a se passe bien...
Ca semble suffisamment parlant, au bout d'environ 120 secondes, soit 50% de la dure de vie du bail, le
client essaye de le renouveler. Ca se passe bien, puisque le serveur rpond toute de suite et a repart pour 4
minutes. Inutile de regarder le dtail des trames.
10.4.2 - Et quand a se passe mal
Nous
allons
faire
la
mme
chose,
mais
en
simulant
une
panne
de
serveur
DHCP
Mais elle aurait pu mal finir, si a avait t une bonne, vraie, grosse panne du serveur. En effet, une fois le
bail expir, le client perd bel et bien son IP et est ject de fait du rseau... Du temps o les cbls Wanadoo
fonctionnaient sur ce systme, ils n'ont pas manqu d'assister quelques fois ce dsolant spectacle.
Dns
1 - Introduction
2 - Historique
3 - Les formats
3.1 - Le transport
3.2 - L'entte
3.3 - Les RR
4 - Les zones
4.1 - Structure arborescente de l'espace de noms
4.2 - Formation des zones
4.3 - Principes des zones
4.4 - Description techniques pour les zones
4.5 - Type de serveurs et autorits
4.6 - La diffusion des modifications
4.7 - Les pannes
5 - Recherche de ressources
5.1 - Les Rsolveurs
5.2 - Les Requtes
5.3 - Les Requtes inverses
6 - La scurit
6.1 - Fragilit
6.2 - Scurisation
7 - Conclusion
8 - Discussion autour de la documentation
9 - Suivi du document
1 - Introduction
Dans le monde de l'Internet, les machines du rseau sont identifies par des adresses Ip. Nanmoins, ces adresses ne
sont pas trs agrables manipuler, c'est pourquoi, on utilise les noms. L'objectif a alors t de permettre la rsolution
des noms de domaines qui consiste assurer la conversion entre les noms d'htes et les adresses Ip. La solution
actuelle est l'utilisation des Dns (Domain Name System) ce que nous allons vous prsenter dans ce document.
Le travail prsent ici s'appuie particulirement sur les Rfcs 1034 et 1035. Les Rfc (Request For Comment) sont des
documents de l'IETF (Internet Engineering Task Force) qui ont vocation tre les standards d'Internet. Dans une
premire partie nous ferons une introduction la notion de Dns, en prsentant un bref historique et en nous penchant
sur sa structure. Nous nous intresserons ensuite plus prcisment aux serveurs de noms et pour finir nous parlerons
du systme de recherches des ressources et plus prcisment des requtes Dns.
Vous pouvez regarder une trs bonne vido en ligne relatant de manire pdagogique le fonctionnement de DNS.
2 - Historique
Jusqu'en 1984, sur la suite des protocoles TcpIp, la transcription de noms d'htes en adresses Internet s'appuyait sur
une table de correspondance maintenue par le Network Information Center (NIC), et ce dans un fichier .txt, lequel tait
transmis par Ftp tous les htes. Il n'tait l'poque pas compliqu de stocker les adresses puisque le nombre de
machines tait trs rduit. Par ailleurs, avec la croissance exponentielle d'Internet il a fallu trouver une autre solution,
car les problmes se sont multiplis :
La mise jour des fichiers : En effet il fallait retransmettre le fichier de mise jour tous les htes, ce qui
encombrait fortement la bande passante du NIC.
L'autonomie des organismes : Avec l'volution de l'Internet, les architectures ont t transformes, ainsi des
organismes locaux ont eu la possibilit de crer leur propres noms et adresses, et ils taient alors obligs
d'attendre que le NIC prenne en compte leurs nouvelles adresses avant que les sites ne puissent tre visibles
par tous sur Internet. Le souhait tait alors que chacun puisse grer ses adresses avec une certaine autonomie.
Tous ces problmes ont fait merger des ides sur l'espace des noms et sa gestion. Les propositions ont t diverses,
mais l'une des tendances mergentes a t celle d'un espace de noms hirarchis, et dont le principe hirarchique
s'appuierait autant que possible sur la structure des organismes eux-mmes, et o les noms utiliseraient le caractre
"."
pour
marquer
la
frontire
entre
deux
niveaux
hirarchiques.
En 1983-1984, Paul Mockapetris et John Postel proposent et dveloppent une solution qui utilise des structures de base
de donnes distribue : les Domain Name System, Rfcs 882 et 883 devenue obsolte par la Rfc 1034. Les spcification
des Dns ont t tablies en 1987.
Paul Mockapetris
Jon Postel
3 - Les formats
3.1 - Le transport
3.1.1 - Utilisation d'Udp
Le port serveur utilis pour l'envoi des datagrammes en Udp est 53. Les datagrammes Dns en Udp sont
limits 512 octets (valeur reprsentant les donnes sans l'entte Udp et Ip). Les datagramme plus long
doivent
tre
tronqu
l'aide
du
champ Tc.
L'utilisation d'Udp n'est pas recommand pour les transfert de zone, mais uniquement pour les requtes
standards.
3.1.2 - Utilisation de Tcp
Le port serveur utilis pour l'envoi des datagrammes en Tcp est 53. Le datagramme inclus alors un champ de
deux octets nomm "longueur", il permet de spcifier la la longueur total des donnes indpendamment de la
fragmentation. La longueur est calcul sans les 2 octets de ce mme champ.
3.2 - L'entte
Voici
la
structure
de
l'entte
Dns
bas
sur
12
octets.
3.2.1 - Id
Cod sur 16 bits, doit tre recopi lors de la rponse permettant l'application de dpart de pouvoir identifier
le datagramme de retour.
3.2.2 - Qr
Sur un 1 bit, ce champ permet d'indiquer s'il s'agit d'une requte (0) ou d'une rponse (1).
3.2.3 - Opcode
Sur 4 bits, ce champ perme de spcifier le type de requte :
0 - Requte standard (Query)
1 - Requte inverse (Iquery)
2 - Status d'une requte serveur (Status)
3-15 - Rserv pour des utilisations futurs
3.2.4 - Aa
Le flag Aa, sur un bit, signifie "Authoritative Answer". Il indique une rponse d'une entit autoritaire.
3.2.5 - Tc
Le champ Tc , sur un bit, indique que ce message a t tronqu.
3.2.6 - Rd
Le flag Rd, sur un bit, permet de demander la rcursivit en le mettant 1.
3.2.7 - Ra
Le flag Ra, sur un bit, indique que la rcursivit est autorise.
3.2.8 - Z
Le flag Z, sur un bit, est rserv pour une utilisation futur. Il doit tre plac 0 dans tout les cas.
3.2.9 - Rcode
Le champ Rcode, bas sur 4 bits, indique le type de rponse.
0 - Pas d'erreur
1 - Erreur de format dans la requte
2 - Problme sur serveur
3 - Le nom n'existe pas
4 - Non implment
5 - Refus
6-15 - Rservs
3.2.10 - Qdcount
Cod sur 16 bits, il spcifie le nombre d'entre dans la section "Question".
3.2.11 - Ancount
Cod sur 16 bits, il spcifie le nombre d'entre dans la section "Rponse".
3.2.12 - Nscount
Cod sur 16 bits, il spcifie le nombre d'entre dans la section "Autorit".
3.2.13 - Arcount
Cod sur 16 bits, il spcifie le nombre d'entre dans la section "Additionnel".
3.3 - Les RR
La base de donnes des serveurs de noms (fichier de domaine et fichiers de rsolution inverse) est constitue
"d'enregistrements de ressources", "Ressource Records" (RRs). Ces enregistrements sont rpartis en classes. La
seule classe d'enregistrement usuellement employe est la classe Internet (IN). L'ensemble d'informations de
ressources associ un nom particulier est compos de quatre enregistrements de ressources spars (RR). Voici
les diffrents champs d'un RR que vous pouvez aussi retrouver dans la Rfc 1035 au chapitre 3.2.1 :
3.3.1 - Nom
Nom du domaine o se trouve le RR. Ce champ est implicite lorsqu'un RR est en dessous d'un autre, auquel
cas le champ owner est le mme que celui de la ligne prcdente.
3.3.2 - Type
Ce champ type, cod sur 16 bits, spcifie quel type de donne sont utiliss dans le RR. Voici les diffrents
types disponibles:
Entre Valeur
Dsignation
01
Adresse de l'hte
NS
02
MD
03
MF
04
CNAME 05
SOA
06
MB
07
MG
08
MR
09
NULL
10
Enregistrement 0 (exprimentale)
WKS
11
PTR
12
HINFO
13
Description de la machine
MINFO
14
MX
15
Mail exchange (Indique le serveur de messagerie. Voir [Rfc-974] pour plus de dtails
TXT
16
Chane de caractre
3.3.3 - Classe
Une valeur encode sur 16 bits identifiant une famille de protocoles ou une instance d'un protocole. Voici les
classes de protocole possible :
Entre Valeur
Dsignation
In
01
Internet
Cs
02
Ch
03
Chaos (chaosnet est un ancien rseau qui historiquement a eu une grosse influence sur le
dveloppement de l'Internet, on peut considrer l'heure actuelle qu'il n'est plus utilis)
Hs
04
Hesiod
3.3.4 - Ttl
C'est la dure de vie des RRs (32 bits, en secondes), utilise par les solveurs de noms lorsqu'ils ont un cache
des RRs pour connatre la dure de validit des informations du cache.
3.3.5 - Longueur
Sur 16 bits, ce champ indique la longueur des donnes suivantes.
3.3.6 - Donnes
Donnes identifiant la ressource, ce que l'on met dans ce champs dpend videmment du type de ressources
que l'on dcrit.
A : Pour la classe IN, une adresse IP sur 32 bits. Pour la classe CH, un nom de domaine suivi d'une
adresse octale Chaotique sur 16 bits.
Cname : un nom de domaine.
Mx : une valeur de prfrence sur 16 bits (la plus basse possible) suivie d'un nom d'hte souhaitant
servir d'changeur de courrier pour le domaine de l'owner.
Ptr : Une adresse IP sous forme d'un nom.
Ns : Un nom d'hte.
Soa : Plusieurs champs.
Voici
un
exemple
montrant
les
diffrents
champs
saisies
par
Ethereal
4 - Les zones
4.1 - Structure arborescente de l'espace de noms
Le Dns utilise la gestion hirarchique des noms. On distingue deux domaines pour le classement des noms.
4.1.1 - Les domaines gographiques (Codes ISO 3166)
.ac - Ascension
.gm - Gambie
.np - Nepal
.ad - Andorre
.ae - Emirats Arabes Unis
.af - Afganistan
.ag - Antigua And Barbuda
.ai - Anguilla
.al - Albania
.am - Armnie
.an - Netherlands Antilles
.ao - Angola
.aq - Antartique
.ar - Argentine
.as - American Samoa
.at - Autriche
.au - Australie
.aw - Aruba
.az - Azerbaijan
.ba - Bosnie Herzgovine
.bb - Barbades
.bd - Bangladesh
.be - Belgique
.bf - Burkina Faso
.bg - Bulgarie
.bh - Bahrain
.bi - Burundi
.bj - Benin
.bm - Bermudes
.bn - Brunei Darussalam
.bo - Bolivie
.br - Brsil
.bs - Bahamas
.bt - Bhutan
.bv - Bouvet Island
.bw - Botswana
.by - Belarus
.bz - Belize
.ca - Canada
.cc - Cocos (Keeling) Islands
.cd - Rpublique du Congo
.cf - Rpublique d'Afrique
Centrale
.cg - Congo
.ch - Suisse
.ci - Cote d'Ivoire
.ck - Iles Cook
.cl - Chili
.cm - Cameroun
.cn - Chine
.co - Colombie
.cr - Costa Rica
.cu - Cuba
.cv - Cap Vert
.cx - Christmas Island
.cy - Chypre
.cz - Rpublique Tchque
.de - Allemagne
.dj - Djibouti
.dk - Danmark
.dm - Dominica
.do - Rpublique Dominicaine
.dz - Algrie
.ec - Equateur
.ee - Estonie
.eg - Egypte
.eh - Sahara occidental
.er - Erytre
.es - Espagne
.et - Ethiopie
.fi - Finlande
.fj - Fiji
.fk - Iles Fakland (Malouines)
.fm - Micronesie (Etat Fdral)
.fo - Iles Faroe
.fr - France
.fx - France Mtropoliotaine
.ga - Gabon
.gn - Guine
.gp - Guadeloupe
.gq - Guinee Equatoriale
.gr - Grce
.gs - South Georgia and the South Sandwich
Islands
.gt - Guatemala
.gu - Ile de Guam
.gw - Guin-Bissau
.gy - Guyane
.hk - Hong Kong
.hm - Heard and McDonald Islands
.hn - Honduras
.hr - Croatie/Hrvatska
.ht - Haiti
.he - Hongrie
.hu - Hongarie
.id - Indonsie
.ie - Irelande
.il - Israel
.im - Isle of Man
.in - Inde
.io - Territoire Anglais de l'Ocan Indien
.iq - Irak
.ir - Iran (Islamic Republic of)
.is - Islande
.it - Italie
.je - Jersey
.jm - Jamaque
.jo - Jordanie
.jp - Japon
.ke - Kenya
.kg - Kyrgyzstan
.kh - Cambodge
.ki - Kiribati
.km - Iles Comores
.kn - Saint Kitts and Nevis
.kp - Rpublique Dmocratique populaire de
Core
.kr - Rpublique de Core
.kw - Koweit
.ky - Iles Cayman
.kz - Kazakhstan
.la - Rpublique Dmocratique populaire du
Laos
.lb - Liban
.lc - Sainte Lucie
.li - Liechtenstein
.lk - Sri Lanka
.lr - Liberia
.ls - Lesotho
.lt - Lituanie
.lu - Luxembourg
.lv - Latvia
.ly - Libyan Arab Jamahiriya
.ma - Maroc
.mc - Monaco
.md - Rpublique de Moldavie
.mg - Madagascar
.mh - Iles Marshall
.mk - Macdoine, ex Rpublique Yougoslave
.ml - Mali
.mm - Myanmar
.mn - Mongolie
.mo - Macao
.mp - Iles Mariannes du Nord
.mq - Martinique
.mr - Mauritanie
.ms - Montserrat
.mt - Malte
.mu - Ile Maurice
.mv - Maldives
.mw - Malawi
.mx - Mexique
.my - Malaisie
.nr - Nauru
.nu - Niue
.nz - Nouvelle Zlande
.om - Oman
.pa - Panama
.pe - Prou
.pf - Polynsie Franaise
.pg - Papouasie Nouvelle Guine
.ph - Philippines
.pk - Pakistan
.pl - Pologne
.pm - Saint Pierre et Miquelon
.pn - Pitcairn Island
.pr - Porto Rico
.ps - Territoires Palestiniens
.pt - Portugal
.pw - Palau
.py - Paraguay
.qa - Qatar
.re - L'Ile de la Runion
.ro - Roumanie
.ru - Fdration Russe
.rw - Rwanda
.sa - Arabie Saoudite
.sb - Iles Salomon
.sc - Seychelles
.sd - Soudan
.se - Sude
.sg - Singapour
.sh - Sainte Hlne
.si - Slovanie
.sj - Svalbard and Jan Mayen
Islands
.sk - Slovaquie
.sl - Sierra Leone
.sm - San Marino
.sn - Sngal
.so - Somalie
.sr - Surinam
.st - Sao Tome and Principe
.sv - Salvador
.sy - Syrie
.sz - Swaziland
.tc - Iles Turques et Caicos
.td - Tchad
.tf - Territoire Franais du Sud
.tg - Togo
.th - Thailande
.tj - Tajikistan
.tk - Tokelau
.tm - Turkmenistan
.tn - Tunisie
.to - Iles Tonga
.tp - Timor Oriental
.tr - Turquie
.tt - Trinit et Tobago
.tv - Tuvalu
.tw - Taiwan
.tz - Tanzanie
.ua - Ukraine
.ug - Ouganda
.uk - Royaume Uni
.um - US Minor Outlying Islands
.us - United States
.uy - Uruguay
.uz - Uzbekistan
.va - Vatican
.vc - Iles Grenadines et St
Vincent
.ve - Vnzuela
.vg - Iles Vierges Anglaises
.vi - Iles Vierges Amricaines
.vn - VietNam
.vu - Vanuatu
.wf - Iles de Wallis et Futuna
.mz - Mozambique
.na - Namibie
.nc - Nouvelle Caldonie
.ne - Niger
.nf - Iles Norfolk
.ng - Nigeria
.ni - Nicaragua
.nl - Hollande
.no - Norvge
.ws - Samoa
.ye - Yemen
.yt - Mayotte
.yu - Yougoslavie
.za - Afrique du sud
.zm - Zambie
.zw - Zimbabwe
liste
est
dfinie
par
la Rfc
1591
Domain
Name
System
Structure
.com
.edu
Organismes
d'ducation
.net
Organismes
de
gestion
de
.org
Organismes
.int
Organismes
.gov
Organismes
gouvernementaux
.mil
Organismes
militaires
.arpa - Transition ARPAnet-> Internet + traduction inverse
and
Delegation
Commerciaux
amricaine
rseaux
non-commerciaux
internationaux
USA
USA
Les donnes qui dcrivent chaque zone sont organises en quatre parties :
Les donnes gnrales sur chaque noeud de la zone
Les donnes qui dfinissent le noeud suprieur de la zone
Les donnes qui dcrivent les sous-zones
Les donnes qui permettent d'accder aux serveurs de noms qui grent les sous-zones
Toutes ces donnes sont stockes dans des RRs, donc une zone peut tre entirement dcrite par un jeu de RRs.
Les informations sur des zones entires peuvent donc tre transmises d'un serveur l'autre, tout simplement en
changeant
ces
RRs.
Les plus importants des RRs sont ceux qui dcrivent le noeud principal d'une zone. Ils sont de deux sortes : des
RRs qui rpertorient l'ensemble des serveurs de noms de la zone, et un RR de type SOA qui dcrit les paramtres
de
gestion
de
la
zone.
Les RRs contenant des informations sur les sous zones sont de type NS. Il faut des informations pour connatre
l'adresse d'un serveur dans la sous zone, ceci pour pouvoir y accder. Ce genre de donnes est conserv dans
d'autres RRs. Tout est fait pour que dans la structure en zones, toute zone puisse disposer localement de toutes
les donnes ncessaires pour communiquer avec les serveurs de noms de chacune de ses sous-zones.
4.5 - Type de serveurs et autorits
Par le dcoupage en zone on a donc trois types de serveurs de noms.
4.5.1 - Le serveur primaire
Le serveur primaire est serveur d'autorit sur sa zone : il tient jour un fichier appel "fichier de zone", qui
tablit les correspondances entre les noms et les adresses IP des hosts de sa zone. Chaque domaine possde
un et un seul serveur primaire.
4.5.2 - Le serveur secondaire
Un serveur de nom secondaire obtient les donnes de zone via le rseau, partir d'un autre serveur de nom
qui dtient l'autorit pour la zone considre. L'obtention des informations de zone via le rseau est appel
transfert de zone (voir partie 2.4). Il est capable de rpondre aux requtes de noms Ip (partage de charge),
et de secourir le serveur primaire en cas de panne. Le nombre de serveurs secondaires par zone n'est pas
limit. Ainsi il y a une redondance de l'information. Le minimum impos est un serveur secondaire et le pr
requis mais pas obligatoire est de le situer sur un segment diffrent du serveur primaire.
Un serveur qui effectue un transfert de zone vers un autre serveur est appel serveur matre. Un serveur
matre peut tre un serveur primaire ou un serveur secondaire. Un serveur secondaire peut disposer d'une
liste de serveurs matres (jusqu' dix serveurs matres). Le serveur secondaire contacte successivement les
serveurs de cette liste, jusqu' ce qu'il ait pu raliser son transfert de zone.
4.5.3 - Le serveur cache
Le serveur cache ne constitue sa base d'information qu' partir des rponses des serveurs de
noms. Il inscrit les correspondances nom / adresse IP dans un cache avec une dure de validit
limite (Ttl) ; il n'a aucune autorit sur le domaine : il n'est pas responsable de la mise jour des
informations contenues dans son cache, mais il est capable de rpondre aux requtes des clients
Dns.
De plus on peut distinguer les serveurs racine : ils connaissent les serveurs de nom ayant autorit
sur tous les domaines racine. Les serveurs racine connaissent au moins les serveurs de noms
pouvant rsoudre le premier niveau (.com, .edu, .fr, etc.) C'est une pierre angulaire du systme
Dns : si les serveurs racine sont inoprationnels, il n'y a plus de communication sur l'Internet, d'o
multiplicit des serveurs racines (actuellement il y en a 14). Chaque serveur racine reoit environ
100 000 requtes par heure.
Un serveur de nom, en terme de physique, peux trs bien jouer le rle de plusieurs de ces fonctions. On
trouvera par exemple, beaucoup d'entreprise qui hberge leurs domaine sur le serveur Dns primaire
servant aussi de cache pour les requtes sortantes des utilisateurs interne.
4.6 - La diffusion des modifications
"Le
transfert
de
zones"
Pour chaque zone Dns, le serveur servant de rfrence est le Dns matre ou Dns primaire. Les Dns esclaves ou
secondaires servant cette zone vont rcuprer les informations du Dns matre. Cette rcupration d'information
est appele transfert de zone. Seuls les Dns secondaires ont besoin d'tre autoriss effectuer cette opration,
mais assez souvent aucune restriction n'est prsente. Ceci permettant n'importe qui de se connecter via
nslookup
et
d'utiliser
l'argument
ls
-d
permettant
l'affichage
du
contenu
d'une
zone.
Lorsque des changements apparaissent sur une zone, il faut que tous les serveurs qui grent cette zone en soient
informs. Les changements sont effectus sur le serveur principal, le plus souvent en ditant un fichier. Aprs
avoir dit le fichier, l'administrateur signale au serveur qu'une mise jour a t effectue, le plus souvent au
moyen d'un signal (SIGINT). Les serveurs secondaires interrogent rgulirement le serveur principal pour savoir si
les donnes ont chang depuis la dernire mise jour. Ils utilisent un numro constitu de la date au format
amricain: anne, mois, jour; version du jour, il est donc toujours incrment. Donc pour la mise a jour ils
comparent le champ SERIAL du RR SOA de la zone donne par le serveur principal contenant le numro celui
qu'ils connaissent. Si ce numro a augment, ils chargent les nouvelles donnes.
4.7 - Les pannes
Lorsqu'un serveur primaire est indisponible, le serveur secondaire ne reoit pas de rponse ses interrogations
sur le numro de version du fichier de zone. Il continue ses tentatives jusqu' expiration de la validit des
enregistrements de son fichier de zone ('Expire Time'). Lorsqu'un serveur primaire redevient disponible, aucun
mcanisme de synchronisation entre le fichier de zone des serveurs secondaires et celui du serveur primaire n'a
t normalis.
5 - Recherche de ressources
5.1 - Les Rsolveurs
Les "rsolveurs" sont des programmes qui interfacent les applications utilisateur aux serveurs de noms de
domaines. En effet, ce n'est pas l'utilisateur qui effectue les requtes directement. Dans le cas le plus simple, un
rsolveur reoit une requte provenant d'une application (ex., applications de courrier lectronique, Telnet, Ftp)
sous la forme d'un appel d'une fonction de bibliothque, d'un appel systme etc., et renvoie une information sous
une
forme
compatible
avec
la
reprsentation
locale
de
donnes
du
systme.
Le rsolveur est situ sur la mme machine que l'application recourant ses services, mais devra par contre
consulter des serveurs de noms de domaines sur d'autres htes. Comme un rsolveur peut avoir besoin de
contacter plusieurs serveurs de noms, ou obtenir les informations directement partir de son cache local, le
temps de rponse d'un rsolveur peut varier selon de grandes proportions, depuis quelques millisecondes
plusieurs
secondes.
L'une des raisons les plus importantes qui justifient l'existence des rsolveurs est d'liminer le temps
d'acheminement de l'information depuis le rseau, et de dcharger simultanment les serveurs de noms, en
rpondant partir des donnes caches en local. Il en rsulte qu'un cache partag entre plusieurs processus,
utilisateurs, machines, etc., sera incomparablement plus efficace qu'une cache non partag.
5.2 - Les Requtes
La principale activit d'un serveur de noms est de rpondre aux requtes standard. La requte et sa rponse sont
toutes deux vhicules par un message standardis dcrit dans la Rfc 1035. La requte contient des champs
QTYPE, QCLASS, et QNAME, qui dcrivent le(s) type(s) et les classes de l'information souhaite, et quel nom de
domaine cette information concerne. Les requtes sont des messages envoys aux serveurs de noms en vue de
consulter les donnes stockes par le serveur. Par exemple avec Internet, on peut utiliser aussi
bienUdp que Tcp pour envoyer ces requtes.
5.2.1 - Structure des requtes
Parmi les champs fixes on trouve 4 bits trs importants appel code d'opration (OPCODE). Le code
d'opration permet de donner des informations sur la nature du message (requte, rponse, ...). Les quatre
possibilits sont :
Question, Contient la question (nom d'hte ou de domaine sur lequel on cherche des renseignements
et type de renseignements recherchs).
Answer, Contient les RRs qui rpondent la question.
Authority, Contient des RRs qui indiquent des serveurs ayant une connaissance complte de cette
partie du rseau.
Additional, Contient des RRs supplmentaires pouvant tre utiles pour exploiter les informations
contenues dans les autres sections.
Voici un exemple de requte o l'on souhaite connatre le nom du serveur de courrier s'occupant de
frameip.com :
Header
OPCODE=SQUERY
Question
Answer
vide
Authotity
vide
Additionnal
vide
OPCODE=SQUERY, RESPONSE, AA
Question
Answer
Authotity
vide
Additionnal
L'utilisation du mode rcursif est limit aux cas qui rsultent d'un accord ngoci entre le client et le serveur.
Cet accord est ngoci par l'utilisation de deux bits particuliers des messages de requte et de rponse :
Le bit Ra (Rcursion admissible), est marqu ou non par le serveur dans toutes les rponses. Ce bit
est marqu si le serveur accepte priori de fournir le service rcursif au client, que ce dernier l'ait
demand ou non. Autrement dit, le bit RA signale la disponibilit du service plutt que son utilisation.
Les requtes disposent d'un bit Rd (pour "rcursion dsire"). Ce bit indique que le requrant dsire
utiliser le service rcursif pour cette requte. Les clients peuvent demander le service rcursif
n'importe quel serveur de noms, bien que ce service ne puisse leur tre fourni que par les serveurs qui
auront dj marqu leur bit RA, ou des serveurs qui auront donn leur accord pour ce service par une
ngociation propritaire ou tout autre moyen hors du champ du protocole Dns.
Le mode rcursif est mis en oeuvre lorsqu'une requte arrive avec un bit RD marqu sur un serveur
annonant disposer de ce service, le client peut vrifier si le mode rcursif a t utilis en constatant que les
deux
bits
Ra
et
Rd
ont
t
marqus
dans
la
rponse.
Notez que le serveur de noms ne doit pas utiliser le service rcursif s'il n'a pas t explicitement demand
par un bit RD, car cela interfre avec la maintenance des serveurs de noms et de leurs bases de donnes.
Lorsque le service rcursif est demand et est disponible, la rponse rcursive une requte doit tre l'une
des suivantes :
La rponse la requte, ventuellement prface par un ou plusieurs RR CNAME qui indiquent les
alias trouvs pendant la recherche de la rponse.
Une erreur de nom indiquant que le nom demand n'existe pas. Celle-ci peut inclure des RR CNAME
qui indiquent que la requte originale pointait l'alias d'un nom qui n'existe pas.
Une indication d'erreur temporaire.
Si le service rcursif n'est pas requis, ou n'est pas disponible, la rponse non-rcursive devra tre l'une des
suivantes :
Une rponse d'erreur "autorise" indiquant que le nom n'existe pas.
Une indication temporaire d'erreur.
Une
combinaison
- Des RR qui rpondent la question, avec indication si les donnes sont extraites d'une zone ou
d'un
cache.
- D'une rfrence un serveur de noms qui gre une zone plus "proche" du nom demand que le
serveur qui a t contact.
Les RR que le serveur de nom pense tre utile au requrant pour continuer sa recherche.
5.2.4 - Exemple de rsolution de noms
Nous allons voir avec un exemple comment se fait le parcours de l'arborescence pour la rsolution de noms.
On prend par exemple l'adresse suivante : www.frameip.com Il faut alors :
Trouver le NS de la racine
Interroger pour trouver le NS des .com
Poser la question finale au NS de frameip.com qui identifiera l'entre www
5.3 - Les Requtes inverses
5.3.1 - Fonctionnement
Dans le cas d'une requte inverse, le solveur envoie une demande un serveur de noms afin que celui-ci
renvoie le nom d'hte associ une adresse Ip connue. C'est utile surtout pour des questions de scurit,
pour savoir avec qui on change. La mise en place de la rsolution inverse est un peu plus complique, car
l'adressage par nom est bas sur la notion de domaine qui souvent n'a rien voir avec la structure des
adresses Ip. Par consquent, seule une recherche approfondie portant sur tous les domaines peut garantir
l'obtention d'une rponse exacte. Deux moyens existent pour convertir une adresse IP en nom d'hte :
l'usage de requtes Dns inverses (Au sens Opcode=Iquery o Iquery = 1) ou les requtes Dns de type Ptr
(Classe
IN
et
Opcode=Query).
En effet, dans le premier cas, on envoie un message Dns contenant une rponse et on demande toutes les
questions pouvant conduire cette rponse, alors que les requtes Ptr posent la question de faon explicite :
Qui
est
l'adresse
a.b.c.d
?
Une requte Dns inverse a la particularit d'avoir le champ Question vide, et de contenir une entre dans le
champ Answer. Pour que le serveur Dns comprenne le sens de la requte, le champ Opcode des en-ttes du
message Dns doit tre la valeur Iquery. Voici une reprsentation extraite de la Rfc 1035 :
Header
OPCODE=IQUERY, ID=997
Question
"EMPTY"
Answer
"ANYNAME" A IN 10.1.0.52
Authotity
"EMPTY"
Additionnal
"EMPTY"
Pour rpondre aux requtes inverses en vitant des recherches exhaustives dans tous les domaines, un
domaine spcial appel in-addr.arpa a t cr. Une fois le domaine in-addr.arpa construit, des
enregistrements de ressources spciaux sont ajouts pour associer les adresses IP au noms d'hte qui leur
correspondent. Il s'agit des enregistrements pointeurs (PTR), ou enregistrements de rfrences. Par exemple
pour connatre le nom de la machine dont l'adresse est 137.194.206.1, on envoie une requte dont la
question contient QNAME=1.206.194.137.IN-ADDR.ARPA.
5.3.2 - Exemple
Ligne
de
commande
permettant
d'tablir
la
requte
Capture
du
Capture
du
datagramme
datagramme
Query
Answer
6 - La scurit
6.1 - Fragilit
Sans le Dns, la majorit des applications d'Internet s'arrtent! De plus le Dns est souvent la cible favorite
desdnis de service (Dos) des pirates. Il y a aussi un exemple simple avec le systme de requtes inverses vu
prcdemment qui entrane une fuite d'information (ceci reprsentant la partie dcouverte de l'attaque). Jusqu'ici,
nous n'avons utiliss les requtes Dns inverses que pour faire la correspondance entre une adresse Ip et
l'hostname associ (Requte de classe IN et de type A). Or, nous pouvons faire des recherches inverses sur
d'autres types de ressources. Par exemple, nous pourrions mettre une requte inverse au sujet des champs
HINFO1 pour se chercher toutes les machines tournant sous une version vulnrable d'un certain systme
d'exploitation. En effet, le champs Hinfo est sens contenir le type et version du Systme d'Exploitation de la
machine.
6.2 - Scurisation
Les normes de scurisation du Dns portent sur la certification de l'origine des donnes, l'authentification des
transactions et des requtes. Elles ne portent pas sur la confidentialit des informations : les donnes changes
ne sont pas chiffres avant d'tre transportes par le rseau et n'apporte aucune protection aux en-ttes des
messages
Dns,
ou
aux
trames
de
commandes
(requtes
Dns).
La scurisation du Dns doit assurer l'authentification d'une transaction, c'est dire que le Resolver reoit une
rponse provenant bien du serveur qui il a envoy une requte, qu'il s'agit de la rponse correspondant
effectivement sa requte, que la trame n'a pas t "diddled" (dup) lors de son transport par le rseau.
L'authentification de transaction est assure par le rajout d'un "Enregistrement de Signature" (SIG RR) la fin de
la trame de rponse. La signature est cre partir d'une concatnation entre la rponse du serveur et la requte
du client. La clef prive utilise pour la signature appartient au serveur qui met le message sign, et non la
zone. Les clefs publiques utilises dans les mcanismes de scurisation du Dns sont contenues dans des
"Enregistrements de Clefs" (Key RR) stocks dans la base de donnes du Dns. Ces clefs publiques peuvent tre
destines une zone, un host ou autre. Un KEY RR est authentifi par un SIG RR comme n'importe quel autre
enregistrement.
7 - Conclusion
Le systme de gestion de noms Dns est efficace et unificateur. De plus, comme tous les systmes cruciaux d'Internet,
il
y
a
au
moins
une
implmentation
efficace
et
gratuite.
C'est
portable
et
trs
complet.
Bind est le gestionnaire de Dns le plus connu et probablement un des plus complets. Il fonctionne sous Unix et
Windows. Nouvelle syntaxe des fichiers de configuration sur la dernire version 9 avec un systme de log flexible par
catgories, une liste d'accs par adresse Ip sur les requtes, transfert de zones et mises a jours pour chaque zone,
transfert de zones plus efficaces et enfin des meilleures performances pour les serveurs grant des milliers de zones.
Rcemment est apparue le DnsSEC. DnsSEC est un ensemble de protocoles utilisant de la cryptographie symtrique
et/ou asymtrique incorporant un systme de stockage et de publication des cls publiques. Ainsi, il permet de
rsoudre les diffrents problmes de scurit lors des transferts de zone, des mises jour (update dynamique par
exemple) et de rendre inoprant le Dns spoofing (dtournement de flux entre deux machines l'avantage du pirate). A
ces nouveauts s'ajoute la compatibilit avec IPv6 et surtout l'interoprabilit des deux systmes d'adressages, ce qui
en fait un systme trs complexe. Les dernires versions de Bind 9 incorporent ces dernires possibilits, mais il
faudrait un dploiement l'chelle mondiale pour que le systme soit rellement utilisable.
NTP
1 - Introduction
2 - Ncessit d'avoir un temps prcis et fiable
3 - Bref historique
3.1 - TP
3.2 - NTP
3.3 - SNTP
4 - Objectifs
5 - Architecture systme et rseau, NTP v3
5.1 - Rfrences de temps
5.2 - Prcision
5.3 - Structure d'un rseau NTP
5.4 - Fonctionnement d'un serveur NTP : cinq modes diffrents
6 - Mcanismes de synchronisation
6.1 - Gestion des messages
6.2 - Traitements internes
6.3 - Rglage de l'horloge
7 - Exemple de trame NTP
8 - Les serveurs NTP d'Internet
9 - Conclusion
10 - Les liens
11 - Discussion autour de la documentation
12 - Suivi du document
1 - Introduction
Actuellement tout quipement informatique dispose d'une horloge matrielle ou logicielle laquelle il est fait rfrence
pour horodater des fichiers, des transactions, des courriers lectroniques, etc... Cette horloge, bien que conue autour
d'un oscillateur quartz, drive comme toute montre ordinaire.
Ceci est d'autant plus gnant lorsque les machines sont en rseau et partagent des ressources communes comme des
systmes de fichiers. Par exemple, certains outils de dveloppement, comme la commande Unix "make", basent leur
travail sur la comparaison des dates de modification de fichiers. De mme, la cohrence et la comparaison de
messages de "logs" de plusieurs systmes devient trs difficile s'ils ne sont pas la mme heure.
La ncessit de synchroniser des quipements en rseau parat alors vidente. C'est la finalit du protocole Network
Time Protocol (NTP), qui synchronise les machines et les routeurs des rseaux. Au cours des 20 dernires annes de
recherches sur ce sujet sensible, trois protocoles ont vu le jour, avec pour aboutissement la version actuelle de NTP
utilise par les systmes.
Nous allons passer rapidement sur ces prcurseurs du protocole NTP. Nous dfinirons ensuite les buts du protocole.
Puis nous verrons les diffrentes architectures qui implmentent ce protocole. Nous dtaillerons enfin les mcanismes
de synchronisation mis en place dans NTP.
3 - Bref historique
Le temps lgal dfini par la seconde lgale a t bas :
Jusqu'en 1956 la seconde lgale tait dfinie comme la 86400me partie du jour solaire moyen. A partir de 1956 la
seconde des phmrides a t dfinie par le comit international des poids et mesure comme tant la fraction
1/31556925.9747 de l'anne tropique pour 1900 janvier 0 12 heures de temps des phmrides. Depuis 1967 la
seconde lgale est dfinie comme la dure de 9 192 631 770 priodes de la radiation correspondant la transition
entre les deux niveaux hyperfins de l'tat fondamental de l'atome de csium 133.
Afin de de synchroniser les systmes travers les rseaux, plusieurs protocoles ont vu le jour avant l'arrive de la
version de NTP actuellement utilise.
3.1 - TP
En 1983, un premier protocole, le Time Protocole est ralis RFC 868. Il est rapidement popularis et repris sur
les systmes Unix au travers du dmons timed et de la commande rdate. Cependant ses limites sont vite atteintes
car, d'une part, il n'offre qu'une prcision de l'ordre de la seconde, et d'autre part, il n'implmente aucun
mcanisme pour compenser la drive des horloges.
3.2 - NTP
Dans le mme temps, les toutes premires versions de NTP sont labores sous le nom d'Internet Clock Service.
On voit cette implmentation utilise dans le protocole de routage HELLO. Cependant, la premire version de NTP
proprement parl apparat en 1988 et ses spcifications sont relates dans le RFC 1059. Dans cette version sont
dj prsents les modes de communication client/serveur et symtrique pour la distribution du temps. Un an plus
tard (1989), apparat la deuxime version de NTP RFC 1119 qui introduit un aspect scuritaire car il permet de
crypter les paquets de communication grce un algorithme de chiffrage cl secrte (DES-CBS). De son cot, la
Digital Equipment Corporation (DEC) met au point le Digital Time Synchronisation Service (DTSS). Se basant alors
sur les bonnes ides de ce dernier et sur NTPv2, une troisime version de NTP voit le jour en 1992 RFC 1305.
C'est la plus utilise jusqu' ce jour. Depuis 1994, une nouvelle spcification de NTP est l'tude pour prendre en
compte les changements de l'Internet comme le support d'IPv6 ou bien encore le chiffrement des paquets avec un
systme cl publique. Bien que cette dernire spcification n'ai toujours pas t rendue publique, une
implmentation de cette version est dj disponible. Pour le moment elle est trs peu rpandue bien qu'elle
assure comme ses prdcesseurs une compatibilit ascendante. On la trouve surtout sur le rseau "DCnet
Research Network" o son comportement est mis l'preuve. Bien videmment, chaque version de NTP a apport
son lot d'amliorations quant l'efficacit des algorithmes afin d'obtenir une meilleure fiabilit et disponibilit du
systme.
3.3 - SNTP
En dernier lieu, une version simplifie du protocole NTP est dveloppe en parallle. Il s'agit du Simple Network
Time Protocol (SNTP) spcifi dans la RFC 4330 et qui en est dj sa quatrime version. SNTP est destin des
rseaux o la prcision de l'ordre de la seconde est suffisante (exemple : workstations). A la base, SNTP amne
un allgement des algorithmes de traitement des paquets NTP, ce qui permet d'envisager SNTP sur des systmes
embarqus o la capacit de calculs, notamment virgule flottante, est gnralement trs limit. L'objectif de ce
nouveau protocole est de faciliter l'implmentation d'un client NTP n'ayant pas besoin de beaucoup de prcision
tout en tant capable de dialoguer avec des serveurs NTP standards. Cependant, l'utilisation de SNTP doit rester
limite pour ne pas perturber et fausser le rseau NTP. En fait, il est vivement recommand de n'utiliser SNTP
qu'en bout de chane dans les change NTP, c'est dire directement sur une horloge de rfrence (horloge
atomique) ou bien sur les systmes clients exclusivement. On doit ainsi viter de faire d'un systme rgl par
SNTP, une rfrence pour un autre systme.
4 - Objectifs
Ce quoi sert NTP
les horloges pilotes par des signaux radio mis par des metteurs spcialiss comme DCF77 en
Allemagne
les horloges pilotes par des metteurs de radio-diffusion publiques transmettant, en plus de leur
programme, des informations horaires comme l'metteur TDF d'Allouis diffusant France-Inter
les systmes de positionnement, comme le GPS, constituent d'excellentes sources de rfrence
5.2 - Prcision
Le protocole NTP fournit diffrents niveaux de prcision :
L'architecture de NTPv4 permet d'atteindre une prcision 10 fois plus grande, de l'ordre de la microseconde sur les
nouveaux rseaux plus performants.
5.3 - Structure d'un rseau NTP
L'une des caractristiques principales d'un rseau NTP est sa structure pyramidale. Un certain nombre de sources
de rfrence, dites primaires, synchronises par la radio ou un rseau filaire sur les standards nationaux, sont
connectes des ressources largement accessibles, comme des passerelles de backbone et des serveurs de
temps primaires.
Le but de NTP est de transporter ces informations de temps de ces serveurs vers d'autres serveurs de temps
relis Internet. Il vrifie aussi les horloges pour minimiser les erreurs dues aux problmes de propagation sur le
rseau.
Quelques machines ou passerelles des rseaux locaux, agissant en tant que serveurs de temps secondaires, font
tourner NTP, en connexion avec un ou plusieurs serveurs primaires.
Dans l'optique de rduire le trafic engendr par le protocole, les serveurs de temps secondaires distribuent le
temps via NTP aux machines restantes sur le rseau local.
Dans un souci de fiabilit, certaines machines peuvent tre quipes avec des horloges moins prcises, mais aussi
moins chres, afin d'tre utilises pour des sauvegardes, en cas de dfaillance des serveurs de temps (primaires
ou secondaires) ou des chemins rseaux.
Pour rsumer : des rfrences de temps synchronisent des serveurs NTP qui leur sont directement raccords.
Ceux-ci constituent la strate 1 et ils vont synchroniser chacun plusieurs dizaines d'autres serveurs qui vont
constituer la strate 2 et ainsi de suite jusqu'aux clients terminaux. Ce principe permet de bien rpartir la
charge des serveurs tout en conservant une distance aux sources de rfrence relativement faible. Relations entre
serveurs NTP :
Mode
symtrique
actif
Un serveur fonctionnant dans ce mode envoie priodiquement des messages, sans se soucier de l'tat de
ses voisins (joignables, serveurs primaires ou secondaires, clients). Il indique ainsi sa volont de
synchroniser
d'autres
serveurs
et
d'tre
synchroniser
par
eux.
Mode
symtrique
passif
ce type d'association est gnralement cre lors de l'arrive sur le serveur d'un message d'un autre
serveur (en mode symtrique actif). Le serveur annonce son intention de synchroniser et d'tre
synchronis. Seulement il ne le fait qu'aprs avoir t sollicit par un autre serveur.
Mode
client
La machine envoie des messages rgulirement, sans se proccuper de l'tat de ses voisins. La station
(typiquement, elle appartient un rseau LAN) indique ainsi sa volont d'tre synchronise.
Mode
serveur
L'association de ce mode est cre lors de la rception d'une requte (un message) d'une station en
mode
client.
Mode
broadcast
Destin aux rseaux locaux, il se limite une diffusion d'informations horaires pour des clients pouvant
tre soit passifs, soit dcouvrant ainsi les serveurs avec lesquels ils vont se synchroniser.
La fiabilit du systme est assure par la redondance des serveurs et l'existence de plusieurs chemins dans un
rseau, pour aller d'un point un autre.
Les serveurs primaires (strate 1) se synchronisent sur des horloges de rfrence par radio, ou autre. Il en existe
environ 230 dans le monde. Les clients et serveurs communiquent en mode client/serveur, symtrique ou
multicast, avec ou sans cryptage.
Les serveurs secondaires (environ 4500)(ex : serveurs de campus universitaires) se synchronisent sur plusieurs
serveurs primaires en mode client/serveur, et avec d'autres serveurs secondaires en mode symtrique.
D'une manire gnrale, les serveurs d'une strate se synchronisent sur plusieurs serveurs de la strate suprieure
en mode client/serveur, et avec d'autres serveurs de la mme strate en mode symtrique.
Les simples clients se synchronisent en mode client/serveur s'ils sont isols, ou en mode multicast s'ils font partie
d'un rseau (ex : machines universitaires se synchronisant sur plusieurs serveurs de strate 3, comme les serveurs
des dpartements universitaires).
Une station en mode client envoie de temps en temps un message NTP une station en mode serveur,
gnralement peu de temps aprs avoir redmarr. Le serveur n'a pas besoin d'enregistrer des informations sur
l'tat du client, puisque c'est le client qui dcide quand envoyer une requte, en fonction de son tat en local.
Dans ce mode, le fonctionnement pourrait tre simplifi en un mcanisme de RPC sans perdre de prcision ni de
robustesse, surtout dans le cadre d'un rseau LAN haut dbit.
Dans les modes symtriques, la distinction client/serveur disparat. Le mode passif est destin aux serveurs de
temps qui se trouvent prs de la racine du systme de synchronisation (les serveurs de la strate 1 ou 2).
Le mode symtrique actif est destin aux serveurs de temps qui se trouvent prs des feuilles du rseau de
synchronisation, sur les strates les plus leves. La fiabilit du service de temps peut tre gnralement assure
avec deux stations sur le niveau au-dessus (strate plus petite) et une station sur le mme niveau. Normalement,
une station fonctionne en mode actif (symtrique, client ou broacast) avec une configuration donne au
dmarrage, alors que les autres sont en mode passif (symtrique ou serveur) sans configuration pralable.
Cependant une erreur intervient lorsque deux stations qui communiquent sont dans le mme mode, sauf pour le
mode symtrique actif. Dans ce cas, chaque station ignore les messages de l'autre et l'association cre par cet
change n'est rompue qu'en cas de coupure de rseau entre les deux stations.
Le mode broadcast est surtout destin aux rseaux locaux avec beaucoup de stations et o la prcision requise
n'est pas trs importante. Le droulement classique est le suivant : un ou plusieurs serveurs de temps du rseau
envoie rgulirement des broacasts aux stations, pour dterminer l'heure, avec une latence de l'ordre de quelques
millisecondes.
Comme dans le mode client/serveur, le protocole utilis peut tre simplifi. Ainsi, un systme bas sur
l'algorithme de slection d'horloge peut tre utilis dans le cas o on dispose de multiples serveurs de temps, afin
d'optimiser la fiabilit.
NTP intgre un systme d'exploration du rseau pour dcouvrir automatiquement de nouveaux serveurs NTP, par
diffrentes mthodes :
Multicast
Manycast
(mode
plus
prcis)
Les
clients
inondent
le
rseau
local
par
un
message
multicast.
Les
serveurs
rpondent
en
multicast.
- Les clients communiquent ensuite avec les serveurs comme s'ils avaient t configurs en unicast.
Des contrles de time-out et de TTL garantissent le bon droulement de la configuration.
6 - Mcanismes de synchronisation
6.1 - Gestion des messages
Comme beaucoup de systmes distribus sur un rseau, les htes NTP (clients ou serveurs) utilisent des
messages pour communiquer.
Voici les champs contenus dans un paquet NTP :
La synchronisation d'un client ncessite plusieurs changes de messages afin d'amliorer chaque fois
l'estimation du temps. Dans la pratique, il faut peu prs cinq minutes pour que l'horloge du systme devienne
fiable. Une fois cette synchronisation effectue, le client pourra devenir son tour un systme de rfrence. De
plus, plus le client change des messages avec ses serveurs de rfrence, plus il est capable de discerner, parmi
eux, ceux qui amnent une certaine part d'erreur dans la dtermination du temps. Le cas chant, il peut dcider
de ne plus faire appel ces systmes appels falsetickers .
L'change de messages conduisant la synchronisation suit la procdure suivante :
Le systme dsirant tre synchronis envoie d'abord un paquet dans lequel il initialise le champ
Originate timestamp avec sa propre heure systme.
Le serveur stocke ensuite l'heure de rception du paquet dans le champ Receive timestamp du
mme paquet.
Ensuite il effectue un contrle de validit du paquet pour s'assurer qu'il doit bien effectuer le traitement
(vrification du stratum du client, authentification, ...).
Avant de retourner le paquet l'expditeur, le champ Transmit timestamp est renseign avec l'heure
courante du serveur.
Le client enregistre l'heure de rception de la rponse afin de pouvoir estimer le temps de trajet du
paquet. En supposant que les dlais de transmission des messages sont symtriques, le temps de trajet
correspond la moiti du temps d'attente total moins le temps de traitement sur la machine distante.
(NTP implmente un algorithme de Huff&Puff pour compenser les dlais de transmission asymtriques)
Le client lui aussi vrifie la validit de la rponse pour savoir si elle doit tre prise en compte.
Le systme client peut alors estimer le dcalage de son horloge avec le systme de rfrence.
6.2 - Traitements internes
Une fois la rponse du serveur obtenue, un ensemble d'algorithmes prend le relais afin de dterminer le dcalage
de l'horloge locale avec le systme distant.
On peut reprsenter la suite des traitements comme ci-dessous :
Les filtres liminent les rponses non conformes aux attentes du protocole.
L'algorithme de slection dtecte les donnes errones afin de lutter contre les comportements byzantins
des serveurs.
Ensuite l'algorithme de combinaison compare les rponses des diffrents serveurs entres elles et avec les
rponses prcdentes pour dterminer le mieux possible le dcalage de l'horloge locale.
Enfin l'algorithme de contrle de l'horloge utilisera les mthodes qui sont sa disposition pour recaler l'horloge.
6.3 - Rglage de l'horloge
Une fois que le dcalage a t dtermin, il faut agir sur l'horloge pour se synchroniser. Plusieurs possibilits
d'action s'offrent alors au processus qui interagit avec l'horloge:
Il peut changer brutalement l'heure systme. Cette technique est viter car elle perturbe les
applications utilisant l'horloge du systme et peut mme engendrer une certaine instabilit.
Le processus peut aussi faire varier la frquence d'horloge: la ralentir si elle est en avance ou
inversement, l'acclrer pour lui faire rattraper son retard. Cette technique permet un contrle plus fin
de l'heure locale et a l'avantage de prserver l'intgrit du systme.
pool.ntp.org
0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org
3.pool.ntp.org
Pour obtenir une meilleur prcision, vous pouvez aussi spcifier le pays o vous dsirez prendre le temps de rfrence,
comme par exemple la France qui vous garantira un temps de rponse plus rapide et plus pertinent. Pour cela, vous
rajoutez fr comme cela :
fr.pool.ntp.org
0.fr.pool.ntp.org
1.fr.pool.ntp.org
2.fr.pool.ntp.org
3.fr.pool.ntp.org
9 - Conclusion
Le protocole NTP est le plus utilis travers le monde pour la synchronisation des machines. Son succs est du sa
facilit de mise en place, sa haute fiabilit ainsi qu' l'exprience des chercheurs qui travaillent sur le projet depuis
plus de vingt ans.
La quatrime version du protocole permettra encore plus de fiabilit et de prcision dans la dtermination du temps.
Mais la version actuellement utilise en fait dj un protocole incontournable que tout bon informaticien devrait
connatre.
SNMP
1 - Introduction
2 - SNMP (Simple Network Management Protocol)
2.1- Prsentation gnrale
2.2- Fonctionnement
2.3- Les MIBS
3 - Prsentation, volution des versions de SNMP
4 - SNMPv1 et v2
4.1- Les faiblesses de SNMPv1
4.2- Les amliorations de SNMPv2c
5 - SNMP v3
5.1 - User Security Module (USM)
5.1.1 - L'authentification
5.1.2 - Le cryptage
5.1.3 - L'estampillage de temps
5.2 - VACM (View Access Control Model)
5.3 - La trame de SNMPv3
6 - Exemple de trame SNMP
7 - Conclusion
8 - Discussion autour de la documentation
9 - Suivi du document
1 - Introduction
L'informatique est de plus en plus prsent dans notre vie de tous les jours. On compte dsormais sur les services
offerts par les rseaux pour le fonctionnement de l'outil informatique, que ce soit en entreprise, lors de transactions
bancaires, lors de tlconfrences, etc. Les services offerts sont devenus quasi-indispensables. Pour assurer que ces
services soient convenables, il est ncessaire de surveiller le rseau et d'agir quand une erreur se produit.
Sur les rseaux physiques de nombreuses composantes sont donc surveiller : l'utilisation de la largeur de bande,
l'tat de fonctionnement des liens, les ventuels goulets d'tranglement, les problmes de cblage, le bon
cheminement de l'information entre les machines, etc. Pour ce faire diffrents points stratgiques sont observer
comme les routeurs, les concentrateurs, les liens, les postes, les imprimantes.
Ainsi, en cas de panne ou de mauvais fonctionnement sur le rseau, l'administrateur doit pouvoir interprter
l'information reue pour identifier la source du problme. Un protocole de gestion est ncessaire pour exercer les
fonctions de gestion sur un rseau. Il doit tre capable de dialoguer avec tous les lments de celui-ci.
La station de supervision (appele aussi manager) excute les applications de gestion qui contrlent les
lments rseaux. Physiquement, la station est un poste de travail.
La MIB (Management Information Base) est une collection d'objets rsidant dans une base d'information
virtuelle. Ces collections d'objets sont dfinies dans des modules MIB spcifiques.
Le protocole, qui permet la station de supervision d'aller chercher les informations sur les lments de
rseaux et de recevoir des alertes provenant de ces mmes lments.
2.2- Fonctionnement
Le protocole SNMP est bas sur un fonctionnement asymtrique. Il est constitu d'un ensemble de requtes, de
rponses et d'un nombre limit d'alertes. Le manager envoie des requtes l'agent, lequel retourne des rponses.
Lorsqu'un vnement anormal surgit sur l'lment rseau, l'agent envoie une alerte (trap) au manager.
SNMP utilise le protocole UDP [RFC 768]. Le port 161 est utilis par l'agent pour recevoir les requtes de la station
de gestion. Le port 162 est rserv pour la station de gestion pour recevoir les alertes des agents.
Les
requtes
Il existe quatre types de requtes: GetRequest, GetNextRequest, GetBulk, SetRequest.
La
La
La
La
requte
requte
requte
requte
SNMP
Les
rponses
de
SNMP
la suite de requtes, l'agent rpond toujours par GetResponse. Toutefois si la variable demande n'est pas
disponible, le GetResponse sera accompagn d'une erreur noSuchObject.
Les
alertes
(Traps,
Notifications)
Les alertes sont envoyes quand un vnement non attendu se produit sur l'agent. Celui-ci en informe la station
de supervision via une trap. Les alertes possibles sont: ColdStart, WarmStart, LinkDown, LinkUp,
AuthentificationFailure.
2.3- Les MIBS
La MIB (Management Information base) est la bas de donnes des informations de gestion maintenue par
l'agent, auprs de laquelle le manager va venir pour s'informer.
Deux MIB publics ont t normalises: MIB I et MIB II (dite 1 et 2)
Un fichier MIB est un document texte crit en langage ASN.1 (Abstract Syntax Notation 1) qui dcrit les variables,
les tables et les alarmes gres au sein d'une MIB.
La MIB est une structure arborescente dont chaque noeud est dfini par un nombre ou OID (Object Identifier).
Elle contient une partie commune tous les agents SNMP en gnral, une partie commune tous les agents
SNMP d'un mme type de matriel et une partie spcifique chaque constructeur. Chaque quipement
superviser possde sa propre MIB. Non seulement la structure est normalise, mais galement les appellations
des diverses rubriques.
Ces appellations ne sont prsentes que dans un souci de lisibilit. En ralit, chaque niveau de la hirarchie est
repr par un index numrique et SNMP n'utilise que celui-ci pour y accder.
Ainsi, pour interroger les diffrentes variables d'activit sur un appareil, il faudra explorer son arborescence MIB.
Celle-ci est gnralement fournie par le constructeur mais il est aussi possible d'utiliser un explorateur de MIB tel
que Getif MIB Browser .
Ensuite, pour accder aux variables souhaites, on utilisera l'OID (Object Identification) qui dsigne
l'emplacement de la variable consulter dans la MIB. On aura par exemple sur un commutateur Nortel Passport
l'OID .1.3.6.1.4.1.2272.1.1.20 dsignant le taux de charge du CPU.
Lorsqu'une entreprise veut dfinir son propre ensemble de variables de gestion, elle va enregistrer son numro
d'objet sous le noeud iso.org.dod.internet.private.entreprise. Ces MIB seront dites prives. Elles correspondent
la racine 1.3.6.1.4.1. Voici la liste de toutes les affectations officielles :
entreprise.0-4998
entreprise.5000-9999
entreprise.10000-14999
entreprise.14999-19999
entreprise.20000-24999
entreprise.25000-27274
SNMPv1 (ancien standard): Ceci est la premire version du protocole, tel que dfinie dans le RFC 1157.. On
dit que la scurit de cette version est triviale, car la seule vrification qui est faite est base sur la chane de
caractres " community ". SNMPsec (historique): Cette version ajoute de la scurit au protocole SNMPv1. La
scurit est base sur des groupes. Trs peu ou aucun manufacturiers n'a utilis cette version qui est
maintenant
largement
oublie.
RFC
1155
SNMPv2p (historique): Beaucoup de travaux on t excuts pour faire une mise jour de SNMPv1. Ces
travaux ne portaient pas seulement sur la scurit. Le rsultat est une mise jour des oprations du
protocole, des nouvelles oprations, des nouveaux types de donnes. La scurit est base sur les groupes
de
SNMPsec.
SNMPv2c (exprimental): Cette version du protocole est appel " community stringbased SNMPv2 ". Ceci est
une amlioration des oprations de protocole et des types d'oprations de SNMPv2p et utilise la scurit par
chane
de
caractres
"community
"
de
SNMPv1.
RFC
1441
SNMPv2u (exprimental): Cette version du protocole utilise les oprations, les types de donnes de SNMPv2c
et
la
scurit
base
sur
les
usagers.
SNMPv2* (exprimental): Cette version combine les meilleures parties de SNMPv2p et SNMPv2u. Les
documents qui dcrivent cette version n'ont jamais t publis dans 12 les RFC. Des copies de ces documents
peuvent tre trouves sur le site web et SNMP Research (un des premiers dfendre de cette version).
RFC
1901
SNMPv3 (standard actuel): Cette version comprend une combinaison de la scurit base sur les usagers et
les types et les oprations de SNMPv2p, avec en plus la capacit pour les " proxies ". La scurit est base
sur
ce
qui
se
trouve
dans
SNMPv2u
et
SNMPv2*.
RFC - 3411
4 - SNMPv1 et v2
La trame SNMPv1 est compltement encode en ASN.1 [ISO 87]. Les requtes et les rponses ont le mme format
La version la plus utilise est encore la version 1. Plusieurs versions 2 ont t proposes par des documents
de travail, mais malheureusement, aucune d'entre elles n'a jamais t adopte comme standard. La version 3
est actuellement en voie d'tre adopte. On place la valeur zro dans le champ version pour SNMPv1, et la
valeur
3
pour
SNMPv3.
La communaut permet de crer des domaines d'administration. La communaut est dcrite par une chane
de
caractres.
Par
dfaut,
la
communaut
est
PUBLIC.
Le PDU type dcrit le type de requte, de rponse ou d'alerte. Le Tableau 2 donne les valeurs associes ces
champs.
Une des plus grandes faiblesses du protocole SNMPv1 est l'absence d'un mcanisme adquat pour assurer la
confidentialit et la scurit des fonctions de gestion. Les faiblesses comprennent aussi l'authentification et le
cryptage, en plus de l'absence d'un cadre administratif pour l'autorisation et le contrle d'accs. Ce problme rend
la scurit sur SNMPv1 du type : "SHOW-AND-TELNET", c'est dire qu'on utilise SNMP pour l'acquisition des
donnes de gestion, mais pas pour effectuer le contrle on utilise le protocole Telnet.
Le groupe de travail de l'IETF qui a oeuvr sur SNMPv2 a voulu inclure la scurit dans la nouvelle version.
Malheureusement, ce groupe n'a pas pu atteindre un consensus sur le fonctionnement du mcanisme de scurit.
Partant de l, deux propositions ont t dveloppes (SNMPv2u et SNMPv2*). La plupart des experts s'entendent
pour dire que deux standards SNMP ne peuvent pas coexister, et que ceci n'est pas une solution long terme.
Tous les consensus du groupe de travail ont t rassembls (uniquement les amliorations qui ne portaient pas
sur la scurit), et le groupe de travail SNMPv2 de l'IETF a termin ses travaux en publiant une version de
SNMPv2 (on l'appelle SNMPv2c, RFC 1901, RFC 1905 et RFC 1906) sans scurit.
4.2- Les amliorations de SNMPv2c
SNMPv2c a introduit quelques nouveaux types, mais sa nouveaut majeure est l'opration GETBULK, qui permet
une plate forme de gestion, de demander en bloc de plusieurs variables conscutives dans la MIB de l'agent.
Gnralement, on demande autant de variables que l'on peut mettre dans un paquet SNMP. Ceci rgle un
problme majeur de performance dans SNMPv1. Avec la version 1, la plate forme est oblige de faire un GETNEXT
et d'attendre la rponse pour chaque variable de gestion.
5 - SNMP v3
Cette nouvelle version du protocole SNMP vise essentiellement inclure la scurit des transactions. La scurit
comprend l'identification des parties qui communiquent et l'assurance que la conversation soit prive, mme si elle
passe par un rseau public.
Cette scurit est base sur 2 concepts :
5.1.1 - L'authentification
L'authentification a pour rle d'assurer que le paquet reste inchang pendant la transmission, et que le mot
de passe est valide pour l'usager qui fait la requte.
Pour construire ce mcanisme, on doit avoir connaissance des fonctions de hachage une seule direction.
Des exemples de ces fonctions sont : MD5 et SHA-1. Ces fonctions prennent en entre une chane de
caractres de longueur indfinie, et gnrent en sortie une chane d'octets de longueur finie (16 octets pour
MD5, 20 octets pour SHA-1).
Pour authentifier l'information qui va tre transmise, on doit aussi avoir un mot de passe qui est partag .
Le mot de passe ne doit donc tre connu que par les deux entits qui s'envoient les messages, et
prfrablement par personne d'autre.
La figure ci dessous montre le mcanisme d'authentification :
Avec cette technique, le mot de passe est valid sans qu'il ait t transmis sur le rseau. Quelqu'un qui saisit
les paquets SNMPv3 passants sur le rseau ne peut pas facilement trouver le mot de passe.
Pour ce qui est de SNMPv3, l'authentification se fait l'aide de HMAC-MD5-96 ou de HMAC-SHA- 96, qui est
un peu plus compliqu que ce qui a t dcrit ici. Le rsultat de la fonction de hachage est plac dans le bloc
paramtres de scurit du paquet SNMPv3.
L'authentification se fait sur tout le paquet.
L'tape d'authentification ne vise pas cacher l'existence du paquet ou le crypter. Si l'on utilise
uniquement l'authentification, les personnes qui saisissent les paquets passants sur le rseau peuvent encore
en voir le contenu. Toutefois, elles ne peuvent pas changer le contenu sans connatre le mot de passe.
5.1.2 - Le cryptage
Le cryptage a pour but d'empcher que quelqu'un n'obtienne les informations de gestion en coutant sur le
rseau les requtes et les rponses de quelqu'un d'autre.
Avec SNMPv3, le cryptage de base se fait sur un mot de passe partag entre le manager et l'agent. Ce
mot de passe ne doit tre connu par personne d'autre. Pour des raisons de scurit, SNMPv3 utilise deux
mots de passe : un pour l'authentification et un pour le cryptage. Ceci permet au systme d'authentification
et au systme de cryptage d'tre indpendants. Un de ces systmes ne peut pas compromettre l'autre.
SNMPv3 se base sur DES (Data Encryption Standard) pour effectuer le cryptage.
On utilise une cl de 64 bits (8 des 64 bits sont des parits, la cl relle est donc longue de 56 bits) et DES
encrypte 64 bits la fois. Comme les informations que l'on doit encrypter sont plus longues que 8 octets, on
utilise du chanage de blocs DES de 64 bits.
Une combinaison du mot de passe, d'une chane alatoire et d'autres informations forme le Vecteur
d'initialisation . Chacun des blocs de 64 bits est pass par DES et est chan avec le bloc prcdent avec un
XOR. Le premier bloc est chan par un XOR au vecteur d'initialisation. Le vecteur d'initialisation est transmis
avec chaque paquet dans les Paramtres de scurit , un champs qui fait partie du paquet SNMPv3.
Contrairement l'authentification qui est applique tout le paquet, le cryptage est seulement applique sur
le PDU.
La RFC 3826 "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security
Model" relate l'intgration d'AES dans SNMP. Celui renforce le chiffrement en remplacement du DES.
Cependant, pour le moment, cette RFC est en cours de validation et donc pas encore officialise.
5.1.3 - L'estampillage de temps
Si une requte est transmise, les mcanismes d'authentification et de cryptage n'empchent pas quelqu'un
de saisir un paquet SNMPv3 valide du rseau et de tenter de le rutiliser plus tard, sans modification.
Par exemple, si l'administrateur effectue l'opration de remise jours d'un quipement, quelqu'un peut saisir
ce paquet et tenter de le retransmettre l'quipement chaque fois que cette personne dsire faire une
mise jour illicite de l'quipement. Mme si la personne n'a pas l'autorisation ncessaire, elle envoie un
paquet, authentifi et encrypt correctement pour l'administration de l'quipement.
On appelle ce type d'attaques le Replay Attack . Pour viter ceci, le temps est estampill sur chaque
paquet. Quand on reoit un paquet SNMPv3, on compare le temps actuel avec le temps dans le paquet. Si la
diffrence est plus que suprieur 150 secondes, le paquet est ignor.
SNMPv3 n'utilise pas l'heure normale. On utilise plutt une horloge diffrente dans chaque agent. Ceux-ci
gardent en mmoire le nombre de secondes coules depuis que l'agent a t mis en circuit. Ils gardent
galement un compteur pour connatre le nombre de fois o l'quipement a t mis en fonctionnement. On
appelle ces compteurs BOOTS (Nombre de fois ou l'quipement a t allum) et TIME (Nombre de secondes
depuis la dernire fois que l'quipement a t mis en fonctionnement).
La combinaison du BOOTS et du TIME donne une valeur qui augmente toujours, et qui peut tre utilise pour
l'estampillage. Comme chaque agent a sa propre valeur du BOOTS/TIME, la plate-forme de gestion doit
garder une horloge qui doit tre synchronise pour chaque agent qu'elle contacte. Au moment du contact
initial, la plateforme obtient la valeur du BOOTS/TIME de l'agent et synchronise une horloge distincte.
5.2 - VACM (View Access Control Model)
Permet le contrle d'accs au MIB. Ainsi on a la possibilit de restreindre l'accs en lecture et/ou criture pour un
groupe ou par utilisateur.
5.3 - La trame de SNMPv3
Le format de la trame SNMPv3 est trs diffrent du format de SNMPv1. Ils sont toutefois cods tous deux dans le
format ASN.1 [ISO 87]. Ceci assure la compatibilit des types de donnes entres les ordinateurs d'architectures
diffrentes.
Pour rendre plus facile la distinction entre les versions, le numro de la version SNMP est plac tout au dbut du
paquet. Toutefois, le contenu de chaque champ varie selon la situation. Selon que l'on envoie une requte, une
rponse, ou un message d'erreur, les informations places dans le paquet respectent des rgles bien dfinies dans
le standard. Voici comment les champs d'un paquet SNMPv3 sont remplis :
Version
Pour SNMPv3, on place la valeur 3 dans ce champ. On place 0 pour un paquet SNMPv1.
SNMP
Identificateur
de
message
Ce champ est laiss la discrtion du moteur SNMP. On retrouve souvent des algorithmes, o le premier message
de requte est envoy avec un nombre alatoire et les suivants avec les incrments de 1. Les paquets qui sont
mis en rponse une requte portent la mme identification que le paquet de la requte.
Taille
maximale
Le moteur choisit la taille maximale d'une rponse une requte selon ses capacits en mmoire tampon et ses
limites dcoder de longs paquets. Quand on envoie une rponse une requte, on doit veiller ne pas dpasser
la taille maximale.
Drapeaux
Trois
bits
sont
utiliss
Si
une
rponse
est
attendue
la
rception
Si
un
modle
de
cryptage
a
- Si un modle d'authentification a t utilis (Authentification Flag)
pour
de
ce
t
paquet.
utilis
indiquer
(Reportable
(Privacy
:
Flag)
Flag)
Le
modle
de
scurit
Ce module identifie le type de scurit qui est utilis pour encrypter le reste du paquet. Cet identificateur doit
identifier de faon unique chaque module de scurit. Actuellement, l'algorithme de cryptage DES (Data
Encryption Standard) et l'algorithme d'authentification HMAC-MD5-96 ont t choisis comme algorithmes utiliss
dans SNMPv3. HMAC-SHA-96 est optionnel.
Les
informations
de
scurit
Ces informations ne sont pas dcrites dans le standard SNMPv3, ce bloc est laiss au soin des modules de
scurit. D'un module de scurit un autre, ces informations seront diffrentes. Le module de scurit DES a
standardis le contenu de ce bloc.
Les
identificateurs
de
contextes
Avec SNMPv1, il tait possible d'avoir une seule base d'informations (MIB) par agent. Ceci n'est pas suffisant pour
certains quipements qui peuvent contenir plusieurs fois les mmes variables. Par exemple, un commutateur ATM
contient plusieurs cartes qui ont chacune leurs propres bases d'informations. Le contexte permet de distinguer
entre plusieurs bases d'informations et mme plusieurs agents. On distingue entre des agents, par exemple,
quand on a un moteur qui agit comme passerelle entre SNMPv3 et du SNMPv1. On envoie donc un paquet
SNMPv3 en identifiant quel agent SNMPv1 on dsire que le paquet soit retransmis.
7 - Conclusion
On soulignera le manque de scurit vident qui subsiste sur les premires versions de SNMP (v1 et v2). C'est dans ce
but qu'a donc t dveloppe la dernire version (v3) de SNMP. Depuis 2002 celle-ci a t dcrte comme standard
pour ce protocole. Pourtant la version 1 reste encore beaucoup utilise et peu d'entreprises voluent en passant en sur
la dernire version.
La VoIP
1
2
3
4
5
Bilan
Gnralits sur la transmission
Synoptique d'une architecture raccord avec un PABX traditionnel
Les diffrents codecs et taux de compression
Les diffrents protocoles
5.1 - H323
5.2 - SIP
5.3 - MGCP
6 - L'alimentation des postes IP
7 - La migration d'une installation
8 - Les 8 arguments plaidant pour
9 - Les 6 faiblesses qui rebutent les entreprises
10 - Les failles du protocole H.323
11 - Les diffrents lments pouvant composer un rseau
12 - La rglementation dans certains pays
13 - Le panorama des produits
13.1 - 3COM
13.2 - ALCATEL
13.3 - AVAYA
13.4 - WellX
13.5 - CISCO
13.6 - NORTEL
13.7 - QUESCOM
13.8 - MITEL
13.9 - SIEMENS
13.10 - EADS-TELECOM
13.11 - ERICSSON
13.12 - CENTILE
13.13 - TENOVIS
13.14 - TIPTEL
13.15 - FRANCE TELECOM
13.16 - ALSATEL
13.17 - IC TELECOM
13.18 - PACWAN
13.19 - Panasonic
13.20 - TechTelecom
13.21 - 3CX
13.22 - Keyyo
13.23 - Open Source
14 - Discussion autour de la documentation
15 - Suivi du document
1 - Bilan
Qui
n'a
pas
entendu
parler
de
tlphonie
sur
Ip
ou
de voix
sur
Ip ?
Bilan : beaucoup de monde l'heure actuelle. Nous avons tous de prs ou de loin entendu parler d'un projet de
dploiement ou mme de participer un projet de tlphonie sur IP. Laissons le terme "Voix sur IP" son utilisation,
c'est dire : technologie utilise pour transporter le service de tlphonie sur Ip (transport de la voix sur un Backbone
ou autre MAN/WAN). N'hsitez pas visiter cette page afin d'en savoir un peu plus sur IP. La tlphonie sur Ip est un
service de tlphonie fourni sur un rseau de tlcommunications ouvert au public ou priv utilisant principalement le
protocole de rseau IP. Cette technologie permet d'utiliser une infrastructure existante de rseau Ip pour raccorder des
terminaux Ip que l'on nomme IP-PHONE, ainsi que des logiciels sur PC raccords sur le mme rseau Ip que l'on
nomme
SOFTPHONE.
La
tlphonie
sur
Ip
peut
:
1) se rajouter en complment sur un rseau tlphonique traditionnel existant avec une passerelle (voir le synoptique
en
bas
de
page)
2) s'utiliser en full-Ip pour une nouvelle infrastructure (nouvel immeuble par exemple avec uniquement du cblage
catgorie
5
ou
6)
3) s'utiliser en multi sites full Ip avec l'aide d'un oprateur adquat et parfois des serveurs centraliss
4) s'utiliser sur un ordinateur reli au rseau Internet destination d'un autre ordinateur reli lui aussi au rseau
Internet, mais en utilisant absolument le mme logiciel (les communications seront donc gratuites de PC PC).
Cette technologie est propos par de multiples constructeurs avec parfois des solutions cls en mains ou des
intgrateurs spcialiss dans ce domaine. Je vous recommande fortement d'analyser vos besoins en ralisant une
petite tude avant de vous dcider ou de vous engager avec un seul constructeur ou intgrateur. Pour les visiteurs
presss et dsireux de comparer tout de suite une partie des offres de ToIP disponibles sur le march franais, voici
une
page
qui
offre
un
petit panorama
des
solutions
actuelles
de
tlphonie
sur
IP.
La tlphonie sur Ip est une transmission de la voix en mode paquets au format TCP/UDP. Pour comprendre le
traitement complexe de la voix analogique (signaux lectriques) en signaux binaires, voici un synoptique explicatif :
Explications du synoptique : La bande voix qui est un signal lectrique analogique utilisant une bande de frquence de
300 3400 Hz, elle est d'abord chantillonn numriquement par un convertisseur puis cod sur 8 bits, puis
compress par les fameux codecs ( il s'agit de processeurs DSP ) selon une certaine norme de compression variable
selon les codecs utiliss, puis ensuite on peut ventuellement supprimer les pauses de silences observs lors d'une
conversation, pour tre ensuite habill RTP,UDP et enfin en IP. Une fois que la voix est transforme en paquets IP, ces
petits paquets Ip identifis et numrots peuvent transits sur n'importe quel rseau Ip (ADSL, Ethernet,
Satellite,routeurs, switchs, PC, Wifi, etc...)
Ci-dessus, un synoptique d'une solution "ToIP" avec interconnexion avec un PBX existant (QSIG ou E&M) et une liaison
vers le rseau public partir de la passerelle (gateway) qui peut servir soit en permanence, soit dans certains cas
(routage international ou oprateur diffrent du PBX). Dans notre cas ci-dessus, les composants sont :
Un switch,
Deux postes Ip ( Cisco 7960 ),
Une application SoftPhone sur PC,
Un routeur servant de passerelle vers le PBX et vers le PSTN,
Un serveur de communications Ip (le serveur peut tre intgr dans un seul et mme lment).
Dbit en KBits/s
G.711 PCM
64
G.726 AD PCM
32
G.728 LD CELP
16
G.729 CS ACELP
G.729 x 2 Encodings
G.729 x 3 Encodings
G.729a CS ACELP
G.723.1 MPMLQ
6,3
G.723.1 ACELP
5,3
Si vous n'avez pas un switch qui assure la tlalimentation ou un power patch panel, il est obligatoire de disposer d'un
transformateur externe par tlphone Ip (IP-PHONE). Il est noter qu'en cas de panne secteur, il n'y a plus de
tlphone ( c'est normal ) et aucun appel d'urgences n'est donc possible.
tlcom
l'investissement
infrastructures
mobilit
de
sites
d'information
facilement
qualit
de
Fiabilit
mdiocre
l'utilisation
Localisation
Standards
son
Amliorer
Le
routeur,
il
assure
la
commutation
des
paquets
d'un
rseau
vers
un
autre
rseau.
- Le switch, il assure la distribution et commutation de dizaines de port Ethernet 10/100 voire 1000 Mbits/s. Suivant
les modles, il peut intgrer la tlalimentation des ports Ethernet la norme 802.3af pour l'alimentation des IPphones
ou
des
bornes
WIFI
en
48V.
- Le gatekeeper, il effectue les translations d'adresses (identifiant H323 et @ Ip du rfrencement du terminal) et gre
la bande passante et les droits d'accs. C'est le point de passage oblig pour tous les quipements de sa zone d'action.
-
Le
MCU,
est
un
lment
optionnel
et
gre
les
confrences
audio
vido.
- L'IP-PHONE, c'est un terminal tlphonique fonctionnant sur le rseau LAN Ip 10/100 avec une norme soit
propritaire, soit SIP, soit H.323. Il peut y avoir plusieurs codecs pour l'audio, et il peut disposer d'un cran
monochrome ou couleur, et d'une ou plusieurs touches soit programmables, soit prprogrammes. IL est en gnral
dot d'un hub passif un seul port pour pouvoir alimenter le PC de l'utilisateur (l'IP-PHONE se raccorde sur la seul
prise
Ethernet
mural
et
le
PC
se
raccorde
derrire
l'IP-PHONE).
- Le SOFTPHONE, c'est un logiciel qui assure toutes les fonctions tlphoniques et qui utilise la carte son et le micro du
PC de l'utilisateur, et aussi la carte Ethernet du PC. Il est gr soit par le Call Manager, soit par le PABX-IP.
Pays
Description de la rglementation
Angola
Antigua-et-Barbuda (1)
Bhoutan
Congo
Costa Rica
Dominicaine (Rp.)
Estonie (2)
Etats-Unis (3)
Gambie
Guatemala
Madagascar
Malte
Mexique
Mongolie (2)
Nouvelle-Zlande
Ouganda
Pologne
Sainte-Lucie (1)
Saint-Vincent (4)
Slovaquie
Tonga
Vietnam
Pays de l'Union
Europenne (5)
Hongrie (6)
Islande
Australie
Canada
Chine
Core (Rp.)
Malaisie
Autorise. Lorsque la transmission de fait en temps rel, assimile aux autres services de
tlcommunication vocale ( sous rserve d'octroi de licences et vise par les dispositions
dtailles de la rglementation applicable la tlphonie vocale classique )
Voici les pays qui autorisent les services tlphoniques/de tlcopie, soit sur Internet public, soit sur des rseaux Ip (
mais pas sur les deux la fois ).
Pays
Argentine
Interdite
Non interdite
Chypre
Interdite
Non interdite
Ethiopie
Interdite
Non interdite
Kenya
Non interdite
Moldova
Non interdite
Prou
Non interdite
Philippines Interdite
Non interdite
Sri Lanka
Interdite ( services
tlphoniques )
Non interdite
Ce prsent tableau est fond sur les rsultats de l'enqute de l'UIT sur la rglementation ( Edition 2000 ) et sur des
tudes de cas ralises par l'UIT. Les tats membres n'y ont apport ni modifications ni claircissements en vue du
troisime Forum Mondial des politiques de tlcommunications.
La rglementation de la tlphonie sur Ip dans certains pays ( ter ). Voici les pays qui interdisent l'utilisation de
l'Internet public et des rseaux Ip pour les services de tlphonie ou de tlcopie.
Pays
Informations donnes
Albanie
Azerbadjan
Belize
Botswana
Cambodge
Cameroun
Cte d'Ivoire
Croatie
Cuba
Equateur
Tlphonie interdite sur l'Internet public. Tlphonie temporairement interdite sur les
rseaux IP
Erytrhe
Tlphonie interdite pendant encore plusieurs annes ( la fois sur l'Internet public et
sur les rseaux Ip )
Gabon
Inde
Ce pays interdit l'utilisation de services tlphoniques sur l'Internet public, mais n'a
pas rpondu la question concernant les rseaux IP
Indonsie
Isral
Tlphonie interdite sur l'Internet public. Tlphonie et tlcopie interdites sur les
rseaux IP
Jordanie
Lettonie
Lituanie
Tlphonie interdite sur l'Internet public et sur les rseaux Ip jusqu'au 31 dcembre
2002
Maroc
Mozambique
Myanmar
Nicaragua
Nigria
Pakistan
Paraguay
Qatar
Tlphonie et tlcopie interdites sur l'Internet public et sur les rseaux IP, mais la
Sngal
Seychelles
Swaziland
Thalande
Togo
Trinit-et-Tobago
Tunisie
Turquie
Ce prsent tableau est fond sur les rsultats de l'enqute de l'UIT sur la rglementation ( Edition 2000 ) et sur des
tudes de cas ralises par l'UIT. Les tats membres n'y ont apport ni modifications ni claircissements en vue du
troisime Forum Mondial des politiques de tlcommunications.
Tlphonie
Internet
et
Applications, cliquez
: www.3com.fr
ici
Le produit 3Com NBX 100 Communications System est disponible dans 61 pays et dans 11
diffrents.
La
connectivit
PSTN
possible
est
Loop-start
analog,
T1/PRI,
E1/PRI
et
ISDN
Les capacits maximum sont : 400 heures de messagerie vocale, 720 PSTN et 1500 devices ( PSTN +
Le
systme
d'exploitation
est
Autre
produit
:
3
NBX
1200
postes
IP
maxi
du
type
Basic
ou
13.2 - ALCATEL
langages
BRI-ST.
postes ).
VxVorks.
Business
Site
Alcatel
Alcatel
Internet
OmniPcx
Office, cliquez
Office, cliquez
: www.alcatel.fr
ici.
ici.
La voix
sur
Ip
est
native sur
le
produit
OmniPcx.
Le systme d'exploitation est Linux, la messagerie unifie est disponible, le nombre de postes Ip maximum est de
4000 pour l'OmniPcx 4400 et de 200 sur l'Omnipcx Office. Le nombre maximum de boites vocales est de 15000.
L'Ip Sotfphone
est
disponible.
13.3 - AVAYA
Site
Avaya
et
et
Internet
401
Ip
Avaya
aussi
Compact
IP403
l'Ip
: www.avaya.fr
Office
Office
6000
Le systme d'exploitation est propritaire, la messagerie unifie est disponible, le nombre de boites vocales est
illimit, et le nombre de postes Ip maximum est de 90 pour l'Ip 403 Office et de 4 pour l'Ip 403 Compact Office.
Deux autres modles :Definity One sous windows NT H323, 240 postes IP maxi du type 4600 ou softphone IP +
Definity sous OS proprietaire, H323, 5000 postes IP maxi du type 4600 ou softphone IP
13.4 - WellX
Site
Pour
Internet
plus
d'informations, cliquez
: www.wellx.com
ici.
WellX Office est une solution PCBX (PC industriel quip de cartes de Tlcommunications). Le systme
d'exploitation
est
Windows
2000.
WellX Office est conforme au protocole SIP (stack OsIP et proxy Partysip) et gre indiffremment des terminaux
analogiques et des terminaux SIP (IP-Phone -par ex. SIEMENS en photo droite-, MSN Messenger, SIP Phone,
postes
USB,....)
mais
aussi
des
"Access
Device"
type
Mediatrix
(www.mediatrix.com).
Jusqu'
200
postes
Ip
et
256
postes
analogiques.
Applications disponibles : Administration Web, Serveur vocal, Enregistreur de communications, Gestion des appels
CTI ( monte de fiches, client Web ), messagerie vocale et unifie, commandes vocales, ACD, interfaces TAPI (
possibilit de dvelopper une application 'tlphonie' avec VBA, VB, ASP, HTML, ou C++ ).
Client
CTI
13.5 - CISCO
Site
Internet
Caractristiques
Dmonstration
Possibilit
Cisco
Unity
des
postes
d'un
de
: messagerie
: www.cisco.com
IP
Phone
poste
unifie
de
Cisco, cliquez
7960, cliquez
dveloppement
et
messagerie
ici.
ici.
XML.
vocale.
Le serveur de convergence mdia Cisco 7835-1266 peut grer 2500 postes IP, tandis que le serveur de
convergence mdia Cisco 7835-1133 peut grer 1000 postes Ip ( par serveur ) avec possibilit de les monter en
grappe . Ils intgrent le serveur Call Manager. Le logiciel de traitement d'appels Cisco CallManager Manager
3.2 peut
grer
un
maximum
de
10
000
postes
Ip
par
grappe..
La
version
4.0
du
Call
Manager
est
sortie..
Ils
sont
tous
compatibles
H323,
MGCP,
SIP,
SCCP.
Quelques
modles
:
MCS7845 sous windows 2000, 30 000 postes IP maxi du type switch, XML, couleur, sans fil
MCS7835 sous windows 2000, 10 000 postes IP maxi du type switch, XML, couleur, sans fil
MCS7825 sous windows 2000, 4000 postes IP maxi du type switch, XML, couleur, sans fil
MCS7815 sous windows 2000, 400 postes IP maxi du type switch, XML, couleur, sans fil
Call manager express , OS temps rel, 120 postes IP maxi du type switch, XML, sans fil
Caractristiques
Dmonstration
Possibilit
des
postes
d'un
IP
Phone
poste
de
de
Cisco, cliquez
7960, cliquez
dveloppement
ici.
ici.
XML
13.6 - NORTEL
Site
Le
Internet
systme
: www.nortelnetworks.com
d'exploitation
est
VxVorks.
Le nombre de postes IP maximum est de 1000 pour le Call Server de base ( Succession Communication Server for
Enterprise
(CSE)
1000 )
et
de
10
000
avec
des
serveurs
en
grappe.
Quelques
modles
:
Business Communication Manager 3.5 sous windows NT, EUROISDN, H323, QSIG, SIP, maxi inconnu, du type
i2004,
i2002
et
i2050
Succession 1000 sous Vx-Works, EUROISDN, H323, QSIG, 1000 postes IP maxi du type i2004, i2002 et i2050
Succession 1000M sous Vx-Works, EUROISDN, H323, QSIG, 10 000 postes IP maxi du type i2004, i2002 et i2050
Caractristiques des postes IP Phone, cliquez ici.
13.7 - QUESCOM
Site
Internet
: http://www.quescom.com/
Le produit QUESCOM 400 intgre les lments suivants : Serveur de voix sur IP, Serveur de messagerie et de
tlphonie, Serveur d'appels RNIS et IP. Ce produit permet d'interconnecter un PABX existant avec une solution
de
VOIX
SUR
Ip
et
dispose
d'une
option
GSM.
Il est compatible avec les tlphones Ip de Cisco et accepte jusqu' 32 communications Ip simultanes.
13.8 - MITEL
Site
Internet
: http://www.mitel.fr/
Le produit 3300 ICP intgre la messagerie vocale ( jusqu' 750 boites ), un standard automatique et la
distribution automatique des appels ( ACD ). La connectivit PSTN est possible ainsi que PRI ( QSIG et Euro Isdn
), et BRI. L'IP Sotfphone est disponible ainsi que des tlphones WI-FI. MITEL propose plus de 6 tlphones Ip et
le nombre d'utilisateurs maximum peut dpasser les 700 avec un montage en cluster des contrleurs.
Deux
MN
3340,
sous
Vx-Works,
MN
3300,
sous
Vx-Works,
100,
40
250
gammes
postes
IP
maxi,
et
700
postes
IP
du
maxi,
type
5201,
du
type
5201,
:
5205
5205
13.9 - SIEMENS
Site
Internet
: http://www.siemens.fr/
CE, IP, 96 postes IP
CE, IP, 96 postes IP
CE, IP, 192 postes IP
CE, IP, 192 postes IP
CE, IP, 500 postes IP
postes IP maxi, du type nc
maxi,
maxi,
maxi,
maxi,
maxi,
du
du
du
du
du
type
type
type
type
type
nc
nc
nc
nc
nc
13.10 - EADS-TELECOM
Plusieurs
modles
:
NexspanCommunicationServer sous windows 2000 et IRMX, 950 postes ip maxi, du type i740, i760, i780, i2052,
H323
M6501 IP PBX sous IRMX, 250 postes IP maxi, du type i740, i760, i780, i2052
M6540 IP PBX sous IRMX, 250 postes IP maxi, du type i740, i760, i780, i2052
M6550 IP PBX sous IRMX, 9500 postes IP maxi, du type i740, i760, i780, i2052
Nexspan
C
sous
IRMX,
0
postes
IP
Nexspan S sous IRMX, 250 postes IP maxi, du type i740, i760, i780, i2052
Nexspan L sous IRMX, 250 postes IP maxi, du type i740, i760, i780, i2052 softphone
softphone
softphone
softphone
maxi
softphone
13.11 - ERICSSON
Site
Internet
: http://www.ericsson.fr/
Webswitch 2000 3.1 OS proprietaire, 128 1500 postes IP maxi, du type Dialog 3413, IP , softphone
13.12 - CENTILE
Site
internet
Centile
dvelopp
: http://www.centile.com/
le
deux
PABX
ainsi
que
le
types
hberg
PABX
de
local
(hosted
(LAN
produits:
iPBX),
PBX).
Le PABX hberg est destin a des Oprateurs tlcoms, ISP afin qu'ils oprent le service.
Cette solution logicielle s'installe sur Solaris et LINUX et contient toutes les fonctionnalits attendues d'un PABX:
-
Serveur
Serveur
Stacks
Gestion
d'IVRs
CTI
pour
protocolaires
des
Call
(boite
les
(SIP,
codecs
vocale,
confrence,
interfaces
utilisateurs
MGCP,
SCCP,
(G729,
G723,
Media
Control
ACD...)
(Flash)
H323)
G711)
serveur
engine
Sur un serveur, plusieurs PABX peuvent tre cres avec un nombre d'utilisateurs differents afin d'attaquer le
march
de
la
PME
a
la
grande
entreprise.
Les API pour les couches applicatives et services sont la disposition des clients afin de dvelopper des services
personnaliss.
Le LAN PABX est destin des entreprises multi-sites, pour des centres d'affaires ou tout simplement pour une
entreprise
qui
veut
avoir
l'quipement
en
local.
13.13 - TENOVIS
Site
Internet
: http://www.tenovis.com/
type
compatible
H323
13.14 - TIPTEL
Site
Internet
: http://www.tiptel.fr/
IP400
sous
windows
,
H323,
200
postes
ip
max,
du
IP3000-30 sous windows , H323, 1000 postes ip max, du type compatible H323
type
compatible
H323
Internet
IRMX
,
IRMX
,
LINUX
,
LINUX
,
postes IP maxi,
: http://www.francetelecom.com/fr/
250
250
200
200
du type
postes
IP
postes
IP
postes
IP
postes
IP
propritaire
maxi,
maxi,
maxi,
maxi,
du
du
du
du
type
type
type
type
propritaire
propritaire
propritaire
propritaire
13.16 - ALSATEL
Site
Internet
: http://www.alsatel.fr/
Irma VPM IPBX Orient Centres de scurit ou d'alertes sous windows NT/XP, SIP, H323, postes IP phones,
TIPPHONE
13.17 - IC Telecom
IC TELECOM permet d'amliorer votre productivit tout en rduisant vos cots. Avec IC CENTREX, IC TELECOM
propose une solution complte et modulaire de tlcommunication d'entreprise : voix, data, mobile. Plus besoin
d'acheter ou de louer un PABX, plus d'abonnement l'oprateur historique. C'est l'avantage d'avoir un guichet
unique donc un seul et mme interlocuteur. Un accompagnement vous est ddi tout au long de notre
collaboration.
Aussi, IC TELECOM vous offre de nombreux autres produits et services avec IC CONVERGENCE qui combine la
tlphonie fixe et mobile, IC OFFICE permet de bnficier d'une solution de messagerie avance, conviviale et
scurise via une interface web 2.0 depuis n'importe quelle borne wifi. IC BACKUP vous donne la possibilit de
sauvegard en ligne vos donnes sans limite de stockage tout en bnficiant d'une architecture scurise. Enfin,
IC 800 qui grce son SVI vous apporte la possibilit de ne plus perdre d'appels, de rduire le temps d'attente de
vos clients et fournisseurs en orientant intelligemment vos appels.
Avantages IC CENTREX :
Pas
de
location
ni
d'achat
Suppression
des
Un
seul
interlocuteur
Forfait
illimit
pour
Une
maintenance
technique
24h
Communications
inter
sites
gratuites
Une
facture
unique
pour
l'internet,
la
tlphonie
- Service de maintenance et de formation
de
vos
/24h
et
fixe
PABX
abonnements
tlphonique
appels
7j/7j
illimites
et
mobile
13.18 - PACWAN
Site
internet
PACWAN
propose
: http://www.pacwan.fr/
deux
solutions
VoxDSL : les solutions professionnelles de voix sur IP pour les entreprises. De 1 999 postes, disposez
immdiatement de nos solutions prt brancher VoxDSL et des tlcommunications gratuites et illimites (vers
les
tlphones
fixes
de
la
France
mtropolitaine,
hors
numros
spciaux
ou
surtaxs).
Votre central tlphonique d'entreprise complet partir de 22 euros par mois... communications incluses !
La technologie de voix sur IP pour les petites entreprises. La convergence de la voix et des donnes pour de trs
grosses
conomies
la
cl
!
VoaDSL : La voix sur IP n'est plus synonyme de multinationales. Vous aussi accdez ds maintenant au futur des
tlcommunications,
et
ne
payez
plus
un
centimes
sur
vos
appels
tlphoniques
!
La voix sur ADSL c'est le tlphone et l'Internet dans un seul abonnement. C'est d'importantes conomies et une
nouvelle
faon
de
penser
le
travail
et
l'organisation
de
votre
entreprise.
Vous tltravaillez, vous grez une agence locale, vous dpensez des fortunes en tlphone ? La solution VoADSL
adapte
vos
besoin
existe
dj
chez
PacWan!
Un quipement simple a installer (Plug & call), un support technique prt vous aider et des tarifs d'abonnement
quivalents
ceux
de
l'ADSL
classique.
13.19 - Panasonic
Site
KX-TD208FR
internet
OS
nc,
max
:
nc,
type
nc
KX-TD612SP
OS
nc,
KXt-TDA100
OS
propritaire,
KXt-TDA200 OS propritaire, max nc, type nc
max
max
nc,
nc,
type
type
nc
nc
13.20 - TechTelecom
Site
Internet
: www.techtelecom.fr
Annuaires
Messagerie
Serveur
Lien
centraliss,
unifie,
vocal,
TAPI...
13.22 - Keyyo
Site internet : www.keyyo.fr
Le standard tlphonique volutif Keyyo grce son mode hberg IPCentrex vous affranchit de toute installation
de
PABX
et
de
cblage.
Vous
mutualisez
votre
rseau
informatique
et
telecom.
Vos
tlphones
IP
se
branchent
directement
sur
votre
rseau
informatique.
Avec Keyyo c'est simple : Branchez/ tlphonez/ Grez d'un simple clic !
Keyyo
c'est
plus
de
flexibilit
pour
une
meilleure
matrise
des
Vous grez en toute autonomie vos lignes et forfaits poste par poste depuis votre compte web Keyyo
13.23 - Open Source
La ToIP Open Source
1 - Introduction
2 - Le Rseau Tlphonique Commut
2.1 - Histoire de la tlphonie
2.2 - Principe du Rtc
2.3 - Architecture du rseau
3 - Les enjeux de la tlphonie sur Ip
4 - Les avantages
4.1 - Rduction des cots
4.2 - Standards ouverts et interoprabilit multi-fournisseurs
4.3 - Choix d'un service opr
4.4 - Un rseau voix, vido et donnes (triple play)
4.5 - Un service PABX distribu ou centralis
4.6 - Evolution vers un rseau de tlphonie sur Ip
4.7 - Intgration des services vido
5 - L'Architecture Voip
5.1 - Les schmas
5.2 - Gateway et Gatekeeper
6 - Standards VoIP
6.1 - Protocole H323
cots
6.1.1 - Introduction
6.1.2 - Fonctionnement
6.1.3 - H323 dans le modle Osi
6.1.4 - La visioconfrence sur Ip
6.1.5 - Avantages et inconvnients
6.1.6 - Comparaison avec Sip
6.1.7 - Conclusion
6.2 - Protocole Sip
6.2.1 - Introduction
6.2.2 - Fonctionnement
6.2.3 - Scurit et Authentification
6.2.4 - Comparaison avec H323
6.2.5 - Conclusion
6.3 - Transport Rtp et Rtcp
6.3.1 - Introduction
6.3.2 - Les fonctions de Rtp
6.3.3 - Entte Rtp
6.3.4 - Les fonctions de Rtcp
6.3.5 - Entte Rtcp
6.3.6 - Conclusion
6.4 - H261
6.5 - Audio
7 - Problme et QoS
7.1 - Latence
7.2 - Perte de paquets
7.3 - Gigue
8 - Etat du march
9 - Conclusion
10 - Discussion autour de la documentation
11 - Suivi du document
1 - Introduction
La voix sur IP (Voice over IP) est une technologie de communication vocale en pleine mergence. Elle fait partie d'un
tournant dans le monde de la communication. En effet, la convergence du triple play (voix, donnes et vido) fait
partie des enjeux principaux des acteurs de la tlcommunication aujourd'hui. Plus rcemment l'Internet s'est tendu
partiellement dans l'Intranet de chaque organisation, voyant le trafic total bas sur un transport rseau de paquets
IP surpasser le trafic traditionnel du rseau voix (rseau commutation de circuits). Il devenait clair que dans le sillage
de cette avance technologique, les oprateurs, entreprises ou organisations et fournisseurs devaient, pour bnficier
de l'avantage du transport unique IP, introduire de nouveaux services voix et vido. Ce ft en 1996 la naissance de la
premire version voix sur IP appele H323. Issu de l'organisation de standardisation europenne ITU-T sur la base de
la signalisation voix RNIS (Q931), ce standard a maintenant donn suite de nombreuses volutions, quelques
nouveaux
standards
prenant
d'autres
orientations
technologiques.
Pour tre plus prcis et nanmoins schmatique, le signal numrique obtenu par numrisation de la voix est dcoup
en paquets qui sont transmis sur un rseau IP vers une application qui se chargera de la transformation inverse (des
paquets vers la voix). Au lieu de disposer la fois d'un rseau informatique et d'un rseau tlphonique commut
(RTC), l'entreprise peux donc, grce la VoIP, tout fusionner sur un mme rseau. Ca par du fait que la tlphonie
devient de la "data". Les nouvelles capacits des rseaux haut dbit devraient permettre de transfrer de manire
fiable des donnes en temps rel. Ainsi, les applications de vido ou audioconfrence ou de tlphonie vont envahir le
monde IP qui, jusqu'alors, ne pouvait raisonnablement pas supporter ce genre d'applications (temps de rponse
important, jigue-jitter, Cos-Qos,...). Jusque vers le milieu des annes 90, les organismes de normalisation ont tent de
transmettre les donnes de manire toujours plus efficace sur des rseaux conus pour la tlphonie. A partir de cette
date, il y a eu changement. C'est sur les rseaux de donnes, que l'on s'est vertu convoyer la parole. Il a donc
fallu dvelopper des algorithmes de codage audio plus tolrants et introduire des mcanismes de contrle de la qualit
de service dans les rseaux de donnes. Faire basculer diffrents types de donnes sur un mme rseau permet en
plus,
de
simplifier
son
administration.
Comme toute innovation technologique qui se respecte, la VoIP doit non seulement simplifier le travail mais aussi faire
conomiser de l'argent. Les entreprises dpensent normment en communications tlphoniques, or le prix des
communications de la Toip (Tlphonie sur Ip) est drisoire en comparaison. En particulier, plus les interlocuteurs sont
loigns, plus la diffrence de prix est intressante. De plus, la tlphonie sur IP utilise jusqu' dix fois moins de bande
passante que la tlphonie traditionnelle. Ceci apportant de grand intrt pour la voix sur rseau prive. Il semblerait
que les entreprises aprs avoir mis un certain nombre de doutes sur la qualit de services soient dsormais
convaincues de la plus grande maturit technologique des solutions proposes sur le march. Qu'il s'agisse
d'entreprises mono-site ou multisites, les sondages montrent que le phnomne de migration vers les systmes de
tlphonie
sur
IP
en
entreprise
est
actuellement
engag.
Les premires technologies de VoIP imagines taient propritaires et donc trs diffrentes les unes des autres.
Pourtant, un systme qui est cens mettre des gens et des systmes en relation exige une certaine dose de
standardisation. C'est pourquoi sont apparus des protocoles standards, comme le H323 ou le SIP.
Mais qu'est-ce que le RTC? Le RTC est tout simplement le rseau tlphonique que nous utilisons dans notre vie de
tous les jours et qui nous donne accs de multiple fonction. En effet outre le fait de pouvoir tlphoner, le RTC nous
permet d'utiliser de multiples services tel que la transmission et rception de fax, l'utilisation d'un minitel, accder
Internet etc... Il reprsente donc l'un des protocole de discussion utilis sur la paire de cuivre boucle locale.
2.1 - Histoire de la tlphonie
Du premier tlgraphe de Chappe en 1790 au RTC actuelle, l'histoire des communications connu de grands
moments et de grandes avancs d l'ingniosit de certains et aux progrs technologique et lectronique. Nous
retiendrons quelques grandes dates tel que :
1837 Premier tlgraphe lectrique invent par Samuel Morse
1889 Almon B. Strowger (USA) invente le premier slecteur automatique et donne ainsi naissance la
commutation tlphonique automatique
1938 Alec Reeves (Franais) dpose le brevet des futurs systmes modulation par impulsion et codage
(MIC) : quantification et chantillonnage du signal intervalles rguliers, puis codage sous forme binaire.
1962 Les premiers systmes de transmission multiplex de type MIC apparaissent aux Etats-Unis ils
permettent une liaison 24 voies entre centraux tlphonique, la mme poque en France on installe des
MIC 32 voies.
1970 Un nouveau pas est franchi dans le domaine de la commutation lectronique avec la mise en service
en France, par le CNET, des premiers centraux tlphoniques publics en commutation lectronique
temporelle.
1979 Lancement du minitel en France
1987 Le RNIS est mis en service en France.
1990 De nouveaux concepts apparaissent tel que la commutation temporelle asynchrone (ATM) et la
hirarchie numrique synchrone.
2.2 - Principe du Rtc
Le rseau tlphonique public (RTPC, Rseau Tlphonique Public Commut ou simplement RTC) a
essentiellement pour objet le transfert de la voix. Le transport des donnes n'y est autoris, en France, que
depuis 1964. Utilisant le principe de la commutation de circuits, il met en relation deux abonns travers une
liaison
ddie
pendant
tout
l'change.
Le rseau de transit, effectue pour sa part le transport des communications entre les noeuds de transit
concentrateurs / commutateurs). Cette portion du rseau est actuellement numrique.
La numrisation offre plusieurs avantages. Puisqu'il ne s'agit que de 0 et de 1, la qualit du signal est prserve,
quelle que soit la distance entre les convertisseurs (analogique numrique et numrique analogique). Ce n'est pas
le
cas
des
communications
analogiques
o
le
signal
est
pollu
chaque
manipulation.
La gestion gnrale du rseau discerne trois fonctions :
La distribution, celle-ci comprend essentiellement la liaison d'abonn ou boucle locale (paire mtallique
torsade) qui relie l'installation de l'abonn au centre de transmission de rattachement. Cette ligne assure
la transmission de la voix (frquence vocale de 300 3 400 Hz), de la numrotation (10 Hz pouf la
numrotation dcimale -au cadran- et 697 1633 Hz pour la numrotation frquentielle) et de la
signalisation gnrale (boucle de courant, frquences supra vocales)
La commutation, c'est la fonction essentielle du rseau, elle consiste mettre en relation deux abonns,
maintenir la liaison pendant tout l'change et librer les ressources la fin de celui-ci. C'est le rseau qui
dtermine les paramtres de taxation et impute le cot de la communication l'appelant
La transmission, c'est la partie support de tlcommunication du rseau, cette fonction est remplie soit par
un systme filaire cuivre (en voie de disparition), de la fibre optique ou des faisceaux hertziens.
Aujourd'hui, le rseau est pratiquement intgralement numris, seule la liaison d'abonn reste
analogique.
2.3 - Architecture du rseau
Le rseau tlphonique commut a une organisation hirarchique trois niveaux. Il est structur en zones
correspondant
un
niveau
de
concentration.
On distingue :
Zone Autonomie d'Acheminement (ZAA), cette zone, la plus basse de la hirarchie, comporte un ou
plusieurs Commutateurs Autonomie d'Acheminement (CAA) qui eux-mmes desservent des
Commutateurs Locaux (CL). Les commutateurs locaux ne sont que de simples concentrateurs de lignes
auxquels sont raccords les abonns finals. La ZAA (Zone Autonomie d'Acheminement) est un rseau
toil, elle constitue le rseau de desserte;
Zone de Transit Secondaire (ZTS), cette zone comporte des Commutateurs de Transit Secondaires (CTS). Il
n'y a pas d'abonns relis aux CTS (Commutateurs de Transit Secondaires). Ils assurent le brassage des
circuits lorsqu'un CAA (Commutateur Autonomie d'Acheminement) ne peut atteindre le CAA destinataire
directement (rseau imparfaitement maill);
Zone de Transit Principal (ZTP), cette zone assure la commutation des liaisons longues distances. Chaque
ZTP (Zone de Transit Principal) comprend un Commutateur de Transit Principal (CTP), L'un des
commutateurs de transit principal (CTP) est reli au commutateur international de transit.
Pourcentage
Rduction de cots
75 %
66 %
65 %
64 %
46 %
Autres facteurs
50 %
La tlphonie sur IP exploite un rseau de donnes IP pour offrir des communications vocales l'ensemble de
l'entreprise sur un rseau unique voix et donnes. Cette convergence des services de communication donnes, voix, et
vido sur un rseau unique, s'accompagne des avantages lis la rduction des cots d'investissement, la
simplification des procdures d'assistance et de configuration, et l'intgration accrue de filiales et de sites distants
aux
installations
du
rseau
d'entreprise.
Les cots gnraux de l'infrastructure de rseau sont rduits. Le dploiement d'un unique rseau converg voix et
donnes sur tous les sites permet de raliser des conomies sur les investissements productifs, l'ordre d'ide en 20042005 atteint les 50% si l'on prend on compte les communications inter-site. De plus, comme le tlphone et le PC
partagent le mme cble Ethernet, les frais de cblage sont rduits. Les frais d'administration du rseau sont
galement minimiss. Il est ainsi possible de raliser des conomies court et long terme sur de nombreux postes :
administration d'un seul rseau, fournisseur d'accs unique, unique contrat de maintenance, cblage commun, gratuit
des communications interurbaines, rduction de la complexit de l'intgration d'applications. Enfin, la migration de la
solution actuelle vers la Tlphonie sur IP s'effectue en douceur. Les solutions de tlphonie sur Ip sont conues pour
dgager
une
stratgie
de
migration
faible
risque
partir
de
l'infrastructure
existante.
Le scnario vers lequel va s'orienter la tlphonie sur Ip dpend beaucoup de l'volution du rseau lui-mme. En effet,
si Internet reste peu prs dans sa configuration actuelle o il est essentiellement dimensionn en fonction d'une
qualit de service moyenne pour la transmission des donnes, il est fort probable que la tlphonie sur Ip restera un
march rserv au rseau de type Frame, Mpls. Les seules exceptions seraient alors les cas d'interconnexion de PBX
d'entreprises, commerce lectronique, applications nouvelles associant la voix pour une vritable utilisation multimdia
d'Internet. En effet, ce qui ralenti considrablement l'explosion de ce secteur est le fait qu'il y ait encore trop peu de
dploiements oprationnels en France et mme dans le monde. De nombreuses entreprises connaissent la tlphonie
sur IP, mais toutes en sont au mme stade : le test. De plus, il faut savoir que la plupart des dploiements
oprationnels de tlphonie sur IP ont t raliss pour des universits, or, les universits n'ayant pas les mmes
exigences
qu'une
entreprise,
ces
dploiements
ne
sont
pas
rellement
pris
en
compte.
Les applications et les services Ip intgrs amliorent la productivit et le soin de la clientle. Les bnfices rcurrents
seront apports par les gains de productivit lis l'utilisation de nouveaux services et de nouveaux applicatifs tels que
la messagerie unifie qui permettent de librer, selon les spcificits des mtiers, entre 25 et 40 minutes de temps de
travail par collaborateur, les assistants personnels qui permettent au collaborateur de personnaliser sur l'Intranet
toutes les fonctions avances de renvoi d'appel en fonction de son agenda propre ou partag et les applications
d'eLearning , qu'il convient de faire apparatre dans une dmarche de dmonstration de retour sur l'investissement
court et moyen terme. De plus, les fonctions simplifies de cration, de dplacement et de modification rduisent le
temps ncessaire pour ajouter de nouveaux utilisateurs au rseau. Le dploiement de nouveaux services est acclr.
L'utilisation d'une infrastructure IP commune et d'interfaces standard ouvertes permet de dvelopper et de dployer
trs rapidement des applications innovantes. Enfin, les utilisateurs accdent tous les services du rseau partout o ils
peuvent s'y connecter notamment travers l'extention mobility (substitution de postes).
4 - Les avantages
La VoIP offre de nombreuses nouvelles possibilits aux oprateurs et utilisateurs qui bnficient d'un rseau bas sur
Ip. Les avantages les plus marqus sont les suivants.
4.1 - Rduction des cots
En dplaant le trafic voix Rtc vers le rseau priv WAN/IP les entreprises peuvent rduire sensiblement certains
cots de communications. Rductions importantes mises en vidence pour des communications internationales,
ces rductions deviennent encore plus intressantes dans la mutualisation voix/donnes du rseau IP inter-sites
(WAN). Dans ce dernier cas, le gain est directement proportionnel au nombre de sites distants.
5 - L'Architecture Voip
5.1 - Les schmas
Voici
le
schma
gnrale
de
l'utilisation
de
la
Voip
en
entreprise
La VoIP tant une nouvelle technologie de communication, elle n'a pas encore de standard unique. En
effet,chaque constructeur apporte ses normes et ses fonctionnalits ses solutions. Il existe tout de mme des
rfrences en la matire. Je vais dcrire les trois principales que sont H.323, SIP et MGCP/MEGACO. Tous les
acteurs de ce march utilisent comme base pour leur produit une ou plusieurs de ces trois architectures. Il existe
donc plusieurs approches pour offrir des services de tlphonie et de visiophonie sur des rseaux IP. Certaines
placent l'intelligence dans le rseau alors que d'autres prfrent une approche peer to peer avec l'intelligence
rpartie la priphrie (terminal de tlphonie IP, passerelle avec le rseau tlphonique commut...). Chacune a
ses
avantages
et
ses
inconvnients.
Le schma ci-dessus, dcrit de faon gnrale la topologie d'un rseau de tlphonie IP. Elle comprend toujours
des terminaux, un serveur de communication et une passerelle vers les autres rseaux. Chaque norme a ensuite
ses propres caractristiques pour garantir une plus ou moins grande qualit de service. L'intelligence du rseau
est aussi dporte soit sur les terminaux, soit sur les passerelles/Gatekeeper (contrleur de commutation). On
retrouve les lments communs suivants :
Le routeur : Il permet d'aiguiller les donnes et le routage des paquets entre deux rseaux. Certains
routeurs, comme les Cisco 2600, permettent de simuler un gatekeeper grce l'ajout de cartes
spcialises supportant les protocoles VoIP.
La passerelle : il s'agit d'une interface entre le rseau commut et le rseau IP.
Le PABX : C'est le commutateur du rseau tlphonique classique. Il permet de faire le lien entre la
passerelle ou le routeur et le rseau RTC. Une mise jour du PABX est aussi ncessaire. Si tout le rseau
devient IP, il n'y a plus besoin de ce matriel.
Les Terminaux : Des PC ou des tlphones VoIP.
Pour transmettre les paquets, on utilise RTP, standardis en 1996. Il est un protocole adapt aux applications
prsentant des proprits temps rel. Il permet ainsi de reconstituer la base de temps des flux (horodatage des
paquets : possibilit de re-synchronisation des flux par le rcepteur), de dtecter les pertes de paquets et en
informer la source, et d'identifier le contenu des donnes pour leurs associer un transport scuris. En revanche,
ce n'est pas "la solution" qui permettrait d'obtenir des transmissions temps rel sur IP. En effet, il ne procure pas
de rservation de ressources sur le rseau (pas d'action sur le rseau de type RSVP, diffserv, Policeur), de
fiabilisation des changes (pas de retransmission automatique, pas de rgulation automatique du dbit) et de
garantie dans le dlai de livraison (seules les couches de niveau infrieur le peuvent) et dans la continuit du flux
temps rel. Bien qu'autonome, RTP peut tre complt par RTCP. Ce dernier apporte un retour d'informations sur
la transmission et sur les lments destinataires. Ce protocole de contrle permet de renvoyer la source des
informations sur les rcepteurs et ainsi lui permettre, par exemple, d'adapter un type de codage ou encore de
modifier le dbit des donnes.
5.2 - Gateway et Gatekeeper
Pour commencer je vais parler d'un des lments clefs d'un rseau VoIP, la passerelle et leurs Gatekeepers
associs. Les passerelles ou gateways en tlphonie IP sont des ordinateurs qui fournissent une interface o se
fait la convergence entre les rseaux tlphoniques commuts (RTC) et les rseaux bass sur la commutation de
paquets TCP/IP. C'est une partie essentielle de l'architecture du rseau de tlphonie IP. Le gatekeeper est
l'lment qui fournit de l'intelligence la passerelle. Comme nous l'avons dj fait remarqu, nous pouvons
sparer les parties matrielles et logicielles d'une passerelle. Le gatekeeper est le compagnon logiciel de la
gateway.
Une gateway permet aux terminaux d'oprer en environnements htrognes. Ces environnements peuvent tre
trs diffrents, utilisant diverses technologies tels que le Numris, la tlphonie commute ou la tlphonie IP. Les
gateways doivent aussi tre compatible avec les terminaux tlphoniques analogiques. La gateway fournit la
possibilit d'tablir une connexion entre un terminal analogique et un terminal multimdia (un PC en gnral).
Beaucoup de socits fournissent des passerelles mais cela ne signifie pas qu'elles fournissent le mme service.
Les gateways (partie physique) et les gatekeepers (partie logicielle) font l'objet de deux sections spares pour
bien cerner la diffrence. Certaines socits vendent un produit " gateway ", mais en ralit, elles incorporent une
autre gateway du march avec leur gatekeeper pour proposer une solution commerciale. La plus-value ne se fait
pas sur la gateway mais sur le gatekeeper car c'est sur celui-ci qu'on peut faire la diffrence.
Un gatekeeper deux services principaux : la gestion des permission et la rsolution d'adresses. La gatekeeper est
aussi responsable de la scurit. Quand un client veut mettre un appel, il doit le faire au travers du gatekeeper.
C'est alors que celui-ci fournit une rsolution d'adresse du client de destination. Dans le cas o il y a plusieurs
gateways sur le rseau, il peut rediriger l'appel vers un autre couple gateway/gatekeeper qui essaiera son tour
de router l'appel. Pendant la rsolution d'adresse, le gatekeeper peut aussi attribuer une certaine quantit de
bande passante pour l'appel. Il peut agir comme un administrateur de la bande passant disponible sur le rseau.
Le gatekeeper rpond aux aspects suivant de la tlphonie IP :
Le routage des appels : en effet, le gatekeeper est responsable de la fonction de routage. Non seulement, il
doit tester si l'appel est permis et faire la rsolution d'adresse mais il doit aussi rediriger l'appel vers le bon
client ou la bonne passerelle.
Administration de la bande passante : le gatekeeper alloue une certaine quantit de bande passant pour un
appel et slectionne les codecs utiliser. Il agit en tant que rgulateur de la bande passante pour prmunir
le rseau contre les goulots d'tranglement (bottle-neck).
Tolrance aux fautes, scurit : le gatekeeper est aussi responsable de la scurit dans un rseau de
tlphonie IP. Il doit grer les redondances des passerelles afin de faire aboutir tout appel. Il connat tout
moment l'tat de chaque passerelle et route les appels vers les passerelles accessibles et qui ont des ports
libres.
Gestion des diffrentes gateways : dans un rseau de tlphonie IP, il peut y avoir beaucoup de gateways.
Le gatekeeper, de par ses fonctionnalits de routage et de scurit, doit grer ces gateways pour faire en
sorte que tout appel atteigne sa destination avec la meilleure qualit de service possible.
Ainsi, le gatekeeper peut remplacer le classique PABX. En effet, il est capable de router les appels entrant et de
les rediriger vers leur destination ou une autre passerelle. Mais il peut grer bien d'autres fonctions telles que la
confrence ou le double appel. Il n'existe pas les mmes contraintes avec un gatekeeper qu'avec un PABX. En
effet, ce dernier est constitu par du logiciel et l'oprateur peut implmenter autant de services qu'il le dsire.
Alors qu'avec un PABX, l'volutivit est limite par le matriel propritaire de chaque constructeur, avec le
gatekeeper, l'amlioration des services d'un rseau de tlphonie IP n'a pas de limites. Le grand bnfice du
dveloppement d'un gros gatekeeper est de remplacer le PABX classique. En effet, chaque PABX utilise son propre
protocole pour communiquer avec les postes clients, ce qui entrane un surcot. Avec le couple
gateway/gatekeeper, ce problme n'existe pas. Il utilise des infrastructures qui existent, le LAN et des protocoles
tel qu'IP.
6 - Standards VoIP
6.1 - Protocole H323
6.1.1 - Introduction
Avec le dveloppement du multimdia sur les rseaux, il est devenu ncessaire de crer des protocoles qui
supportent ces nouvelles fonctionnalits, telles que la visioconfrence : l'envoi de son et de vido avec un
soucis de donnes temps rel. Le protocole H.323 est l'un d'eux. Il permet de faire de la visioconfrence sur
des
rseaux
IP.
H.323 est un protocole de communication englobant un ensemble de normes utiliss pour l'envoi de donnes
audio et vido sur Internet. Il existe depuis 1996 et a t initi par l'ITU (International Communication
Union), un groupe international de tlphonie qui dveloppe des standards de communication. Concrtement,
il est utilis dans des programmes tels que Microsoft Netmeeting, ou encore dans des quipements tels que
les routeurs Cisco. Il existe un projet OpenH.323 qui dveloppe un client H.323 en logiciel libre afin que les
utilisateurs et les petites entreprises puissent avoir accs ce protocole sans avoir dbourser beaucoup
d'argent.
6.1.2 - Fonctionnement
Le protocole H.323 est utilis pour l'interactivit en temps rel, notamment la visioconfrence (signalisation,
enregistrement, contrle d'admission, transport et encodage). C'est le leader du march pour la tlphonie
Ip. Il s'inspire du protocole H.320 qui proposait une solution pour la visioconfrence sur un rseau numrique
intgration de service (Rnis ou Isdn en anglais), comme par exemple le service numris propos par France
Telecom. Le protocole H.323 est une adaptation de H.320 pour les rseaux Ip. A l'heure actuelle, la
visioconfrence sur liaison Rnis est toujours la technique la plus dploye. Elle existe depuis 1990. Les
rseaux utiliss sont commutation de circuits. Ils permettent ainsi de garantir une Qualit de Service (QoS)
aux utilisateurs (pas de risque de coupure du son ou de l'image). Aujourd'hui, c'est encore un avantage
indiscutable. Par contre, comme pour le tlphone, la facturation est fonction du dbit utilis, du temps de
communication
et
de
la
distance
entre
les
appels.
H.323 dfinit plusieurs lments de rseaux :
Les terminaux - Dans un contexte de tlphonie sur IP, deux types de terminaux H.323 sont
Aujourd'hui disponibles. Un poste tlphonique IP raccords directement au rseau Ethernet de
l'entreprise. Un PC multimdia sur lequel est install une application compatible H.323.
Les passerelles (GW: Gateway) - Elles assurent l'interconnexion entre un rseau Ip et le rseau
tlphonique, ce dernier pouvant tre soit le rseau tlphonique public, soit un Pabx d'entreprise.
Elles assurent la correspondance de la signalisation et des signaux de contrle et la cohsion entre les
mdias. Pour ce faire, elles implmentent les fonctions suivantes de transcodage audio (compression,
dcompression), de modulation, dmodulation (pour les fax), de suppression d'chos, de suppression
des silences et de contrle d'appels. Les passerelles sont le plus souvent bases sur des serveurs
informatiques standards (Windows NT, Linux) quips d'interfaces particuliers pour la tlphonie
(interfaces analogiques, accs de base ou accs primaire RNIS, interface E1, etc.) et d'interfaces
rseau, par exemple de type Ethernet. La fonctionnalit de passerelle peut toutefois tre intgre
directement dans le routeur ainsi que dans les Pbx eux-mmes.
Les portiers (GK: Gatekeeper) - Ils sont des lments optionnels dans une solution H.323. Ils ont pour
rle de raliser la traduction d'adresse (numro de tlphone - adresse Ip) et la gestion des
autorisations. Cette dernire permet de donner ou non la permission d'effectuer un appel, de limiter la
bande passante si besoin et de grer le trafic sur le Lan. Les "gardes-barrire" permettent galement
de grer les tlphones classiques et la signalisation permettant de router les appels afin d'offrir des
services supplmentaires. Il peuvent enfin offrir des services d'annuaires.
Les units de contrle multipoint (MCU, Multipoint Control Unit) - Rfrence au protocole T.120 qui
permet aux clients de se connecter aux sessions de confrence de donnes. Les units de contrle
multipoint peuvent communiquer entre elles pour changer des informations de confrence.
Dans un contexte de tlphonie sur IP, la signalisation a pour objectif de raliser les fonctions suivantes :
Recherche et traduction d'adresses - Sur la base du numro de tlphone du destinataire, il s'agit de
trouver son adresse IP (appel tlphone . PC) ou l'adresse IP de la passerelle desservant le
destinataire. Cette fonction est prise en charge par le Gatekeeper. Elle est effectue soit localement
soit par requte vers un annuaire centralis.
Contrle d'appel - L'quipement terminal ( endpoint = terminal H.323 ou passerelle) situ
l'origine de l'appel tablit une connexion avec l'quipement de destination et change avec lui les
informations ncessaires l'tablissement de l'appel. Dans le cas d'une passerelle, cette fonction
implique galement de supporter la signalisation propre l'quipement tlphonique laquelle elle est
raccorde (signalisation analogique, Q.931, etc.) et de traduire cette signalisation dans le format
dfini dans H.323. Le contrle d'appel est pris en charge soit par les quipements terminaux soit par
le Gatekeeper. Dans ce cas, tous les messages de signalisation sont routs via le Gatekeeper, ce
dernier
jouant
alors
un
rle
similaire
celui
d'un
PBX.
Services supplmentaires : dviation, transfert d'appel, confrence, etc.
Trois protocoles de signalisation sont spcifis dans le cadre de H.323 savoir :
RAS (Registration, Admission and Status) - Ce protocole est utilis pour communiquer avec un
Gatekeeper. Il sert notamment aux quipements terminaux pour dcouvrir l'existence d'un
Gatekeeper et s'enregistrer auprs de ce dernier ainsi que pour les demandes de traduction
d'adresses. La signalisation RAS utilise des messages H.225.0 6 transmis sur un protocole de
transport non fiable (Udp, par exemple).
Q.931 - H.323 utilise une version simplifie de la signalisation RNIS Q.931 pour l'tablissement et le
contrle d'appels tlphoniques sur Ip. Cette version simplifie est galement spcifie dans la norme
H.225.0.
H.245 : ce protocole est utilis pour l'change de capacits entre deux quipements terminaux. Par
exemple, il est utilis par ces derniers pour s'accorder sur le type de codec activer. Il peut
galement servir mesurer le retard aller-retour (Round Trip Delay) d'une communication.
Une communication H.323 se droule en cinq phases :
tablissement d'appel
change de capacit et rservation ventuelle de la bande passante travers le protocole RSVP
(Ressource reSerVation Protocol)
tablissement de la communication audio-visuelle
Invocation ventuelle de services en phase d'appel (par exemple, transfert d'appel, changement de
bande passante, etc.)
Libration de l'appel.
6.1.3 - H323 dans le modle Osi
Les
diffrents
protocoles
sont
reprsents
ci-dessous
dans
le
modle
OSI
point
comme
illustr
sur
le
schma
ci-dessous
:
Dans le cas o il y a plus de deux interlocuteurs, la visioconfrence ncessite l'utilisation d'un pont multipoint
comme
illustr
sur
le
schma
ci-dessous
:
Pour se connecter entre eux, les interlocuteurs sont identifis par un numro ou une adresse E.164. Elle est
compose de numros et est structure comme un numro de tlphone. En particulier, un numro de
tlphone est une adresse E.164. E.164 est le nom de la norme qui dfinit ces adresses.
Pour router un appel H.323 dans le rseau, il est ncessaire d'avoir un GateKeeper . C'est un lment
logiciel qui fonctionne dans un PC, ou encore dans un pont multipoint ou dans un routeur IP (Exemple dans
les routeurs Cisco). En fonction de l'adresse destinataire contenue dans l'appel H.323, les diffrents
GateKeeper vont tablir la communication entre metteur et destinateur et mettre en place le routage.
Par ailleurs, le protocole H.323 intgre la norme T.120 qui permet le partage d'applications. On peut, par
exemple, afficher des documents sur les postes de travail des autres interlocuteurs.
6.1.5 - Avantages et inconvnients
Les rseaux IP sont commutation de paquets, les flux de donnes transitent en commun sur une mme
liaison. La visioconfrence IP mise sur une disponibilit de ces liaisons. Les dbits des rseaux IP doivent
donc tre adapts en fonction du trafic afin d'viter tout risque de coupure du son et de la vido. Tous les
sites n'ont pas le mme dbit. Plus le dbit sera lev et plus le risque de coupure sera faible. Par ailleurs,
tant que la Qualit de Service n'existera pas dans les rseaux IP, la fiabilit des visioconfrences sur les
lignes
faible
dbit
sera
basse.
A l'heure actuelle, la compatibilit entre les diffrentes normes de visioconfrence est assez faible. La
visioconfrence H.323 et H.320 sont compatibles mais elles ncessitent l'emploi de passerelles H.320/H.323.
En ce qui concerne les diffrentes normes pour la visioconfrence sur Ip, H.323 et Ip Multicast ne sont, en
rgle gnrale, pas compatibles, sauf dans le cadre de VRVS qui permet un certain degr d'interoprabilit,
mais
ne
gre
pas
la
norme
T.120.
Voici les principaux bnfices qu'apporte la norme H.323 sont les suivants :
Codec standards : H.323 tablit des standards pour la compression et la dcompression des flux audio
et vido. Ceci assure que des quipements provenant de fabricants diffrents ont une base commune
de dialogue.
Interoprabilit : Les utilisateurs veulent pouvoir dialoguer sans avoir se soucier de la compatibilit
du terminal destinataire. En plus d'assurer que le destinataire est en mesure de dcompresser
l'information, H.323 tablit des mthodes communes d'tablissement et de contrle d'appel.
Indpendance vis vis du rseau : H.323 est conu pour fonctionner sur tout type d'architecture
rseau. Comme les technologies voluent et les techniques de gestion de la bande passante
s'amliorent, les solutions bases sur H.323 seront capables de bnficier de ces amliorations
futures.
Indpendance vis vis des plates-formes et des applications : H.323 n'est li aucun quipement ou
systme d'exploitation.
Support multipoint : H.323 supporte des confrences entre trois points terminaux ou plus sans
ncessiter la prsence d'une unit de contrle spcialise.
Gestion de la bande passante : Le trafic audio et vido est un grand consommateur de ressources
rseau. Afin d'viter que ces flux ne congestionnent le rseau, H.323 permet une gestion de la bande
passante disposition. En particulier, le gestionnaire du rseau peut limiter le nombre simultan de
connexions H.323 sur son rseau ou limiter la largeur de bande disposition de chaque connexion. De
telles limites permettent de garantir que le trafic important ne soit pas interrompu.
Support multicast : H.323 supporte le multicast dans les confrences multipoint. Multicast envoie
chaque paquet vers un sous-ensemble des destinataires sans rplication, permettant une utilisation
optimale du rseau.
A l'heure actuelle, le standard de fait pour les systmes de tlphonie sur IP est la norme H.323 de l'UIT.
Indispensable pour permettre un minimum d'interoprabilit entre quipements de fournisseurs diffrents, ce
standard prsente toutefois les inconvnients suivants :
Protocole complexe, cr initialement pour les confrences multimdia et qui incorpore des
mcanismes superflus dans un contexte purement tlphonique. Ceci a notamment des incidences au
niveau des terminaux H.323 (tlphones IP, par exemple) qui ncessitent de ce fait une capacit
mmoire et de traitement non sans incidence au niveau de leur cot.
Comprend de nombreuses options susceptibles d'tre implmentes de faon diffrentes par les
constructeurs et donc de poser des problmes d'interoprabilit ou de plus petit dnominateur
commun (dans le choix du codec, par exemple) ; D'autre part, comme le seul codec obligatoire est le
codec G.711 (64 Kps) et que le support des autres codecs plus efficaces est optionnel,
l'interoprabilit entre produits provenant de constructeurs diffrents ne signifie pas qu'ils feront un
usage optimal de la bande passante. En effet, dans le cas o les codecs bas dbits sont diffrents, le
transport de la voix se fera 64 Kbps, ce qui, en terme de bande passante, ne prsente gure
d'avantages par rapport un systme tlphonique classique.
6.1.6 - Comparaison avec Sip
Sip est un autre protocole pour l'interactivit en temps rel. Il a t dvelopp par l'IETF et s'inspire du
protocole Http alors que H.323 s'inspire de la tlphonie. Sip est plus modulaire et peut fonctionner avec
d'autres protocoles. Il est donc plus souple que H.323.
6.1.7 - Conclusion
Le protocole H.323 est une des normes envisageables pour la visioconfrence sur Ip. Cependant, elle est
pour l'instant surtout employ par des programmes propritaires (Microsoft, etc.). La documentation est
difficile d'accs car l'ITU fait payer les droits d'accs aux derniers dveloppements de cette technologie, en
dehors des efforts faits par le projet OpenH.323 pour rendre cette technologie accessible tous. Cet
ensemble de normes ne s'avrent pas toujours compatibles avec d'autres protocoles cause de son
dveloppement inspir de la tlphonie, ce qui peut rendre son utilisation un peu "rigide".
6.2 - Protocole SIP
6.2.1 - Introduction
Le protocole Sip (Session Initiation Protocole) a t initi par le groupe MMUSIC (Multiparty Multimedia
Session Control) et dsormais repris et maintenu par le groupe SIP de l'IETF donnant la Rfc 3261 rendant
obsolte la Rfc 2543. Sip est un protocole de signalisation appartenant la couche application du modle Osi.
Son rle est d'ouvrir, modifier et librer les sessions. L'ouverture de ces sessions permet de raliser de
l'audio ou vidoconfrence, de l'enseignement distance, de la voix (tlphonie) et de la diffusion
multimdia sur Ip essentiellement. Un utilisateur peut se connecter avec les utilisateurs d'une session dj
ouverte. Pour ouvrir une session, un utilisateur met une invitation transportant un descripteur de session
permettant aux utilisateurs souhaitant communiquer de s'accorder sur la compatibilit de leur mdia, Sip
permet donc de relier des stations mobiles en transmettant ou redirigeant les requtes vers la position
courante de la station appele. Enfin, SIP possde l'avantage de ne pas tre attach un mdium particulier
et est sens tre indpendant du protocole de transport des couches basses.
6.2.2 - Fonctionnement
Sip intervient aux diffrentes phases de l'appel :
Une rponse une requte est caractrise, par un code et un motif, appels code d'tat et raison phrase
respectivement. Un code d'tat est un entier cod sur 3 bits indiquant un rsultat l'issue de la rception
d'une requte. Ce rsultat est prcis par une phrase, textbased (UTF-8), expliquant le motif du refus ou de
l'acceptation de la requte. Le code d'tat est donc destin l'automate grant l'tablissement des sessions
Sip et les motifs aux programmeurs. Il existe 6 classes de rponses et donc de codes d'tat, reprsentes
par le premier bit :
1xx = Information - La requte a t reue et continue tre traite
2xx = Succs - L'action a t reue avec succs, comprise et accepte
3xx = Redirection - Une autre action doit tre mene afin de valider la requte
4xx = Erreur du client - La requte contient une syntaxe ronne ou ne peut pas tre traite par ce
serveur
5xx = Erreur du serveur - Le serveur n'a pas russi traiter une requte apparemment correcte
6xx = Echec gnral - La requte ne peut tre traite par aucun serveur
Dans un systme Sip on trouve deux types de composantes, les users agents (UAS, UAC) et un rseau de
serveurs :
L'UAS (User Agent Server) - Il reprsente l'agent de la partie appele. C'est une application de type
serveur qui contacte l'utilisateur lorsqu'une requte Sip est reue. Et elle renvoie une rponse au nom
de l'utilisateur.
L'U.A.C (User Agent Client) - Il reprsente l'agent de la partie appelante. C'est une application de type
client qui initie les requtes.
Le relais mandataire ou PS (Proxy Server), auquel est reli un terminal fixe ou mobile, agit la fois comme
un client et comme un serveur. Un tel serveur peut interprter et modifier les messages qu'il reoit avant de
les retransmettre :
Le RS (Redirect Server) - Il ralise simplement une association (mapping) d'adresses vers une ou
plusieurs nouvelles adresses. (lorsqu'un client appelle un terminal mobile - redirection vers le PS le
plus proche - ou en mode multicast - le message mis est redirig vers toutes les sorties auxquelles
sont relis les destinataires). Notons qu'un Redirect Server est consult par l'Uac comme un simple
serveur et ne peut mettre de requtes contrairement au Ps.
Le LS (Location Server) - Il fournit la position courante des utilisateurs dont la communication
traverse les Rs et PS auxquels il est rattach. Cette fonction est assure par le service de localisation.
Le RG (Registrar) - C'est un serveur qui accepte les requtes Register et offre galement un service de
localisation comme le LS. Chaque PS ou RS est gnralement reli un Registrar.
6.2.3 - Scurit et Authentification
Les messages Sip peuvent contenir des donnes confidentielles, en effet le protocole Sip possde 3
mcanismes de cryptage :
Cryptage de bout en bout du Corps du message Sip et de certains champs d'en-tte sensibles aux
attaques.
Cryptage au saut par saut (hop by hop) fin d'empcher des pirates de savoir qui appelle qui.
Cryptage au saut par saut du champ d'en-tte Via pour dissimuler la route qu'a emprunt la requte.
De plus, fin d'empcher tout intrus de modifier et retransmettre des requtes ou rponses Sip, des
mcanismes d'intgrit et d'authentification des messages sont mis en place. Et pour des messages Sip
transmis de bout en bout, des cls publiques et signatures sont utilises par Sip et stockes dans les champs
d'en-tte
Autorisation.
Une autre attaque connue avec Tcp ou Udp est le deny of service , lorsqu'un Proxy Server intrus renvoie
une rponse de code 6xx au client (signifiant un chec gnral, la requte ne peut tre traite). Le client
peut ignorer cette rponse. Si il ne l'ignore pas et met une requte vers le serveur "rgulier" auquel il tait
reli avant la rponse du serveur "intrus", la requte aura de fortes chances d'atteindre le serveur intrus et
non son vrai destinataire.
6.2.4 - Comparaison avec H323
Voici les avantages du protocole H.323 :
Il existe de nombreux produits (plus de 30) utilisant ce standard adopt par de grandes entreprises
telles Cisco, IBM, Intel, Microsoft, Netscape, etc.
Les cinq principaux logiciels de visioconfrence Picturel 550, Proshare 500, Trinicon 500, Smartstation
et Cruiser 150 utilisent sur Ip la norme H.323.
Un niveau d'interoprabilit trs lev, ce qui permet plusieurs utilisateurs d'changer des donnes
audio et vido sans faire attention aux types de mdia qu'ils utilisent.
Voici les avantages du protocole Sip :
Sip est un protocole plus rapide. La sparation entre ses champs d'en-tte et son corps du message
facilite le traitement des messages et diminue leur temps de transition dans le rseau.
Nombre des en-ttes est limit (36 au maximum et en pratique, moins d'une dizaine d'en-ttes sont
utilises simultanment), ce qui allge l'criture et la lecture des requtes et rponses.
Sip est un protocole indpendant de la couche transport. Il peut aussi bien s'utiliser avec Tcp que Udp.
De plus, il spare les flux de donnes de ceux la signalisation, ce qui rend plus souple l'volution "en
direct" d'une communication (arrive d'un nouveau participant, changement de paramtres...).
SIP
H323
1,5 aller-retour
6 7 aller-retour
Maintenance du code
protocolaire
Evolution du protocole
Fonction de confrence
Distribue
Fonction de tlservices
H.323 v2 + H.450
Signalisation multicast
Non
6.2.5 - Conclusion
La simplicit, la rapidit et la lgret d'utilisation, tout en tant trs complet, du protocole Sip sont autant
d'arguments qui pourraient permettre Sip de convaincre les investisseurs. De plus, ses avances en
matire de scurit des messages sont un atout important par rapport ses concurrents.
6.3 - Transport Rtp et Rtcp
6.3.1 - Introduction
Rtp est un protocole qui a t dvelopp par l'IETF afin de facilit le transport temps rel de bout en bout des
flots donnes audio et vido sur les rseaux Ip, c'est dire sur les rseaux de paquets. Rtp est un protocole
qui se situe au niveau de l'application et qui utilise les protocoles sous-jacents de transport Tcp ou Udp. Mais
l'utilisation de Rtp se fait gnralement au-dessus de Udp ce qui permet d'atteindre plus facilement le temps
rel. Les applications temps rels comme la parole numrique ou la visio-confrence constitue un vritable
problme pour Internet. Qui dit application temps rel, dit prsence d'une certaine qualit de service (QoS)
que Rtp ne garantie pas du fait qu'il fonctionne au niveau Applicatif. De plus Rtp est un protocole qui se
trouve dans un environnement multipoint, donc on peut dire que Rtp possde sa charge, la gestion du
temps
rel,
mais
aussi
l'administration
de
la
session
multipoint.
Rtp et Rtcp sont dfinis, depuis juillet 2003, par la Rfc 3550 rendant obsolte la version prcdente Rfc 1889.
6.3.2 - Les fonctions de Rtp
Le protocole Rtp, Real Time Transport Protocol, standardis en 1996, a pour but d'organiser les paquets
l'entre du rseau et de les contrler la sortie. Ceci de faon reformer les flux avec ses caractristiques
de dpart. Rtp est gr au niveau de l'application donc ne ncessite pas l'implmentation d'un Kernel ou de
librairies. Comme nous l'avons dit dans l'introduction, Rtp est un protocole de bout en bout. Rtp est
volontairement incomplet et mallable pour s'adapter aux besoins des applications. Il sera intgr dans le
noyau de l'application. Rtp laisse la responsabilit du contrle aux quipements d'extrmit.
Rtp, est un protocole adapt aux applications prsentant des proprits temps rel. Il permet ainsi de :
Reconstituer la base de temps des flux (horodatage des paquets : possibilit de resynchronisation des
flux par le rcepteur)
Mettre en place un squencement des paquets par une numrotation et ce afin de permettre ainsi la
dtection des paquets perdus. Ceci est un point primordial dans la reconstitution des donnes. Mais il
faut savoir quand mme que la perte d'un paquet n'est pas un gros problme si les paquets ne sont
pas perdus en trop grands nombre. Cependant il est trs important de savoir quel est le paquet qui a
t perdu afin de pouvoir pallier cette perte. Et ce par le remplacement par un paquet qui se
compose d'une synthse des paquets prcdent et suivant.
Identifier le contenu des donnes pour leurs associer un transport scuris.
L'identification de la source c'est dire l'identification de l'expditeur du paquet. Dans un multicast
l'identit de la source doit tre connue et dtermine.
Transporter les applications audio et vido dans des trames (avec des dimensions qui sont
dpendantes des codecs qui effectuent la numrisation). Ces trames sont incluses dans des paquets
afin d'tre transportes et doivent de ce fait tre rcupres facilement au moment de la phase de
dpaqutisation afin que l'application soit dcode correctement.
En revanche, ce n'est pas "la solution" qui permettrait d'obtenir des transmissions temps rel sur IP. En effet,
il ne procure pas de :
Rservation de ressources sur le rseau (pas d'action sur le rseau, cf. RSVP);
Fiabilit des changes (pas de retransmission automatique, pas de rgulation automatique du dbit);
Garantie dans le dlai de livraison (seules les couches de niveau infrieur le peuvent) et dans la
continuit du flux temps rel.
6.3.3 - Entte Rtp
L'entte d'un paquet Rtp est obligatoirement constitu de 16 octets. Cette entte prcde le "payload" qui
reprsente
les
donnes
utiles.
6.3.3.1 - V
Ce champ, cod sur 2 bits, permet d'indiquer la version de Rtp. Actuellement, V=2.
6.3.3.2 - P
Ce bit indique, si il est 1, que les donnes possdent une partie de bourrage.
6.3.3.3 - X
Ce bit spcifie, si il est 1, que l'entte est suivie d'une entte supplmentaire.
6.3.3.4 - CC
Ce champ, cod sur 4 bits, reprsente le nombre de CSRC qui suit l'entte.
6.3.3.5 - M
Ce bit, lorsqu'il est 1, dfinie que l'interprtation de la Marque est par un profil d'application.
6.3.3.6 - PT
Bas sur 7 bits, ce champ identifie le type du payload (audio, vido, image, texte, html, etc.).
6.3.3.7 - Numro de squence
Ce champ, d'une taille de 2 octets, reprsente le numro d'ordre d'mission des paquets. Sa valeur initiale
est alatoire et il s'incrmente de 1 chaque paquet envoy, il peut servir dtecter des paquets perdus.
6.3.3.8 - Timestamp
Ce champ horodatage, de 4 octets, reprsente l'horloge systme ou l'horloge d'chantillonnage de
l'metteur. Elle doit tre monotone et linaire pour assurer la synchronisation des flux.
6.3.3.9 - SSRC
Bas sur 4 octets, ce champ identifie de manire unique la source de synchronisation, sa valeur est choisie
de manires alatoire par l'application.
6.3.3.10 - CSRC
Ce champ, sur 4 octets, identifie les sources de contribution. La liste des participants ayant leur contribution
(audio, vido) aux donne du paquet.
6.3.4 - Les fonctions de Rtcp
Le protocole Rtcp est fond sur la transmission priodique de paquets de contrle tous les participants
d'une session. C'est le protocole Udp (par exemple) qui permet le multiplexage des paquets de donnes Rtp
et des paquets de contrle Rtcp. Le protocole Rtp utilise le protocole Rtcp, Real-time Transport Control
Protocol, qui transporte les informations supplmentaires suivantes pour la gestion de la session :
Les rcepteurs utilisent Rtcp pour renvoyer vers les metteurs un rapport sur la QoS. Ces rapports
comprennent le nombre de paquets perdus, le paramtre indiquant la variance d'une distribution (plus
communment appel la gigue : c'est dire les paquets qui arrivent rgulirement ou
irrgulirement) et le dlai aller-retour. Ces informations permettent la source de s'adapter, par
exemple, de modifier le niveau de compression pour maintenir une QoS.
Une synchronisation supplmentaire entre les mdias. Les applications multimdias sont souvent
transportes par des flots distincts. Par exemple, la voix, l'image ou mme des applications
numrises sur plusieurs niveaux hirarchiques peuvent voir les flots gres suivre des chemins
diffrents.
L'identification car en effet, les paquets Rtcp contiennent des informations d'adresses, comme
l'adresse d'un message lectronique, un numro de tlphone ou le nom d'un participant une
confrence tlphonique.
Le contrle de la session, car Rtcp permet aux participants d'indiquer leur dpart d'une confrence
tlphonique (paquet Bye de Rtcp) ou simplement de fournir une indication sur leur comportement.
Le protocole Rtcp demande aux participants de la session d'envoyer priodiquement les informations cites
ci-dessus. La priodicit est calcule en fonction du nombre de participants de l'application. On peut dire que
les paquets Rtp ne transportent que les donnes des utilisateurs. Tandis que les paquets Rtcp ne
transportent en temps rel, que de la supervision. On peut dtailler les paquets de supervision en 5 types:
200 : rapport de l'metteur
201 : rapport du rcepteur
202 : description de la source
203 : au revoir
204 : application spcifique
Ces diffrents paquets de supervision fournissent aux noeuds du rseau les instructions ncessaires un
meilleur contrle des applications temps rel.
6.3.5 - Entte Rtcp
Ce protocole dfini cinq paquets de contrle :
200 - SR (Sender Report) : Ce rapport regroupe des statistiques concernant la transmission
(pourcentage de perte, nombre cumul de paquets perdus, variation de dlai (gigue), ...Ces rapports
sont issus d'metteurs actifs d'une session.
201 - RR (Receiver Report) : Ensemble de statistiques portant sur la communication entre les
participants. Ces rapports sont issus des rcepteurs d'une session.
202 - SDES (Source Description) : Carte de visite de la source (nom, e-mail, localisation).
203 - BYE : Message de fin de participation une session.
204 - APP : Fonctions spcifiques une application.
Voici
l'en-tte
commun
tous
les
paquets
Rtcp.
6.3.5.1 - V
Ce champ, cod sur 2 bits, permet d'indiquer la version de Rtp, qui est la mme que dans les paquets Rtcp.
Actuellement, V=2.
6.3.5.2 - P
Ce bit indique, si il est 1, que les donnes possdent une partie de bourrage.
6.3.5.3 - RC
Ce champ, bas sur 5 bits, indique le nombre de blocs de rapport de rception contenus en ce paquet. Une
valeur de zro est valide.
6.3.5.4 - PT
Ce champ, cod sur 1 octet, est fix 200 pour identifier ce datagramme Rtcp comme SR.
6.3.5.5 - Longueur
Ce champ de 2 octets, reprsente la longueur de ce paquet Rtcp incluant l'entte et le bourrage.
6.3.5.6 - SSRC
Bas sur 4 octets, ce champ, reprsente l'identification de la source pour le createur de ce paquet SR.
6.3.6 - Conclusion
Rtp ncessite le protocole de transport Udp, (en-tte 8 octets), qui fournira les numros de port source et
destination ncessaire la couche application. Pour l'instant le protocole Rtp se trouve au dessus de Udp,
tandis que dans le futur, on aura une indpendance vis vis des couches rseaux.
En rsumant, ces deux protocoles sont adapts pour la transmission de donnes temps rel. Cependant, ils
fonctionnent en stratgie bout bout et donc ne peuvent contrler l'lment principal de la communication :
le
rseau.
Ces protocoles sont principalement utiliss en visioconfrence o les participants sont tour tour metteurs
ou rcepteurs. Pour le transport de la voix, ils permettent une transmission correcte sur des rseaux bien
cibls. C'est--dire, des rseaux qui implmentent une qualit de service adapte. Des rseaux bien
dimensionns (bande passante, dterminisme des couches sous-jacentes, Cos, ...) peuvent aussi se servir de
cette solution.
6.4 - H261
Le protocole H.261 est dcrit dans la RFC 2032, cette norme dcrit le transport d'un flux vido sur Rtp. Le format
de
l'en-tte
est
le
suivant
:
SBIT (Start Bit) - Bas sur 3 bits, ce champ reprsente le nombre de bits de poids forts ignorer dans le premier
octet
de
donnes.
EBIT (End Bit) - Bas sur 3 bits, ce champ reprsente le nombre de bits de poids faible ignorer dans le dernier
octet
de
donnes.
I (Intra-frame encoded data flag) - Bas sur 1 bit, ce flag doit tre mis 1 si il contient seulement des intra-frame
cod.
V
(Motion
Vector)
Bas
sur
bit,
ce
flag
indique
si
le
Motion
Vector
est
utilis
ou
pas.
GOBN (GOB number) - Bas sur 4 bits, ce champ code le nombre de GOB actif au dbut du paquet. Placez 0 si
le
paquet
commence
par
un
en-tte
de
GOB.
MBAP (Macroblock Address Predictor) - Bas sur 5 bits, ce champ code le prdicteur d'adresse de Macroblock.
Placez
0
si
le
paquet
commence
par
un
en-tte
de
GOB.
QUANT (Quantizer) - Bas sur 5 bits, ce champ reprsente la valeur actif avant le dbut de ce paquet.
HMVD (Horizontal Motion Vector Data) - Bas sur 5 bits, ce champ doit tre 0 si le flag V est 0 ou si le paquet
commence
avec
une
entte
Gob.
VMVD (Vertical Motion Vector Data) - Bas sur 5 bits, ce champ doit tre 0 si le flag V est 0 ou si le paquet
commence avec une entte Gob.
6.5 - Audio
Le transport de la voix sur un rseau IP ncessite au pralable tout ou une partie des tapes suivantes :
Numrisation : dans le cas o les signaux tlphoniques transmettre sont sous forme analogique, ces
derniers doivent d'abord tre convertis sous forme numrique suivant le format PCM (Pulse Code
Modulation) 64 Kbps. Si l'interface tlphonique est numrique (accs RNIS, par exemple), cette fonction
est omise.
Compression : le signal numrique PCM 64 Kbps est compress selon l'un des formats de codec
(compression / dcompression) (Tableau 3-3) puis insr dans des paquets IP. La fonction de codec est le
plus souvent ralise par un DSP (Digital Signal Processor). Selon la bande passante disposition, le signal
voix peut galement tre transport dans son format originel 64 Kbps.
Dcompression : ct rception, les informations reues sont dcompresses .il est ncessaire pour cela
d'utiliser le mme codec que pour la compression- puis reconverties dans le format appropri pour le
destinataire (analogique, PCM 64Kbps, etc.).
L'objectif d'un codec est d'obtenir une bonne qualit de voix avec un dbit et un dlai de compression le plus
faibles possibles. Le cot du DSP est li la complexit du codec utilis. Le Tableau ci-dessous prsente les
caractristiques des principaux codecs standards de l'UIT. Les codecs les plus souvent mis en oeuvre dans les
solutions
VoIP
sont
G.711,
G.729
et
G.723.1.
La qualit d'un codec est mesure de faon subjective en laboratoire par une population test de personnes. Ces
dernires coutent tout un ensemble de conversations compresses selon les diffrents codecs tester et les
valuent
qualitativement
selon
la
table
suivante
:
Tableau : Echelle utilis pour l'valuation de la qualit de voix
Qualit de la parole
Score
Excellente
Bonne
Correcte
Pauvre
Insuffisante
Sur la base des donnes numriques des apprciations, une opinion moyenne de la qualit d'coute (Mean
Opinion Score . MOS) est ensuite calcule pour chaque codec. Les rsultats obtenus pour les principaux codecs
sont
rsums
dans
le
tableau
ci-dessous
:
Tableau : Score MOSdes diffrents codecs
Codec VoIP
Dbit (Kbps)
Score MOS
G.711 (PCM)
64
4.1
G.726
32
3.85
3.92
G.729
G.723.1
6.4
3.9
G.723.1
5.3
3.65
GSM
13
3.5
G.729 x2
3.27
G.729 x3
2.68
G.729 x GSM
3.17
7 - Problme et QoS
7.1 - Latence
La matrise du dlai de transmission est un lment essentiel pour bnficier d'un vritable mode conversationnel
et minimiser la perception d'cho (similaire aux dsagrments causs par les conversations par satellites,
dsormais
largement
remplacs
par
les
cbles
pour
ce
type
d'usage).
Or la dure de traverse d'un rseau IP dpend de nombreux facteurs:
ce
dlai.
Il est important de rappeler que sur les rseaux IP actuels (sans mcanismes de garantie de qualit de service),
chaque paquet IP fait sont chemin indpendamment des paquets qui le prcdent ou le suivent: c'est ce qu'on
appelle grossirement le Best effort pour signifier que le rseau ne contrle rien. Ce fonctionnement est
fondamentalement diffrent de celui du rseau tlphonique o un circuit est tabli pendant toute la dure de la
communication.
Les chiffres suivants (tirs de la recommandation UIT-T G114) sont donns titre indicatif pour prciser les
classes de qualit et d'interactivit en fonction du retard de transmission dans une conversation tlphonique. Ces
chiffres concernent le dlai total de traitement, et pas uniquement le temps de transmission de l'information sur le
rseau.
Classe n Dlai par sens Commentaires
Classe n
Commentaires
0 150 ms
150 300 ms
300 700 ms
Au del de 700 ms
En conclusion, on considre gnralement que la limite suprieure "acceptable" , pour une communication
tlphonique, se situe entre 150 et 200 ms par sens de transmission (en considrant la fois le traitement de la
voix et le dlai d'acheminement).
7.2 - Perte de paquets
Lorsque les buffers des diffrents lment rseaux IP sont congestionns, ils librent automatiquement de la
bande passante en se dbarrassant d'une certaine proportion des paquets entrant, en fonction de seuils
prdfinis. Cela permet galement d'envoyer un signal implicite aux terminaux TCP qui diminuent d'autant leur
dbit au vu des acquittements ngatifs mis par le destinataire qui ne reoit plus les paquets. Malheureusement,
pour les paquets de voix, qui sont vhiculs au dessus d'UDP, aucun mcanisme de contrle de flux ou de
retransmission des paquets perdus n'est offert au niveau du transport. D'o l'importance des protocoles RTP et
RTCP qui permettent de dterminer le taux de perte de paquet, et d'agir en consquence au niveau applicatif.
Si aucun mcanisme performant de rcupration des paquets perdus n'est mis en place (cas le plus frquent dans
les quipements actuels), alors la perte de paquet IP se traduit par des ruptures au niveau de la conversation et
une impression de hachure de la parole. Cette dgradation est bien sr accentue si chaque paquet contient un
long temps de parole (plusieurs trames de voix de paquet). Par ailleurs, les codeurs trs faible dbit sont
gnralement plus sensibles la perte d'information, et mettent plus de temps reconstruire un codage
fidle.
Enfin connatre le pourcentage de perte de paquets sur une liaison n'est pas suffisant pour dterminer la qualit
de la voix que l'on peut esprer, mais cela donne une bonne approximation. En effet, un autre facteur essentiel
intervient; il s'agit du modle de rpartition de cette perte de paquets, qui peut tre soit rgulirement
rpartie, soit rpartie de manire corrle, c'est dire avec des pics de perte lors des phases de congestion,
suivies de phases moins dgrades en terme de QoS.
7.3 - Gigue
La gigue est la variance statistique du dlai de transmission. En d'autres termes, elle mesure la variation
temporelle entre le moment o deux paquets auraient d arriver et le moment de leur arrive effective. Cette
irrgularit d'arrive des paquets est due de multiples raisons dont: l'encapsulation des paquets IP dans les
protocoles supports, la charge du rseau un instant donn, la variation des chemins emprunts dans le rseau,
etc...
Pour compenser la gigue, on utilise gnralement des mmoires tampon (buffer de gigue) qui permettent de lisser
l'irrgularit des paquets. Malheureusement ces paquets prsentent l'inconvnient de rallonger d'autant le temps
de traverse global du systme. Leur taille doit donc tre soigneusement dfinie, et si possible adapte de
manire
dynamique
aux
conditions
du
rseau.
La dgradation de la qualit de service due la prsence de gigue, se traduit en fait, par une combinaison des
deux facteurs cits prcdemment: le dlai et la perte de paquets; puisque d'une part on introduit un dlai
supplmentaire de traitement (buffer de gigue) lorsque l'on dcide d'attendre les paquets qui arrivent en retard,
et que d'autre part on finit tout de mme par perdre certains paquets lorsque ceux-ci ont un retard qui dpasse le
dlai maximum autoris par le buffer.
8 - Etat du march
On compte une bonne vingtaine de firmes sur le march. Les principaux sont Cisco, Clarent, Avaya, Alcatel, Nortel
Network, Siemens, Tnovis, 3COM ... Ce qu'il faut souligner, c'est le fait qu'il y ait peu de concurrents car comme je l'ai
dit prcdemment, la tlphonie sur Ip est un march trs jeune et trs novateur. D'ailleurs, le fait que la tlphonie
sur IP soit un march chevauchant 2 secteurs qui se rapprochent et taient compltement diffrent auparavant, la
tlphonie et l'informatique, nous assistons ici une concurrence ayant des origines diffrentes. En effet, nous
retrouvons le gant de l'quipement rseaux Cisco en concurrence avec des entreprises de tlphonies tel que Alcatel
ou Siemens. Mais Cisco et Clarent arrivent largement en tte, sur un march qui de 259 millions de dollars cette anne
pourrait atteindre 2,89 milliards en 2006. La tlphonie sur IP propose 3 types de terminaux diffrents : Les
hardphones qui sont des tlphones physiques IP, les softphones qui sont des logiciels permettant de tlphoner sur IP
au travers d'un PC et les tlphones IP Wi-fi qui sont des tlphones sans-fil IP. Mais la plupart des concurrents
proposent ces 3 produits qui sont plutt homognes. Un softphone Cisco et un Softphone Siemens sont quasiidentiques. Seule l'interface graphique les distingue. Pour le client, le produit des 2 concurrents est identique dans la
mesure
o
il
apporte
les
mmes
services.
Voici une documentation complmentaire sur la tlphonie sur IP en Open Source.
9 - Conclusion
Actuellement, il est vident que la tlphonie IP va continuer de se dvelopper dans les prochaines annes. Le march
de la tlphonie IP est trs jeune mais se dveloppe une vitesse fulgurante. C'est aujourd'hui que les entreprises
doivent
investir
dans
la
tlphonie
IP
si
elles
veulent
y
jouer
un
rle
majeur.
Le fait est que IP est maintenant un protocole trs rpandu, qui a fait ses preuves et que beaucoup d'entreprises
disposent avantage de la tlphonie IP, car elle demande un investissement relativement faible pour son dploiement.
La tlphonie IP ouvre la voie de la convergence voix/donnes et celle de l'explosion de nouveaux services tels que les
CTI.
Maintenant que la normalisation a atteint une certaine maturit, il n'est plus dangereux de miser sur le standard H323
qui
a
t
accept
par
l'ensemble
de
la
communaut.
La tlphonie IP est une bonne solution en matire d'intgration, de fiabilit, d'volutivit et de cot. Elle fera partie
intgrante des Intranets d'entreprises dans les annes venir et apparatra aussi dans la tlphonie publique pour
permettre
des
communications
bas
cot.
Enfin, le dveloppement de cette technologie reprsente-t-il un risque ou une opportunit pour les oprateurs
traditionnels ? La rponse n'est pas tranche. D'un cot, une stagnation des communications classiques; d'un autre
cot l'utilisation massive d'Internet va augmenter le trafic et dvelopper de nouveaux services que pourront dvelopper
les
oprateurs.
Bientt
nous
tlphonerons
tous
sur
IP...
On peut ainsi vraisemblablement penser que le protocole IP deviendra un jour un standard unique permettant
l'interoprabilit des rseaux mondialiss. C'est pourquoi l'intgration de la voix sur IP n'est qu'une tape vers EoIP :
Everything over IP.
Triple Play
1 - Introduction
2 - Triple Play par ADSL
2.1 - La technologie ADSL
2.2 - La Set-Top-Box
2.3 - Accs Internet
2.3.1 - Connexion l'abonn
2.3.2 - Connexion la Set-Top-Box
2.3.3 - Dbit IP
2.4 - Tlphonie
2.4.1 - POTS
2.4.2 - Voice over IP
2.4.3 - Voice over ATM
3-
45678-
1 - Introduction
Les FAI (Fournisseur d'Accs Internet) proposent depuis maintenant prs de deux ans de nouvelles offres. Il s'agit
d'offres Triple Play qui permettent l'utilisateur de bnficier d'un accs Internet haut dbit, de la tlphonie et de
la tlvision par Internet.
Aprs avoir ralis une prsentation gnrale de cette technologie, une prsentation plus spcifiques des diffrentes
technologies utilises sera ralise. Puis nous exposerons les diffrentes offres proposs actuellement par les FAI. Ce
document sera cltur par une prsentation des volutions possibles de cette technologie.
L'ADSL a permis d'obtenir des dbits de 10 500 fois plus importants que les prcdentes techniques d'accs
Internet pour particuliers (V92: 56kbps ; ADSL2+: 25Mbps), offrant alors la possibilit aux FAI de proposer
d'autres services que l'accs Internet, comme c'est le cas avec les offres Triple Play.
Les offres Triple Play par ADSL sont exclusivement proposes aux abonns dgroups. Le dgroupage est une
modalit technico-conomique pour ouvrir rapidement le rseau local de tlcommunications la concurrence. Il
permet aux FAI de disposer d'une partie (dgroupage partiel) ou de la totalit (dgroupage total) des bandes de
frquences de la ligne tlphonique, et ainsi, de faire passer des dbits beaucoup plus important que sur des
lignes non dgroupes. Pour exploiter ces bandes de frquences, ils doivent cependant installer leurs propre
appareils dans les centrales tlphoniques.
En France, l'heure actuelle, les abonns dont la ligne tlphonique n'est pas dgroupe ne peuvent, au mieux,
que bnficier d'un dbit de 2Mbps, ce qui n'est pas suffisant pour faire passer des flux audio/vido.
Les dbits proposs par l'ADSL sont des dbits idaux, car l'ADSL est trs sensible l'attnuation des lignes
tlphoniques. Ainsi, plus une ligne sera longue entre un abonn et son central tlphonique, et moins le dbit
qu'il pourra obtenir via l'ADSL sera grand. De mme si la ligne est abme, ou qu'elle comporte des dispositifs
lectroniques (ex: les anciens condensateurs en fin de ligne qui servait l'oprateur tlphonique pour tester la
ligne distance).
Cette contrainte est trs pnalisante pour les offres Triple Play (et notamment pour le flux vido qui demandent
beaucoup de bande passante), et ne peut tre amliore dans les futures versions de l'ADSL. Les offres Triple Play
compltes sont donc rserves aux abonns habitant relativement prs de leur central tlphonique (max:
2,5km).
2.2 - La Set-Top-Box
La Set-Top Box (STB) est un appareil que les FAI ADSL fournissent (parfois gratuitement) leurs abonns pour
pouvoir bnficier des offres Triple Play. Il s'agit d'un botier qui se connecte sur la ligne tlphonique, et qui
dispose au minimum d'une sortie tlvision (prise Pritel ou RCA), d'un connecteur tlphonique (RJ11 ou prise
tlphonique), et d'un connecteur Internet (RJ45, USB, WiFi, etc.).
La STB est en quelque sorte un mini-ordinateur capable de communiquer via ADSL avec le FAI, et de proposer des
services avancs aux abonns.
Certaines STB disposent de services supplmentaires (parfois payant) comme des fonctionnalits de partages de
connexion Internet (routage IP/NAT), de lecteur multimdia ( destination de la tlvision), de streaming
multipostes (i.e., recevoir plus d'une chane de tlvision), etc.
2.3 - Accs Internet
L'accs Internet est le premier type de service qui a t propos travers l'ADSL. Les autres services d'une
offre Triple Play par ADSL tant dpendant de celui l, nous allons nous intresser au fonctionnement de ce
service dans un premier temps.
2.3.1 - Connexion l'abonn
La connexion entre l'utilisateur et la STB peut gnralement s'effectuer de trois faons diffrentes:
Connexion USB: il s'agit d'une liaison srie qui permet l'utilisateur de connecter directement son
ordinateur la STB. Elle ne spcifie aucun protocole de communication particulier utiliser.
Cependant, la communication avec la STB se fait, la plupart du temps, en utilisant soit le protocole
ATM, soit le protocole Ethernet. Il se peut aussi que la STB ne fonctionne que comme un modem
ADSL classique en utilisant ce type de connexion, obligeant alors l'utilisation du protocole PPP au
dessus d'ATM (PPPoA) ou d'Ethernet (PPPoE) dans ce cas.
Connexion Ethernet: il s'agit en fait d'une connexion Fast Ethernet (100 Mbit/s) qui permet
l'utilisateur de se connecter la STB au moyen d'une carte rseau.
Connexion WiFi: la plupart du temps, il s'agit d'un module optionnel payant qui permet
l'utilisateur de se connecter la STB au moyen d'une connexion sans fils, type 802.11b/g.
Bien videmment, le protocole rseau utilis ici es t le protocole IP. Sa configuration au niveau de
l'ordinateur de l'utilisateur est effectue l'aide d'un serveur DHCP, soit implment dans la STB, soit se
situant dans les locaux du FAI.
En gnral, les FAI ne procurent qu'une seule adresse IP par abonn (l'abonn peut cependant en obtenir
d'autre en payant, mais ce n'est pas frquent avec tous les FAI). Cette dernire peut d'ailleurs changer dans
le temps (IP dynamique), mais tant donn la nature quasi permanente des connexions ADSL, les IP
dynamiques n'offrent aucun avantage aux FAI.
Pour partager la connexion Internet entre diffrent ordinateurs, il existe gnralement deux solutions:
soit la STB permet d'effectuer du routage IP (et plus prcisment, du routage NAT), et dans ce cas,
il suffit de la configurer de manire ce qu'elle partage la connexion Internet (ou, plus exactement,
qu'elle partage l'adresse IP publique de cette connexion). Si on veut pouvoir se connecter en
Ethernet Internet, il faut alors prvoir des appareils de partage du lien Ethernet (hub ou switch).
En WiFi, le lien est naturellement partag. Enfin, en utilisant la connexion USB, on doit possder un
appareil qui fasse la passerelle entre le lien USB et un lien rseau (principalement Ethernet), et qui
soit compatible avec les drivers USB de la STB. Cela ne peut bien sur pas fonctionner si la
connexion Internet dpend du protocole PPP. Ce type de partage de connexion permet de pouvoir
utiliser en mme temps les trois types d'accs la STB pour se connecter Internet.
sinon, on doit utiliser un appareil externe la STB capable d'effectuer le routage NAT. Cela peut
tre un appareil ddi, ou un ordinateur. L cependant, on ne peut plus utiliser qu'un seul des trois
type
de
connexion
la
STB
pour
accder
Internet.
2.3.3 - Dbit IP
Le dbit en ADSL dpend du contrat de l'abonn, mais surtout, de la distance entre l'installation de
l'utilisateur et le central tlphonique o se trouve le DSLAM auquel il est connect. Actuellement, cela va de
128 kbit/s 25 Mbit/s (ADSL2+) pour le flux descendant (download), et de 128 kbit/s 1 Mbit/s (ADSL2+)
pour le flux montant (upload), sachant que seuls les utilisateurs habitant prs de leur central tlphonique
peuvent bnficier des meilleurs dbits. Les limites de dbits par utilisateur sont effectues au niveau du
DSLAM.
Ainsi, en ADSL, le dbit vendu n'est que rarement garanti. De plus, il est spcifi par un dbit ATM, qui ne
correspond pas au dbit IP, et, de fait, encore moins au dbit utile disponible pour l'utilisateur.
On notera enfin que la totalit du dbit ADSL vendu n'est pas totalement ddi l'accs Internet dans une
offre Triple Play. En effet, ce dbit est partag entre le flux de donnes (Internet), le flux audio (tlphonie)
et le flux vido (tlvision), sachant que ce dernier est extrmement gourmand. Ce partage est cependant
adaptatif, c'est dire que, tant qu'un flux est tout seul utiliser la connexion, il peut jouir de la totalit du
dbit (c'est une spcificit d'ATM).
2.4 - Tlphonie
La tlphonie au travers d'une ligne ADSL (parfois nomme Voice over xDSL) peut tre effectue de plusieurs
manires, mme si aujourd'hui, les FAI ADSL semble tous adopter la mme technologie pour mettre en place
leurs services de tlphonie.
2.4.1 - POTS
Le Plain Old Telephone Service correspond en fait la faon traditionnelle de faire de la tlphonie, c'est-dire, en se servant classiquement des frquences basses de la ligne tlphonique de l'abonn pour y faire
passer de la voix de manire analogique. C'est un systme encore utilis par les oprateurs tlphoniques, et
qui, dans le cas de l'ADSL, est une faon logique de transporter de la voix, les lignes tlphoniques ayant t
prvues initialement pour cela. Les conversations tlphoniques sont alors possibles sans ajout de matriel
spcifique chez l'abonn, et sont directement transmises par le RTC classique (via le rseau d'un oprateur
de tlphonie).
Fournir un service tlphonique de ce type ncessite d'avoir accs aux frquences basses de la ligne
tlphonique. Cela n'est possible que si le FAI a effectu un dgroupage total de la ligne tlphonique de
l'abonn, ou si le FAI est en plus un oprateur de tlphonie alternatif.
Aujourd'hui, seuls les oprateurs de tlphonie qui se sont lancs par la suite dans la proposition de services
Internet utilisent encore ce systme. Les FAI qui ne proposaient pas initialement de services de tlphonie
ont quant eux prfrs ne pas avoir utiliser directement le RTC pour faire passer leurs services de
tlphonie (et donc, payer les services d'un oprateur de tlphonie), mais plutt, utiliser leur rseau
informatique interne pour rduire les cots.
2.4.2 - Voice over IP
La voix sur IP est un mcanisme qui permet de faire passer des conversations audio entre plusieurs appareils
interconnects entre eux via un rseau informatique supportant le protocole IP. Dans le monde ADSL, on
peut aussi le retrouver sous l'acronyme VoMSDN (Voice over MultiService Data Networks).
Il se compose essentiellement de trois modules:
un module de numrisation de la voix, qui a pour tche de convertir la voix analogique en donnes
numriques (et inversement), en utilisant ventuellement des algorithmes de compression.
un protocole de contrle de la conversation, qui permet d'tablir une conversation entre plusieurs
participant, et qui se charge de ngocier les diffrents paramtres de configuration de cette
conversation.
un protocole de transport des donnes audio, qui encapsule la voix numrise dans des paquets IP
afin de la transporter travers le rseau, en utilisant ventuellement un mcanisme de QoS.
La VoIP est une technique rentable pour les FAI, car elle rutilise leur rseau interne (initialement destin
aux services Internet) pour faire passer leurs services de tlphonie. De plus, cela permet de supprimer la
notion de distance dans le cot des appels tlphoniques tant donn que le trafic IP n'est pas factur la
distance, mais la quantit de donnes transfres, et que les rseaux des FAI s'tendent sur la quasitotalit du territoire franais. Enfin, les circuits lectroniques de numrisation de la voix tant aujourd'hui peu
coteux (du fait qu'il s'agisse d'une technologie amortie, et qu'ils sont maintenant produit en masse), cela
permet d'inclure directement dans les STB de tels circuits moindre frais. Ainsi, c'est ce type de technique
qui est presque exclusivement utilis par les FAI franais pour proposer leurs services de tlphonie.
La VoIP ne reste cependant qu'un concept, et il en existe aujourd'hui plusieurs implmentations
incompatibles entres elles. Elles fonctionnent cependant globalement avec les mmes types d'lments
rseaux:
les terminaux: cela peut tre soit un ordinateur disposant d'une connexion IP, soit un tlphone IP,
soit un appareil permettant de numriser les signaux d'un tlphone classique (le cas d'une STB par
exemple). C'est par eux que les utilisateurs initialisent et reoivent les conversations tlphoniques.
les registres: ils permettent d'associer un terminal (via son adresse IP) un identifiant plus simple
utiliser, et connu par les utilisateurs dsirant contacter ce terminal. Cette association peut
s'effectuer l'aide d'un mcanisme d'identification plus ou moins complexe.
les proxy: ce sont des lments qui permettent la mise en relation de deux terminaux qui ne se
connaissent pas (i.e., le terminal appelant ne connat pas l'adresse IP du terminal appeler). Ils
sont gnralement lis aux registres (voire confondus), et peuvent controler les accs d'un terminal
en fonction d'une politique de gestion de droits.
les passerelles: elles assurent l'inter-connexion entre un rseau VoIP spcifique et un autre type de
rseau tlphonique (RTC, VoIP, VoATM, etc.).
les units de contrle multi-points (Multipoint Control Unit): elles permettent de grer les
communications qui comportent plus de deux participants.
point point: les terminaux qui veulent communiquer ( hauteur de deux terminaux maximum par
conversation) se connectent directement entre eux, en effectuant une phase de ngociation pour
dterminer les paramtres de la communication. Un fois la communication initialise, les donnes
(uniquement audio dans le cas de la VoIP) peuvent circuler entre les deux terminaux, l'aide d'un
protocole de transfert de donnes isochrones. Ce type de communication ncessite de connatre
l'adresse IP du terminal qu'un utilisateur veut joindre, ce qui n'est pas toujours possible (surtout
quand un des deux participants se situe derrire un routeur NAT).
point point, via un proxy: ici, tous les terminaux s'enregistrent avec le registre afin d'tre associ
avec un identifiant connus des utilisateurs susceptibles de les appeler. Quand un terminal a besoin
d'en contacter un autre, il utilise alors le proxy en lui donnant l'identifiant du terminal qu'il veut
contacter. Le proxy se sert alors du registre pour dterminer l'adresse IP du terminaux joindre, et
dtermine si ce terminal est libre et accessible par le terminal appelant. Le cas chant, la
communication entre les deux terminaux s'effectue en point point.
multi-points: dans le cadre d'une communication entre plus de deux terminaux, une MCU est
utilise pour grer la mise en relation des diffrents participants. Elle permet de spcifier le nombre
maximum de participants, les dbits de la communication, l'identifiant de la communication, etc. La
MCU est utilise par le proxy. Le reste de la communication s'effectue de la mme manire qu'en
point point, via un proxy, ceci prs que c'est la MCU qui est le destinataire de tous les flux (elle
les redirige vers les autres participant en utilisant du multicast IP en gnral).
Les implmentations actuelles de VoIP ont t penses, non pas pour effectuer des conversations audio
seulement, mais pour grer et transporter des communications multimdia, pouvant comporter autant de la
voix que de la vido ou des donnes (texte, dessins, etc.). Il existe aujourd'hui deux grandes normes qui
sont utilises pour effectuer de la VoIP:
La plupart du temps, c'est le protocole RTP (Real Time Protocol) qui est utilis pour transporter les donnes
audio, que a soit en H.323 (norme d'o provient RTP) ou en SIP. Ce protocole encapsule les donnes de la
conversation en ajoutant des informations temporelles qui permettent d'effectuer une synchronisation
temporelle des flux au niveau du rcepteur. RTP reposant sur UDP, il ne permet pas de s'assurer de la
fiabilit de la transmission (mais seul UDP peut tre utilis pour des applications temps rel, TCP ajoutant
une latence non ngligeable).
Il peut tre associ au protocole RTCP (Real Time Control Protocol) qui permet d'avoir un retour de la part du
rcepteur sur, entre autre, le nombre de donnes reues et perdues, afin d'adapter dynamiquement les
paramtres de la communication, et effectuer ainsi de la QoS.
Les FAI fournissant des services de tlphonie par VoIP utilisent gnralement le protocole SIP, en
association avec d'autres protocoles de signaltique qui permettent d'adapter simplement les signaux de la
tlphonie classique (provenant du RTC ou d'un simple tlphone classique) des signaux de contrles VoIP.
Ainsi, on peut par exemple trouver les protocoles SIP-T (Session Initiation Protocol for Telephones) et MGCP
(Multimedia Gateway Control Protocol) dans le dispositif VoIP du FAI Free.
Le protocole SIP-T permet d'adapter les signaux provenant (ou destination) du RTC pour les utiliser en
VoIP, et MGCP permet d'adapter les signaux provenant (ou destination) d'un tlphone classique pour que
la STB puisse les utiliser en VoIP, sans effectuer un trop gros travail de conversion.
Dans le cas de Free, les commutateurs XC jouent le fois le rle de passerelle (vers le RTC ou les rseau
d'autres FAI), de proxy et de registre (en se servant de la base de donnes des abonnes). Ils
communiquent entre eux l'aide du protocole SIP-T.
Les STB (appeles Freebox chez Free) communiquent quant elles avec un commutateur XC (toujours le
mme pour une Freebox donne) l'aide du protocole MGCP. Chaque Freebox est associe
(gographiquement) un commutateur dont elle dpend pour passer et recevoir des appels.
Les commutateurs ont besoin de communiquer entre eux pour acheminer un appel, soit en provenance (ou
destination) d'un autre rseau, soit en provenance (ou destination) de deux Freebox ne dpendant pas du
mme commutateur.
Les donnes audio voyagent par le protocole RTP, entre une Freebox et un commutateur, dans le cas d'une
communication inter-rseaux, ou directement entre deux Freebox, dans le cas d'une communication entre
deux abonns de Free. On notera, dans le premier cas, qu'un seul commutateur XC est concern par les
paquets RTP: le commutateur qui fait la passerelle avec le rseau du second participant de la communication.
La VoIP est donc un technique particulirement adapte la tlphonie dans les offres Triple Play,
de part son faible cot (d principalement au fait qu'elle r-utilise le rseau du FAI) et sa simplicit
d'intgration dans les STB.
2.4.3 - Voice over ATM
La VoATM (aussi connue sous le nom Voice Trafic over ATM) est une technique qui permet de tirer partie des
fonctionnalits de transport multi-flux de l'ATM. Les DSLAM tant la plupart du temps relis par des liaisons
ATM au FAI, il peut sembler plus judicieux d'utiliser de la VoATM pour faire passer le flux audio ADSL plutt
que de se servir du protocole VoIP. De plus, l'ATM permet de faire de la rservation de dbit, ce que n'offre
pas IP, cela pouvant tre un gros problme dans les transferts de type isochrone.
Cependant, en France, la VoATM n'est pas utilise par les FAI ADSL qui proposent des services de tlphonie,
probablement pour des raisons d'volutions improbables. C'est pourquoi cette technologie est cite ici
uniquement titre informatif, et ne sera pas dveloppe plus (se rfrer aux rfrences bibliographiques
pour plus de dtails, et notamment, celles de l'IEC).
On notera enfin que cette technologie reste cependant utilise par certains FAI amricains.
2.5 - Tlvision par ADSL
On peut trouver aujourd'hui de chane de tlvision en ligne. Ces chanes transmettent leurs programmes en
temps rel. C'est ce que l'on appelle du streaming accessible grce des logiciels particuliers (le plus souvent
Windows Media Player). Il s'agit alors d'un simple flux disponible sur son cran d'ordinateur. Avec de systme il
faut possder haut dbit constant pour assurer une bonne rception.
La tlvision par l'ADSL permet quand elle d'accder un bouquet de chane tlvis directement sur son poste
de tlvision.
2.5.1 - Fonctionnement
Sur le cble et le satellite toutes les chanes sont transmises aux abonns. C'est alors au dcodeur de faire le
tri. Le fonctionnement est diffrent par le ADSL. Le dbit sur la boucle locale tant limit, le DSLAM ne
transmet qu'une seule chane au domicile de l'abonn. Il n'est donc pas possible de regarder deux chanes
simultanment, ou d'enregistrer une chane sur son magntoscope pendant que vous en regardez une autre.
Lorsque l'utilisateur veut changer de chane, la set-top-box transmet la demande au DSLAM. Celui-ci la
charge de slectionner le bon flux. Mais le DSLAM non plus ne reoit pas toutes les chanes. Il ne reoit que
les chanes qu'il transmet ce moment ces abonns, et cela pour ne pas saturer le rseau.
Donc quand un abonn zappe, le DSLAM vrifie s'il ne reoit pas dj la chane dsire. Ce serait le cas s'il la
transmet un autre abonn. Si c'est la cas il duplique le flux pour l'envoyer aux diffrents abonns. Dans le
cas contraire il doit aller le rechercher la tte du rseau. Cela peut entraner un dlai lors du changement
de chane.
La set-top-box reoit enfin le flux vido. Il se charge de le sparer des autres flux ventuellement reus
(Internet ou tlphonie). Puis le dcodeur numrique traduit le signal la vole. Il envoie ce signal la
tlvision (ou magntoscope ...).
Avant de dlivrer des programmes payant le DSLAM consulte le serveur de gestion des droits d'accs situ
sur le centre de diffusion, pour vrifier que le client a bien souscrit l'abonnement correspondant.
2.5.2 - Bande passante et encodage
La tlvision est le service le plus critique en matire de bande passante pour les offres Triple play de l'ADSL.
En effet elle est gourmande en bande passante, et requiert un dbit garanti pour une bonne visualisation. Il
faut donc trouver un compromis entre qualit de l'image et contraintes dues au dbit.
Ainsi les oprateurs rservent environ 4 5 Mbps de bande passante pour le flux vido, mme si le support
est utilis en mme temps pour d'autre technologie (Internet, tlphonie ..). Cette bande passante alloue
la tlvision sur ADSL devrait ainsi permettre d'obtenir une qualit d'images trs correcte.
Le type d'encodage retenue est gnralement le MPEG2. Il permet de diffuser le flux vido dans la bande
passante rserv, tout en conservant une bonne qualit d'image. Une compression trop importante pourrait
bien sur entraner une perte de qualit d'image ou de fluidit. Ce taux de compression et le dbit garanti de
3,5 4 Mbps permettent d'attendre une dfinition de 576;480 points.
Le passage en MPEG4 est aujourd'hui envisag. Cela permettrai d'obtenir une meilleure qualit dans un
bande passante diminu de moiti. Les FAI pourrait alors envisag de permettre l'abonn de recevoir deux
chanes simultanment.
Les fournisseurs de contenu (TPS, Canal Satellite ou autres) livrent leurs contenues en direct au FAI. Ceux-ci
encodent en direct ces flux audio-vido en MPEG2. C'est une partie dlicate qui peut tre l'origine d'une
grande perte de qualit. Mais cet encodage est indispensable pour ramener le flux numrique des
dimensions permettant la transmission via l'ADSL. Une fois cet encodage ralis, le flux peut tre envoy sur
le rseau.
2.5.3 - Vido la demande
Le service VOD (Video On Demande) propos par les FAI permet un utilisateur de louer une vido sans
bouger de chez lui, et de la visionn partir de son cran de tlvision. L'utilisation est trs simple pour
l'abonn .Il peut de slectionner dans un catalogue les films, documentaires ou archives tlvisuels que lui
propose son FAI. Il utilise pour cela son quipement, connexion et settop-box. Il effectue son choix sur sa
tlvision grce la tlcommande de sa set-top-box. Il peut ainsi slectionner une vido et la visionner
moyennant finance.
Le FAI Propose ses abonns une srie de vido. Ces vidos sont dtenus par des fournisseurs de contenus,
les socits grant les droits de ces vidos. Ce sont eux qui sont chargs de la compression des vido. Cet
encodage est ralis en MPEG2 ou MPEG4. Ils peuvent galement raliser une encryption du flux vido, afin
de protger les vidos contre la copie. Le plus utilis pour ralis cet encryption est la technologie DRM, Data
Rigth Management, de Microsoft. Les fichiers diffuss sont alors crypts avant leur diffusion sur Internet. Le
client doit possder une cl, ou licence, pour le lire. Cette cl est unique et dfinit l'usage que faire de cette
vido l'utilisateur et notamment le nombre de lecture et la dure de validit.
Une fois ces oprations effectues, le FAI se charge de l'acheminement de ces flux de donns vers l'abonn.
Grce la technologie Multicast le fournisseur peut allger la charge de transmission sur le rseau. Il
installera partout sur son rseau des serveurs vido relais. Ce sont des ordinateurs dots de trs grandes
capacits de stockage et d'interfaces trs rapides. Ils peuvent envoyer simultanment plusieurs instance
d'une mme vido vers diffrents abonns.
D'aprs le dbit de la ligne deux techniques peuvent tre utilis par les FAI. Si le dbit vers l'abonn est
suffisant la vido peut tre envoye en streaming au dcodeur. Le client peut donc lire la vido en simultan.
Si le dbit est insuffisant le FAI proposera certain film pralablement envoy sur le disque dur de l'abonn. Le
fait que les vidos soient crypts empche l'abonn de raliser des copies de ces vidos.
Au dbut de la sance le client effectue le rglement. Il reoit alors une cl de dcodage lui permettant de
visualiser le film.
Les modems cbles sont bidirectionnelles et permettent l'envoie et la rception de donnes IP en mme temps. Ce
modems peuvent atteindre des vitesse de 43 Mbps en montant et 10 Mbps en descendant. Ils utilisent pour cela
des techniques QAM (Quadrature Amplitude Modulation) ou PSK (Phase Shift Keying).
Le modem cble sert donc de convertisseur de modulation entre rseaux cbls et rseau Ethernet. Les donnes
sont transmises sur des frquences du rseau cbl diffrentes de celles utilises par la TV. Pour transmettre la
voix
les
oprateurs
ont
choisi
de
s'appuyer
sur
les
technologies
existantes.
C'est
donc via la voix sur IP que s'est implant la tlphonie chez les cablo-oprateur.
Les tlphones IP, les fax, les ordinateurs et les tlviseurs sont relis a au modem cble via un bus Ethernet. Un
couche application DOCSIS permet de relier le rseau HFC un rseau IP via le Headend ou CMTS (Cable Modem
Termination System). C'est l'quipement de tte de rseau. Il est situ dans la station locale et connecte
l'ensemble des abonns de la zone. Il va donc convertir les donnes du rseau IP en en signal radio frquence
pour les transmettre sur le rseau HFC. Il va galement procder l'opration inverse. Il permet ainsi de faire
communiquer le rseau HFC avec d'autres rseaux comme Internet ou le rseau CATV analogique. Le CMTS est
l'quivalent du DSLAM pour les technologies xDSL.
Typiquement pour les consommateurs domestiques la vitesse du flux de donnes avales est limite entre 512
kbit/s 10 Mbit/s, et le flux amont entre 256 kbit/s et 1 Mbit/s. Il faut distinguer trois types de communication
qui se propagent sur un rseau cbl :
Les bandes passantes Upstream Return et Downstream Interactive sont rparties par le CMTS pour les diffrents
abonns.
3.4 - DVB/DAVIC
La technologie de Digital Video Broadcast (DVB) et de Digital Audio Video Council (DAVIC) reprsente le standard
europen pour la tlvision numrique. Elles prsentent l'interet d'tre conforme aux directives et normes
europennes.
La spcification DVD 2,0 appel galement DVD-RCC (Return Channel for Cable) est standardis sous la
dnomination ETSS 200800. Le standard s'appuie sur une couche ATM utilisant LLC/SNAP (RFC 1483) et une
couche d'adaptation AAL5 pour encapsuler les paquet IP (IP switching permettant un routage IP sur un
commutateur ATM). Pour la communication entre le terminal abonn (STM) et les quipements de la station locale
(TDR), il utilise le protocole de signalisation ATM ou alors un proxy avec DSMCC.
3.5 - DOCSIS et PacketCable
Le consortium CableLabs a t cr en mai 1988 et regroupe des oprateurs, acteurs ou industriels de la
tlvision par cble. Il a tabli plusieurs spcifications pour le transport de paquet IP : DOCSIS et PacketCable.
Le standard amricain DOCSIS (Data Over Cable Service Interface Specification) dfinit les exigences relatives
aux interfaces des modems cbles utiliss pour la diffusion de donnes grandes vitesse par tlrseau.
En mars 1998 l'ITU (Union Internationale des Tlcommunications) accepte DOCSIS comme standard pour les
modems cbles sous l'appellation ITU J,112 ou DOCSIS 1.0. Pour dlivrer les services de donnes DOCSIS sur un
rseau cbl, un canal de frquence radio de 6MHz dans la bande de frquence 50-750 MHz est allou pour le
trafic descendant et un autre canal de 6 Mhz dans la bande de frquence 5-42MHz pour le trafic montant.
Un quipement de tte de rseau CMTS communique travers ces canaux avec les modems cbles situs chez
l'abonn. Ce sont des quipement externes qui se connectent aux ordinateurs par l'intermdiaire d'une carte
Ethernet ou d'une interface USB.
DOCSIS emploie la mthode TDMA(Time Division Multiple Access)/SCDMA(Synchronous Code Division Multiple
Access). Cette mthode d'accs diffre du systme d' Ethernet, car le systme DOCSIS n'prouve aucune
collision.
La phase d'initialisation logicielle en DOCSIS est gnralement la suivante (fortement simplifie) :
Le modem envoie une requte DHCP de faon a connaitre la configuration rseau utiliser.
Le CMTS renvoie son adresse IP locale (a ne pas confondre avec l'adresse IP de l'ordinateur sur
Internet), sa passerelle, et plus spcifiquement l'adresse IP du serveur TFTP et le nom du fichier de
configuration a aller y chercher.
Le modem se connecte au serveur TFTP et demande le fichier de configuration nomm prcdemment.
Ce fichier contient entre autre les informations relative a la vitesse de connexion du modem, sa priorit
sur le rseau, et le nombre d'ordinateurs autoriss a accder au modem en mme temps.
Le modem informe le CMTS qu'il a bien reu le fichier, et qu'il est prt a oprer (phase de
synchronisation).
Aprs ceci, le ou les ordinateurs branchs au modem peuvent eux-mme demander leurs informations de
connexion via le DHCP, et agir comme sur un rseau local tout a fait conventionnel.
En avril 1999 CableLabs a crit une nouvelle spcification : DOCSIS 1.1. Elle ajoute quelques lments cls par
rapport au standard d'origine : qualit suprieurs, systmes de scurit, gestion priorit des paquets destins aux
communications vocales ... L'objectif est de supporter la tlphonie et les autres services temps rel.
Enfin en fvrier 2002 arrive DOCSIS 2.0. Cette nouvelle norme apporte une symtrie de la bande passante entre
les voies montantes et descendantes. Cette volution est due l'volution de l'utilisation d'Internet par les
internautes avec les l'avnement du peer-to-peer, de la voix sur IP, de la vido-confrence ...
La version europenne de DOCSIS s'appelle EuroDOCSIS. La diffrence principale est que les canaux de cble en
Europe sont de 8 MHz de large (PAL), tandis qu'en Amrique du Nord les canaux sont de 6 MHz de large (NTSC).
Ceci permet d'assigner plus de largeurs de bande la circulation de donnes aval. Il existe galement un DOCSIS
spcifique pour le Japon.
Le projet PacketCable a pour ambition d'implanter des services audio et vido IP sur le cble. Ces services
incluent TV, tlphonie, vido-confrence, unifies sur la couche rseau IP. Ce projet s'appuie sur plusieurs
protocole. Il utilise DOCSIS 1.1 pour le transport des donnes sur le rseau cbl. IPsec doit assurer la scurit
des donns en dehors du rseau cbl. H.263 pour la compression vido et G.711, G.726 et G.729 pour la
compression audio. Enfin pour la gestion centralise de la signalisation tlphonique inter-rseau CableLabs utilise
MGCP. MGCP (Medio Gateway Control Protocol) permet d'assurer la signalisation des services de tlphonie sur les
rseaux cbls.
90 % des franais sont abonns aux fournisseurs tlphoniques utilisant l'ADSL. En faisant une comparaison des
diffrentes offres, nous trouvons une offre moyenne pour l'ADSL correspondant 16Megabit par seconde avec un cot
d'environ 30 euro par mois.
En ce qui concerne les offres passant par le cble, les offres des deux fournisseurs taient pendant longtemps trs
ressemblantes, mais UPC-Noos depuis peu augment le dbit de 4Mgabit 10Megabit. Nous avons une offre
moyenne de 7Megabit par seconde de dbit avec un cot d'environ 60 euros par mois.
Nous voyons que les offres ADSL proposent un dbit plus lev avec un cot infrieur par rapport aux fournisseurs
cble. Mais les facteurs de choix ne s'arrtent pas la. Le dbit de l'Internet pour les clients ADSL peut changer dans le
cas ou ils regardent la tlvision, alors que le dbit Internet des offres cble est fixe. Il faut galement prendre en
compte l'offre et le dbit des diffrents fournisseurs proposs selon le lieu d'habitation, ce qui varie beaucoup d'une
localisation une autre.
5 - Evolution
Un des grandes volutions de ces dernires annes est la fusion des technologies telecoms avec celle de l'Internet dans
des offres dites convergentes. En d'autre terme, cela signifie pour le client une facturation unique, et la possibilit de
retrouver les mmes services chez lui mais aussi en mobilit (vido, musique, communication...)
Depuis le dbut de l'anne 2005, les offres de convergence se multiplient en Europe et dans le monde. Ces offres sont
bases sur diffrentes technologies, principalement sur Cell-ID (France, Suisse, Allemagne) et UMA (Angleterre, Sude
et Finlande). NTT DoCoMo, oprateur mobile au Japon, a lanc une offre entreprise permettant ses clients d'utiliser
de la VoIP grce un terminal bi-mode Wi-Fi.
La technologie Cell-ID permet un oprateur mobile de localiser un client (prcision de la cellule GSM). Cette
information est utilise pour une facturation diffrencie. Cette solution qui est "pur mobile" souffre d'un manque de
prcision en milieu urbain et de cots importants de dveloppements. Elle ne rpond pas aux attentes en termes
d'intgration et de haut dbit mais permet de rpondre aux attentes clients concernant des offres d'abondance
domestique. C'est pourquoi on continu chercher d'autres solutions de convergence.
Afin d'adapter ces nouvelles technologies, il est ncessaire de faire voluer les technologies de rseau sans fil comme
le Wi-Fi ou le WiMAX aux tlphones mobiles.
5.1 - WiMax
Le WiMAX (Worldwide Interoperability for Microwave Access) est l'volution du Wi-Fi. Cette norme est base sur le
standard de transmission radio 802.16. Elle a t valide en 2001 par l'organisme international de normalisation
IEEE (Institute of Electrical and Elecronic Engeneers), et fut pousse par un consortium d'une cinquantaine de
membres, dont Intel, Nokia, Fujitsu, Cisco, Atmel, Siemens, Motorola, Alcatel, France Telecom, etc.
WiMAX est une rponse pour des connexions sans-fil haut dbit. Elle porte sur des zones de couvertures de
plusieurs kilomtres, permettant des usages en situation fixe ou mobile. Avec sa couverture de rseau de 20 km
et le dbit de 70 Mbit/s, il est par la suite envisageable de fournir un accs haut dbit aux endroits ruraux n'ayant
pas l'ADSL ni le cble.
Il y a trs peu de temps, le 12 dcembre 2005, l'organisme IEEE a standardis la variante mobile de la
technologie WiMAX, le WiMAX mobile. Elle a un dbit de 30 Megabit/seconde avec une porte de 3-4 kilomtres,
ce qui est largement plus que les rseaux tlphonique. Le G3 peut actuellement transiter entre 400 et 700
Kilobit/seconde et par utilisateur. C'est la concurrent direct du rseau tlphonique.
Pour le moment les composants compatibles avec le WiMAX mobile commencent tout juste tre fabriqus. On
estime la sortie en masse des ces composants en 2008. Avec cette technologie on pourrait peut tre un jour
remplacer le rseau mobile actuel, condition d'avoir une couverture total du pays.
Les licences d'exploitation du WiMAX sont aujourd'hui en cours d'attribution au niveau rgional, sachant que seuls
2 oprateurs pourront se partager une rgion. C'est l'ARCEP (Autorit de Rgulation des Communications
Electroniques et des Postes), anciennement ART (Autorit de Rgulation des Tlcoms), qui a pour charge de
dterminer les ayant droits.
Il existe aussi une seule licence d'exploitation nationale qui a t attribue la socit Altitude Telecom
(rcemment renomme IFW suite son acquisition par le FAI Free) qui aurait dj commenc dployer son
rseau WiMAX avec des quipements 802.16e ready .
Une Autre volution se fait au niveau des services proposs par le Triple play. Il existe aujourd'hui plusieurs
concepts et technologies en cours de dveloppement par les diffrents fournisseurs. Afin de gagner des parts du
march, ils proposent des services et des fonctionnalits supplmentaires. Une des services qui est en plein essor
est le Quadruple play. Le Quadruple play est un Triple play auquel on ajoute de la tlphonie mobile.
Ds qu'on entre dans la zone du STB de la maison ou du bureau, la communication mobile passe par le rseau
haut dbit via de la VoIP. Pour que cela fonctionne, il faut avoir des oprateurs qui proposent cette fonctionnalit,
ainsi que des tlphones mobiles compatibles.
Grce au dveloppement des technologies sans fil, le Wi-Fi et le WiMAX, ainsi que des tlphones compatibles WiFi via la VoIP, le Quadruple play sera envisageable. La plupart des tlphones mobiles en construction intgrent le
support de la VoIP. Aujourd'hui il y a un certain nombre de tlphones sortis avec le support de la VoIP. Il y a
notamment Skype qui prsente, en partenariat avec Netgear, le premier tlphone Skype Wi-Fi VoIP. Il y a
galement Senao, socit tawanaise, qui propose un tlphone Wi-Fi 802.11b/g pour la VoIP. Un autre exemple
est NTT DoCoMo, oprateur mobile au Japon, qui introduit son tlphone 3G/Wi-Fi.
En ce qui concerne les fournisseurs d'accs, ils sont un pas en avance. Il y a, pour le moment, dj deux
fournisseurs proposant le concept du Quadruple play, mais les autres ne tarderont pas suivre. Nous faisons par
la suite une brve explications de ces deux offres.
5.2 - UMA (Unlicensed Mobile Acces)
Le tlphone compatible avec la technologie UMA utilise un accs haut dbit sans fil la maison ou au bureau.
Puis il bascule, sans interruption de service, sur le rseau mobile l'extrieur et en mobilit. L'utilisation du
rseau fixe ou mobile devient transparente pour l'utilisateur. Ce dernier pourrait alors utiliser un seul tlphone et
un seul numro au lieu d'avoir un numro fixe et un deuxime pour le tlphone mobile.
Le protocole dont se sert l'UMA permet d'utiliser des services concernant les tlphones mobiles tel que GSM et
GPRS, travers des technologies comme le Bluetooth et le Wi-Fi (802.11b/g). Il est galement compatible avec
les rseaux IP sans fil comme les rseaux WiMAX.
Le fonctionnement de cette technologie est relativement simple. Ds qu'un tlphone mobile UMA entre dans la
zone de couverture d'un point d'accs Wi-Fi ou Bluetooth, il peut recevoir et tablir une communication par paquet
IP. Ces paquets sont alors transmis jusqu'au contrleur UMA grce au rseau IP de la maison ou de l'entreprise.
Ce contrleur envoie les donnes ncessaires vers le rseau de l'oprateur mobile. Il authentifie de cette mme
manire l'utilisateur avant sa connexion au rseau cellulaire.
Une fois que cette technologie sera sortie de la phase tests, elle sera intgre la Livebox afin d'offrir le
Quadruple play aux clients de Wanadoo.
Le deuxime fournisseur proposant le Quadruple play est Neuf Tlcom. Il propose le Beautiful Phone . C'est un
tlphone de nouvelle gnration qui permet lui aussi de tlphoner en Wi-Fi la maison grce la Neufbox, et
de basculer vers une connexion GSM l'extrieur, en utilisant le rseau de l'oprateur SFR. Actuellement le
Beautiful Phone est en cours de tests par des clients volontaires. Aprs cette priode d'essais le fournisseur
devrait ajouter la tlphonie mobile ses offres, et le Triple play se transformera en Quadruple play.
Avec ces nouvelles technologies qui ne cessent d'voluer, utilisant de plus en plus de bande passante, le dbit doit
galement suivre. A la suite de ADSL 2+, voici maintenant le VDSL (Very High Rate Digital Subscriber line). Base
sur la mme technologie que l'xDSL, les signaux VDSL sont transports sur une paire de cuivre, simultanment et
sans interfrence avec la voix tlphonique. Cette technologie permet d'atteindre de trs hauts dbits. VDSL
promet un dbit vers l'internaute atteignant 50 Mbit/s, et depuis l'abonn vers Internet de l'ordre de 3 Mbit/s.
L'volution de cette technologie, le VDSL 2, peut mme fonctionner jusqu' 100 Mbit/s dans les deux sens (en
thorie).
Cette technologie utilise une bande de frquences allant jusqu' 12 MHz en VDSL 1 et 30 MHz pour le VDSL 2,
tandis que l'ADSL 2+ utilise une bande de frquences de 2,2 MHz. La plage de frquences tant plus large et la
consommation d'nergie plus importante, les oprateurs doivent adapter leurs quipements rseaux. Alors qu'une
carte ADSL 2+, insre dans un multiplexeur d'accs pour lignes d'abonns numriques (DSLAM), peut desservir
jusqu' 72 clients, une carte VDSL n'accepterait pas plus de 24 clients pour l'instant. Club Internet est l'un des
rares FAI disposer dj de DSLAM quips aussi bien de cartes ADSL 2+ que VDSL. L'objectif est de fournir des
dbits en VDSL aux abonns situs 1500 m du rpartiteur et de l'ADSL 2+ aux personnes rsidant plus de 1,5
km.
Une autre technologie en cours de dveloppement est la FTTH (Fiber To The Home) ; la fibre optique la
maison/immeuble. Elle permet l'accs Internet des dbits atteignant souvent 100 Mbit/s. Comparable au cble
dans son installation, puisqu'elle ncessite la pose de fibres jusque chez l'abonn, la FTTH est principalement
utilis dans les zones urbanises de la Core du Sud, du Japon et des Etats-Unis, ainsi que dans quelques
agglomrations europennes. Elle est cependant en phase de tests dans certaines grandes villes franaises (telles
Lyon ou Paris), par diffrentes socits (Cite Fibre, France Tlcom, etc.).
6 - Conclusion
Les grands axes de convergence technologique s'effectuent principalement entre le monde des tlcommunications et
celui de l'informatique. Cela se voit notamment avec l'arrive de solutions concernant la tlphonie sur IP. La
convergence des oprateurs de tlcommunication avec les FAI, s'effectue entre le tlphone fixe, le mobile, l'Internet
ainsi que la tlvision travers les offres Quadruple play. L'objectif principale de la tlphonie sur IP est de rduire les
cots de fonctionnement. En effet, avec cette offre, l'utilisateur n'est plus dpendant de l'oprateur tlphonique pour
des appels internes. On diminue de mme les frais sur les appels longue distance en passant par le rseau IP.
Afin de garder leur clientle, et de gagner plus de part du march, les FAI et les cblo-oprateurs ne cessent pas de
dvelopper des services supplmentaires. En parallle avec le Quadruple play, on parle galement de Quintuple play.
Ce dernier prsente diffrents services selon le fournisseur. Le cinquime service peut tre: le jeu en ligne, des
services travers le rseau Wi-Fi ou bien le CPL (Courant Porteur en Ligne).
Demain, notre tlphone mobile basculera de manire automatique, en fonction du lieu d'utilisation et sans que nous le
sachions, sur les modes de tlcommunications les plus adapts, comme le Wi-Fi et le WiMAX.
Les IpVpn
1 - Introduction
2 - Principe de fonctionnement
2.1 - Principe gnral
2.2 - Fonctionnalits des Vpn
2.2.1 - Le Vpn d'accs
2.2.2 - L'intranet Vpn
2.2.3 - L'extranet Vpn
2.2.4 - Bilan des caractristiques fondamentales d'un Vpn
3 - Protocoles utiliss pour raliser une connexion Vpn
3.1 - Rappels sur Ppp
3.1.1 - Gnralits
3.1.2 - Format d'une trame Ppp
3.1.3 - Les diffrentes phases d'une connexion Ppp
3.2 - Le protocole Pptp
3.3 - Le protocole L2tp
3.3.1 - Concentrateurs d'accs L2tp (Lac : L2tp Access Concentrator)
3.3.2 - Serveur rseau L2tp (Lns : L2tp Network Server)
3.4 - Le protocole Ipsec
3.4.1 - Vue d'ensemble
3.4.2 - Principe de fonctionnement
3.4.3 - Le protocole Ah (Authentication Header)
3.4.4 - Protocole Esp (Encapsulating Security Payload)
3.4.5 - La gestion des clefs pour Ipsec : Isakmp et Ike
3.4.6 - Les deux modes de fonctionnement de Ipsec
3.5 - Le protocole Mpls
3.5.1 - Principe de fonctionnement de Mpls
3.5.2 - Utilisation du Mpls pour les Vpn
3.5.3 - Scurit
3.6 - Le protocole Ssl
3.6.1 - Fonctionnement
4 - Comparaison des diffrents protocoles
4.1 - Vpn-Ssl, une nouveaut marketing ?
4.2 - Pptp
4.3 - L2tp / Ipsec
4.4 - Mpls
4.5 - Mpls / Ipsec
5 - Conclusion
6 - Discussion autour de la documentation
7 - Suivi du document
1 - Introduction
Les applications et les systmes distribus font de plus en plus partie intgrante du paysage d'un grand nombre
d'entreprises. Ces technologies ont pu se dvelopper grce aux performances toujours plus importantes des rseaux
locaux. Mais le succs de ces applications a fait aussi apparatre un de leur cueil. En effet si les applications
distribues deviennent le principal outil du systme d'information de l'entreprise, comment assurer leur accs scuris
au sein de structures parfois rparties sur de grandes distances gographiques ? Concrtement comment une
succursale d'une entreprise peut-elle accder aux donnes situes sur un serveur de la maison mre distant de
plusieurs milliers de kilomtres ? Les Vpn ont commenc tre mis en place pour rpondre Ce type de
problmatique. Mais d'autres problmatiques sont apparues et les Vpn ont aujourd'hui pris une place importante dans
les rseaux informatique et l'informatique distribues. Nous verrons ici quelles sont les principales caractristiques des
Vpn travers un certain nombre d'utilisation type. Nous nous intresserons ensuite aux protocoles permettant leur
mise en place.
2 - Principe de fonctionnement
Le Vpn d'accs est utilis pour permettre des utilisateurs itinrants d'accder au rseau priv. L'utilisateur
se sert d'une connexion Internet pour tablir la connexion Vpn. Il existe deux cas:
L'utilisateur demande au fournisseur d'accs de lui tablir une connexion crypte vers le serveur
distant : il communique avec le Nas (Network Access Server) du fournisseur d'accs et c'est le Nas qui
tablit la connexion crypte.
L'utilisateur possde son propre logiciel client pour le Vpn auquel cas il tablit directement la
communication de manire crypte vers le rseau de l'entreprise.
Les deux mthodes possdent chacune leurs avantages et leurs inconvnients :
La premire permet l'utilisateur de communiquer sur plusieurs rseaux en crant plusieurs tunnels,
mais ncessite un fournisseur d'accs proposant un Nas compatible avec la solution Vpn choisie par
l'entreprise. De plus, la demande de connexion par le Nas n'est pas crypte Ce qui peut poser des
problmes de scurit.
Sur la deuxime mthode Ce problme disparat puisque l'intgralit des informations sera crypte
ds l'tablissement de la connexion. Par contre, cette solution ncessite que chaque client transporte
avec lui le logiciel, lui permettant d'tablir une communication crypte. Nous verrons que pour pallier
Ce problme certaines entreprises mettent en place des Vpn base de Ssl, technologie implmente
dans la majorit des navigateurs Internet du march.
Quelle que soit la mthode de connexion choisie, Ce type d'utilisation montre bien l'importance dans le Vpn
d'avoir une authentification forte des utilisateurs. Cette authentification peut se faire par une vrification
"login / mot de passe", par un algorithme dit "Tokens scuriss" (utilisation de mots de passe alatoires) ou
par certificats numriques.
L'intranet Vpn est utilis pour relier au moins deux intranets entre eux. Ce type de rseau est
particulirement utile au sein d'une entreprise possdant plusieurs sites distants. Le plus important dans Ce
type de rseau est de garantir la scurit et l'intgrit des donnes. Certaines donnes trs sensibles
peuvent tre amenes transiter sur le Vpn (base de donnes clients, informations financires...). Des
techniques de cryptographie sont mises en oeuvre pour vrifier que les donnes n'ont pas t altres. Il
s'agit d'une authentification au niveau paquet pour assurer la validit des donnes, de l'identification de leur
source ainsi que leur non-rpudiation. La plupart des algorithmes utiliss font appel des signatures
numriques qui sont ajoutes aux paquets. La confidentialit des donnes est, elle aussi, base sur des
algorithmes de cryptographie. La technologie en la matire est suffisamment avance pour permettre une
scurit quasi parfaite. Le cot matriel des quipements de cryptage et dcryptage ainsi que les limites
lgales interdisent l'utilisation d'un codage " infaillible ". Gnralement pour la confidentialit, le codage en
lui-mme pourra tre moyen faible, mais sera combin avec d'autres techniques comme l'encapsulation Ip
dans Ip pour assurer une scurit raisonnable.
2.2.3 - L'extranet Vpn
Une entreprise peut utiliser le Vpn pour communiquer avec ses clients et ses partenaires. Elle ouvre alors son
rseau local ces derniers. Dans Ce cadre, il est fondamental que l'administrateur du Vpn puisse tracer les
clients sur le rseau et grer les droits de chacun sur celui-ci.
2.2.4 - Bilan des caractristiques fondamentales d'un Vpn
Un systme de Vpn doit pouvoir mettre en oeuvre les fonctionnalits suivantes :
Authentification d'utilisateur. Seuls les utilisateurs autoriss doivent pouvoir s'identifier sur le rseau
virtuel. De plus, un historique des connexions et des actions effectues sur le rseau doit tre
conserv.
Gestion d'adresses. Chaque client sur le rseau doit avoir une adresse prive. Cette adresse prive
doit rester confidentielle. Un nouveau client doit pourvoir se connecter facilement au rseau et
recevoir une adresse.
Cryptage des donnes. Lors de leurs transports sur le rseau public les donnes doivent tre
protges par un cryptage efficace.
Gestion de cls. Les cls de cryptage pour le client et le serveur doivent pouvoir tre gnres et
rgnres.
Prise en charge multiprotocole. La solution Vpn doit supporter les protocoles les plus utiliss sur les
rseaux publics en particulier Ip.
Le Vpn est un principe : il ne dcrit pas l'implmentation effective de ces caractristiques. C'est pourquoi il
existe plusieurs produits diffrents sur le march dont certains sont devenus standard, et mme considrs
comme des normes.
Fanion - Sparateur de trame gale la valeur 01111110. Un seul drapeau est ncessaire entre 2 trames.
Adresse - Ppp ne permet pas un adressage individuel des stations donc Ce champ doit tre 0xFF (toutes les
stations).
Toute
adresse
non
reconnue
entranera
la
destruction
de
la
trame.
Contrle
Le
champ
contrle
doit
tre
0x03
Protocole - La valeur contenue dans Ce champ doit tre impaire (l'octet de poids fort tant pair). Ce champ
identifie le protocole encapsul dans le champ informations de la trame. Les diffrentes valeurs utilisables
sont dfinies dans la Rfc assign number et reprsentent les diffrents protocoles supports par Ppp (Osi,
Ip,
Decnet
IV,
Ipx...),
les
Ncp
associs
ainsi
que
les
Lcp.
Donnes - De longueur comprise entre 0 et 1500 octets, Ce champ contient le datagramme du protocole
suprieur indiqu dans le champ "protocole". Sa longueur est dtecte par le drapeau de fin de trame, moins
deux
octets
de
contrle.
Fcs (Frame Check Sequence) - Ce champ contient la valeur du checksum de la trame. Ppp vrifie le contenu
du Fcs lorsqu'il reoit un paquet. Le contrle d'erreur appliqu par Ppp est conforme X25.
3.1.3 - Les diffrentes phases d'une connexion Ppp
Toute connexion Ppp commence et finit par une phase dite de "liaison morte". Ds qu'un vnement externe
indique que la couche physique est prte, la connexion passe la phase suivante, savoir l'tablissement de
la liaison. Comme Ppp doit tre support par un grand nombre d'environnements, un protocole spcifique a
t labor et intgr Ppp pour toute la phase de connexion ; il s'agit de Lcp (Link Control Protocol). Lcp
est un protocole utilis pour tablir, configurer, tester, et terminer la connexion Ppp. Il permet de manipuler
des tailles variables de paquets et effectue un certain nombre de tests sur la configuration. Il permet
notamment
de
dtecter
un
lien
boucl
sur
lui-mme.
La connexion Ppp passe ensuite une phase d'authentification. Cette tape est facultative et doit tre
spcifie
lors
de
la
phase
prcdente.
Si l'authentification russie ou qu'elle n'a pas t demande, la connexion passe en phase de "Protocole
rseau". C'est lors de cette tape que les diffrents protocoles rseaux sont configurs. Cette configuration
s'effectue sparment pour chaque protocole rseau. Elle est assure par le protocole de contrle de rseau
(Ncp) appropri. A Ce moment, le transfert des donnes est possible. Les NPC peuvent tout moment ouvrir
ou fermer une connexion. Ppp peut terminer une liaison tout moment, parce qu'une authentification a
choue, que la qualit de la ligne est mauvaise ou pour toute autre raison. C'est le Lcp qui assure la
fermeture de la liaison l'aide de paquets de terminaison. Les Ncp sont alors informs par Ppp de la
fermeture de la liaison.
3.2 - Le protocole Pptp
Pptp, dfinit par la Rfc 2637, est un protocole qui utilise une connexion Ppp travers un rseau Ip en crant un
rseau priv virtuel (Vpn). Microsoft a implment ses propres algorithmes afin de l'intgrer dans ses versions de
windows. Ainsi, Pptp est une solution trs employe dans les produits Vpn commerciaux cause de son
intgration au sein des systmes d'exploitation Windows. Pptp est un protocole de niveau 2 qui permet
l'encryptage des donnes ainsi que leur compression. L'authentification se fait grce au protocole Ms-Chap de
Microsoft qui, aprs la cryptanalyse de sa version 1, a rvl publiquement des failles importantes. Microsoft a
corrig ces dfaillances et propose aujourd'hui une version 2 de Ms-Chap plus sre. La partie chiffrement des
donnes
s'effectue
grce
au
protocole
Mppe
(Microsoft
Point-to-Point
Encryption).
Le principe du protocole Pptp est de crer des paquets sous le protocole Ppp et de les encapsuler dans des
datagrammes IP. Pptp cre ainsi un tunnel de niveau 3 dfini par le protocole Gre (Generic Routing
Encapsulation). Le tunnel Pptp se caractrise par une initialisation du client, une connexion de contrle entre le
client et le serveur ainsi que par la clture du tunnel par le serveur. Lors de l'tablissement de la connexion, le
client effectue d'abord une connexion avec son fournisseur d'accs Internet. Cette premire connexion tablie une
connexion de type Ppp et permet de faire circuler des donnes sur Internet. Par la suite, une deuxime connexion
dial-up est tablie. Elle permet d'encapsuler les paquets Ppp dans des datagrammes IP. C'est cette deuxime
connexion qui forme le tunnel Pptp. Tout trafic client conu pour Internet emprunte la connexion physique
normale, alors que le trafic conu pour le rseau priv distant, passe par la connexion virtuelle de Pptp.
Plusieurs protocoles peuvent tre associs Pptp afin de scuriser les donnes ou de les compresser. On retrouve
videment les protocoles dvelopps par Microsoft et cits prcdemment. Ainsi, pour le processus
d'identification, il est possible d'utiliser les protocoles Pap (Password Authentification Protocol) ou MsChap. Pour
l'encryptage des donnes, il est possible d'utiliser les fonctions de Mppe (Microsoft Point to Point Encryption).
Enfin, une compression de bout en bout peut tre ralise par Mppc (Microsoft Point to Point Compression). Ces
divers protocoles permettent de raliser une connexion Vpn complte, mais les protocoles suivants permettent un
niveau de performance et de fiabilit bien meilleur.
3.3 - Le protocole L2tp
L2tp, dfinit par la Rfc 2661, est issu de la convergence des protocoles Pptp et L2F. Il est actuellement dvelopp
et valu conjointement par Cisco Systems, Microsoft, Ascend, 3Com ainsi que d'autres acteurs cls du march
des rseaux. Il permet l'encapsulation des paquets Ppp au niveau des couches 2 (Frame Relay et Atm) et 3 (Ip).
Lorsqu'il est configur pour transporter les donnes sur IP, L2tp peut tre utilis pour faire du tunnelling sur
Internet. L2tp repose sur deux concepts : les concentrateurs d'accs L2tp (Lac : L2tp Access Concentrator) et les
serveurs rseau L2tp (Lns : L2tp Network Server). L2tp n'intgre pas directement de protocole pour le chiffrement
des
donnes.
C'est
pourquoi
L'IETF
prconise
l'utilisation
conjointe
d'Ipsec
et
L2tp.
une
communication
donne.
Une SA est unidirectionnelle ; en consquence, protger les deux sens d'une communication classique
requiert deux associations, une dans chaque sens. Les services de scurit sont fournis par l'utilisation soit
de AH soit de Esp. Si AH et Esp sont tout deux appliqus au trafic en question, deux SA (voire plus) sont
cres
;
on
parle
alors
de
paquet
(bundle)
de
SA.
Chaque association est identifie de manire unique l'aide d'un triplet compos de:
L'adresse de destination des paquets,
L'identifiant du protocole de scurit utilis (AH ou Esp),
Un index des paramtres de scurit (Security Parameter Index, SPI). Un SPI est un bloc de 32 bits
inscrit en clair dans l'en-tte de chaque paquet chang ; il est choisi par le rcepteur.
Pour grer les associations de scurits actives, on utilise une "base de donnes des associations de scurit"
(Security Association Database, SAD). Elle contient tous les paramtres relatifs chaque SA et sera
consulte
pour
savoir
comment
traiter
chaque
paquet
reu
ou
mettre.
Les protections offertes par Ipsec sont bases sur des choix dfinis dans une "base de donnes de politique
de scurit" (Security Policy Database, SPD). Cette base de donnes est tablie et maintenue par un
utilisateur, un administrateur systme ou une application mise en place par ceux-ci. Elle permet de dcider,
pour chaque paquet, s'il se verra apporter des services de scurit, s'il sera autoris passer ou rejet.
3.4.2 - Principe de fonctionnement
Le schma ci-dessous reprsente tous les lments prsents ci-dessus (en bleu), leurs positions et leurs
interactions.
Le champ bourrage peut tre ncessaire pour les algorithmes de chiffrement par blocs ou pour aligner le
texte
chiffr
sur
une
limite
de
4
octets.
Les
donnes
Voyons
d'authentification
maintenant
ne
comment
sont
est
prsentes
que
applique
si
la
Ce
service
confidentialit
slectionn.
dans
Esp.
L'expditeur :
Encapsule, dans le champ "charge utile" de Esp, les donnes transportes par le datagramme original
et ventuellement l'en-tte Ip (mode tunnel).
Phase
Main
Mode
et
Aggressive
Mode
Les attributs suivants sont utiliss par Ike et ngocis durant la phase 1 : un algorithme de chiffrement, une
fonction
de
hachage,
une
mthode
d'authentification et
un groupe
pour
Diffie-Hellman.
Trois clefs sont gnres l'issue de la phase 1 : une pour le chiffrement, une pour l'authentification et une
pour la drivation d'autres clefs. Ces clefs dpendent des cookies, des alas changs et des valeurs
publiques Diffie-Hellman ou du secret partag pralable. Leur calcul fait intervenir la fonction de hachage
choisie pour la SA Isakmp et dpend du mode d'authentification choisi. Les formules exactes sont dcrites
dans
la Rfc
2409.
b)
Phase
Quick
Mode
Les messages changs durant la phase 2 sont protgs en authenticit et en confidentialit grce aux
lments ngocis durant la phase 1. L'authenticit des messages est assure par l'ajout d'un bloc Hash
aprs l'en-tte Isakmp et la confidentialit est assure par le chiffrement de l'ensemble des blocs du
message.
Quick Mode est utilis pour la ngociation de SA pour des protocoles de scurit donns comme Ipsec.
Chaque ngociation aboutit en fait deux SA, une dans chaque sens de la communication.
Plus prcisment, les changes composant Ce mode ont le rle suivant :
Ngocier un ensemble de paramtres Ipsec (paquets de SA)
changer des nombres alatoires, utiliss pour gnrer une nouvelle clef qui drive du secret gnr
en phase 1 avec le protocole Diffie-Hellman. De faon optionnelle, il est possible d'avoir recours un
nouvel change Diffie-Hellman, afin d'accder la proprit de Perfect Forward Secrecy, qui n'est pas
fournie si on se contente de gnrer une nouvelle clef partir de l'ancienne et des alas.
Optionnellement, identifier le trafic que Ce paquet de SA protgera, au moyen de slecteurs (blocs
optionnels IDi et IDr ; en leur absence, les adresses Ip des interlocuteurs sont utilises).
c)
Les
groupes
New
Groupe
Mode
Le groupe utiliser pour Diffie-Hellman peut tre ngoci, par le biais du bloc SA, soit au cours du Main
Mode, soit ultrieurement par le biais du New Group Mode. Dans les deux cas, il existe deux faons de
dsigner le groupe utiliser :
Donner la rfrence d'un groupe prdfini : il en existe actuellement quatre, les quatre groupes
Oakley (deux groupes MODP et deux groupes EC2N).
Donner les caractristiques du groupe souhait : type de groupe (MODP, ECP, EC2N), nombre premier
ou polynme irrductible, gnrateurs...
d)
Au
Phases
final,
le
droulement
d'une
et
ngociation
IKE
suit
modes
le
diagramme
suivant
Les routeurs Mpls situs la priphrie du rseau (Edge Lsr), qui possdent la fois des interfaces Ip
traditionnelles et des interfaces connectes au backbone Mpls, sont chargs d'imposer ou de retirer les labels
des paquets Ip qui les traversent. Les routeurs d'entre, qui imposent les labels, sont appels Ingress Lsr,
tandis que les routeurs de sortie, qui retirent les labels, sont appels Egress Lsr.
Le
schma
ci-dessous
montre
l'emplacement
de
ces
routeurs
dans
une
architecture
Mpls
niveau
de
scurit
est
le
mme
que
celui
de
Frame
Relay
avec
les
Dlci
au
niveau
2.
Le dni de service est en gnral effectu au niveau 3 (Ip). Ici, les paquets seront quand mme routs
jusqu'au destinataire au travers du rseau Mpls en s'appuyant sur les LSPs.
3.6 - Le protocole Ssl
Rcemment arriv dans le monde des Vpn, les Vpn base de Ssl prsente une alternative sduisante face aux
technologies contraignantes que sont les Vpn prsents jusque ici. Les Vpn Ssl prsentent en effet le gros
avantage de ne pas ncessiter du cot client plus qu'un navigateur Internet classique. En effet le protocole Ssl
utilis pour la scurisation des changes commerciaux sur Internet est implment en standard dans les
navigateurs
modernes.
Ssl est un protocole de couche 4 (niveau transport) utilis par une application pour tablir un canal de
communication
scuris
avec
une
autre
application.
Ssl a deux grandes fonctionnalits : l'authentification du serveur et du client l'tablissement de la connexion et
le
chiffrement
des
donnes
durant
la
connexion.
3.6.1 - Fonctionnement
Le protocole Ssl Handshake dbute une communication Ssl. Suite la requte du client, le serveur envoie
son certificat ainsi que la liste des algorithmes qu'il souhaite utiliser. Le client commence par vrifier la
validit du certificat du serveur. Cela se fait l'aide de la cl publique de l'autorit de certification contenue
dans le navigateur du client. Le client vrifie aussi la date de validit du certificat et peut galement consulter
une CRL (Certificate Revocation List). Si toutes les vrifications sont passes, le client gnre une cl
symtrique et l'envoie au serveur. Le serveur peut alors envoyer un test au client, que le client doit signer
avec sa cl prive correspondant son propre certificat. Ceci est fait de faon Ce que le serveur puisse
authentifier
le
client.
De nombreux paramtres sont changs durant cette phase : type de cl, valeur de la cl, algorithme de
chiffrage
...
La phase suivante consiste en l'change de donnes cryptes (protocole Ssl Records). Les cls gnres avec
le protocole Handshake sont utilises pour garantir l'intgrit et la confidentialit des donnes changes. Les
diffrentes phases du protocole sont :
Segmentation des paquets en paquets de taille fixe
Compression (mais peu implment dans la ralit)
Ajout du rsultat de la fonction de hachage compos de la cl de cryptage, du numro de message, de
la longueur du message, de donnes ...
Chiffrement des paquets et du rsultat du hachage l'aide de la cl symtrique gnre lors du
Handshake.
Ajout d'un en-tte Ssl au paquet.
Mpls est aujourd'hui la solution apparaissant comme la plus mature du march. La possibilit d'obtenir une Qos
garantie par contrat est un lment qui pse fortement dans la balance des dcideurs. Cependant, seuls des
oprateurs spcialiss fournissent Ce service Ce qui peut poser de nouveaux problmes. Tout d'abord, Ce sont ces
oprateurs de services qui fixent les prix. Ce prix inclus forcement une marge pour le fournisseur de service.
D'autre part certaines entreprise ne souhaitent pas sous traiter leurs communications un seul oprateur. En
effet l'explosion de la bulle boursire autour des valeurs technologiques a suscit une vague de faillite
d'oprateurs rseaux et de nombreuses entreprises ont vu leurs connexions coupes du jour au lendemain. Ce
risque est aujourd'hui fortement pris en compte par les dcideurs informatiques. Cependant utiliser plusieurs
oprateurs pour la gestion du Vpn complique d'autant la gestion et la configuration de celui-ci.
Enfin l'tendu d'un Vpn-Mpls est aujourd'hui limit par la capacit de l'oprateur de service couvrir de vastes
zones gographiques.
4.5 - Mpls / Ipsec
Mpls
Ipsec
Qualit de service
Cot
Infrieur celui des rseaux Frame Relay et Atm Faible grce au transfert via le domaine
mais suprieur celui des autres Vpn IP.
Internet public
Scurit
Applications
compatibles
Etendue
Evolutivit
Frais de gestion
du rseau
Vitesse de
dploiement
Prise en charge
par le client
5 - Conclusion
Cette tude des solutions Vpn, met en vidence une forte concurrence entres les diffrents protocoles pouvant tre
utiliss. Nanmoins, il est possible de distinguer deux rivaux sortant leurs pingles du jeu, savoir Ipsec et Mpls. Ce
dernier est suprieur sur bien des points, mais il assure, en outre, simultanment, la sparation des flux et leur
confidentialit. Le dveloppement rapide du march pourrait bien cependant donner l'avantage au second. En effet, la
mise en place de Vpn par Ip entre gnralement dans une politique de rduction des cots lis l'infrastructure rseau
des entreprises. Les Vpn sur Ip permettent en effet de se passer des liaisons loues de type Atm ou Frame Relay. Le
cot des Vpn Ip est actuellement assez intressant pour motiver de nombreuses entreprises franchir le pas. A
performance gales un Vpn Mpls cote deux fois moins cher qu'une ligne Atm. Mais si les solutions base de Mpls
prennent actuellement le devant face aux technologies Ipsec c'est principalement grce l'intgration possible
de solution de tlphonie sur Ip. La qualit de service offerte par le Mpls autorise en effet Ce type d'utilisation. Le
march des Vpn profite donc de l'engouement actuel pour ces technologies qui permettent elles aussi de rduire les
cot des infrastructures de communication. Les Vpn sont donc amens prendre de plus en plus de place dans les
rseaux informatiques.
IPsec
1 - Introduction
2 - Les services offerts par IPsec
2.1 - Les deux modes d'change IPsec
2.2 - Les protocoles la base d'IPsec
2.2.1 - AH (authentication header)
2.2.2 - ESP (encapsulating security payload)
2.2.3 - Implantation d'IPsec dans le datagramme IP
3 - Architectures de scurit
3.1 - Associations de scurit
3.2 - Architectures supportes
3.2.1 - Dialogue entre deux htes protgeant le trafic eux-mmes
3.2.2 - Dialogue entre deux LANs l'aide de passerelles de scurit
3.2.3 - Dialogue entre deux htes traversant deux passerelles de scurit
3.2.4 - Dialogue entre un hte et une passerelle de scurit
4 - Gestion des clefs
5 - La compression des en-ttes
6 - Problmes divers
6.1 - Limitations des la gestion manuelle des clefs
6.2 - Broadcast et multicast
6.3 - Firewalls
6.4 - NATs
6.5 - Protocoles autres qu'IP
6.5.1 - PPTP
6.5.2 - L2TP
6.5.3 - PPTP ou L2TP ?
7 - Quelques implmentations actuelles
7.1 - Windows
7.2 - Linux
7.3 - NetBSD
7.4 - FreeBSD
7.5 - OpenBSD
7.6 - Solutions hardware
8 - Les cueils
9 - Discussion autour de la documentation
10 - Suivi du document
Cet article prsente le fonctionnement du protocole IPsec, qui permet de crer des rseaux privs virtuels de manire
conforme aux spcifications de l'IETF. Les services offerts par IPsec et leurs limitations y sont dtaills, de mme que
les problmes d'interoprabilit, tant avec d'autres protocoles qu'entre applications diffrentes. Enfin, quelques
implmentations sont prsentes, et un rapide aperu de leur conformit aux standards est donn.
1 - Introduction
Le protocole IPsec est l'une des mthodes permettant de crer des VPN (rseaux privs virtuels), c'est--dire de relier
entre eux des systmes informatiques de manire sre en s'appuyant sur un rseau existant, lui-mme considr
comme non scuris. Le terme sr a ici une signification assez vague, mais peut en particulier couvrir les notions
d'intgrit et de confidentialit. L'intrt majeur de cette solution par rapport d'autres techniques (par exemple les
tunnels SSH) est qu'il s'agit d'une mthode standard (facultative en IPv4, mais obligatoire en IPv6), mise au point dans
ce but prcis, dcrite par diffrentes RFCs, et donc interoprable. Quelques avantages supplmentaires sont l'conomie
de bande passante, d'une part parce que la compression des en-ttes des donnes transmises est prvue par ce
standard, et d'autre part parce que celui-ci ne fait pas appel de trop lourdes techniques d'encapsulation, comme par
exemple les tunnels PPP sur lien SSH. Il permet galement de protger des protocoles de bas niveau
comme ICMP et IGMP,
RIP,
etc...
IPsec prsente en outre l'intrt d'tre une solution volutive, puisque les algorithmes de chiffrement et
d'authentification proprement parler sont spcifis sparment du protocole lui-mme. Elle a cependant
l'inconvnient inhrent sa flexibilit : sa grande complexit rend son implmentation dlicate. Les diffrents services
offerts par le protocole IPsec sont ici dtaills. Les manires de les combiner entre eux que les implmentations sont
tenues de supporter sont ensuite prsentes. Les moyens de gestion des clefs de chiffrement et signature sont tudis
et les problmes d'interoprabilit associs sont voqus. Enfin, un aperu rapide de quelques implmentations IPsec,
en s'intressant essentiellement leur conformit aux spcifications est donn.
de niveau suprieur, le second permet quant lui d'encapsuler des datagrammes IP dans d'autres datagrammes
IP, dont le contenu est protg. L'intrt majeur de ce second mode est qu'il rend la mise en place de passerelles
de scurit qui traitent toute la partie IPsec d'une communication et transmettent les datagrammes purs de leur
partie IPsec leur destinataire rel ralisable. Il est galement possible d'encapsuler une communication IPsec en
mode tunnel ou transport dans une autre communication IPsec en mode tunnel, elle-mme traite par une
passerelle de scurit, qui transmet les datagrammes aprs suppression de leur premire enveloppe un hte
traitant son tour les protections restantes ou une seconde passerelle de scurit.
2.2 - Les protocoles la base d'IPsec
2.2.1 - AH (authentication header)
AH est le premier et le plus simple des protocoles de protection des donnes qui font partie de la spcification
IPsec. Il est dtaill dans la Rfc 2402. Il a pour vocation de garantir :
L'authentification : les datagrammes IP reus ont effectivement t mis par l'hte dont l'adresse IP
est indique comme adresse source dans les en-ttes.
L'unicit (optionnelle, la discrtion du rcepteur) : un datagramme ayant t mis lgitimement et
enregistr par un attaquant ne peut tre rutilis par ce dernier, les attaques par rejeu sont ainsi
vites.
L'intgrit : les champs suivants du datagramme IP n'ont pas t modifis depuis leur mission : les
donnes (en mode tunnel, ceci comprend la totalit des champs, y compris les en-ttes, du
datagramme IP encapsul dans le datagramme protg par AH), version (4 en IPv4, 6 en IPv6),
longueur de l'en-tte (en IPv4), longueur totale du datagramme (en IPv4), longueur des donnes (en
IPv6), identification, protocole ou en-tte suivant (ce champ vaut 51 pour indiquer qu'il s'agit du
protocole AH), adresse IP de l'metteur, adresse IP du destinataire (sans source routing).
En outre, au cas o du source routing serait prsent, le champ adresse IP du destinataire a la valeur que
l'metteur a prvu qu'il aurait lors de sa rception par le destinataire. Cependant, la valeur que prendrontles
champs type de service (IPv4), indicateurs (IPv4), index de fragment (IPv4), TTL (IPv4), somme de contrle
d'en-tte (IPv4), classe (IPv6), flow label (IPv6), et hop limit (IPv6) lors de leur rception n'tant pas
prdictible
au
moment
de
l'mission,
leur
intgrit
n'est
pas
garantie
par
AH.
L'intgrit de celles des options IP qui ne sont pas modifiables pendant le transport est assure, celle des
autres
options
ne
l'est
pas.
Attention, AH n'assure pas la confidentialit : les donnes sont signes mais pas chiffres.
Enfin, AH ne spcifie pas d'algorithme de signature particulier, ceux-ci sont dcrits sparment, cependant,
une implmentation conforme la Rfc 2402 est tenue de supporter les algorithmes MD5 et SHA-1.
2.2.2 - ESP (encapsulating security payload)
ESP est le second protocole de protection des donnes qui fait partie de la spcification IPsec. Il est dtaill
dans la Rfc 2406. Contrairement AH, ESP ne protge pas les en-ttes des datagrammes IP utiliss pour
transmettre la communication. Seules les donnes sont protges. En mode transport, il assure :
La confidentialit des donnes (optionnelle) : la partie donnes des datagrammes IP transmis est
chiffre.
L'authentification (optionnelle, mais obligatoire en l'absence de confidentialit) : la partie donnes des
datagrammes IP reus ne peut avoir t mise que par l'hte avec lequel a lieu l'change IPsec, qui
ne peut s'authentifier avec succs que s'il connat la clef associe la communication ESP. Il est
galement important de savoir que l'absence d'authentification nuit la confidentialit, en la rendant
plus vulnrable certaines attaques actives.
L'unicit (optionnelle, la discrtion du rcepteur).
L'integrit : les donnes n'ont pas t modifies depuis leur mission.
En mode tunnel, ces garanties s'appliquent aux donnes du datagramme dans lequel est encapsul le trafic
utile, donc la totalit (en-ttes et options inclus) du datagramme encapsul. Dans ce mode, deux
avantages supplmentaires apparaissent:
Une confidentialit, limite, des flux de donnes (en mode tunnel uniquement, lorsque la
confidentialit est assure) : un attaquant capable d'observer les donnes transitant par un lien n'est
pas mme de dterminer quel volume de donnes est transfr entre deux htes particuliers. Par
exemple, si la communication entre deux sous-rseaux est chiffre l'aide d'un tunnel ESP, le volume
total de donnes changes entre ces deux sous-rseaux est calculable par cet attaquant, mais pas la
rpartition de ce volume entre les diffrents systmes de ces sous-rseaux.
La confidentialit des donnes, si elle est demande, s'tend l'ensemble des champs, y compris les
en-ttes, du datagramme IP encapsul dans le datagramme protg par ESP).
Enfin, ESP ne spcifie pas d'algorithme de signature ou de chiffrement particulier, ceux-ci sont dcrits
sparment, cependant, une implmentation conforme la Rfc 2406 est tenue de supporter l'algorithme de
chiffrement DES en mode CBC, et les signatures l'aide des fonctions de hachage MD5 et SHA-1.
2.2.3 - Implantation d'IPsec dans le datagramme IP
La figure 1 montre comment les donnes ncessaires au bon fonctionnement des formats AH et ESP sont
places dans le datagramme IPv4. Il s'agit bien d'un ajout dans le datagramme IP, et non de nouveaux
datagrammes, ce qui permet un nombre thoriquement illimit ou presque d'encapsulations IPsec : un
datagramme donn peut par exemple tre protg l'aide de trois applications successives de AH et de deux
encapsulations
de
ESP.
3 - Architectures de scurit
3.1 - Associations de scurit
La Rfc 2401 (Security Architecture for the Internet Protocol) dcrit le protocole IPsec au niveau le plus lev. En
particulier, elle indique ce qu'une implmentation est cense permettre de configurer en termes de politique de
scurit (c'est--dire quels changes IP doivent tre protgs par IPsec et, le cas chant, quel(s) protocole(s)
utiliser). Sur chaque systme capable d'utiliser IPsec doit tre prsente une SPD (security policy database), dont
la forme prcise est laisse au choix de l'implmentation, et qui permet de prciser la politique de scurit
appliquer au systme. Chaque entre de cette base de donnes est identifie par un SPI (security parameters
index)
unique
(32
bits)
choisi
arbitrairement.
Une communication protge l'aide d'IPsec est appele une SA (security association). Une SA repose sur une
unique application de AH ou sur une unique application de ESP. Ceci n'exclut pas l'usage simultan de AH et ESP
entre deux systmes, ou par exemple l'encapsulation des datagrammes AH dans d'autres datagrammes AH, mais
plusieurs SA devront alors tre actives entre les deux systmes. En outre, une SA est unidirectionnelle. La
protection d'une communication ayant lieu dans les deux sens ncessitera donc l'activation de deux SA. Chaque
SA est identifie de manire unique par un SPI, une adresse IP de destination (ventuellement adresse de
broadcast ou de multicast), et un protocole (AH ou ESP). Les SA actives sont regroupes dans une SAD (security
association
database).
La SPD est consulte pendant le traitement de tout datagramme IP, entrant ou sortant, y compris les
datagrammes non-IPsec. Pour chaque datagramme, trois comportements sont envisageables : le rejeter,
l'accepter sans traitement IPsec, ou appliquer IPsec. Dans le troisime cas, la SPD prcise en outre quels
traitements IPsec appliquer (ESP, AH, mode tunnel ou transport, quel(s) algorithme(s) de signature et/ou
chiffrement
utiliser).
Les plus importants de ces termes sont rcapituls dans le tableau suivant :
SPD base de donnes dfinissant la politique de scurit
SA une entre de la SPD
SAD liste des SA en cours d'utilisation
Les rgles de la SPD doivent pouvoir, si l'adminsitrateur du systme le souhaite, dpendre des paramtres
suivants :
clef
publique.
Deux manires d'changer des clefs sont abondamment utilises : les clefs pr-partages, et les certificats X.509 (dans
ce dernier cas, deux systmes d'adresses initialement inconnues pourront protger leurs changes).
La seconde manire de procder a l'avantage de permettre des clients d'adresses IP dynamiques et changeant
ventuellement de crer des SAs, mais n'est pas obligatoirement supporte par les implmentations conformes laRfc
2409.
Enfin, une dfinition qui peut s'avrer utile lors de la lecture de documentations techniques sur IPsec : la PFS (perfect
forward secrecy) est dfinie par la Rfc 2409 comme la notion selon laquelle la compromission d'une clef ne permettra
l'accs qu'aux donnes protges par cette clef, mais ne sera pas suffisante pour dchiffrer tout l'change IPsec, seule
la partie de la communication protge par la clef corrompue sera dchiffrable.
6 - Problmes divers
L'utilisation simultane d'IPsec et d'autres protocoles ou de certains quipements rseau pose, dans certains cas,
quelques problmes. En outre, la gestion manuelle de clefs introduit quelques restrictions sur les usages possibles du
protocole.
6.1 - Limitations dues la gestion manuelle des clefs
Les services d'unicit offerts par AH et ESP s'appuient sur des numros de squence initialiss 0 lors de la
cration d'une SA et incrments lors de l'envoi de chaque datagramme. Ces numros de squence sont stocks
dans un entier de 32 bits, qui ne doit jamais tre diminu. Le nombre maximal de datagrammes qu'une SA peut
permettre d'changer est donc de l'ordre de quatre milliards. Pass cette limite, il est ncessaire de crer une
nouvelle SA et donc une nouvelle clef. Ceci rend pnible la mise en oeuvre simultane de la gestion manuelle de
clefs et de la protection contre la duplication de datagrammes. Cette dernire tant optionnelle, il est possible de
la dsactiver, auquel cas le numro de squence peut tre annul lorsqu'il a atteint sa valeur maximale.
6.2 - Broadcast et multicast
L'utilisation d'IPsec pour l'envoi et la rception de datagrammes multicast et broadcast pose quelques problmes
dont certains ne sont pas encore rsolus. Des problmes de performances d'une part, et des difficults qu'une
simple augmentation de la puissance de calcul ne saurait rsoudre, comme la vrification des numros de
squence. Le service de protection contre la duplication des donnes n'est donc pas utilisable en environnement
multicast et broadcast l'heure actuelle.
6.3 - Firewalls
Le filtrage de datagrammes IPsec est dlicat pour deux raisons :
les RFCs ne prcisent pas si, sur un systme remplissant simultanment les fonctions de passerelle de
scurit et de firewall, le dcodage de l'IPsec doit avoir lieu avant ou aprs l'application des rgles de
firewalling
il n'est pas possible au code de firewalling de lire certaines donnes, par exemple des numros de port,
dans des donnes chiffres, ou transmises dans un format qu'il ne connat pas
Il est donc important de lire la documentation de l'implmentation IPsec utilise sur les systmes destins grer
simultanment IPsec et firewalling. Il est galement utile de noter que les systmes qui appliquent les rgles de
firewalling avant le dcodage IPsec sont nanmoins souvent capables de filtrer les datagrammes dcods en
utilisant des outils de tunneling comme ipip et gif, ou en filtrant au niveau de l'interface de sortie des donnes.
Enfin, AH utilise le numro de protocole 51 et ESP le numro de protocole 50. Quant IKE, il utilise le numro de
port UDP 500. Ces informations sont indispensables lors de la configuration d'un firewall qui doit laisser passer ou
bloquer les changes IPsec.
6.4 - NATs
Thoriquement, toute translation d'adresse sur un datagramme IPsec devrait tre vite, car ce type d'opration
modifie le contenu des datagrammes, ce qui est incompatible avec les mcanismes de protection de l'intgrit des
donnes d'IPsec. Il existe une solution ce problme, propose par SSH Communications Security : l'IPsec NATTraversal. Il s'agit d'un draft, donc encore incomplet, mais suffisant pour envisager ce que l'avenir rserve.
Certains quipement permettent d'ailleurs dj de traverser des NAT, en utilisant des protocoles plus ou moins
normaliss et avec plus ou moins de bonheur. Comme il ne s'agit que d'un draft, il est dcrit dans des documents
dont le nom et l'adresse changent souvent, mais un moyen simple de le retrouver est d'entrer la chane draftstenberg-ipsec-nat-traversal dans votre moteur de recherche favori. Enfin, ce protocole ne peut tre mis en
oeuvre que si le protocole IKE est utilis simultanment.
6.5 - Protocoles autres qu'IP
Un inconvnient d'IPsec est que ce protocole ne prvoit que le convoyage scuris de datagrammes IP. Ceci n'est
pas suffisant, car d'autres standards comme IPX et NetBIOS sont utiliss sur un grand nombre de rseaux. Il
existe cependant une solution ce problme : encapsuler les donnes protger dans du PPP, lui-mme
transport par IPsec. Le rle de PPP est en effet de permettre la transmission de diffrents protocoles au-dessus
d'un lien existant. Ceci implique de pouvoir encapsuler PPP dans les datagrammes IPsec, cette opration est
dcrite dans les paragraphes suivants.
6.5.1 - PPTP
La premire solution permettant cette encapsulation est le protocole PPTP, dcrit par la Rfc 2637. PPTP offre
ainsi un client, dit PAC (PPTP access concentrator), la possibilit d'tablir un lien PPP avec un serveur dit
PNS (PPTP network server), encapsul dans des datagrammes IP. Si le client a pralablement tabli une SA
avec une passerelle de scurit (ventuellement distincte du PNS), qui lui permet de protger ces
datagrammes IP, les donnes PPP seront donc galement scurises, de mme que les protocoles de niveau
suprieur s'appuyant sur le lien PPP. Deux points s'avrent importants lors de la configuration d'un firewall
plac entre un PAC et un PNS :
PPTP s'appuie sur le protocole d'encaspulation gnral GRE, auquel l'IANA a attribu le numro 47
un lien PPTP est contrl par une connexion TCP vers le port 1723 du PNS
Enfin, PPTP seul, c'est--dire sans IPsec, peut tre et a t utilis pour crer des VPNs, assurant des
changes authentifis, en protgeant les mots de passes utiliss d'un ventuel attaquant, mais sans chiffrer
le reste de la communication. Cependant, ce systme offre une authentification nettement moins fiable que
ce qu'il est possible d'obtenir avec IPsec. En outre, de nombreuses implmentations de ce protocole,
notamment celles de Microsoft, ont fait l'objet de dcouvertes de vulnrabilits et d'incapacit protger
efficacement les mots de passe des utilisateurs. Aussi l'usage de ce systme est-il risqu.
6.5.2 - L2TP
Une deuxime solution d'encapsulation de PPP dans IP est le protocole L2TP, dcrit par la Rfc 2661. Il permet
la transmission de PPP l'aide des protocoles de niveau 2 comme ethernet. Il offre galement un mcanisme
d'encapsulation de PPP dans UDP. Ainsi, il est possible de protger PPP l'aide d'UDP encapsul dans IPsec.
L2TP offre en outre une architecture plus modulaire que PPTP : on suppose le client capable d'changer des
trames par l'intermdiaire d'un protocole de niveau 2 ou des datagrammes UDP avec un LAC (L2TP access
concentrator), qui transmet les donnes un LNS (L2TP network server). Si le LAC et le LNS sont situs
physiquement sur le mme systme, celui-ci joue alors exactement le mme rle que le PNS de PPTP.
Un dtail important lors du paramtrage d'un firewall : le L2TP encapsul dans UDP utilise le port 1701.
6.5.3 - PPTP ou L2TP ?
L'utilisation de PPTP ou L2TP ne change pas grand-chose du point de vue de la scurit, celle-ci tant assure
par la couche infrieure IPsec. La question qui se pose est donc celle de la consommation de bande passante,
parce que toutes ces encapsulations commencent reprsenter un volume de donnes non ngligeable. Dans
le cas d'un client se connectant un ISP et tablissant ensuite le tunnel vers un rseau destination, PPTP
devrait permettre d'conomiser les en-ttes UDP. En revanche, dans le cas d'un client se connectant, par
exemple l'aide d'un modem ou d'une ligne ISDN, directement sur le rseau priv, et disposant donc d'un
lien de niveau 2 vers ce rseau, L2TP semble plus conome. Un dernier point prendre compte est que l'os
tournant sur le serveur imposera parfois des limitations :
pour Windows 2000 et ultrieures, Microsoft semble privilgier trs fortement L2TP
les versions prcdentes de Windows ne supportent pas L2TP
les Unix-like libres semblent accuser un lger retard en matire de support L2TP
le chiffrement opportuniste, qui permet la protection des donnes changes entre deux systmes
totalement trangers jusqu'alors (les clefs publiques sont alors changes l'aide de la DNS)
Les principaux problmes connus lors de l'criture de ce document taient :
KLIPS prsente une trs lgre fuite de mmoire
si plusieurs connexions sont tablies entre deux passerelles de scurit, la compression d'en-ttes doit tre
active pour toutes ou aucune de ces connexions
KLIPS ne gre pas les datagrammes dans lesquels des options IP sont prsentes
Enfin, FreeS/WAN dcode les paquets IPsec avant de les transmettre au code de firewalling. Les rgles de
firewalling peuvent nanmoins tester si les datagrammes ont t envoys en clair ou non.
7.3 - NetBSD
NetBSD utilise KAME, une implmentation IPsec (et plus gnralement IPv6) sous licence BSD. La foire aux
questions concernant IPsec pour NetBSD. Sont notamment supports :
l'utilisation simultane d'IPsec en mode tunnel ou transport avec IPv6, au moins pour la version courante
de NetBSD
la configuration socket par socket ( l'aide de l'appel systme setsockopt(2))
la cration de tunnels IPsec grce aux ports pptp et pptp-server
un nombre quasiment illimit de SA imbriques
l'change dynamique de clefs IKE, en utilisant soit racoon, qui peut fonctionner l'aide de clefs prpartages ou de certificats, soit isakmpd, qui en est encore son stade alpha, et supporte galement ces
deux mthodes
Les principaux problmes connus lors de l'criture de ce document taient :
les clefs associes une SA mise en place l'aide de l'appel setsockopt(2) ne peuvent tre ngocies par
racoon
le protocole AH en mode tunnel ne fonctionne pas correctement
Enfin, lors d'une utilisation conjointe de KAME et IPfilter sous NetBSD, les datagrammes sont traits par le firewall
avant d'tre dcods par KAME.
7.4 - FreeBSD
FreeBSD s'appuie galement KAME. L'utilisation d'IPsec sous FreeBSD est documente. Sont notamment
supports :
l'utilisation simultane d'IPsec en mode tunnel ou transport avec IPv6, au moins pour la version courante
de FreeBSD
la cration de tunnels PPTP (ct client)
la cration de tunnels PPTP (ct serveur), grce au logiciel PoPToP
la cration de tunnels L2TP, grce au logiciel (dont le portage sous FreeBSD en est encore au stade
alpha) l2tpd
l'change dynamique de clefs IKE, en utilisant racoon
7.5 - OpenBSD
A l'instar de FreeBSD et NetBSD, OpenBSD utilise KAME. La documentation relative l'utilisation d'IPsec
sousOpenBSD. Sont notamment supports :
l'change dynamique de clefs ISAKMP grce au logiciel isakmpd, qui supporte le mode agressif et
l'utilisation de certificats comme de clefs pr partages, et la cration de SAs avec des clients d'adresse IP
variables et attribues dynamiquement, photuris peut galement tre employ, mais il est encore en stade
alpha et peu document
la cration de tunnels PPTP (ct client), grce au port pptp
la cration de tunnels PPTP (ct serveur), grce au logiciel PoPToP
l'change dynamique de clefs selon le standard Photuris, en s'appuyant sur le logiciel photurisd
7.6 - Solutions hardware
Si de nombreuses SA doivent tre maintenues, compte tenu de la forte charge CPU lie au chiffrement, il sera
peut-tre ncessaire d'avoir recours l'une des multiples solutions hard disponibles dans le commerce
(Redcreek, Timestep).
8 - Les cueils
Nous conclurons cet article sur une mise en garde : il est fondamental, lors de la mise en place de VPNs l'aide d'IPsec
de parfaitement comprendre quoi la protection va s'appliquer. Il est en effet trs facile de commettre des erreurs aux
consquences extrmement graves. Par exemple, placer une passerelle de scurit derrire un firewallet configurer ce
dernier pour laisser passer tout trafic IPsec implique un paramtrage soigneux de la passerelle de scurit, pour viter
qu'un attaquant l'utilise pour contourner le firewall. Notamment, si cette passerelle met en oeuvre le chiffrement
opportuniste de l'implmentation FreeS/WAN, le firewall peut ne plus tre d'aucune utilit. Il est de manire gnrale
recommand d'appliquer des rgles de firewalling aprs au mme titre qu'avant les traitements IPsec (pour fixer les
ides, une manire simple bien qu'exorbitante d'appliquer ce conseil est de placer un premier firewall avant la
passerelle
de
scurit
et
un
second
aprs
cette
passerelle).
En outre, le chiffrement des donnes ne doit pas crer l'illusion de la scurit, comme SSL l'a trop souvent fait :
chiffrer n'est pas authentifier (un attaquant peut trs bien engager une conversation chiffre avec une passerelle de
scurit), et authentifier le systme metteur d'un datagramme l'aide du protocole AH ne suffit pas ncessairement
assurer la scurit : si un administrateur utilise un protocole permettant une authentification en clair comme telnet, en
encapsulant les donnes dans des datagrammes protgs par AH, un attaquant pourra lire son mot de passe, et s'il est
ensuite possible d'tablir des connexions non authentifies l'aide d'IPsec vers le systme, ce dernier peut alors tre
considr
comme
compromis.
Ces deux exemples illustrent la complexit de la mise en place d'IPsec. Cette complexit ne saurait que difficilement
s'accommoder de solutions soi-disant magiques et clefs en mains, paramtres en quelques clics de souris. IPsec est
excessivement complexe, et masquer cette complexit derrire des interfaces graphiques n'appelant pas les choses par
leurs noms est aussi dangereux qu'irresponsable (serait-il grand temps de mettre un terme l'anarchie dans le
vocabulaire ?-D).
1 - Introduction
2 - Histoire
2.1 - Rappel du contexte technico-conomique
2.2 - Les diffrentes connexions "Haut dbit" par modem xDSL
2.3 - L'alternative PPPoE
2.4 - Statut de PPP over Ethernet
3 - Le protocole PPP
3.1 - Introduction
3.2 - Format de l'entte
3.3 - Etablissement d'une connexion
3.4 - LCP - Link Control Protocol
3.5 - NCP - Network Control Protocols
3.6 - Authentification
4 - Le protocole PPPoE
4.1 - Introduction
4.2 - L'histoire
4.3 - Format de l'entte
4.4 - Les tapes
4.5 - Scurit
5 - Le protocole L2TP
5.1 - Introduction
6-
789-
1 - Introduction
La premire partie du dossier est un peu thorique. Aprs un bref rappel du contexte technico-conomique et des
diffrentes problmatiques rencontres par les fournisseurs d'accs Internet (ISP) avec les connexions Haut Dbit
chez le particulier (technologies xDSL ou liaison cble), le protocole PPPoE sera prsent en dtail ainsi que PPP afin
d'aborder L2TP. La seconde partie du document est plus oriente pratique. Elle dcrit la mise en place d'une solution
L2TP et prsente les diffrentes encapsulations et taille des trames.
L2TP, dfinit par la Rfc 2661, est issu de la convergence des protocoles PPTP et L2F. Il est actuellement dvelopp et
valu conjointement par Cisco Systems, Microsoft, Ascend, 3Com ainsi que d'autres acteurs cls du march des
rseaux. Il permet l'encapsulation des paquets PPP au niveau des couches 2 (Frame Relay et ATM) et 3 (Ip). Lorsqu'il
est configur pour transporter les donnes sur IP, L2TP peut tre utilis pour faire du tunnelling sur Internet. L2TP
repose sur deux concepts : les concentrateurs d'accs L2TP (LAC : L2TP Access Concentrator) et les serveurs rseau
L2TP (LNS : L2TP Network Server). L2TP n'intgre pas directement de protocole pour le chiffrement des donnes. C'est
pourquoi L'IETF prconise l'utilisation conjointe d'IPSEC et L2TP.
2 - Histoire
2.1 - Rappel du contexte technico-conomique
Les services Internet proposs au particulier et aux petites entreprises sont de plus en plus nombreux (connexion
via un fournisseur d'accs, travail distance, services valeur ajoute tels que l'e-mail, serveur Web hberg,
VPN, etc.). Cette population appele communment SOHO (Small Office / Home Office) est la cible des grands de
l'industrie
du
rseau
(oprateurs,
constructeurs,
etc.).
En effet, le besoin de connexion Haut-dbit est de plus en plus fort, mais face des technologies de plus en
plus complexes, les dploiements sont ralentis car trop coteux (liens fibres optiques, terminaux de connexion
ATM), trop spcifiques (encapsulations multiples des protocoles pour interfacer PC et modem) ou encore trop
difficiles
mettre
en
place
par
les
oprateurs
(configuration,
formation
des
utilisateurs).
Diffrentes propositions ont t faites afin de standardiser et simplifier le mode de connexion entre un
micro-ordinateur personnel PC et un modem de type xDSL ou modem cble. Ces diffrentes solutions sont
prsentes
en
paragraphe
II.2.
Rappelons que les objectifs qui animent ces recherches sont la facilit et la vitesse de dploiement des connexions
Haut dbit chez les consommateurs SOHO, et de surcrot moindre cot !
2.2 - Les diffrentes connexions "Haut dbit" par modem xDSL
Dans le cas de connexion par RTC (Rseau Tlphonique Commut), les utilisateurs finaux (SOHO ou particuliers
pour un usage priv) sont habitus utiliser un matriel banalis comme un modem analogique fonctionnant
en bande tlphonique analogique (30Hz -> 3,6 KHz), dont le cot d'achat est faible, et surtout dont la
configuration est minimale (utilisation des protocoles PPP, SLIP, RAS, etc. nativement grs par les systmes
d'exploitations
les
plus
rpandus
du
march).
Dans le cadre des connexions Haut-dbit , un matriel plus sophistiqu de type modem xDSL ou modem cble
est ncessaire. Son cot d'acquisition est plus lev que dans le cas prcdent, et la configuration est plus
complexe
car
elle
s'appuie
sur
des
technologies
plus
labores.
Les recherches menes par l'industrie du rseau et des tlcommunications ont abouti plusieurs propositions
d'architecture dcrites ci-aprs, chacune base sur les technologies ATM sur xDSL. Un des objectifs tant la
simplicit de configuration, le protocole PPP a t retenu comme point de dpart. Chacune des solutions diffre
sur le mode de connexion entre le micro-ordinateur et le modem xDSL.
2.2.1 - ATM sur interface xDSL
Le
schma
suivant
prsente
la
premire
proposition
de
configuration.
Une carte d'interface xDSL est implante directement dans le micro-ordinateur, sur lequel sont installs un
driver PPP et un driver ATM. L'avantage principal est l'utilisation de PPP pour l'utilisateur, donc la
configuration et la procdure de connexion est connue car identique celle utilise dans le cas de connexion
analogique par RTC. La connexion PPP s'effectue au travers de la boucle locale jusqu'au rseau de donnes
rgional
vers
un
POP
(Point-Of-Presence)
de
fournisseur
d'accs.
Deux inconvnients majeurs cette architecture :
Le march des interfaces xDSL n'en est qu' ses premiers pas et le manque d'inter-oprabilit entre
les diffrents quipements xDSL ne permet pas la ralisation d'conomies d'chelles ncessaires pour
la production d'interfaces xDSL standards cot rduit.
La ligne xDSL ne peut tre utilise que par un seul micro-ordinateur la fois, ce qui limite l'intrt de
ce type de connexion pour les SOHO.
2.2.2 - Interface ATM et modem xDSL
La
seconde
proposition
d'architecture
est
prsente
dans
le
schma
ci-dessous.
Les limites reconnues d'une interface xDSL, les approches suivantes, dont celle-ci, s'appuient sur un
quipement xDSL externe (modem). La configuration propose ici repose sur un lien ATM entre le microordinateur et le modem xDSL. A cet effet, une interface ATM est implante dans le PC.
Les inconvnients de cette proposition sont les suivants :
Les interfaces ATM sont peu rpandues chez les utilisateurs finaux. Cette configuration tait la
premire hypothse des oprateurs pour le dploiement des connexions Haut dbit chez le
consommateur. Pour rappel, elle n'a pas t retenue pour des raisons conomiques. De plus, ce type
d'interface est difficile installer et configurer par l'utilisateur. Cette complexit risque de ralentir le
dploiement et l'acceptation de la technologie xDSL chez les consommateur.
Il n'existe pas d'interface ATM pour les micro-ordinateurs portables, ce qui est un inconvnient pour
les SOHO, le plus souvent nomades.
Le partage d'une telle connexion ncessite l'utilisation d'un commutateur ATM, ce qui rend difficile,
voir quasi impossible le dploiement d'un telle solution.
2.2.3 - Interface Ethernet, L2TP sur IP et modem xDSL
La
troisime
solution
est
prsente
dans
le
schma
suivant.
Cette architecture est plus ouverte dans la mesure o le lien entre le micro-ordinateur et l'quipement
xDSL repose sur une technologie prouve : Ethernet. En effet, le modem xDSL dispose d'un banal
connecteur Ethernet qui peut tre soit attach directement une carte Ethernet implante dans le client PC
(liaison l'aide d'un cble crois ou droit ), soit indirectement via un Hub (ou Switch) Ethernet. Le
micro-ordinateur doit tre configur comme sur un rseau local d'entreprise (LAN : Local Area Network),
c'est dire : possder un driver de carte rseau (NIC Ethernet), une pile de protocole TCP/IP, et une couche
logicielle
permettant
la
gestion
de
sessions
PPP
(pour
la
connexion
l'ISP).
Cette topologie a l'avantage de permettre le partage de la connexion xDSL au travers d'un rseau. Autre
avantage d'un telle architecture : le cot peu lev de l'quipement. A noter quand mme les quelques
inconvnients suivants :
Cette configuration n'intgre pas nativement ce qui est ncessaire au dpart, savoir un mcanisme
de transport et de gestion de sessions PPP au travers d'Ethernet. L'utilisation d'un protocole de
tunneling comme L2TP (ou PPTP) peut s'avrer un moyen pour assurer le transport de PPP sur IP,
mais ajoute une complexit la configuration.
Le modem xDSL doit, dans ce type de solution, possder une adresse IP (configurable de prfrence)
pour la communication au niveau du rseau Ethernet. Le client PC a donc quant lui deux adresses IP
: la premire pour la connexion au rseau Ethernet (afin d'tablir correctement le tunnel L2TP), la
seconde pour la liaison PPP vers un ISP.
Quelles adresses IP utiliser pour tablir le tunnel L2TP entre le client PC et le modem xDSL ? Une des
rponses possibles cette problmatique est l'implantation et l'utilisation combine de mcanismes
comme NAT (Network Address Translation : translation d'adresses IP d'un rseau vers un autre)
etDHCP (attribution dynamique d'une adresse IP un client, partir de plages dfinies). Mme si ces
techniques sont connues et matrises dans le monde du rseau, elles sont loin d'tre la porte des
utilisateurs finaux.
2.2.4 - Interface Ethernet, ATM sur BMAP et modem xDSL
La
quatrime
et
dernire
architecture
propose
est
la
suivante.
Les inconvnients apports par l'utilisation d'un protocole de tunneling comme L2TP pour transporter du
PPP sur de l'Ethernet ont entran le dveloppement d'un nouveau protocole baptis BMAP (Broadband
Modem Access Protocol). Dans l'approche qui est prsente sur le schma ci-avant, la configuration reprend
le principe de PPP sur ATM, mais le transport entre le client PC et le modem xDSL sur Ethernet, est assur
par ce protocole BMAP. La configuration de l'quipement xDSL est nettement simplifie, mais cette solution
apporte d'autres inconvnients que ceux cits auparavant :
La pile de protocole au niveau du client PC est bien plus complexe que le modle Dial-up standard.
Alors que ce dernier consiste adresser directement le modem analogique partir du protocole PPP,
le modle prsent ici introduit un rseau Ethernet et de l'ATM cohabitant avec du BMAP pour
transporter le protocole PPP vers le modem xDSL. La complexit d'un telle configuration est donc une
fois de plus mise en avant.
Concernant le partage de la connexion : la nature du protocole BMAP est telle que si plusieurs clients
PC veulent accder au modem xDSL (donc la mme ligne) au mme moment, un des microordinateurs du rseau doit tre dfini pour fonctionner en mode passerelle, relayant ainsi le trafic des
autres postes vers le modem. Cet aspect augmente encore le niveau de complexit de cette solution.
Pas ou peu d'quipement xDSL intgre la gestion du protocole BMAP. De plus, il n'y a pas encore de
drivers BMAP disponibles pour les systmes d'exploitations Windows.
2.2.5 - Conclusion
En conclusion de la prsentation de ces quatre propositions, il apparat chaque fois plus d'inconvnients que
d'avantages. D'un ct la configuration mettre en place est soit trop coteuse ou soit trop complexe pour
l'utilisateur final, d'un autre ct les quipements n'intgrent pas les fonctionnalits ncessaires. C'est pour
cette raison qu'aucune d'entre elles n'a t retenue.
2.3 - L'alternative PPPoE
La solution qui a t retenue a donn naissance un nouveau protocole baptis PPPoE : PPP over Ethernet.
Comme son nom l'indique, cette technique repose sur le meilleur des deux mondes :
Le protocole PPP pour la communication avec un ISP au travers de l'architecture xDSL mise en place.
Respectant un des objectifs majeurs initiaux, la solution se rapproche du modle Dial-Up bien connu.
L'utilisateur final a dj une connaissance de l'utilisation et de la configuration de ce mode de connexion.
La topologie Ethernet pour le partage du modem xDSL au travers d'un rseau local bti autour de Hub (ou
Switch) ou de rattachement direct au client PC dans lequel est implante une carte d'interface Ethernet
(NIC), s'appuyant ainsi sur un standard de l'industrie.
Le
schma
suivant
prsente
l'architecture
PPPoE
Le modem xDSL peut tre prconfigur par l'oprateur (CVP pour le lien oprateur), rduisant ainsi le temps
d'installation d'une telle solution chez l'utilisateur final. Ce dernier n'a plus que quelques tapes raliser pour
finaliser sa connexion Haut dbit :
Implanter une carte d'interface Ethernet dans le ou les clients PC. Connecter la carte directement au
modem xDSL ou sur un Hub Ethernet (dans le cas du partage de la connexion).
Installer le driver Ethernet de la carte correspondant au systme d'exploitation du client
Installer le driver PPPoE qui fera le lien PPP entre le client et le modem xDSL.
Crer une connexion un ISP de faon tout fait classique.
Le rsultat d'une demande de connexion est l'tablissement d'une session PPP over Ethernet. Le modem xDSL
joue un rle de pont MAC/LLC qui se contente de faire transiter du flux PPP encapsul dans des trames Ethernet
d'un ct, vers du flux PPP circulant dans un CVP ATM sur support xDSL de l'autre. Le CVP ATM dfini permet la
connexion directe un POP via la boucle locale Haut dbit . Ce dernier doit tre quip de telle manire
accepter des connexions PPP sur ce canal virtuel. L'ISP voit quand lui arriver une demande de connexion PPP
des plus classiques. Lors du partage de connexion, il n'est pas ncessaire de dfinir de CVP supplmentaires. En
effet,
le
multiplexage
de
sessions
PPP
se
ralise
de
manire
transparente.
Redback Networks est une des socits qui a activement particip l'laboration du protocole PPPoE. Elle propose
un
quipement
complet
pour
les
POP
s'appuyant
sur
un
serveur
SMS1000.
Le
schma
suivant
rsume
une
solution
mettant
en
oeuvre
PPPoE
et
le
serveur
de
RedBack.
3 - Le protocole PPP
3.1 - Introduction
Le protocole Point Point (PPP) propose une mthode standard pour le transport de datagrammes multiprotocoles sur une liaison simple point point. PPP comprend trois composants principaux:
Une mthode pour encapsuler les datagrammes de plusieurs protocoles.
Un protocole de contrle du lien "Link Control Protocol" (LCP) destin tablir, configurer, et tester la
liaison de donnes.
Une famille de protocoles de contrle de rseau "Network Control Protocols" (NCPs) pour l'tablissement et
la configuration de plusieurs protocoles de la couche "rseau".Dans notre cas nous n'utilisons que NCP/IP.
Nous prsentons l'organisation et les mthodes utilises par PPP, ainsi que l'encapsulation effectue par ce
protocole, un mcanisme extensible de ngociation d'options spcifique son utilisation capable de ngocier une
large gamme de paramtres de configuration et apportant des fonctions tendues de gestion. Dans cette
prsentation Nous tudierons les spcificits de son utilisation dans une cession de type PPPoE.
3.2 - Format de l'entte
La trame PPP est constitue d'un en-tte et d'un bloc de donnes. Cette encapsulation ncessite l'usage d'un
tramage dont le but principal est d'indiquer le dbut et la fin de l'encapsulation. Les champs ci-dessous sont
toujours transmis de gauche droite.
Protocole
8021
IP
8023
OSI
8025
XNS, Vines
8027
DECnet
8029
AT
8031
Bridge
Donnes - Contient soit la valeur zro, soit des donnes (1500 octets maximum).
FCS - Squence de contrle de trame pour une vrification des erreurs.
3.3 - Etablissement d'une connexion
Pour tablir une connexion sur un lien Point Point, chaque extrmit doit dans un premier temps mettre des
paquets
LCP
pour
configurer
et
tester
le
support
de
liaison.
Ensuite, PPP envoie des paquets NCP pour choisir et configurer un ou plusieurs protocoles rseau disponibles. Une
fois ces protocoles configurs, les datagrammes peuvent tre envoys sur la liaison. Celle-ci reste disponible
jusqu'
ce
que
des
paquets
LCP
ou
NCP
spcifiques
ne
la
ferment
explicitement.
Dead - Une communication dbute et se termine ncessairement dans cet tat. Le passage la phase
d'tablissement s'effectue lorsque le niveau physique est prt accueillir la connexion.
Etablissement - Grce au protocole LCP, les quipements distants s'changent des paquets de configuration
par l'intermdiaire desquels ils ngocient les paramtres de la connexion. Au cours de cette phase, tout
paquet non-LCP est ignor.
Authentification - Par dfaut, l'authentification n'est pas demande mais sur certaines liaisons, elle peut
tre indispensable. Dans ce cas, c'est lors de la phase d'tablissement que le protocole d'authentification
doit tre spcifi.
Connexion - le protocole rseau utilis (IP, IPX ou Apple Talk) doit tre configur via le protocole NCP. Le
trafic sur le lien peut alors avoir lieu.
Fin - la fermeture de la liaison peut survenir suite plusieurs vnements comme la perte de la porteuse,
la chute d'une temporisation d'attente ou plus frquemment suite la demande d'un utilisateur.
Voici
un
exemple
appliqu
dans
le
cadre
d'une
connexion
d'un
internaute
un
provider:
Les paquets de Configuration de Liaison utiliss pour tablir et configurer une communication (RequteConfiguration, Configuration-Acquitte, Configuration-NonAcquitte et Configuration-Rejete).
Les paquets de Fermeture de Liaison utiliss pour couper une communication (Requte-Fermeture et
Fermeture-Acquitte).
Les paquets de Maintenance de Liaison utiliss pour grer et dterminer une liaison (Code-Rejet,
Protocole-Rejet, Requte-Echo, Rponse-Echo, et Requte-Elimination).
Lorsque le champ Protocole du paquet PPP indique une valeur hexadcimale c021 (Link Control Protocol). Format
d'un paquet LCP :
Nom
Signification
Configure-Request
Configure-Ack
Configure-Nak
Configure-Reject
Terminate-Request
Fermeture de la connexion
Terminate-Ack
Code-Reject
Non utilisation : Vrification du squencement des champs (FCS), Compression des champs adresse et
contrle (ACFD); Table des caractres de contrle asynchrones (ACCM).
3.5 - NCP - Network Control Protocols
L'tat rseau d'une connexion PPP suit soit l'tat d'authentification, soit l'tat d'tablissement. A ce stade, LCP a
dj tabli toutes les options de PPP. La connexion est active et presque prte transporter les donnes de
l'utilisateur. Le NCP configure les protocoles de la couche rseau que la connexion PPP va transporter (IP pour
PPPoE). Il existe trois classes de paquets NCP :
Les paquets de Configuration, utiliss pour tablir et configurer une communication (RequteConfiguration, Configuration-Acquitte, Configuration-NonAcquitte et Configuration-Rejete).
Les paquets de Fermeture, utiliss pour couper une communication (Requte-Fermeture et FermetureAcquitte).
Le paquet erreur (Code-Rejet).
Dtail
du
paquet
NCP
Nom
Signification
Configure-Request
Configure-Ack
Configure-Nak
Configure-Reject
Terminate-Request
Fermeture de la connexion
Terminate-Ack
Code-Reject
Protocol-Reject
Echo-Request
10
Echo-Reply
Rponse au Echo-Request
11
Discard-Request
Longueur - Le champ Longueur comporte deux octets, et donne la longueur du paquet NCP.
Donnes - Le champ Donnes comporte zro ou un nombre quelconque d'octets, selon l'indication du
champ Longueur. Le format interne du champ Donnes dpend de la valeur prsente dans le champ Code.
3.6 - Authentification
PPP
peut
supporter
les
oprations
d'authentifications
au
dbut
d'une
connexion.
L'tat d'authentification fait suite l'tat d'tablissement si l'une ou l'autre des extrmits est d'accord pour
utiliser un protocole d'authentification. La ngociation de cette option s'effectue lors de la monte du niveau LCP.
Les deux protocoles d'authentifications :
Password Authentication Protocol (PAP) - PAP implmente la mthode traditionnelle avec l'utilisation d'un
nom d'utilisateur et d'un mot de passe. Sur demande d'un authentificateur , le rcepteur rpond avec le
nom et le mot de passe, l'authentificateur valide l'information et envoie un accus de rception positif ou
ngatif.
Challenge Handshake Authentification Protocol (CHAP) - CHAP implmente une authentification utilisant un
nom d'utilisateur et une chane alatoire CHAP. L'authentificateur envoie son nom et sa chane alatoire, le
rcepteur transforme cette chane par un algorithme de calcul et une cl CHAP secrte. Il envoie ensuite le
rsultat avec son propre nom, l'authentificateur compare la rponse avec sa propre copie de la cl secrte.
Enfin, il envoie un accus de rception indiquant un chec ou un succs.
4 - Le protocole PPPoE
4.1 - Introduction
Les technologies d'accs modernes font face quelques problmes et buts contradictoires. Il est souhaitable de
connecter des htes multiples un site distant travers un mme dispositif d'accs client. Un autre but est de
fournir un contrle d'accs et facturer selon la mme mthode que celle utilise par PPP sur rseau commut.
Dans beaucoup de technologies d'accs, la mthode la plus avantageuse financirement pour rattacher des htes
multiples un dispositif d'accs client est l'utilisation d'Ethernet. Enfin, la minimisation des cots est importante ;
il
faut
utiliser
la
plus
petite
configuration
possible
ou
mieux
aucune
configuration.
PPP sur Ethernet (PPPoE) fournit la capacit de connecter un rseau d'htes vers un concentrateur d'accs distant
travers un simple dispositif d'accs pont. Avec ce modle, chaque hte utilise sa propre pile PPP et l'utilisateur
garde une interface familire. Le contrle d'accs, la facturation et les autres services peuvent tre raliss par un
utilisateur
final
plutt
que
par
un
site
final
(la
base).
Pour fournir une connexion point point travers Ethernet, chaque session PPP doit apprendre l'adresse Ethernet
de la machine distante afin d'tablir et d'identifier une session unique. PPPoE inclut donc un protocole de
dcouverte.
4.2 - L'histoire
Ce document prsente le protocole de communication baptis PPPoE (Point to Point over Ethernet) permettant de
vhiculer du flux PPP (Point to Point Protocol) encapsul dans des trames Ethernet. Cette technologie (1998-99)
est ne d'un travail conjoint de UUNET Technologies Inc., RedBack Networks Inc., et RouterWare Inc. Elle fait
l'objet de la Rfc 2516 qui sera dcrite au cours de l'tude du protocole PPPoE, suivi d'une traduction en franais.
4.3 - Format de l'entte
L'entte
pour
PPPoE
se
dfinie
comme
suit
Version - 4 bits qui doivent tre la valeur 0x1 pour cette version de la spcification PPPoE.
Type - 4 bits qui doivent tre la valeur 0x1 pour cette version de la spcification PPPoE.
Code - 8 bits dfinis plus bas pour l'tape de dcouverte et l'tape de la session PPP.
Id - Valeur non signe sur 16 bits. C'est la valeur dfinie lors de l'tape de la dcouverte. Cette valeur est
fixe pour une session PPP donne entre l'adresse Ethernet source et l'adresse Ethernet destination. La
valeur 0xffff est rserve pour un usage futur et ne doit pas tre utilise.
Longueur - 16 bits indiquant la longueur de la charge utile PPPoE. Cela n'inclut pas la longueur des en-ttes
Ethernet ou PPPoE.
Voil
comment
l'entte
Ethernet
spcifie
l'intgration
de
PPP
Adresse de destination - Ce champs, bas sur 6 octets contient soit une adresse Ethernet unicast soit une
broadcast (0xFFFFFFFFFFFF). Pour les paquets de dcouverte, la valeur peux tre soit unicast soit
broadcast. Pour le trafic de session PPP, ce champ doit contenir l'adresse unicast du peer distant qui a t
dtermine lors de l'tape Dcouverte.
Adresse source - Ce champs, bas sur 6 octets, doit contenir l'adresse MAC de l'quipement source.
Type Ethernet - Ce champ cod sur 16 bits doit tre configur 0x8863 pour l'tape Dcouverte et 0x8864
pour la session PPP.
CRC - Ce champ permet en 4 octets de valider la conformit de la trame.
4.4 - Les tapes
PPPoE est compos de deux tapes distinctes : la dcouverte et la session PPP. Quand un hte veut initier une
session PPPoE, il doit tout d'abord lancer une requte de dcouverte afin d'identifier l'adresse Ethernet MAC de
son vis vis puis dfinir un identificateur de session PPPoE. Alors que PPP dfinit une liaison de bout en bout, la
phase de dcouverte correspond un rapport client-serveur. Lors du processus de dcouverte, un hte (le client)
dcouvre un concentrateur d'accs (le serveur). Selon la topologie du rseau, il peut y avoir plus d'un
concentrateur d'accs avec lequel l'hte peut communiquer. L'tape de la dcouverte permet l'hte de dcouvrir
tous les concentrateurs d'accs et d'en slectionner un. Quand la dcouverte s'achve avec succs, l'hte et le
concentrateur d'accs slectionn possdent les informations qu'ils emploieront pour construire leur connexion
point
point
sur
Ethernet.
L'tape de la dcouverte attend alors jusqu' ce qu'une session PPP soit tablie. Une fois qu'une session PPP est
tablie, l'hte et le concentrateur d'accs doivent allouer les ressources pour une interface virtuelle PPP.
4.4.1 - Dcouverte
L'tape de dcouverte s'effectue en quatre temps. Quand elle s'achve, chaque vis vis connat
l'identificateur de session PPPoE ainsi que les adresses Ethernet des extrmits; cela suffit pour dfinir une
session PPPoE. Les tapes sont :
Emission par diffusion d'un paquet d'initialisation par l'hte.
Emission de paquets d'offres par un ou plusieurs concentrateurs d'accs.
Emission adresse d'un paquet de demande de session par l'hte.
Emission d'un paquet de confirmation par le concentrateur d'accs slectionn.
Quand l'hte reoit le paquet de confirmation, il peut passer l'tape suivante : la session PPP. Toutes les
trames de dcouvertes Ethernet ont la valeur 0x8863 dans le champ Type Ethernet . La charge utile
PPPoE contient zro ou plusieurs TAGs. Un TAG est un ensemble type-longueur-valeur (TLV) construit et
dfini comme suit :
Type - 16 bits. L'annexe A contient une liste de tous les types et de leurs valeurs.
Longueur - Valeur non-signe sur 16 bits indiquant en octets la longueur de Valeur .
Si un paquet de dcouverte est reu avec un TAG de type inconnu, il doit tre ignor moins qu'il n'en soit
spcifi autrement dans ce document. Ceci fournira une compatibilit ascendante lorsque de nouveaux TAGs
seront ajouts. Lorsque de nouveaux TAGs indispensables seront ajouts, le numro de version sera
incrment.
Voici un exemple appliqu dans le cadre de l'ADSL. En effet lors de connexion PPPoE, le client pourra choisir
l'quipement de connexion pour soit aller vers son provider, soit vers un serveur multicast ou tablir deux
sessions
simultanes.
Identificateur
de
session
relais
.
doit
contenir
0x0000.
Quand un hte ne reoit pas de paquet PADO au bout d'un laps de temps dtermin, il doit renvoyer le paquet
PADI et doubler la priode d'attente. Cela peut se rpter autant de fois que souhait et dsir. Si l'hte attend
pour recevoir un paquet PADS, un mcanisme similaire de temps mort doit tre employ, avec l'hte renvoyant le
PADR. Aprs un nombre dtermin d'essais, l'hte doit alors renvoyer un paquet PADI. Les valeurs du champ
Type Ethernet employes dans ce document (0x8863 et 0x8864) ont t assignes par l'IEEE pour l'utilisation
de PPPoE. L'utilisation de ces valeurs et le champ Version sont les seuls identifiants du protocole.
4.5 - Scurit
Afin de se protger contre d'ventuels actes de piratage, le point d'accs (AC : Access Concentrator) peut utiliser
le TAG AC-Cookie. Ce dernier doit tre en effet capable de gnrer de manire unique une valeur de TAG base
sur l'adresse MAC source d'une requte PADR, identifiant l'hte metteur. Cet identifiant permettra ainsi au point
d'accs de limiter le nombre de sessions simultanes pour un hte donn. L'algorithme utilis pour la gnration
d'un identifiant unique partir de l'adresse MAC est laiss au choix des constructeurs (dtail d'implmentation).
L'algorithme HMAC (Keyed-Hashing for Message Authentication) peut par exemple tre mis en place. Il ncessite
une cl prive qui n'est connue que du point d'accs. Attention toutefois l'utilisation du TAG AC-Cookie, car il est
une mthode de protection contre certaines attaques, mais il n'offre pas une garantie de scurit totale.
Certains point d'accs ne souhaitent pas forcment diffuser l'ensemble des services qu'ils implmentent des
htes non authentifis. Dans ce cas, deux stratgies peuvent tre employes :
Ne jamais refuser une requte base sur le TAG Service-Name, et toujours lui retourner la valeur du
service demand. Il y a donc correspondance entre le service demand et le service retourn l'hte
metteur.
N'accepter que les requtes Service-Name ayant une longueur de TAG nulle (indiquant n'importe quel
service). L'hte metteur et le point d'accs connaissent dj le type de service utilis pour cette session.
L'information sur le service ne circule donc plus sur le rseau.
5 - Le protocole L2TP
5.1 - Introduction
L2TP a t conu pour transporter des sessions PPP au travers d'un rseau IP, et de terminer physiquement les
sessions
PPP
en
un
point
de
concentration
dtermin
dans
le
rseau.
Le protocole L2TP (Layer 2 Tunneling Protocol), dvelopp partir du protocole point point PPP, est sans
conteste l'une des pierres angulaires des rseaux privs virtuels d'accs. Il rassemble en effet les avantages de
deux autres protocoles L2F et PPTP. L2TP est une norme prliminaire de l'IETF (Engineering Task Force)
actuellement dveloppe et value conjointement par Cisco Systems, Microsoft, Ascend, 3Com et d'autres
acteurs
cls
du
march
des
rseaux.
Le protocole L2TP est un protocole rseau qui encapsule des trames PPP pour les envoyer sur des rseaux IP,
X25, relais de trames ou ATM. Lorsqu'il est configur pour transporter les donnes sur IP, le protocole L2TP peut
tre utilis pour faire du tunnelling sur Internet. Dans ce cas, le protocole L2TP transporte des trames PPP dans
des paquets IP. La maintenance du tunnel est assure l'aide de messages de commandes au format L2TP tandis
que le protocole UDP est utilis pour envoyer les trames PPP au sein de trames L2TP.
5.2 - Format de l'entte
d'extrmit
PPP
prenant
en
charge
le
protocole
L2TP.
Le rle du concentrateur d'accs LAC se limite fournir un support physique qui sera utilis par L2TP pour
transfrer le trafic vers un ou plusieurs serveurs rseau L2TP (LNS). Il assure le fractionnement en canaux pour
tout protocole bas sur PPP. Le concentrateur d'accs LAC joue le rle de serveur d'accs, il est l'origine du
tunnel et est responsable de l'identification du VPN.
5.4 - Les serveurs rseau - LNS
Les serveurs rseau L2TP, signifiant L2tp Network Server (LNS), peuvent fonctionner sur toute plate-forme
prenant en charge la terminaison PPP. Les serveurs rseaux L2TP grent le protocole L2TP ct serveur. Les
serveurs LNS sont les metteurs des appels sortants et les destinataires des appels entrants. Ils sont responsables
de l'authentification du tunnel.
5.5 - Avantages et inconvnients
L2TP repose sur UDP qui lui mme repose sur IP. Au total, l'empilement total des couches protocolaires est le
suivant (en partant du backbone) : IP/PPP/L2TP/UDP/IP/Couche2. A cela se rajoutent TCP/HTTP si l'utilisateur
surfe sur le web. L'ensemble n'est donc pas trs lger, et une attention particulire doit tre porte sur ce qui est
de l'accordement de MRU (pour PPP) avec la MTU de tous les quipements IP traverss, de telle faon liminer
la fragmentation sur les paquets de grande taille. L'overhead reprsente donc l'inconvnient de L2TP.
L2TP permettant de terminer des sessions PPP n'importe o. Cela permet un oprateur ou plus gnralement au
propritaire d'un rseau d'accs (boucle locale) de collecter pour le compte d'un tiers des connexions et de lui
laisser le soin de terminer les sessions PPP associes. C'est vraiment la fonction VPN de L2TP : permettre un
utilisateur mobile de se connecter un rseau particulier, ventuellement priv, tout en utilisant une
infrastructure publique et partage. Ainsi un salari d'une entreprise peut tre sr de se connecter un VPN
particulier de son entreprise (correspondant son groupe de travail), quelque soit le POP de son entreprise auquel
il se connecte. Il peut ainsi conserver les droits, et les restrictions dfinies par son profil. Les concepts de mobilit
et de Wholesale reprsentent donc les avantages de L2TP.
l'architecture
PPP
transport
sur
un
rseau
d'infrastructure
IP
via
L2TP
Un dtail important lors du paramtrage d'un firewall : le L2TP encapsul dans UDP utilise le port 1701
6.2 - Les encapsulations
Voici un exemple dans le cas o le client surf via le protocole HTTP.
6.2.1 - Cas de PPP
PPP
La surcouche des enttes est donc de 8 octets. Voici la reprsentation en pourcentage dans le cadre de
paquet non fragment :
Taille de datagramme
Pourcentage relatif
70
11,4 %
1300
0,6 %
1500
0,5 %
PPP
PPPoE
La surcouche des enttes est donc de 8+6=14 octets. Voici la reprsentation en pourcentage dans le cadre
de paquet non fragment :
Taille de datagramme
Pourcentage relatif
70
20 %
1300
1,1 %
1500
0,9 %
PPP
L2TP
UDP
IP
La surcouche des enttes est donc de 8+6+8+20=42 octets. Voici la reprsentation en pourcentage dans le
cadre de paquet non fragment :
Taille de datagramme
Pourcentage relatif
70
60 %
1300
3,2 %
1500
2,8 %
Mpls
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Introduction MPLS
MPLS: Objectifs et Missions
Le routage classique
La commutation de labels
Principes MPLS
Label
Implicit Routing (LDP)
Explicit Routing
Support de la QoS
9.1 - Signalisation et QoS
9.2 - Routage et QoS
9.3 - Architecture pour la QoS
- VPN
- Traffic Engineering
- Agrgation de flux
- Applications
- Discussion autour de la documentation
- Suivi du document
1 - Introduction MPLS
MPLS (Multi-Protocol Label Switching) est une technique rseau en cours de normalisation l'IETF dont le rle principal
est de combiner les concepts du routage IP de niveau 3, et les mcanismes de la commutation de niveau 2 telles que
implmente dans ATM ou Frame Relay. MPLS doit permettre d'amliorer le rapport performance/prix des quipements
de routage, d'amliorer l'efficacit du routage (en particulier pour les grands rseaux) et d'enrichir les services de
routage (les nouveaux services tant transparents pour les mcanismes de commutation de label, ils peuvent tre
dploys
sans
modification
sur
le
coeur
du
rseau).
Les efforts de l'IETF portent aujourd'hui sur Ipv4. Cependant, la technique MPLS peut tre tendue de multiples
protocoles (IPv6, IPX, AppleTalk, etc,). MPLS n'est en aucune faon restreint une couche 2 spcifique et peut
fonctionner sur tous les types de support permettant l'acheminement de paquets de niveau 3.
MPLS traite la commutation en mode connect (bas sur les labels); les tables de commutation tant calcules partir
d'informations provenant des protocoles de routage IP ainsi que de protocoles de contrle. MPLS peut tre considr
comme une interface apportant IP le mode connect et qui utilise les services de niveau 2 (PPP, ATM, Ethernet, ATM,
Frame
Relay,
SDH
...).
La technique MPLS a t voulue par l'IETF relativement simple mais trs modulaire et trs efficace. Certains points cl
sont maintenant mis en avant par l'IETF et par certains grands constructeurs domins par Cisco, ainsi que par les
fournisseurs de services aux premiers desquels se trouvent les oprateurs de rseaux. Un grand effort pour aboutir
une normalisation a t consentie par les diffrents acteurs, ce qui semble mener une rvolution des rseaux IP.
3 - Le routage classique
IP est un protocole de niveau rseau fonctionnant dans un mode non connect, c'est--dire que l'ensemble des paquets
(ou datagrammes) constituant le message sont indpendants les uns des autres : les paquets d'un mme message
peuvent donc emprunter des chemins diffrents utilisant des protocoles IGP (interior gateway protocol), tels que RIP
(routing information protocol) de type "Vecteur de distance", et OSPF (open shortest path first) de type "Etat de liens"
, ou bien des protocoles EGP (exterior gateway protocol), tel que BGP (border gateway protocol). Chaque routeur
maintient une table de routage, dans laquelle chaque ligne contient un rseau de destination, un port de sortie, et le
prochain
routeur
relaie
vers
ce
rseau
de
destination.
A la rception d'un datagramme, les noeuds intermdiaires (ou routeurs) dterminent le prochain relais (ou next-hop)
le plus appropri pour que le paquet rallie sa destination. Ensuite l'adresse mac destination (niveau 2 du model OSI) du
datagramme est remplace par l'adresse mac du routeur relaie (ou next-hop), et l'adresse mac source du datagramme
est remplace par l'adresse mac du routeur courant, laissant sans changement les adresses ip (niveau 3 du model OSI)
du datagramme afin que le prochain routeur effectue les mme oprations sur le paquet pour les sauts suivants. Ce
calcul fastidieux est effectu sur tous les datagrammes d'un mme flux, et cela autant de fois qu'il y a de routeurs
intermdiaires traverser. Il est donc gourmand en terme de ressource machine. Le mode non connect du protocole
IP, qui tait initialement l'un de ses atouts, en particulier pour sa scalabilit, est devenu aujourd'hui un frein son
volution.
4 - La commutation de labels
Lorsqu'un paquet arrive dans un rseau MPLS (1). En fonction de la FEC auquelle appartient le paquet, l'ingress node
consulte sa table de commutation (2) et affecte un label au paquet (3), et le transmet au LSR suivant (4).
Lorsque le paquet MPLS arrive sur un LSR [1] interne du nuage MPLS, le protocole de routage fonctionnant sur cet
quipement dtermine dans la base de donnes des labels LIB (Label Base Information), le prochain label appliquer
ce paquet pour qu'il parvienne jusqu' sa destination [2]. L'quipement procde ensuite une mise jour de l'en-tte
MPLS (swapping du label et mise jour du champ TTL, du bit S) [3], avant de l'envoyer au noeud suivant (LSR ou
l'egress node) [4]. Il faut bien noter que sur un LSR interne, le protocole de routage de la couche rseau n'est jamais
sollicit.
Enfin, une fois que le paquet MPLS arrive l'egress node [1], l'quipement lui retire toute trace MPLS [2] et le
transmet
la
couche
rseau.
5 - Principes MPLS
Base sur la permutation d'tiquettes, un mcanisme de transfert simple offre des possibilits de nouveaux paradigmes
de contrle et de nouvelles applications. Au niveau d'un LSR (Label Switch Router) du nuage MPLS, la permutation
d'tiquette est ralise en analysant une tiquette entrante, qui est ensuite permute avec l'tiquette sortante et
finalement envoye au saut suivant. Les tiquettes ne sont imposes sur les paquets qu'une seule fois en priphrie du
rseau MPLS au niveau du Ingress E-LSR (Edge Label Switch Router) o un calcul est effectu sur le datagramme afin
de lui affecter un label spcifique. Ce qui est important ici, est que ce calcul n'est effectu qu'une fois. La premire fois
que le datagramme d'un flux arrive un Ingress E-LSR. Ce label est supprim l'autre extrmit par le Egress E-LSR.
Donc le mcanisme est le suivant: Le Ingress LSR (E-LSR) recoit les paquets IP, ralise une classification des paquets,
y assigne un label et transmet les paquets labelliss au nuage MPLS. En se basant uniquement sur les labels, les LSR
du nuage MPLS commutent les paquets labelliss jusqu' l'Egress LSR qui supprime les labels et remet les paquets
leur
destination
finale.
L'affectation des tiquettes aux paquets dpend des groupes ou des classes de flux FEC (forwarding quivalence
classes). Les paquets appartenant une mme classe FEC sont traits de la mme manire. Le chemin tabli par MPLS
appel LSP (Label Switched Path) est emprunt par tous les datagrammes de ce flux. L'tiquette est ajoute entre la
couche 2 et l'en-tte de la couche 3 (dans un environnement de paquets) ou dans le champ VPI/VCI (identificateur de
chemin virtuel/identificateur de canal virtuel dans les rseaux ATM). Le switch LSR du nuage MPLS lit simplement les
tiquettes, applique les services appropris et redirige les paquets en fonction des tiquettes. Ce schma de
consultation et de transfert MPLS offre la possibilit de contrler explicitement le routage en fonction des adresses
source et destination, facilitant ainsi l'introduction de nouveaux services IP. Un flux MPLS est vu comme un flux de
niveau
2.5
appartenant niveau
2
et
niveau
3
du
modle
de
l'OSI.
6 - Label
Un label a une signification locale entre 2 LSR adjacents et mappe le flux de trafic entre le LSR amont et la LSR aval. A
chaque bond le long du LSP, un label est utilis pour chercher les informations de routage (next hop, lien de sortie,
encapsulation, queueing et scheduling) et les actions raliser sur le label : insrer, changer ou retirer. La figure ci
dessous, dcrit la mise en oeuvre des labels dans les diffrentes technologies ATM, Frame Relay, PPP, Ethernet et
HDLC. Pour les rseaux Ethernet, un champ appel shim a t introduit entre la couche 2 et la couche 3. Sur 32 bits, il
a une signification d'identificateur local d'une FEC. 20 bits contiennent le label, un champ de 3 bits appel Classe of
Service (CoS) sert actuellement pour la QoS, un bit S pour indiquer s'il y a empilement de labels et un dernier champ,
le TTL sur 8 bits (mme signification que pour IP). L'empilement des labels permet en particulier d'associer plusieurs
contrats
de
service
un
flux
au
cours
de
sa
travers
du
rseau
MPLS.
La distribution implicite de labels aux LSR est ralise grce au protocole LDP (Label Distribution Protocol). LDP dfinit
une suite de procdures et de messages utiliss par les LSR pour s'informer mutuellement du mapping entre les labels
et le flux. Les labels sont spcifis selon le chemin " Hop By Hop " dfini par l'IGP (Interior Gateway Protocol) dans le
rseau. Chaque noeud doit donc mettre en oeuvre un protocole de routage de niveau 3, et les dcisions de
routage sont
prises
indpendamment
les
unes
des
autres.
LDP est bi-directionnel et permet la dcouverte dynamique des noeuds adjacents grce des messages Hello changs
par UDP. Une fois que les 2 noeuds se sont dcouverts, ils tablissent une session TCP qui agit comme un mcanisme
de transport fiable des messages d'tablissement de session TCP, des messages d'annonce de labels et des messages
de
notification.
8 - Explicit Routing
L'Explicit Routing est la solution MPLS pour faire du Traffic Engineering dont l'objectif est le suivant :
utiliser efficacement des ressources du rseau
viter les points de forte congestion en rpartissant le trafic sur l'ensemble du rseau. En effet, le plus court
chemin dtermin par le routage classique IP pour atteindre une destination peut ne pas tre le seul chemin
possible et certains chemins alternatifs peuvent tre sous-utiliss alors que le plus court chemin est sur-utilis.
Historiquement, le Traffic Engineering a t ralis grce des mtriques de liens associes des protocoles de
routage internes (RIP, OSPF, IS-IS). A la fin des annes 90, il a galement t possible de faire du Traffic Engineering
avec des technologies de niveau 2 telles que ATM et Frame Relay. Aujourd'hui, MPLS merge comme un nouveau
mcanisme de Traffic Engineering en offrant une plus grande flexibilit de routage IP (bande passante, QoS,...), grce
l'Explicit Routing. Dans ce cas, le LSP n'est plus dtermin chaque bond comme pour l'implicit routing : c'est
l'ingress node qui choisit le chemin de bout en bout. Au niveau des LSR en coeur de rseau, seul le label MPLS est
analys
(pas
l'en-tte
du
datagramme
IP).
L'Explicit Routing permet un oprateur de faire du Traffic Engineering en imposant au rseau des contraintes sur les
flux, du point source jusqu'au point destination. Ainsi, des routes autres que le plus court chemin peuvent tre
utilises. Le rseau dtermine lui-mme le chemin en suivant les tapes ci-dessous :
connaissance de l'tat du rseau : topologie, bande passante relle d'un lien, bande passante utilise, bande
passante restante. Des extensions ont t apportes aux protocoles de routage OSPF et IS-IS car la distribution
dynamique des bases de donnes tait limite aux noeuds adjacents et une seule mtrique.
calcul d'un chemin rpondant aux contraintes spcifies. Les extensions d'OSPF et d'IS-IS sont ncessaires.
tablissement du ER-LSP (Explicitly Routed Path). La source connat le chemin complet de l'ingress node
l'egress node et c'est elle qui spcifie les LSR l'intrieur du LSP. Deux options de signalisation spcifies pour
l'tablissement du LSP : RSVP ou CR-LDP (Constraint-Based Routing LDP) :
CR-LDP est l'alternative RSVP; il est jug plus fiable dans la mesure o il met en oeuvre TCP (orient
connexion). De plus, CR-LDP peut interfonctionner avec LDP et utilise les messages LDP pour signaler les
diffrentes contraintes. Les fonctions de CR-LDP sont ralises par des instructions matrielles (asics) ne
ncessitant pas de frquents rafrachissements, contrairement RSVP dont les fonctions sont ralises par le
logiciel ncessitant de frquents messages de rafrachissement.
envoi du trafic sur le chemin trouv
supervision de l'tat des LSP et le transmet l'IGP
r-optimisation des LSP quand ncessaire
9 - Support de la QoS
9.1 - Signalisation et QoS
L'intrt principal de MPLS est de permettre de se passer des couches infrieures ATM, Ethernet, PPP, Frame
Relay et de fournir directement la couche IP un mode connect. Vu les similitudes qu'il y a entre traiter un "
label " et traiter un champ VPI/VCI de cellule ATM, la majorit des premires implmentations rutilisent un coeur
de commutateur ATM. De fait, pour les constructeurs d'quipements, il est relativement facile de transformer un
commutateur PNNI/ATM, en commutateur/routeur MPLS/IP de coeur de rseau : ceci revient remplacer la
couche logicielle du plan de commande par une " couche logicielle MPLS ", c'est dire remplacer PNNI Signalling
par
LDP
(Label
Distribution
Protocol)
et
PNNI
Routing
par
OSPF
(ou
IS-IS,
etc.).
LDP est le protocole de signalisation qui permet d'affecter des labels un chemin au sein d'un rseau. En ce sens,
il correspond un protocole de signalisation et d'un point de vue fonctionnel s'apparente PNNI Signalling.
Cependant, LDP ne contient pas de paramtres permettant de formuler une demande de ressources
l'tablissement d'un LSP (mme s'il est possible de demander un traitement spcifique pour tous les paquets
empruntant
un
mme
LSP,
selon
le
modle
DiffServ).
Deux approches ont t retenues l'IETF pour permettre d'associer des ressources et de garantir de la QoS sur
un LSP : CR-LDP pour Constraint based Routing LDP, dfinit des extensions LDP, et RSVP-Tunnels, dfinit des
extensions RSVP pour la commande de LSP. L'IETF a dcid de ne pas trancher entre ces deux approches
concurrentes et de laisser ce soin au march. Elles permettent toutes les deux d'associer de la ressource un
LSP. La premire peut le faire selon les deux modles " QoS ATM " (catgorie de service, paramtres de trafic et
de QoS), et " QoS IP " (modle Intserv), alors que la deuxime permet essentiellement de la " QoS IP ".
Une utilisation combine de LDP+CR-LDP, ou de RSVP-Tunnels permet donc d'tablir des LSP en leur associant de
la bande passante.
9.2 - Routage et QoS
Dans son expression la plus simple, MPLS utilise les fonctions de routage IP pour tablir un LSP : le message
d'tablissement est alors rout comme le serait n'importe quel autre paquet IP contenant la mme adresse
destination. Dans ce cas, le routage se fait " hop by hop ", chaque routeur dcidant par lui mme de l'interface de
sortie vers laquelle il envoie le message, indpendamment de ce que les routeurs prcdent ont pu choisir. Ce
mode de fonctionnement permet un oprateur d'tablir simplement un LSP entre deux extrmits de son rseau
(pratique dans le cadre des VPNs). De plus, un tel mode de fonctionnement permet de scuriser des LSP en
autorisant leur reroutage en cas de faute dans le rseau (comme pour des Soft PVC en PNNI).
L'inconvnient d'un routage " hop by hop " dans un environnement dynamique est qu'il y a un risque de cration
de boucles. Le problme des boucles en MPLS a fait l'objet de divers documents, sans que de relle solution soit
trouve : en routage " hop by hop ", on sait dtecter des boucles, on ne sait pas les viter compltement. Au
cours de l'tablissement, quand RSVP-Tunnels ou CR-LDP est utilis, MPLS permet d'tablir des LSP avec
ressources
associes,
automatiquement
travers
le
rseau.
En MPLS, un LSP auquel on veut associer de la bande passante, s'il est rout via le protocole de routage IP, suivra
la mme route que n'importe quel autre LSP vers la mme destination : la route qui minimise la somme des poids
administratifs (seul paramtre dclar par OSPF). Dans le cas de MPLS, les routeurs choisissent la route et
vrifient a posteriori que la ressource ncessaire l'tablissement du LSP est effectivement prsente sur cette
route. La probabilit que la route retenue ne dispose pas de la ressource est plus importante en MPLS qu'en PNNI.
OSPF et IS-IS n'ont pas t dfinis pour router des trafics ncessitant un certain niveau de QoS, ou un minimum
de bande passante. Ils ne fournissent donc pas un routeur IP les informations dont celui-ci aurait besoin pour
router un LSP en fonction de ce qui est signal en RSVP-Tunnels ou CR-LDP. Pour surmonter ces insuffisances, des
extensions ont t proposes pour OSPF et IS-IS (par exemple OSPF-TE: une extension au traffic engeneering )
pour leur permettre de diffuser au sein d'un rseau IP les informations de QoS dont les routeurs pourraient avoir
besoin pour router des LSP.
9.3 - Architecture pour la QoS
Deux types d'architectures sont tudies pour dfinir la QoS IP :
Integrated Services (IntServ)
Differential Services (DiffServ)
IntServ suppose que pour chaque flux demandant de la QoS, les ressources ncessaires sont rserves chaque
bond entre l'metteur et le rcepteur. IntServ requiert une signalisation de bout en bout, assure par RSVP, et
doit maintenir l'tat de chaque flux (messages RSVP, classification, policing et scheduling par flux de niveau 4).
IntServ permet donc une forte granularit de QoS par flux et pour cette raison, est plutt destin tre
implment
l'accs.
IntServ dfinit 2 classes de services :
Guaranteed : garantie de bande passante, dlai et pas de perte de trafic
Controlled Load : fournit diffrents niveaux de services en best effort
DiffServ, quant lui, est davantage destin tre appliqu en coeur de rseau oprateur. Les diffrents flux,
classifis selon des rgles prdfinies, sont agrgs selon un nombre limit de classes de services, ce qui permet
de minimiser la signalisation. DiffServ ne peut pas offrir de QoS de bout en bout et a un comportement " Hop By
Hop
".
DiffServ dfinit 2 classifications de service (Expedited, Assured) qui peuvent tre corrles aux classifications de
service
IntServ
(Guaranteed,
Controlled
Load).
DiffServ utilse les 6 premiers bits du champ TOS de l'entte IP afin de classifier le trafic dans des classes ou
contrats au niveau de l'Ingress-LSR. Ce champ s'appellera DS-Field dans DiffServ. Voir la comparaison dans les
deux figures ci dessus entre ces deux champs. Au niveau des LSR, DiffServ dfinit des PHB (Per Hop Behaviors)
afin de construire ces LSPs. Ainsi au niveau des Edges LSR, DiiServ utilise le champs DS-Field, et l'intrieur du
corps
MPLS,
il
invoque
les
PHBs.
MPLS est amen inter fonctionner avec DiffServ, car LDP supporte avant tout de la QoS faible granularit.
IntServ et DiffServ sont donc 2 mcanismes complmentaires permettant d'tablir une QoS consistante sur les
rseaux MPLS et non MPLS.
10 - VPN
Dfinitions (RFC2547):
Deux sites distincts ont une connectivit IP sur le mme backbone, seulement s'ils appartiennent un mme
VPN sur ce backbone.
Deux sites qui ne sont pas dans le mme backbone, n'ont aucune connectivit IP entre eux sur ce backbone.
Si tous les sites dans un VPN appartiennent la mme entreprise, alors il s'agit d'un intranet.
Si tous les sites dans un VPN appartiennent diffrentes entreprises, alors il s'agit d'un extranet.
Un site peut tre dans plusieurs VPN: Dans un intranet et dans un, ou plusieurs extranets.
Les offres d'un service VPN IP rpondent aux besoins des entreprises ncessitant:
Un service de rseau IP priv sur une infrastructure de rseau IP public.
Utilisant la couche rseau IP, niveau 3.
Une scalabilit aise.
Possibilit d'utilisation d'un adressage priv sur un rseau public.
QoS.
Accs contrl et tanche vis vis des autres flux sur l'infrastructure public.
Les informations de routage l'intrieur d'un VPN sont distribues de la manire suivante :
du site client vers le VBG (VPN Border Gateway) source : via RIP, OSPF ou en routage statique
Le VBG source applique 2 labels au paquet de data lorsqu'un VPN est utilis (Cisco utilse une autre methode: La VPNIP@ = 96 bits: 64 bits identifiant le VPN et 32 bits de l'@ IP-V4 classique).
le premier label (extrieur) identifie le chemin vers le VBG destination, et change chaque bond
le second label (intrieur) spcifie le VPN-ID attribu au VPN et n'est pas modifi entre le VBG source et le VBG
destination
Cette
paire
de
labels
permet
d'implmenter
aisment
les
mcanismes
des
VPN
dans
MPLS:
11 - Traffic Engineering
Les motivations initiales pour la dfinition de l'architecture MPLS taient de doter le monde IP d'un mode connect et
ainsi d'amliorer les performances des routeurs en traitant les paquets IP directement au niveau 2 (commutation) sans
avoir remonter systmatiquement au niveau 3 (routage) chaque bond. En effet, commuter un paquet IP partir
d'un " label " revient utiliser le label entrant comme pointeur dans un tableau dont la case correspondante contient
l'interface de sortie vers laquelle le paquet doit tre envoy, ainsi que le nouveau label lui affecter. Une telle
opration, qui correspond exactement au traitement du champ VPI/VCI d'une cellule entrant dans un commutateur
ATM, est priori beaucoup plus simple que l'opration classique de routage d'un paquet IP.
Ceci tant, les performances des routeurs IP tant devenues ce qu'elles sont, l'argument de l'augmentation des
performances des commutateurs/routeurs MPLS/IP perd un peu de son intrt : les algorithmes de routage de paquets
les plus rcents offrent des performances (en rapidit de traitement) quasi similaires celles d'une simple opration de
commutation. L'industrie a ds lors mis l'accent sur l'intrt de MPLS comme outil permettant le " Traffic Engineering ".
Par " Traffic Engineering MPLS ", il faut comprendre, tablissement de connexions " la demande ", " gestion de trafic
", gestion des routes, gestion des ressources, gestion de l'coulement de flux de trafic travers un rseau IP. La
possibilit de faire suivre des paquets IP un chemin travers le rseau ne correspondant pas forcment au chemin
que ces mmes paquets auraient suivi s'ils avaient t routs au niveau 3 (c'est dire partir des informations issues
du protocole de routage interne du rseau, i.e. RIP, OSPF, IS-IS, EIGRP, etc.), ceci afin de mieux grer les ressources
du rseau ". En effet, via un Label Switched Path (LSP), MPLS permet d'imposer le chemin que les paquets IP doivent
suivre
pour
atteindre
une
destination
donne.
Un
LSP
est
donc
unidirectionnel.
MPLS et ses LSPs constituent ds lors un outil de gestion et d'optimisation de l'utilisation des ressources d'un rseau IP
: les LSP sont monts par voie de gestion l'avance par l'oprateur selon un chemin que celui-ci peut avoir
pralablement
choisi
et
dtermin....
Une utilisation " Traffic Engineering " de LSP MPLS s'apparente la fonction Soft PVC unidirectionnel (contrairement
un LSP, un VC peut aussi tre bidirectionnel) qui existe en commutation ATM. Pour tablir un Soft PVC, l'oprateur se
contente gnralement d'identifier par voie de gestion les extrmits qu'il veut joindre. La connexion est ensuite
tablie automatiquement entre ces deux extrmits, la route que cette connexion suit travers le rseau tant
dtermine par les lments de coeur de rseau. Dans le cas de PNNI, la spcification laisse le routage d'un Soft PVC
sous la responsabilit des noeuds ATM. Ceci tant, la majorit des MIB propritaires permettent un oprateur de
spcifier lui-mme s'il le dsire le chemin qu'un Soft PVC doit suivre travers le rseau.
La principale diffrence entre un LSP MPLS et un Soft PVC ATM est qu'il est possible d'associer un Soft PVC une
catgorie de service ATM, ainsi que des paramtres de trafic et de QoS. Dans un rseau MPLS simple, tablir des LSP
revient alors tablir des Soft PVC UBR unidirectionnels : on marque un chemin travers le rseau sans lui associer
de ressources.
12 - Agrgation de flux
L'une des forces annonces de MPLS est sa capacit d'agrgation de flux : la possibilit de runir le trafic entrant dans
un routeur via plusieurs LSP dans un seul et unique LSP sortant. Une telle configuration correspond monter une
connexion multi-point point (fonction de VC merge en ATM), comparable un arbre invers dont le routeur de sortie
serait la racine. Cette fonction permet de rduire au maximum le nombre de connexions que les routeurs de coeur de
rseau
ont
grer.
Dans ce mme but, MPLS introduit un concept de hirarchie au niveau des LSP et d'empilement des labels. Il est donc
possible de construire des LSP, encapsuls dans un autre LSP, lui-mme encapsul dans un LSP, etc. Ce concept
d'encapsulation rappelle videmment la possibilit en ATM de mettre des VC dans des VP. Cependant, en MPLS, le
nombre de niveau d'encapsulation (ou de hirarchie) n'est a priori pas limit 2.
13 - Applications
Les applications les plus courantes du MPLS sont les suivantes :
L'ingnierie de trafic est active par des mcanismes MPLS permettant de diriger le trafic via un chemin
spcifique, qui n'est pas ncessairement le chemin le moins coteux. Les administrateurs de rseau peuvent
mettre en oeuvre des politiques visant assurer une distribution optimale du trafic et amliorer l'utilisation
globale du rseau.
La bande passante garantie constitue une amlioration forte valeur ajoute par rapport aux mcanismes
d'ingnierie de trafic traditionnels. MPLS permet aux fournisseurs de services d'allouer des largeurs de bande
passante et des canaux garantis. La bande passante garantie permet galement la comptabilit des ressources
QoS (qualit de service) de manire organiser le trafic 'prioritaire' et 'au mieux', tels que la voix et les
donnes.
Le reroutage rapide permet une reprise trs rapide aprs la dfaillance d'une liaison ou d'un noeud. Une telle
rapidit de reprise empche l'interruption des applications utilisateur ainsi que toute perte de donnes.
Les rseaux privs virtuels MPLS simplifient considrablement le dploiement des services par rapport aux VPN
IP traditionnels. Lorsque le nombre de routes et de clients augmente, les VPN MPLS peuvent facilement monter
en charge, tout en offrant le mme niveau de confidentialit que les technologies de niveau 2. Ils peuvent
galement transporter des adresses IP non-uniques travers un domaine public.
La fonction Classe de service (CoS) MPLS assure que le trafic important est trait avec la priorit adquate sur
le rseau et que les exigences de latence sont respectes. Les mcanismes de qualit de service IP peuvent tre
mis en oeuvre de faon transparente dans un environnement MPLS.
1 - Introduction
2 - Matriel et configurations utiliss
1 - Introduction
Dans les rseaux IP traditionnels, le routage des paquets s'effectue en fonction de l'adresse de destination contenue
dans l'entte de niveau 3. Chaque routeur, pour dterminer le prochain saut (next-hop), consulte sa table de routage
et dtermine l'interface de sortie vers laquelle envoyer le paquet. Le mcanisme de recherche dans la table de routage
est consommateur de temps CPU, et avec la croissance de la taille des rseaux ces dernires annes, les tables de
routage des routeurs ont constamment augment. Il tait donc ncessaire de trouver une mthode plus efficace pour
le routage des paquets. Le but de MPLS tait l'origine de donner aux routeurs IP une plus grande puissance de
commutation, en basant la dcision de routage sur une information de label (ou tag) insr entre le niveau 2 (DataLink Layer) et le niveau 3 (Network Layer). La transmission des paquets tait ainsi ralise en switchant les paquets en
fonction
du
label,
sans
avoir
consulter
l'entte
de
niveau
3
et
la
table
de
routage.
Toutefois, avec le dveloppement de techniques de commutation comme CEF (Cisco Express Forwarding) et la mise au
point de nouveaux ASIC (Application Specific Interface Circuits), les routeurs IP ont vu leurs performances amliores
sans le recours MPLS. L'intrt de MPLS n'est actuellement plus la rapidit mais l'offre de services qu'il permet, avec
notamment les rseaux privs virtuels (VPN) et le Traffic Engineering (TE), qui ne sont pas ralisables sur des
infrastructures IP traditionnelles. Ce document se focalise principalement sur la prsentation des principes de MPLS et
une tude approfondie de MPLS/VPN. Des notions essentielles de Traffic Engineering sont galement prsentes en
dernire partie.
Les deux pods sont connects entre eux par les deux routeurs R1, au moyen d'une interface FastEthernet.
Les
quipements
-
mis
en
jeu
sont
Modle
Modle
Modle
des
routeurs
3640
3620
des
familles
:
:
2600
R1,
:
2600
et
R2,
R4,
R6,
3600
:
R3
R5
R7
Tous les routeurs utilisent OSPF comme protocole de routage interne (IGP) et toutes les interfaces sries ont t
configures pour fonctionner avec MPLS. Les configurations des routeurs pour cette partie sont fournies en
Annexe
1.
La
convention
utilise
pour
les
Interface
Loopback0
:
Subnet
entre
deux
routeurs
Rx
- Adresse IP pour Rx : 10.10.xy.x et Ry : 10.10.xy.y.
adresses
10.10.x.x
et
Ry
IP
(x
pour
<
est
y)
la
suivante:
routeur
Rx
:
10.10.xy.0/24
;
;
schma
suivant
montre
un
exemple
de
label
swapping
Les routeurs MPLS situs la priphrie du rseau (Edge LSR), qui possdent la fois des interfaces IP
traditionnelles et des interfaces connectes au backbone MPLS, sont chargs d'imposer ou de retirer les labels des
paquets IP qui les traversent. Les routeurs d'entres, qui imposent les labels, sont appels Ingress LSR, tandis
que
les
routeurs
de
sortie,
qui
retirent
les
labels,
sont
appels
Egress
LSR.
Le schma suivant montre le rle des diffrents routeurs en fonction de leur emplacement dans le rseau MPLS:
critres
-
de
ressources
MP-BGP
(MultiProtocol
Border
et
Gateway
d'utilisation
Protocol)
pour
des
l'change
de
liens
routes
;
VPN.
Les deux derniers protocoles seront abords dans leurs sections respectives (Traffic Engineering et Virtual Private
Networks). Remarque : aucun label n'est affect pour les routes apprises par eBGP. Il existe deux mthodes pour
propager les labels entre LSR: upstream et downstream. Le schma suivant explicite la notion d'upstream
neighbor
et
de
downstream
neighbor
par
rapport
un
rseau
IP
donn:
Sur le schma ci-dessus, le routeur A est un upstream neighbor par rapport au routeur B pour le rseau
192.168.2.0. Le routeur A est aussi downstream neighbor par rapport au routeur B pour le rseau 192.168.1.0.
Une mthode de distribution des labels dite downstream indique que la propagation des rseaux se fait du
routeur
le
plus
proche
au
routeur
le
plus
loign
(downstream
vers
upstream).
La mthode downstream, avec deux variantes: unsollicited downstream et downstream on demand. Dans la
premire variante, les LSR downstream propagent systmatiquement tous leurs labels leurs voisins. Dans la
deuxime, les LSR upstreams demandent explicitement aux LSR downstreams de leur fournir un label pour le
subnet IP demand. Le mode non sollicit est utilis dans le cas d'interfaces en mode trame, le downstream on
demand
tant
utilis
par
les
LSR
ATM
(mode
cellule).
-
Unsollicited
Downstream
Downstream
on
demand
Pour changer les labels correspondants aux routes unicast apprises par un IGP, les routeurs Cisco emploient TDP
(Tag Distribution Protocol), utilisant TCP sur le port 711. Ce protocole est un protocole propritaire dfini par Cisco
Systems. Le protocole dfini par l'IETF est LDP (Label Distribution Protocol), qui utilise TCP sur le port 646. Bien
que ces deux protocoles soient fonctionnellement identiques, ils sont incompatibles entre eux, cause de
diffrences dans le format des paquets. A l'avenir, Cisco IOS pourra utiliser soit TDP ou LDP, ou bien les deux
simultanment.
Deux routeurs sont configurs pour changer des labels par TDP avec la commande tag-switching ip , spcifie
sur
les
interfaces
qu'ils
ont
en
commun.
Il est possible de connatre tous les voisins TDP d'un routeur en utilisant la commande show tag-switching tdp
neighbor :
L10-R1# sh tag tdp neigh
Peer TDP Ident: 10.10.3.3:0; Local TDP Ident 10.10.1.1:0
TCP connection: 10.10.3.3.11004 - 10.10.1.1.711
State: Oper; PIEs sent/rcvd: 1727/1740; ; Downstream
Up time: 1d01h
TDP discovery sources:
Serial0/0
Addresses bound to peer TDP Ident:
10.10.3.3 10.10.35.3 10.10.13.3 10.10.23.3
Peer TDP Ident: 10.10.2.2:0; Local TDP Ident 10.10.1.1:0
TCP connection: 10.10.2.2.11006 - 10.10.1.1.711
State: Oper; PIEs sent/rcvd: 1607/1616; ; Downstream
Up time: 23:23:28
TDP discovery sources:
Serial0/1
Addresses bound to peer TDP Ident:
10.10.2.2 100.10.20.20 10.10.24.2 10.10.12.2
Chaque voisin est list avec toutes les adresses IP qui lui appartiennent. La mthode d'allocation des labels
(unsollicited downstream, downstream on demand) est galement indique. Comme les interfaces des routeurs de
cet exemple sont de type srie, il s'agit d'interfaces en mode trame et le mode unsollicited downstream est
employ.
Pour pouvoir tablir correctement une adjacence TDP, les deux voisins doivent tre convenablement configurs.
La commande show tag-switching tdp discovery permet de s'assurer du bon tablissement de l'adjacence :
L10-R1# sh tag tdp disc
Local TDP Identifier:
10.10.1.1:0
TDP Discovery Sources:
Interfaces:
Serial0/0: xmit/recv
TDP Id: 10.10.3.3:0
Serial0/1: xmit/recv
10.10.57.5
10.10.35.3
10.10.23.2
10.10.24.4
10.10.46.6
0]
0]
0]
0]
Le label MPLS affich pour chaque hop correspond au label en entre du routeur. Le champ Exp (cod sur
3 bits) est similaire au champ TOS de l'entte IP, mais n'est pas employ ici. Dans cet exemple, le chemin
pour atteindre R6 partir de R7 est { R5, R3, R2, R4, R6 }. Le schma suivant montre comment les paquets
sont
achemins
de
R7
jusqu'
R6
:
Les
routeurs
R5,
R3,
R2
et
R4
commutent
les
paquets
uniquement
sur
l'entte
MPLS
l'entte IP n'est pas examine, et les routeurs ne consultent que leur table TFIB (leur table de routage n'est
pas utilise). On constate que les paquets arrivant sur le routeur R6 pour le rseau 10.10.6.6 ne sont pas
taggus. Ce phnomne, appel Penultimate Hop Popping, permet au routeur auquel sont rattachs des
rseaux sur des interfaces non MPLS d'viter un lookup dans la table TFIB. Le Penultimate Hop Popping est
dcrit plus prcisement dans le paragraphe suivant.
3.7 - Penultimate Hop Popping
Un LSR "egress" annonant un rseau, qui lui est soit directement connect, soit rattach (appris par IGP, EGP,
routage statique...) par une interface non taggue, n'a pas besoin de recevoir de paquets taggus pour atteindre
ce rseau. En effet, si les paquets reus taient taggus, le routeur egress devrait d'abord dterminer l'interface
de sortie grce la table TFIB, puis effectuer une recherche dans la table de routage IP. L'opration de recherche
sur le label dans la TFIB est inutile, car dans tous les cas le routeur devra effectuer une recherche dans la table de
routage. Le routeur egress annonce donc ces rseaux IP avec le label "implicit-null" ses voisins. Un LSR ayant
comme label de sortie "implicit-null" aura ainsi pour but de dpiler le premier label du paquet et de faire suivre le
paquet sur l'interface de sortie spcifie. Le routeur egress n'aura alors plus qu'une recherche faire dans sa
table
de
routage.
Un exemple de Penultimate Hop Popping entre L10-R1 et L10-R2 est donn ci-dessous:
L10-R1# sh tag for 10.10.2.2
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
23 Pop tag 10.10.2.2/32 145198 Se0/1 point2point
L10-R1# sh ip cef 10.10.2.2
10.10.2.2/32, version 593, cached adjacency to Serial0/1
0 packets, 0 bytes
tag information set
local tag: 23
via 10.10.12.2, Serial0/1, 0 dependencies
next hop 10.10.12.2, Serial0/1
valid cached adjacency
tag rewrite with Se0/1, point2point, tags imposed: {}
Le rseau 10.10.2.2/32 correspond l'interface Loopback0 du routeur L10-R2, connect par un lien srie L10R1. On constate que le tag de sortie (Outgoing tag) pour 10.10.2.2/32 est dclar sous le terme pop tag pour
signaler l'action de dpilement du premier label.
3.8 - Rtention des labels
Afin d'acclrer la convergence du rseau lors d'un changement de topologie (lien dfectueux, dysfonctionnement
d'un routeur), les LSR conservent dans leur table TIB la liste des labels annoncs pour chaque rseau IP par leurs
voisins TDP, y compris de ceux n'tant pas les next-hops choisis par l'IGP. Ainsi, en cas de perte d'un lien ou d'un
noeud, la slection d'un nouveau label de sortie est immdiate : en effet, il suffit au routeur d'lire un nouveau
next-hop et de slectionner l'entre correspondante dans la TIB, puis de mettre jour la TFIB. Ce mode de
fonctionnement est appel mode libral (liberal mode). L'avantage de ce procd est naturellement une
convergence plus rapide lorsque les informations de routage au niveau 3 changent, avec pour inconvnients que
davantage de mmoire est alloue dans les routeurs et que des labels supplmentaires sont utiliss. Le mode
libral
est
appliqu
dans
le
cas
d'interfaces
fonctionnant
en
mode
trame.
Il existe un autre mode appel mode conservatif, qui correspond au downstream on demand, utilis par les LSR
ATM. Pour atteindre un subnet donn au-del d'une interface de type cellule , les LSR ATM demandent leurs
voisins downstream de leur fournir un label pour chaque couple (interface d'entre, subnet IP). La problmatique
des rseaux ATM est aborde dans le paragraphe suivant.
3.9 - MPLS sur ATM
Il existe deux manires d'implmenter MPLS sur des rseaux de type ATM. La premire consiste mettre en place
un backbone constitu de switches purement ATM, c'est--dire sans aucune connaissance de MPLS ou du routage
IP. Dans ce cas, des PVCs sont simplement tablis entre les routeurs MPLS et les labels sont alors encapsuls
entre l'entte LLC/SNAP et l'entte IP. La deuxime mthode consiste mettre en oeuvre MPLS sur des switches
ATM dits IP-aware , c'est--dire ayant connaissance de la topologie IP grce un protocole de routage, et o
l'information de label est encode dans les champs VPI/VCI. Ces switches sont alors appels ATM LSR. Ce
paragraphe aborde les spcificits d'un backbone MPLS compos de LSR ATM par rapport un backbone
purement IP, notamment dans les mcanismes de distribution des labels. Le MPLS sur ATM natif ayant un
fonctionnement similaire des LSR traditionnels , cette architecture ne sera pas tudie ici. Pour distribuer des
labels MPLS entre LSR ATM, les protocoles TDP / LDP en mode downstream on demand sont utiliss. Si le mode
unsollicited downstream tait employ, comme dans le cas de LSR non ATM, on aurait le scnario suivant :
Dans cet exemple, le routeur C aurait fourni au switch ATM le label 4 pour atteindre le subnet 192.168.1.0/24. On
remarque alors que si des paquets IP sont envoys par les routeurs A et B destination de ce subnet, les cellules
ATM reues par le routeur C ont toutes pour label 4. Le label tant encod dans les champs VPI / VCI pour des
LSR ATM, il y a mlange des cellules composant les paquets IP, sans moyen de resynchronisation (impossible de
distinguer les cellules les unes des autres pour reformer les paquets). La solution mise en oeuvre pour viter le
mlange des cellules est d'affecter un label en fonction du subnet de destination et de l'interface d'entre. Dans ce
cas de figure, les LSR upstream demandent leurs voisins downstream de leur fournir un label pour chaque
subnet IP et pour chacune de leur interface d'entre. Ce mode de fonctionnement est donc appel downstream
on demand . Il est noter que le choix du mode de distribution des labels est fix automatiquement de manire
optimale par les routeurs (en fonction du type des interfaces), sans possibilit de modification au niveau de la
configuration.
Le schma ci-dessous montre le fonctionnement des LSR ATM avec un label de sortie dfini pour chaque couple
(interface
d'entre,
subnet
IP)
:
Sur cet exemple, le switch ATM, fonctionnant en mode downstream on demand, a demand au routeur C de lui
fournir deux labels (2 et 6) pour atteindre le subnet 192.168.1.0 : un label diffrent est alors utilis en fonction de
l'interface
d'entre
pour
atteindre
le
mme
subnet.
L'allocation de plusieurs labels, mapps dans les champs VPI/VCI, peut rapidement dpasser les limites des
quipements ATM. En effet, bien que les champs VPI/VCI soient cods sur 32 bits, il peut exister des limitations
hardware, qui dans certains cas, ne permettent pas d'utiliser plus d'un certain nombre de VC par interface. Le VC
Merge permet de rduire le nombre de labels utiliss sur une interface ATM, tout en gardant les paquets IP
synchroniss. Le principe de cette mthode est de grouper les cellules composant un paquet IP dans un buffer et
de ne les mettre sur l'interface de sortie que lorsque tout le paquet a t reu. Les cellules sont mises dans
l'ordre et le LSR downstream les recevant peut donc reconstituer le paquet dans risque de mlange, grce au
champ
End
Of
Frame
de
l'entte
AAL5.
L'avantage de cette mthode est de pouvoir affecter un label unique pour chaque subnet IP trait. Toutefois, la
bufferisation des paquets augmente la latence de transmission des paquets, et le dbit de l'interface risque d'tre
limit.
3.10 - Pile de labels (label stacking)
Chaque paquet MPLS est susceptible de transporter plusieurs labels, formant ainsi une pile de labels, qui sont
empils et dpils par les LSR. Cette possibilit d'empiler des labels, dsigne sous le terme de Label Stacking,
est
utilise
par
le
Traffic
Engineering
et
MPLS
/
VPN.
Lorsqu'un LSR commute un paquet, seul le premier label est trait, comme le montre la figure suivante:
La
label
MPLS
signification
occupe
des
octets
diffrents
(32-bits)
et
champs
se
prsente
est
sous
donnes
la
forme:
ci-dessous:
Label
(20
bits)
- Exp (3 bits): Champ exprimental, utilis pour la QoS. Equivalent au champ TOS de l'entte IP ;
- S (1 bit): Champ "bottom of stack". Lorsque ce bit est 1, le bas de la pile est atteint, et l'entte de niveau 3
est
plac
juste
aprs.
- TTL (8 bits): Ce champ a le
mme rle que le champ TTL de l'entte IP.
Le format des labels MPLS est gnrique et peut notamment tre utilis sur Ethernet, 802.3, PPP, Frame-Relay et
sur des PVC ATM (backbone ATM natif). En cas d'emploi d'un mdium non support (par ex. ISDN), des tunnels
GRE peuvent tre mis en place. L'adjacence TDP peut alors s'tablir entre les deux extrmits du tunnel et les
paquets labelliss sont encapsuls dans IP.
3.12 - Configuration d'un routeur LSR
Cette partie, axe sur la configuration IOS, indique la liste des diffrentes tapes devant tre suivies pour
configurer MPLS sur un backbone IP. Les configurations rsultantes sont fonctionnelles bien que dnues d'intrt
pratique, aucun service spcifique MPLS n'tant mis en oeuvre. Elles permettent toutefois d'apprhender les
changements induits par MPLS au niveau des commandes IOS par rapport des routeurs purement IP. Les
configurations minimales MPLS ainsi dcrites peuvent tre consultes en Annexe 1 de ce document.
Les routeurs R6 et R7 sont placs respectivement dans les VPN "GREEN" et "RED". Les routeurs R4 et R5 ont
chacun trois interfaces Loopback places dans les VRF GREEN , RED et BLUE . Au niveau du backbone
MPLS, les routeurs R1 R5 emploient OSPF (aire 0) comme protocole de routage interne.
4.2 - Routeurs P, PE et CE
Une terminologie particulire est employe pour dsigner les routeurs (en fonction de leur rle) dans un
environnement
MPLS
/
VPN
:
- P (Provider) : ces routeurs, composant le coeur du backbone MPLS, n'ont aucune connaissance de la notion
VPN. Ils se contentent d'acheminer les donnes grce la commutation de labels ;
- PE (Provider Edge) : ces routeurs sont situs la frontire du backbone MPLS et ont par dfinition une ou
plusieurs
interfaces
relies
des
routeurs
clients
;
- CE (Customer Edge) : ces routeurs appartiennent au client et n'ont aucune connaissance des VPN ou mme
de la notion de label. Tout routeur traditionnel peut tre un routeur CE, quelle que soit son type ou la version
d'IOS
utilise.
de
Le
schma
ci-dessous
montre
l'emplacement
de
ces
routeurs
dans
une
architecture
MPLS
consulter grce une extension des commandes classiques. Par exemple, pour consulter la table de routage de la
VRF RED sur L10-R4, il suffit d'employer la commande show ip route vrf <vrf> :
L10-R4# sh ip route vrf RED
Gateway of last resort is not set
100.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
B 100.10.57.0/24 [200/0] via 10.10.5.5, 01:10:46
B 100.10.7.7/32 [200/0] via 10.10.5.5, 01:10:46
B 100.10.5.5/32 [200/0] via 10.10.5.5, 01:10:46
C 100.10.4.4/32 is directly connected, Loopback2
B 100.10.172.0/24 [200/0] via 10.10.5.5, 01:10:46
B 100.10.171.0/24 [200/0] via 10.10.5.5, 01:10:46
Si l'on examine la table de routage globale de L10-R4, on constate qu'il s'agit bien d'une table compltement
diffrente et indpendante :
L10-R4# sh ip route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
O 10.10.5.5/32 [110/2401] via 10.10.24.2, 01:04:51, Serial0/1
O 10.10.3.3/32 [110/1601] via 10.10.24.2, 01:04:51, Serial0/1
O 10.10.1.1/32 [110/1601] via 10.10.24.2, 01:04:51, Serial0/1
O 10.10.2.2/32 [110/801] via 10.10.24.2, 01:04:51, Serial0/1
C 10.10.4.4/32 is directly connected, Loopback0
O 10.10.12.0/24 [110/1600] via 10.10.24.2, 01:04:51, Serial0/1
O 10.10.13.0/24 [110/2400] via 10.10.24.2, 01:04:51, Serial0/1
O 10.10.23.0/24 [110/1600] via 10.10.24.2, 01:04:51, Serial0/1
C 10.10.24.0/24 is directly connected, Serial0/1
C 10.10.24.2/32 is directly connected, Serial0/1
O 10.10.35.0/24 [110/2400] via 10.10.24.2, 01:04:51, Serial0/1
La table CEF d'une VRF peut galement tre examine, au moyen de la commande show ip cef vrf <vrf>
<subnet> :
L10-R4# sh ip cef vrf RED 100.10.7.7
100.10.7.7/32, version 24, cached adjacency to Serial0/1
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Se0/1, point2point, tags imposed: {27 30}
via 10.10.5.5, 0 dependencies, recursive
next hop 10.10.24.2, Serial0/1 via 10.10.5.5/32
valid cached adjacency
tag rewrite with Se0/1, point2point, tags imposed: {27 30}
La table CEF permet donc de dterminer le Next-Hop, l'interface de sortie et les labels utiliss pour atteindre un
subnet particulier.
4.4 - Multiprotocol BGP (MP-BGP)
Le protocole MP-BGP est une extension du protocole BGP 4, et permettant d'changer des routes Multicast et des
routes
VPNv4.
MP-BGP
adopte
une
terminologie
similaire
BGP
concernant
le
peering
:
MPBGP
:
peering
entre
routeurs
- MP-eBGP : peering entre routeurs situs dans 2 AS diffrents.
d'un
mme
AS
dans les updates MP-BGP avec ce RD. Les RD affects aux diffrentes VRF existantes sur un PE peuvent tre
consults au moyen de la commande show ip vrf :
L10-R4# sh ip vrf
Name Default RD Interfaces
BLUE 100:1 Loopback1
GREEN 100:3 Serial0/0
Loopback3
RED 100:2 Loopback2
On constate que les interfaces connectes aux VRF sont galement listes par cette commande.
4.4.2 - Notion de RT (Route Target)
Le RD permet de garantir l'unicit des routes VPNv4 changes entre PE, mais ne dfinit pas la manire dont
les routes vont tre insres dans les VRF des routeurs PE. L'import et l'export de routes sont grs grce
une communaut tendue BGP (extended community) appele RT (Route Target). Les RT ne sont rien de
plus que des sortes de filtres appliqus sur les routes VPNv4. Chaque VRF dfinie sur un PE est configure
pour exporter ses routes suivant un certain nombre de RT. Une route VPN exporte avec un RT donn sera
ajoute dans les VRF des autres PE important ce RT. Par exemple, si la route VPN 2000:1:192.168.1.0/24 est
exporte par un routeur PE avec comme liste de RT 2000:500 et 2000:501, tous les autres routeurs PE ayant
une ou plusieurs VRF important au minimum un de ces deux RT ajouteront cette route dans leurs VRF
concernes.
La
configuration
simple
RT_import
(Avec
RT_VPN
pour
un
=
choisi
comme
VPN
consiste
RT_export
identifiant
appliquer
la
=
spcifique
rgle
RT_VPN
au
VPN).
Sur la figure ci-dessus, les 3 sites rouges appartiennent au mme VPN. Pour changer les routes entre tous
les
sites,
chaque
PE
importe
et
exporte
le
RT
500:1000.
Le schma suivant indique la marche suivre pour crer une topologie de type hub and spoke :
Dans ce exemple, le site vert est un site central (par ex. pour l'administration des diffrents VPN). Chacun
des 3 sites, appartenant un VPN diffrent (Rouge, Violet et Bleu) importe les routes du site central (RT
500:1001). Rciproquement, le site central importe les routes de tous les sites clients (RT 500:1000). Bien
que le site central ait accs tous les sites clients, ceux-ci ne peuvent se voir entre eux. En effet, aucune
relation de RT n'est dfinie entre les sites clients (aucun site n'importe ou n'exporte de route vers un autre).
Naturellement, comme le site vert voit les 3 sites clients, le plan d'adressage de ces sites doit tre
compatible (c'est--dire non recouvrant) au niveau des routes changes pour garantir l'unicit des routes
vis--vis du site central.
4.4.3 - Configuration d'une VRF
Les
VRF
sont
configures
sur
les
Nom
-
Filtres
sur
PE
de
l'import
avec
VRF
RD
-
routeurs
(Route
RT
RT
et
l'export
les
paramtres
(case-sensitive)
Distinguisher)
exports
imports
des
routes
suivants
;
;
;
;
(optionnel).
Le paramtrage d'une VRF TEST (avec un RD de 500:1000), exportant ses routes avec les RT 500:1 et
500:2 et important les routes avec les RT 500:1 et 500:3, serait le suivant :
ip vrf TEST
rd 500:1000
route-target export 500:1
route-target export 500:2
route-target import 500:1
route-target import 500:3
!
4.4.4 - Updates MP-BGP
En plus du RD et des RT, les updates MP-BGP contiennent d'autres informations, telles que le Site d'Origine
(SOO), l'adresse IP du PE annonant la route (PE nexthop) et le label VPN affect par ce PE.
la
propagation
des
routes
VPN.
Pour propager les Route-Target (RT), qui dfinissent l'appartenance aux VPN et qui sont des communauts
tendues BGP, la ligne neighbor <neighbor> sendcommunity extended doit tre utilise.
Dans le rseau de dmonstration MPLS/VPN, le routeur L10-R1 fait office de Route Reflector BGP. Sa
configuration est la suivante :
router bgp 10
no synchronization
no bgp default route-target filter
bgp log-neighbor-changes
bgp cluster-id 10
neighbor iBGP peer-group
no neighbor iBGP activate
neighbor iBGP remote-as 10
neighbor iBGP update-source Loopback0
neighbor iBGP soft-reconfiguration inbound
no auto-summary
!
address-family vpnv4
neighbor iBGP activate
neighbor iBGP route-reflector-client
neighbor iBGP send-community extended
iBGP
iBGP
iBGP
iBGP
!
Afin de faciliter l'ajout de nouveaux voisins, la notion de peer-group a t utilise. Un peer group est
dfini par un nom, et il est possible de fixer certaines proprits pour ce groupe : AS distant (remote-as),
interface source pour les updates (update-source), etc. Chaque voisin est ensuite ajout dans ce groupe avec
un commande du type: neighbor 10.10.5.5 peer-group iBGP . Dans cet exemple, toutes les commandes
appliques au groupe iBGP le seront pour le voisin 10.10.5.5.
4.4.6 - Vrification du fonctionnement de MP-BGP
Plusieurs commandes existent pour s'assurer du bon fonctionnement de BGP sur les routeurs. Par exemple,
pour connatre toutes les routes apprises par MP-BGP sur un routeur donn, la commande show ip bgp
vpnv4 all peut tre utilise :
L10-R4# sh ip bgp vpnv4 all
BGP table version is 129, local router ID is 10.10.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf BLUE)
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
Route Distinguisher: 100:2 (default for vrf RED)
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
*>i100.10.7.7/32 10.10.5.5 0 100 0 102 i
*>i100.10.57.0/24 10.10.5.5 0 100 0 ?
*>i100.10.171.0/24 10.10.5.5 0 100 0 102 i
*>i100.10.172.0/24 10.10.5.5 0 100 0 102 i
Route Distinguisher: 100:3 (default for vrf GREEN)
*>i100.10.3.3/32 10.10.3.3 0 100 0 ?
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
*> 100.10.6.6/32 100.10.46.6 1 32768 ?
*> 100.10.46.0/24 0.0.0.0 0 32768 ?
*> 100.10.46.6/32 0.0.0.0 0 32768 ?
*> 100.10.161.0/24 100.10.46.6 1 32768 ?
*> 100.10.162.0/24 100.10.46.6 1 32768 ?
Route Distinguisher: 100:2000
*>i100.10.3.3/32 10.10.3.3 0 100 0 ?
Si l'on souhaite se restreindre une VRF donne, la commande show ip bgp vpnv4 vrf <vrf> peut tre
employe :
L10-R4# sh ip bgp vpnv4 vrf RED
BGP table version is 129, local router ID is 10.10.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:2 (default for vrf RED)
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
*>i100.10.7.7/32 10.10.5.5 0 100 0 102 i
*>i100.10.57.0/24 10.10.5.5 0 100 0 ?
*>i100.10.171.0/24 10.10.5.5 0 100 0 102 i
*>i100.10.172.0/24 10.10.5.5 0 100 0 102 i
Les labels fournis dans les updates MP-BGP peuvent tre affichs au moyen de la commande sh ip bgp
vpnv4 [vrf <vrf> | all] tags :
router bgp 10
!
[...]
address-family ipv4 vrf RED
redistribute connected
neighbor 100.10.57.7 remote-as 102
neighbor 100.10.57.7 activate
no auto-summary
no synchronization
exit-address-family
[...]
!
L'interface reliant L10-R5 et L10-R7 tant paramtre comme suit (sur L10-R5):
interface Serial0/0.1 point-to-point
description Vers L10-R7
bandwidth 125
ip vrf forwarding RED
ip address 100.10.57.5 255.255.255.0
frame-relay interface-dlci 100
Chaque voisin devant tre actif en eBGP dans une VRF donn doit donc tre configur dans la section
address-family ipv4 vrf <vrf> correspondante. A titre indicatif, la configuration BGP de L10-R7 est fournie
ci-dessous:
router bgp 102
bgp log-neighbor-changes
network 100.10.7.7 mask 255.255.255.255
network 100.10.171.0 mask 255.255.255.0
network 100.10.172.0 mask 255.255.255.0
neighbor 100.10.57.5 remote-as 10
!
On constate donc que la configuration du routeur CE est tout fait classique, sans prsence de VRF ou de
toute autre notion de VPN.
4.5.2 - Configuration RIPv2
La configuration RIPv2 avec un routeur CE suit le mme principe qu'une configuration eBGP, mais les routes
apprises par RIP doivent tre rinjectes dans MP-BGP et rciproquement :
router rip
version 2
!
address-family ipv4 vrf GREEN
version 2
redistribute bgp 10 metric 1
network 100.0.0.0
no auto-summary
exit-address-family
!
[...]
router bgp 10
[...]
address-family ipv4 vrf GREEN
redistribute connected
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
[...]
L'interface reliant L10-R4 et L10-R6 est paramtre de la manire suivante (sur L10-R4):
interface Serial0/0
description Vers L10-R6
bandwidth 125
ip vrf forwarding GREEN
ip address 100.10.46.4 255.255.255.0
encapsulation ppp
no fair-queue
clockrate 125000
end
4.6 - Transmission des paquets IP
La transmission des paquets IP provenant des CE sur le backbone MPLS emploie la notion de label stacking. Pour
atteindre un site donn, le PE source encapsule deux labels : le premier sert atteindre le PE de destination,
tandis que le second dtermine l'interface de sortie sur le PE, laquelle est relie le CE. Le second label est appris
grce aux updates MP-BGP. Les tables CEF des routeurs peuvent tre consultes pour dterminer les labels
utilises. Par exemple, supposons que l'on souhaite connatre les tags employs pour atteindre l'adresse de
Loopback 100.10.5.5 configure sur le routeur L10-R5, et place dans la VRF RED . La consultation de la table
de routage de la VRF RED sur L10-R4 montre que le next-hop est bien L10-R5 (10.10.5.5):
L10-R4# sh ip route vrf RED
Gateway of last resort is not set
B
B
B
C
B
B
Le label utilis pour atteindre L10-R5 est dtermin grce la table CEF globale du routeur :
L10-R4# sh ip cef 10.10.5.5
10.10.5.5/32, version 41, cached adjacency to Serial0/1
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Se0/1, point2point, tags imposed: {27}
via 10.10.24.2, Serial0/1, 7 dependencies
next hop 10.10.24.2, Serial0/1
valid cached adjacency
tag rewrite with Se0/1, point2point, tags imposed: {27}
L10-R4 imposera donc le label 27 pour atteindre L10-R5, le prochain saut tant le routeur L10-R2 (10.10.24.2).
Le deuxime label (dit label VPN), servant slectionner l'interface de sortie sur L10-R5, peut tre dtermin
grce la table CEF de la VRF RED , indpendante de la table CEF globale :
L10-R4# sh ip cef vrf RED 100.10.5.5
100.10.5.5/32, version 23, cached adjacency to Serial0/1
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Se0/1, point2point, tags imposed: {27 26}
via 10.10.5.5, 0 dependencies, recursive
next hop 10.10.24.2, Serial0/1 via 10.10.5.5/32
valid cached adjacency
tag rewrite with Se0/1, point2point, tags imposed: {27 26}
Le label VPN est donc 26. Pour joindre l'adresse IP 100.10.5.5 de la VRF RED , le routeur L10-R4 imposera
donc la pile de label { 27 26 }. Sur le backbone MPLS, la commutation se fera uniquement en fonction du premier
label, comme le montre le rsultat de la commande traceroute :
L10-R4# trace vrf RED 100.10.5.5
1 10.10.24.2 [MPLS: Labels 27/26 Exp 0] 72 msec 72 msec 68 msec
On constate la prsence du Penultimate Hop Popping, entre les routeurs L10-R3 (10.10.24.3) et L10-R5.
(100.10.57.5). En effet, L10-R3 a retir le premier label 23, servant atteindre L10-R5. Ce fonctionnement est
confirm en consultant la table TFIB de L10-R3 :
L10-R3# sh tag for
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged 10.10.13.1/32 0 Se0/1 point2point
17 Untagged 10.10.35.5/32 0 Se0/0 point2point
18 Untagged 10.10.23.2/32 0 Se1/0 point2point
20 Pop tag 10.10.1.1/32 1693 Se0/1 point2point
21 Pop tag 10.10.2.2/32 0 Se1/0 point2point
22 20 10.10.4.4/32 3020 Se1/0 point2point
23 Pop tag 10.10.5.5/32 5821 Se0/0 point2point
26 Pop tag 10.10.12.0/24 0 Se1/0 point2point
Pop tag 10.10.12.0/24 0 Se0/1 point2point
27 Pop tag 10.10.24.0/24 2304 Se1/0 point2point
29 Aggregate 100.10.3.3/32[V] 0
local tag: 23
via 10.10.35.5, Serial0/0, 0 dependencies
next hop 10.10.35.5, Serial0/0
valid cached adjacency
tag rewrite with Se0/0, point2point, tags imposed: {}
Le
schma
ci-dessous
montre
le
trajet
suivi
par
les
paquets,
de
L10-R4
vers
L10-R7
cet
exemple,
on
suppos
que
PE-Internet
pour
adresse
120.1.1.2.
Lorsque le PE recevra un paquet sur la VRF GREEN , il effectuera un lookup dans la table de routage de
cette VRF. Si aucune entre n'est trouve pour la destination IP, la route par dfaut injecte au moyen de la
commande ip route sera utilise. Il est noter que la table de routage globale du routeur est examine
pour atteindre PEInternet, et que les paquets traversent le backbone MPLS sans label VPN (seul le label de
PE-Internet
est
accol
par
le
PE).
Naturellement, ce type de routage n'est pas optimal, car si plusieurs PE disposent d'un accs Internet, seul le
PE dclar dans la route par dfaut sera employ. De plus, cette mthode casse la notion de VRF avec la
dclaration des routes VPN de manire globale sur les PE. Enfin, tous les PE doivent tre configurs de cette
manire, avec pour chacun la route par dfaut et la mise en place dans la table de routage globale des routes
VPN.
4.7.2 - Route par dfaut dynamique (Dynamic Default Route)
Une solution plus propre techniquement pour propager une route par dfaut tous les PE est d'utiliser la
notion de VPN avec une topologie Hub and Spoke . Sur le routeur PE-Internet, une VRF particulire est
configure pour annoncer la route par dfaut (apprise par un autre routeur, gnralement avec eBGP). Si l'on
souhaite propager manuellement cette route un certains sites de diffrents VPN, il suffit d'employer la
politique
d'attribution
des
RT
du
schma
ci-dessous
:
Chacun des sites clients reoit la route par dfaut provenant du site vert central grce au RT 500:1001. Pour
permettre le retour des paquets, chaque site doit exporter vers le site central ses propres routes (RT
500:1000). Chaque PE doit donc tre configur avec ces RT pour permettre la propagation de la route par
dfaut. Il est ainsi possible de ne propager la route par dfaut qu' certains sites d'un mme VPN (les VRF de
ces sites devant traiter les RT du VPN Internet ), en configurant les PE adquats et en ne changeant rien
sur
les
autres
:
Si l'on souhaite propager automatiquement la route par dfaut tous les sites d'un mme VPN sans avoir
modifier la configuration des diffrents PE, il suffit d'importer et d'exporter le RT de ce VPN dans la VRF
Internet . De cette manire, aucun changement dans la configuration des PE rattachs ces sites n'est
ncessaire.
Internet
La mise en place d'une double liaison avec le CE (une avec VRF, l'autre sans) peut tre ralise au moyen de
deux sous-interfaces (2 VLAN sur trunk Ethernet, 2 DLCI sur Frame Relay, 2 VC sur ATM, etc.) ou avec un
tunnel
GRE.
Exemple de configuration avec une interface Frame-Relay :
interface Serial1/0
no ip address
encapsulation frame-relay
!
interface Serial1/0.1
description Interface pour accs Internet
ip address 100.2.1.1 255.255.255.252
frame-relay interface-dlci 100
!
interface Serial1/0.2
description Interface pour accs VPN
ip vrf forwarding RED
ip address 10.2.1.1 255.255.255.252
frame-relay interface-dlci 200
!
Exemple de configuration avec une interface Ethernet en mode trunk :
interface FastEthernet0/0
no ip address
!
interface FastEthernet0/0.1
description Interface pour accs Internet
ip address 100.1.1.1 255.255.255.252
encapsulation isl 1
!
interface FastEthernet0/0.2
description Interface pour accs VPN
ip vrf forwarding GREEN
ip address 10.1.1.1 255.255.255.252
encapsulation isl 2
!
Sur le CE, deux approches sont possibles pour accder la fois aux autres sites du VPN et Internet. La
premire, la plus classique, consiste slectionner l'interface de sortie grce au Policy Routing, au moyen
des commandes route-map. La seconde consiste employer la notion de VRF sur le routeur CE lui-mme,
mais sans utilisation de MP-BGP. Les VRF peuvent en effet tre mises en place sur un routeur,
indpendamment de MPLS/VPN. L'exemple suivant montre comment implmenter le Policy Routing sur un CE
(en reprenant l'exemple du PE ci-dessus, connect au CE par une interface FastEthernet) avec translation
d'adresse (NAT) :
interface FastEthernet0/0
description Vers site client
ip address 10.2.0.1 255.255.255.0
ip policy route-map ACCESS
ip nat inside
!
interface FastEthernet1/0
no ip address
!
interface FastEthernet1/0.1
description Interface pour accs Internet
ip address 100.1.1.2 255.255.255.252
encapsulation isl 1
ip nat outside
!
interface FastEthernet1/0.2
description Interface pour accs VPN
ip address 10.1.1.2 255.255.255.252
encapsulation isl 2
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
route-map ACCESS permit 10
match ip address 100
set ip next-hop 100.1.1.1
!
ip nat inside source list 101 interface FastEthernet1/0.1 overload
access-list 100 deny ip any 10.0.0.0 0.255.255.255
access-list 100 permit ip any any
access-list 101 permit ip 10.0.0.0 0.255.255.255 any
!
Pour cet exemple, il est suppos que le VPN client emploie le rseau 10.0.0.0/8 dans son plan d'adressage IP
interne. Le route-map ACCESS permet de rediriger le trafic destin Internet (c'est--dire n'tant pas
dirig vers une adresse en 10.x.y.z, voir liste d'accs 100) sur l'interface Internet , FastEthernet1/0.1.
Pour pouvoir communiquer avec l'extrieur, une translation des adresses source en 10.0.0.0/8 (voir liste
d'accs 101) du site doit galement avoir lieu. Cette action est ralise avec les commandes ip nat [...] .
Remarque: en cas d'utilisation des VRF sur un routeur CE, il est important de garder l'esprit que certaines
fonctions (par exemple NAT, HSRP, etc.) peuvent ne pas tre supportes avec des interfaces VRF.
4.8 - Signalisation Inter-AS (MP-eBGP)
A partir de la version 12.1(5)T, il devient possible de crer relier des sites d'un 3me VPN travers des
Autonomous Systems diffrents. En effet, l'annonce des routes VPNv4 inter-AS est fonctionnelle, ainsi que la
transmission
des
paquets
labelliss
entre
plusieurs
backbones.
Le peering MP-eBGP se fait de manire similaire au peering MP-iBGP, l'exception naturellement du numro
d'AS et du format des updates MP-eBGP, qui subit quelques lgres adaptations. Chaque routeur
d'interconnexion entre deux AS va annoncer les routes VPNv4 ses voisins externes avec un seul label. Ce
label
sera
utilis
entre
les
2
AS
pour
la
transmission
des
paquets.
Des tests ont t effectus lors du Workshop MPLS avec les versions 12.1(5)T et 12.2(0.4) pour tudier le
fonctionnement de MP-eBGP. Pour cela, les deux pods, L10 et L20, ont t raccords au moyen d'une liaison
FastEthernet entre les deux routeurs R1. La signalisation MP-BGP est alors la suivante :
La
transmission
des
paquets
suivrait
alors
le
schma
ci-dessous
A l'intrieur du backbone MPLS, la mthode de transmission n'est en aucun cas modifie. Seuls les routeurs
MPLS en bordure d'AS ont un comportement diffrent : par exemple, sur le schma ci-dessus, le routeur L10R1 reoit des paquets de l'AS #20 ne contenant qu'un 3eul label. Cependant, celui-ci est converti en
deux labels (label PE + label VPN) lors de l'mission du paquet dans le backbone. Pour fonctionner
correctement, certaines prcautions doivent tre prises au niveau des routeurs reliant les AS :
- Aucune session TDP ne doit tre tablie entre ces routeurs : la commande tag-switching ip ne doit
donc pas tre passe sur les interfaces interconnectant les voisins MP-eBGP. L'absence de cette commande
n'empche pas les routeurs de pouvoir traiter des paquets taggus arrivant sur ces interfaces ;
- Les routeurs doivent annoncer les routes apprises par MP-eBGP avec leur propre adresse IP (next-hopself). Il est conseill de se reporter configurations du routeur L10-R1 fournie en Annexe II pour disposer
d'un exemple complet et oprationnel. Le pod L20 tant configur de manire similaire au pod L10, les
configurations des routeurs de ce pod ne sont pas incluses dans ce document.
Le Trafic Engineering permet un meilleur emploi des liaisons, puisqu'il permet aux administrateurs rseau d'tablir
des tunnels LSP travers le backbone MPLS, indpendamment de l'IGP.
5.2 - Types de tunnels
Les tunnels MPLS (appels galement trunks) peuvent tre crs en indiquant la liste des routeurs emprunter
(mthode explicite) ou bien en utilisant la notion d'affinit (mthode dynamique). La notion d'affinit est
simplement une valeur sur 32 bits spcifie sur les interfaces des routeurs MPLS. La slection du chemin
s'effectue alors en indiquant (sur le routeur initiant le tunnel) une affinit et un masque.
5.3 - Critres de bande passante
Pour permettre une gestion plus souple du trafic, chaque interface MPLS susceptible d'tre un point de transit
pour des tunnels MPLS dispose d'une notion de priorit, dfinie sur 8 niveaux. Lors de l'tablissement d'un
nouveau tunnel, si celui-ci a une priorit plus grande que les autres tunnels et que la bande passante totale
utilisable pour le TE est insuffisante, alors un tunnel moins prioritaire sera ferm. Ce mode de fonctionnement est
appel
premption.
Les niveaux de priorit sont cods avec valeur de 0 8, 0 correspondant la priorit plus leve et 8 la priorit
la plus basse. Chaque interface MPLS/TE doit tre configure avec un dbit maximum allou pour le Traffic
Engineering. Par exemple, il est possible de n'autoriser que 50 Kb/s pour les tunnels sur une interface ayant un
dbit
de
128
Kb/s.
Pour bien comprendre la notion de premption, considrons l'exemple suivant : un tunnel de priorit 3 avec une
bande passante (BW) de 50 Kb/s est dj tablie sur une interface autorisant 100 Kb/s de tunnels MPLS. Le
routeur autorisera l'tablissement d'un tunnel de priorit infrieure (>= 3) jusqu' un dbit de 50 Kb/s, c'est-dire la bande passante disponible. Par contre, si une demande pour l'tablissement d'un tunnel de priorit
suprieure survient (< 3), alors le routeur considre que la bande passante disponible est de 100 Kb/s. Le
nouveau tunnel sera ainsi tabli, et des tunnels de priorit moindre seront ferms si besoin est (premption). Il
est important de garder l'esprit que crer un tunnel MPLS ne garantit pas la prsence de la bande passante tout
au long du rseau. En effet, les interfaces des routeurs sont configures pour allouer un certain dbit au TE ; mais
en cas de congestion d'un lien avec du trafic hors tunnel, les tunnels n'auront pas de bande passante garantie.
5.4 - Etablissement d'un tunnel
Pour permettre au Trafic Engineering de fonctionner, le protocole de routage interne (IGP) doit tre un protocole
tat de liens (link-state). En effet, pour dterminer le chemin emprunter par un tunnel, les routeurs doivent
avoir la connaissance complte de la topologie du rseau. Les seuls protocoles supportant le TE sont donc OSPF et
ISIS. Des extensions ont t rajouts ces deux protocoles pour grer les critres de bande passante et de
priorit sur les liens du rseau. Pour OSPF, des Opaque LSA ont t mis en place et pour IS-IS de nouveaux
enregistrements
TLV
ont
t
crs.
Pour choisir le meilleur chemin correspondant aux critres de bande passante spcifis, l'algorithme de SPF de ces
protocoles a t modifi pour tenir compte de ces contraintes. Cet algorithme de calcul du meilleur chemin pour
les
tunnels
LSP
est
appel
PCALC
et
permet
donc
le
Constrained
Based
Routing.
L'algorithme
PCALC
est
le
suivant
Supprimer
les
liens
qui
ne
disposent
pas
de
la
bande
passante
suffisante
;
Supprimer
les
liens
qui
ne
correspondent
pas
l'affinit
demand
;
- Excuter l'algorithme de Dijkstra sur la topologie restante (avec les mtriques de l'IGP) ;
- Si plusieurs chemins subsistent, maximiser la valeur V, dfinie comme tant le minimum des valeurs de
bande passante disponible sur chaque lien du chemin. Cela permet de load-balancer les tunnels de mmes
critres
sur
plusieurs
chemins
diffrents
;
- S'il existe encore plusieurs chemins, slectionner celui-ci avec le nombre minimal de sauts (hops) ;
- Enfin, si plusieurs chemins sont encore prsents, en choisir un alatoirement. L'tablissement d'un tunnel,
aprs excution de l'algorithme PCALC, est ralis au moyen du protocole RSVP, auquel des extensions ont t
rajoutes pour permettre le TE. Chaque noeud du chemin vrifie si les critres demands sont compatibles avec
son tat actuel ; dans le cas contraire, la signalisation RSVP dclenche une annulation et le noeud floode son
tat pour en informer ses voisins.
5.5 - Roptimisation
Un mcanisme important du Traffic Engineering est le fait de pouvoir roptimiser les chemins emprunts par les
tunnels LSP. Pour viter une rupture dans le routage, un nouveau tunnel est tabli paralllement de celui dj
ouvert. Ds que l'tablissement du tunnel de remplacement est russie, le premier tunnel est ferm.
5.6 - Configuration IOS
Ce
paragraphe
prsente
les
diffrentes
tapes
Traffic Engineering sur un backbone MPLS dj en place.
de
configurations
permettant
d'activer
le
l'IGP
(OSPF
ou
IS-IS),
la
mthode
de
configuration
diffre
- OSPF :
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
!
- IS-IS :
router isis
net 49.0020.4444.4444.4444.00
metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1
!
5.6.3 - Configurations des interfaces
Chaque interface MPLS devant permettre le Traffic Engineering doit tre configure de la manire analogue
l'exemple ci-dessous :
interface serial 0/0
ip address 10.20.24.4 255.255.255.0
no ip directed-broadcast
bandwidth 125
encapsulation ppp
tag-switching ip
mpls traffic-eng tunnels
ip rsvp bandwidth 100 100
!
La commande mpls traffic-eng tunnels permet d'autoriser le passage de tunnels LSP travers cette
interface.
La commande ip rsvp bandwidth indique quel dbit en Kb/s peut tre utilis pour les tunnels.
5.6.4 - Cration d'un tunnel explicite
En prenant comme exemple le pod L20 avec
et L20-R3, la configuration de L20-R4 serait la suivante :
interface Tunnel1
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache cef
tunnel destination 10.20.3.3
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng bandwidth 10
tunnel mpls traffic-eng path-option 1 explicit name WAY1
!
ip explicit-path name WAY1 enable
next-address 10.20.24.2
next-address 10.20.12.1
next-address 10.20.13.3
!
l'tablissement
d'un
tunnel
entre
L20-R4
La
liste
des
hops,
dfinie
par
le
chemin
explicite
L20-R2
L20-R1
WAY1
est
ainsi
(10.20.24.2)
(10.20.12.1)
- L20-R3 (10.20.13.3)
5.6.5 - Cration d'un tunnel dynamique
La cration d'un tunnel dynamique est relativement similaire la cration d'un tunnel explicite. Ici, l'affinit
est fixe 0x10, avec un masque de 0x11.
interface Tunnel2
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache cef
tunnel destination 10.20.3.3
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng bandwidth 10
tunnel mpls traffic-eng affinity 0x10 mask 0x11
tunnel mpls traffic-eng path-option 1 dynamic
5.7 - Utilisation avec MPLS/VPN
Pour assurer un bon fonctionnement du Traffic Engineering avec MPLS/VPN, les deux extrmits des tunnels
doivent tablir une adjacence TDP. Pour cela, deux tunnels LSP doivent tre tablis (un pour chaque direction) et
la
commande
tagswitching
ip
passe
sur
les
interfaces
Tunnels.
Au niveau de la transmission des paquets, 3 labels sont utiliss : un label correspondant au tunnel sera plac en
premire position, les deux labels MPLS/VPN (label PE + label VPN) tant placs aprs. Le label de tunnel est
naturellement retir par l'extrmit terminale du tunnel, et les paquets sont ensuite forwards
normalement.
6 - Conclusion
- A l'origine dvelopp pour la rapidit, la commutation de paquets par tag switching a permis la mise en oeuvre de
solutions de plus haut niveau, comme les VPN ou le Traffic Engineering. MPLS rassemble en une seule entit l'efficacit
des protocoles de niveau 3, allie la vitesse de commutation de niveau 2.
bandwidth 125
ip address 10.10.23.2 255.255.255.0
encapsulation ppp
clockrate 125000
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R3 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R3
!
boot system flash slot0:c3640-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$3Paa$QoFQfhYLZLCidMokHBanf1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
call rsvp-sync
!
interface Loopback0
ip address 10.10.3.3 255.255.255.255
!
interface Serial0/0
description Vers L10-R5
bandwidth 125
ip address 10.10.35.3 255.255.255.0
encapsulation ppp
clockrate 125000
!
interface Serial0/1
description Vers L10-R1
bandwidth 125
ip address 10.10.13.3 255.255.255.0
encapsulation ppp
!
interface Serial1/0
description Vers L10-R2
bandwidth 125
ip address 10.10.23.3 255.255.255.0
encapsulation ppp
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R4 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R4
!
boot system flash slot0:c3620-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$mLZz$9KLAmd1tA023Bd5Z5mV.s1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
call rsvp-sync
!
interface Loopback0
ip address 10.10.4.4 255.255.255.255
!
interface Serial0/0
description Vers L10-R6
bandwidth 125
ip address 10.10.46.4 255.255.255.0
encapsulation ppp
no fair-queue
clockrate 125000
!
interface Serial0/1
description Vers L10-R2
bandwidth 125
ip address 10.10.24.4 255.255.255.0
encapsulation ppp
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R5 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R5
!
boot system flash flash:c3620-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$m80i$NykiaSFf0D9EdTDAjJozu.
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
frame-relay switching
call rsvp-sync
!
interface Loopback0
ip address 10.10.5.5 255.255.255.255
!
interface Serial0/0
no ip address
encapsulation frame-relay
clockrate 125000
frame-relay lmi-type cisco
frame-relay intf-type dce
!
interface Serial0/0.1 point-to-point
description Vers L10-R7
bandwidth 125
ip address 10.10.57.5 255.255.255.0
frame-relay interface-dlci 100
!
interface Serial0/1
description Vers L10-R3
bandwidth 125
ip address 10.10.35.5 255.255.255.0
encapsulation ppp
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R6 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R6
!
!
interface Serial0/0.1 point-to-point
description Vers L10-R5
bandwidth 125
ip address 10.10.57.7 255.255.255.0
frame-relay interface-dlci 100
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
password cisco
login
line vty 5 15
login
!
end
tag-switching ip
!
interface FastEthernet1/0
ip address 50.50.50.1 255.255.255.0
duplex auto
speed auto
!
router ospf 10
log-adjacency-changes
passive-interface FastEthernet1/0
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 10
no synchronization
no bgp default route-target filter
bgp log-neighbor-changes
bgp cluster-id 10
neighbor iBGP peer-group
no neighbor iBGP activate
neighbor iBGP remote-as 10
neighbor iBGP update-source Loopback0
neighbor iBGP soft-reconfiguration inbound
neighbor 50.50.50.2 remote-as 20
no neighbor 50.50.50.2 activate
no auto-summary
!
address-family vpnv4
neighbor iBGP activate
neighbor iBGP route-reflector-client
neighbor iBGP send-community extended
neighbor iBGP route-map NH_Rewrite out
neighbor 10.10.2.2 peer-group iBGP
neighbor 10.10.3.3 peer-group iBGP
neighbor 10.10.4.4 peer-group iBGP
neighbor 10.10.5.5 peer-group iBGP
neighbor 50.50.50.2 activate
neighbor 50.50.50.2 send-community extended
no auto-summary
exit-address-family
!
route-map NH_Rewrite permit 10
match as-path 1
set ip next-hop peer-address
!
route-map NH_Rewrite permit 20
!
ip as-path access-list 1 deny ^$
ip as-path access-list 1 permit .*
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R2 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R2
!
password cisco
login
!
end
Configuration de L10-R3 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R3
!
boot system flash slot0:c3640-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$3Paa$QoFQfhYLZLCidMokHBanf1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
call rsvp-sync
!
ip vrf ADMIN
rd 100:2000
route-target export 100:2000
route-target import 100:2001
!
interface Loopback0
ip address 10.10.3.3 255.255.255.255
!
interface Loopback10
description Interface de Management
ip vrf forwarding ADMIN
ip address 100.10.3.3 255.255.255.255
!
interface Ethernet0/0
no ip address
shutdown
half-duplex
!
interface Serial0/0
description Vers L10-R5
bandwidth 125
ip address 10.10.35.3 255.255.255.0
encapsulation ppp
clockrate 125000
tag-switching ip
!
interface Serial0/1
description Vers L10-R1
bandwidth 125
ip address 10.10.13.3 255.255.255.0
encapsulation ppp
tag-switching ip
!
interface Ethernet1/0
no ip address
shutdown
half-duplex
!
interface Serial1/0
description Vers L10-R2
bandwidth 125
ip address 10.10.23.3 255.255.255.0
encapsulation ppp
tag-switching ip
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 10
no synchronization
neighbor 10.10.1.1 remote-as 10
neighbor 10.10.1.1 update-source Loopback0
no neighbor 10.10.1.1 activate
no auto-summary
!
address-family ipv4 vrf ADMIN
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.10.1.1 activate
neighbor 10.10.1.1 send-community extended
no auto-summary
exit-address-family
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R4 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R4
!
boot system flash slot0:c3620-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$mLZz$9KLAmd1tA023Bd5Z5mV.s1
!
memory-size iomem 10
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
call rsvp-sync
!
ip vrf BLUE
rd 100:1
route-target import 100:1
route-target export 100:1
!
ip vrf RED
rd 100:2
route-target import 100:2
route-target export 100:2
!
ip vrf GREEN
rd 100:3
redistribute connected
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.10.1.1 activate
neighbor 10.10.1.1 send-community extended
no auto-summary
exit-address-family
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R5 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R5
!
boot system flash flash:c3620-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$m80i$NykiaSFf0D9EdTDAjJozu.
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
frame-relay switching
call rsvp-sync
!
ip vrf BLUE
rd 100:1
route-target import 100:1
route-target export 100:1
!
ip vrf RED
rd 100:2
route-target import 100:2
route-target export 100:2
route-target import 100:2000
route-target export 100:2001
!
ip vrf GREEN
rd 100:3
route-target import 100:3
route-target export 100:3
!
interface Loopback0
ip address 10.10.5.5 255.255.255.255
!
interface Loopback1
ip vrf forwarding BLUE
ip address 100.10.5.5 255.255.255.255
!
interface Loopback2
ip vrf forwarding RED
ip address 100.10.5.5 255.255.255.255
!
interface Loopback3
ip vrf forwarding GREEN
ip address 100.10.5.5 255.255.255.255
!
interface Ethernet0/0
no ip address
half-duplex
!
interface Serial0/0
no ip address
encapsulation frame-relay
clockrate 125000
frame-relay lmi-type cisco
frame-relay intf-type dce
!
interface Serial0/0.1 point-to-point
description Vers L10-R7
bandwidth 125
ip vrf forwarding RED
ip address 100.10.57.5 255.255.255.0
frame-relay interface-dlci 100
!
interface Serial0/1
description Vers L10-R3
bandwidth 125
ip address 10.10.35.5 255.255.255.0
encapsulation ppp
tag-switching ip
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 10
no synchronization
bgp log-neighbor-changes
neighbor 10.10.1.1 remote-as 10
neighbor 10.10.1.1 update-source Loopback0
no neighbor 10.10.1.1 activate
no auto-summary
!
address-family ipv4 vrf BLUE
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
neighbor 100.10.57.7 remote-as 102
neighbor 100.10.57.7 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf GREEN
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.10.1.1 activate
neighbor 10.10.1.1 send-community extended
no auto-summary
exit-address-family
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
Configuration de L10-R6 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R6
!
boot system flash flash:c2600-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$bZ2c$wdF872FRcLXaObuYJD90u1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
call rsvp-sync
!
interface Loopback0
ip address 100.10.6.6 255.255.255.255
!
interface Ethernet0/0
no ip address
half-duplex
!
interface Serial0/0
description Vers L10-R4
bandwidth 125
ip address 100.10.46.6 255.255.255.0
encapsulation ppp
no fair-queue
!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
!
interface FastEthernet1/0.1
encapsulation dot1Q 161
ip address 100.10.161.6 255.255.255.0
no ip redirects
!
interface FastEthernet1/0.2
encapsulation dot1Q 162
ip address 100.10.162.6 255.255.255.0
no ip redirects
!
router rip
version 2
network 100.0.0.0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
line vty 5 15
login
!
end
Configuration de L10-R7 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R7
!
boot system flash flash:c2600-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$Fgps$hTMFn1J6vXX9P3Dh9JDaK/
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
no ip dhcp-client network-discovery
call rsvp-sync
!
interface Loopback0
ip address 100.10.7.7 255.255.255.255
!
interface Ethernet0/0
no ip address
half-duplex
!
interface Serial0/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/0.1 point-to-point
description Vers L10-R5
bandwidth 125
ip address 100.10.57.7 255.255.255.0
frame-relay interface-dlci 100
!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
!
interface FastEthernet1/0.1
encapsulation dot1Q 171
ip address 100.10.171.7 255.255.255.0
no ip redirects
!
interface FastEthernet1/0.2
encapsulation dot1Q 172
ip address 100.10.172.7 255.255.255.0
no ip redirects
!
router bgp 102
bgp log-neighbor-changes
network 100.10.7.7 mask 255.255.255.255
network 100.10.171.0 mask 255.255.255.0
network 100.10.172.0 mask 255.255.255.0
neighbor 100.10.57.5 remote-as 10
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
transport input none
line aux 0
line vty 0 4
password cisco
login
line vty 5 15
login
!
no scheduler allocate
end
Les sockets
Winsock
1 - L'histoire de Winsock
2 - L'architecture
3 - Les compatibilits
3.1 - Winsock
3.2 - Le mode Raw
3.3 - Les options
4 - Le mode non connect
5 - Le mode connect
6 - Le mode brut
7 - Les liens
8 - Discussion autour de la documentation
9 - Suivi du document
1 - L'histoire de Winsock
Depuis des annes, les applications se sont tournes vers une communication rseaux afin d'interagir entre elles. La
Socket Windows, ou plus couramment appel Winsock, est une API (Application Programming Interface) procurant des
fonctions d'accs aux protocoles rseaux. Winsock reprsente donc une interface API permettant l'utilisation du
protocole
TCP/IP
sur
une
interface
Windows.
Winsock 1.1 t publi le 20 janvier 1993 afin de crer un standard universel pour les applications TCP/IP. Les
auteurs des Windows Socket 1.1 ont limit les possibilits l'utilisation d'un seul protocole, TCP/IP, contrairement la
version 2.0 qui propose en plus, la suite des protocoles ATM, IPX/SPX, DECnet et le sans fil. Le passage Winsock 2.0
s'est fait en gardant 100% de compatibilit permettant aux applications dj dveloppes de continuer fonctionner.
2 - L'architecture
L'architecture
Winsock
est
conforme
WOSA
(Windows
Open
System
Architecture).
Comme vous pouvez le voir sur le schma ci dessus, Winsock 2.0 fournit deux interfaces de programmation. La
premire, application programming interface, est appel API. Elle se situe en couche 5 du modle OSI et utilise donc
un protocole de couche 3 et 4 pour vhiculer ses informations travers un rseau. La seconde interface, service
provider interface, est appel SPI. Elle se situe en couche 3 du modle OSI et permet de personnaliser les protocoles
tels que IP, IPX afin de grer l'adressage, le transport et les options.
3 - Les compatibilits
3.1 - Winsock
Winsock 1.1
Winsock 2
Windows 3.x
Oui
Non
Windows NT 3.x
Oui
Non
Windows 95
Oui
Oui *
Windows NT 4
Oui
Oui **
Windows 98
Oui
Oui **
Windows 2000
Oui
Oui
Windows XP
Oui
Oui
Windows 2003
Oui
Oui
* Windows 95 est livr de base avec Winsock 1.1. Il est possible d'installer Winsock 2 l'aide d'un add-on
Microsoft disponible cette l'Url.
3.2 - Le mode Raw
Le
mode
Raw
est
disponible
partir
de
la
version
2.0
de
Winsock.
** Malgr le support du mode Raw, Win98 et Nt4 ne sont pas compatibles avec l'option IP_HDRINCL permettant
de spcifier l'entte IP.
3.3 - Les options
Vous trouverez la liste des compatibilits de toutes les options.
5 - Le mode connect
Le mode connect est bas sur l'ouverture d'une session TCP afin de garantir, au niveau 4, la transmission de donne.
Voici
le
schma
d'une
relation
entre
deux
hosts
IP
en
mode
connect.
6 - Le mode brut
Le mode brut est plus communment appel mode raw. Compatible uniquement avec la version 2 de Winsock, il
permet de spcifier un protocole de couche 3 tel que ATM, SPX, IP et autres. Dans le cadre d'IP, il existe une option
appele IP_HDRINCL apportant la possibilit de spcifier l'entte IP entire. Pour avoir accs aux options du mode raw,
il faut possder les droits d'administrateur local. Microsoft l'impose pour des raisons de scurit, mais propose de
contourner cette restriction l'aide de la modification du registre explicit dans la Q195445.
le
schma
d'une
relation
entre
un
client
et
un
serveur.
2 - Initialisation de la socket
Une socket est un mcanisme de couche 5 permettant une communication rseau inter application. En rsum, elle
permet la communication entre deux applications situs sur deux machines distinctes.
2.1 Commande WSAStartup()
Windows se basant sur Winsock, nous devons initialiser cette API, contrairement Linux. Pour cela, nous allons
utiliser la fonction WSAStartup(). L'utilisation de cette fonction est donc obligatoire pour un systme d'exploitation
Windows. Si vous utilisez un autre OS, alors passez directement l'tape suivante. Voici un exemple d'utilisation
pour le ct client et serveur.
// ********************************************************
// Dclaration des variables
// ********************************************************
WSADATA initialisation_win32; // Variable permettant de rcuprer la structure d'information sur l'initialisation
int erreur; // Variable permettant de rcuprer la valeur de retour des fonctions utilises
// ********************************************************
// Initialisation de Winsock
// ********************************************************
erreur=WSAStartup(MAKEWORD(2,2),&initialisation_win32);
if (erreur!=0)
printf("\nDesole, je ne peux pas initialiser Winsock du a l'erreur : %d %d",erreur,WSAGetLastError());
else
printf("\nWSAStartup : OK");
- Le
premier
paramtre
indique
la
version
de Winsock que
nous
demandons.
- Le second paramtre est l'adresse d'une structure de type WSADATA qui contient toutes les informations
ncessaires
rsultant
de
l'initialisation.
- La fonction devra renvoyer 0 pour indiquer que sont excution c'est correctement droule.
Voici la fiche Msdn concernant la fonction WSAStartup().
2.2 - Commande socket()
La cration d'une socket est obligatoire afin d'obtenir un identifiant unique. Cela permettra aux prochaines
fonctions de toutes ce rfrencer au mme id, donc la mme socket. Voici un exemple d'utilisation pour le ct
client et serveur.
// ********************************************************
// Dclaration des variables
// ********************************************************
SOCKET id_de_la_socket; // Identifiant de la socket
// ********************************************************
// Ouverture d'une Socket
// ********************************************************
id_de_la_socket=socket(AF_INET,SOCK_STREAM,0);
if (id_de_la_socket==INVALID_SOCKET)
printf("\nDesole, je ne peux pas creer la socket du a l'erreur : %d",WSAGetLastError());
else
printf("\nsocket
: OK");
- Le premier paramtre indique que vous dsirez cre une socket bas sur le protocole IPv4.
- Le second paramtre slectionne le mode connect via TCP, cela ncessitera alors une ouverture de session.
- La fonction retournera l'identifiant de la socket si elle s'est excute correctement. Sinon, elle indiquera la
valeur
INVALID_SOCKET.
Voici la fiche Msdn concernant la fonction socket().
2.3 - Commande setsockopt()
La configuration des options de la socket n'est pas obligatoire. Vous devez l'utilisez que si vous avez un besoin
spcifique. Voici un exemple d'utilisation pour le ct client et serveur.
// ********************************************************
// Dclaration des variables
// ********************************************************
int tempo; // Variable temporaire de type int
// ********************************************************
// Activation de l'option permettant d'activer l'algorithme de Nagle
// ********************************************************
tempo=1;
erreur=setsockopt(id_de_la_socket,IPPROTO_TCP,TCP_NODELAY,(char *)&tempo,sizeof(tempo));
if (erreur!=0)
printf("\nDesole, je ne peux pas configurer cette options du l'erreur : %d %d",erreur,WSAGetLastError());
else
printf("\nsetsockopt : OK");
- Le premier argument est l'identifiant de la socket que vous avez rcupr grce la fonction socket().
Le
second
paramtre
spcifie
le niveau
de
l'option.
- Le troisime paramtres indique l'option configurer. Dans cette exemple, la passage 1, de TCP_NODELAY,
permet d'activer l'algorithme de Nagle dcrit dans la RFC 896. Il apportera une meilleur gestion dans le cadre
d'envoi
de
trs
petite
donne.
Le
quatrime
paramtre
indique
la
valeur
de
l'option
que
l'on
spcifie.
Le
cinquime
paramtre
spcifie
uniquement
la
taille
du
quatrime.
- La fonction devra renvoyer 0 pour indiquer que sont excution c'est correctement droule.
Voici la fiche Msdn concernant la fonction setsockopt().
La commande send permet l'envoi d'une chane de caractre destination du serveur ayant tabli la session TCP.
Voici un exemple d'utilisation pour le ct client.
// ********************************************************
// Dclaration des variables
// ********************************************************
int nombre_de_caractere; // Indique le nombre de caractres qui a t reu ou envoy
char buffer[65535]; // Tampon contenant les donnes reues ou envoyes
// ********************************************************
// Envoi des donnes
// ********************************************************
strcpy(buffer,"Coucou, je suis les donnees. www.frameip.com"); // Copie la chaine de caractre dans buffer
nombre_de_caractere=send(id_de_la_socket,buffer,strlen(buffer),0);
if (nombre_de_caractere==SOCKET_ERROR)
printf("\nDesole, je n'ai pas envoyer les donnees du a l'erreur : %d",WSAGetLastError());
else
printf("\nsend
: OK");
- Le premier argument est l'identifiant de la socket que vous avez rcupr grce la fonction socket().
Le
second
argument
est
le
buffer
contenant
les
donnes
envoyer.
Le
troisime
paramtre
spcifie
uniquement
la
taille
du
buffer.
- La
fonction
renverra
le
nombre
de
caractre
qui
a
t
mis.
Voici la fiche Msdn concernant la fonction send().
5.2 - Commande recv()
La commande recv permet de recueillir dans un buffer les donnes reues sur une socket. Voici un exemple
d'utilisation pour le ct serveur.
// ********************************************************
// Reception des donnes
// ********************************************************
nombre_de_caractere=recv(id_de_la_nouvelle_socket,buffer,1515,0);
if (nombre_de_caractere==SOCKET_ERROR)
printf("\nDesole, je n'ai pas recu de donnee");
else
{
buffer[nombre_de_caractere]=0; // Permet de fermer le tableau aprs le contenu des data, car la fonction recv ne
le fait pas
printf("\nVoici les donnees : %s",buffer);
}
- Le premier argument est l'identifiant de la socket que vous avez rcupr grce la fonction accept().
Le
second
argument
est
le
buffer
contenant
les
donnes
recevoir.
Le
troisime
paramtre
reprsente
le
nombre
maximum
de
caractre
attendu.
- La
fonction
renverra
le
nombre
de
caractre
qui
a
t
reu.
Voici la fiche Msdn concernant la fonction recv().
// ********************************************************
// Fermeture de la session TCP Correspondant la commande connect()
// ********************************************************
erreur=shutdown(id_de_la_socket,2); // 2 signifie socket d'mission et d'coute
if (erreur!=0)
printf("\nDesole, je ne peux pas fermer la session TCP du a l'erreur : %d %d",erreur,WSAGetLastError());
else
printf("\nshutdown : OK");
- Le premier argument est l'identifiant de la socket que vous avez rcupr grce la fonction socket().
- Le second argument indique si l'on doit fermer l'mission, la rception ou les deux.
- La fonction devra renvoyer 0 pour indiquer que sont excution c'est correctement droule.
Voici la fiche Msdn concernant la fonction shutdown().
7 - Libration de la socket
7.1 Commande closesocket()
Cette fonction permet de librer proprement l'accs la socket. Durement conseill pour le respect d'un
dveloppement propre et d'une utilisation saine du systme d'exploitation. Voici un exemple d'utilisation pour le
ct client et serveur.
// ********************************************************
// Fermeture de la socket correspondant la commande socket()
// ********************************************************
erreur=closesocket(id_de_la_socket);
if (erreur!=0)
printf("\nDesole, je ne peux pas liberer la socket du a l'erreur : %d %d",erreur,WSAGetLastError());
else
printf("\nclosesocket : OK");
- Le premier argument est l'identifiant de la socket que vous avez rcupr grce la fonction socket().
- La fonction devra renvoyer 0 pour indiquer que sont excution c'est correctement droule.
Voici la fiche Msdn concernant la fonction closesocket().
7.2 Commande WSACleanup()
Cette tape n'est utile et fonctionnelle que dans le cadres du systme d'exploitation Microsoft. Cette fonction
permet de librer l'accs Winsock. Attention, dans un environnement multiprocess, l'utilisation de cette
commande fermera les accs de tous les process. Voici un exemple d'utilisation pour le ct client et serveur.
// ********************************************************
// Quitte proprement le winsock ouvert avec la commande WSAStartup
// ********************************************************
erreur=WSACleanup(); // A appeler autant de fois qu'il a t ouvert.
if (erreur!=0)
printf("\nDesole, je ne peux pas liberer winsock du a l'erreur : %d %d",erreur,WSAGetLastError());
else
printf("\nWSACleanup : OK");
-
La
fonction
devra
renvoyer
pour
indiquer
que
sont
excution
c'est
correctement
droule.
{
printf("\nBonjour, vous etes du cote client. www.frameip.com\n");
// ********************************************************
// Initialisation de Winsock
// *****************************************