All Cours Rezo 430 Pages

RESEAUX
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.
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.
3 - Comparaison avec le modle OSI et critique

3.1 - Comparaison avec le modle OSI
Tout d'abord, les points communs. Les modles OSI et TCP/IP sont tous les deux fonds sur le concept de pile de
protocoles indpendants. Ensuite, les fonctionnalits des couches sont globalement les mmes.
Au niveau des diffrences, on peut remarquer la chose suivante : le modle OSI faisait clairement la diffrence
entre 3 concepts principaux, alors que ce n'est plus tout fait le cas pour le modle TCP/IP. Ces 3 concepts sont
les concepts de services, interfaces et protocoles. En effet, TCP/IP fait peu la distinction entre ces concepts, et ce
malgr les efforts des concepteurs pour se rapprocher de l'OSI. Cela est d au fait que pour le modle TCP/IP, ce
sont les protocoles qui sont d'abord apparus. Le modle ne fait finalement que donner une justification thorique
aux
protocoles,
sans
les
rendre
vritablement
indpendants
les
uns
des
autres.
Enfin, la dernire grande diffrence est lie au mode de connexion. Certes, les modes orient connexion et sans
connexion sont disponibles dans les deux modles mais pas la mme couche : pour le modle OSI, ils ne sont
disponibles qu'au niveau de la couche rseau (au niveau de la couche transport, seul le mode orient connexion
n'est disponible), alors qu'ils ne sont disponibles qu'au niveau de la couche transport pour le modle TCP/IP (la
couche internet n'offre que le mode sans connexion). Le modle TCP/IP a donc cet avantage par rapport au
modle OSI : les applications (qui utilisent directement la couche transport) ont vritablement le choix entre les
deux modes de connexion.
3.2 - Critique
Une des premires critiques que l'on peut mettre tient au fait que le modle TCP/IP ne fait pas vraiment la
distinction entre les spcifications et l'implmentation : IP est un protocole qui fait partie intgrante des
spcifications
du
modle.
Une autre critique peut tre mise l'encontre de la couche hte rseau. En effet, ce n'est pas proprement
parler une couche d'abstraction dans la mesure o sa spcification est trop floue. Les constructeurs sont donc
obligs de proposer leurs solutions pour "combler" ce manque. Finalement, on s'aperoit que les couches physique
et liaison de donnes sont tout aussi importantes que la couche transport. Partant de l, on est en droit de
proposer un modle hybride 5 couches, rassemblant les points forts des modles OSI et TCP/IP :
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
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
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.
2 - Les diffrentes couches du modle

2.1 - Les 7 couches
Le
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.
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...
3 - Transmission de donnes au travers du modle OSI

Le processus metteur remet les donnes envoyer au processus rcepteur la couche application qui leur ajoute un
en-tte application AH (ventuellement nul). Le rsultat est alors transmis la couche prsentation.
La couche prsentation transforme alors ce message et lui ajoute (ou non) un nouvel en-tte (ventuellement nul). La
couche prsentation ne connat et ne doit pas connatre l'existence ventuelle de AH ; pour la couche prsentation, AH
fait en fait partie des donnes utilisateur. Une fois le traitement termin, la couche prsentation envoie le nouveau
"message"
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.
4 - Critique du modle OSI

La chose la plus frappante propos du modle OSI est que c'est peut-tre la structure rseau la plus tudie et la plus
unanimement reconnue et pourtant ce n'est pas le modle qui a su s'imposer. Les spcialistes qui ont analys cet
chec en ont dtermin 4 raisons principales.
4.1 - Ce n'tait pas le bon moment
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 : A Novice's Guide to the Internet Engineering Task Force
Rfc 3160-fr
RFC : Un guide pour la participation aux travaux de l'Internet Engineering Task Force
ATM
Rfc 1483
RFC : Multiprotocol Encapsulation over ATM Adaptation Layer 5
Rfc 2684
RFC : Multiprotocol Encapsulation over ATM Adaptation Layer 5
Ethernet
Rfc 894
RFC : Un Standard pour la Transmission des Datagrammes IP sur les Rseaux Ethernet
Rfc 894-err
RFC : Errata de la RFC 894
Rfc 3580
RFC : IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
Rfc 3748
RFC : Extensible Authentication Protocol (EAP)
PPP
Rfc 1661
RFC : The Point-to-Point Protocol (PPP)
Rfc 2153
RFC : PPP Vendor Extensions
PPPOE
Rfc 2516
RFC : A Method for Transmitting PPP Over Ethernet (PPPoE)
Rfc 2516-fr
RFC : Une mthode pour la transmission du PPP sur ethernet
PPTP
Rfc 2637
RFC : Point-to-Point Tunneling Protocol (PPTP)
Rfc 2637-fr
RFC : Protocole de transmission sous tunnel point point
IP
Rfc 791
RFC : Internet Protocol
Rfc 791 fr
RFC : Internet Protocol
Rfc 815
RFC : Ip Datagram Reassembly Algorithms
Rfc 1071
RFC : Computing the Internet Checksum
Rfc 1340
RFC : Assigned Numbers (Remplac par la RFC 1700)
Rfc 1700
RFC : Assigned Numbers
Rfc 1349
RFC : Type of Service in the Internet Protocol Suite
Rfc 1517
RFC : Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)
Rfc 1518
RFC : An Architecture for IP Address Allocation with CIDR
Rfc 1519
RFC : Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
Rfc 1631
RFC : The IP Network Address Translator (NAT)
Rfc 1878
RFC : Variable Length Subnet Table For IPv4
Rfc 1918
RFC : Address Allocation for Private Internets
IPv6
Rfc 2460
RFC : Internet Protocol, Version 6 (IPv6) - Specification
Rfc 4302
RFC : IP Authentication Header
Rfc 4303
RFC : IP Encapsulating Security Payload (ESP)
ARP/RARP
Rfc 826
RFC : An Ethernet Address Resolution Protocol
Rfc 5227
RFC : IPv4 Address Conflict Detection
Rfc 903
RFC : A Reverse Address Resolution Protocol
IGMP
Rfc 1112
RFC : Host Extensions for Ip Multicasting
Rfc 2236
RFC : Internet Group Management Protocol, Version 2
ICMP
Rfc 792
RFC : Internet Control Message Protocol
Rfc 792-fr
RFC : Internet Control Message Protocol
Rfc 1256
RFC : Icmp Router Discovery Messages
TCP
Rfc 793
RFC : Transmission Control Protocol
Rfc 793-fr
RFC : Transmission Control Protocol
Rfc 896
RFC : Congestion Control in Ip/Tcp Internetworks
Rfc 1071
Rfc 1340
Rfc 1323
RFC : TCP Extensions for High Performance
Rfc 2018
RFC : TCP Selective Acknowledgment Options
UDP
Rfc 768
RFC : User Datagram Protocol
Rfc 768-fr
RFC : User Datagram Protocol
Rfc 1071
Rfc 1340
DHCP
Rfc 951
RFC : Bootstrap Protocol (Bootp)
Rfc 951-fr
RFC : Protocole d'amorage (Bootp)
Rfc 1497
RFC : Bootp Vendor Information Extensions
Rfc 1541
RFC : Dynamic Host Configuration Protocol
Rfc 1542
RFC : Clarifications and Extensions for the Bootstrap Protocol
Rfc 2131
RFC : Dynamic Host Configuration Protocol
Rfc 2131-fr
RFC : Protocole de configuration dynamique de machine (DHCP)
Rfc 2132
RFC : Dhcp Options and Bootp Vendor Extensions
Rfc 2132-fr
RFC : Options DHCP et Extensions fournisseur BOOTP
IPSEC
Rfc 2401
RFC : Security Architecture for the Internet Protocol
Rfc 2401-fr
RFC : Architecture de scurit pour IP
Rfc 2402
RFC : IP Authentication Header
Rfc 2406
RFC : IP Encapsulating Security Payload (ESP)
Rfc 2408
RFC : Internet Security Association and Key Management Protocol (ISAKMP)
Rfc 2409
RFC : The Internet Key Exchange (IKE)
Rfc 3095
RFC : Robust Header Compression (ROHC)
L2TP
Rfc 2661
RFC : Layer Two Tunneling Protocol "L2TP"
DNS
Rfc 1033
RFC : Domain adminstrators operations guide
Rfc 1034
RFC : Domain Names - Concepts and facilities
Rfc 1034-fr
RFC : Domain Name Server (Concepts de base)
Rfc 1035
RFC : Domain Names - Implementation and specification
Rfc 1591
RFC : Domain Name System Structure and Delegation
rfc 5358
Preventing Use of Recursive Nameservers in Reflector Attacks
SIP
Rfc 3261
RFC : SIP: Session Initiation Protocol
Rfc 3265
Session Initiation Protocol (SIP)-Specific Event Notification
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
Connected Identity in the Session Initiation Protocol (SIP)
Rfc 5393
Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
Rfc 2327
SDP: Session Description Protocol
RTP
Rfc 3550
RFC : RTP: A Transport Protocol for Real-Time
Rfc 2032
RFC : RTP Payload Format for H.261 Video
Rfc 3711
RFC : The Secure Real-time Transport Protocol (SRTP)
MPLS
Rfc 2547
RFC : BGP/MPLS VPNs
NNTP
Rfc 977
RFC : Network News Transfer Protocol
NTP
Rfc 868
RFC : Time Protocol
Rfc 1059
RFC : Network Time Protocol (Version 1)
Rfc 1119
Rfc 1305
Rfc 4330
RFC : Simple Network Time Protocol (SNTP) Version 4
SNMP
Rfc 1155
RFC : V1 - Structure and identification of management information for TCP/IP-based internets
Rfc 1441
RFC : v2c - Introduction to version 2 of the Internet-standard Network Management Framework
Rfc 1901
RFC : V2 - Introduction to Community-based SNMPv2
Rfc 3411
RFC : V3 - An Architecture for Describing SNMP Management Frameworks
Rfc 3826
RFC : The Advanced Encryption Standard (AES) in the SNMP User-based Security Model
SSL - TLS
draft xxx
RFC : The SSL Protocol Version 2.0
draft 302
RFC : The SSL Protocol Version 3.0
Rfc 2246
RFC : The TLS Protocol Version 1.0
Rfc 3546
RFC : Transport Layer Security (TLS) Extensions
Rfc 4366
RFC : Transport Layer Security (TLS) Extensions
STUN
Rfc 3489
RFC : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators
(NATs)
Rfc 5389
RFC : Session Traversal Utilities for NAT (STUN)
FTP
Rfc 959
RFC : File Transfert Protocol (FTP)
HTTP
Rfc 2616
RFC : Hypertext Transfer Protocol -- HTTP/1.1
Rfc 2109
RFC : HTTP State Management Mechanism
HSRP
Rfc 2281
RFC : Cisco Hot Standby Router Protocol (HSRP)
Divers
Rfc 822
RFC : Standard for the format of ARPA Internet text messages
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
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.
5 - Dfinition des diffrents champs

5.1 - Prambule
Ce champ est cod sur 7 octets et permet de synchroniser l'envoi. Chacun des octets vaut 10101010 et cette srie
permet la carte rceptrice de synchroniser son horloge.
5.2 - SFD
Ce champ est cod sur 1 octet et indique la carte rceptrice que le dbut de la trame va commencer. La valeur
de SFD (Starting Frame Delimiter) est 10101011.
5.3 - Adresse destination
Ce champ est cod sur 6 octets et reprsente l'adresse MAC (Medium Access Control) de l'adaptateur destinataire.
Dans le cadre d'un broadcast, l'adresse utilise est FF-FF-FF-FF-FF-FF.
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.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.
6 - Les types d'quipements

6.1 - Le rpteur (Repeater)
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
6.4 - Le pont (Bridge)
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
6.5 - Le routeur (Gateway)
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
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
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.
Voici la structure de l'entte IP bas sur 20 octets.
Voici le complment de l'entte IP qui est optionnel bas sur 4 octets.

3.1 - Le champ Vers
Le champ version est cod sur 4 bits. Il reprsente le numro de version du protocole IP. Il permet aux piles IP
rceptionnant la trame de vrifier le format et d'interprter correctement la suite du paquet. C'est d'ailleurs pour
cette raison qu'il est plac au dbut, une version inconnue par un quipement conduit au rejet direct.
Voici
-
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.12 - Adresse IP destination

Le champ IP destination est cod sur 32 bits et reprsente l'adresse IP destination. Il est cod sur 4 octets qui
forme l'adresse A.B.C.D.
3.13 - Options
Le champ Options est cod entre 0 et 40 octets. Il n'est pas obligatoire, mais permet le "Tuning de l'entte IP".
Afin de bien grer les Options, cela doit commencer par un octets de renseignement. Voici le dtail de cette octet
:
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
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
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".
Voici
l'entte
du
protocole
ARP
dans
le
cadre
spcifique
d'Ip
sur
Ethernet.

3.1 - Hardware type
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]
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
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

Ce champ correspond la longueur de l'adresse rseau. La longueur doit tre prise en octets. Voici des exemples
de
valeurs
courantes.
- 16 - IP v6
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]

Ce champ indique l'adresse physique de l'metteur. Dans le cadre spcifique d'Ethernet, cela reprsente l'adresse
Mac source.
Ce champ indique l'adresse rseau de l'metteur. Dans le cadre spcifique de TCP/IP, cela reprsente l'adresse Ip
de source.
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.
Ce champ indique l'adresse rseau du destinataire. Dans le cadre spcifique de TCP/IP, cela reprsente l'adresse
Ip de destination.
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.
4.2 - Arp Reply

L'hte destinataire qui va se reconnatre va pouvoir d'un cot alimenter sa table de conversion et rpondre
l'hte source en envoyant une trame comportant son adresse physique. Voici la traduction de cette rponse saisie
grce
Ethereal.
4.3 - Le cache
4.3.1 - Le cache des htes

Par la forme de la question et de la rponse, on s'aperoit que la table Arp des deux htes ont t aliment.
Voici
la
table
Arp
de
la
machine
192.168.0.3.
Voici
la
table
Arp
de
la
machine
192.168.0.1.
4.3.2 - Le cache dans la Rfc

Les mises en caches sont systmatiques et obligatoires. Le fonctionnement du cache est bien cach dans
le Rfc
826,
mais
l'on
retrouve
trois
rfrences.
La premire concerne l'envoi. Elle se trouve dans le chapitre "An Example:" dont voici un extrait :
An Example:
----------...
Machine X gets the reply packet from Y, forms the map from
<ET(IP), IPA(Y)> to EA(Y), notices the packet is a reply and
throws it away. The next time X's Internet module tries to send
a packet to Y on the Ethernet, the translation will succeed, and
the packet will (hopefully) arrive. If Y's Internet module then
wants to talk to X, this will also succeed since Y has remembered
the information from X's request for Address Resolution.
Cette exemple spcifie que l'metteur, aprs rception de la rponse, met en cache la correspondance @mac
@ip
afin
de
la
rutiliser
la
prochaine
fois
sans
mettre
de
nouvelle
requte.
La seconde concerne la rception. Elle se trouve dans le chapitre "Packet Reception:" dont voici un extrait :
Packet Reception:
----------------When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
Cette explication du fonctionnement bas sur le conditionnel aboutit, si le rcepteur possde dj l'entre
dans son cache, mettre l'entre obligatoirement jour. Et a, quelle soit ou pas identique au cache actuel.
Cette dernire rflexion est trs importante pour comprendre la faiblesse de ce process qui vise privilgier
l'conomie
et
la
rapidit
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
3.1 - Hardware type
3.2 - Protocol type
3.5 - Operation
4
5
6
7

Fonctionnement
Serveur Rarp
Discussion autour de la documentation
Suivi du document
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".
Voici
l'entte
du
protocole
ARP

3.1 - Hardware type
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
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

Ce champ correspond la longueur de l'adresse rseau. La longueur doit tre prise en octets. Voici des exemples
de
valeurs
courantes.
- 16 - IP v6
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 physique de l'metteur. Dans le cadre spcifique d'Ethernet, cela reprsente l'adresse
Mac source.
Ce champ indique l'adresse rseau de l'metteur. Dans le cadre spcifique de TCP/IP, cela reprsente l'adresse Ip
de source.
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.
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.
*/
#if !defined(_MT) // Symantec seems to need this to believe we're multithreaded

//#define _MT
#endif
#define WIN32_LEAN_AND_MEAN
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
<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"
// for sscanf; sorry!
#define VERSION "1.15"

#define TEST_VERSION 0
// if nonzero, annoying messagebox
#define WM_REALLY_CLOSE WM_APP
BOOL quiescing = FALSE;
// set by GUI, obeyed by threads
/*
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.
*/
BOOL differentObjects(HANDLE ahandleA, HANDLE ahandleB)

{
BOOL result = FALSE;
char objectNameA[ObjectNameLen];
char objectNameB[ObjectNameLen];
DWORD ignoreLenNeeded;
if ((GetUserObjectInformation(ahandleA, UOI_NAME, objectNameA,
ObjectNameLen, &ignoreLenNeeded)) &&
(GetUserObjectInformation(ahandleB, UOI_NAME, objectNameB,
ObjectNameLen, &ignoreLenNeeded))) {
result = strcmp(objectNameA, objectNameB);
}
else outFile << "Can't get object name" << GetLastError() << endl;
return result;
}
/*
Send the main window's listbox one line of text. After we send the line
we select it to make sure it's visible, and then we deselect it so it
won't call attention to itself. If we're in a desperate hurry, though dump() is, due to its responsibility in promiscuous mode - we do without
the visibility manipulation. By the way, while this function would run
faster using PostMessage() than with SendMessage(), the data wouldn't get
through reliably.
There's a kink here that was introduced when we made it possible to run,
launched by an NT service at boot time, trying to grab a desktop we wouldn't
normally have (WinLogon.) Since we can't execute SetThreadDesktop once
we already have a window, we need the ability to log messages without a
main window, i.e. straight to rarpd.log.
*/
void logLine(HWND amainWindow, const char* aline, BOOL ahurry = FALSE)
{
if (!amainWindow) {
outFile << aline << endl;
return;
}
static HWND dlg = HWND(INVALID_HANDLE_VALUE);
if (dlg == INVALID_HANDLE_VALUE) dlg = GetDlgItem(amainWindow, IDC_LOGBOX);
SendMessage(dlg, LB_ADDSTRING, 0, (LPARAM)aline);
if (!ahurry) {
LONG lastLine = SendMessage(dlg, LB_GETCOUNT, 0, 0) - 1;
SendMessage(dlg, LB_SETCARETINDEX, WPARAM(lastLine), MAKELPARAM(FALSE, 0));
UpdateWindow(dlg);
}
}
/*
This is a convenience function for the cases where we just have a string
to put out together with Windows's wisdom on what might have happened.
Just to be tidy, we strip the trailing CRLF in the Windows error message.
*/
void logLastError(HWND amainWindow, char* aline)
{
char* errMsgBuf = "";
char* msgBuf = new char[logLineLen];
ostrstream msgOss(msgBuf, logLineLen);
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL, GetLastError(),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
(LPTSTR) &errMsgBuf, 0, NULL);
char* crLoc = strchr(errMsgBuf, '\r');
if (crLoc) *crLoc = '\0';
msgOss << aline << ": " << errMsgBuf << ends;
logLine(amainWindow, msgBuf);
LocalFree(errMsgBuf);
}
/*
Running under NT, launched by a service, things get complicated. Originally
our aproach involved a window of 0 to go along with our
MB_APPLMODAL | MB_SERVICE_NOTIFICATION style. But we like to make the
whole context of the rarp transaction, i.e. the log in our main window,
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);
}
/*
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, ((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.
*/
void setNTDesktop(int& acmdShow, const OSVERSIONINFO& avInfo)

{
mbType = (avInfo.dwMajorVersion < 4) ? // Service notification
MB_TASKMODAL | 0x00040000 : MB_TASKMODAL | 0x00200000;
enum { ObjectNameLen = logLineLen / 2 };
char oldDesktopName[ObjectNameLen];
char newDesktopName[ObjectNameLen];
DWORD ignoreLenNeeded;
HWINSTA windowStation = GetProcessWindowStation();
if (windowStation) {
char stationName[ObjectNameLen];
if (GetUserObjectInformation(windowStation, UOI_NAME, stationName,
ObjectNameLen, &ignoreLenNeeded)) {
msgOss << "Window station name: " << stationName << ends;
logLine(0, msgBuf);
msgOss.seekp(0);
}
else logLastError(0, "Can't get window station name");
}
else logLastError(0, "Can't get window station");
HDESK oldDesktop = GetThreadDesktop(GetCurrentThreadId());
if (oldDesktop) {
if (GetUserObjectInformation(oldDesktop, UOI_NAME, oldDesktopName,
msgOss << "Old desktop name: " << oldDesktopName << ends;
logLine(0, msgBuf);
msgOss.seekp(0);
}
else logLastError(0, "Can't get old desktop name");
}
else logLastError(0, "Can't get thread desktop");
HDESK newDesktop = OpenInputDesktop(0, TRUE, DESKTOP_CREATEWINDOW |
DESKTOP_SWITCHDESKTOP);
if (newDesktop) {
if (GetUserObjectInformation(newDesktop, UOI_NAME, newDesktopName,
msgOss << "New desktop name: " << newDesktopName << ends;
logLine(0, msgBuf);
msgOss.seekp(0);
}
else logLastError(0, "Can't get new desktop name");
if (strcmp(oldDesktopName, newDesktopName)) {
if (SetThreadDesktop(newDesktop)){
acmdShow = SW_SHOWNORMAL;
mainWindowDesktop = newDesktop;
}
else logLastError(0, "SetThreadDesktop");
}
else {
mainWindowDesktop = oldDesktop;
logLine(0, "Already have the input desktop");
}
}
else logLastError(0, "Can't open input desktop");
}
/*
The handles for dealing with the NT RARP driver:
*/
SC_HANDLE scmHandle = NULL;
SC_HANDLE srvHandle = NULL;
HANDLE ntRarpHandle = INVALID_HANDLE_VALUE;
HINSTANCE ourInstance = HINSTANCE(INVALID_HANDLE_VALUE);
/*
Normally the driver doesn't already exist as a service when we're called,
but if it already exists that's OK. We know the current directory has been
set to the directory rarpd was loaded from. The call to GetFileAttributes
is necessary because CreateService will vacuously succeed even if it fails
to find the driver.
*/
BOOL installNTDriver(SC_HANDLE ascmHandle)

{
char driverPath[logLineLen];
*driverPath = 0;
GetCurrentDirectory(logLineLen, driverPath);
wsprintf(driverPath + strlen(driverPath), "\\RARP.SYS");
if (GetFileAttributes(driverPath) != 0xffffffff) {
SC_HANDLE srvHandle =
CreateService(ascmHandle, "RARP", "RARP Support",
SERVICE_ALL_ACCESS,
SERVICE_KERNEL_DRIVER,
SERVICE_DEMAND_START,
SERVICE_ERROR_NORMAL,
driverPath,
NULL, NULL, NULL, NULL, NULL);
if (srvHandle == NULL) {
if (GetLastError() == ERROR_SERVICE_EXISTS) {
logLine(0, "RARP.SYS already existed");
result = TRUE;
}
else logLastError(0, "Couldn't install RARP.SYS");
}
else {
logLine(0, "Created service for RARP.SYS");
result = TRUE;
CloseServiceHandle(srvHandle); // 0.54.2
}
}
else logLine(0, "Can't find RARP.SYS");
return result;
}
/*
Here we wait for success (in which case we return TRUE) or either of two
kinds of failure:
- we get an error from StartService() other than an indication that the
service database is still locked;
- the user gives up.
In either error condition we log an error message and return FALSE.
*/
BOOL APIENTRY startServiceDialogProc(HWND hDlg, UINT message, UINT wParam,
LONG /* lParam */)
{
switch (message)
{
case WM_INITDIALOG:
{
SetDlgItemText(hDlg, IDC_EDIT_WAIT_SCM,
"Windows NT has reported to rarpd that the "
"service database is locked. This means that "
"rarpd's device driver cannot yet be started. "
"Normally this is "
"a temporary situation, especially when rarpd "
"is being used to configure a new workstation.\r\n"
"Unless you press the button below, rarpd will "
"continue trying to start its driver until it "
"succeeds.\r\n"
"If you press the button, rarpd will try to reach "
"the rarp server without the use of its device "
"driver. You are strongly urged to wait.");
SetTimer(hDlg, 0, 5000, NULL);
}
break;
case WM_COMMAND:
if (wParam == IDC_BUTTON_STOP) {
SetLastError(ERROR_SERVICE_DATABASE_LOCKED);
logLastError(0, "Couldn't start RARP service");
return EndDialog(hDlg, FALSE);
}
break;
case WM_TIMER:
if (StartService(srvHandle, 0, NULL)) return EndDialog (hDlg, TRUE);

else {
DWORD error = GetLastError();
if (error != ERROR_SERVICE_DATABASE_LOCKED) {
SetLastError(error);
return EndDialog (hDlg, FALSE);
}
}
break;
}
return FALSE;
}
/*
Because our call to StartService() can be frustrated by a transitory lock
on the service database held by some other process, we keep trying to
start our driver periodically while displaying a dialog that allows the
user to give up.
*/
void ourStartService()
{
if (StartService(srvHandle, 0, NULL)) result = TRUE;
else {
DWORD error = GetLastError();
if (error == ERROR_SERVICE_DATABASE_LOCKED) {
result = DialogBox(ourInstance, MAKEINTRESOURCE(DIALOG_WAIT_SCM), 0,
(DLGPROC)startServiceDialogProc);
}
else {
SetLastError(error);
}
}
if (result) logLine(0, "Started RARP service");
}
void connectToNTDriver()
{
scmHandle = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS);
if (scmHandle == NULL) fail(0, "OpenSCManager");
if (installNTDriver(scmHandle)) {
srvHandle = OpenService(scmHandle, "RARP", SERVICE_ALL_ACCESS);
if (srvHandle != NULL) ourStartService();
else logLastError(0, "Couldn't open RARP service");
}
}
void disconnectFromNTDriver()
{
if (ntRarpHandle != INVALID_HANDLE_VALUE) {
if (!CloseHandle(ntRarpHandle)) {
logLastError(0, "Can't close RARP device");
}
}
if (srvHandle != NULL) {
SERVICE_STATUS serviceStatus;
SC_HANDLE stopHandle = OpenService(scmHandle, "RARP",
SERVICE_ALL_ACCESS);
if (stopHandle == NULL) logLastError(0, "OpenService stopping RARP");
else {
if (!ControlService(stopHandle, SERVICE_CONTROL_STOP, &serviceStatus)) {
logLastError(0, "ControlService SERVICE_STOP");
}
CloseServiceHandle(stopHandle);
}
SC_HANDLE removeHandle = OpenService(scmHandle, "RARP",
SERVICE_ALL_ACCESS);
if (removeHandle == NULL) logLastError(0, "OpenService removing RARP");
else {
if (!DeleteService(removeHandle)) {
logLastError(0, "DeleteService for RARP");
}
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* 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)
{
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) {
msgOss << "Failure on " << apath << " at subkey: " << subKeyName <<
" with read access." << ends;
}
RegCloseKey(thisKeyHandle);
return NULL;
}
RegCloseKey(nextKeyHandle);
if (RegOpenKeyEx(thisKeyHandle, subKeyName, 0,
KEY_READ | KEY_SET_VALUE,
&nextKeyHandle)!= ERROR_SUCCESS) {
if (!asilent) {
msgOss << "Failure on " << apath << " at subkey: " << subKeyName <<
" with full access." << ends;
}
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)
{
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);
DWORD regType;
// value's type
if (keyHandle == NULL) abortOnBadKey(akeyName, amainWindow);
if (RegQueryValueEx(keyHandle, anexpectedName, NULL,
&regType, 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,
BOOL adumpDriver, DWORD arxTimeout,

SubnetHolder& anexcludedSubnets) :
mainWindow(amainWindow), dumpDriver(adumpDriver),
rxTimeout(arxTimeout),
excludedSubnets(anexcludedSubnets),
transportKeyName(NULL), adapterName(NULL) { };
~WorkerParams() {
if (transportKeyName) delete transportKeyName;
if (adapterName) delete adapterName;
};
void dumpDriverMemory();
char* findNT4NetcardTCPParams();
char* findNT5NetcardTCPParams();
BOOL isSubnetExcluded(char* atcpParamsKeyName);
void openntRarp();
BOOL checkStack();
UINT ourIpAddress();
BOOL probeAdapter(char* anadapterName);
};
/*
If we get something from the netcard that looks fishy, we want to dump it.
*/
void dump(HWND amainWindow, UINT asize, BYTE* abufP, char* alegend)
{
logLine(amainWindow, alegend);
for (UINT offset = 0; offset < asize; offset += 16) {
msgOss << hex << setw(3) << setfill('0') << offset << ":";
for (UINT incr = 0; incr < 16; incr++) {
if (offset + incr >= asize) break;
if ((incr % 4) == 0) msgOss << " ";
msgOss << hex << setw(2) << setfill('0') << WORD(abufP[offset + incr]);
}
msgOss << ends;
logLine(amainWindow, msgBuf, TRUE);
}
}
BOOL ReceiverParams::getntRarpHardwareAddress()
{
char allZeroes[6] = { 0 };
DWORD length;
BYTE hwType;
if (DeviceIoControl(ntRarpHandle, DIOC_RarpGetMacAddress,
NULL, 0, ourMacAddress, MacAddressSize, &length, NULL) &&
memcmp(ourMacAddress, allZeroes, sizeof(allZeroes))) {
DWORD hwLength;
if (DeviceIoControl(ntRarpHandle, DIOC_RarpGetHWType,
NULL, 0, &hwType, 1, &hwLength, NULL)) {
result = TRUE;
ourHwLen = UCHAR(length);
ourHwType = htons(hwType);
}
}
return result;
}
/*
The receiver thread exits when it detects a good reply
(params->success TRUE) or when the socket fails (FALSE.)
*/
void rarpReceiver(void* aparams)
{
ReceiverParams& params = *((ReceiverParams*)aparams);
if (!params.getntRarpHardwareAddress()) {
fail(params.mainWindow, "Couldn't get hardware address.");
}
RarpBuf rxBuf, txBuf;
txBuf.ap.hwType = params.ourHwType;
txBuf.ap.protType = htons(ProtocolTypeIP);
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;
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 {
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 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 */,
&ethAddrCode, 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***
size_t cardKeyNameLen = strlen(keyNameBuf); // length so far...

valueBufLen = ValueBufLen;
strcpy(keyNameBuf + cardKeyNameLen, "\\Ndi\\Interfaces");
if (!keyExists(keyNameBuf, mainWindow)) continue; // not physical...
// If our driver could handle ALL media we'd use Characteristics of x84
// as our test of the physicality of the adapter.
if (getValue(keyNameBuf, "LowerRange", (BYTE*)valueBuf, valueBufLen,
REG_SZ, mainWindow) &&
((!stricmp(valueBuf, "ethernet")) ||
(!stricmp(valueBuf, "token ring")))) {
logLine(mainWindow, "...is a physical netcard"); // ***temp***
keyNameBuf[cardKeyNameLen] = '\0';
if (getValue(keyNameBuf, "NetCfgInstanceId", (BYTE*)valueBuf,
valueBufLen, REG_SZ, mainWindow)) {
logLine(mainWindow, valueBuf); // ***temp***
char* resultSave = result;
result = new char[strlen(tcpParamsPrefix) +
strlen(keyNameTail(valueBuf)) + 1];
strcpy(result, tcpParamsPrefix);
strcat(result, keyNameTail(valueBuf));
#if 0
// ***temp 1.10.1***
HKEY tcpParamsKey = getKey(result, mainWindow);
if (tcpParamsKey != NULL) {
logLine(mainWindow, "...bound to TCP/IP");
RegCloseKey(tcpParamsKey);
}
else {
delete[] result;
continue;
}
#endif
// Is the NTEContextList stuff needed?
char physSignature[ValueBufLen]; // signature of physical netcard
if (!getValue(result, "NTEContextList", (BYTE*)physSignature,
valueBufLen, REG_MULTI_SZ, mainWindow) ||
isSubnetExcluded(result) ||
!probeAdapter(keyNameTail(valueBuf))) {
delete[] result;
continue;
}
else if (++nTCPKeys > 1) break;
else {
adapterName = new char[strlen(keyNameTail(valueBuf)) + 1];
strcpy(adapterName, keyNameTail(valueBuf));
}
}
}
}
RegCloseKey(netcardClassHandle);
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 valueBuf;
delete keyNameBuf;
return result;
}
/*
When the Registry fails us we try to get our IP address this way.
*/
UINT getWinsockLocalIp()
{
UINT result = 0;
WSAData wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData) == 0) {
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];
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");
wndclass.hCursor = LoadCursor (NULL, IDC_ARROW);

wndclass.hbrBackground = (HBRUSH)(COLOR_BTNFACE+1);
wndclass.lpszMenuName = NULL;
wndclass.lpszClassName = appName;
RegisterClass(&wndclass);
amainWindow = CreateDialog(hInstance, MAKEINTRESOURCE(DIALOG_MAIN), NULL,
(DLGPROC)mainDialogProc);
if (amainWindow) {
#if 0
if ((srvHandle != NULL) && !allowClose) {
HMENU ctrlMenuH = GetSystemMenu(amainWindow, FALSE);
if (ctrlMenuH != NULL) {
EnableMenuItem(ctrlMenuH, SC_CLOSE, MF_BYCOMMAND | MF_GRAYED);
}
}
#endif
ShowWindow(amainWindow,
((nCmdShow == SW_SHOWDEFAULT) ? SW_SHOWMINIMIZED : nCmdShow));
return TRUE;
}
else {
char* complaint = "Couldn't create main window";
logLastError(0, complaint);
MessageBox(0, complaint, "rarpd", MB_ICONSTOP);
return FALSE;
}
}
/*
Here we extract the /t<seconds> option, returning a millisecond value,
or, failing that, return the default 30,000 milliseconds.
*/
DWORD getTimeout(char* acmdLine)
{
DWORD result = 30000;
if (acmdLine != NULL) {
char* optionP = strstr(acmdLine, "/t");
if (optionP == NULL) optionP = strstr(acmdLine, "/T");
if (optionP != NULL) {
int secs = atoi(optionP + 2);
if (secs > 0) result = secs * 1000;
}
}
return result;
}
/*
We want to set the current directory to the one we were launched from.
This can be tricky because if we were launched by the rarpd Launcher
our full file path is encased in quotes in the command line. Then we can
open the logfile according to whether the user wants to overwrite any old
logfile or append to it. If we were launched from the command line
without an explicit path, there's no need to set the current directory.
*/
void openLog(char* cmdLine)
{
const char* progNameSentinels = (cmdLine[0] == '"') ? "\\\"" : "\\ ";
char* lastBackslash = strchr(cmdLine, '\\');
while (lastBackslash != NULL) {
size_t nextSentinelLoc = strcspn(lastBackslash + 1, progNameSentinels);
char sentinel = lastBackslash[nextSentinelLoc + 1];
if (sentinel != '\\') break;
lastBackslash += (nextSentinelLoc + 1);
}
char dirPath[MAX_PATH];
if (lastBackslash != NULL) {
char* cmdLineDirStart = cmdLine + strspn(cmdLine, "\"");
size_t dirPathLen = lastBackslash - cmdLineDirStart;
memcpy(dirPath, cmdLineDirStart, dirPathLen);
dirPath[dirPathLen] = '\0';
SetCurrentDirectory(dirPath);
}
if ((strstr(cmdLine, "/a") != NULL) || (strstr(cmdLine, "/A") != NULL)) {
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
3.1 - Type et Code

3.1.1 - Type=0,8 - Le Ping
3.1.2 - Type=3 - Destination non valide
3.1.3 - Type=4 - Volume de donne trop importante
3.1.4 - Type=5 - Redirection
3.1.5 - Type=9,10 - dcouverte de routeur
3.1.6 - Type=11 - Temps excd
3.1.7 - Type=12 - Erreur d'entte
3.1.8 - Type=13,14 - Marqueur temporel
3.1.9 - Type=15,16,17,18 - Demande d'information
3.2 - Checksum
3.3 - Identifiant
3.4 - Numro de squence
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.
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.

3.1 - Type et Code
Les champs Type et Code sont cods respectivement sur 8 bits ce qui donne un totale de 2 octets. Ils
reprsentent la dfinition de message d'erreur contenu. Voici la liste des principales combinaison entre les champs
Type et Code :
Type
Code
Description
Rponse une demande d'cho
Rseau inaccessible
Hte inaccessible
Protocole inaccessible
Port inaccessible
Fragmentation ncessaire mais interdite
Echec de routage par la source
Rseau de destination inconnu
Hte de destination inconnue
Machine source isole
Rseau de destination interdit administrativement
10
Hte de destination interdite administrativement
11
Rseau inaccessible pour ce type de service
12
Hte inaccessible pour ce type de service
13
Communication interdite par un filtre
14
Host Precedence Violation
15
Precedence cutoff in efect
Volume de donne trop importante
Redirection pour un hte
Redirection pour un hte et pour un service donn
Redirection pour un rseau
Redirection pour un rseau et pour un service donn
Demande d'cho
Avertissement routeur
10
Sollicitation routeur
11
Dure de vie coule avant d'arrive destination
11
Temps limite de rassemblage du fragment dpass
12
En-tte IP invalide
12
Manque d'une option obligatoire
12
Mauvaise longueur
13
Requte pour un marqueur temporel
14
Rponse pour un marqueur temporel
15
Demande d'adresse rseau
16
Rponse d'adresse rseau
17
Demande de masque de sous rseau
18
Rponse de masque de sous rseau
3.1.1 - Type=0,8 - Le Ping

Le principe du Ping tant, la base, de valider la prsence d'un Hote IP. Pour cela, l'application Ping utilisera
la squence 8-0 afin d'mettre une demande d'cho. Les donnes reues dans un message d'cho doivent
tre rmises dans la rponse. Ainsi, si le message de retour correspond l'mission, on en dduit que l'Hote
est prsent. De plus, on peux en dduire d'autres services, tel que le temps de rponse, la taille paquet
maximum
la
dure
de
vie
et
etc.
L'identificateur et le numro de squence peuvent tre utiliss par l'metteur du message d'cho afin
d'associer facilement l'cho et sa rponse. Par exemple, l'identificateur peut tre utilis comme l'est un port
pour TCP ou UDP, identifiant ainsi une session. Et le numro de squence peut tre incrment pour chaque
message d'cho envoy. L'hte de destination respectera ces deux valeurs pour le retour.
3.1.2 - Type=3 - Destination non valide
Ce type de message est mis dans le cas o un routeur ou un hte ne puisse pas router un paquet.
3.1.3 - Type=4 - Volume de donne trop importante

Un routeur ou hte peut tre amen dtruire un Datagramme s'il manque de mmoire pour bufferiser.
Dans ce cas, le routeur mettra un message destination de la source du Datagramme dtruit, un paquet
ICMP
de
type
4.
Cela peut ce produire dans un second cas. Quand le Datagramme arrive trop rapidement pour qu'il puisse
tre trait le message ICMP peut donc constituer une demande de diminution de dbit de transfert.
3.1.4 - Type=5 - Redirection
Ces types de messages sont mis afin d'indiquer que le chemin emprunt n'est pas le bon pour la destination
demand. La rception de ce type de message d'erreur peut tre interprte par la modification de la table
de routage locale. C'est plus communment appel "Icmp Redirect".
3.1.5 - Type=9,10 - dcouverte de routeur
Au dmarrage d'une station, plutt que de configurer manuellement les routes statiques, surtout si elle sont
susceptibles de changer et que le nombre de stations est grands, il peut tre intressant de faire de la
dcouverte automatique de routeurs. Pour cela, il y a deux possibilits. La premire est l'envoi rgulier de
messages ICMP de type 9 "Avertissement routeur" d'annonces de routes par les routeurs. La seconde
possibilit est qu'une station sollicite les routeurs avec un message de type 10 "Sollicitation routeur".
La dcouverte de routeur n'est pas un protocole de routage, son objectif est bien moins ambitieux , juste
obtenir
une
route
par
dfaut.
Vous trouverez tous les dtails du "dcouverte de routeur" dans la Rfc 1256.
3.1.6 - Type=11 - Temps excd
Lorsqu'un routeur traitant un Datagramme est amen mettre jour le champ Dure de Vie de l'en-tte IP
et que ce champ atteint une valeur zro, le Datagramme sera dtruit. Le routeur peut alors envoyer un
message d'erreur "Time To Live expir". Ce message ICMP peux tre mis aussi dans le cas o le temps de
rassemblage expire et le Datagramme ne peux donc tre reconstitu temps.
3.1.7 - Type=12 - Erreur d'entte
Si un routeur rencontre un problme avec un paramtre d'en-tte IP l'empchant de finir son traitement, le
datagramme sera alors dtruit. Un message d'erreur de type 12 sera donc alors mis.
3.1.8 - Type=13,14 - Marqueur temporel
Le but de ce type de message est de s'changer des donnes temporelles pour, par exemple, synchroniser
les horloges.
3.1.9 - Type=15,16,17,18 - Demande d'information
Ce type de message est envoy vers une adresse constitue du numro de rseau dans le champ source de
l'en-tte IP et un champ destinataire 0. La pile IP qui rpondra pourra alors envoyer une rponse avec les
adresses entirement renseignes.
3.2 - Checksum
Le champ Checksum est cod sur 16 bits et reprsente la validit du paquet de la couche 3 ICMP. Pour pouvoir
calculer le Checksum, il faut positionner le champ du checksum a 0. Ce calcul est strictement le mme que celui
du
protocole IGMP.
Voici un exemple de fonction permettant le calcul du checksum ICMP.
{
// ********************************************************
// ********************************************************
while(taille>1)
{
}
if(taille)
}
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.
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
3.1 - Type
3.2 - Temps de rponse max
3.3 - Checksum
3.4 - Adresse du groupe
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.
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.

3.1 - Type
Le champ Type est cod sur 8 bits et dtermine la nature du message IGMP. Voici les 4 types de messages
existant
:
11
00001011
Requte
pour
identifier
les
groupes
ayant
des
membres
actifs.
- 12 - 00001100 - Rapport d'appartenance au groupe mis par un membre actif du groupe (IGMP version 1)
- 16 - 00010000 - Rapport d'appartenance au groupe mis par un membre actif du groupe (IGMP version 2)
- 17 - 00010001 - Un membre annonce son dpart du groupe
3.2 - Temps de rponse max
Ce champ n'est utilis que pour les messages de type 11. Il indique le temps d'attente maximum pour un client
avant l'mission du rapport d'appartenance. L'unit utilise est le 1/10 de seconde. Pour les autres types, ce
champ est marqu 0.
3.3 - Checksum
Le champ Checksum est cod sur 16 bits et reprsente la validit du paquet de la couche 3 IGMP. Pour pouvoir
calculer le Checksum, il faut positionner le champ du checksum a 0. Ce calcul est strictement le mme que celui
du
protocole ICMP.
Voici un exemple de fonction permettant le calcul du checksum IGMP :
{
// ********************************************************
// ********************************************************
while(taille>1)
{
}
if(taille)
}
unsigned short calcul_du_checksum_igmp(bool liberation, struct igmp igmp_tampon,char data_tampon[65535])
{
char tampon[65535];
// ********************************************************
// ********************************************************
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
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.1 - Port source
5.2 - Port destination
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
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.
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
3.3 - Fermeture de session

<==
ACK=1
FIN=1
==> ACK=1 - FIN=0 - SeqNum=136 - AckNum=321
SeqNum=321
AckNum=136
3.4 - Fermeture brutale de connexion

1re
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
Vitesse de la liaison (bits par seconde pouvant tre transmis)

Retard de propagation
Dimension de la fentre (quantit de donnes n'ayant pas fait l'objet d'un accus de rception et qui peuvent
tre en attente sur une connexion TCP)
Fiabilit de la liaison
Encombrement du rseau et des priphriques intermdiaires
MTU du parcours
quelques
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.

5.1 - Port source
Le champ Port source est cod sur 16 bits et correspond au port relatif l'application en cours sur la machine
source.
Le champ Port destination est cod sur 16 bits et correspond au port relatif l'application en cours sur la machine
de destination.
Vous trouverez la liste des ports TCP officialises par l'IANA, organisation grant mondialement les adressage IP.
Le champ Numro de squence est cod sur 32 bits et correspond au numro du paquet. Cette valeur permet de
situer quel endroit du flux de donnes le paquet, qui est arriv, doit se situer par rapport aux autres paquets.
5.4 - Numro de l'accus de rception
Le champ Numro de squence est cod sur 32 bits et dfinit un acquittement pour les paquets reus. Cette
valeur signale le prochain numro de paquet attendu. Par exemple, si il vaut 1500, cela signifie que tous les
Datagrammes <1500 ont t reus
5.5 - Offset
Le champ Offset est cod sur 4 bits et dfinit le nombre de mots de 32 bits dans l'entte TCP. Ce champ indique
donc o les donnes commencent.
5.6 - Rserv
Le champ Rserv est cod sur 6 bits et il servira pour des besoins futurs. Ce champ doit tre marqu 0. Au jour
d'aujourd'hui, on peut considrer que les besoins futurs se transforment en un champ non utilis.
5.7 - Flags
- Le champ URG est cod sur 1 bit et indique que le champ Pointeur de donne urgente est utilis.
- Le champ ACK est cod sur 1 bit et indique que le numro de squence pour les acquittements est valide.
- Le champ PSH est cod sur 1 bit et indique au rcepteur de dlivrer les donnes l'application et de ne pas
attendre
le
remplissage
des
tampons.
Le
champ
RST
est
cod
sur
1
bit et demande la
rinitialisation de
la connexion.
- Le champ SYN est cod sur 1 bit et indique la synchronisation des numros de squence.
- Le champ FIN est cod sur 1 bit et indique fin de transmission.
5.8 - Fentre
Le champ Fentre "Windows" est cod sur 16 bits et correspond au nombre d'octets partir de la position
marque dans l'accus de rception que le rcepteur est capable de recevoir. Le destinataire ne doit donc pas
envoyer les paquets aprs Numro de squence + Window.
5.9 - Checksum
Le champ Checksum est cod sur 16 bits et reprsente la validit du paquet de la couche 4 TCP.
Le Checksum est constitu en calculant le complment 1 sur 16 bits de la somme des complments 1 des
octets de l'en-tte et des donnes pris deux par deux (mots de 16 bits). Si le message entier contient un nombre
impair d'octets, un 0 est ajout la fin du message pour terminer le calcul du Checksum. Cet octet
supplmentaire n'est pas transmis. Lors du calcul du Checksum, les positions des bits attribus celui-ci sont
marques
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 )
};
{
// ********************************************************
// ********************************************************
while(taille>1)
{
}
if(taille)
}
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];
// ********************************************************
// ********************************************************
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
3.1 - Port source
3.3 - Longueur
3.4 - Checksum
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.
Voici
la
structure
de
l'entte
UDP
bas
sur
octets.

3.1 - Port source
Le champ Port source est cod sur 16 bits et correspond au port relatif l'application en cours sur la machine
source.
Le champ Port destination est cod sur 16 bits et il correspond au port relatif l'application en cours sur la
machine de destination.
Vous trouverez la liste des ports TCP officialises par l'IANA, organisation grant mondialement les adressage IP.
3.3 - Longueur
Le champ Longueur est cod sur 16 bits et il reprsente la taille de l'entte et des donnes. Sont unit est l'octet
et sa valeur maximale est 64 Koctets (216).
3.4 - Checksum
Le champ Checksum est cod sur 16 bits et reprsente la validit du paquet de la couche 4 UDP.
Le Checksum est constitu en calculant le complment 1 sur 16 bits de la somme des complments 1 des
octets de l'en-tte et des donnes pris deux par deux (mots de 16 bits). Si le message entier contient un nombre
impair d'octets, un 0 est ajout la fin du message pour terminer le calcul du Checksum. Cet octet
supplmentaire n'est pas transmis. Lors du calcul du Checksum, les positions des bits attribus celui-ci sont
marques
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.
{
};
{
// ********************************************************
// ********************************************************
while(taille>1)
{
}
if(taille)
}
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];
// ********************************************************
// ********************************************************
udp_tampon.checksum=0; // Doit tre 0 pour le calcul
// ********************************************************
// Le calcul du Checksum UDP (Idem TCP)

// ********************************************************
// Le calcul passe par une pseudo entete UDP + l'entete UDP + les Data
pseudo_udp.ip_source=ip_source_tampon;
pseudo_udp.ip_destination=ip_destination_tampon;
pseudo_udp.mbz=0;
pseudo_udp.type=IPPROTO_UDP;
pseudo_udp.length=htons((unsigned short)(sizeof(struct udp)+(unsigned short)strlen(data_tampon)));
memcpy(tampon,&pseudo_udp,sizeof(pseudo_udp));
memcpy(tampon+sizeof(pseudo_udp),&udp_tampon,sizeof(struct udp));
memcpy(tampon+sizeof(pseudo_udp)+sizeof(struct udp),data_tampon,strlen(data_tampon));
checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(pseudo_udp)+sizeof(struct
udp)+strlen(data_tampon));
return(checksum);
}
Entte IPv6
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
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.
IPv6 est dfinit par la RFC 2460.
Voici la structure de l'entte IP bas sur 40 octets.

L'entte qui tait de 20 octets en IPv4 passe 40 octets en IPv6. Certains champs d'IPv4 ont t supprims, ou sont
maintenant optionnels, ceci afin de rduire le cot de traitement des paquets et de bande passante des enttes IPv6.
3.1 - Version (Version)
Le champ "Version" est cod sur 4 bits. Il reprsente le numro de version du Protocole Internet. Sa valeur est
donc gale 6 (0110 base 2). Ce champ est identique la pile IPV4, il sert justement identifier le protocole de
couche
3
du
modle
OSI.
Voici
la
liste
des
diffrent
codes
:
-
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
3.2 - Classe (Traffic Class)

Le champ "Classe" est cod sur 8 bits. Il dfinit la priorit du datagramme afin que des noeuds origines et des
routeurs transmetteurs puissent identifier et distinguer la classe ou la priorit du paquets IPv6 en question.
3.3 - Label (Flow Label)
Le champ "Label" est cod sur 20 bits. Il peut tre utilis par une source pour nommer des squences de paquets
pour lesquels un traitement spcial de la part des routeurs IPv6 est demand. Ce traitement spcial pourrait tre
une qualit de service diffrente du service par dfaut ou un service "temps rel".
3.4 - Longueur (Payload Length)
Le champ "Longueur" est cod sur 16 bits. Le champ "Longueur" de l'entte IPV4 indiquait la longueur des
donnes incluant l'entte IPV4. Contrairement cela, cette fois le champ "Longueur" de l'entte IPv6 indique le
nombre d'octet des donnes qui suivent cette entte IPv6. Il faut not que les options de l'entte IPv6 sont
considrs comme de la donne et font donc partie du calcul du champ "Longueur".
3.5 - 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
l'entte IPv6. Les valeurs employes sont identiques au champ "Protocole" de l'entte IPV4. Vous trouverez tous
les dtails des types de protocole dans la RFC 1700 qui remplace dsormais la RFC 1340.
Voici
la
- 58 - 00111010 -
liste
des
01
02
06
17
ICMPV6
protocoles
les
plus
connu
00000001
00000010
00000110
00010001
:
ICMP
IGMP
TCP
UDP
Voici la liste des options de l'entte IPv6 vues plus bas :

00
- 50 - Option ESP
60
43
44
51
Option
-
Sauts
Option
Option
Option
Option
aprs
sauts
Destination
Routage
Fragmentation
AH
3.6 - Saut maximum (Hop Limit)

Le champ "Saut maximum" est cod sur 8 bits. Il indique le nombre de routeur maximum que le datagramme
pourra traverser. Identiquement au champ "TTL" de l'entte IPV4, il est dcrment de 1 par chaque noeud que le
paquet traverse.
3.7 - Adresse source (Source Address)
Le champ "Adresse source" est cod sur 128 bits. Il reprsente l'adresse IP de l'metteur.
3.8 - Adresse destination (Destination Address)
Le champ "Adresse destination" est cod sur 128 bits. Il reprsente l'adresse IP du destinataire.
4 - Structure des options de l'entte

Voici la structure de cette option base sur N octets.


Voici la structure de cette option base sur 8 octets.


5 - Dfinition des diffrentes champs des Options

Lors de l'utilisation de plusieurs extensions, il est recommand d'utiliser l'ordre suivant :
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.
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.
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.
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.2 - Rserv (Reserved)

Le champ "Rserv" est cod sur 8 bits. Il est prvu pour des besoins futurs, en attendant, sa valeurs doit
tre positionne 0 pour l'mission et il doit tre ignor pour la rception.
5.2.3 - Offset (Fragment Offset)
Le champ "Offset" est cod sur 13 bits. Il indique l'offset des donnes suivant cette entte, en nombre de
mots de 8 octets, par rapport au dbut de la partie fragmentable du paquet original.
5.2.4 - Rserv (Res)
5.2.5 - M (M)
Le champ "M" est cod sur 1 bit. Il peux prendre deux valeurs. 0 pour indiquer que c'est le dernier fragment
et 1 pour signifier que ce n'est pas termin.
5.1.6 - Identification (Identification)
Le champ "Identification" est cod sur 32 bits. Pour chaque paquet devant tre fragment, le noeud source
gnre une valeur d'Identification. L'Identification doit tre diffrente de tout autre identification de paquet
fragment envoy rcemment avec les mmes Adresse Source et Adresse Destination. Si un entte de
routage est prsent, l'Adresse Destination concerne est celle de la destination finale.
L'option de "Destination" est utilise pour transporter des informations optionnelles qui ont besoin d'tre
examines uniquement par les noeuds destination du paquet. Cette Option est cod 60 et est dfinie par laRFC
2460.
Le champ "Longueur" est cod sur 8 bits. Il reprsente la taille de cette Option "Destination". L'unit de
mesure est les mots de 8 octets sans compter les 8 premiers octets.
5.4.3 - Options (Options)
Le champ "Options" est cod sur N bits. Il contient le contenu de l'option spcifier.
L'option "AH" est utilise pour fournir un mcanisme permettant au destinataire de s'assurer de l'identit de la
source et de l'intgrit des donnes. Cela fournit surtout une bonne protection contre les rejeux et les spoofing IP.
Cette Option est cod 51 et est dfinie par la RFC 4302.
5.5.2 - Longueur (Payload Len)

Le champ "Longueur" est cod sur 8 bits. Il reprsente la taille de cette Option "AH". L'unit de mesure est
les mots de 4 octets avec une valeur minimale de 2.
5.5.3 - Rserv (Reserved)
5.5.4 - SPI (Security Parameters Index)
Le champ "SPI" est cod sur 32 bits. Il permet au destinataire d'identifier l'association de scurit (SA) avec
le datagramme entrant.
5.5.5 - Squence (Sequence Number Field)
Le champ "Squence" est cod sur 32 bits. Il contient le numro de squence du SA. Il est incrment
chaque datagramme.
5.5.6 - ICV (Integrity Check Value-ICV)
Le champ "ICV" est cod sur N bits. Il contient la valeur du rsultat d'un procd cryptographique sur les
donnes. Cela permet de protger et vrifier l'intgrit de celles-ci.
L'option "ESP" est utilise aprs l'entte IP et avant les donnes (l'entte de couche suprieur). Elle complte
l'option 'AH" afin d'offrir la confidentialit des donnes. Elle permet en plus de chiffrer l'ensemble des paquets
incluant ou pas l'entte IPv6. Cette Option est cod 50 et est dfinie par la RFC 4303.
5.6.1 - SPI (Security Parameters Index)
Le champ "SPI" est cod sur 32 bits. Il permet au destinataire d'identifier l'association de scurit (SA) avec
le datagramme entrant.
5.6.2 - Squence (Sequence Number)
Le champ "Squence" est cod sur 32 bits. Il contient le numro de squence du SA. Il est incrment
chaque datagramme.
5.6.3 - Donnes utiles (Payload Data)
Le champ "Donnes utiles" est cod sur N bits. Il contient les donnes chiffres.
5.6.4 - Remplissage (Padding)
Le champ "Remplissage" est cod sur N bits. Il permet de combler l'entte de donnes non intressante afin
d'obtenir une taille de multiple. La longueur maximum possible est 255 octets.
5.6.5 - Longueur (Pad Length)
Le champ "Longueur" est cod sur 8 bits. Il reprsente la taille du champ "Remplissage".
5.6.7 - ICV (Integrity Check Value)

Le champ "ICV" est cod sur N bits. Il contient le Hash de l'entte ESP.
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
1 - Introduction

Avec le dveloppement croissant du monde de l'internet, et notamment des liaisons connexions permanentes
comme le cble ou l'ADSL, de plus en plus de particuliers utilisent de la NAT pour partager leur accs Internet,
parfois mme sans le savoir ;-) Il m'a donc sembl opportun de faire un petit cours rassemblant les ides
principales qui tournent autour de la NAT, et d'essayer de les clarifier. Ce cours se limitera l'tude de la NAT sur
le modle TCP/IP. Pour comprendre les mcanismes mis en oeuvre dans la NAT, vous aurez besoin d'avoir
quelques connaissances sur le modle TCP/IP, et notamment sur les couches 3 et 4 du modle OSI (IP et
TCP/UDP).
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 le 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 cours 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 attrait la NAT et rendent l'expos plus complet,
combler tout manque pour amliorer ce cours.
2 - Dfinitions
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.
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.
8 - Vaut-il mieux faire de la NAT ou avoir un proxy ?

8.1 - Avantages du proxy
Comme nous l'avons vu, un proxy est ddi un protocole (une application) particulier. Ainsi, il est capable
d'interprter le trafic et notamment de cacher les informations. On diminue ainsi le trafic et augmente la bande
passante de la mme occasion. On peut aussi autoriser ou non l'accs certaines partie d'un site, certaines
fonctionnalits, etc. On a donc un bon contrle de ce qui transite sur le rseau, et on sait quels protocoles peuvent
circuler.
8.2- Avantages de la NAT
Contrairement au proxy, la NAT est indpendante des applications utilises. On peut donc faire passer la plupart
des protocoles que l'ont veut.
8.3 - Alors ? NAT ou proxy ?
La rponse est bien sur... a dpend !! Vous tes dus ? Il ne faut pas, car si vous avez bien lu et compris ce qui
prcde, vous devriez tre en mesure de faire votre choix vous mme en fonction de ce que vous avez (adresses,
matriel, etc.) et de ce que vous voulez faire (applications, politique de scurit, etc.). Personnellement, j'ai une
petite prfrence pour la NAT car elle ne limite pas ce que je peux faire sur le rseau, je n'ai donc pas de
mauvaises surprises quand j'utilise un nouveau protocole un peu exotique ;-)
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.
10 - Utilitaires pour faire de la NAT

10.1 - Sous windows
Voici quelques noms de produits qui permettent entre autres de faire de la NAT, une prsentation plus prcise
sera peut-tre faite par la suite si cela s'avre utile. Je n'ai pas tests ces produits, vos remarques et expriences
sont
donc
les
bienvenues
;-)
Wingate, winroute lite, NAT32, TCPrelay...
10.2 - Sous Unix
IPchains, ipfilter, netfilter...
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
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:
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.2 - Pr requis
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.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
11 - Conclusion
1 - Introduction
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
Vous tes libre d'utiliser de courts extraits de ce cours, dans la mesure o vous incluez un lien permettant d'avoir
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
1.5 - Votre travail
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...
2 - Une communication, comment a marche ?

2.1 - Que faut-il pour dialoguer ?
"Peux
tu
me
passer
le
sel
s'il
te
plait
?"
"Oui,
tiens,
le
voici"
Il apparat souvent trs simple de dialoguer, cependant, un dialogue ncessite une multitude de normes mettre
en
place
pour
que
chacun
puisse
s'exprimer
et
comprendre
l'autre.
"Peux
tu
me
passer
le
sel
s'il
te
plait
?"
"Excuse
me,
but
I
don't
understand
what
you're
talking
about"
"Pardon
?
je
te
demande
le
SEL
!
tu
me
comprends
pas
ou
quoi
?"
Et bien non, il ne comprend pas puisqu'ils n'utilisent pas le mme moyen pour communiquer.
On voit donc qu'il est ncessaire de se mettre d'accord sur des normes pour pouvoir dialoguer.
2.2 - Analogie de la parole
Nous avons vu prcdemment que deux personnes devaient utiliser la mme langue pour se comprendre, ou du
moins, que chacun d'eux comprenne la langue utilise par l'autre. Mais le dialogue par la parole ne se limite pas
cela. Le dialogue met en place deux interlocuteurs, chacun leur tour metteur puis rcepteur. Ils doivent donc
avoir chacun un moyen d'couter, et un moyen de parler. Il faudra par ailleurs un moyen de transmission de
l'information.
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).
4 - La couche physique (couche 1)

4.1 - Le rle de la couche 1
Nous ne nous attarderons pas longtemps sur la couche 1 car son rle est simple et ne demande pas de
connaissance
particulires
(du
moins,
si
l'on
n'entre
pas
dans
les
dtails
;-)
La couche 1 concerne le support physique de transport des donnes. Cela peut aller du simple cble transportant
un signal lectrique, la fibre optique, en passant par les ondes radio. Le rle de la couche 1 est donc d'offrir un
support de transmission permettant d'acheminer les donnes d'un point un autre.
5 - La couche liaison de donnes (couche 2)

La couche liaison de donnes a pour rle de transmettre les donnes de faon fiable entre des quipements
directement connects. D'autres rles lui incombent, mais leur connaissance ne nous sera pas utile pour
comprendre
le
transport
des
informations.
Nous allons donc voir dans ce chapitre comment deux machines directement lies vont faire pour dialoguer. Sur
un rseau, il y a souvent plusieurs machines connectes, il faut alors pouvoir les diffrencier les unes par rapport
aux autres. Pour cela, nous allons les identifier individuellement grce des adresses.
5.2 - L'adressage des machines
Pour
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
5.4 - Format d'une trame Ethernet

La description suivante ne prend en compte que les informations qui nous intressent et n'est pas le format
complet d'une trame Ethernet. La trame est compose d'une en-tte contenant les informations du protocole
Ethernet,
et
d'un
payload
contenant
les
informations
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.
6 - La couche rseau (couche 3)

La couche rseau a pour rle d'acheminer les informations d'un rseau un autre. C'est ce que l'on appelle le
routage. Les rseaux sont donc relis entre eux par des machines que l'on appelle routeurs. Ces routeurs vont
donc recevoir les paquets sur un rseau, et les renvoyer sur l'autre. Ils ont donc une connexion sur chaque
rseau. Tous les rseaux ne pouvant pas tre relis entre eux, il va souvent falloir passer par des rseaux
intermdiaires
pour
pouvoir
envoyer
un
paquet
d'un
rseau
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
O 192.168.0.0, 172.16.0.0 et 10.0.0.0 reprsentent les rseaux 1, 2 et 3. Et 172.16.0.254 reprsente l'adresse

de l'interface de gauche du routeur 2. Ainsi, pour atteindre la machine d'adresse 10.0.0.45 situe sur le rseau 3,
le routeur va voir dans la table de routage quelle entre correspond au rseau contenant cette adresse. Il s'agit
du rseau 10.0.0.0/255.0.0.0, et pour atteindre ce rseau, il est dit d'envoyer le paquet par l'interface ethernet 2,
vers
l'adresse
172.16.0.254.
Et
voil
!
Ce systme semble trs bien, mais on en voit vite les limites sachant que le rseau Internet est compos de
plusieurs millions de rseaux... Cela voudrait dire qu'il faut connatre la route vers chacun de ces rseaux pour
pouvoir dialoguer avec eux. Heureusement, une solution a t mise en place pour rpondre ce problme. Il
s'agit de la route par dfaut.
6.6 - Qu'est-ce qu'une route par dfaut ?
La route par dfaut est la route qui sera utilise lorsque aucune route spcifique pour aller vers la destination
spcifie n'aura t trouve. Ainsi, dans le cas prcdent, si je voulais atteindre l'adresse 193.253.25.46, aucune
entre de ma table de routage ne m'aurait indiqu comment y aller... Ce qui fait que ma machine n'aurait pas su
vers
qui
envoyer
le
paquet
et
qu'il
serait
all
directement
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.
6.11 - Cas particulier des liaisons point point

Il existe cependant des cas o l'utilisation d'une table de routage est un peu diffrente, et o la prcision d'une
passerelle n'est pas ncessaire. C'est quand deux machines sont relies directement l'une l'autre. On parle alors
de liaison point point. Dans ce cas, nous sommes srs qu'un paquet envoy par une des machines une
extrmit de la connexion va tre reu par l'autre machine. Il suffit alors dans la table de routage de spcifier
l'interface de sortie.
7 - Les interactions entre les couches 2 et 3

7.1 - Trame et datagramme, qu'est-ce qui circule sur le rseau ?
Et bien oui, nous avons vu que les couches 2 et 3 avaient chacune leur propre format de message utilis pour
transporter l'information, mais le quel des deux circule vraiment sur le rseau ? Si nous rpondons la trame, cela
voudra dire que notre trame sera contrainte de rester sur le rseau local, puisque la couche 2 ne permet pas
d'aller d'un rseau l'autre. Si nous rpondons le datagramme, de la mme faon, nous ne serons pas capables
de dialoguer avec les machines de notre rseau, et donc pas avec les routeurs utiliser pour aller vers d'autres
rseaux.
Donc
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 !
8 - Dialogue entre deux machines distantes

8.1 - Prsentation du dialogue
Nous allons reprendre le mme type de schma que nous avons vu prcdemment, avec une machine A
souhaitant
envoyer
un
message
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
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.
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.
Petit cours sur les masques de sous-rseau
1 - Introduction
1.3 - Dcharge
1.4 - Votre travail
2 - Dfinitions
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.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
12 - Conclusion
1 - Introduction
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.
Vous tes libre d'utiliser de courts extraits de ce cours, dans la mesure o vous incluez un lien permettant d'avoir
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
1.4 - Votre travail
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
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
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
3.2 - Nombre de machines

En y regardant d'un peu plus prs, on peut calculer le nombre de machines que l'on peut identifier l'aide de cet
adressage. Ainsi, on utilise 4 octets, soit 32 bits, soit encore 2^32 adresses (2 exposant 32 adresses) Or 2^32 =
4 294 967 296, on peut donc dfinir un peu plus de 4 milliards d'adresses !!!
3.3 - La sparation grce au masque
Cependant, nous avons vu qu'il fallait sparer cette adresse en deux parties pour pouvoir identifier la fois le
rseau et l'adresse. Mais comment se fait cette sparation ? En fait, le masque comme l'adresse IP est une suite
de 4 octets, soit 32 bits. Chacun des ces bits peut prendre la valeur 1 ou 0. Et bien il nous suffit de dire que les
bits 1 reprsenteront la partie rseau de l'adresse, et les bits 0 la partie machine. Ainsi, on fera une
association entre une adresse IP et un masque pour savoir dans cette adresse IP quelle est la partie rseau et
quelle est la partie machine de l'adresse.
3.4 - Le couple adresse IP et masque
Le masque servant faire la sparation en deux parties sur une adresse IP, il est donc indissociable de celle-ci.
Une adresse seule ne voudra rien dire puisqu'on ne saura pas quelle est la partie rseau et quelle est la partie
machine. De la mme faon, un masque seul n'aura pas de valeur puisqu'on n'aura pas d'adresse sur laquelle
l'appliquer. L'adresse IP et le masque sont donc lis l'un a l'autre, mme si l'on peut choisir l'un indpendamment
de l'autre.
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
4.2 - Pourquoi un codage binaire pour les ordinateurs ?

Pour les ordinateurs, c'est ce choix du codage binaire qui a t fait. Pourtant, il aurait t plus simple d'utiliser la
base 10 avec laquelle nous sommes familiers. Cependant, les informations lies aux ordinateurs circulent sur des
fils lectriques. Sur ces fils, il est difficile de distinguer plus de deux tats pour le signal, on peut par exemple
choisir un tat 0 volt, et un autre pour 5 volts. On se retrouve donc avec deux valeurs possibles. C'est pour cela
qu'on a choisi un codage binaire avec deux valeurs possibles, 0 et 1.
4.3 - Qu'est-ce qu'un octet ?
Un octet est une squence de huit bits. C'est donc un nombre cod avec huit bits. Ainsi, si on transpose sa valeur
en dcimal, on obtient un nombre qui peut varier entre 0 et 255. Donc, dans une adresse IP, on ne pourra pas
trouver d'autres nombres que ceux compris entre 0 et 255. Une adresse comme 192.65.25.428 ne peut pas tre
une adresse IP valide vu que son dernier octet n'est pas compris entre 0 et 255.
4.4 - Ecriture binaire de l'adresse IP
Nous avons vu que l'adresse IP tait compose de 4 octets crits en notation dcimale, spars par des points,
par
exemple:
192.168.25.132
Cette
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.
6 - Comment bien choisir son masque ?

6.1 - Partir de l'existant
La plupart du temps, le choix de l'adressage se fait en fonction des besoins exprims, et des limites de ce que l'on
a le droit de faire. Une certaine plage vous est alloue par votre fournisseur d'accs. Vous pourrez alors dcouper
cette plage en diffrents rseaux, mais ne surtout pas dpasser celle-ci. Ainsi, si vous possdez une plage de 128
adresses et que vous voulez adresser 500 machines, vous aurez quelques petits problmes...
6.2 - En fonction du nombre de machines
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 travaille en binaire, le nombre de
machines possible au sein d'un rseau sera une puissance de 2. Pour un nombre donn de machines, il faudra
donc choisir la puissance de 2 immdiatement 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
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
7 - Comment dcouper une plage d'adresses en plusieurs sous-rseaux ?

7.1 - Dtermination des masques pour chacun des rseaux
Il est souvent ncessaire de dcouper une plage d'adresses en plusieurs sous-rseaux. Pour cela, il vaut souvent
mieux envisager le dcoupage des rseaux dans son ensemble plutt que de les faire chacun sparment et de se
rendre
compte
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.
8 - Que sont les classes d'adresses A, B, C, D... ?

8.1 - Historique
Comme nous l'avons vu dans le paragraphe 2, le masque de sous-rseau permet de segmenter l'ensemble des
adresses de l'Internet en diffrents rseaux. Mais cette segmentation ne s'est pas faite n'importe comment !
On a dcoup la plage d'adresses disponible en cinq parties distinctes. Les classes A, B, C, D et E, que l'on appelle
aussi adresses globales.
8.2 - Dfinition
Classe A: Premier bit de l'adresse 0, et masque de sous-rseau en 255.0.0.0. Ce qui donne la plage d'adresse
0.0.0.0
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...
8.3 - Y a-t-il une pnurie d'adresses IPv4 ?

La
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.
9 - Trucs et astuces avec les masques

9.1 - Comment dterminer qu'une machine appartient mon rseau ?
C'est trs simple. pour cela, il va falloir dterminer si l'adresse de la machine appartient la plage d'adresses
dfinie par mon adresse et mon masque. Pour cela, je fais un ET logique entre mon adresse et mon masque
rseau, j'en dduis donc l'adresse de mon rseau (pour une explication du ET logique, regarder le paragraphe
10.4)
Je fais pareil avec l'adresse de l'autre machine et MON masque rseau, et j'obtiens une adresse de rseau. Si les
deux adresses de rseau sont les mmes, a veut dire que la machine appartient bien au mme rseau.
Disons par exemple que ma machine ait pour adresse 192.168.0.140/255.255.255.128 et je veux savoir si les
machines A et B ayant pour adresses 192.168.0.20(A) et 192.168.0.185(B) sont sur le mme rseau ? Je fais
192.168.0.140
ET 255.255.255.128
------------------=
de
ET
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
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.
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
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$.
2 - Prsentation de Bluetooth du point de vue technique

Reprsentation
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
:
2.1.1 - Liaison connexion synchrone oriente (SCO)

Ce type de liaison est utilis pour la transmission de voix, puisqu'il y a besoin de "temps rel" pour ce type
d'application. Bluetooth utilise dans ce cas des crneaux rservs afin de rduire au maximum le dlai. Si l'on
est en fonctionnement mode "Point To Point", la transmission sera Bidirectionnelle. Ce type de connexion
fonctionnant en mode "Temps rel" il n'y a pas de retransmission possible. Il est possible d'atteindre 64Kb/s
afin de respecter la norme de codage, sachant qu'un matre peut grer jusqu' 3 liens de ce type.
2.1.2 - Liaison connexion asynchrone (ACL)
Ce type de connexion a t conu pour changer des donnes. Avec ce type de connexion il est possible
d'effectuer un broadcast. Les dbits de ce type de connexion sont de 723.2 Kbps en sortie avec un entrant
57.6 Kb/s. En mode symtrique on peut aller jusqu' 433.9Kb/s.
2.2 - L2CAP
Le couche L2CAP a pour rle de transformer les donnes en paquets pour la couche Baseband. Son rle est
galement la gestion des connexions logiques entre plusieurs lments Bluetooth. Encapsulation partir de L2CAP
:
2.3 - SDP (Service discovery Protocol)

SDP est la couche charge de la dcouverte d'lments Bluetooth. Son rle est la dtection et l'intgration de
nouveaux lments Bluetooth dans le rseau.
2.3.1 - Mode de dtection
Schma
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
2.3.3 - Contrle des erreurs

Au niveau du contrle d'erreurs il en existe de deux types sur bluetooth.
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 :
4.2 - Utilisation de BNEP

BNEP simplifie les choses, car il n'y a plus PPP. BNEP ne fournit pas une mulation RS-232. On arrive donc un
schma
avec
BNEP
:
4.3 - Poste mobile esclave

Dans le cas o les mobiles sont esclaves, on est donc limit 7 mobiles par station de base. Station de base
matre
:
4.4 - Poste mobile matre
Dans ce cas prcis, la station de base est esclave d'autant de Mobile. Station de base esclave :
4.5 - Adaptation de la couche IP pour priphriques mobiles

La couche IP a trois tats possibles :
Discovery : Le priphrique est dans cet tat au dmarrage. C'est dans cette tape qu'il va chercher les
stations de base les plus proches dont il a gnralement aucune information. Il y a une procdure
permettant d'obtenir uniquement les stations de base. Cette procdure va tre rpte tant qu'une station
de base n'a pas t trouve. Une procdure de connexion est dclenche pour passer dans l'tat
Configuration.
Configuration : La station de base va donner un tat de matre ou esclave au mobile. Le mobile va ensuite
tablir une connexion bidirectionnelle L2CAP sur la connexion existante. C'est cette tape que la MTU des
datagrammes de la couche L2CAP est ngocie. La station de base va envoyer un datagramme contenant
la MTU maximum qu'il peut accepter. Le mobile va ensuite confirmer la valeur en la renvoyant. A ce
moment l si il n'y a pas eu d'erreur, on passe en phase Connected.
Connected : Une fois arriv dans cette tape pour la premire fois, il faut affecter une IP au mobile. Pour
cela DHCP peut tre utilis, ou alors, si Mobile IP est activ il n'y aura pas de configuration modifier sur le
Mobile.
Etats
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.2 - Vrification
9.4 - Linux
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
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.
6 - Les requtes et les messages DHCP

On pourrait croire qu'un seul aller-retour peut suffire la bonne marche du protocole. En fait, il existe plusieurs
messages DHCP qui permettent de complter une configuration, la renouveler... Ces messages sont susceptibles d'tre
mis
soit
par
le
client
pour
le
ou
les
serveurs,
soit
par
le
serveur
vers
un
client :
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) :
7 - Les messages DHCP

7.1 - Dialogue avec le serveur
Les messages DHCP sont transmises via UDP. Bien que peu fiable, ce protocole suffit au transport des paquets
simples sur rseau local, et surtout il est trs lger, donc intressant pour les petits systmes (du genre le micro
bout de programme qui fait la requte DHCP lorsque le PC se met en route). De facto, DHCP fonctionne aussi en
mode non connect. Le client n'utilise que le port 68 pour envoyer et recevoir ses messages de la mme faon, le
serveur envoie et reoit ses messages sur un seul port, le port 67.
7.2 - Format de la trame BOOTP/DHCP
La trame DHCP est en fait la mme que BOOTP, et a le format suivant (les chiffres entre parenthses indique la
taille
du
champ
en
octets) :
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 :
-
subnet-mask (option 1) qui indique le masque de sous-rseau pour la configuration IP,

routers
(option
3)
qui
indique
les
routeurs
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
were
called.
in
"$1"
-n
/usr/sbin/dhcpd
-lf
Start
"Starting
-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.
9 - Configuration des clients

Vous devez aller dans la configuration TCP/IP, enlever tout ce qu'il y a concernant l'IP, le masque de sous rseau, DNS,
passerelle et juste dire que vous voulez une configuration dynamique (DHCP). Relancez vos services rseaux, la
mthode la plus simple et la plus bestiale tant le "reboot", et voil. Une fois le systme remont, vous devez avoir
hrit d'une configuration automatique.
9.1 - Tout pour contrler, rparer etc
Dans
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
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
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
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.
10.2.1 - Le DHCP Discover
10.2.2 - Un petit ping...
Pas de rponse au ping, on peut continuer tranquille...
10.2.3 - Offre d'un nouveau bail
Le serveur DHCP vient de proposer une configuration au client.

10.2.4 - Demande du Bail de la part du client
Il faut aussi, maintenant que le client fasse une demande explicite pour ce bail. N'oublions pas qu'il pourrait y
avoir plusieurs DHCP qui rpondent, il faut donc qu'il y ait une confirmation au serveur choisi par le client.
C'est presque fini, il ne reste plus au serveur qu' confirmer l'attribution de ce bail.
10.2.5 - Le serveur est d'accord
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
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
Nom du serveur de noms pour ce domaine
MD
03
Messagerie (obselete par l'entre MX)
MF
04
Messagerie (obselete par l'entre MX)
CNAME 05
Nom canonique (Nom pointant sur un autre nom)
SOA
06
Dbut d'une zone d'autorit (informations gnrales sur la zone)
MB
07
Une boite lette du nom de domaine (exprimentale)
MG
08
Membre d'un groupe de mail (exprimentale)
MR
09
Alias pour un site (exprimentale)
NULL
10
Enregistrement 0 (exprimentale)
WKS
11
Services Internet connus sur la machine
PTR
12
Pointeur vers un autre espace du domaine (rsolution inverse)
HINFO
13
Description de la machine
MINFO
14
Groupe de boite lettres
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
Class Csnet (obselete)
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
.gb - Grande Bretagne

.gd - Grenade
.ge - Gorgie
.gf - Guyane Franaise
.gg - Guernesey
.gh - Ghana
.gi - Gibraltar
.gl - Groenland
.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
4.1.2 - Les domaines gnriques

Cette
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
L'arborescence des noms de domaine est constitue :

d'une racine
de noeud identifis par des labels dont les informations sont stockes dans une base de donnes
Les labels ports par les noeuds font entre 0 et 63 octets, sachant que l'identifiant de longueur zro est rserv
la racine. Deux noeuds " frre " ne peuvent pas porter le mme identifiant, nanmoins, deux noeuds peuvent
avoir le mme label dans le cas o il n'on aucun lien de " fratrie ". Le nom de domaine d'un noeud est constitu
des identifiants situs entre ce noeud la racine de l'arborescence. Lorsqu'un utilisateur doit entrer un nom de
domaine, la longueur de chaque identifiant est omise et les identifiants devront tre spars par des points (".").
Un nom de domaine complet atteignant toujours la racine, la forme crite exacte de tout domaine entirement
qualifi se termine par un point. Nous utiliserons cette proprit pour distinguer les cas :
d'une chane de caractres reprsentant un nom de domaine complet (souvent appel "absolu" ou
"entirement qualifi"). Par exemple, "www.FRAMEIP.COM"
d'une chane de caractres reprsentant les premiers identifiants d'un nom de domaine incomplet, et
devant tre complt par l'application locale avec un complment absolu (expression appele "relative").
Par exemple, "www", utiliser relativement au domaine FRAMEIP.COM.
4.2 - Formation des zones
La base de donnes est divise en sections appeles zones, lesquelles sont distribues sur l'ensemble des
serveurs de noms. De plus, elle est divise selon deux mthodes : en classes et par "dcoupage" de l'espace des
noms
de
domaines.
La partition en classes est assez simple. La base de donnes est organise, dlgue, et maintenue sparment
pour chacune des classes. Comme par convention, l'espace de noms est identique quel que soit la classe, la
sparation par classe peut conduire voir l'espace de domaines comme un tableau d'arbres de noms parallles.
Notez que les donnes attaches aux noeuds des arbres seront diffrentes dans chaque arbre.
4.3 - Principes des zones

Dans une classe, des "coupes" dans l'espace de noms peuvent tre faites entre deux noeuds adjacents
quelconques. Un fois toutes les coupes dfinies, chaque groupe de noeuds interconnects devient une zone
indpendante. La zone est alors dfinie comme tant la "sphre d'autorisation" pour tout nom l'intrieur de la
zone. Notez que les "coupes" dans l'espace de noms peuvent tre des endroits diffrents de l'arbre suivant la
classe,
les
serveurs
de
noms
associs
peuvent
tre
diffrents,
etc.
Ces rgles signifient que chaque zone doit avoir au moins un noeud, et donc un nom de domaine, pour lequel il
est "autoris", et que tous les noeuds d'une zone particulire sont connects. Du fait de la structure d'arbre,
chaque zone contient un noeud "de plus haut niveau" qui est plus proche de la racine que tous les autres noeuds
de cette zone. Le nom de ce noeud est souvent utilis pour identifier la zone elle-mme.
Selon ce concept, il est possible, bien que pas forcment utile, de dcouper l'espace de noms de telle faon que
chaque nom de domaine se retrouve dans une zone spare ou au contraire que tous les noeuds se retrouvent
dans une zone unique.
4.4 - Description techniques pour les zones
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
QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer
vide
Authotity
vide
Additionnal
vide
La rponse obtenue est :

Header
OPCODE=SQUERY, RESPONSE, AA
Question
QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer
ISI.EDU MX 10 VENERA.ISI.EDU MX 10 VAXA.ISI.EDU
Authotity
vide
Additionnal
VENERA.ISI.EDU A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU A 10.2.0.27 A 128.9.0.33
5.2.2 - Le mode Itratif

Ce mode est le plus simple du point de vue du serveur. Les serveur rpondent directement la requte sur la
base seule de ses informations locales. La rponse peut contenir la rponse demande, ou bien donne la
rfrence d'un autre serveur qui sera "plus susceptible " de disposer de l'information demande. Il est
important que tous les serveurs de noms puissent implmenter ce mode itratif et dsactive la fonction de
rcursivit.
Les avantages d'une rsolution itrative :

Dans le cas d'une implmentation simplifie d'un rsolveur qui ne sait exploiter d'autres rponses
qu'une rponse directe la question.
Dans le cas d'une requte qui doit passer travers d'autres protocoles ou autres "frontires" et doit
pouvoir tre envoye un serveur jouant le rle d'intermdiaire.
Dans le cas d'un rseau dans lequel intervient une politique de cache commun plutt qu'un cache
individuel par client.
Le service non-rcursif est appropri si le rsolveur est capable de faon autonome de poursuivre sa
recherche et est capable d'exploiter l'information supplmentaire qui lui est envoye pour l'aider rsoudre
son problme.
5.2.3 - Le mode Rcursif
Le mode rcursif une fois est plus simple du point de vue du client. Dans ce mode, le premier serveur prend
le
rle
de
rsolveur.
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
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.
2 - Ncessit d'avoir un temps prcis et fiable
Bases de donnes distribues : transactions, journalisation, logs

Estampilles de documents scuriss : certification et cryptographie
Aviation : contrle de trafic et enregistrement de positions
Programmation tlvision et radio

Multimdia : synchronisation pour les tlconfrences en temps rel
Gestion des rseaux
...
3 - Bref historique
Le temps lgal dfini par la seconde lgale a t bas :
Sur le temps universel (TU) jusqu'en 1956.

Sur le temps des phmrides (TE) de 1956 1967.
Sur le temps atomique jet de csium partir de 1967.
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
donner la meilleure prcision possible compte tenu des conditions matrielles
rsister une multitude de pannes (y compris les bugs d'implmentation)

optimiser l'utilisation de la diversit et de la redondance prsentes sur Internet
organiser de manire automatique la topologie d'un sous-rseau afin d'avoir une prcision et une fiabilit
optimales
raliser l'authentification cryptographique base sur des infrastructures de clefs symtriques et de clefs
publiques
Ce quoi ne sert pas NTP
temps local : le noyau le fait

contrle d'accs : firewall
non-rpudiation : utiliser un protocole spcifique si besoin
5 - Architecture systme et rseau, NTP v3

NTP est un protocole bas sur les protocoles UDP et IP. C'est donc un protocole Internet bas sur l'adressage IP, en
mode non connect avec User Datagram Protocol sur le port 123.
La synchronisation de l'heure est diffuse depuis des serveurs primaires dans une arborescence en rseau. Prs de 200
000 clients et serveurs utilisent NTP sur internet.
NTP a t port sur la plupart des plateformes dont Windows, Linux, Unix,... La version 3 de NTP, dont nous parlons
ici, est utilise depuis 1992.
5.1 - Rfrences de temps
Elles sont toutes drives plus ou moins directement d'horloges atomiques. On peut citer :
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 :
de l'ordre d'une dizaine de millisecondes sur les rseaux WAN

infrieure la milliseconde sur les rseaux LAN
infrieure la microseconde lorsqu'on utilise une rfrence de temps de type GPS (sur les LAN)
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 :
5.4 - Fonctionnement d'un serveur NTP : cinq modes diffrents

Sauf dans le mode broadcast, une association est cre quand deux machines changent des messages. Une
association peut fonctionner dans un des cinq modes suivants :
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
- Les serveurs inondent priodiquement le rseau local par un message multicast.

- Les clients utilisent le mode client/serveur lors du premier contact pour mesurer le temps de
propagation
puis
restent
en
coute.
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 premires tapes franchir servent assurer la scurit du protocole :
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.
Le choix de l'action entreprendre dpend en fait de l'importance du dcalage constat :
Pour un dcalage minuscule, la frquence d'horloge est modifie.

Si ensuite on constate des dcalages plus grands (de l'ordre de la seconde), le processus ne tient pas
compte de la rponse des serveurs et prfrera faire des calculs statistiques sur les anciens dcalages
afin de dterminer la marche suivre.
Au bout d'un moment, si des dcalages encore importants sont constats, ils seront pris en compte :
pour les plus petits d'entre eux, la frquence d'horloge sera modifie tandis que pour les plus grands
(sans toutefois tre normes), l'horloge est rinitialise brutalement.
Dans le cas d'un dcalage vraiment trs important, la rponse des serveurs est rejete et le processus
NTP s'arrte car il pense que ses systmes de rfrence sont entrs dans un tat non fiable.
7 - Exemple de trame NTP
Fichier de capture NTP effectu par Ethereal V0.10.12
8 - Les serveurs NTP d'Internet

Il existe beaucoup de serveur NTP publique disponible sur Internet, cependant, il y a un regroupement de serveur que
vous pouvez retrouver l'adresse suivante : http://ntp.vuntz.net/
Le principe est de se synchroniser vis vis d'un serveur de temps de rfrence. Pour rsoudre la problmatique de
charge sur ce serveur de temps, un groupement de serveur lieu et la redistribution se fait l'aide du Round Robin
DNS. Vous pouvez requter plusieurs noms d'htes diffrent :
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
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.
2 - SNMP (Simple Network Management Protocol)

2.1- Prsentation gnrale
SNMP (Simple Network Management Protocol) est le protocole de gestion de rseaux propos par l'IETF. Il est
actuellement
le
protocole
le
plus
utilis
pour
la
gestion
des
quipements
de
rseaux.
SNMP est un protocole relativement simple. Pourtant l'ensemble de ses fonctionnalits est suffisamment puissant
pour permettre la gestion des rseaux htrognes complexes. Il est aussi utilis pour la gestion distance des
applications: les bases de donnes, les serveurs, les logiciels, etc.
L'environnement de gestion SNMP est constitu de plusieurs composantes : la station de supervision, les lments
actifs du rseau, les variables MIB et un protocole. Les diffrentes composantes du protocole SNMP sont les
suivantes:
Les lments actifs du rseau sont les quipements ou les logiciels que l'on cherche grer. Cela va d'une station
de travail un concentrateur, un routeur, un pont, etc. Chaque lment du rseau dispose d'une entit dite agent
qui rpond aux requtes de la station de supervision. Les agents sont des modules qui rsident dans les lments
rseau. Ils vont chercher l'information de gestion comme par exemple le nombre de paquets en reus ou
transmis.
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
GetRequest permet la recherche d'une variable sur un agent.

GetNextRequest permet la recherche de la variable suivante.
GetBulk permet la recherche d'un ensemble de variables regroupes.
SetRequest permet de changer la valeur d'une variable sur un agent.
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.
Voici un exemple de structure de table MIB :
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
3 - Prsentation, volution des versions de SNMP
Voici les diffrentes versions de SNMP:
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 (Packet Data Unit).
Le PDU type dcrit le type de requte, de rponse ou d'alerte. Le Tableau 2 donne les valeurs associes ces
champs.
Le Request ID permet la station de gestion d'associer les rponses ses requtes.

Le Error Status est l'indicateur du type d'erreur. Si aucune erreur ne s'est produite, ce champ est mis zro. Les
rponses ngatives possibles sont dcrites dans le tableau suivant :
4.1- Les faiblesses de SNMPv1
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 :
USM (User-based Security Model)

VACM (View- based Access Control Model)
5.1 - User Security Module (USM)

Trois mcanismes sont utiliss. Chacun de ces mcanismes a pour but d'empcher un type d'attaque.
L'authentification : Empche quelqu'un de changer le paquet SNMPv3 en cours de route et de

valider le mot de passe de la personne qui transmet la requte.
Le cryptage : Empche quiconque de lire les informations de gestions contenues dans un paquet
SNMPv3.
L'estampillage du temps : Empche la rutilisation d'un paquet SNMPv3 valide a dj transmis
par quelqu'un.
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 :
Les tapes d'authentification sont les suivantes :
Le transmetteur groupe des informations transmettre avec le mot de passe.

On passe ensuite ce groupe dans la fonction de hachage une direction.
Les donnes et le code de hachage sont ensuite transmis sur le rseau.
Le receveur prend le bloc des donnes, et y ajoute le mot de passe.
On passe ce groupe dans la fonction de hachage une direction.
Si le code de hachage est identique celui transmis, le transmetteur est authentifi.
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.
6 - Exemple de trame SNMP
Tlchargez le l'exemple de trame SNMP
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
Tlphonie sur IP - TOIP
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
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...)
2 - Gnralits sur la transmission

Tout d'abord, il s'agit de parler de commutation par paquets ( au lieu de commutation par circuit : PBX, ce qui est le
cas d'un rseau tlphonique traditionnel). Le transport des signaux voix numriss par paquets impose des
contraintes majeures :
1) Optimisation de la bande passante (attention aux autres applications informatiques qui monopolise la
majeure partie de la bande passante disponible comme Microsoft Exchange). Pour un bon partage de la bande
passante, il faut connatre l'ensemble des flux pouvant avoir une influence importante sur le transport de la
voix.
2) Dlai de transmission (trs important dans des cahiers des charges : temps de transfert des paquets), il
comprend le codage, le passage en file d'attente d'mission, la propagation dans le rseau, la buffrisation en
rception et le dcodage. Le dlai de transmission optimal est de 150 ms (UIT-T G114). Les dlais parfois
tolrables sont entre 150 et 400 ms.
3) Le phnomne d'cho (rverbration du signal). C'est le dlai entre l'mission du signal et la rception de ce
mme signal en rverbration. Cette rverbration est cause par les composants lectroniques des parties
analogiques. Un cho < 50 ms n'est pas perceptible. Plus il est dcal dans le temps plus il est insupportable.
4) La gigue ou Jitter (variation de l'cart initial entre deux paquets mis). Correspond des carts de dlais de
transmission entre des paquets conscutifs. Ncessite la mise en place de buffers en rception qui lissent ces
carts pour retrouver le rythme de l'mission. Effet nefaste des buffers de rception ==> augmentation du dlai
de transmission.
5) La gestion de la qualit de service des rseaux Ip de transport d'un bout l'autre. Elle peut-tre une solution
propritaire (Qos constructeur), DiffServ, RSVP ou MPLS. Rappelons enfin que le mode de fonctionnement de
l'acheminement sur l'Internet est du type Best Effort : chaque quipement constituant le rseau (en particulier
les routeurs) fait de son mieux pour acheminer les informations.
En conclusion, le transport de la tlphonie sur l'Ip ne doit souffrir d'aucun retard de transmission, ni d'altrations
(attention aux firewall), ni de perte de paquets.
3 - Synoptique d'une architecture raccord avec un PABX traditionnel
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).
4 - Les diffrents codecs et taux de compression

Les codecs sont des chipsets qui font office de codeurs/dcodeurs. Certains terminaux IP-PHONES n'acceptent qu'une
partie ou mme un seul codec, tout dpend du modle de terminal et du constructeur. Le principe de fonctionnement
de ces codecs vous ont t expliqus sur la page prcdente. Les principaux taux de compression de la voix sont les
codecs officiels suivants :
Mthode de compression
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
5 - Les diffrents protocoles utiliss
Les diffrents protocoles non propritaires sont les trois suivants :

5.1 - H323
Le protocole H323 est le plus connu et se base sur les travaux de la srie H.320 sur la visioconfrence sur RNIS.
C'est une norme stabilise avec de trs nombreux produits sur le march (terminaux, gatekeeper, gateway,
logiciels). Il existe actuellement 5 versions du protocole (V1 V5). Vous trouverez plus de renseignement
sur H323 ici.
5.2 - SIP
Le protocole SIP est natif du monde Internet (HTTP) et est un concurrent direct de l'H323. A l'heure actuelle, il est
moins riche que H.323 au niveau des services offerts, mais il suscite actuellement un trs grand intrt dans la
communaut Internet et tlcom. Vous trouverez plus de renseignement sur SIP ici.
5.3 - MGCP
Le protocole MGCP est complmentaire H.323 ou SIP, et traite des problmes d'interconnexion avec le monde
tlphonique (SS7, RI).
6 - L'alimentation des postes IP

He oui, un poste Ip (ou ip-phone) a besoin d'une alimentation externe DC de 48Volts ou d'une tl alimentation par le
port ethernet. Il y a deux solutions pour se passer d'un petit transformateur 220V~/48VDC pouvant tre facilement
oubli et dbranch avec une fausse manip.. Ces deux solutions ont t normaliss par un document officiel de IEEE
Computer Society (norme : 802.3af) et elles sont dcrites ci-dessous:
Dans le premier cas gauche ici,

les tlphones Ip sont
directement connects aux
switchs d'tages qui intgrent
l'alimentation 48 V ncessaire
sur les paires LIBRES ! C'est
donc un switch dernire
gnration compatible 802.3af
Dans notre 2 cas gauche, le

switch n'tant pas quips, il a
fallu installer un PATCH POWER
PANEL pour pouvoir alimenter
quand mme les tlphones IP.
Les cordons rseaux sortent du
switch, vont au power panel puis
ressortent sur un autre port vers
le PC de l'tage.
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.
7 - La migration d'une installation

Cette migration d'un rseau existant doit respecter absolument certaines rgles, les voici :
1 - Mettre niveau le rseau tendu
2 - Dimensionner le rseau local (s'assurer d'une trs bonne bande passante et surtout de son utilisation)
3 - Rcuprer l'existant en tlphonie classique (comme les fax par exemple ou les liens oprateurs analogiques
ou numriques)
4 - Confrer une certaine autonomie aux sites distants
5 - Intgrer la tlphonie sans fil (soit DECT, soit WIFI)

6 - Autoalimenter les postes tlphoniques (norme 802.3af)
7 - Assurer la scurit
8 - Calculer le retour sur investissement (ROI)
8 - Les 8 arguments plaidant pour

1
conomiser
sur
la
facture
2
Prenniser
3
Simplifier
les
4
Faciliter
l'administration
et
la
5
Homogniser
les
services
tlphoniques
sur
un
ensemble
6
Faciliter
l'intgration
avec
le
systme
7
voluer
plus
8 - Regrouper les quipes et se passer d'un prestataire
tlcom
l'investissement
infrastructures
mobilit
de
sites
d'information
facilement
9 - Les 6 faiblesses qui rebutent les entreprises

1)
2)
Une
3)
4)
5)
6) Support administratif
qualit
de
Fiabilit
mdiocre
l'utilisation
Localisation
Standards
son
Amliorer
10 - Les failles du protocole H.323

He oui, mme ce protocole n'est pas l'abri de failles de scurit. Ces trous de scurit pourraient tre exploites pour
excuter
des
commandes
arbitraires
ou
provoquer
un
deni
de
service
sur
le
systme
vulnrable. La criticit de ces problmes sur les diffrents quipements/logiciels semble varier d'un produit a l'autre.
Les systmes touchs sont les tlphones Ip et les visioconfrences IP.
11 - Les diffrents lments pouvant composer un rseau

- Le PABX-IP, c'est lui qui assure la commutation des appels et leurs autorisations, il peut servir aussi de routeur ou de
switch dans certains modles, ainsi que de serveur DHCP. Il peut possder des interfaces de type analogiques (fax),
numriques (postes), numriques (RNIS,QSIG) ou oprateurs (RTC-PSTN ou EURO-RNIS). Il peut se grer par Ip en
intranet ou par un logiciel serveur spcialis que ce soit en interne ou depuis l'extrieur. Il peut s'interconnecter avec
d'autres PABX-IP ou PABX non Ip de la mme marque (rseau homogne) ou d'autres PABX d'autres marques (rseau
htrogne).
- Le serveur de communications (exemple : Call Manager de Cisco), il gre les autorisations d'appels entre les
terminaux Ip ou softphones et les diffrentes signalisations du rseau. Il peut possder des interfaces rseaux
oprateurs (RTC-PSTN ou RNIS), sinon les appels externes passeront par la passerelle ddie cela (gateway).
- La passerelle (gateway), c'est un lment de routage quip de cartes d'interfaces analogiques et/ou numriques
pour s'interconnecter avec soit d'autres PABX (en QSIG,RNIS ou E&M), soit des oprateurs de tlcommunications
local, national ou international. Plusieurs passerelles peuvent faire partie d'un seul et mme rseau, ou l'on peut
galement avoir une passerelle par rseau local (LAN). La passerelle peut galement assurer l'interface de postes
analogiques classiques qui pourront utiliser toutes les ressources du rseau tlphonique Ip (appels internes et
externes,
entrants
et
sortants).
-
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.
12 - La rglementation dans certains pays

Le 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.
Notes : selon que la transmission des signaux s'effectue ou non "en temps rel", la rglementation affrente la
tlphonie classique peut s'appliquer divers degrs. On ne dispose pas pour tous les pays d'informations
rglementaires permettant de dterminer si le service est assur ou non en temps rel.
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
Hong-Kong (RAS de)

Japon
Rpublique Tchque (7)
Singapour
Suisse
Pas d'interdiction spcifique pour la tlphonie/tlcopie sur l'Internet public.

Notes :
(1) Antigua-et-Barbuda et Sainte Lucie : l'utilisation de l'Internet public n'est pas interdite
pour la tlphonie et la tlcopie, mais on ne dispose d'aucune donne sur l'utilisation des
rseaux Ip pour ces services.
(2) En Estonie, les communications tlphoniques nationales et internationales
achemines par des rseaux Ip taient interdites jusqu'au 31 dcembre 2000. La
tlphonie Ip publique tait galement interdite jusqu' la mme date.
En Mongolie, les communications tlphoniques internationales taient interdites jusqu'
cette mme date.
(3) Les Etats-Unis autorisent la tlphonie Ip sans aucune condition, c'est dire qu'elle
n'est pas assujettie au rgime des rglements internationaux.
(4) Saint-Vincent : l'utilisation de rseaux Ip n'est pas interdite, mais on ne dispose
d'aucune donne concernant l'utilisation de l'Internet public pour la tlphonie et la
tlcopie.
Autorise ou non rglemente si la transmission n'est pas en temps rel

( n'est pas assimile de la tlphonie vocale ).
(5) L'Union Europenne regroupe les 15 pays suivants : Allemagne, Autriche, Belgique,
Danemark, Espagne, Finlande, France, Grce, Irlande, Italie, Luxembourg, Pays-bas,
Portugal, Royaume Uni et Sude.
(6) Hongrie : lorsque le temps mort de transmission est =/> 250 ms et la perte de
paquets >1%.
Autorise. Dans le cas d'une transmission en temps rel, assortie de conditions peu
contraignantes
( obligation de notification ou d'enregistrement, autres dispositions de base de la
rglementation de la tlphonie vocale classique ).
(7) Exception : de tlphone tlphone dans le cas autre que l'oprateur tabli.
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
Utilisation de Internet public
Utilisation des rseaux IP
Argentine
Interdite
Non interdite
Chypre
Interdite
Non interdite
Ethiopie
Interdite
Non interdite
Kenya
Interdite ( services tlphoniques, rappel et

reroutage compris )
Non interdite
Kirghizistan Non interdite
Interdite ( jusqu'en 2003

pour la tlphonie Ip )
Moldova
Non interdite
Interdite ( jusqu'en 2003

pour la tlphonie Ip )
Prou
Interdite ( les services tlphoniques sont

interdits puisqu'ils sont assimils des services
de tlphonie vocale )
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
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
Services tlphoniques sur rseaux Ip interdits jusqu'en 2003
Azerbadjan
Belize
Tous les services sont interdits
Botswana
Tlphonie interdite sur l'Internet public
Cambodge
Tlphonie interdite indfiniment
Cameroun
Cte d'Ivoire
Tlphonie interdite sur l'Internet public jusqu'en 2004
Croatie
Cuba
Tlphonie interdite sur l'Internet public et les rseaux Ip la diffrence de la

tlcopie
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
Tlphonie interdite ( la fois sur l'Internet public et sur les rseaux Ip )
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
Tlphonie interdite sur l'Internet public. Rglementation en cours d'laboration pour

autoriser la tlphonie sur les rseaux IP.
Isral
Tlphonie interdite sur l'Internet public. Tlphonie et tlcopie interdites sur les
rseaux IP
Jordanie
Tlphonie interdite sur l'Internet public. Services tlphoniques et de tlcopie

interdits sur les rseaux Ip jusqu'a la fin de l'anne 2004
Lettonie
Lituanie
Tlphonie interdite sur l'Internet public et sur les rseaux Ip jusqu'au 31 dcembre
2002
Maroc
Mozambique
Tlphonie et tlcopie interdites sur l'Internet public et sur les rseaux IP
Myanmar
Nicaragua
Services tlphoniques interdits sur l'Internet public et sur les rseaux IP
Nigria
Tlphonie et tlcopie interdites l'heure actuelle sur les rseaux IP
Pakistan
Services de terminaison tlphoniques interdits sur l'Internet public. Tlphonie

interdite sur les rseaux IP
Paraguay
Tlphonie interdite sur l'Internet public et les rseaux IP
Qatar
Tlphonie et tlcopie interdites sur l'Internet public et sur les rseaux IP, mais la
situation sera rexamine

Roumanie
Tlphonie interdite sur l'Internet public. Services tlphoniques interdits au moins

jusqu'au 1er janvier 2003
Sngal
Seychelles
Tlphonie et tlcopie interdites sur l'Internet public; nanmoins, la tlphonie

Internet, qui est considre comme une application Internet plutt que comme service
de tlcommunication assur par un fournisseur de services Internet, est autorise.
Tous les services sur les rseaux Ip sont interdits
Swaziland
Thalande
Tlphonie et tlcopie interdites sur l'Internet public et sur les rseaux IP
Togo
Trinit-et-Tobago
Tlphonie interdite sur les rseaux Ip
Tunisie
Turquie
Tlphonie interdite sur l'Internet public et les rseaux IP
Ce prsent tableau est fond sur les rsultats de l'enqute de l'UIT sur la rglementation ( Edition 2000 ) et sur des
troisime Forum Mondial des politiques de tlcommunications.
13 - Le panorama des produits

Les informations contenues dans cette page n'engagent ni la responsabilit du webmaster, ni les diffrents
constructeurs auquel il faut se rfrer en cas d'tude prcise sur la tlphonie sur IP. Les images proviennent des
images existantes sur les sites des constructeurs. Work in progress. Travaux en cours. Mise jour du 13 juin2004. Le
panorama n'est pas class selon les qualits des constructeurs, il est class alatoirement.
13.1 - 3COM
Site
Produits
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
HiPath 3300 sous windows NT/2000, ETSI, ISO,

HiPath 3750 sous windows NT/2000, ETSI, ISO, CE, IP, 500
: http://www.siemens.fr/
CE, IP, 96 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
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/
ICC sous proprietaire et LINUX, H323, 5000 postes ip maxi, du

I5 IP sous proprietaire et LINUX, H323, 48 postes ip maxi, du type compatible H323
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
13.15 - FRANCE TELECOM

Site
e-DIATONIS
Mx
sous
e-DIATONIS
Lx
sous
e-DIATONIS
S
sous
e-DIATONIS
M
sous
e-DIATONIS L sous LINUX , 200
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
La solution de tlphonie sur IP e-phone a la particularit de s'intgrer directement dans l'environnement de

messagerie du client. Avec son combin USB, son casque USB ou son oreillette Bluetooth, il est possible d'mettre
ou de recevoir des appels directement partir de sa messagerie. Cette nouvelle offre construite autour de
serveurs standard Windows a de plus l'avantage d'utiliser toutes les possibilits de l'informatique :
-
Annuaires
Messagerie
Serveur
Lien
centraliss,
unifie,
vocal,
TAPI...
Document au format Pdf

13.21 - 3CX
Site internet : http://www.3cx.fr/
Faites voluer vos moyens de communications avec 3CX PABX-IP for Windows
Un autocom qui remplace entirement votre PABX propritaire, compatible avec tlphones/softphones SIP
standard, les services VoIP et les lignes RTC traditionnelles. 3CX PABX-IP est bien moins onreux qu'un PABX
traditionnel et peut vous aider faire des conomies importantes sur le cot des appels en utilisant un fournisseur
de services VoIP. Son administration web rend facile la gestion du systme tlphonique. 3CX PABX-IP limine le
rseau de branchements tlphoniques et permet aux utilisateurs d'avoir un poste direct en prenant tout
simplement leur tlphone.
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
Voix sur IP - VOIP
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.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.3 - Scurit et Authentification
6.2.4 - Comparaison avec H323
6.2.5 - Conclusion
6.3 - Transport Rtp et Rtcp
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
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.
2 - Le Rseau Tlphonique Commut
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.
On distingue deux grandes parties dans ce rseau :

Le rseau capillaire ou de distribution, c'est le raccordement depuis chez l'abonn un point d'entre du
rseau. Cette partie du rseau est analogique.
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.
3 - Les enjeux de la tlphonie sur Ip

Dans cette partie, nous allons voir pourquoi la tlphonie IP est devenue importante pour les entreprises. L'enjeu est
de russir faire converger le rseau de donne IP et le rseau tlphonique actuel. Voici les principales motivations
pour dployer la tlphonie sur IP (Source Sage Research 2003, sondage auprs de 100 dcisionnaires IT).
Motivations
Pourcentage
Rduction de cots
75 %
Ncessit de standardiser l'quipement
66 %
Hausse de la productivit des employs
65 %
Autres bnfices de productivit
64 %
Hausse du volume d'appels traiter
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.
4.2 - Standards ouverts et interoprabilit multi-fournisseurs

Trop souvent par le pass les utilisateurs taient prisonniers d'un choix technologique antrieur. La VoIP a
maintenant prouv tant au niveau des rseaux oprateurs que des rseaux d'entreprises que les choix et les
volutions
deviennent
moins
dpendants
de
l'existant.
Contrairement nos convictions du dbut, nous savons maintenant que le monde VoIP ne sera pas uniquement
H323, mais un usage multi-protocoles selon les besoins de services ncessaires. Par exemple, H323 fonctionne en
mode "peer to peer" alors que MGCP fonctionne en mode centralis. Ces diffrences de conception offrent
immdiatement une diffrence dans l'exploitation des terminaisons considres.
4.3 - Choix d'un service opr
Les services oprateurs ouvrent les alternatives VoIP. Non seulement l'entreprise peut oprer son rseau
privVoIP en extension du rseau RTC oprateur, mais l'oprateur lui-mme ouvre de nouveaux services de
transport VoIP qui simplifient le nombre d'accs locaux un site et rduit les cots induits. Le plus souvent les
entreprises oprant des rseaux multi-sites louent une liaison prive pour la voix et une pour la donne, en
conservant les connexions RTC d'accs local. Les nouvelles offres VoIP oprateurs permettent outre les accs RTC
locaux, de souscrire uniquement le mdia VoIP inter-sites.
4.4 - Un rseau voix, vido et donnes (triple play)
En positionnant la voix comme une application supplmentaire du rseau IP, l'entreprise ne va pas uniquement
substituer un transport oprateur RTC un transport IP, mais simplifier la gestion des trois rseaux (voix,
donnes et vido) par ce seul transport. Une simplification de gestion, mais galement une mutualisation des
efforts financiers vers un seul outil. Concentrer cet effort permet de bnficier d'un rseau de meilleure qualit,
plus facilement volutif et plus disponible, pourvu que la bande passante du rseau concentrant la voix, la vido
et
les
donnes
soit
dimensionne
en
consquence.
4.5 - Un service PABX distribu ou centralis

Les PABX en rseau bnficient de services centraliss tel que la messagerie vocale, la taxation, etc... Cette
mme centralisation continue tre assure sur un rseau VoIP sans limitation du nombre de canaux. A l'inverse,
un certain nombre de services sont parfois souhaits dans un mode de dcentralisation. C'est le cas du centre
d'appels o le besoin est une centralisation du numro d'appel (ex : numro vert), et une dcentralisation des
agents du centre d'appel. Difficile effectuer en tlphonie traditionnelle sans l'utilisation d'un rseau IP pour le
dport de la gestion des ACD distants. Il est ainsi trs facile de constituer un centre d'appel ou centre de contacts
(multi canaux/multi-mdias) virtuel qui possde une centralisation de supervision et d'informations.
Il convient pour en assurer une bonne utilisation de dimensionner convenablement le lien rseau. L'utilisation de
la VoIP met en commun un mdia qui peut la fois offrir un moment prcis une bande passante maximum la
donne, et dans une autre priode une bande passante maximum la voix, garantissant toujours la priorit
celle-ci.
4.6 - Evolution vers un rseau de tlphonie sur Ip
La tlphonie sur IP repose totalement sur un transport VoIP. La mise en oeuvre de la VoIP offre l une premire
brique de migration vers la tlphonie sur IP.
4.7 - Intgration des services vido
La VoIP intgre une gestion de la voix mais galement une gestion de la vido. Si nous excluons la configuration
des "multicasts" sur les composants du rseau, le rseau VoIP peut accueillir des applications vido de type vido
confrence, vido surveillance, e-learning, vido on demand,..., pour l'ensemble des utilisateurs un cot
d'infrastructure rseau supplmentaire minime.
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
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.
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
6.1.4 - La visioconfrence sur Ip

Tout d'abord, au niveau conomique, la visioconfrence sur Ip s'avre moins coteuse que celle sur liaison
RNIS car d'un ct, l'quipement d'un PC est relativement peu cher : ce systme ne ncessite pas
l'installation de prises RNIS spciales. D'autre part, une liaison Rnis a un cot calcul selon la longueur de
l'appel, le dbit, et la distance. Alors que dans une liaison IP, le prix est forfaitaire selon le dbit. En fin de
compte, la visioconfrence par Ip s'avre souvent moins onreuse que par liaison Rnis.
Ensuite, qualitativement parlant, la visioconfrence sur Ip peut utiliser des dbits suprieurs et ainsi avoir
une image et un son meilleurs qu'avec une liaison Rnis. En effet, la visioconfrence sur Numeris utilise des
dbits allant de 128Kb/s 384Kb/s, alors qu'en mutualisant certaines liaisons Ip, on peut obtenir des lignes
haut dbit allant jusqu' plusieurs Mb/s. Malheureusement, le problme majeur de la visioconfrence sur Ip
est l'absence d'une Qualit de Service (QoS) sur les rseaux Ip. C'est galement ce qui fait l'avantage des
rseaux Rnis. Cependant, avec l'volution des rseaux Ip, on sait dsormais qu'il est possible qu'on puisse
disposer d'une QoS sur ceux-ci tel que Rsvp, Diffserv, gestion de file d'attente. On pourrait donc avoir des
flux
avec
priorit
sur
ces
rseaux.
En dehors du protocole H.323, il existe des normes de visioconfrence sur Ip ayant des possibilits analogues
H.323 telles que Ip multicast, qui est particulirement adapts au tlenseignement et la diffusion de
sminaires et confrences car il permet la connexion de plusieurs dizaines de sites voire plus. Il existe
galement le systme Vrvs qui est utilis dans certaines communauts scientifiques, notamment la physique,
en
raison
de
sa
convivialit.
Il
intgre
Ip
multicast
et
H.323.
Pour pouvoir suivre une visioconfrence, il faut bien entendu le matriel adquat. Ce peut tre un matriel
ddi contenant tout ce qu'il faut : moniteur, micro, et camra vido. Ou alors, un ensemble matriel et
logiciel sur un poste de travail normal (PC, etc.). Si la visioconfrence ne compte que deux interlocuteurs,
alors
la
liaison
est
point
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
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.
Sip intervient aux diffrentes phases de l'appel :
Localisation du terminal correspondant,

Analyse du profil et des ressources du destinataire,
Ngociation du type de mdia (voix, vido, donnes...) et des paramtres de communication,
Disponibilit du correspondant, dtermine si le poste appel souhaite communiquer, et autorise
l'appelant le contacter.
Etablissement et suivi de l'appel, avertit les parties appelant et appel de la demande d'ouverture de
session, gestion du transfert et de la fermeture des appels.
Gestion de fonctions volues : cryptage, retour d'erreurs, ...
Avec Sip, les utilisateurs qui ouvrent une session peuvent communiquer en mode point point, en mode
diffusif ou dans un mode combinant ceux-ci. Sip permet donc l'ouverture de sessions en mode :
Point--point - Communication entre 2 machines, on parle d'unicast.
Diffusif - Plusieurs utilisateurs en multicast, via une unit de contrle M.C.U (Multipoint Control Unit)
Combinatoire - Plusieurs utilisateurs pleinement interconnects en multicast via un rseau maillage
complet de connexions.
Voici les diffrents lments intervenant dans l'ouverture de session :
Suivant nature des changes, choix des protocoles les mieux adapts (Rsvp, Rtp, Rtcp, Sap, Sdp).
Dtermination du nombre de sessions, comme par exemple, pour vhiculer de la vido, 2 sessions
doivent tre ouvertes (l'une pour l'image et l'autre pour la vido).
Chaque utilisateur et sa machine est identifi par une adresse que l'on nomme Url Sip et qui se
prsente comme une Url Mailto.
Requte Uri permettant de localiser le proxy server auquel est rattach la machine de l'appel.
Requte Sip, une fois le client (machine appelante) connect un serveur Sip distant, il peut lui
adresser une ou plusieurs requtes Sip et recevoir une ou plusieurs rponses de ce serveur. Les
rponses contiennent certains champs identiques ceux des requtes, tels que : Call-ID, Cseq, To et
From.
Les changes entre un terminal appelant et un terminal appel se font par l'intermdiaire de requtes :
Invite - Cette requte indique que l'application (ou utilisateur) correspondante l'Url Sip spcifi est
invit participer une session. Le corps du message dcrit cette session (par ex : mdia supports
par l'appelant ). En cas de rponse favorable, l'invit doit spcifier les mdias qu'il supporte.
Ack - Cette requte permet de confirmer que le terminal appelant a bien reu une rponse dfinitive
une requte Invite.
Options - Un proxy server en mesure de contacter l'UAS (terminal) appel, doit rpondre une
requte Options en prcisant ses capacits contacter le mme terminal.
Bye - Cette requte est utilise par le terminal de l'appel fin de signaler qu'il souhaite mettre un
terme la session.
Cancel - Cette requte est envoye par un terminal ou un proxy server fin d'annuler une requte
non valide par une rponse finale comme, par exemple, si une machine ayant t invite participer
une session, et ayant accept l'invitation ne reoit pas de requte Ack, alors elle met une requte
Cancel.
Register - cette mthode est utilise par le client pour enregistrer l'adresse liste dans l'URL TO par le
serveur auquel il est reli.
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
Nombre changes pour tablir

la connexion
1,5 aller-retour
6 7 aller-retour
Maintenance du code
protocolaire
Simple par sa nature textuelle

l'exemple de Http
Complexe et ncessitant un compilateur
Evolution du protocole
Protocole ouvert de nouvelles

fonctions
Ajout d'extensions propritaires sans

concertation entre vendeurs
Fonction de confrence
Distribue
Centralise par l'unit MC
Fonction de tlservices
Oui, par dfaut
H.323 v2 + H.450
Dtection d'un appel en boucle Oui
Inexistante sur la version 1

un appel rout sur l'appelant provoque une
infinit de requtes
Signalisation multicast
Non
Oui, par dfaut
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
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
Deux observations principales peuvent tre tires du Tableau 3-5 :

La qualit de la voix obtenue par les codecs G.729 et G.723.1 ( 6.4Kbps) est trs proche de celle du
service tlphonique actuel, et ce pour des dbits entre 8 et 10 fois infrieurs. Ces deux codecs prsentent
une meilleure qualit que celle des rseaux tlphoniques cellulaires (GSM).
Le cumul, dans une mme communication, d'oprations de compression/dcompression conduit une
rapide dgradation de la qualit. Les solutions mises en oeuvre doivent viter des configurations en tandem
dans lesquelles un PBX reoit un appel d'un poste distant travers une liaison VoIP et le redirige vers une
autre liaison semblable.
Offrant une qualit de voix trs proche, les codecs G.729 et G.723.1 se distinguent essentiellement par la bande
passante qu'ils requirent et par le retard que chacun introduit dans la transmission. Le choix d'un quipement
implmentant l'un ou l'autre de ces codecs devra donc tre fait selon la situation, en fonction notamment de la
bande passante disposition et du retard cumul maximum estim pour chaque liaison (selon les standards de
l'UIT, le retard aller ( one-way delay ) devrait tre infrieur 150 ms). Le facteur du jitter est primordiale pour
une bonne coute de la Voip.
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:
Le dbit de transmission sur chaque lien

Le nombre d'lments rseaux traverss
Le temps de traverse de chaque lment, qui est lui mme fonction de la puissance et la charge de ce
dernier, du temps de mise en file d'attente des paquets, et du temps d'accs en sortie de l'lment
Le dlai de propagation de l'information, qui est non ngligeable si on communique l'oppos de la terre.
Une transmission par fibre optique, l'oppos de la terre, dure environ 70 ms.
Noter que le temps de transport de l'information n'est pas le seul facteur responsable de la dure totale de
traitement de la parole. Le temps de codage et la mise en paquet de la voix contribuent aussi de manire
importante
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
Dlai par sens
Commentaires
0 150 ms
Acceptable pour la plupart des conversations
150 300 ms
Acceptable pour des communications faiblement interactives
300 700 ms
Devient pratiquement une communication half duplex
Au del de 700 ms
Inutilisable sans une bonne pratique de la conversation half duplex
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-
2.5 - Tlvision par ADSL

2.5.2 - Bande passante et encodage
2.5.3 - Vido la demande
Triple Play par cble
3.1 - Origine
3.2 - Hybride Fiber Coax
3.3 - Modem Cble
3.4 - DVB/DAVIC
3.5 - DOCSIS et PacketCable
Offres des diffrents oprateurs
Evolution
5.1 - WiMax
5.2 - UMA (Unlicensed Mobile Acces)
Conclusion
Suivi du document
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.
2 - Triple Play par ADSL

L'ADSL (Asymmetric Digital Subscriber Line) est la technologie la plus utilise actuellement pour l'accs Internet par
les particuliers. Bien que a ne fut pas historiquement sur ce type de technologie que les offres Triple Play ont t
dveloppes, c'est aujourd'hui le premier fournisseur de ce genre d'offres.
Avant d'expliquer le fonctionnement de ces offres via ADSL, nous allons effectuer une brve description de cette
technologie.
2.1 - La technologie ADSL
L'ADSL est une technologie dveloppe pour pouvoir faire passer des donnes informatiques au travers des lignes
tlphoniques (cela permet alors de rutiliser un rseau de cble dj existant). Pour ce faire, elle utilise les
bandes de hautes frquences, non utilises par la tlphonie (300-3400Hz), en utilisant des techniques de
multiplexage et de modulation adaptes aux lignes tlphoniques. Le fait d'utiliser les frquences hautes de la
ligne tlphonique implique cependant l'utilisation d'un filtre de part et d'autre de la ligne tlphonique afin que
les signaux de tlphonie ne viennent pas perturber les signaux ADSL (et inversement).
Les flux sont asymtriques, ce qui signifie qu'en ADSL, un abonn peut envoyer des donnes (voie montante)
un dbit plus faible qu'il peut en recevoir (voie descendante). Cela est particulirement adapt une utilisation de
la connexion par un particulier qui reoit plus souvent des donnes qu'il n'en envoie (bien que l'asymtrie de
l'ADSL soit plus d une contrainte technique qu' un rel choix).
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.2 - Connexion la Set-Top-Box

La STB est connecte la ligne tlphonique de l'utilisateur. A l'autre bout de la ligne tlphonique se trouve
le DSLAM qui a pour tche de faire la passerelle entre les quipements des utilisateurs (via la STB) et le
rseau du FAI. Le DSLAM se situe au niveau du central tlphonique local (plus techniquement appel le
Noeud de Raccordement Abonn), et peut tre un quipement appartenant au FAI ou l'oprateur
historique, France Tlcom (cela dpend du niveau de dgroupage de l'abonn). Un mme DSLAM est
connect un ensemble d'abonns (du mme FAI). Le nombre d'abonns par DSLAM varie en fonction du
fabricant (ex: 1008 abonns par DSLAM pour Free).
La communication entre la STB et le DSLAM est effectue en utilisant la technologie ADSL. Cette technologie
provenant des tlcommunications, elle implique quasiment tout le temps l'utilisation du protocole ATM au
dessus, ce dernier tant suffisamment simple pour tre implment facilement dans des appareils de
tlcommunication et offrant une trs bonne gestion de la QoS. Dans le cas d'une offre Triple Play, il peut
aussi s'agir d'une extension du protocole ATM qui est utilise (RFC 2684), afin de permettre le transport de
plusieurs flux (protocoles) diffrents via ATM. Ces flux sont gnralement au nombre de quatre: un pour les
donnes audio (tlphonie), un pour les donnes vido (tlvision), un pour les donnes Internet, et un
dernier pour les donnes de contrle des trois flux prcdents.
Enfin, au dessus d'ATM, on peut trouver un certain nombre de protocoles, mais pour ce qui nous intresse
(l'accs Internet), il s'agit bien videmment du protocole IP (qui peut tre encapsul dans de l'Ethernet
chez certains FAI pour faciliter l'interfaage avec le rseau interne de ces FAI).
Le DSLAM peut contenir certains services IP, comme un service DHCP par exemple, pour configurer les STB.
a n'est cependant pas courant.
La connexion entre le DSLAM et le rseau du FAI est effectue l'aide d'une ou plusieurs fibres optiques. A
ce niveau, les technologies utilises sont SDH ou DWDM, couples un protocole pouvant supporter le trs
haut dbit, type ATM ou Gigabit Ethernet. Dans ce dernier cas, les fonctions de routages sont effectues par
la pile TCP/IP, le protocole IP tant invitablement utilis dans tous les cas pour pouvoir interagir avec
Internet et les services IP du FAI (e-mails, newsgroup, proxy Web, etc.).
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.
Ces implmentations permettent gnralement d'effectuer trois types de conversations:
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:
H.323: cette norme regroupe un ensemble de protocoles de communication de la voix, de l'image

et de donnes sur IP. C'est un protocole qui fut dvelopp par l'UIT-T en 1996. Il est driv du
protocole H.320 utilis sur RNIS. Il se base sur le fonctionnement de la tlphonie classique (de
l'poque), et est de fait assez complexe et trs rigide. Il est de plus en plus remplac par
leprotocole SIP, plus simple utiliser et bien plus modulaire.
SIP (Session Initiation Protocol): c'est un protocole normalis et standardis par l'IETF (RFC 3261)
qui a t conu pour tablir, modifier et terminer des sessions multimedia. Il se charge de
l'authentification et la localisation des multiples participants. Il se charge galement de la
ngociation sur les types de mdia utilisables par les diffrents participants. SIP ne transporte pas
les donnes changes durant la session comme la voix ou la vido. SIP tant indpendant de la
transmission des donnes, tout type de donnes et de protocoles peut tre utilis pour cet change.
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.
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.
3 - Triple Play par cble

3.1 - Origine
A l'origine le cble a t dvelopp pour vhiculer des missions de tlvision : il tait donc analogique,
unidirectionnel et dploy dans les zones rsidentielles. La tlvision devenant numrique les cablo-oprateurs ont
voulu suivre. Ils ont alors rapidement voulu dvelopper leur offre pour offrir leurs abonns l'Internet et la
tlphonie. Le cble devient alors bidirectionnel et se dploiera dans le zones industrielles pour s'ouvrir aux
entreprises.
A l'origine les rseaux desservant l'abonn tait constitu de cble coaxiaux TV. Ils ont une impdance de 75
ohms et offrent une largeur de bande de 400 Mhz environ. Leurs taux d'affaiblissement est important. Le nombre
de rpteur ncessaires au transport du signal viennent limiter la bande passante.
Afin d'augmenter cette bande passante une nouvelle architecture a t construite : l'architecture HFC, Hybride
Fiber Coax.
3.2 - Hybride Fiber Coax
L'architecture HFC combine les deux supports de transmission que sont la fibre optique et le cble coaxial. Le
cble coaxial est alors utilis pour le dernier kilomtre vers l'abonn. Cette architecture s'oppose un rseau en
coaxial de bout en bout et l'architecture FTTH, Fiber To The Home, ou seul le dernier mtre est en coaxial.
Le cble tait prvu au dpart pour faire uniquement arriver la tlvision chez l'abonn. Il fonctionnait donc en
mode half-duplex, du fournisseur vers l'abonn. Les communications dans le sens inverse n'taient possible que
via une ligne tlphonique. Ce systme tait performant pour l'acheminement de la tlvision seul. Mais le halfduplex n'est pas adapt pour les services Internet ou la tlphonie. Les cablo-oprateurs ont donc largement
investi pour passer en full-duplex, en dveloppant des architectures HFC. Ils mettent ainsi en service la voie de
retour de leurs cbles, qui auparavant servait la maintenance ou aux tests. Cela permet d'obtenir des dbits de
27 36 Mbps en voie descendante et de 320 Kbps 10 Mbps en voie montante. Ces lignes full-duplex offrent
donc prsent des dbits suffisants pour permettre aux fournisseurs de proposer leurs abonns Internet et
tlphonie.
Pour l'architecture HFC les artres sont donc en fibre optique, et la distribution jusqu' l'abonn passe par du
coaxiale. Le cble coaxial ne sert donc plus que pour le dernier kilomtre au plus. Un noeud de rseau HFC
dessert entre 500 et 1500 abonns. Au contraire de l'ADSL la bande passante doit tre partage par tous. Ce
systme, logique pour la distribution de la tlvision uniquement, peut poser des problmes de vitesse de
transmission. Ainsi il y a le plus souvent une limitation en download pour les abonns.
De plus cela signifie que l'ensemble des abonns sur un noeud reoivent l'ensemble des messages. Pour assurer
un minimum de scurit des donnes, il faut donc que l'oprateur crypte ces donnes et que seul l'abonn
destinataire soit en mesure de le dcrypter.
L'avantage de cette solution est de bnficier du rseau TV cbl dj mis en place. Mais ce rseau ce limite aux
grandes agglomrations, et il est financirement lourd a dploy. La communication s'effectue grce un modem
cbl situ chez l'abonn.
3.3 - Modem Cble
Il est indispensable de disposer d'un modem cble pour pouvoir bnficier de l'Internet et de la tlphonie via le
cble. En effet les signaux de donnes numriques sont transmis travers des signaux de spectre de frquence
radio sur le cble. Les modems cbles permettent de convertir les donnes numriques en signal modul de
frquence radio et inversement.
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 :
Downstream Broadcast Channel : permettant la diffusion de la tlvision.

Downstream Interactive Channel : communication de l'oprateur vers l'abonn.
Upstream Return Channel : communication de l'abonn vers l'oprateur.
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.
4 - Offres des diffrents oprateurs

Voici un tableau comparatif des diffrents oprateurs proposant du Triple play. Nous avons deux catgories: les
oprateurs proposant du Triple play travers le tlphone (ADSL), et les oprateurs passant par le cble.
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
Rseaux Privs Virtuels - Vpn
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
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
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
2.1 - Principe gnral

Un rseau Vpn repose sur un protocole appel "protocole de tunneling". Ce protocole permet de faire circuler les
informations de l'entreprise de faon crypte d'un bout l'autre du tunnel. Ainsi, les utilisateurs ont l'impression
de
se
connecter
directement
sur
le
rseau
de
leur
entreprise.
Le principe de tunneling consiste construire un chemin virtuel aprs avoir identifi l'metteur et le destinataire.
Par la suite, la source chiffre les donnes et les achemine en empruntant Ce chemin virtuel. Afin d'assurer un
accs ais et peu coteux aux intranets ou aux extranets d'entreprise, les rseaux privs virtuels d'accs simulent
un rseau priv, alors qu'ils utilisent en ralit une infrastructure d'accs partage, comme Internet.
Les donnes transmettre peuvent tre prises en charge par un protocole diffrent d'Ip. Dans Ce cas, le protocole
de tunneling encapsule les donnes en ajoutant une en-tte. Le tunneling est l'ensemble des processus
d'encapsulation, de transmission et de dsencapsulation.
2.2 - Fonctionnalits des Vpn
Il existe 3 types standard d'utilisation des Vpn. En tudiant ces schmas d'utilisation, il est possible
d'isoler les fonctionnalits indispensables des Vpn.
2.2.1 - Le Vpn d'accs
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.
2.2.2 - L'intranet Vpn
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.
3 - Protocoles utiliss pour raliser une connexion Vpn

Nous pouvons classer les protocoles que nous allons tudier en deux catgories:
Les protocoles de niveau 2 comme Pptp et L2tp.
Les protocoles de niveau 3 comme Ipsec ou Mpls.
Il existe en ralit trois protocoles de niveau 2 permettant de raliser des Vpn : Pptp (de Microsoft), L2F (dvelopp
par CISCO) et enfin L2tp. Nous n'voquerons dans cette tude que Pptp et L2tp : le protocole L2F ayant aujourd'hui
quasiment disparut. Le protocole Pptp aurait sans doute lui aussi disparut sans le soutien de Microsoft qui continue
l'intgrer ses systmes d'exploitation Windows. L2tp est une volution de Pptp et de L2F, reprenant les avantages
des
deux
protocoles.
Les protocoles de couche 2 dpendent des fonctionnalits spcifies pour Ppp (Point to Point Protocol), c'est pourquoi
nous allons tout d'abord rappeler le fonctionnement de Ce protocole.
3.1 - Rappels sur Ppp
Ppp (Point to Point Protocol) est un protocole qui permet de transfrer des donnes sur un lien synchrone ou
asynchrone. Il est full duplex et garantit l'ordre d'arrive des paquets. Il encapsule les paquets Ip, Ipx et Netbeui
dans des trames Ppp, puis transmet ces paquets encapsuls au travers de la liaison point point. Ppp est employ
gnralement entre un client d'accs distance et un serveur d'accs rseau (Nas). Le protocole Ppp est dfini
dans la Rfc 1661 appuy de la Rfc 2153.
3.1.1 - Gnralits
Ppp est l'un des deux protocoles issus de la standardisation des communications sur liaisons sries (Slip
tant le deuxime). Il permet non seulement l'encapsulation de datagrammes, mais galement la rsolution
de certains problmes lis aux protocoles rseaux comme l'assignation et la gestion des adresses (Ip, X25 et
autres).
Une connexion Ppp est compose principalement de trois parties :
Une mthode pour encapsuler les datagrammes sur la liaison srie. Ppp utilise le format de trame Hdlc
(Hight Data Level Control) de l'ISO (International Standartization Organisation).
Un protocole de contrle de liaison (Lcp - Link Control Protocol) pour tablir, configurer et tester la
connexion de liaison de donnes.
Plusieurs protocoles de contrle de rseaux (Ncps - Network Control Protocol) pour tablir et
configurer les diffrents protocoles de couche rseau.
3.1.2 - Format d'une trame Ppp
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 documentation ddi L2TP est prsent sur le site de FrameIP.

3.3.1 - Concentrateurs d'accs L2tp (Lac : L2tp Access Concentrator)
Les priphriques Lac fournissent un support physique aux connexions L2tp. Le trafic tant alors transfr
sur les serveurs rseau L2tp. Ces serveurs peuvent s'intgrer la structure d'un rseau commut Rtc ou
alors un systme d'extrmit Ppp prenant en charge le protocole L2tp. Ils assurent le fractionnement en
canaux de tous les protocoles bass sur Ppp. Le Lac est l'metteur des appels entrants et le destinataire des
appels sortants.
3.3.2 - Serveur rseau L2tp (Lns : L2tp Network Server)
Les serveurs rseau L2tp ou Lns peuvent fonctionner sur toute plate-forme prenant en charge la terminaison
Ppp. Le Lns gre le protocole L2tp ct serveur. Le protocole L2tp n'utilise qu'un seul support, sur lequel
arrivent les canaux L2tp. C'est pourquoi, les serveurs rseau Lns, ne peuvent avoir qu'une seule interface de
rseau local (Lan) ou tendu (Wan). Ils sont cependant capables de terminer les appels en provenance de
n'importe quelle interface Ppp du concentrateur d'accs Lac : async., Rnis, Ppp sur Atm ou Ppp sur relais de
trame. Le Lns est l'metteur des appels sortants et le destinataire des appels entrants. C'est le Lns qui sera
responsable de l'authentification du tunnel.
3.4 - Le protocole Ipsec

Ipsec, dfinit par la Rfc 2401, est un protocole qui vise scuriser l'change de donnes au niveau de la couche
rseau. Le rseau Ipv4 tant largement dploy et la migration vers Ipv6 tant invitable, mais nanmoins
longue, il est apparu intressant de dvelopper des techniques de protection des donnes communes Ipv4 et
Ipv6. Ces mcanismes sont couramment dsigns par le terme Ipsec pour Ip Security Protocols. Ipsec est bas
sur deux mcanismes. Le premier, AH, pour Authentification Header vise assurer l'intgrit et l'authenticit des
datagrammes IP. Il ne fournit par contre aucune confidentialit : les donnes fournies et transmises par Ce
"protocole" ne sont pas encodes. Le second, Esp, pour Encapsulating Security Payload peut aussi permettre
l'authentification des donnes mais est principalement utilis pour le cryptage des informations. Bien
qu'indpendants ces deux mcanismes sont presque toujours utiliss conjointement. Enfin, le protocole Ike
permet de grer les changes ou les associations entre protocoles de scurit. Avant de dcrire ces diffrents
protocoles,
nous
allons
exposer
les
diffrents
lments
utiliss
dans
Ipsec.
Une documentation ddi IPSEC est prsente sur le site de FrameIP.
3.4.1 - Vue d'ensemble
Les mcanismes mentionns ci-dessus font bien sr appel la cryptographie et utilisent donc un certain
nombre de paramtres (algorithmes de chiffrement utiliss, clefs, mcanismes slectionns...) sur lesquels
les tiers communicants doivent se mettre d'accord. Afin de grer ces paramtres, Ipsec a recours la notion
d'association
de
scurit
(Security
Association,
SA).
Une association de scurit Ipsec est une "connexion" simplexe qui fournit des services de scurit au trafic
qu'elle transporte. On peut aussi la considrer comme une structure de donnes servant stocker l'ensemble
des
paramtres
associs
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.
On distingue deux situations :

Trafic
sortant
Lorsque la "couche" Ipsec reoit des donnes envoyer, elle commence par consulter la base de
donnes des politiques de scurit (SPD) pour savoir comment traiter ces donnes. Si cette base lui
indique que le trafic doit se voir appliquer des mcanismes de scurit, elle rcupre les
caractristiques requises pour la SA correspondante et va consulter la base des SA (SAD). Si la SA
ncessaire existe dj, elle est utilise pour traiter le trafic en question. Dans le cas contraire, Ipsec
fait appel IKE pour tablir une nouvelle SA avec les caractristiques requises.
Trafic
entrant
Lorsque la couche Ipsec reoit un paquet en provenance du rseau, elle examine l'en-tte pour savoir
si Ce paquet s'est vu appliquer un ou plusieurs services Ipsec et si oui, quelles sont les rfrences de
la SA. Elle consulte alors la SAD pour connatre les paramtres utiliser pour la vrification et/ou le
dchiffrement du paquet. Une fois le paquet vrifi et/ou dchiffr, la Spd est consulte pour savoir si
l'association de scurit applique au paquet correspondait bien celle requise par les politiques de
scurit.
Dans le cas o le paquet reu est un paquet Ip classique, la Spd permet de savoir s'il a nanmoins le droit de
passer. Par exemple, les paquets IKE sont une exception. Ils sont traits par Ike, qui peut envoyer des
alertes administratives en cas de tentative de connexion infructueuse.
3.4.3 - Le protocole Ah (Authentication Header)
L'absence de confidentialit permet de s'assurer que Ce standard pourra tre largement rpandu sur
Internet, y compris dans les endroits o l'exportation, l'importation ou l'utilisation du chiffrement dans des
buts
de
confidentialit
est
restreint
par
la
loi.
Son principe est d'adjoindre au datagramme Ip classique un champ supplmentaire permettant la rception
de vrifier l'authenticit des donnes incluses dans le datagramme. Ce bloc de donnes est appel "valeur de
vrification d'intgrit" (Intgrity Check Value, Icv). La protection contre le rejet se fait grce un numro
de
squence.
3.4.4 - Protocole Esp (Encapsulating Security Payload)

Esp peut assurer au choix, un ou plusieurs des services suivants :
Confidentialit (confidentialit des donnes et protection partielle contre l'analyse du trafic si l'on
utilise le mode tunnel).
Intgrit des donnes en mode non connect et authentification de l'origine des donnes, protection
contre le rejeu.
La confidentialit peut tre slectionne indpendamment des autres services, mais son utilisation sans
intgrit/authentification (directement dans Esp ou avec AH) rend le trafic vulnrable certains types
d'attaques
actives
qui
pourraient
affaiblir
le
service
de
confidentialit.
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).
Ajoute si ncessaire un bourrage.

Chiffre le rsultat (donnes, bourrage, champs longueur et en-tte suivant).
Ajoute ventuellement des donnes de synchronisation cryptographiques (vecteur d'initialisation) au
dbut du champ "charge utile".
3.4.5 - La gestion des clefs pour Ipsec : Isakmp et Ike
Les protocoles scuriss prsents dans les paragraphes prcdents ont recours des algorithmes
cryptographiques et ont donc besoin de clefs. Un des problmes fondamentaux d'utilisation de la
cryptographie est la gestion de ces clefs. Le terme "gestion" recouvre la gnration, la distribution, le
stockage
et
la
suppression
des
clefs.
IKE (Internet Key Exchange) est un systme dvelopp spcifiquement pour Ipsec qui vise fournir des
mcanismes d'authentification et d'change de clef adapts l'ensemble des situations qui peuvent se
prsenter sur l'Internet. Il est compos de plusieurs lments : le cadre gnrique Isakmp et une partie des
protocoles Oakley et Skeme. Lorsqu'il est utilis pour Ipsec, IKE est de plus complt par un "domaine
d'interprtation" pour Ipsec.
3.4.5.1 - Isakmp (Internet Security Association and Key Management Protocol)
Isakmp a pour rle la ngociation, l'tablissement, la modification et la suppression des associations de
scurit et de leurs attributs. Il pose les bases permettant de construire divers protocoles de gestion des clefs
(et plus gnralement des associations de scurit). Il comporte trois aspects principaux :
Il dfinit une faon de procder, en deux tapes appeles phase 1 et phase 2 : dans la premire, un
certain nombre de paramtres de scurit propres Isakmp sont mis en place, afin d'tablir entre les
deux tiers un canal protg ; dans un second temps, Ce canal est utilis pour ngocier les associations
de scurit pour les mcanismes de scurit que l'on souhaite utiliser (AH et Esp par exemple).
Il dfinit des formats de messages, par l'intermdiaire de blocs ayant chacun un rle prcis et
permettant de former des messages clairs.
Il prsente un certain nombre d'changes types, composs de tels messages, qui permettant des
ngociations prsentant des proprits diffrentes : protection ou non de l'identit, perfect forward
secrecy...
Isakmp est dcrit dans la Rfc 2408.
3.4.5.2 Ike (Internet Key Exchange)
IKE utilise Isakmp pour construire un protocole pratique. Il comprend quatre modes :
Le mode principal (Main mode)
Le mode agressif (Aggressive Mode)
Le mode rapide (Quick Mode)
Le mode nouveau groupe (New Groupe Mode)
Main Mode et Aggressive Mode sont utiliss durant la phase 1, Quick Mode est un change de phase 2. New
Group Mode est un peu part : Ce n'est ni un change de phase 1, ni un change de phase 2, mais il ne peut
avoir lieu qu'une fois qu'une SA Isakmp est tablie ; il sert se mettre d'accord sur un nouveau groupe pour
de
futurs
changes
Diffie-Hellman.
a)
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
3.4.6 - Les deux modes de fonctionnement de Ipsec

Le mode transport prend un flux de niveau transport (couche de niveau 4 du modle OSI) et ralise les
mcanismes de signature et de chiffrement puis transmet les donnes la couche Ip. Dans Ce mode,
l'insertion de la couche Ipsec est transparente entre Tcp et Ip. Tcp envoie ses donnes vers Ipsec comme il
les
enverrait
vers
IPv4.
L'inconvnient de Ce mode rside dans le fait que l'en-tte extrieur est produit par la couche Ip c'est--dire
sans masquage d'adresse. De plus, le fait de terminer les traitements par la couche Ip ne permet pas de
garantir la non-utilisation des options Ip potentiellement dangereuses. L'intrt de Ce mode rside dans une
relative
facilit
de
mise
en
oeuvre.
Dans le mode tunnel, les donnes envoyes par l'application traversent la pile de protocole jusqu' la couche
Ip incluse, puis sont envoyes vers le module Ipsec. L'encapsulation Ipsec en mode tunnel permet le
masquage d'adresses. Le mode tunnel est utilis entre deux passerelles de scurit (routeur, firewall, ...)
alors
que
le
mode
transport
se
situe
entre
deux
htes.
3.5 - Le protocole Mpls

Le protocole Mpls est un brillant rejeton du "tout ip". Il se prsente comme une solution aux problmes de routage
des datagrammes Ip vhiculs sur Internet. Le principe de routage sur Internet repose sur des tables de routage.
Pour chaque paquet les routeurs, afin de dterminer le prochain saut, doivent analyser l'adresse de destination du
paquet contenu dans l'entte de niveau 3. Puis il consulte sa table de routage pour dterminer sur quelle interface
doit sortir le paquet. Ce 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. Le protocole Mpls fut initialement dvelopp pour donner une plus grande puissance aux
commutateurs Ip, mais avec l'avnement 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 augmenter sans le recours Mpls.
3.5.1 - Principe de fonctionnement de Mpls
Le principe de base de Mpls est la commutation de labels. Ces labels, simples nombres entiers, sont insrs
entre les en-ttes de niveaux 2 et 3, les routeurs permutant alors ces labels tout au long du rseau jusqu'
destination, sans avoir besoin de consulter l'entte Ip et leur table de routage.
3.5.1.1 - Commutation par labels
Cette technique de commutation par labels est appele Label Swapping. Mpls permet de dfinir des piles de
labels (label stack), dont l'intrt apparatra avec les Vpn. Les routeurs ralisant les oprations de label
swapping
sont
appels
Lsr
pour
Label
Switch
Routers.
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.
3.5.1.2 - Classification des paquets

A l'entre du rseau Mpls, les paquets Ip sont classs dans des Fec (Forwarding Equivalent Classes). Des
paquets appartenant une mme Fec suivront le mme chemin et auront la mme mthode de forwarding.
Typiquement, les Fec sont des prfixes Ip appris par l'Igp tournant sur le backbone Mpls, mais peuvent aussi
tre dfinis par des informations de Qos (Quality Of Services). La classification des paquets s'effectue
l'entre du backbone Mpls, par les Ingress Lsr. A l'intrieur du backbone Mpls, les paquets sont labelswitchs, et aucune reclassification des paquets n'a lieu. Chaque Lsr affecte un label local, qui sera utilis en
entre, pour chacune de ses Fec et le propage ses voisins. Les Lsr voisins sont appris grce l'Igp.
L'ensemble des Lsr utiliss pour une Fec, constituant un chemin travers le rseau, est appel Label Switch
Path (Lsp). Il existe un Lsp pour chaque Fec et les Lsp sont unidirectionnels.
3.5.2 - Utilisation du Mpls pour les Vpn
Pour satisfaire les besoins des oprateurs de services Vpn, la gestion de Vpn-IP l'aide des protocoles Mpls a
t dfinie dans une spcification rfrence Rfc 2547. Des tunnels sont crs entre des routeurs Mpls de
priphrie appartenant l'oprateur et ddis des groupes ferms d'usagers particuliers, qui constituent
des Vpn. Dans l'optique Mpls/Vpn, un Vpn est un ensemble de sites placs sous la mme autorit
administrative, ou groups suivant un intrt particulier.
3.5.2.1 - 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 de 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, quel que soit son
type ou la version d'OS utilise.
Le
schma
ci-dessous
montre
l'emplacement
de
ces
routeurs
dans
une
architecture
Mpls
3.5.2.2 - Routeurs Virtuels : VRF

La notion mme de Vpn implique l'isolation du trafic entre sites clients n'appartenant pas aux mmes Vpn.
Pour raliser cette sparation, les routeurs Pe ont la capacit de grer plusieurs tables de routage grce la
notion de Vrf (Vpn Routing and Forwarding). Une Vrf est constitue d'une table de routage, d'une Fib
(Forwarding Information Base) et d'une table Cef spcifiques, indpendantes des autres Vrf et de la table de
routage globale. Chaque Vrf est dsigne par un nom (par ex. RED, GREEN, etc.) sur les routeurs Pe. Les
noms sont affects localement et n'ont aucune signification vis--vis des autres routeurs.
Chaque interface de Pe, relie un site client, est rattache une Vrf particulire. Lors de la rception de
paquets Ip sur une interface client, le routeur Pe procde un examen de la table de routage de la Vrf
laquelle est rattache l'interface et donc ne consulte pas sa table de routage globale. Cette possibilit
d'utiliser plusieurs tables de routage indpendantes permet de grer un plan d'adressage par sites, mme en
cas de recouvrement d'adresses entre Vpn diffrents.
3.5.3 - Scurit
La sparation des flux entre clients sur des routeurs mutualiss supportant Mpls est assure par le fait que
seul la dcouverte du rseau se fait au niveau de la couche 3 et qu'ensuite le routage des paquets est
effectu en s'appuyant uniquement sur le mcanisme des labels (intermdiaire entre la couche 2 et la couche
3).
Le
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.
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.
4 - Comparaison des diffrents protocoles

Chaque protocole prsent permet de raliser des solutions performantes de Vpn. Nous allons ici aborder les points
forts et les points faibles de chacun de ses protocoles.
4.1 - Vpn-Ssl, une nouveaut marketing ?
Prsente comme la solution miracle pour permettre aux itinrants de se connecter aux applications rparties de
l'entreprise les Vpn-Ssl souffrent de problmes principalement lis aux navigateurs web utiliss.
Le but d'utiliser des navigateurs web est de permettre aux utilisateurs d'utiliser un outil dont ils ont l'habitude et
qui ne ncessite pas de configuration supplmentaire. Cependant lorsqu'un certificat expire l'utilisateur doit aller
manuellement le renouveler. Cette opration peut poser problme aux utilisateurs novices. De plus sur la majorit
des navigateurs web la consultation des listes de certificats rvoqus n'est pas active par dfaut : toute la
scurit
de
Ssl
reposant
sur
ces
certificats
ceci
pose
un
grave
problme
de
scurit.
Rien n'empche de plus le client de tlcharger une version modifie de son navigateur pour pouvoir utiliser de
nouvelles fonctionnalits (skins, plugins...). Rien ne certifie que le navigateur n'a pas t modifi et que son
autorit
de
certification
en
soit
bien
une.
Enfin Un autre problme li l'utilisation de navigateurs web comme base au Vpn est leur spcificit au monde
web. En effet par dfaut un navigateur n'interceptera que des communication Https ou ventuellement Ftps.
Toutes les communications venant d'autre type d'applications (MS Outlook, ou une base de donnes par exemple)
ne sont pas supportes. Ce problme est gnralement contourn par l'excution d'une applet Java ddie dans le
navigateur. Mais ceci implique galement la maintenance de cette applet (s'assurer que le client possde la bonne
version,
qu'il
peut
la
re-tlcharger
au
besoin)
L'ide suivant laquelle le navigateur web est une plate-forme idale pour raliser des accs Vpn est donc
srieusement nuancer.
4.2 - Pptp
Pptp prsente l'avantage d'tre compltement intgr dans les environnements Windows. Ceci signifie en
particulier que l'accs au rseau local distant pourra se faire via le systme d'authentification de Windows NT :
RADIUS et sa gestion de droits et de groupe. Cependant comme beaucoup de produit Microsoft la scurit est le
point faible du produit :
Mauvaise gestion des mots de passe dans les environnements mixtes win 95/NT
Faiblesses dans la gnration des cls de session : ralis partir d'un hachage du mot de passe au lieu
d'tre entirement gnres au hasard. (facilite les attaques force brute )
Faiblesses cryptographiques du protocole MsCHAP 1 corriges dans la version 2 mais aucun contrle sur
cette version n'a t effectu par une entit indpendante.
Identification des paquets non implmente : vulnrabilit aux attaques de type spoofing
4.3 - L2tp / Ipsec
Les mcanismes de scurit mis en place dans Ipsec sont plus robustes et plus reconnus que ceux mis en place
par Microsoft dans Pptp. Par dfaut le protocole L2tp utilise le protocole Ipsec. Cependant si le serveur distant ne
le supporte pas L2tp pourra utiliser un autre protocole de scurit. Il convient donc de s'assurer que l'ensemble
des
quipements
d'un
Vpn
L2tp
implmente
bien
le
protocole
Ipsec.
Ipsec ne permet d'identifier que des machines et non pas des utilisateurs. Ceci est particulirement problmatique
pour les utilisateurs itinrants. Il faut donc prvoir un service d'authentification des utilisateurs. Dans le cas de
connexion dial-up c'est l'identifiant de connexion qui sera utilis pour authentifier l'utilisateur. Mais dans le cas de
connexion via Internet il faudra prvoir une phase d'authentification supplmentaire l'tablissement du tunnel.
D'autre part Ipsec n'offre aucun mcanisme de Qos Ce qui limite ses applications : toutes les applications de voix
sur Ip ou de vido sur Ip sont impossibles ou seront amenes tre compltement dpendantes des conditions de
traffic
sur
l'internet
public.
Enfin Ipsec cause de la lourdeur des oprations de cryptage/dcryptage rduit les performances globales des
rseaux. L'achat de priphriques ddis, coteux est souvent indispensable.
4.4 - Mpls
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
Permet d'attribuer des priorits au trafic par le

biais de classes de service
Le transfert se faisant sur l'Internet public,

permet seulement un service "best effort"
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
Comparable la scurit offerte par les rseaux

Atm et Frame Relay existants.
Scurit totale grce la combinaison de

certificats numriques et de Pki pour
l'authentification ainsi qu' une srie d'options
de cryptage, triple DES et AES notamment
Applications
compatibles
Toutes les applications, y compris les logiciels

d'entreprise vitaux exigeant une qualit de
service leve et une faible latence et les
applications en temps rel (vido et voix sur IP)
Accs distance et nomade scuris.

Applications sous IP, notamment courrier
lectronique et Internet. Inadapt au trafic en
temps rel ou priorit leve
Etendue
Dpend du rseau Mpls du fournisseur de

services
Trs vaste puisque repose sur l'accs

Internet
Evolutivit
Evolutivit leve puisque n'exige pas une

interconnexion d'gal gal entre les sites et que
les dploiements standard peuvent prendre en
charge plusieurs dizaines de milliers de
connexions par Vpn
Les dploiements les plus vastes exigent une

planification soigneuse pour rpondre
notamment aux problmes d'interconnexion
site site et de peering
Frais de gestion
du rseau
Aucun traitement exig par le routage
Traitements supplmentaires pour le cryptage

et le dcryptage
Vitesse de
dploiement
Le fournisseur de services doit dployer un

routeur Mpls en bordure de rseau pour
permettre l&148;accs client
Possibilit d'utiliser l'infrastructure du rseau Ip

existant
Prise en charge
par le client
Non requise. Le Mpls est une technologie rseau
Logiciels ou matriels client requis
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
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.
2 - Les services offerts par IPsec

2.1 - Les deux modes d'change IPsec
Une communication entre deux htes, protge par IPsec, est susceptible de fonctionner suivant deux modes
diffrents : le mode transport et le mode tunnel. Le premier offre essentiellement une protection aux protocoles
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 :
adresse ou groupe d'adresses IP de destination

adresse ou groupe d'adresses IP source
nom du systme (DNS complte, nom X.500 distingu ou gnral)
protocole de transport utilis (typiquement, TCP ou UDP)
nom d'utilisateur complet, comme foo@bar.net (ce paramtre n'est toutefois pas obligatoire sur certains
types d'implmentations)
importance des donnes (ce paramtre n'est toutefois pas obligatoire sur certains types d'implmentations)
ports source et destination (UDP et TCP seulement, le support de ce paramtre est facultatif)
Certains paramtres peuvent tre illisibles cause d'un ventuel chiffrement ESP au moment o ils sont traits,
auquel cas la valeur de la SPD les concernant peut le prciser, il s'agit de :
l'identit de l'utilisateur
le protocole de transport
les ports source et destination
Il est donc possible de spcifier une politique de scurit relativement fine et dtaille. Cependant, une politique
commune pour le trafic vers un ensemble de systmes permet une meilleure protection contre l'analyse de trafic
qu'une politique extrmement dtaille, comprenant de nombreux paramtres propres chaque systme
particulier. Enfin, si l'implmentation permet aux applications de prciser elles-mmes quelle partie du trafic
appliquer IPsec et comment, l'administrateur doit pouvoir les empcher de contourner la politique par dfaut.
3.2 - Architectures supportes
Le protocole IPsec permet thoriquement n'importe quelle combinaison, en un nombre quasiment illimit de
niveaux d'encapsulation, c'est--dire d'accumulations de SA. Nanmoins, les implmentations ne sont pas tenues
d'offrir une telle flexibilit. Les architectures qu'une application conforme la Rfc 2401 doivent supporter, au
nombre de quatre, sont dcrites ci-dessous.
3.2.1 - Dialogue entre deux htes protgeant le trafic eux-mmes
Deux htes engagent une communication IPsec, en encapsulant le protocole de haut niveau dans :
en mode transport :
des datagrammes AH
des datagrammes ESP
ou des datagrammes ESP encapsuls dans des datagrammes AH
en mode tunnel :
des datagrammes AH
ou des datagrammes ESP
3.2.2 - Dialogue entre deux LANs l'aide de passerelles de scurit
Ici, deux passerelles de scurit grent les conversations entre les htes de deux LANs diffrents, IPsec
s'appliquant de manire transparente pour les htes. Les deux passerelles de scurit changent des
datagrammes en mode tunnel, l'aide de AH ou ESP (aprs routage, ceci correspond simplement la
deuxime partie du cas prcdent), puis transmettent les datagrammes obtenus aprs traitement IPsec aux
htes destinataires. Ainsi, les datagrammes IP mis par un systme de l'un des deux LANs sont encapsuls
dans d'autres datagrammes IP+IPsec par la passerelle du "LAN metteur", encapsulation supprime par la
passerelle du "LAN rcepteur" pour obtenir de nouveau les datagrammes IP originaux.
3.2.3 - Dialogue entre deux htes traversant deux passerelles de scurit

Le troisime cas n'ajoute pas vraiment de prrequis sur les implmentations IPsec. Ainsi, une passerelle de
scurit doit avoir la capacit de transmettre dans un tunnel IPsec du trafic dj scuris par IPsec. Cel
autorise les dialogues IPsec entre deux htes situs eux-mmes dans des LANs relis par des passerelles de
scurit.
3.2.4 - Dialogue entre un hte et une passerelle de scurit
Le dernier cas est celui d'un hte externe se connectant un LAN protg par une passerelle de scurit. Les
documentations techniques dsignent souvent un tel hte sous le nom de road warrior. Il engage une
conversation IPsec avec un systme du LAN en mode transport, le tout encapsul dans un tunnel IPsec tabli
entre le road warrior lui-mme et la passerelle de scurit. Dans ce cas, les datagrammes du tunnel sont de
type AH ou ESP et les datagrammes utiliss en mode transport doivent pouvoir tre de type AH, ESP, ou ESP
encapsul dans AH.
4 - Gestion des clefs

Les services de protection offerts par IPsec s'appuient sur des algorithmes cryptographiques, et reposent donc sur des
clefs. Si celles-ci sont grables manuellement dans le cas o peu d'htes seront amens engager des conversations
IPsec, ceci devient un vritable cauchemar quand le systme commence prendre un peu d'extension (le nombre de
couples de clefs augmentant de manire quadratique avec le nombre de systmes). C'est pourquoi la spcification
IPsec propose galement des procds d'change automatique de clefs, dont les aspects les plus importants sont ici
voqus. Une prsentation complte de cette procdure dpasse toutefois le cadre de cet article. La Rfc 2401 prcise
qu'une implmentation IPsec est tenue de supporter la gestion manuelle de clefs et la mthode d'change automatique
de clefs IKE, bien que d'autres algorithmes existent. Un point important est que la gestion de clefs automatique est
considre
comme
plus
sre
que
la
gestion
manuelle.
Le protocole IKE (internet key exchange) est dcrit par la Rfc 2409. Il permet l'change de clefs entre deux htes
d'adresses IP connues pralablement ou inconnues selon le mode d'change de clefs slectionn. Parmi ses avantages
figure le mode agressif (cette caractristique n'est pas obligatoire), qui permet d'acclrer la ngociation, au prix de la
protection d'identit. L'identit est toutefois protge dans le cas d'une ngociation IKE authentifie l'aide de
signatures
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.
5 - La compression des en-ttes

La Rfc 3095 dcrit un protocole de compression d'en-ttes pouvant s'appliquer RTP, UDP, et ESP sur IP. La
compression des donnes elles-mmes n'est malheureusement pas couverte par cette spcification, il n'est donc pas
prvu, l'heure actuelle, de les compresser. En revanche, il est conu pour s'accommoder des taux d'erreurs de
transmission importants des communications par voie hertzienne. Enfin, la compression dcrite s'appuie sur une
couche de liens garantissant la transmission des donnes dans leur ordre d'mission et sans duplication, ce qui peut
rendre dangereuse son utilisation sur certains rseaux. Enfin, la couche de liens doit permettre la ngociation des
paramtres ROHC (robust header compression), cette ngociation peut cependant se faire priori ou en s'appuyant sur
d'autres protocoles.
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
7 - Quelques implmentations actuelles

Cette partie donne un aperu des capacits de quelques OS populaires en matire de support IPsec. Les informations
fournies constituent une synthse des sites des OS, des diteurs et des FAQs des logiciels concerns : de plus amples
dtails sont donc disponibles sur ces sites.
7.1 - Windows
Windows XP et 2000 incluent un support du mode transport d'IPsec et de l'change de clefs l'aide de certificats
en natif. Il existe de trs nombreux logiciels permettant de crer des VPN sous Windows, y compris un serveur
VPN en option sous Windows 2000 et XP, capable de mettre en place des tunnels IPsec/L2TP. D'autre part,
Windows 95, 98 et NT 4 disposent d'une grande quantit d'implmentations IPsec commerciales et peu prs
toutes les versions de Windows depuis 95 sont capables de crer des tunnels PPTP. Une solution intressante est
galement propose par SSH Communications Security. Leur implmentation est l'heure actuelle l'une des rares
supporter IPsec NAT-Traversal. Le client est disponible pour les versions 95, 98, Me, NT 4, 2000 et XP de
Windows.
7.2 - Linux
L'implmentation IPsec la plus utilise sous Linux est sous licence GPL, il s'agit de FreeS/WAN. La partie kernel de
cette implmentation s'appelle KLIPS. Sont notamment supports :
l'change dynamique de clefs IKE l'aide du logiciel pluto, qui permet l'utilisation de clefs pr-partages
aussi bien que de certificats
la protection des connexions d'un road warrior un LAN, mme si son adresse IP est attribue
dynamiquement et est susceptible de changer
la cration de tunnels PPTP (ct serveur), grce au logiciel PoPToP
la cration de tunnels PPTP (ct client), grce au logiciel PPTP-linux
la cration de tunnels L2TP, grce au logiciel l2tpd
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 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
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).
Architecture L2TP - Layer 2 Tunneling Protocol
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.4 - Les tapes
4.5 - Scurit
5 - Le protocole L2TP
5.1 - Introduction
6-
789-

5.3 - Les concentrateurs d'accs - LAC
5.4 - Les serveurs rseau - LNS
5.5 - Avantages et inconvnients
L'architecture PPP - L2TP
6.1 - Architecture IP
6.2 - Les encapsulations
6.3 - Les tailles maximums de l'OverHead
6.4 - Problmatique lie au MTU
Conclusion
Suivi du document
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.
2.4 - Statut de PPP over Ethernet

Depuis son dveloppement initial, PPPoE a t soumis en Aot 1998 l'IETF (Internet Engineering Task Force)
comme Internet Draft. Une session BOF (Birds Of a Feather) a abouti la mise jour de l'Internet Draft initial.
Les socits qui ont particip l'laboration de PPPoE (RedBack Networks, UUNET, Routerware) ont demand
l'IETF d'inclure PPPoE dans les RFC (Request for Comment), proposition qui a t retenue et qui fait rfrence
la RFC 2516.
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.
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.
Flag - Indicateur de dbut ou fin de trame (Valeur = 01111110).

Adresse - Adresse de broadcast standard (Valeur = 11111111), car PPP n'attribue pas d'adresse d'hte
(Couche 2).
Contrle - Fourniture d'un service non orient connexion (semblable au LLC) (Valeur = 00000011).
Protocole - Identification du protocole encapsul (LCP=Cxxx, NCP=8xxx,Protocole de niveau 3=0xxx).
Code
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:
3.4 - LCP - Link Control Protocol

LCP transporte les paquets permettant d'tablir, de maintenir et de terminer PPP. Pour l'tablissement de PPP, il
faut ngocier de paramtres de fonctionnement. LCP gre les options PPP indpendantes des protocoles de la
couche rseau. Les premiers paquets envoys par les extrmits PPP ngocient les options configurables au dbut
d'une connexion. Il existe trois classes de paquets LCP :
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 :
Code - Le champ Code comporte un octet, et identifie le type de paquet LCP.

Valeur
Nom
Signification
Configure-Request
Dpart de la connexion, dfinie et ngocie la configuration
Configure-Ack
Accus de la rception d'un Configure-Request
Configure-Nak
Rponse ngative la rception d'un Configure-Request
Configure-Reject
Options de configurations non reconnaissables
Terminate-Request
Fermeture de la connexion
Terminate-Ack
Accus de la rception d'un Terminate-Request
Code-Reject
Code reu inconnu
Identificateur - Le champ Identificateur comporte un octet, et fournit un moyen d'associer requtes et

rponses. Lorsqu'un paquet prsente un Identificateur invalide, il est ignor sans affecter l'automate.
Longueur - Le champ Longueur comporte deux octets, et donne la longueur du paquet LCP, y compris
l'octet de Code, d'Identificateur, le champ Longueur lui-mme et le champ Donnes. La longueur ne doit
pas excder l'U R M de la liaison.
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.
Options de LCP pour PPPoE:
Recommand : numro magique, MRU (<=1492 Octets).
Non recommand : Compression des champs (PFC).
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
Code - Le champ Code comporte un octet, et identifie le type de paquet NCP.

Valeur
Nom
Signification
Configure-Request
Dpart de la connexion, dfinie et ngocie la configuration
Configure-Ack
Accus de la rception d'un Configure-Request
Configure-Nak
Rponse ngative la rception d'un Configure-Request
Configure-Reject
Options de configurations non reconnaissables
Terminate-Request
Fermeture de la connexion
Terminate-Ack
Accus de la rception d'un Terminate-Request
Code-Reject
Code reue inconnue
Protocol-Reject
Rception avec une valeur de protocole inconnu
Echo-Request
Loopback pour la dtermination de la qualit du lien
10
Echo-Reply
Rponse au Echo-Request
11
Discard-Request
Ignore la requte reue
Identificateur - Le champ Identificateur comporte un octet, et fournit un moyen d'associer requtes et

rponses. Lorsqu'un paquet prsente un Identificateur invalide, il est ignor sans affecter l'automate.
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.
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.
Le paquet de dcouverte Initialisation (PADI)

Les htes envoient le paquet PADI (PPPoE Active Discovery Initition) en plaant l'adresse de diffusion dans le
champ Adresse de destination . Le champ Code contient 0x09 et le champ Identificateur de session
contient 0x0000. Le paquet PADI doit contenir un TAG de type Nom du service indiquant le service que
l'hte demande ainsi qu'un nombre quelconque de TAGs d'autres types. Un paquet PADI entier (incluant l'entte PPPoE) ne doit pas dpasser 1484 octets afin de laisser la place suffisante pour qu'un agent relais
puissent
ajouter
un
TAG
Identificateur
de
session
relais
.
Le paquet de dcouverte Offre (PADO)

Quand le concentrateur d'accs reoit un PADI qu'il peut servir, il rpond en envoyant un paquet PADO
(PPPoE Active Discovery Offer). L'adresse de destination est l'adresse de l'hte telle qu'envoye dans le PADI.
Le champ Code est fix 0x07 et le champ Identificateur de session 0x0000. Le paquet PADO doit
contenir exactement un TAG Concentrateur d'accs-Nom contenant le nom du concentrateur d'accs, un
TAG Nom du service identique celui contenu dans le PADI et un nombre quelconque d'autres TAGs
Nom du service indiquant les autres services offerts par le concentrateur d'accs. Si le concentrateur
d'accs
ne
peut
pas
servir
le
PADI,
il
ne
doit
pas
rpondre
avec
un
PADO.
Le paquet de dcouverte Requte (PADR)

Puisque le PADI a t envoy en diffusion, l'hte peut recevoir plusieurs PADO. L'hte examine les paquets
PADO reus et en choisit un. Le choix peut tre bas sur le nom du concentrateur d'accs ou sur les services
offerts. L'hte envoie alors un paquet PADR (PPPoE Active Discovery Request) au concentrateur d'accs
slectionn. Le champ Adresse de destination est l'adresse Ethernet du concentrateur d'accs qui a t
envoye par le PADO. Le champ Code contient 0x19 et le champ Identificateur de session la valeur
0x0000. Le paquet PADR doit contenir exactement un TAG de type Nom du service indiquant le nom du
service
que
l'hte
a
demand
et
un
nombre
quelconque
de
TAGs
d'autres
types.
Le paquet de dcouverte Confirmation de session (PADS)

Quand le concentrateur d'accs reoit un paquet PADR, il se prpare commencer une session PPP. Il gnre
un identificateur de session unique pour la session PPPoE et rpond l'hte avec un paquet PADS (PPPoE
Active Discovery Session-confirmation). Le champ Adresse de destination est l'adresse Ethernet de l'hte
qui a envoy le PADR. Le champ Code contient 0x65 et le champ Identificateur de session doit tre
mis la valeur unique gnre pour cette session PPPOE. Le paquet PADS contient exactement un TAG de
type Nom du service indiquant le nom du service sous lequel le concentrateur d'accs a accept la
session PPPoE et un nombre quelconque de TAGs d'autres types. Si le concentrateur d'accs n'accepte pas le
service propos dans le PADR, il doit rpondre avec un PADS contenant un TAG de type Nom du serviceErreur . (et un nombre quelconque de TAGs d'autres types). Dans ce cas le champ Identificateur de
session
doit
contenir
0x0000.
Le paquet de dcouverte Terminaison (PADT)

Ce paquet peut tre envoy n'importe quel moment aprs qu'une session ait t tablie pour indiquer que
la session PPPoE est termine. Il peut tre envoy soit par l'hte, soit par le concentrateur d'accs. Le champ
Adresse de destination est une adresse Ethernet fixe, le champ Code contient 0xa7 et le champ
Identificateur de session doit indiquer quelle session se termine. Aucun TAG n'est ncessaire. Quand un
paquet PADT (PPPoE Active Discovery Terminate) est reu, aucun autre trafic PPP utilisant cette session ne
peut tre envoy. Mme les paquets normalement utiliss pour terminer une session PPP ne doivent pas tre
envoys aprs rception d'un PADT. Une extrmit PPP devrait utiliser le protocole PPP lui-mme pour arrter
une session PPPoE, mais le paquet PADT peut tre utilis quand PPP ne le peut pas.
4.4.2 - Session PPP

Une fois que la session PPPoE est ouverte, les donnes PPP sont envoyes comme dans n'importe quelle
autre encapsulation PPP. Tous les paquets Ethernet contiennent une adresse fixe. Le champ Type Ethernet
vaut 0x8864. Le champ Code de PPPoE doit contenir 0x00. Le champ Identificateur de session ne
doit pas changer pour cette session PPPoE et doit tre la mme valeur que celle assigne lors de l'tape de
dcouverte. La charge utile PPPoE contient une trame PPP. La trame commence avec l'identificateur de
protocole
de
PPP.
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.
T - 1 bit indiquant le type de message. 0 si c'est un message de donnes, 1 si c'est un message de

contrle.
L - 1 bit qui positionn 1, indique la prsence du champ longueur. Ce bit doit tre mis 1 dans les
messages de contrle.
0 - 2 bits rservs pour des extensions futures. Pour l'instant ces bits sont mis 0 et ignors.
S - 1 bit qui positionn 1 indique la prsence des champs Ns et Nr. Ce bit doit tre 1 dans les messages
de contrle.
0 - 1 bit rserv pour des extensions futures. Pour l'instant ce bit est mis 0 et ignor.
O - 1 bit qui positionn 1, indique la prsence du champ Offset Size. Ce bit doit tre 0 pour les
messages de contrle.
P - 1 bit qui positionn 1, considre ce message comme prioritaire. Exemple : messages LCP echo
request utiliss par les extrmits PPP pour le maintien de la session PPP.
0 - 4 bits rservs pour des extensions futures. Pour l'instant ces bits sont mis 0 et ignors.
Version - 4 bits indique la version du tunnel employ. Il doit tre 2 pour le L2TP RFC 2661. La valeur 1
reprsenterait un paquets L2F.
Longueur - 16 bits. Ce champ est optionnel et reprsente la longueur totale du message en octet. Ce
champ n'existe que si le flag L est positionn 1.
Tunnel ID - 16 bits reprsentant l'identifiant du tunnel, qui a une signification locale. Le Tunnel ID d'un
message est celui du destinataire.
Session ID - 16 bits reprsentant l'identification pour une session dans un tunnel. La signification est
galement purement locale. La session ID d'un message est celui du destinataire.
Ns - 16 bits correspondant au numro de squence pour ce message.
Nr - 16 bits correspondant au numro de squence attendu lors de la rception du prochain message.
Offset Size - 16 bits reprsentant la longueur de la fin de l'entte L2TP.
5.3 - Les concentrateurs d'accs - LAC
Les concentrateurs d'accs L2TP, signifiant L2TP Access Concentrateur (LAC), peuvent tre intgrs la structure
d'un rseau commut comme le rseau tlphonique commut (RTC) ou encore associs un systme
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.
6 - L'architecture PPP - L2TP

6.1 - Architecture IP
Voici
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
6.2.1 - Cas de PPPoE
6.2.1 - Cas de L2TP
6.3 - Les tailles maximums de l'OverHead

6.3.1 - Cas de PPP
OverHead
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 %
6.3.2 - Cas de PPPoE

OverHead
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 :
Pourcentage relatif
70
20 %
1300
1,1 %
1500
0,9 %
6.3.2 - Cas de L2TP

OverHead
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 :
Pourcentage relatif
70
60 %
1300
3,2 %
1500
2,8 %
6.4 - Problmatique lie au MTU

Si l'infrastructure de l'oprateur est base sur Ethernet, alors un Overhead de 42 octets demande une gestion de
trame Ethernet de 1518+42 soit 1560 octets pour ne pas fragmenter. Je ne compte pas en plus si cette
infrastructure Ethernet gre les VLAN. L'utilisation de la VOIP devient dans ce cadre assez difficile matriser.
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.
2 - MPLS: Objectifs et Missions

L'un des objectifs initiaux tait d'accrotre la vitesse du traitement des datagrammes dans l'ensemble des quipements
intermdiaires. Cette volont, avec l'introduction des gigarouteurs, est dsormais passe au second plan. Depuis,
l'aspect "fonctionnalit" a largement pris le dessus sur l'aspect "performance", avec notamment les motivations
suivantes :
Intgration IP/ATM
Cration de VPN
Flexibilit : possibilit d'utiliser plusieurs types de media (ATM, FR, Ethernet, PPP, SDH).
Differential Services (DiffServ)
Routage multicast
MPLS pourra assurer une transition facile vers l'Internet optique. MPLS n'tant pas li une technique de niveau
2 particulire, il peut tre dploy sur des infrastructures htrognes (Ethernet, ATM, SDH, etc.). Avec la prise
en charge de la gestion de contraintes molles et dures sur la qualit de service (DiffServ, Cisco Guaranteed
Bandwidth). Avec la possibilit d'utiliser simultanment plusieurs protocoles de contrle, MPLS peut faciliter
l'utilisation de rseaux optiques en fonctionnant directement sur WDM.
Traffic Engineering permettant de dfinir des chemins de routage explicites dans les rseaux IP (avec RSVP ou
CR-LDP). L'ingnierie des flux est la facult de pouvoir grer les flux de donnes transports au dessus d'une
infrastructure rseau. Aujourd'hui, cette ingnierie des flux est essentiellement faite l'aide d'ATM, avec comme
consquence une grande complexit de gestion (en effet IP et ATM sont deux techniques rseaux totalement
diffrentes, avec parfois des contraintes non compatibles). Avec l'intgration de cette fonctionnalit, MPLS va
permettre une simplification radicale des rseaux.
Les labels peuvent tre associs un chemin, une destination, une source, une application, un critre de qualit de
service, etc. ou une combinaison de ces diffrents lments. Autrement dit, le routage IP est considrablement enrichi
sans pour autant voir ses performances dgrades ( partir du moment ou un datagrame est encapsul, il est
achemin en utilisant les mcanismes de commutation de niveau 2). On peut imaginer qu'un des services les plus
importants sera la possibilit de crer des rseaux privs virtuels (VPN) de niveau 3. Ainsi, des services de voix sur IP,
de multicast ou d'hbergement de serveurs web pourront coexister sur une mme infrastructure. La modularit de
MPLS et la granularit des labels permettent tous les niveaux d'abstraction envisageables.
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.
7 - Implicit Routing (LDP)
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.
LDP supporte les spcifications suivantes :

les labels sont assigns un noeud amont partir des informations contenues dans la table de routage:
3 FEC (Forwarding Equivalent Classes) sont dfinies : il est possible de mapper un label soit un flux de trafic,
un prfixe d'adresse IP ou un router-ID. Le flux de trafic reoit le mme traitement de forwarding selon le
label qui lui est associ.
une connexion LDP peut tre tablie entre 2 LSR directement ou indirectement connects
il existe 2 modes de rtention de label : soit " conservatif " soit " libral ". Pour le mode de rtention "
conservatif " , seul le label correspondant au meilleur bond est retenu. Par contre, pour le mode de rtention "
libral ", tous les labels transmis par les LSR adjacents pour un flux donn sont retenus. Ce mode permet un
reroutage rapide en cas de problme car des labels alternatifs sont disponibles instantanment.
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
Les fonctions supportes par ER-LDP sont :

ER-LSP de bout en bout
strict/loose explicit routing : dans un LSP rout de manire " stricte ", chaque bond est spcifi. Une section du
LSP peut tre route de manire " imprcise " lorsque sont introduits 2 LSR non directement connects.
spcification d'une classe de service
rservation de bande passante
route pinning : dans une section de ER-LSP route de manire " imprcise ", les bonds sont slectionns selon
une transmission bond par bond
ER-LSP preemption : tablissement/maintien de priorit
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
au niveau du VBG source : exportation vers BGP

entre VBG source et VBG destination : via BGP
au niveau du VBG destination : importation partir de BGP
du VBG destination vers le site client : 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.
Implmentation Mpls avec Cisco
1 - Introduction
2 - Matriel et configurations utiliss
3 - Principes gnraux - Terminologie

3.1 - Rseau de dmonstration
3.2 - Commutation par labels
3.3 - Classification des paquets
3.4 - Mode trame et mode cellule
3.5 - Distribution des labels (TDP / LDP)
3.6 - Tables MPLS: TIB et TFIB
3.6.1 - Rle de la TIB (Tag Information Base)
3.6.2 - Rle de la TFIB (Tag Forwarding Information Base)
3.7 - Penultimate Hop Popping
3.8 - Rtention des labels
3.9 - MPLS sur ATM
3.10 - Pile de labels (label stacking)
3.11 - Description de l'entte MPLS
3.12 - Configuration d'un routeur LSR
3.12.1 - Configuration de CEF
3.12.2 - Configuration d'un IGP
3.12.3 - Configuration de TDP / LDP
4 - Virtual Private Networks (VPN)
4.2 - Routeurs P, PE et CE
4.3 - Routeurs virtuels : VRF
4.4 - Multiprotocol BGP (MP-BGP)
4.4.1 - Notion de RD (Route Distinguisher)
4.4.2 - Notion de RT (Route Target)
4.4.3 - Configuration d'une VRF
4.4.4 - Updates MP-BGP
4.4.5 - Configuration MP-BGP d'un PE
4.4.6 - Vrification du fonctionnement de MP-BGP
4.5 - Echange des routes avec les CE
4.5.1 - Configuration eBGP
4.5.2 - Configuration RIPv2
4.6 - Transmission des paquets IP
4.7 - Accs Internet
4.7.1 - Route par dfaut statique (Static Default Route)
4.7.2 - Route par dfaut dynamique (Dynamic Default Route)
4.7.3 - Routage optimal (Optimum Routing)
4.8 - Signalisation Inter-AS (MP-eBGP)
5 - Traffic Engineering (TE)
5.1 - Introduction
5.2 - Types de tunnels
5.3 - Critres de bande passante
5.4 - Etablissement d'un tunnel
5.5 - Roptimisation
5.6 - Configuration IOS
5.6.1 - Activation globale de Traffic Engineering
5.6.2 - Configuration de l'IGP
5.6.3 - Configurations des interfaces
5.6.4 - Cration d'un tunnel explicite
5.6.5 - Cration d'un tunnel dynamique
5.7 - Utilisation avec MPLS/VPN
6 - Conclusion
7 - Annexe I: Configurations MPLS simples
8 - Annexe II: Configurations MPLS/VPN
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.
2 - Matriel et configurations utiliss

Afin d'tayer d'exemples pratiques les diffrents principes de MPLS abords dans ce document, deux pods
(nomms L10 et L20) composs de 7 routeurs chacun ont t utiliss. Ces routeurs sont relis au moyen de liaisons
srie,
de
la
manire
suivante
:
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
La version de Cisco IOS tournant sur les routeurs est la 12.2(0.4).
3 - Principes gnraux - Terminologie

Pour cette partie, seul le pod L10 a t utilis. Le schma suivant rsume les diffrents subnets et adresses IP
configurs
sur
les
routeurs
:
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
;
;
3.2 - Commutation par labels

Comme il l'a t brivement expliqu en introduction, le principe de base de MPLS est la commutation de labels.
Ces labels, simples nombres entiers, sont insrs entre les enttes de niveaux 2 et 3, les routeurs permutant ces
labels tout au long du rseau jusqu' destination, sans avoir besoin de consulter l'entte IP et leur table de
routage. Cette technique, appele Label Swapping, est similaire la commutation de cellules sur ATM avec les
informations de VPI/VCI ou la commutation sur rseau Frame Relay avec les DLCI. Toutefois, MPLS permet de
dfinir des piles de labels (label stack), dont l'intrt apparatra avec le TE et les VPN. Les routeurs ralisant les
oprations
de
label
swapping
sont
appels
LSR
pour
Label
Switch
Routers.
Le
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:
3.3 - Classification des paquets

A l'entre du rseau MPLS, les paquets IP sont classs dans des FEC (Forwarding Equivalent Classes). Des
paquets appartenant une mme FEC suivront le mme chemin et auront la mme mthode de forwarding.
Typiquement, les FEC sont des prfixes IP appris par l'IGP tournant sur le backbone MPLS, mais peuvent aussi
tre dfinies par des informations de QoS ou de TE. La classification des paquets s'effectue l'entre du backbone
MPLS, par les Ingress LSR. A l'intrieur du backbone MPLS, les paquets sont label-switchs, et aucune
reclassification des paquets n'a lieu. Chaque LSR affecte un label local, qui sera utilis en entre, pour chacune de
ses FEC et le propage ses voisins. Les LSR voisins sont appris grce l'IGP. L'ensemble des LSR utiliss pour
une FEC, constituant un chemin travers le rseau, est appel Label Switch Path (LSP). Il existe un LSP pour
chaque FEC et les LSP sont unidirectionnels.
3.4 - Mode trame et mode cellule
Il existe deux catgories d'interfaces MPLS sur les routeurs, dpendant de leur mode de fonctionnement. Le
premier mode, appel mode trame (framed mode), correspond aux interfaces traitant des paquets de taille
variable, comme par exemple Ethernet, Frame-Relay, PPP, etc. Le second mode concerne les interfaces ATM et est
appel mode cellule (cell mode), la commutation tant base sur la notion de circuit. Sur ATM, les circuits virtuels
sont dfinis par les champs VPI/VCI de l'entte des cellules. Suivant le mode de fonctionnement d'une interface,
les mthodes de propagation des labels aux routeurs voisins diffrent.
3.5 - Distribution des labels (TDP / LDP)
Les LSR se basent sur l'information de label pour commuter les paquets au travers du backbone MPLS. Chaque
routeur, lorsqu'il reoit un paquet taggu, utilise le label pour dterminer l'interface et le label de sortie. Il est
donc ncessaire de propager les informations sur ces labels tous les LSR. Pour cela, des protocoles de
distributions de labels sont utiliss. Suivant le type des FEC, diffrents protocoles sont employs pour l'change de
labels
entre
LSR:
TDP/LDP
(Tag/Label
Distribution
Protocol):
Mapping
des
adresses
IP
unicast
;
- RSVP (Resource Reservation Protocol): utilis en Traffic Engineering pour tablir des LSP en fonction de
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
TDP Id: 10.10.2.2:0

Chaque voisin doit tre marqu xmit/recv (mission / rception) pour que l'change des labels puisse avoir
lieu.
3.6 - Tables MPLS: TIB et TFIB
A partir des informations apprises par TDP / LDP, les LSR construisent deux tables, la TIB et la TFIB. De manire
gnrale, la TIB contient tous les labels appris des LSR voisins, tandis que la TFIB, utilise pour la commutation
proprement dite des paquets, est un sous-ensemble de la TIB.
3.6.1 - Rle de la TIB (Tag Information Base)
La premire table construite par le routeur MPLS est la table TIB (Tag Information Base). Elle contient pour
chaque subnet IP la liste des labels affects par les LSR voisins. Il est possible de connatre les labels affects
un subnet par chaque LSR voisin en utilisant la commande "show tag tdp bindings". Un exemple de rsultat
de cette commande est donn ci-dessous:
L10-R1# sh tag tdp bind 10.10.4.4 255.255.255.255
tib entry: 10.10.4.4/32, rev 31
local binding: tag: 24
remote binding: tsr: 10.10.3.3:0, tag: 20
On remarque que le routeur a affect le label local 24 pour atteindre le rseau 10.10.4.4/32, et que les
routeurs L10-R2 (10.10.2.2) et L10-R3 (10.10.3.3) ont respectivement affect les label 21 et 20 pour
atteindre le subnet 10.10.4.4/32. Il est noter qu'IOS emploie le terme TSR pour Tag Switch Router , qui
est quivalent celui de LSR. Pour les interfaces ATM (fonctionnant en mode cellule), la commande utiliser
est show tag atm-tdp bindings :
ATM-LSR# show tag-switching atm-tdp bindings
Destination: 193.12.161.1/32
Tailend Switch XTagATM162 241/33 Active -> Terminating Active, VCD=2
Destination: 194.16.16.4/32
Transit XTagATM161 240/91 Active -> XTagATM162 241/276 Active
Les labels entre ATM LSR sont changs au moyen d'un VC de contrle MPLS, par dfaut configur sur
VPI/VCI = 0/32.
3.6.2 - Rle de la TFIB (Tag Forwarding Information Base)
A partir de la table TIB et de la table de routage IP, le routeur construit une table TFIB, qui sera utilise pour
commuter les paquets. Chaque rseau IP est appris par l'IGP, qui dtermine le prochain saut ("next-hop")
pour atteindre ce rseau. Le LSR choisit ainsi l'entre de la table TIB qui correspond au rseau IP et
slectionne comme label de sortie le label annonc par le voisin dtermin par l'IGP (plus court chemin). Il
est possible d'afficher le contenu de la table TFIB grce la commande "show tagswitching forwarding". Le
rsultat de cette commande sur le routeur utilis prcdemment est donn ci-dessous:
L10-R1# sh tag for 10.10.4.4
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
24 21 10.10.4.4/32 0 Se0/1 point2point
On remarque ainsi que le routeur L10-R1 a slectionn pour le rseau 10.10.4.4/32 l'entre de la TIB cre
par le voisin 10.10.2.2 (connect L10-R1 par l'interface Serial0/1), qui a la meilleure mtrique du point de
vue de l'IGP (plus court chemin). Ainsi, pour chaque paquet reu ayant comme label 24, le routeur
commutera le paquet sur l'interface de sortie Serial0/1, et en permutant le label 24 par 21. La slection de
L10-R2 comme next-hop est confirme en consultant l'entre 10.10.4.4/32 de la table de routage:
L10-R1# sh ip route 10.10.4.4
Routing entry for 10.10.4.4/32
Known via "ospf 10", distance 110, metric 1601, type intra area
Last update from 10.10.12.2 on Serial0/1, 23:16:16 ago
Routing Descriptor Blocks:
* 10.10.12.2, from 10.10.4.4, 23:16:16 ago, via Serial0/1

Route metric is 1601, traffic share count is 1
Le routeur, lorsqu'il reoit un paquet taggu, se base sur la TFIB pour forwarder le paquet. A partir d'un label
d'entre (local tag), il en dduit l'interface et le label de sortie (Outgoing interface et Outgoing tag or VC).
Pour pouvoir utiliser la TFIB, le routeur doit employer CEF comme technique de commutation, qui doit tre
active globalement et pour chaque interface recevant des paquets taggus. CEF est en effet le seul mode de
commutation capable d'utiliser la TFIB. Les anciens modes (fastswitching, optimum switching, etc.) ne sont
pas
conus
pour
grer
cette
table.
Il est possible de consulter la table CEF d'un routeur avec la commande show ip cef . Tous les prfixes IP
connus seront alors affichs avec leur interface de sortie et l'adresse du next-hop. Il est possible d'obtenir
des informations plus dtailles sur un subnet particulier avec la commande show ip cef subnet netmask .
Il est ainsi ais de connatre le(s) label(s) de sortie utiliss pour atteindre ce rseau, l'interface de sortie et le
next-hop IP, comme le montre l'exemple suivant :
L10-R1# sh ip cef 10.10.4.4
10.10.4.4/32, version 594, cached adjacency to Serial0/1
0 packets, 0 bytes
tag information set
local tag: 24
fast tag rewrite with Se0/1, point2point, tags imposed: {21}
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: {21}
L'interface de sortie emprunter pour atteindre le subnet 10.10.4.4/32 est donc Serial0/1, avec comme
adresse de next-hop 10.10.12.2 (routeur L10-R2). Le tag local affect par le routeur L10-R1 est 24 et le tag
utilis
en
sortie
est
21
(appris
de
L10-R2
par
TDP).
Sur L10-R2, le contenu de la TIB pour 10.10.4.4/32 est reproduit ci-dessous :
L10-R2# sh tag tdp bind 10.10.4.4 255.255.255.255
tib entry: 10.10.4.4/32, rev 26
local binding: tag: 21
remote binding: tsr: 10.10.4.4:0, tag: imp-null
On retrouve donc bien comme tag d'entre le tag 21 pour atteindre le rseau 10.10.4.4. A partir de la
version IOS 12.1(5)T, il est possible de connatre les labels d'un chemin servant atteindre une destination
prcise, avec la commande traceroute :
L10-R7# trace 10.10.6.6
Type escape sequence to abort.
Tracing the route to 10.10.6.6
1
2
3
4
5
10.10.57.5
10.10.35.3
10.10.23.2
10.10.24.4
10.10.46.6
[MPLS: Label 29 Exp

[MPLS: Label 22 Exp
[MPLS: Label 23 Exp
[MPLS: Label 29 Exp
40 msec * 40 msec
0]
0]
0]
0]
120 msec 116 msec 116 msec

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
23 Pop tag 10.10.2.2/32 145198 Se0/1 point2point
L10-R1# sh ip cef 10.10.2.2
0 packets, 0 bytes
tag information set
local tag: 23
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:
3.11 - Description de l'entte MPLS

Un
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.
3.12.1 - Configuration de CEF

La premire opration effectuer pour utiliser MPLS est d'activer CEF (Cisco Express Forwarding) comme
mthode de commutation sur tous les routeurs du backbone. En effet, CEF est la seule mthode de routage
capable d'utiliser la TFIB pour commuter les paquets. En cas d'oubli, MPLS ne sera pas fonctionnel. CEF se
configure avec la commande globale: "ip cef [distributed]". Le mot-cl optionnel "distributed" permet
d'activer CEF de manire distribue sur les routeurs disposant de cartes de routage et de cartes filles comme
les cartes VIP des routeurs 7500. Ce type de carte fait tourner une version rduite d'IOS et a une certaine
autonomie de fonctionnement car disposant d'un processeur et de mmoire ddie.
3.12.2 - Configuration d'un IGP
Un protocole de routage interne doit tre utilis sur le backbone pour pouvoir diffuser les labels MPLS. Il est
conseill d'utiliser un protocole "link-state", tel que OSPF ou IS-IS, qui sont les seuls permettre le Traffic
Engineering. Il est bien entendu ncessaire de s'assurer que la connectivit est tablie partout sur le
backbone avant de procder la configuration de MPLS.
3.12.3 - Configuration de TDP / LDP
Pour permettre un routeur d'tablir une adjacence TDP avec un voisin sur une interface donne, cette
interface doit tre configure avec la commande "tagswitching ip". Bien que le protocole LDP (standard de
l'IETF) ne soit pas encore support, la commande "mpls ip" (correspondant LDP) existe dans la version
12.1(5)T. Toutefois, cette commande a le mme effet que "tag-switching ip".
4 - Virtual Private Networks (VPN)

Actuellement, il est trs courant qu'une entreprise soit constitue de plusieurs sites gographiques (parfois trs
loigns) et dont elle souhaite interconnecter les rseaux informatiques travers un WAN (Wide Area Network). La
solution la plus connue et la plus employe consiste relier les sites au moyen de liaisons spcialises, ddies
l'entreprise. Toutefois, le cot prohibitif de ces liaisons, et ventuellement la non aisabilit technique, par exemple
avec des sites spars de plusieurs centaines de km, amnent rechercher des solutions plus abordables. Les
fournisseurs d'accs Internet disposent de backbones tendus, et couvrant la plupart du temps une large portion de
territoire. Il est donc plus simple pour une entreprise de relier ses sites aux points de prsence (POP) de l'oprateur
et mettre
en
place
une
solution
VPN
(Virtual
Private
Networks).
MPLS/VPN fournit une mthode de raccordement de sites appartenant un ou plusieurs VPN, avec possibilit de
recouvrement des plans d'adressage IP pour des VPN diffrents. En effet, l'adressage IP priv (voir RFC 1918) est trs
employ aujourd'hui, et rien ne s'oppose ce que plusieurs entreprises utilisent les mmes plages d'adresses (par
exemple 172.16.1.0/24). MPLS/VPN permet d'isoler le trafic entre sites n'appartenant pas au mme VPN, et en tant
totalement transparent pour ces sites entre eux. Dans l'optique MPLS/VPN, un VPN est un ensemble de sites placs
sous la mme autorit administrative, ou groups suivant un intrt particulier. Cette partie aborde les concepts de
MPLS/VPN, en particulier avec les notions de routeurs virtuels (VRF) et le protocole MP-BGP, ddi l'change de
routes VPN. Dans les documents prsentant MPLS/VPN, les VPN sont gnralement dfinis avec des noms de couleurs
(red, blue, etc.). Cette convention sera conserve dans ce rapport.
Dans cette partie, le rseau de dmonstration est constitu du pod L10, avec R6 et R7 comme placs en tant que
routeurs clients. Afin de sparer le plan d'adressage du backbone MPLS (adresses en 10.x.y.z), les adresses
utilises par les VPN sont du type 100.x.y.z, avec les mmes conventions que prcdemment. Par exemple,
l'interface
Loopback0
du
routeur
L10-R6
sera
100.10.6.6.
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
4.3 - Routeurs virtuels : VRF

La notion mme de VPN implique l'isolation du trafic entre sites clients n'appartenant pas aux mmes VPN. Pour
raliser cette sparation, les routeurs PE ont la capacit de grer plusieurs tables de routage grce la notion de
VRF (VPN Routing and Forwarding). Une VRF est constitue d'une table de routage, d'une FIB (Forwarding
Information Base) et d'une table CEF spcifiques, indpendantes des autres VRF et de la table de routage globale.
Chaque VRF est dsigne par un nom (par ex. RED, GREEN, etc.) sur les routeurs PE. Les noms sont affects
localement, et n'ont aucune signification vis--vis des autres routeurs. Chaque interface de PE relie un site
client est rattache une VRF particulire. Lors de la rception de paquets IP sur une interfaces client, le routeur
PE procde un examen de la table de routage de la VRF laquelle est rattache l'interface, et donc ne consulte
pas sa table de routage globale. Cette possibilit d'utiliser plusieurs tables de routage indpendantes permet de
grer un plan d'adressage par sites, mme en cas de recouvrement d'adresses entre VPN diffrents.
Par exemple, L10-R4 est configur de la manire suivante pour ses interfaces Loopback :
interface Loopback1
ip vrf forwarding BLUE
ip address 100.10.4.4 255.255.255.255
!
interface Loopback2
ip vrf forwarding RED
ip address 100.10.4.4 255.255.255.255
!
interface Loopback3
ip vrf forwarding GREEN
ip address 100.10.4.4 255.255.255.255
!
La commande ip vrf forwarding <vrf> permet de placer une interface dans la VRF spcifie. Comme le montre
l'exemple ci-dessus, la mme adresse IP peut tre affecte plusieurs fois diffrentes interfaces, car celles-ci sont
places
dans
des
VRF
diffrentes.
Pour construire leurs tables VRF, les PE doivent s'changer les routes correspondant aux diffrents VPN. En effet,
pour router convenablement les paquets destins un PE nomm PE-1, reli au site CE-1, le routeur PE-2 doit
connatre les routes VPN de PE- 1. L'change des routes VPN s'effectue grce au protocole MP-BGP, dcrit dans le
paragraphe suivant. Les configurations des VRF ne comportant que des paramtres relatifs MP-BGP (notamment
pour l'export et l'import des routes), la syntaxe IOS et des exemples pratiques seront donc donns dans les
paragraphes suivants. Les VRF disposant de tables de routage et de tables CEF spcifiques, il est possible de les
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
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
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
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
4.4.1 - Notion de RD (Route Distinguisher)

Des sites appartenant des VPN isols ayant la possibilit d'utiliser des plans d'adressage recouvrants, les
routes changes entre PE doivent tre rendues uniques au niveau des updates BGP. Pour cela, un identifiant
appel RD (Route Distinguisher), cod sur 64 bits, est accol chaque subnet IPv4 d'une VRF donne. Le RD
s'crit sous la forme ASN:nn ou IP-Address:nn . Dans les exemples de configuration fournis avec ce
document, le paramtre ASN a t fix arbitrairement 100, et nn choisi en fonction de la VRF, quel que
soit le routeur. Il est toutefois conseill de choisir un RD unique par routeur et par VRF. Une route VPNv4,
form d'un RD et d'un prfixe IPv4, s'crit ainsi sous la forme RD:Subnet/Masque. Exemple :
100:1:100.10.5.5/32. Lors de la cration d'une VRF sur un PE, un RD doit tre configur. Les routes apprises
soit localement (routes statiques, Loopback sur le PE), soit par les CE rattachs au PE seront ainsi exportes
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 import 500:1
!
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.
4.4.5 - Configuration MP-BGP d'un PE

La configuration d'un routeur PE pour changer des routes VPNv4 se prsente sous la forme suivante :
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 vpnv4
neighbor 10.10.1.1 activate
neighbor 10.10.1.1 send-community extended
no auto-summary
exit-address-family
!
On remarque la prsence d'une section supplmentaire par rapport une configuration BGP traditionnelle,
introduite par la commande address-family vpnv4 . Cette partie de la configuration BGP contient tous les
voisins tournant MP-BGP. Pour pouvoir ajouter un voisin dans la configuration VPNv4, ce voisin doit tre
pralablement dclar dans la configuration globale de BGP (commande remote- s et autres). Pour viter
qu'un voisin ne soit actif la fois pour BGP et MP-BGP, la ligne no neighbor <neighbor> activate doit tre
insre globalement. Naturellement, il est tout fait possible pour un routeur d'tre actif pour BGP et MPBGP simultanment. Par exemple, le BGP traditionnel servira propager les routes Internet aux routeurs PE,
tandis
que
MP-BGP
servira
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 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
!
neighbor iBGP activate
neighbor iBGP route-reflector-client
neighbor iBGP send-community extended
neighbor 10.10.2.2 peer-group

no auto-summary
exit-address-family
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 :
L10-R4# sh ip bgp vpnv4 vrf RED tags

Network Next Hop In tag/Out tag
Route Distinguisher: 100:2 (RED)
100.10.4.4/32 0.0.0.0 28/aggregate(RED)
100.10.5.5/32 10.10.5.5 notag/26
100.10.7.7/32 10.10.5.5 notag/29
100.10.57.0/24 10.10.5.5 notag/28
100.10.171.0/24 10.10.5.5 notag/33
100.10.172.0/24 10.10.5.5 notag/34
4.5 - Echange des routes avec les CE
Les CE sont des routeurs clients traditionnels, n'ayant aucune connaissance de MPLS ou des VRF. Les CE doivent
donc changer leurs routes IP avec leur PE au moyen de protocoles de routages classiques. Les protocoles
supports
par
IOS
sont
eBGP
(external
BGP),
RIPv2
et
OSPF.
Les deux paragraphes suivants donnent des exemples de configuration avec eBGP et RIPv2. Dans le rseau de
dmonstration, eBGP est utilis entre L10-R5 et L10-R7, tandis que RIPv2 est utilis entre L10-R4 et L10-R6. Le
routeur L10-R7 a t plac dans le VPN RED , et le routeur L10-R6 dans le VPN GREEN .
4.5.1 - Configuration eBGP

La configuration BGP de L10-R5 (routeur PE) pour la VRF RED est liste ci-dessous :
router bgp 10
!
[...]
address-family ipv4 vrf RED
redistribute connected
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 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
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
!
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
[...]
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
bandwidth 125
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
B
B
B
C
B
B

100.10.57.0/24 [200/0] via 10.10.5.5, 00:01:45
100.10.7.7/32 [200/0] via 10.10.5.5, 00:01:46
100.10.5.5/32 [200/0] via 10.10.5.5, 00:01:46
100.10.4.4/32 is directly connected, Loopback2
100.10.172.0/24 [200/0] via 10.10.5.5, 00:01:46
100.10.171.0/24 [200/0] via 10.10.5.5, 00:01:46
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
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Se0/1, point2point, tags imposed: {27}
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
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
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
2 10.10.23.3 [MPLS: Labels 23/26 Exp 0] 56 msec 60 msec 60 msec

3 100.10.57.5 28 msec * 28 msec
On remarque que seul le premier label a t modifi, le label VPN ayant t conserv intact pendant tout le
cheminement sur le backbone. La copie d'cran suivante montre quel aurait t le rsultat de la commande
traceroute pour atteindre l'adresse de Loopback 10.10.5.5 (adresse globale) partir de L10-R4 :
L10-R4# trace 10.10.5.5
1 10.10.24.2 [MPLS: Label 27 Exp 0] 68 msec 68 msec 64 msec
2 10.10.23.3 [MPLS: Label 23 Exp 0] 52 msec 56 msec 56 msec
3 10.10.35.5 28 msec * 24 msec
Il apparat clairement que la prsence du label VPN n'a pas d'effet sur les routeurs P du backbone : ceux-ci
switchent les paquets entre routeurs PE et n'ont aucune information sur les labels VPN.
Rappelons que les labels VPN, appris par MP-BGP, peuvent tre affichs au moyen de la commande show ip bgp
vpnv4 vrf <vrf> tags :
L10-R4# sh ip bgp vpnv4 vrf RED tags
Network Next Hop In tag/Out tag
Route Distinguisher: 100:2 (RED)
100.10.4.4/32 0.0.0.0 28/aggregate(RED)
100.10.5.5/32 10.10.5.5 notag/26
100.10.7.7/32 10.10.5.5 notag/30
100.10.57.0/24 10.10.5.5 notag/28
100.10.171.0/24 10.10.5.5 notag/31
100.10.172.0/24 10.10.5.5 notag/32
On retrouve bien le label 26 pour atteindre le subnet 100.10.5.5/32 sur le routeur L10-R5. Si l'on effectue un
traceroute vers l'adresse 100.10.7.7, appartenant L10-R7, on obtient le rsultat suivant :
L10-R4# trace vrf RED 100.10.7.7
Type escape sequence to abort.
Tracing the route to 100.10.7.7
1
2
3
4
10.10.24.2 [MPLS: Labels 27/30 Exp 0] 96 msec 92 msec 92 msec

10.10.23.3 [MPLS: Labels 23/30 Exp 0] 84 msec 88 msec 84 msec
100.10.57.5 [MPLS: Label 30 Exp 0] 76 msec 76 msec 72 msec
100.10.57.7 36 msec * 36 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
16 Untagged 10.10.13.1/32 0 Se0/1 point2point
22 20 10.10.4.4/32 3020 Se1/0 point2point
Pop tag 10.10.12.0/24 0 Se0/1 point2point
29 Aggregate 100.10.3.3/32[V] 0
L10-R3# sh ip cef 10.10.5.5

0 packets, 0 bytes
tag information set
local tag: 23
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
4.7 - Accs Internet

Le principe des VRF permet de concevoir aisment des routeurs virtuels, qui consultent leurs diffrentes tables de
routage en fonction de l'interface d'entre des paquets. Ces tables sont remplies avec les routes du VPN associ,
et le backbone MPLS assure la transmission des paquets entre les routeurs PE. Il se pose alors le problme de
l'accs Internet, situ par dfinition l'extrieur des diffrents VPN. De plus, les fournisseurs d'accs Internet
disposant de plusieurs points de sortie, il est important que les sites clients puissent utiliser le meilleur chemin
vers
l'extrieur.
Diffrentes mthodes existent pour permettre un accs Internet. Les deux premires se situent dans la catgorie
Sub-Optimized Routing , du fait qu'elles ne permettent pas de slectionner le meilleur chemin vers Internet. La
dernire, nomme Optimum Routing , permet de choisir le chemin optimal, tout en tant la plus propre
techniquement.
4.7.1 - Route par dfaut statique (Static Default Route)

La premire mthode (la plus ancienne) consiste une utiliser une extension de la commande ip route
pour dfinir une route par dfaut dans les VRF des routeurs PE, au moyen de la commande :
ip route vrf GREEN 0.0.0.0 0.0.0.0 PE-Internet global
o PE-Internet est l'adresse globale du PE fournissant l'accs Internet. Pour que le retour des paquets
puisse tre effectif vers le CE concern, les routes VPN du CE doivent tre dclares globalement sur son PE
de rattachement, et propages au PE-Internet (IGP, iBGP, etc.). Par exemple, si un rseau 120.2.1.0/24 est
connect un CE 120.1.1.1 appartenant au VPN GREEN , le PE doit contenir les deux lignes suivantes :
ip route vrf GREEN 0.0.0.0 0.0.0.0 120.1.1.2 global
ip route 120.2.1.0 255.255.255.0 120.1.1.1
Dans
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
4.7.3 - Routage optimal (Optimum Routing)

La mthode dite Optimum Routing permet aux sites clients d'accder Internet, tout en slectionnant le
meilleur
chemin
si
plusieurs
PE
sont
passerelles
vers
l'extrieur.
Le concept cl de l'Optimum Routing est de propager l'ensemble des routes Internet sur tous les PE du
backbone MPLS. Naturellement, il n'est pas possible de propager ces routes dans chaque VPN : en supposant
que l'on compte 100000 routes Internet ; propager ces routes dans 100 VPN diffrents (soit 10 millions de
routes au total) n'est videmment pas ralisable. Les routes Internet sont donc changes entre PE grce au
protocole BGP standard (sessions iBGP entre les PE), et ce sont les tables de routage globales des PE qui
contiennent
ces
routes.
Pour permettre aux sites d'accder l'extrieur, les CE sont relis de deux manires au backbone de
l'oprateur : la premire connexion permet l'accs aux routes Internet globales, tandis que la seconde
permet
l'accs
aux
autres
sites
du
VPN,
avec
l'utilisation
d'une
VRF.
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
!
interface Serial1/0.2
description Interface pour accs VPN
ip address 10.2.1.1 255.255.255.252
!
Exemple de configuration avec une interface Ethernet en mode trunk :
interface FastEthernet0/0
no ip address
!
interface FastEthernet0/0.1
ip address 100.1.1.1 255.255.255.252
encapsulation isl 1
!
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) :
description Vers site client
ip address 10.2.0.1 255.255.255.0
ip policy route-map ACCESS
ip nat inside
!
no ip address
!
ip address 100.1.1.2 255.255.255.252
encapsulation isl 1
ip nat outside
!
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.
5 - Traffic Engineering (TE)

5.1 - Introduction
La plupart des gros rseaux IP, en particulier ceux des oprateurs, disposent de liens de secours en cas de panne.
Toutefois, il est assez difficile d'obtenir une rpartition du trafic sur ces liens qui ne sont traditionnellement pas
utiliss,
car
n'tant
pas
slectionns
comme
chemins
optimaux
par
l'IGP.
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
5.6.1 - Activation globale de Traffic Engineering

Pour qu'un LSR puisse grer le TE, la commande mpls traffic-eng tunnels doit tre saisie en mode de
configuration globale.
5.6.2 - Configuration de l'IGP
Suivant
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 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
!
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 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.
7 - Annexe I: Configurations MPLS simples

Configuration de L10-R1 :
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname L10-R1
!
boot system flash slot0:c3620-js-mz.122-0.4.bin
logging rate-limit console 10 except errors
enable secret 5 $1$AKNE$ZjooLX5ZFP7nbGr6E/ejh/
!
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.1.1 255.255.255.255
!
interface Serial0/0

bandwidth 125
ip address 10.10.13.1 255.255.255.0
encapsulation ppp
clockrate 125000
!
interface Serial0/1
bandwidth 125
ip address 10.10.12.1 255.255.255.0
encapsulation ppp
clockrate 125000
!
router ospf 10
log-adjacency-changes
passive-interface Ethernet0/0
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
!
version 12.2
!
hostname L10-R2
!
boot system flash flash:c3640-js-mz.122-0.4.bin
enable secret 5 $1$M7Ig$NBWKag8D2u7Q9sOU9xDfm/
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 10.10.2.2 255.255.255.255
!
interface Serial0/0
bandwidth 125
ip address 10.10.24.2 255.255.255.0
encapsulation ppp
clockrate 125000
!
interface Serial0/1
bandwidth 125
ip address 10.10.12.2 255.255.255.0
encapsulation ppp
!
interface Serial1/0
bandwidth 125
ip address 10.10.23.2 255.255.255.0
encapsulation ppp
clockrate 125000
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R3
!
enable secret 5 $1$3Paa$QoFQfhYLZLCidMokHBanf1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 10.10.3.3 255.255.255.255
!
interface Serial0/0
bandwidth 125
ip address 10.10.35.3 255.255.255.0
encapsulation ppp
clockrate 125000
!
interface Serial0/1
bandwidth 125
ip address 10.10.13.3 255.255.255.0
encapsulation ppp
!
interface Serial1/0
bandwidth 125
ip address 10.10.23.3 255.255.255.0
encapsulation ppp
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R4
!
enable secret 5 $1$mLZz$9KLAmd1tA023Bd5Z5mV.s1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 10.10.4.4 255.255.255.255
!
interface Serial0/0
bandwidth 125
ip address 10.10.46.4 255.255.255.0
encapsulation ppp
no fair-queue
clockrate 125000
!
interface Serial0/1
bandwidth 125
ip address 10.10.24.4 255.255.255.0
encapsulation ppp
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R5
!
enable secret 5 $1$m80i$NykiaSFf0D9EdTDAjJozu.
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
frame-relay switching
call rsvp-sync
!
interface Loopback0
ip address 10.10.5.5 255.255.255.255
!
interface Serial0/0
no ip address
clockrate 125000
frame-relay lmi-type cisco
frame-relay intf-type dce
!
bandwidth 125
ip address 10.10.57.5 255.255.255.0
!
interface Serial0/1
bandwidth 125
ip address 10.10.35.5 255.255.255.0
encapsulation ppp
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R6
!

enable secret 5 $1$bZ2c$wdF872FRcLXaObuYJD90u1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 10.10.6.6 255.255.255.255
!
interface Serial0/0
bandwidth 125
ip address 10.10.46.6 255.255.255.0
encapsulation ppp
no fair-queue
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
line vty 5 15
login
!
end
!
version 12.2
!
hostname L10-R7
!
enable secret 5 $1$Fgps$hTMFn1J6vXX9P3Dh9JDaK/
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 10.10.7.7 255.255.255.255
!
interface Serial0/0
no ip address
!
bandwidth 125
ip address 10.10.57.7 255.255.255.0
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
password cisco
login
line vty 5 15
login
!
end
8 - Annexe II: Configurations MPLS/VPN

!
version 12.2
!
hostname L10-R1
!
enable secret 5 $1$AKNE$ZjooLX5ZFP7nbGr6E/ejh/
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 10.10.1.1 255.255.255.255
!
interface Ethernet0/0
ip address 200.1.112.1 255.255.255.0
half-duplex
!
interface Serial0/0
bandwidth 125
ip address 10.10.13.1 255.255.255.0
encapsulation ppp
clockrate 125000
tag-switching ip
!
interface Serial0/1
bandwidth 125
ip address 10.10.12.1 255.255.255.0
encapsulation ppp
clockrate 125000
tag-switching ip
!
ip address 50.50.50.1 255.255.255.0
duplex auto
speed auto
!
router ospf 10
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 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
!
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
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
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R2
!

enable secret 5 $1$M7Ig$NBWKag8D2u7Q9sOU9xDfm/
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 10.10.2.2 255.255.255.255
!
no ip address
shutdown
half-duplex
!
interface Serial0/0
bandwidth 125
ip address 10.10.24.2 255.255.255.0
encapsulation ppp
clockrate 125000
tag-switching ip
!
interface Serial0/1
bandwidth 125
ip address 10.10.12.2 255.255.255.0
encapsulation ppp
tag-switching ip
!
no ip address
shutdown
half-duplex
!
interface Serial1/0
bandwidth 125
ip address 10.10.23.2 255.255.255.0
encapsulation ppp
clockrate 125000
tag-switching ip
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 10
no synchronization
no auto-summary
!
no auto-summary
exit-address-family
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R3
!
enable secret 5 $1$3Paa$QoFQfhYLZLCidMokHBanf1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
ip vrf ADMIN
rd 100:2000
!
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
!
no ip address
shutdown
half-duplex
!
interface Serial0/0
bandwidth 125
ip address 10.10.35.3 255.255.255.0
encapsulation ppp
clockrate 125000
tag-switching ip
!
interface Serial0/1
bandwidth 125
ip address 10.10.13.3 255.255.255.0
encapsulation ppp
tag-switching ip
!
no ip address
shutdown
half-duplex
!
interface Serial1/0
bandwidth 125
ip address 10.10.23.3 255.255.255.0
encapsulation ppp
tag-switching ip
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 10
no synchronization
no auto-summary
!
address-family ipv4 vrf ADMIN
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
exit-address-family
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R4
!
enable secret 5 $1$mLZz$9KLAmd1tA023Bd5Z5mV.s1
!
memory-size iomem 10
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
ip vrf BLUE
rd 100:1
!
ip vrf RED
rd 100:2
!
ip vrf GREEN
rd 100:3

!
interface Loopback0
ip address 10.10.4.4 255.255.255.255
!
interface Loopback1
ip address 100.10.4.4 255.255.255.255
!
interface Loopback2
ip address 100.10.4.4 255.255.255.255
!
interface Loopback3
ip address 100.10.4.4 255.255.255.255
!
no ip address
shutdown
!
interface Serial0/0
bandwidth 125
ip address 100.10.46.4 255.255.255.0
encapsulation ppp
no fair-queue
clockrate 125000
!
interface Serial0/1
bandwidth 125
ip address 10.10.24.4 255.255.255.0
encapsulation ppp
tag-switching ip
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
router rip
version 2
!
version 2
redistribute bgp 10 metric 1
network 100.0.0.0
no auto-summary
exit-address-family
!
router bgp 10
no synchronization
no auto-summary
!
address-family ipv4 vrf BLUE
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
exit-address-family
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R5
!
enable secret 5 $1$m80i$NykiaSFf0D9EdTDAjJozu.
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
frame-relay switching
call rsvp-sync
!
ip vrf BLUE
rd 100:1
!
ip vrf RED
rd 100:2
!
ip vrf GREEN
rd 100:3
!
interface Loopback0
ip address 10.10.5.5 255.255.255.255
!
interface Loopback1
ip address 100.10.5.5 255.255.255.255
!
interface Loopback2
ip address 100.10.5.5 255.255.255.255
!
interface Loopback3
ip address 100.10.5.5 255.255.255.255
!
no ip address
half-duplex
!
interface Serial0/0
no ip address
clockrate 125000
frame-relay intf-type dce
!
bandwidth 125
ip address 100.10.57.5 255.255.255.0
!
interface Serial0/1
bandwidth 125
ip address 10.10.35.5 255.255.255.0
encapsulation ppp
tag-switching ip
!
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 10
no synchronization
no auto-summary
!
address-family ipv4 vrf BLUE
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
exit-address-family
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
!
end
!
version 12.2
!
hostname L10-R6
!
enable secret 5 $1$bZ2c$wdF872FRcLXaObuYJD90u1
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 100.10.6.6 255.255.255.255
!
no ip address
half-duplex
!
interface Serial0/0
bandwidth 125
ip address 100.10.46.6 255.255.255.0
encapsulation ppp
no fair-queue
!
no ip address
duplex auto
speed auto
!
encapsulation dot1Q 161
ip address 100.10.161.6 255.255.255.0
no ip redirects
!
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
line aux 0
line vty 0 4
exec-timeout 0 0
password cisco
login
line vty 5 15
login
!
end
!
version 12.2
!
hostname L10-R7
!
enable secret 5 $1$Fgps$hTMFn1J6vXX9P3Dh9JDaK/
!
ip subnet-zero
!
no ip finger
no ip domain-lookup
!
ip cef
call rsvp-sync
!
interface Loopback0
ip address 100.10.7.7 255.255.255.255
!
no ip address
half-duplex
!
interface Serial0/0
no ip address
!
bandwidth 125
ip address 100.10.57.7 255.255.255.0
!
no ip address
duplex auto
speed auto
!
ip address 100.10.171.7 255.255.255.0
no ip redirects
!
ip address 100.10.172.7 255.255.255.0
no ip redirects
!
router bgp 102
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
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
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
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.
4 - Le mode non connect

Le mode non connect est bas sur UDP qui ne garanti pas la transmission de donne. Voici le schma d'une relation
entre
deux
hosts
IP
en
mode
non
connect.
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.
Mode connecte en C++
1 - Schma d'une relation client serveur

2 - Initialisation de la socket
2.1 - Commande WSAStartup()
2.2 - Commande socket()
2.3 - Commande setsockopt()
3 - Ecoute du port TCP
3.1 - Commande bind()
4 - Etablissement de la session TCP
4.1 - Commande connect()
4.2 - Commande listen()
4.3 - Commande accept()
5 - Echange des donnes
5.1 - Commande send()
5.2 - Commande recv()
6 - Fermeture de la session TCP
6.1 - Commande shutdown()
7 - Libration de la socket
7.1 - Commande closesocket()
7.2 - Commande WSACleanup()

8 - Exemple complet d'une communication client serveur
8.1 - Ct serveur
8.2 - Ct client
9 - Les liens
1 - Schma d'une relation client-serveur

Voici
le
schma
d'une
relation
entre
un
client
et
un
serveur.
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().
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.
// ********************************************************
// ********************************************************
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.
// ********************************************************
// ********************************************************
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.
Voici la fiche Msdn concernant la fonction setsockopt().
3 - Ecoute du port TCP

La commande bind permet de lier la socket un port et adresse IP d'coute. Voici un exemple d'utilisation pour le
ct serveur.
// ********************************************************
// ********************************************************
SOCKADDR_IN information_sur_la_source; // Dclaration de la structure des informations li l'coute
// ********************************************************
// Lie la socket une ip et un port d'coute
// ********************************************************
information_sur_la_source.sin_family=AF_INET;
information_sur_la_source.sin_addr.s_addr=INADDR_ANY; // Ecoute sur toutes les IP locales
information_sur_la_source.sin_port=htons(33333); // Ecoute sur le port 33333
erreur=bind(id_de_la_socket,(struct sockaddr*)&information_sur_la_source,sizeof(information_sur_la_source));
if (erreur!=0)
printf("\nDesole, je ne peux pas ecouter ce port : %d %d",erreur,WSAGetLastError());
else
printf("\nbind
: OK");
- Le second argument est la structure comprenant les informations sur le port et l'adresse IP se lier.
Le
troisime
paramtre
spcifie
uniquement
la
taille
de
la
structure
du
second.
Voici la fiche Msdn concernant la fonction bind().
4 - tablissement d'une session TCP

Le client doit utiliser la fonction connect() afin d'amorcer l'ouverture de session TCP. Et le serveur doit appeler la
fonction accept() pour valider l'ouverture. Le but de ces fonctions est de crer la session TCP bas sur trois trames
S,AS,A. Cette tape n'est donc ncessaire que dans le cadre de l'utilisation du mode connect.
4.1 - Commande connect()
La commande connect permet d'initier et d'tablir la session TCP avec le serveur. Voici un exemple d'utilisation
pour le ct client.
// ********************************************************
// ********************************************************
SOCKADDR_IN information_sur_la_destination; // Dclaration de la structure des informations li au serveur
// ********************************************************
// Ouverture de la session TCP sur destination de l'adresse IP 10.10.10.10 et du port 80
// ********************************************************
information_sur_la_destination.sin_family=AF_INET;
information_sur_la_destination.sin_addr.s_addr=inet_addr("10.10.10.10"); // Indiquez l'adresse IP de votre serveur
information_sur_la_destination.sin_port=htons(80); // Port cout du serveur (33333)

erreur=connect(id_de_la_socket,(struct
sockaddr*)&information_sur_la_destination,sizeof(information_sur_la_destination));
if (erreur!=0)
printf("\nDesole, je n'ai pas pu ouvrir la session TCP : %d %d",erreur,WSAGetLastError());
else
- Le second argument est la structure comprenant les informations sur la destination du port et sur l'adresse IP.
Le
troisime
paramtre
spcifie
uniquement
la
taille
de
la
structure
du
second.
- La fonction devra renvoyer 0 pour indiquer que son excution c'est correctement droule.
Voici la fiche Msdn concernant la fonction connect().
4.2 - Commande listen()
La commande listen permet d'couter les demandes d'ouvertures de session TCP arrivant sur le port et adresse IP
slectionn par la commande bind(). Voici un exemple d'utilisation pour le ct serveur.
// ********************************************************
// Attente d'ouverture de session
// ********************************************************
erreur=99; // Initiation de erreur pour tre sur que l'on va rentrer dans la boucle
while(erreur!=0) // Boucle tant qu'une demande de session (SYN) tcp n'a pas t reu
erreur=listen(id_de_la_socket,1);
printf("\nlisten
: OK");
- Le second argument reprsente le nombre maximum de demande d'ouverture de session simultane accept.
La
fonction
devra
renvoyer
0
pour
indiquer
qu'une
session
TCP
a
t
tablie.
Voici la fiche Msdn concernant la fonction listen().
4.3 - Commande accept()
La commande accept permet d'indiquer, aprs rception du SYN (demande d'ouverture de session TCP),
l'acceptation de l'tablissement complte de la session. Voici un exemple d'utilisation pour le ct serveur.
// ********************************************************
// ********************************************************
SOCKET id_de_la_nouvelle_socket; // Identifiant de la nouvelle socket
// ********************************************************
// Acceptation de la demande d'ouverture de session
// ********************************************************
printf("\nAttente de la reception de demande d'ouverture de session tcp (SYN)");
tempo=sizeof(information_sur_la_source); // Passe par une variable afin d'utiliser un pointeur
id_de_la_nouvelle_socket=accept(id_de_la_socket,(struct sockaddr*)&information_sur_la_source,&tempo);
if(id_de_la_nouvelle_socket==INVALID_SOCKET)
printf("\nDesole, je ne peux pas accepter la session TCP du a l'erreur : %d",WSAGetLastError());
else
printf("\naccept
: OK");
- Le second argument est la structure comprenant les informations sur la source du port et de l'adresse IP qui ont
t
rcupres.
Le
troisime
paramtre
spcifie
uniquement
la
taille
de
la
structure
du
second.
- La fonction renverra le descripteur d'une nouvelle socket permettant l'envoi des donnes via la session TCP
ouverte.
Voici la fiche Msdn concernant la fonction accept().

5.1 - Commande send()
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.
// ********************************************************
// ********************************************************
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
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);
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().
6 - Fermeture de la session TCP

6.1 Commande shutdown()
La fermeture de session TCP n'est pas obligatoire d fait que vous aurez dj obtenue les services attendus.
Cependant ces trs fortement conseill pour un dveloppement propre et une utilisation respectueuse duprotocole
IP.
Voici
un
exemple
d'utilisation
pour
le
ct
client
et
serveur.
// ********************************************************
// 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 second argument indique si l'on doit fermer l'mission, la rception ou les deux.
Voici la fiche Msdn concernant la fonction shutdown().
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");
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.
Voici la fiche Msdn concernant la fonction WSACleanup().

8.1 - Ct serveur
Voici un exemple de code fonctionnel qui permet d'couter sur le port TCP 33333 et d'afficher les donnes reues.
Le fichier cpp est disponible ici.
// ********************************************************
// Les includes
// ********************************************************
#include <winsock2.h> // pour les fonctions socket
#include <cstdio> // Pour les Sprintf
// ********************************************************
// Les librairies
// ********************************************************
#pragma comment(lib,"ws2_32.lib")
// ********************************************************
// Dfinition des variables

// ********************************************************
SOCKET id_de_la_nouvelle_socket; // Identifiant de la nouvelle socket
int main (int argc, char* argv[])
{
printf("\nBonjour, vous etes du cote serveur. www.frameip.com\n");
// ********************************************************
// ********************************************************
if (erreur!=0)
else
// ********************************************************
// ********************************************************
else
printf("\nsocket
: OK");
// ********************************************************
// ********************************************************
tempo=1;
if (erreur!=0)
else
// ********************************************************
// ********************************************************
if (erreur!=0)
else
printf("\nbind
: OK");
// ********************************************************
// Attente d'ouverture de session
// ********************************************************
erreur=99; // Initiation de erreur pour tre sur que l'on va rentrer dans la boucle
while(erreur!=0) // Boucle tant qu'une demande de session (SYN) tcp n'a pas t reu
erreur=listen(id_de_la_socket,1);
printf("\nlisten
: OK");
// ********************************************************
// Acceptation de la demande d'ouverture de session
// ********************************************************
printf("\nAttente de la reception de demande d'ouverture de session tcp (SYN)");
id_de_la_nouvelle_socket=accept(id_de_la_socket,(struct sockaddr*)&information_sur_la_source,&tempo);
if(id_de_la_nouvelle_socket==INVALID_SOCKET)
printf("\nDesole, je ne peux pas accepter la session TCP du a l'erreur : %d",WSAGetLastError());
else
printf("\naccept
: OK");
// ********************************************************

// ********************************************************
nombre_de_caractere=recv(id_de_la_nouvelle_socket,buffer,1515,0);
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
}
// ********************************************************
// ********************************************************
erreur=shutdown(id_de_la_nouvelle_socket,2); // 2 signifie socket d'mission et d'coute
if (erreur!=0)
else
// ********************************************************
// Fermeture des deux socket correspondant la commande socket() et accept()
// ********************************************************
erreur=closesocket(id_de_la_nouvelle_socket);
if (erreur!=0)
else
if (erreur!=0)
else
// ********************************************************
// ********************************************************
if (erreur!=0)
else
}
8.2 - Ct client
Voici un exemple de code fonctionnel qui permet d'envoyer des donnes sur le port TCP 33333, n'oubliez pas de
changer l'IP de destination pour correspondre votre serveur. Le fichier cpp est disponible ici.
// ********************************************************
// Les includes
// ********************************************************
// ********************************************************
// Les librairies
// ********************************************************
// ********************************************************
// ********************************************************
char buffer[65535]; // Tampon contennant les donnes reues ou envoyes
{
printf("\nBonjour, vous etes du cote client. www.frameip.com\n");
// ********************************************************
// ********************************************************
if (erreur!=0)
else
// ********************************************************
// ********************************************************
else
printf("\nsocket
: OK");
// ********************************************************
// ********************************************************
tempo=1;
if (erreur!=0)
else
// ********************************************************
// Etablissement de l'ouverture de session
// ********************************************************
information_sur_la_destination.sin_family=AF_INET;
information_sur_la_destination.sin_addr.s_addr=inet_addr("10.10.10.10"); // Indiquez l'adresse IP de votre
serveur
information_sur_la_destination.sin_port=htons(33333); // Port cout du serveur (33333)
erreur=connect(id_de_la_socket,(struct
if (erreur!=0)
printf("\nDesole, je n'ai pas pu ouvrir la session TCP : %d %d",erreur,WSAGetLastError());
else
// ********************************************************
// Envoi des donnes
// ********************************************************
nombre_de_caractere=send(id_de_la_socket,buffer,strlen(buffer),0);
printf("\nDesole, je n'ai pas envoyer les donnees du a l'erreur : %d",WSAGetLastError());
else
printf("\nsend
: OK");
// ********************************************************
// ********************************************************
erreur=shutdown(id_de_la_socket,2); // 2 signifie socket d'mission et d'coute
if (erreur!=0)
else
// ********************************************************
// ********************************************************
if (erreur!=0)
else
// ********************************************************
// ********************************************************
if (erreur!=0)
else
Mode non connecte en C++
1 - Schma d'une relation client serveur

2.1 - Commande WSAStartup()
3 - Ecoute du port UDP
4.1 - Commande sendto()
4.2 - Commande recvfrom()
5.1 - Commande closesocket()
5.2 - Commande WSACleanup()
6.1 - Ct serveur
6.2 - Ct client
7 - Les liens
1 - Schma d'une relation client-serveur
Voici
le
schma
d'une
relation
entre
un
client
et
un
serveur.
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.
// ********************************************************
// ********************************************************
// ********************************************************
// ********************************************************
if (erreur!=0)
else
- 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.
Voici la fiche Msdn concernant la fonction WSAStartup().
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.
// ********************************************************
// ********************************************************
// ********************************************************
// ********************************************************
id_de_la_socket=socket(AF_INET,SOCK_DGRAM,0);
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 UDP, 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().
3 - Ecoute du port UDP

La commande bind permet de lier la socket un port et adresse IP d'coute. Voici un exemple d'utilisation pour le
ct serveur.
// ********************************************************
// ********************************************************
// ********************************************************
// ********************************************************
if (erreur!=0)
else
printf("\nbind
: OK");
- Le second argument est la structure comprenant les informations sur le port et l'adresse IP se lier.
Le
troisime
paramtre
spcifie
uniquement
la
taille
de
la
structure
du
second.
Voici la fiche Msdn concernant la fonction bind().

4.1 - Commande sendto()
La commande sendto permet l'envoi d'une chane de caractre destination du serveur prcis comme argument
de la fonction. Voici un exemple d'utilisation pour le ct client.
// ********************************************************
// ********************************************************
// ********************************************************
// Envoi des donnes
// ********************************************************
information_sur_la_destination.sin_family=AF_INET; // Indiquez l'utilisation d'IPV4
information_sur_la_destination.sin_addr.s_addr=inet_addr("10.10.10.10"); // Indiquez l'adresse IP de votre serveur
information_sur_la_destination.sin_port=htons(33333); // Port TCP 33333 destination du serveur
nombre_de_caractere=sendto(id_de_la_socket,buffer,strlen(buffer),0,(struct
printf("\nDesole, je ne peux pas envoyer les donnees du a l'erreur : %d",WSAGetLastError());
else
printf("\nsend : OK");
Le
second
argument
est
le
buffer
contenant
les
donnes
envoyer.
Le
troisime
paramtre
spcifie
uniquement
la
taille
du
buffer.
- Le quatrime fait rfrence la structure comprenant les informations sur le port et l'adresse IP de destination.
Le
cinquime
indique
la
taille
de
la
structure
prcdente.
- La
fonction
renverra
le
nombre
de
caractre
qui
a
t
mis.
Voici la fiche Msdn concernant la fonction sendto().
4.2 - Commande recvfrom()
La commande recvfrom permet de recueillir dans un buffer les donnes reues sur une socket. Voici un exemple
d'utilisation pour le ct serveur.
// ********************************************************
// ********************************************************
nombre_de_caractere=recvfrom(id_de_la_socket,buffer,1515,0,(struct
sockaddr*)&information_sur_la_source,&tempo);
buffer[nombre_de_caractere]=0; // Permet de fermer le tableau aprs le contenu des data, car la fonction recvfrom ne
le fait pas
- 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.
- Le quatrime fait rfrence la structure comprenant les informations sur le port et l'adresse IP en coute.
Le
cinquime
indique
la
taille
de
la
structure
prcdente.
- La
fonction
renverra
le
nombre
de
caractre
qui
a
t
reu.
Voici la fiche Msdn concernant la fonction recvfrom()
5.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.
// ********************************************************
// ********************************************************
if (erreur!=0)
else
Voici la fiche Msdn concernant la fonction closesocket().
5.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.
// ********************************************************
// ********************************************************
if (erreur!=0)
else
-
La
fonction
devra
renvoyer
pour
indiquer
que
sont
excution
c'est
correctement
droule.
Voici la fiche Msdn concernant la fonction WSACleanup().

6.1 - Ct serveur
Voici un exemple de code fonctionnel qui permet d'couter sur le port UDP 33333 et d'afficher les donnes reues.
Le fichier cpp est disponible ici.
// ********************************************************
// Les includes
// ********************************************************
// ********************************************************
// Les librairies
// ********************************************************
// ********************************************************
// ********************************************************
{
printf("\nBonjour, vous etes du cote serveur. www.frameip.com\n");
// ********************************************************
// ********************************************************
if (erreur!=0)
else
// ********************************************************
// ********************************************************
else
printf("\nsocket
: OK");
// ********************************************************
// ********************************************************
if (erreur!=0)
else
printf("\nbind
: OK");
// ********************************************************
// ********************************************************
nombre_de_caractere=recvfrom(id_de_la_socket,buffer,1515,0,(struct
sockaddr*)&information_sur_la_source,&tempo);
buffer[nombre_de_caractere]=0; // Permet de fermer le tableau aprs le contenu des data, car la fonction
recvfrom ne le fait pas
// ********************************************************
// Fermeture de la socket correspondante la commande socket()
// ********************************************************
if (erreur!=0)
else
// ********************************************************
// ********************************************************
if (erreur!=0)
else
}
6.2 - Ct client
Voici un exemple de code fonctionnel qui permet d'envoyer des donnes sur le port UDP 33333, n'oubliez pas de
changer l'IP de destination pour correspondre votre serveur. Le fichier cpp est disponible ici.
// ********************************************************
// Les includes
// ********************************************************
// ********************************************************
// Les librairies
// ********************************************************
// ********************************************************
// ********************************************************

char buffer[65535]; // Tampon contennant les donnes reues ou envoyes
{
printf("\nBonjour, vous etes du cote client. www.frameip.com\n");
// ********************************************************
// ********************************************************
if (erreur!=0)
else
// ********************************************************
// ********************************************************
else
printf("\nsocket
: OK");
// ********************************************************
// Envoi des donnes
// ********************************************************
information_sur_la_destination.sin_family=AF_INET; // Indiquez l'utilisation d'IPV4
information_sur_la_destination.sin_addr.s_addr=inet_addr("10.10.10.10"); // Indiquez l'adresse IP de votre
serveur
information_sur_la_destination.sin_port=htons(33333); // Port TCP 33333 destination du serveur
nombre_de_caractere=sendto(id_de_la_socket,buffer,strlen(buffer),0,(struct
printf("\nDesole, je ne peux pas envoyer les donnees du a l'erreur : %d",WSAGetLastError());
else
printf("\nsend
: OK");
// ********************************************************
// ********************************************************
if (erreur!=0)
else
// ********************************************************
// ********************************************************
if (erreur!=0)
else
}
Mode connecte et non connect en VB
1 - Le composant Winsock en VB
2 - Les proprits, les procdure et les vnements de Winsock
3 - Mode connect
3.1 - Schma d'une relation client serveur
3.2 - Le mode client
3.3 - Le mode serveur
3.3.1 - Sur une feuille
4-
567-
3.3.2 - Dans une classe

3.4 - Exemple complet d'une communication client serveur
Mode non connect
4.2 - Le mode client et serveur
Les liens
Suivi du document
1 - Le composant Winsock en VB
Le contrle Winsock VB de Microsoft permet d'envoyer des datagrames facilement un autre ordinateur ou tout autre
quipement
Ip.
Ce
contrle
ne
supporte
que
deux
mode
de
connexion
qui
sont Tcp et Udp.
On peut utiliser ce contrle sous deux formes. La premire comme composant et la seconde comme rfrence. Quand
vous
voulez
utiliser
Winsock
dans
votre
application, vous devez l'ajouter comme composant "Microsoft Winsock Control 6.0" ou comme rfrence
"%WinDir%\System\mswinsck.ocx".
2 - Les proprits, les procdures et les vnements de Winsock

Voici la liste des proprits ayant rapport la configuration de Winsock. Leurs effets et les valeurs qu'ils peuvent
prendre et videmment, elle peuvent aussi en retourner.
Nom
Effet
Valeurs acceptes
Name
*(Quand il est sur une feuille) Le nom du contrle
Une chane de caractres correcte

pour un nom d'objet
Index
*(Quand il est sur une feuille) Son index si il fait partit d'une
collection de contrles
rien=pas dans une collection;un

chiffre de 0 (limite du type entier)
Left
*(Quand il est sur une feuille) La position du ct gauche du contrle un chiffre
LocalPort
Port couter pour recevoir des paquets ou des demandes de

connexion
un chiffre de 0 65 000
Protocol
Protocole utiliser
0 pour TCP et 1 pour UDP
RemoteHost L'adresse de l'hte auquel il faut envoyer des paquets (UDP)
une adresse ip: 192.168.0.1,

125.124.368.14, ... ou un DNS.
RemotePort
Le port de l'hte auquel il faut envoyer des paquets (UDP)
un chiffre de 0 65 000
Tag
*(Quand il est sur une feuille) Une proprit pour stocker des
donnes, ce que l'on veut
ce que l'on veut
Top
*(Quand il est sur une feuille) La position du haut du contrle
un chiffre
Voici la liste des proprits de Winsock retournant une valeur en lecture seule.
Nom
Rsultat
BytesReceived
Nombre de BYTES reus
LocalHostName
Nom d'hte de cet ordinateur
RemoteHostIP
Adresse IP de l'hte auquel on est connect

Le handle du socket qui est utilis (la section que l'API winsock a d lui rserver)
SocketHandle
State
L'tat du socket (connect, erreur, attente de connexion, ...)
Voici la liste des vnements que Winsock peut dclencher. Normalement, tout va bien dans une feuille, mais pour la
classe, vous devez utiliser Withevents puis lui crer un instance et il n'y aura pas de problme.
Nom
Close()
Description des arguments
Description
Fermeture d'une connexion
(TCP)
Connect()
Connexion russie (TCP)
ConnectionRequest(ByVal requestID As Long)
l'ID d'une requte de

connexion)
Demande de connexion
(TCP)
DataArrival(ByVal bytesTotal As Long)
Le nombre de bytes qui

arrivent
Arrive de donnes
Error(ByVal Number As Integer, Description As String, ByVal

Scode As Long, ByVal Source As String, ByVal HelpFile As
String, ByVal HelpContext As Long, CancelDisplay As
Boolean)
Informations relatives
l'erreur (numro, description, Erreur!!!!!!
...)
SendComplete()
SendProgress(ByVal bytesSent As Long, ByVal
bytesRemaining As Long)
Envoi des donnes termin

Nombre de bytes envoyes
Nombre de bytes qui reste
envoyer
Envoi des donnes en cours

...
Avec c'est diffrentes mthodes et proprits, vous serez capables de crer des applications utilisant Winsock.
3 - Mode connect
3.2 - Le mode client

Voici le code expliqu d'un client en Tcp. Il est bien sur requis une feuille avec un bouton command1 et un
contrle socket.
Private Sub Command1_Click() socket.Connect "www.google.com", 80 'On se connecte www.google.com sur le port
80 End Sub
Private Sub socket_Close() 'Fin de la connexion MsgBox "connexion termine!" socket.Close 'Fermeture du socket End
Sub
Private Sub socket_Connect() 'Connexion tablie MsgBox "connexion ressie!" socket.SendData "GET / HTTP/1.0" &
vbCrLf & "Accept: */*" & vbCrLf & "User-Agent: Winsock" & vbCrLf & vbCrLf 'On envoie des donnes au serveur, ici
c'est une requte HTTP End Sub
Private Sub socket_DataArrival(ByVal bytesTotal As Long) 'Arrive de donnes Dim data As String If socket.State <>
sckConnected Then Exit Sub 'Juste au cas o a a bugg socket.GetData data, vbString 'On rcupre les donnes
'DONNES DANS DATA MsgBox data End Sub
Private Sub socket_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As
String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean) Err.Clear 'On ignore l'erreur
End Sub
Voici comment crer un client http sans utiliser le contrle Winsock, mais plutt l'objet rfrence.
Public WithEvents socket As Winsock 'Pour les vnements
Private Sub Command1_Click() socket.Connect "www.google.com", 80 'On se connecte www.google.com sur le port
80 End Sub
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer) Set socket = Nothing 'On vide l'objet
winsock End Sub
Private Sub socket_Close() 'Fin de la connexion MsgBox "connexion termine!" socket.Close 'Fermeture du socket End
Sub
Private Sub socket_Connect() 'Connexion tablie MsgBox "connexion ressie!" socket.SendData "GET / HTTP/1.0" &
vbCrLf & "Accept: */*" & vbCrLf & "User-Agent: Winsock" & vbCrLf & vbCrLf 'On envoie des donnes au serveur, ici
c'est une requte HTTP End Sub
Private Sub socket_DataArrival(ByVal bytesTotal As Long) 'Arrive de donnes Dim data As String If socket.State <>
sckConnected Then Exit Sub 'Juste au cas o a a bugg socket.GetData data, vbString 'On rcupre les donnes
'DONNES DANS DATA MsgBox data End Sub
Private Sub socket_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As
String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean) Err.Clear 'On ignore l'erreur
End Sub
Private Sub Form_Load() Set socket = New Winsock 'On initialise winsock 'With socket '.param1=??? '.param2=???
'End With End Sub
3.3 - Le mode serveur
3.3.1 - Sur une feuille
Voici le code expliqu d'un serveur avec un seul client Tcp simultan. Il est bien sur requis une feuille avec
un bouton command1 et un contrle Winsock socket.
Private Sub Command1_Click() socket.Close 'UN SOCKET DOIT TRE FERMER AVANT D'TRE MIS EN COUTE!!!
socket.LocalPort = 95 'coute port 95 socket.Listen End Sub
Private Sub socket_Close() 'Fermeture du socket MsgBox "connexion termine!" socket.Close 'S'assurer que le
socket se ferme car sinon, a peut tre trs drle ;-) Command1_Click End Sub
Private Sub socket_ConnectionRequest(ByVal requestID As Long) 'Demande de connexion MsgBox "Demande de
connexion!" socket.Close 'UN SOCKET DOIT TRE FERMER AVANT D'ACCEPTER UNE CONNEXION!!! 'Bon, ya u
gros problme. c'est une connexion par socket. QUE FAIRE!!! socket.Accept requestID 'Une autre contrle
winsock peut trs bien accepter cette demande... End Sub
Private Sub socket_DataArrival(ByVal bytesTotal As Long) 'Arrive des donnes Dim data As String If
socket.State <> sckConnected Then Exit Sub 'En cas de problmes ... on ne sait pas socket.GetData data,
vbString MsgBox data 'Ce que le client dit (on s'en fiche tu :-) 'Ce qu'on lui rpond : Dim envoie As String envoie
= "<html><head><title>Salut</title></head><body>Allo</body></html>" 'La rponse envoyer
socket.SendData "HTTP/1.0 200 OK" & vbCrLf & "Server: Winsock/6.0" & vbCrLf & "Content-Type: text/html" &
vbCrLf & "Content-Lenght: " & Len(envoie) & vbCrLf & vbCrLf & envoie 'Une rponse HTTP ^ End Sub
Private Sub socket_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source
As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean) Err.Clear 'En cas
d'erreur, ignorer End Sub
Private Sub socket_SendComplete() socket.Close 'On ferme End Sub
Voici la partie serveur multi-clients. il est bien sur requis une feuille avec un bouton command1 et deux
contrles Winsock socket et coute.
Private Sub Command1_Click() 'Le socket est ouvert et il restera ouvert If ecoute.State = 2 Then Exit Sub 'Si on
coute dj, on quitte la procdure ecoute.LocalPort = 95 ecoute.Listen End Sub
Private Sub ecoute_ConnectionRequest(ByVal requestID As Long) 'LE TRS GROS MORCEAU Dim nb As Integer
nb = socket.Count 'Le nombre de socket dans la collection. Comme le 0 compte, pas besoins de rajouter +1.
Load socket(nb) 'On ajoute ajoute un autre socket dans la collection de ce contrle socket(nb).Accept requestID
'CE contrle fesant partit de la collection accepte la requte Debug.Print "Client ajout : " &
socket(nb).RemoteHostIP End Sub
Private Sub ecoute_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source
Private Sub socket_Close(Index As Integer) socket_SendComplete Index 'Si le socket se ferme, fait comme si
l'envoie serait fini End Sub
Private Sub socket_DataArrival(Index As Integer, ByVal bytesTotal As Long) 'NOTEZ BIEN L'ARGUMENT INDEX.
IL RETOURE L'INDEX DE CE SOCKET DANS LA COLLECTION 'Ce que le client dit (on s'en fiche tu :-) 'Ce qu'on lui
rpond : Dim envoie As String envoie = "<html><head><title>Salut</title></head><body>a" &
String$(10000, "l") & "o</body></html>" 'La rponse envoyer Debug.Print "Envoie du socket # " & Index & "
" & Now socket(Index).SendData "HTTP/1.0 200 OK" & vbCrLf & "Server: Winsock/6.0" & vbCrLf & "ContentType: text/html" & vbCrLf & "Content-Lenght: " & Len(envoie) & vbCrLf & "Pragma: no-cache" & vbCrLf & vbCrLf
& envoie 'Une rponse HTTP ^ End Sub
Private Sub socket_Error(Index As Integer, ByVal Number As Integer, Description As String, ByVal Scode As
Long, ByVal Source As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean)
Err.Clear 'En cas d'erreur, ignorer End Sub
Private Sub socket_SendComplete(Index As Integer) socket(Index).Close 'Fermer le socket Debug.Print
"Fermeture du socket # " & Index & " " & Now If Index <> 0 Then Unload socket(Index) 'Si le socket n'est pas
le 0 (celui de base), on le FLUSH End Sub
3.3.2 - Dans une classe
Pour un serveur avec un seul client, c'est la mme chose que sur une feuille sauf qu'il faut utiliser Winsock
comme rfrence et le dclarer avec Withevents. Pour un serveur multi-clients, c'est plus complexe.
Voici la partie cliente Classe 1.
Public WithEvents socket As Winsock
Public MyNum As Long
Private Sub Class_Initialize() Set socket = New Winsock End Sub
Private Sub Class_Terminate() Set socket = Nothing End Sub

Private Sub socket_Close() Form1.Killsocket MyNum 'S'assurer que le socket se ferme car sinon, a peut tre
trs drle ;-) End Sub
Private Sub socket_DataArrival(ByVal bytesTotal As Long) 'Ce qu'on lui rpond : Debug.Print "OK" Dim envoie As
String envoie = "<html><head><title>Salut</title></head><body>A" & String$(1000, "l") &
"o</body></html>" 'La rponse envoyer socket.SendData "HTTP/1.0 200 OK" & vbCrLf & "Server:
Winsock/6.0" & vbCrLf & "Content-Type: text/html" & vbCrLf & "Content-Lenght: " & Len(envoie) & vbCrLf &
vbCrLf & envoie 'Une rponse HTTP ^ End Sub
Private Sub socket_SendComplete() socket.Close 'On ferme End Sub
Voici la partie clients Classe 2.
Private WithEvents socket As Winsock
Public Sockets As New Collection
Public Num As Long
Private Sub Class_Initialize() Set socket = New Winsock With socket .LocalPort = 95 .Listen End With End Sub
Private Sub Class_Terminate() Set Sockets = Nothing Set socket = Nothing End Sub
Private Sub socket_ConnectionRequest(ByVal requestID As Long) Dim buf As New Client buf.socket.Accept
requestID buf.MyNum = Num Num = Num + 1 Sockets.Add buf End Sub
As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean) Err.Clear End Sub
Voici la dfinition de la feuille que l'on peux, au passage, se passer.
Private Clients As Clients
'JUSTE POUR DMARRER ET NETTOYER CAR J'AI PAS ENVIE DE ME CASSER LA TTE
Private Sub Form_Load() Set Clients = New Clients End Sub
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer) Set Clients = Nothing End Sub
Sub Killsocket(MyNum As Long) For i = 1 To Clients.Sockets.Count If Clients.Sockets.MyNum = MyNum Then
Clients.Sockets.Remove i Next End Sub
C'est trs simple, le serveur commence couter un port pour attendre une connexion Tcp. Ds qu'un client
envoie une demande de connexion, le serveur l'accepte et tablit l'ouverture de session avec le client. Le serveur
et le client sont maintenant connects et peuvent donc envoyer et recevoir des donnes. Quand le serveur arrte
la connexion, le client s'en rend compte grce l'vnement socket_close. La fermeture de la session TCP peux
tre
demand
par
le
client
ou
par
le
serveur.
Les sources et l'exe peuvent tre tlcharg ici.
Private Sub CheckState_Timer()
If Clients.ListCount = 0 Then send.Enabled = False Else: send.Enabled = True 'Si il n'y a pas de client, pourquoi
envoyer un message?
If Ecoute.State = 0 Then Go.Caption = "couter" Else: Go.Caption = "Arrter le serveur" 'Placer le texte du bouton
Go
End Sub
Private Sub Clients_MouseUp(Button As Integer, Shift As Integer, X As Single, Y As Single)
If Button = vbRightButton And Clients.ListIndex <> -1 Then 'Si on clique avec le bouton droit et qu'on a slectionner
un ip dans la liste, on affiche le menu
PopupMenu pop
End If
End Sub
Private Sub Decon_Click() 'ON LE BOOT!!
Dim col
col = Split(Clients.List(Clients.ListIndex), ":") 'On rcuprre son # de socket (aprs le ":")
Socket_Close (CInt(col(1))) 'On fait comme s'il aurait quitt
End Sub
Private Sub Ecoute_ConnectionRequest(ByVal requestID As Long) 'Demande de connexion
Dim Nb As Integer
Nb = Socket.Count '# de la prochaince socket disponible (LIMITE : 65535 CAR TYPE INTEGER = SUR 4 OCTETS
(FFFF))
Load Socket(Nb) 'On charge ce socket
Socket(Nb).Accept requestID 'On fait accepter la connexion
recep.Text = recep.Text & recep.Text & "<system> : Connexion tablie avec " & Socket(Nb).RemoteHostIP & " !" &
vbCrLf & vbCrLf 'On dit que le client c'est connect
Clients.AddItem Socket(Nb).RemoteHostIP & ":" & Nb 'On met son IP suivit de ":" et son 1 de socket dans la liste
End Sub
Private Sub Ecoute_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As
String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean) 'Erreur!
MsgBox "Erreur avec le socket! & vbcrlf # " & Number & vbCrLf & Description
Ecoute.Close
End Sub
Private Sub Form_Load()
CheckState_Timer 'On fait faire une premire vrification avec le timer
End Sub
Private Sub Go_Click() 'On appuie sur le bouton Go
On Error Resume Next
If Ecoute.State = 2 Then 'Si on coutait, ben on ferme
Ecoute.Close
For i = 1 To Socket.Count - 1 'On dcharge tout les sockets
Socket(i).Close
Unload Socket(i) 'On dtruit l'objet crer (0 ne peut pas tre unload)
Next
Else 'Sinon ben on coute
Ecoute.LocalPort = Port.Text 'Le port
Ecoute.Listen 'On coute
If Err.Number <> 0 Then 'ERREUR, POURQUOI ON PEUT PAS COUTER (srement que le port est occup)
MsgBox "Erreur avec le socket! & vbcrlf # " & Err.Number & vbCrLf & Err.Description 'On dit pourquoi
Err.Clear 'On nettoie l'erreur
End If
End If
End Sub
Private Sub send_Click() 'Envoie du message, comme avec le client
recep.Text = recep.Text & "<you> : " & vbCrLf & Emission.Text & vbCrLf & vbCrLf
For i = 1 To Socket.Count - 1
Socket(i).SendData Emission.Text
Next
Emission.Text = ""
End Sub
Private Sub Socket_Close(Index As Integer) 'Le client vient de quitter ou il s'est fait booter
Dim col
For i = 0 To Clients.ListCount - 1 'On cherche son # de socket pour l'enlever de la liste
col = Split(Clients.List(i), ":")
If col(1) = Index Then
Socket(col(1)).Close
Unload Socket(col(1)) 'On kill le socket
recep.Text = recep.Text & recep.Text & "<system> : Connexion termine avec " & col(0) & " !" & vbCrLf & vbCrLf 'On
dit qu'il quitte
Clients.RemoveItem i 'On l'enlve de la liste
Exit For 'Pas besoins de continuer
End If
Next
End Sub
Private Sub Socket_DataArrival(Index As Integer, ByVal bytesTotal As Long) 'Arrive des donnes, comme avec le
client
Dim data As String
Socket(Index).GetData data, vbString
recep.Text = recep.Text & "<" & Socket(Index).RemoteHostIP & "> : " & vbCrLf & data & vbCrLf & vbCrLf
End Sub
4 - Mode non connect

4.2 - Le mode client et serveur

Udp est orient sans connexion, donc il ncessite peu de code. C'est le mme fonctionnement que Tcp, mais il n'y
a pas de session, donc pas de fermeture de connexion. Il est bien sur requis deux Sockets en tant que contrle ou
objet socket1 et socket2 avec le protocole Udp de slectionn!
'SOCKET 1 EST LE "CLIENT" ET LE 2 EST LE "SERVEUR"
Private Sub Form_Load() On Error Resume Next 'UDP PLANTE DESFOIS!!! socket2.Bind 98, "0.0.0.0" 'PORT
COUTER socket1.RemoteHost = "127.0.0.1" 'Adresse auquel il faut envoyer le(s) datagramme(s)
socket1.RemotePort = 98 'Port auquel il faut envoyer le(s) datagramme(s) socket1.SendData "drole" 'Envoyer les
donnes End Sub
Private Sub Form_Unload(Cancel As Integer) socket2.Close 'Arrter d'couter le port UDP 98 End Sub
Private Sub socket1_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As
String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean) Err.Clear 'Ignorer l'erreur End
Sub
Private Sub socket2_DataArrival(ByVal bytesTotal As Long) Dim data As String socket2.GetData data, vbString
'Prendre les donnes comme avec tcp MsgBox "Message de " & socket2.RemoteHostIP & " : " & data End Sub
Private Sub socket2_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As
String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean) Err.Clear 'Ignorer l'erreur End
Sub
Le principe d'Udp est simple. Premirement, un "serveur" dcide de commencer couter un port et attend
l'arrive de paquets de donnes. Un client lui envoie un datagramme en spcifiant l'adresse ip et ports de
destination ainsi que la correspondance de retour. Le client utilise LocalPort=le_#_du_port pour spcifier le port
sur lequel il attend une rponse, pus communment appel port source. Quand le serveur reoit un paquet, il
dtermine les coordonnes de l'metteur et peut ainsi lui rpondre. Il n'y a pas de session donc pas de fermeture
de
connexion,
cela
permet
d'effectuer
des
changes
courts
et
rapides.
Les sources et l'exe peuvent tre tlcharg ici.
Option Explicit
Private Sub CheckState_Timer()
If Socket.State = 1 Then Go.Caption = "Arrter" Else: Go.Caption = "couter"
End Sub
Private Sub Go_Click()
If Socket.State <> 1 Then
Socket.Close
Socket.Bind port.Text, addr.Text
If Err.Number <> 0 Then 'ERREUR, POURQUOI ON PEUT PAS COUTER (srement que le port est occup)
MsgBox "Erreur avec le socket! & vbcrlf # " & Err.Number & vbCrLf & Err.Description 'On dit pourquoi
Err.Clear 'On nettoie l'erreur
End If
Else
Socket.Close
End If
End Sub
Private Sub send_Click()
If Socket.State <> 1 Then 'On prend 1 port pour recevoir les messages du recpteur
Socket.LocalPort = 0 'N'IMPORTE QUEL PORT LIBRE
End If
Socket.RemoteHost = sendaddr.Text 'L'adresse o ilo faut envoyer les donnes
Socket.RemotePort = sendport.Text 'Le port o ilo faut envoyer les donnes
Socket.SendData Emission.Text 'On envoie (A PEUT BOGUER POUR RIEN!!!)
recep.Text = recep.Text & "<you> : " & vbCrLf & Emission.Text & vbCrLf & vbCrLf 'Pour savoir ce qu'on a envoyer
Emission.Text = "" 'On fait de la place pour un nouveau message
End Sub
Private Sub Socket_DataArrival(ByVal bytesTotal As Long)
Dim data As String
Socket.GetData data, vbString 'On les met dans la variable data
recep.Text = recep.Text & "<" & Socket.RemoteHostIP & "> : " & vbCrLf & data & vbCrLf & vbCrLf 'Pour dire qui
envoyer le message
sendaddr.Text = Socket.RemoteHostIP 'On garde son adresse et on peut lui rpondre
sendport.Text = Socket.RemotePort 'On garde son port et on peut lui rpondre
Beep
End Sub
Private Sub Socket_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As
String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean)
'ERREUR!!! ON AFFICHE L'ERRREUR ET ON FERME LE SOCKET
MsgBox "Erreur avec le socket! & vbcrlf # " & Number & vbCrLf & Description
Socket.Close
End Sub
La scurit
Liste des blocks Ip Fdraux

1 - Liste des blocks Fdraux
2 - ACL Cisco
2.1 - Appel depuis l'interface
2.2 - Access-List
3 - NetFilter
1 - Liste des blocks Fdraux

Voici la liste officieuse des blocks d'adresses Ip fdraux. Vous y trouverez dedant des plages d'adresses IP franaises :
French Department of Defense et French Military Police.
Adresse de dpart Adresse de fin
Masque Description
4.42.244.160
4.42.244.175
28
Federal Bureau of Investigation
4.42.244.192
4.42.244.223
27
12.38.31.216
12.38.31.223
29
29.0.0.0
29.255.255.255
DoD Network Information Center
61.88.128.38
61.88.128.38
32
Australian Federal Police (proxy server)
63.64.5.0
63.64.5.255
24
Cyveillance
63.78.79.144
63.78.79.151
29
Police Protective Le UU-63-78-79-144
63.100.163.0
63.100.163.255
24
CYVEILLANCE (unlisted)
63.100.235.128
63.100.235.191
26
Syntrillium Software
63.127.255.0
63.127.255.255
24
Cyveillance
63.148.99.224
63.148.99.255
27
Cyveillance
63.163.104.32
63.163.104.47
28
Department of Homeland Security SPRINTLINK
64.115.129.144
64.115.129.151
29
Internal Intelligence Service 973242S101-BDVU
65.118.41.192
65.118.41.223
27
Cyveillance
65.173.188.0
65.173.189.255
24
65.174.230.32
65.174.230.47
28
66.72.93.16
66.72.93.23
29
Police Intelligence Network SBCIS-101529-164145
66.109.166.136
66.109.166.143
29
Office of Law Enforcement Tech. OLETCINCDSL
66.109.166.144
66.109.166.151
29
Office of Law Enforcement Tech. OLETCINCCONREACH
130.46.0.0
130.46.255.255
16
130.109.0.0
130.109.255.255
16
131.73.0.0
131.73.255.255
16
131.80.0.0
131.80.255.255
16
131.81.0.0
131.81.255.255
16
131.83.0.0
131.83.255.255
16
131.85.0.0
131.85.255.255
16
131.88.0.0
131.88.255.255
16
131.185.0.0
131.185.255.255
16
Australian Department of Defence DSTO
131.240.0.0
131.240.255.255
16
132.37.0.0
132.37.255.255
16
132.39.0.0
132.39.255.255
16
132.80.0.0
132.80.255.255
16
132.81.0.0
132.81.255.255
16
132.82.0.0
132.82.255.255
16
132.83.0.0
132.83.255.255
16
132.84.0.0
132.84.255.255
16
132.85.0.0
132.85.255.255
16
132.86.0.0
132.86.255.255
16
132.87.0.0
132.87.255.255
16
132.95.0.0
132.95.255.255
16
132.96.0.0
132.96.255.255
16
132.97.0.0
132.97.255.255
16
132.98.0.0
132.98.255.255
16
132.99.0.0
132.99.255.255
16
132.100.0.0
132.100.255.255
16
132.101.0.0
132.101.255.255
16
132.102.0.0
132.102.255.255
16
132.103.0.0
132.103.255.255
16
132.133.0.0
132.133.255.255
16
132.134.0.0
132.134.255.255
16
132.135.0.0
132.135.255.255
16
132.136.0.0
132.136.255.255
16
132.137.0.0
132.137.255.255
16
132.138.0.0
132.138.255.255
16
132.139.0.0
132.139.255.255
16
132.140.0.0
132.140.255.255
16
132.141.0.0
132.141.255.255
16
132.142.0.0
132.142.255.255
16
132.143.0.0
132.143.255.255
16
132.144.0.0
132.144.255.255
16
134.194.0.0
134.194.255.255
16
134.229.0.0
134.229.255.255
16
134.230.0.0
134.230.255.255
16
134.232.0.0
134.232.255.255
16
134.254.0.0
134.254.255.255
16
136.188.0.0
136.188.255.255
16
136.189.0.0
136.189.255.255
16
136.190.0.0
136.190.255.255
16
136.191.0.0
136.191.255.255
16
136.192.0.0
136.192.255.255
16
136.193.0.0
136.193.255.255
16
136.194.0.0
136.194.255.255
16
136.195.0.0
136.195.255.255
16
136.196.0.0
136.196.255.255
16
136.197.0.0
136.197.255.255
16
136.208.0.0
136.208.255.255
16
136.211.0.0
136.211.255.255
16
136.212.0.0
136.212.255.255
16
136.213.0.0
136.213.255.255
16
136.214.0.0
136.214.255.255
16
136.222.0.0
136.222.255.255
16
137.130.0.0
137.130.255.255
16
137.191.0.0
137.191.255.255
16
Irish Department of Defense
137.209.0.0
137.209.255.255
16
137.210.0.0
137.210.255.255
16
137.211.0.0
137.211.255.255
16
137.212.0.0
137.212.255.255
16
137.231.0.0
137.231.255.255
16
137.232.0.0
137.232.255.255
16
137.233.0.0
137.233.255.255
16
137.234.0.0
137.234.255.255
16
137.235.0.0
137.235.255.255
16
137.246.0.0
137.246.255.255
16
137.247.0.0
137.247.255.255
16
138.60.0.0
138.60.255.255
16
138.135.0.0
138.135.255.255
16
138.136.0.0
138.136.255.255
16
138.150.0.0
138.150.255.255
16
138.151.0.0
138.151.255.255
16
138.153.0.0
138.153.255.255
16
138.159.0.0
138.159.255.255
16
138.170.0.0
138.170.255.255
16
139.77.0.0
139.77.255.255
16
139.233.0.0
139.233.255.255
16
139.234.0.0
139.234.255.255
16
139.235.0.0
139.235.255.255
16
139.236.0.0
139.236.255.255
16
139.237.0.0
139.237.255.255
16
139.238.0.0
139.238.255.255
16
139.239.0.0
139.239.255.255
16
139.240.0.0
139.240.255.255
16
139.241.0.0
139.241.255.255
16
139.242.0.0
139.242.255.255
16
139.243.0.0
139.243.255.255
16
139.244.0.0
139.244.255.255
16
139.245.0.0
139.245.255.255
16
139.246.0.0
139.246.255.255
16
139.247.0.0
139.247.255.255
16
139.248.0.0
139.248.255.255
16
139.249.0.0
139.249.255.255
16
139.250.0.0
139.250.255.255
16
139.251.0.0
139.251.255.255
16
139.252.0.0
139.252.255.255
16
139.253.0.0
139.253.255.255
16
139.254.0.0
139.254.255.255
16
140.1.0.0
140.1.255.255
16
140.2.0.0
140.2.255.255
16
140.3.0.0
140.3.255.255
16
140.4.0.0
140.4.255.255
16
140.5.0.0
140.5.255.255
16
140.6.0.0
140.6.255.255
16
140.7.0.0
140.7.255.255
16
140.8.0.0
140.8.255.255
16
140.9.0.0
140.9.255.255
16
140.10.0.0
140.10.255.255
16
140.11.0.0
140.11.255.255
16
140.12.0.0
140.12.255.255
16
140.13.0.0
140.13.255.255
16
140.15.0.0
140.15.255.255
16
140.16.0.0
140.16.255.255
16
140.17.0.0
140.17.255.255
16
140.18.0.0
140.18.255.255
16
140.19.0.0
140.19.255.255
16
140.20.0.0
140.20.255.255
16
140.21.0.0
140.21.255.255
16
140.22.0.0
140.22.255.255
16
140.23.0.0
140.23.255.255
16
140.24.0.0
140.24.255.255
16
140.25.0.0
140.25.255.255
16
140.26.0.0
140.26.255.255
16
140.27.0.0
140.27.255.255
16
140.28.0.0
140.28.255.255
16
140.29.0.0
140.29.255.255
16
140.30.0.0
140.30.255.255
16
140.31.0.0
140.31.255.255
16
140.32.0.0
140.32.255.255
16
140.33.0.0
140.33.255.255
16
140.34.0.0
140.34.255.255
16
140.35.0.0
140.35.255.255
16
140.36.0.0
140.36.255.255
16
140.37.0.0
140.37.255.255
16
140.38.0.0
140.38.255.255
16
140.39.0.0
140.39.255.255
16
140.40.0.0
140.40.255.255
16
140.41.0.0
140.41.255.255
16
140.42.0.0
140.42.255.255
16
140.44.0.0
140.44.255.255
16
140.45.0.0
140.45.255.255
16
140.46.0.0
140.46.255.255
16
140.47.0.0
140.47.255.255
16
140.48.0.0
140.48.255.255
16
140.49.0.0
140.49.255.255
16
140.50.0.0
140.50.255.255
16
140.51.0.0
140.51.255.255
16
140.52.0.0
140.52.255.255
16
140.53.0.0
140.53.255.255
16
140.54.0.0
140.54.255.255
16
140.55.0.0
140.55.255.255
16
140.56.0.0
140.56.255.255
16
140.57.0.0
140.57.255.255
16
140.58.0.0
140.58.255.255
16
140.59.0.0
140.59.255.255
16
140.60.0.0
140.60.255.255
16
140.61.0.0
140.61.255.255
16
140.62.0.0
140.62.255.255
16
140.63.0.0
140.63.255.255
16
140.64.0.0
140.64.255.255
16
140.65.0.0
140.65.255.255
16
140.66.0.0
140.66.255.255
16
140.67.0.0
140.67.255.255
16
140.68.0.0
140.68.255.255
16
140.69.0.0
140.69.255.255
16
140.70.0.0
140.70.255.255
16
140.71.0.0
140.71.255.255
16
140.72.0.0
140.72.255.255
16
140.73.0.0
140.73.255.255
16
140.74.0.0
140.74.255.255
16
140.194.0.0
140.194.255.255
16
140.199.0.0
140.199.255.255
16
146.221.0.0
146.221.255.255
16
Australian Department of Defence DOD-AU
147.186.0.0
147.186.255.255
16
[se] police
149.101.0.0
149.101.255.255
16
US Department of Justice
152.91.0.0
152.91.255.255
16
claims to be an Australian government dept that no longer exists,

associated with 90East.com, an Internet security site
153.31.0.0
153.31.255.255
16
Federal Bureau of Investigation-CJIS
160.64.0.0
160.64.255.255
16
Australian Department of Defence DSTOMEL1
162.23.0.0
162.23.255.255
16
Swiss Federal Government, Swiss Federal Office of Information

Technology and Systems, Bundesamt fur Informatik
162.45.0.0
162.45.255.255
16
Central Intelligence Agency CIA
164.112.0.0
164.112.255.255
16
Queensland Police Service
164.128.37.17
164.128.223.145
17
Police of Switzerland
164.141.0.0
164.141.255.255
16
Police Administration in Finland
165.142.0.0
165.142.255.255
16
Department of Justice AUVICDJUST
165.187.0.0
165.187.255.255
16
Western Australian Police Department WAPOL
166.64.0.0
166.64.255.255
16
New South Wales Police Service NSWPOLICE
168.152.0.0
168.152.255.255
16
Australian Federal Police AFP-AU-B1
192.58.200.0
192.58.203.255
22
Department of Justice GOVDOJBLS01
192.84.170.0
192.84.170.255
24
192.190.61.0
192.190.61.255
24
Tasmania Police Department TASPOL
192.190.66.0
192.190.66.255
24
Australian Institute of Criminology AIC
192.251.207.0
192.251.207.255
24
Australian Army Support Agency SYS-SPT-ARMY
193.77.9.0
193.77.9.255
24
Hacker from Slovenia
193.121.83.1
193.121.83.255
24
Federale politie - Police federale (BELGIUM)
193.172.176.0
193.172.177.255
24
Dutch Government
193.191.209.192
193.191.209.207
28
Belgium Federal Government
193.252.72.142
193.252.72.142
32
French Department of Defense
193.252.228.0
193.252.228.255
24
Prefecture de police de Paris
194.89.205.0
194.89.205.255
24
Finnish Police
195.46.218.178
195.46.218.178
32
French Military Police
195.76.172.0
195.76.172.255
24
Direccion General de la Policia (SPAIN)
195.76.204.0
195.76.204.255
24
Ministerio del Interior (Spain)
195.162.203.0
195.162.203.7
29
Politie-Belgium (Federal Computer Crime Unit)
198.61.8.0
198.61.15.255
21
Tasmania Police Department NETBLK-TASPOL
198.137.240.0
198.137.241.255
24
Executive Office Of The President USA
198.165.21.64
198.165.21.79
28
Department of Justice GT-198-165-21-64-CX
198.190.209.0
198.190.209.255
24
199.75.96.0
199.75.107.255
21
Organization of American States (www.ftaa-alca.org)
199.123.80.0
199.123.80.255
24
US Army Criminal Investigation Command ACIRS-DEV
199.212.192.0
199.212.216.255
19
Department of Justice DOJ-GC-CA
199.227.159.64
199.227.159.95
27
Epic EPIC-200309091608751 (NET-199-227-159-64-1)
203.25.230.0
203.25.231.255
24
Victoria Police Centre
204.75.224.0
204.75.224.255
24
Office of the Sheriff, Rusk County, Texas
204.91.138.0
204.91.138.255
24
EPIC EPIC2-NET (NET-204-91-138-0-1)
205.128.1.240
205.128.1.255
28
Office of the Inspector General OIG-1-05
205.229.233.0
205.229.233.255
24
206.212.128.0
206.212.191.255
18
New York City Police Department NYPD-GOV
206.218.64.0
206.218.127.255
18
Office of the Attorney General, State of Texas
206.241.30.0
206.241.31.255
24
US Customs
207.43.55.0
207.43.55.255
24
207.132.172.0
207.132.175.255
22
Office of the Judge Advocate General, US Navy
207.132.176.0
207.132.191.255
20
Office of the Judge Advocate General, US Navy
207.155.128.0
207.155.255.255
17
NetPD
212.31.111.172
212.31.111.175
30
Cyprus Police
214.0.0.0
214.255.255.255
215.0.0.0
215.255.255.255
DoD Network Information Center (More)
216.118.66.0
216.118.66.255
24
Brussel politie - Police bruxelles
216.146.85.224
216.146.85.255
27
217.167.182.0
217.167.182.255
24
French Department of Defense
2 - ACL Cisco
Voici un exemple d'Access List Cisco, permettant de dropper toutes les trames vennant de l'un de ces rseaux.
2.1 - Appel depuis l'interface
Vous devez appeler l'Access-List partir de votre interface Wan et lui indiquer de dropper les paquets matchs
par cette Acl.
Interface Wan
ip access-group ACL_ENTRANTE in
2.2 - Access-List
Voici l'Acl se terminant bien videment par un permit Any.
ip access-list extended ACL_ENTRANTE
deny ip 4.42.244.160 0.0.0.15 any
deny ip 4.42.244.192 0.0.0.31 any
deny ip 12.38.31.216 0.0.0.7 any
deny ip 29.0.0.0 0.255.255.255 any
deny ip 61.88.128.38 0.0.0.0 any
deny ip 63.64.5.0 0.0.0.255 any
deny ip 63.78.79.144 0.0.0.7 any
deny ip 63.100.163.0 0.0.0.255 any
deny ip 63.100.235.128 0.0.0.63 any
deny ip 63.127.255.0 0.0.0.255 any
deny ip 63.148.99.224 0.0.0.31 any
deny ip 63.163.104.32 0.0.0.15 any
deny ip 64.115.129.144 0.0.0.7 any
deny ip 65.118.41.192 0.0.0.31 any
deny ip 65.173.188.0 0.0.0.255 any
deny ip 65.174.230.32 0.0.0.15 any
deny ip 66.72.93.16 0.0.0.7 any
deny ip 66.109.166.136 0.0.0.7 any
deny ip 66.109.166.144 0.0.0.7 any
deny ip 130.46.0.0 0.0.255.255 any
deny ip 130.109.0.0 0.0.255.255 any
deny ip 131.73.0.0 0.0.255.255 any
deny ip 131.80.0.0 0.0.255.255 any
deny ip 131.81.0.0 0.0.255.255 any
deny ip 131.83.0.0 0.0.255.255 any
deny ip 131.85.0.0 0.0.255.255 any
deny ip 131.88.0.0 0.0.255.255 any
deny ip 131.185.0.0 0.0.255.255 any
deny ip 131.240.0.0 0.0.255.255 any
deny ip 132.37.0.0 0.0.255.255 any
deny ip 132.39.0.0 0.0.255.255 any
deny ip 132.80.0.0 0.0.255.255 any
deny ip 132.81.0.0 0.0.255.255 any
deny ip 132.82.0.0 0.0.255.255 any
deny ip 132.83.0.0 0.0.255.255 any
deny ip 132.84.0.0 0.0.255.255 any
deny ip 132.85.0.0 0.0.255.255 any
deny ip 132.86.0.0 0.0.255.255 any
deny ip 132.87.0.0 0.0.255.255 any
deny ip 132.95.0.0 0.0.255.255 any
deny ip 132.96.0.0 0.0.255.255 any
deny ip 132.97.0.0 0.0.255.255 any
deny ip 132.98.0.0 0.0.255.255 any
deny ip 132.99.0.0 0.0.255.255 any
deny ip 132.100.0.0 0.0.255.255 any
deny ip 132.101.0.0 0.0.255.255 any
deny ip 132.102.0.0 0.0.255.255 any
deny ip 132.103.0.0 0.0.255.255 any
deny ip 132.133.0.0 0.0.255.255 any
deny ip 132.134.0.0 0.0.255.255 any
deny ip 132.135.0.0 0.0.255.255 any
deny ip 132.136.0.0 0.0.255.255 any
deny ip 132.137.0.0 0.0.255.255 any
deny ip 132.138.0.0 0.0.255.255 any
deny ip 132.139.0.0 0.0.255.255 any
deny ip 132.140.0.0 0.0.255.255 any
deny ip 132.141.0.0 0.0.255.255 any
deny ip 132.142.0.0 0.0.255.255 any
deny ip 132.143.0.0 0.0.255.255 any
deny ip 132.144.0.0 0.0.255.255 any
deny ip 134.194.0.0 0.0.255.255 any
deny ip 134.229.0.0 0.0.255.255 any
deny ip 134.230.0.0 0.0.255.255 any
deny ip 134.232.0.0 0.0.255.255 any
deny ip 134.254.0.0 0.0.255.255 any
deny ip 136.188.0.0 0.0.255.255 any
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
136.189.0.0 0.0.255.255 any

136.190.0.0 0.0.255.255 any
136.191.0.0 0.0.255.255 any
136.192.0.0 0.0.255.255 any
136.193.0.0 0.0.255.255 any
136.194.0.0 0.0.255.255 any
136.195.0.0 0.0.255.255 any
136.196.0.0 0.0.255.255 any
136.197.0.0 0.0.255.255 any
136.208.0.0 0.0.255.255 any
136.211.0.0 0.0.255.255 any
136.212.0.0 0.0.255.255 any
136.213.0.0 0.0.255.255 any
136.214.0.0 0.0.255.255 any
136.222.0.0 0.0.255.255 any
137.130.0.0 0.0.255.255 any
137.191.0.0 0.0.255.255 any
137.209.0.0 0.0.255.255 any
137.210.0.0 0.0.255.255 any
137.211.0.0 0.0.255.255 any
137.212.0.0 0.0.255.255 any
137.231.0.0 0.0.255.255 any
137.232.0.0 0.0.255.255 any
137.233.0.0 0.0.255.255 any
137.234.0.0 0.0.255.255 any
137.235.0.0 0.0.255.255 any
137.246.0.0 0.0.255.255 any
137.247.0.0 0.0.255.255 any
138.60.0.0 0.0.255.255 any
138.135.0.0 0.0.255.255 any
138.136.0.0 0.0.255.255 any
138.150.0.0 0.0.255.255 any
138.151.0.0 0.0.255.255 any
138.153.0.0 0.0.255.255 any
138.159.0.0 0.0.255.255 any
138.170.0.0 0.0.255.255 any
139.77.0.0 0.0.255.255 any
139.233.0.0 0.0.255.255 any
139.234.0.0 0.0.255.255 any
139.235.0.0 0.0.255.255 any
139.236.0.0 0.0.255.255 any
139.237.0.0 0.0.255.255 any
139.238.0.0 0.0.255.255 any
139.239.0.0 0.0.255.255 any
139.240.0.0 0.0.255.255 any
139.241.0.0 0.0.255.255 any
139.242.0.0 0.0.255.255 any
139.243.0.0 0.0.255.255 any
139.244.0.0 0.0.255.255 any
139.245.0.0 0.0.255.255 any
139.246.0.0 0.0.255.255 any
139.247.0.0 0.0.255.255 any
139.248.0.0 0.0.255.255 any
139.249.0.0 0.0.255.255 any
139.250.0.0 0.0.255.255 any
139.251.0.0 0.0.255.255 any
139.252.0.0 0.0.255.255 any
139.253.0.0 0.0.255.255 any
139.254.0.0 0.0.255.255 any
140.1.0.0 0.0.255.255 any
140.2.0.0 0.0.255.255 any
140.3.0.0 0.0.255.255 any
140.4.0.0 0.0.255.255 any
140.5.0.0 0.0.255.255 any
140.6.0.0 0.0.255.255 any
140.7.0.0 0.0.255.255 any
140.8.0.0 0.0.255.255 any
140.9.0.0 0.0.255.255 any
140.10.0.0 0.0.255.255 any
140.11.0.0 0.0.255.255 any
140.12.0.0 0.0.255.255 any
140.13.0.0 0.0.255.255 any
140.15.0.0 0.0.255.255 any
140.16.0.0 0.0.255.255 any
140.17.0.0 0.0.255.255 any
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
deny
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
140.18.0.0 0.0.255.255 any

140.19.0.0 0.0.255.255 any
140.20.0.0 0.0.255.255 any
140.21.0.0 0.0.255.255 any
140.22.0.0 0.0.255.255 any
140.23.0.0 0.0.255.255 any
140.24.0.0 0.0.255.255 any
140.25.0.0 0.0.255.255 any
140.26.0.0 0.0.255.255 any
140.27.0.0 0.0.255.255 any
140.28.0.0 0.0.255.255 any
140.29.0.0 0.0.255.255 any
140.30.0.0 0.0.255.255 any
140.31.0.0 0.0.255.255 any
140.32.0.0 0.0.255.255 any
140.33.0.0 0.0.255.255 any
140.34.0.0 0.0.255.255 any
140.35.0.0 0.0.255.255 any
140.36.0.0 0.0.255.255 any
140.37.0.0 0.0.255.255 any
140.38.0.0 0.0.255.255 any
140.39.0.0 0.0.255.255 any
140.40.0.0 0.0.255.255 any
140.41.0.0 0.0.255.255 any
140.42.0.0 0.0.255.255 any
140.44.0.0 0.0.255.255 any
140.45.0.0 0.0.255.255 any
140.46.0.0 0.0.255.255 any
140.47.0.0 0.0.255.255 any
140.48.0.0 0.0.255.255 any
140.49.0.0 0.0.255.255 any
140.50.0.0 0.0.255.255 any
140.51.0.0 0.0.255.255 any
140.52.0.0 0.0.255.255 any
140.53.0.0 0.0.255.255 any
140.54.0.0 0.0.255.255 any
140.55.0.0 0.0.255.255 any
140.56.0.0 0.0.255.255 any
140.57.0.0 0.0.255.255 any
140.58.0.0 0.0.255.255 any
140.59.0.0 0.0.255.255 any
140.60.0.0 0.0.255.255 any
140.61.0.0 0.0.255.255 any
140.62.0.0 0.0.255.255 any
140.63.0.0 0.0.255.255 any
140.64.0.0 0.0.255.255 any
140.65.0.0 0.0.255.255 any
140.66.0.0 0.0.255.255 any
140.67.0.0 0.0.255.255 any
140.68.0.0 0.0.255.255 any
140.69.0.0 0.0.255.255 any
140.70.0.0 0.0.255.255 any
140.71.0.0 0.0.255.255 any
140.72.0.0 0.0.255.255 any
140.73.0.0 0.0.255.255 any
140.74.0.0 0.0.255.255 any
140.194.0.0 0.0.255.255 any
140.199.0.0 0.0.255.255 any
146.221.0.0 0.0.255.255 any
147.186.0.0 0.0.255.255 any
149.101.0.0 0.0.255.255 any
152.91.0.0 0.0.255.255 any
153.31.0.0 0.0.255.255 any
160.64.0.0 0.0.255.255 any
162.23.0.0 0.0.255.255 any
162.45.0.0 0.0.255.255 any
164.112.0.0 0.0.255.255 any
164.128.37.17 0.0.127.255 any
164.141.0.0 0.0.255.255 any
165.142.0.0 0.0.255.255 any
165.187.0.0 0.0.255.255 any
166.64.0.0 0.0.255.255 any
168.152.0.0 0.0.255.255 any
192.58.200.0 0.0.3.255 any
192.84.170.0 0.0.0.255 any
deny ip 192.190.61.0 0.0.0.255 any

deny ip 192.190.66.0 0.0.0.255 any
deny ip 192.251.207.0 0.0.0.255 any
deny ip 193.77.9.0 0.0.0.255 any
deny ip 193.121.83.1 0.0.0.255 any
deny ip 193.172.176.0 0.0.0.255 any
deny ip 193.191.209.192 0.0.0.15 any
deny ip 193.252.72.142 0.0.0.0 any
deny ip 193.252.228.0 0.0.0.255 any
deny ip 194.89.205.0 0.0.0.255 any
deny ip 195.46.218.178 0.0.0.0 any
deny ip 195.76.172.0 0.0.0.255 any
deny ip 195.76.204.0 0.0.0.255 any
deny ip 195.162.203.0 0.0.0.7 any
deny ip 198.61.8.0 0.0.7.255 any
deny ip 198.137.240.0 0.0.0.255 any
deny ip 198.165.21.64 0.0.0.15 any
deny ip 198.190.209.0 0.0.0.255 any
deny ip 199.75.96.0 0.0.7.255 any
deny ip 199.123.80.0 0.0.0.255 any
deny ip 199.212.192.0 0.0.31.255 any
deny ip 199.227.159.64 0.0.0.31 any
deny ip 203.25.230.0 0.0.0.255 any
deny ip 204.75.224.0 0.0.0.255 any
deny ip 204.91.138.0 0.0.0.255 any
deny ip 205.128.1.240 0.0.0.15 any
deny ip 205.229.233.0 0.0.0.255 any
deny ip 206.212.128.0 0.0.63.255 any
deny ip 206.218.64.0 0.0.63.255 any
deny ip 206.241.30.0 0.0.0.255 any
deny ip 207.43.55.0 0.0.0.255 any
deny ip 207.132.172.0 0.0.3.255 any
deny ip 207.132.176.0 0.0.15.255 any
deny ip 207.155.128.0 0.0.127.255 any
deny ip 212.31.111.172 0.0.0.3 any
deny ip 214.0.0.0 0.255.255.255 any
deny ip 215.0.0.0 0.255.255.255 any
deny ip 216.118.66.0 0.0.0.255 any
deny ip 216.146.85.224 0.0.0.31 any
deny ip 217.167.182.0 0.0.0.255 any
permit ip any any
3 - NetFilter
Voici un exemple de rgle IpTables, permettant de dropper toutes les trames vennant de l'un de ces rseaux. Cette
rgle se termine bien videmant par un -j ACCEPT.
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
4.42.244.160/28 -p ip -j DROP
4.42.244.192/27 -p ip -j DROP
12.38.31.216/29 -p ip -j DROP
29.0.0.0/8 -p ip -j DROP
61.88.128.38/32 -p ip -j DROP
63.64.5.0/24 -p ip -j DROP
63.78.79.144/29 -p ip -j DROP
63.100.163.0/24 -p ip -j DROP
63.100.235.128/26 -p ip -j DROP
63.127.255.0/24 -p ip -j DROP
63.148.99.224/27 -p ip -j DROP
63.163.104.32/28 -p ip -j DROP
64.115.129.144/29 -p ip -j DROP
65.118.41.192/27 -p ip -j DROP
65.173.188.0/24 -p ip -j DROP
65.174.230.32/28 -p ip -j DROP
66.72.93.16/29 -p ip -j DROP
66.109.166.136/29 -p ip -j DROP
66.109.166.144/29 -p ip -j DROP
130.46.0.0/16 -p ip -j DROP
130.109.0.0/16 -p ip -j DROP
131.73.0.0/16 -p ip -j DROP
131.80.0.0/16 -p ip -j DROP
131.81.0.0/16 -p ip -j DROP
131.83.0.0/16 -p ip -j DROP
131.85.0.0/16 -p ip -j DROP
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
131.88.0.0/16 -p ip -j DROP
131.185.0.0/16 -p ip -j DROP
131.240.0.0/16 -p ip -j DROP
132.37.0.0/16 -p ip -j DROP
132.39.0.0/16 -p ip -j DROP
132.80.0.0/16 -p ip -j DROP
132.81.0.0/16 -p ip -j DROP
132.82.0.0/16 -p ip -j DROP
132.83.0.0/16 -p ip -j DROP
132.84.0.0/16 -p ip -j DROP
132.85.0.0/16 -p ip -j DROP
132.86.0.0/16 -p ip -j DROP
132.87.0.0/16 -p ip -j DROP
132.95.0.0/16 -p ip -j DROP
132.96.0.0/16 -p ip -j DROP
132.97.0.0/16 -p ip -j DROP
132.98.0.0/16 -p ip -j DROP
132.99.0.0/16 -p ip -j DROP
132.100.0.0/16 -p ip -j DROP
132.101.0.0/16 -p ip -j DROP
132.102.0.0/16 -p ip -j DROP
132.103.0.0/16 -p ip -j DROP
132.133.0.0/16 -p ip -j DROP
132.134.0.0/16 -p ip -j DROP
132.135.0.0/16 -p ip -j DROP
132.136.0.0/16 -p ip -j DROP
132.137.0.0/16 -p ip -j DROP
132.138.0.0/16 -p ip -j DROP
132.139.0.0/16 -p ip -j DROP
132.140.0.0/16 -p ip -j DROP
132.141.0.0/16 -p ip -j DROP
132.142.0.0/16 -p ip -j DROP
132.143.0.0/16 -p ip -j DROP
132.144.0.0/16 -p ip -j DROP
134.194.0.0/16 -p ip -j DROP
134.229.0.0/16 -p ip -j DROP
134.230.0.0/16 -p ip -j DROP
134.232.0.0/16 -p ip -j DROP
134.254.0.0/16 -p ip -j DROP
136.188.0.0/16 -p ip -j DROP
136.189.0.0/16 -p ip -j DROP
136.190.0.0/16 -p ip -j DROP
136.191.0.0/16 -p ip -j DROP
136.192.0.0/16 -p ip -j DROP
136.193.0.0/16 -p ip -j DROP
136.194.0.0/16 -p ip -j DROP
136.195.0.0/16 -p ip -j DROP
136.196.0.0/16 -p ip -j DROP
136.197.0.0/16 -p ip -j DROP
136.208.0.0/16 -p ip -j DROP
136.211.0.0/16 -p ip -j DROP
136.212.0.0/16 -p ip -j DROP
136.213.0.0/16 -p ip -j DROP
136.214.0.0/16 -p ip -j DROP
136.222.0.0/16 -p ip -j DROP
137.130.0.0/16 -p ip -j DROP
137.191.0.0/16 -p ip -j DROP
137.209.0.0/16 -p ip -j DROP
137.210.0.0/16 -p ip -j DROP
137.211.0.0/16 -p ip -j DROP
137.212.0.0/16 -p ip -j DROP
137.231.0.0/16 -p ip -j DROP
137.232.0.0/16 -p ip -j DROP
137.233.0.0/16 -p ip -j DROP
137.234.0.0/16 -p ip -j DROP
137.235.0.0/16 -p ip -j DROP
137.246.0.0/16 -p ip -j DROP
137.247.0.0/16 -p ip -j DROP
138.60.0.0/16 -p ip -j DROP
138.135.0.0/16 -p ip -j DROP
138.136.0.0/16 -p ip -j DROP
138.150.0.0/16 -p ip -j DROP
138.151.0.0/16 -p ip -j DROP
138.153.0.0/16 -p ip -j DROP
138.159.0.0/16 -p ip -j DROP
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
138.170.0.0/16 -p ip -j DROP
139.77.0.0/16 -p ip -j DROP
139.233.0.0/16 -p ip -j DROP
139.234.0.0/16 -p ip -j DROP
139.235.0.0/16 -p ip -j DROP
139.236.0.0/16 -p ip -j DROP
139.237.0.0/16 -p ip -j DROP
139.238.0.0/16 -p ip -j DROP
139.239.0.0/16 -p ip -j DROP
139.240.0.0/16 -p ip -j DROP
139.241.0.0/16 -p ip -j DROP
139.242.0.0/16 -p ip -j DROP
139.243.0.0/16 -p ip -j DROP
139.244.0.0/16 -p ip -j DROP
139.245.0.0/16 -p ip -j DROP
139.246.0.0/16 -p ip -j DROP
139.247.0.0/16 -p ip -j DROP
139.248.0.0/16 -p ip -j DROP
139.249.0.0/16 -p ip -j DROP
139.250.0.0/16 -p ip -j DROP
139.251.0.0/16 -p ip -j DROP
139.252.0.0/16 -p ip -j DROP
139.253.0.0/16 -p ip -j DROP
139.254.0.0/16 -p ip -j DROP
140.1.0.0/16 -p ip -j DROP
140.2.0.0/16 -p ip -j DROP
140.3.0.0/16 -p ip -j DROP
140.4.0.0/16 -p ip -j DROP
140.5.0.0/16 -p ip -j DROP
140.6.0.0/16 -p ip -j DROP
140.7.0.0/16 -p ip -j DROP
140.8.0.0/16 -p ip -j DROP
140.9.0.0/16 -p ip -j DROP
140.10.0.0/16 -p ip -j DROP
140.11.0.0/16 -p ip -j DROP
140.12.0.0/16 -p ip -j DROP
140.13.0.0/16 -p ip -j DROP
140.15.0.0/16 -p ip -j DROP
140.16.0.0/16 -p ip -j DROP
140.17.0.0/16 -p ip -j DROP
140.18.0.0/16 -p ip -j DROP
140.19.0.0/16 -p ip -j DROP
140.20.0.0/16 -p ip -j DROP
140.21.0.0/16 -p ip -j DROP
140.22.0.0/16 -p ip -j DROP
140.23.0.0/16 -p ip -j DROP
140.24.0.0/16 -p ip -j DROP
140.25.0.0/16 -p ip -j DROP
140.26.0.0/16 -p ip -j DROP
140.27.0.0/16 -p ip -j DROP
140.28.0.0/16 -p ip -j DROP
140.29.0.0/16 -p ip -j DROP
140.30.0.0/16 -p ip -j DROP
140.31.0.0/16 -p ip -j DROP
140.32.0.0/16 -p ip -j DROP
140.33.0.0/16 -p ip -j DROP
140.34.0.0/16 -p ip -j DROP
140.35.0.0/16 -p ip -j DROP
140.36.0.0/16 -p ip -j DROP
140.37.0.0/16 -p ip -j DROP
140.38.0.0/16 -p ip -j DROP
140.39.0.0/16 -p ip -j DROP
140.40.0.0/16 -p ip -j DROP
140.41.0.0/16 -p ip -j DROP
140.42.0.0/16 -p ip -j DROP
140.44.0.0/16 -p ip -j DROP
140.45.0.0/16 -p ip -j DROP
140.46.0.0/16 -p ip -j DROP
140.47.0.0/16 -p ip -j DROP
140.48.0.0/16 -p ip -j DROP
140.49.0.0/16 -p ip -j DROP
140.50.0.0/16 -p ip -j DROP
140.51.0.0/16 -p ip -j DROP
140.52.0.0/16 -p ip -j DROP
140.53.0.0/16 -p ip -j DROP
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
-i
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
interface_wan
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
140.54.0.0/16 -p ip -j DROP
140.55.0.0/16 -p ip -j DROP
140.56.0.0/16 -p ip -j DROP
140.57.0.0/16 -p ip -j DROP
140.58.0.0/16 -p ip -j DROP
140.59.0.0/16 -p ip -j DROP
140.60.0.0/16 -p ip -j DROP
140.61.0.0/16 -p ip -j DROP
140.62.0.0/16 -p ip -j DROP
140.63.0.0/16 -p ip -j DROP
140.64.0.0/16 -p ip -j DROP
140.65.0.0/16 -p ip -j DROP
140.66.0.0/16 -p ip -j DROP
140.67.0.0/16 -p ip -j DROP
140.68.0.0/16 -p ip -j DROP
140.69.0.0/16 -p ip -j DROP
140.70.0.0/16 -p ip -j DROP
140.71.0.0/16 -p ip -j DROP
140.72.0.0/16 -p ip -j DROP
140.73.0.0/16 -p ip -j DROP
140.74.0.0/16 -p ip -j DROP
140.194.0.0/16 -p ip -j DROP
140.199.0.0/16 -p ip -j DROP
146.221.0.0/16 -p ip -j DROP
147.186.0.0/16 -p ip -j DROP
149.101.0.0/16 -p ip -j DROP
152.91.0.0/16 -p ip -j DROP
153.31.0.0/16 -p ip -j DROP
160.64.0.0/16 -p ip -j DROP
162.23.0.0/16 -p ip -j DROP
162.45.0.0/16 -p ip -j DROP
164.112.0.0/16 -p ip -j DROP
164.128.37.17/17 -p ip -j DROP
164.141.0.0/16 -p ip -j DROP
165.142.0.0/16 -p ip -j DROP
165.187.0.0/16 -p ip -j DROP
166.64.0.0/16 -p ip -j DROP
168.152.0.0/16 -p ip -j DROP
192.58.200.0/22 -p ip -j DROP
192.84.170.0/24 -p ip -j DROP
192.190.61.0/24 -p ip -j DROP
192.190.66.0/24 -p ip -j DROP
192.251.207.0/24 -p ip -j DROP
193.77.9.0/24 -p ip -j DROP
193.121.83.1/24 -p ip -j DROP
193.172.176.0/24 -p ip -j DROP
193.191.209.192/28 -p ip -j DROP
193.252.72.142/32 -p ip -j DROP
193.252.228.0/24 -p ip -j DROP
194.89.205.0/24 -p ip -j DROP
195.46.218.178/32 -p ip -j DROP
195.76.172.0/24 -p ip -j DROP
195.76.204.0/24 -p ip -j DROP
195.162.203.0/29 -p ip -j DROP
198.61.8.0/21 -p ip -j DROP
198.137.240.0/24 -p ip -j DROP
198.165.21.64/28 -p ip -j DROP
198.190.209.0/24 -p ip -j DROP
199.75.96.0/21 -p ip -j DROP
199.123.80.0/24 -p ip -j DROP
199.212.192.0/19 -p ip -j DROP
199.227.159.64/27 -p ip -j DROP
203.25.230.0/24 -p ip -j DROP
204.75.224.0/24 -p ip -j DROP
204.91.138.0/24 -p ip -j DROP
205.128.1.240/28 -p ip -j DROP
205.229.233.0/24 -p ip -j DROP
206.212.128.0/18 -p ip -j DROP
206.218.64.0/18 -p ip -j DROP
206.241.30.0/24 -p ip -j DROP
207.43.55.0/24 -p ip -j DROP
207.132.172.0/22 -p ip -j DROP
207.132.176.0/20 -p ip -j DROP
207.155.128.0/17 -p ip -j DROP
212.31.111.172/30 -p ip -j DROP
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-i interface_wan
-i interface_wan
-i interface_wan
-i interface_wan
-i interface_wan
-j ACCEPT
-s
-s
-s
-s
-s
214.0.0.0/8 -p ip -j DROP
215.0.0.0/8 -p ip -j DROP
216.118.66.0/24 -p ip -j DROP
216.146.85.224/27 -p ip -j DROP
217.167.182.0/24 -p ip -j DROP
Dos Cisco
1 - Le concept
2 - Le fonctionnement
2.1 - Schma
2.2 - Envoi
2.3 - Rception
2.4 - Multiples rceptions
3 - Les conseils et astuces
4 - Les liens
5 - Les outils
6 - La conclusion
1 - Le concept
L'envoi de paquet spcifique sur une interface Cisco provoque le blocage de la rception sur cette mme interface
ralisant ainsi un DOS. Ces trames doivent avoir un formatage spcial en spcifiant un type de protocole et une valeur
de temps de vie.
2.1 - Schma
2.2 - Envoi
L'metteur envoi une trame Ip d'un des 4 types de protocoles suivant destination de l'adresse Ip cible A.
-
53
55
77
avec
avec
avec
103
un
un
un
avec
TTL
TTL
TTL
n'importe
0
0
0
ou
ou
ou
quel
1
1
1
TLL
Voici le schma de l'entte IP avec le champ Type protocol bas sur 1 octet ainsi que le TTL bas, lui aussi sur
1 octet.
2.3 - Rception
A la rception de l'un des paquets malicieux, l'quipement Cisco le positionne dans son Buffer d'interface. De l, le
paquet reste bloqu dans ce tampon. Vous pouvez en voir le contenu grce la commande show buffers inputinterface
ethernet
0
packet
On peut remarqu la prsence d'une trame bloque dans le buffer de l'interface Ethernet 0.
Attention, toutes les trames reues transitent via le buffer qui reprsente la file d'attente de l'interface. Donc vous
pouvez trs bien appliquer la commande au moment o un paquet entre dans le buffer sans qu'il est le temps d'en
sortir. Effectuez donc plusieurs fois la commande afin de confirmer le blocage des trames visualises.
2.4 - Multiples rceptions
L'attaque est de type Dos (Deny Of Service) via un Buffer Over Flow, cela signifie donc que le blocage massif de
trame saturera la capacit du buffer. L'interface sera alors dans l'incapacit de recevoir de trames
supplmentaires.

Voici
trois
conseils
pour
vous
cacher.
L'Ip
Spoofing
permettra
de
changer
votre
IP
source.
- Si vous avez besoin de connatre le TTL avant l'envoi, n'effectuez pas un Traceroute, car vous serrez certainement
logg.
Par
contre,
vous
pouvez
gnrez
255
fois
l'attaque
avec
un
TTL
variant.
- Trouvez des Hosts de rebond administr en Http via un Proxy ouvert. Mais attention aux HoneyPots !
- Ne vous arrtez pas une interface, mais testez les toutes. Et si vous pouvez, mettez les paquets provenant du Lan,
car certain Host, ne sont pas patchs et ne sont scuris que par des ACL plac sur linterface Wan.
4 - Les liens
- La
description
- L'information de CERT Coordination Center
par
Cisco
5 - Les outils
- FrameIP est un gnrateur de trames IP. Il vous permettra de personnaliser les champs des diffrentes enttes
rseaux.
- CiscoDos, c'est un outils spcifique pour l'attaque Cisco. Il vous permettra d'effectuer de l'Ip Spoofing.
6 - La conclusion
C'est une attaque violente du fait qu'elle s'effectue en une seule trame et ne peut donc pas tre arrte par une IDS
classique
(sauf
IDS
double
patte
transparente).
Ce n'est pas la peine de vous acharner aprs les grands noms de l'Internet, car il y de trs forte chance qu'ils aient
appliqus le patch. Nanmoins, sachant que l'IOS est le second Operating System de la plante aprs Windows, cela
nous apporte la certitude que le parc est loin d'tre patch...
Les Firewalls
1 - Pourquoi un firewall
2 - Les diffrents types de filtrages
2.1 - Le filtrage simple de paquet (Stateless)
2.1.1 - Le principe
2.1.2 - Les limites
2.2 - Le filtrage de paquet avec tat (Stateful)
2.2.1 - Le principe
2.2.2 - Les limites
2.3 - Le filtrage applicatif (ou pare-feu de type proxy ou proxying applicatif)
2.3.1 - Le principe
2.3.2 - Les limites
2.4 - Que choisir
3 - Les diffrents types de firewall
3.1 - Les firewall bridge
3.1.1 - Avantages
3.1.2 - Inconvnients
3.2 - Les firewalls matriels
3.2.1 - Avantages
3.3 - Les firewalls logiciels
3.3.1 - Les firewalls personnels
3.3.2 - Les firewalls plus srieux
4 - Attaques, outils, dfenses
4.1 - Scnarios d'attaques (Pntrations de rseaux)
4.1.1 - Premier cas : Pas de protection
4.1.2 - Deuxime cas : Filtrer les flux entrants illgaux
4.1.3 - Troisime cas : Bloquer les flux entrants et sortants
4.1.4 - Quatrime cas : Protection locale via un Firewall personnel
4.2 - Les techniques et outils de dcouvertes de Firewall
4.2.1 - Firewalk
4.2.2 - Nmap
4.2.3 - HPING2
4.2.4 - NESSUS
4.3 - Configuration thorique des dfenses
4.4 - Les ractions des firewalls aux attaques classiques
4.5 - Un exemple pratique : netfilter
5 - Conclusion
1 - Pourquoi un firewall
De nos jours, toutes les entreprises possdant un rseau local possdent aussi un accs Internet, afin d'accder la
manne d'information disponible sur le rseau des rseaux, et de pouvoir communiquer avec l'extrieur. Cette
ouverture vers l'extrieur est indispensable... et dangereuse en mme temps. Ouvrir l'entreprise vers le monde signifie
aussi laisser place ouverte aux trangers pour essayer de pntrer le rseau local de l'entreprise, et y accomplir des
actions douteuses, parfois gratuites, de destruction, vol d'informations confidentielles, ... Les mobiles sont nombreux et
dangereux.
Pour parer ces attaques, une architecture scurise est ncessaire. Pour cela, le coeur d'une tel architecture est bas
sur un firewall. Cette outil a pour but de scuriser au maximum le rseau local de l'entreprise, de dtecter les
tentatives d'intrusion et d'y parer au mieux possible. Cela reprsente une scurit supplmentaire rendant le rseau
ouvert sur Internet beaucoup plus sr. De plus, il peut permettre de restreindre l'accs interne vers l'extrieur. En
effet, des employs peuvent s'adonner des activits que l'entreprise ne cautionne pas, le meilleur exemple tant le
jeu en ligne. En plaant un firewall limitant ou interdisant l'accs ces services, l'entreprise peut donc avoir un
contrle
sur
les
activits
se
droulant
dans
son
enceinte.
Le firewall propose donc un vritable contrle sur le trafic rseau de l'entreprise. Il permet d'analyser, de scuriser et
de grer le trafic rseau, et ainsi d'utiliser le rseau de la faon pour laquelle il a t prvu et sans l'encombrer avec
des activits inutiles, et d'empcher une personne sans autorisation d'accder ce rseau de donnes.
2 - Les diffrents types de filtrages

2.1 - Le filtrage simple de paquet (Stateless)
2.1.1 - Le principe
C'est la mthode de filtrage la plus simple, elle opre au niveau de la couche rseau et transport dumodle
Osi. La plupart des routeurs d'aujourd'hui permettent d'effectuer du filtrage simple de paquet. Cela consiste
accorder ou refuser le passage de paquet d'un rseau un autre en se basant sur :
-
Et
Le
bien
sur
L'adresse
numro
le
IP
de
protocole
de
port
niveau
Source/Destination.
Source/Destination.
3
ou
4.
Cela ncessite de configurer le Firewall ou le routeur par des rgles de filtrages, gnralement appeles des
ACL (Access Control Lists).
2.1.2 - Les limites
Le premier problme vient du fait que l'administrateur rseau est rapidement contraint autoriser un trop
grand nombre d'accs, pour que le Firewall offre une relle protection. Par exemple, pour autoriser les
connexions Internet partir du rseau priv, l'administrateur devra accepter toutes les
connexions Tcpprovenant de l'Internet avec un port suprieur 1024. Ce qui laisse beaucoup de choix un
ventuel
pirate.
Il est noter que de dfinir des ACL sur des routeurs haut de gamme - c'est dire, supportant un dbit
important - n'est pas sans rpercussion sur le dbit lui-mme. Enfin, ce type de filtrage ne rsiste pas
certaines attaques de type IP Spoofing / IP Flooding, la mutilation de paquet, ou encore certainesattaques de
type DoS. Ceci est vrai sauf dans le cadre des routeurs fonctionnant en mode distribu. Ceci permettant de
grer les Acl directement sur les interfaces sans remonter la carte de traitement central. Les performances
impactes par les Acl sont alors quasi nulles.
2.2 - Le filtrage de paquet avec tat (Stateful)
2.2.1 - Le Principe
L'amlioration par rapport au filtrage simple, est la conservation de la trace des sessions et des connexions
dans des tables d'tats internes au Firewall. Le Firewall prend alors ses dcisions en fonction des tats de
connexions, et peut ragir dans le cas de situations protocolaires anormales. Ce filtrage permet aussi de se
protger
face
certains
types
d'attaques
DoS.
Dans l'exemple prcdent sur les connexions Internet, on va autoriser l'tablissement des connexions la
demande, ce qui signifie que l'on aura plus besoin de garder tous les ports suprieurs 1024 ouverts. Pour
les protocoles Udp et Icmp, il n'y a pas de mode connect. La solution consiste autoriser pendant un certain
dlai les rponses lgitimes aux paquets envoys. Les paquets Icmp sont normalement bloqus par le
Firewall, qui doit en garder les traces. Cependant, il n'est pas ncessaire de bloquer les paquets Icmp de type
3 (destination inaccessible) et 4 (ralentissement de la source) qui ne sont pas utilisables par un attaquant.
On peut donc choisir de les laisser passer, suite l'chec d'une connexion Tcp ou aprs l'envoi d'un paquet
Udp.
Pour le protocole Ftp (et les protocoles fonctionnant de la mme faon), c'est plus dlicat puisqu'il va falloir
grer l'tat de deux connexions. En effet, le protocole Ftp, gre un canal de contrle tabli par le client, et un
canal de donnes tabli par le serveur. Le Firewall devra donc laisser passer le flux de donnes tabli par le
serveur. Ce qui implique que le Firewall connaisse le protocole Ftp, et tous les protocoles fonctionnant sur le
mme principe. Cette technique est connue sous le nom de filtrage dynamique (Stateful Inspection) et a t
invente par Checkpoint. Mais cette technique est maintenant gre par d'autres fabricants.
2.2.2 - Les limites

Tout d'abord, il convient de s'assurer que les deux techniques sont bien implmentes par les Firewalls, car
certains constructeurs ne l'implmentent pas toujours correctement. Ensuite une fois que l'accs un service
a t autoris, il n'y a aucun contrle effectu sur les requtes et rponses des clients et serveurs. Un
serveur Http pourra donc tre attaqu impunment (Comme quoi il leur en arrive des choses aux serveurs
WEB !). Enfin les protocoles maisons utilisant plusieurs flux de donnes ne passeront pas, puisque le systme
de filtrage dynamique n'aura pas connaissance du protocole.
2.3 - Le filtrage applicatif (ou pare-feu de type proxy ou proxying applicatif)
2.3.1 - Le principe
Le filtrage applicatif est comme son nom l'indique ralis au niveau de la couche Application. Pour cela, il faut
bien sr pouvoir extraire les donnes du protocole de niveau 7 pour les tudier. Les requtes sont traites
par des processus ddis, par exemple une requte de type Http sera filtre par un processus proxy Http. Le
pare-feu rejettera toutes les requtes qui ne sont pas conformes aux spcifications du protocole. Cela
implique que le pare-feu proxy connaisse toutes les rgles protocolaires des protocoles qu'il doit filtrer.
2.3.2 - Les limites
Le premier problme qui se pose est la finesse du filtrage ralis par le proxy. Il est extrmement difficile de
pouvoir raliser un filtrage qui ne laisse rien passer, vu le nombre de protocoles de niveau 7. En outre le fait
de devoir connatre les rgles protocolaires de chaque protocole filtr pose des problmes d'adaptabilit de
nouveaux
protocoles
ou
des
protocoles
maisons.
Mais il est indniable que le filtrage applicatif apporte plus de scurit que le filtrage de paquet avec tat,
mais cela se paie en performance. Ce qui exclut l'utilisation d'une technologie 100 % proxy pour les rseaux
gros trafic au jour d'aujourd'hui. Nanmoins d'ici quelques annes, le problme technologique sera sans
doute rsolu.
2.4 - Que choisir
Tout d'abord, il faut nuancer la supriorit du filtrage applicatif par rapport la technologie Stateful. En effet les
proxys doivent tre paramtrs suffisamment finement pour limiter le champ d'action des attaquants, ce qui
ncessite un trs bonne connaissance des protocoles autoriss traverser le firewall. Ensuite un proxy est plus
susceptible de prsenter une faille de scurit permettant un pirate d'en prendre le contrle, et de lui donner un
accs
sans
restriction
tout
le
systme
d'information.
Idalement, il faut protger le proxy par un Firewall de type Stateful Inspection. Il vaut mieux viter d'installer les
deux types de filtrage sur le mme Firewall, car la compromission de l'un entrane la compromission de l'autre.
Enfin
cette
technique
permet
galement
de
se
protger
contre
l'ARP
spoofing.
3 - Les diffrents types de firewall

3.1 - Les firewall bridge
Ces derniers sont relativement rpandus. Ils agissent comme de vrais cbles rseau avec la fonction de filtrage en
plus, d'o leur appellation de firewall. Leurs interfaces ne possdent pas d'adresse Ip, et ne font que transfrer les
paquets d'une interface a une autre en leur appliquant les rgles prdfinies. Cette absence est particulirement
utile, car cela signifie que le firewall est indtectable pour un hacker lambda. En effet, quand une requte ARP est
mise sur le cble rseau, le firewall ne rpondra jamais. Ses adresses Mac ne circuleront jamais sur le rseau, et
comme il ne fait que transmettre les paquets, il sera totalement invisible sur le rseau. Cela rend impossible
toute attaque dirige directement contre le firewall, tant donn qu'aucun paquet ne sera trait par ce dernier
comme tant sa propre destination. Donc, la seule faon de le contourner est de passer outre ses rgles de drop.
Toute
attaque
devra
donc
faire
avec
ses
rgles,
et
essayer
de
les
contourner.
Dans la plupart des cas, ces derniers ont une interface de configuration spare. Un cble vient se brancher sur
une troisime interface, srie ou mme Ethernet, et qui ne doit tre utilise que ponctuellement et dans un
environnement
scuris
de
prfrence.
Ces firewalls se trouvent typiquement sur les switchs.
3.1.1 - Avantages
Impossible de l'viter (les paquets passeront par ses interfaces)
Peu coteux
Possibilit de le contourner (il suffit de passer outre ses rgles)
Configuration souvent contraignante
Les fonctionnalits prsentes sont trs basiques (filtrage sur adresse IP, port, le plus souvent en
Stateless).
3.2 - Les firewalls matriels
Ils se trouvent souvent sur des routeurs achets dans le commerce par de grands constructeurs comme Cisco ou
Nortel. Intgrs directement dans la machine, ils font office de boite noire , et ont une intgration parfaite avec
le matriel. Leur configuration est souvent relativement ardue, mais leur avantage est que leur interaction avec
les autres fonctionnalits du routeur est simplifie de par leur prsence sur le mme quipement rseau. Souvent
relativement peu flexibles en terme de configuration, ils sont aussi peu vulnrables aux attaques, car prsent dans
la boite noire qu'est le routeur. De plus, tant souvent trs lis au matriel, l'accs leur code est assez
difficile, et le constructeur a eu toute latitude pour produire des systme de codes signs afin d'authentifier le
logiciel (systme RSA ou assimils). Ce systme n'est implant que dans les firewalls haut de gamme, car cela
vite un remplacement du logiciel par un autre non produit par le fabricant, ou toute modification de ce dernier,
rendant ainsi le firewall trs sr. Son administration est souvent plus aise que les firewall bridges, les grandes
marques de routeurs utilisant cet argument comme argument de vente. Leur niveau de scurit est de plus trs
bon, sauf dcouverte de faille ventuelle comme tout firewall. Nanmoins, il faut savoir que l'on est totalement
dpendant du constructeur du matriel pour cette mise jour, ce qui peut tre, dans certains cas, assez
contraignant. Enfin, seules les spcificits prvues par le constructeur du matriel sont implmentes. Cette
dpendance induit que si une possibilit nous intresse sur un firewall d'une autre marque, son utilisation est
impossible. Il faut donc bien dterminer l'avance ses besoin et choisir le constructeur du routeur avec soin.
3.2.1 - Avantages
Intgr au matriel rseau
Administration relativement simple
Bon niveau de scurit
Dpendant du constructeur pour les mises jour
Souvent peu flexibles.
3.3 - Les firewalls logiciels
Prsents la fois dans les serveurs et les routeurs faits maison , on peut les classer en plusieurs catgories :
3.3.1 - Les firewalls personnels
Ils sont assez souvent commerciaux et ont pour but de scuriser un ordinateur particulier, et non pas un
groupe d'ordinateurs. Souvent payants, ils peuvent tre contraignants et quelque fois trs peu scuriss. En
effet, ils s'orientent plus vers la simplicit d'utilisation plutt que vers l'exhaustivit, afin de rester accessible
l'utilisateur final.
3.3.1.1 - Avantages
Scurit en bout de chane (le poste client)
Personnalisable assez facilement
3.3.1.2 - Inconvnients
Facilement contournable
Difficiles a dpartager de par leur nombre norme.
3.3.2 - Les firewalls plus srieux
Tournant gnralement sous linux, car cet OS offre une scurit rseau plus leve et un contrle plus
adquat, ils ont gnralement pour but d'avoir le mme comportement que les firewalls matriels des
routeurs, ceci prt qu'ils sont configurables la main. Le plus courant est iptables (anciennement ipchains),
qui utilise directement le noyau linux. Toute fonctionnalit des firewalls de routeurs est potentiellement
ralisable sur une telle plateforme.
3.3.2.1 - Avantages
Personnalisables
Niveau de scurit trs bon
3.3.2.2 - Inconvnients
Ncessite une administration systme supplmentaire
Ces firewalls logiciels ont nanmoins une grande faille : ils n'utilisent pas la couche bas rseau. Il suffit donc de
passer outre le noyau en ce qui concerne la rcupration de ces paquets, en utilisant une librairie spciale, pour
rcuprer les paquets qui auraient t normalement dropps par le firewall. Nanmoins, cette faille induit de
s'introduire sur l'ordinateur en question pour y faire des modifications... chose qui induit dj une intrusion dans
le rseau, ou une prise de contrle physique de l'ordinateur, ce qui est dj Synonyme d'inefficacit de la part du
firewall.
4 - Attaques, outils, dfenses

4.1 - Scnarios d'attaques (Pntrations de rseaux)
Qu'est-ce qu'une backdoor ? Une backdoor est un accs ( cach ) sur votre systme qui permet un pirate d'en
prendre le contrle distance. Il existe une multitude de sortes de backdoor, et en gnral dans ce domaine,
l'imagination des pirates rivalise avec l'incrdulit des utilisateurs. Voici quelques scnarios d'attaques plus ou
moins classique.
4.1.1 - Premier cas : Pas de protection
Considrons un ordinateur victime sur lequel on a install une backdoor en exploitant une des failles du
systme. L'attaquant a alors la possibilit d'utiliser tous les services prsents sur cet ordinateur. Il lui suffit
d'envoyer
ses
ordres
la
backdoor
et
de
rcuprer
les
rponses.
4.1.2 - Deuxime cas : Filtrer les flux entrants illgaux

La scurit de notre systme ne nous semblant pas infaillible, nous dcidons alors d'installer un Firewall avec
tats (Un Firewall sans tat nous semblant quelque peu lger). Le trafic entrant est maintenant stopp
comme il se doit. Malheureusement, le pirate tant rus et malicieux, il a pris soin de s'arranger pour que sa
backdoor initie elle-mme les sessions. Du coup le Firewall laisse passer les requtes de l'attaquant qui sont
considres
comme
des
rponses
par
celui-ci.
4.1.3 - Troisime cas : Bloquer les flux entrants et sortants

Dans le cas prcdent, le problme tait d aux flux sortants qui permettait au cheval de Troie d'initier les
sessions avec la machine de l'attaquant. Il s'agit donc de bloquer les flux sortants. Pour cela la dfense
insre donc un proxy afin de contrler ce qui sort du rseau. Malheureusement le trojan peut encore sortir,
certes avec plus de difficults puisqu'il devra se renseigner sur les flux autoriss sortir par le proxy, et les
utiliser pour passer le proxy. Par exemple on peut encapsuler des ordres dans du HTTP (Ip over Http),dans
du SSL (Ip
over
Ssl), DNS (Ip
over
Dns),
Smtp
(Ip
over
Smtp).
Dans le cas d'un proxy avec authentification, le pirate fera preuve de grande imagination en ralisant un
trojan capable de profiter des applications (comme IE par exemple) qui une fois qu'elles se sont authentifies
sont
utilises
pour
passer
le
proxy.
4.1.4 - Quatrime cas : Protection locale via un Firewall personnel

L'ide du Firewall personnel est de surveiller le trafic entrant et sortant de la machine infecte.
Malheureusement
ceux-ci
sont
fortement
attaquables,
on
peut
:
Passer au-dessus du Firewall via une application autorise. Appel de CreateRemoteThread
permettant de l'injection de code la vole sous Windows.
Passer en dessous du Firewall via une bibliothque adapte (Winpcap sous Windows ou pcap sous
Linux).
Attaquer le Firewall lui-mme en tant qu'applicatif (Arrt du processus).
4.1.5 - Cinquime cas : piratage de VPN
Imaginons qu'un pirate mal intentionn installe un trojan sur l'ordinateur d'un commercial. L'ordinateur
possdant entre autre un systme Windows et un client VPN. Normalement, le client VPN fonctionne de telle
sorte que toutes les liaisons rseaux n'tant pas dans le VPN ne fonctionnent pas. Malheureusement, il s'agit
du mme problme que pour les Firewall personnels et le trojan permet l'attaquant d'accder au rseau de
l'entreprise
via
le
VPN.
On peut se rendre compte de l'importance de la robustesse du systme d'exploitation, sur lequel est install
le VPN. Aprs une attaque russie et la prise de contrle en root de la machine par le pirate, celui-ci va
essayer
d'installer
ce
que
l'on
appelle
un
rootkit.
Il existe deux types de rootkit, les rootkit simples et les rootkit noyaux. Les rootkit simples se contentent de
remplacer toute une collection de programmes systme (ps, netstat, ifconfig, ....) lui permettant d'effacer les
traces de son passage et ainsi masquer compltement sa backdoor. Un simple outils tel que Tripwire permet
de vrifier l'intgrit des commandes, en enregistrant de faon crypte les signatures (gnres par une
fonction
de
hashage)
des
fichiers
de
commandes
en
question.
Les rootkit noyaux sont beaucoup plus difficiles dtecter, puisqu'ils modifient le noyau et donc modifient
son comportement. Par exemple rendre invisible un processus chaque appel (non pas de la commande ps)
mais des fonctions systmes du noyau, qui elles mme sont appeles par la commande ps. Evidemment un
rootkit noyau modifie en plus les routines de journalisassions du systme, masque les connexions rseaux,
... Pour se protger des rootkit noyaux, le plus simple est de s'en prmunir. Pour cela, l'idal est de patcher
son noyau pour empcher l'installation d'un rootkit, et de dsactiver les LKM (Loadable Kernel Modules qui
permettent au root d'introduire un nouveau code dans le systme d'exploitation pendant que ce dernier est
en cours d'excution), malheureusement cela ne suffit pas toujours (voir kinsmod.c). Il existe un outil pour
Linux capable d'un certain nombre de vrification de modules de backdoor. Cet outil s'appelle rkscan et
permet de dtecter les versions de rootkits les plus populaires.
4.2 - Les techniques et outils de dcouvertes de Firewall
Il existe beaucoup d'outils et beaucoup de techniques permettant d'identifier un Firewall. L'objectif de ce
paragraphe est d'en exposer quelques-uns et quelques-unes. Il est vident que la plupart des outils utiliss par les
pirates pour dcouvrir les Firewall sont utilisables pour une activit tout aussi louable telle que la vrification du
bon
fonctionnement
du
firewall
et
de
la
robustesse
du
rseau.
Dans un premier temps il convient de localiser le ou les Firewalls. La localisation du firewall ne pose pas de gros
problmes, un simple traceroute (ou tracert.exe) suffira, bien que dans certains cas netcat apporte de meilleurs
rsultats.
Exemple :
C:> nc -v -n 10.10.1.8 25
(UNKNOWN) [10.10.1.8] 25 (?) open
421 10.10.1.8 Sorry, the firewall does not provide mail service to you.
Ensuite l'attaquant cherchera identifier le Firewall, soit en esprant exploiter une faille mme du Firewall, soit il
cherchera identifier les rgles du Firewall afin d'y dtecter une faille dans le filtrage de paquet. Pour identifier les
rgles d'un Firewall, il faut utiliser un scanner de port. Il existe de nombreux scanner de ports, les plus connus
sont Firewalk, Nmap et Hping2 :
4.2.1 - Firewalk
Le Firewalking est une technique qui permet de dterminer les rgles de filtrages de niveau 4 (Transport) sur
les quipements (routeurs, Firewall, passerelles) qui acheminent des paquets de niveau 3 (Rseau).
Le principe de cette technique repose sur le champ Ttl (Time To Live) des en-ttes IP des paquets. C'est
dire le nombre d'quipement (routeur) que peut traverser le paquet. Le logiciel traceroute utilise aussi la
technique du Ttl. Lorsque l'on envoie un paquet Udp avec un Ttl de 1, le premier routeur recevant le paquet
mettra un paquet Icmp Ttl-exceeded. Et l'on rpte le procd en augmentant le Ttl de 1 chaque fois. En
fait ce procd peut tre ralis avec d'autres protocoles de niveau 4 comme Tcp ou de niveau 3 comme
Icmp.
Firewalk fonctionne en construisant des paquets avec un IP Ttl calcul de faon expirer sur un segment
situ aprs le firewall. En fait si le paquet est autoris par le firewall, il pourra le passer et expirera comme
prvu en envoyant un message "Icmp Ttl expired in transit". A l'inverse, si le paquet est bloqu par l'ACL du
firewall, il sera abandonn et aucune rponse ne sera envoye ou bien un paquet de filtre admin Icmp de
type
13
sera
envoy.
Il est possible de bloquer les paquets Icmp Ttl EXPIRED au niveau de l'interface externe, mais le problme
est que ses performances risquent d'en prendre un srieux coup car des clients se connectant lgitimement
ne sauront jamais ce qui est arriv leur connexion.
4.2.2 - Nmap
Nmap (Network Mapper) est certainement le scanner de port le plus clbre disponible sous linux, Windows
et mme MAC. En rgle gnrale, Nmap vrifie que l'hte scanner est connect au rseau. Il ralise pour
cela la fois un Tcp ping sur le port 80 et un ping Icmp normal. Ce comportement peut tre dtect par un
IDS (Inspection Detection System) et pour cela on peut changer le comportement de Nmap. Nmap permet
d'effectuer diffrents types de scans, en voici les exemples principaux :
Tcp connect : option -sT Principe : une connexion Tcp habituelle est tente sur chaque port.
Inconvnient, ce genre de scan est visible dans les logs des firewalls. Les noms de services sont
associs aux ports ouverts par le fichier Nmap-services et non /etc/services. Il n'est donc pas exclu
que le service dsign soit faux. Avantage, possibilit de dterminer l'utilisateur sous lequel est lanc
un dmon via Ident.
Syn scan : option -sS Principe : Seul un paquet Syn est envoy. Si le port est ouvert, un Syn|ACK est
renvoy, sinon un RST est renvoy. En cas de port ouvert Nmap renvoie un paquet RST pour fermer la
connexion immdiatement. Avantages, rapide et moins dtectable. Fait une diffrence entre les ports
filtrs et ouverts. Inconvnient, impossibilit de dterminer l'utilisateur via Ident.
IDLE scan : option -sI @zombie:port zombie Principe : Une machine "zombie" permet de masquer la
source du scan. Avantages, quasiment impossible tracer, permet de dterminer les rgles du firewall
partir du zombie plutt que de la machine qui initie le scan. Inconvnients, pas de prise d'empreinte
d'OS,
ni
d'utilisation
de
Ident.
(0) S'assurer que la machine zombie n'est pas trop charge pour permettre de bien mesurer
l'incrmentation (un petit calibrage avant le scan est donc ncessaire en envoyant une dizaine de
paquets
Syn).
(1) et (6) Envoi d'un paquet Syn|ACK au zombie pour rcuprer l'IP ID (le numro de squence).
(2) et (7) Rponse (1) et (6) par un paquet RST contenant l'IP ID du zombie.
(3) Envoi d'un paquet Syn la cible avec comme adresse source celle du zombie.
(4) Si le port est ouvert, la cible rpond en envoyant un paquet Syn | ACK au zombie, sinon par un
paquet
RST.
(5) Le zombie incrmente son IP ID, et rpond la cible en envoyant un paquet RST la cible.
(8) Il est aussi conseill de tester plusieurs fois chaque port pour viter les faux-positifs.
FIN, XMAS et NULL scans : options -sF, -sX et -sN Principe : envoi respectivement de paquet FIN, de
paquet FIN| URG |PSH et de paquet sans aucun flag Tcp activ. Avantages, contournement de
certains Firewalls. Inconvnient, ne fonctionne pas contre certains OS qui n'appliquent pas les normes
la lettre (comme Windows, IRIX, ...)
SCAN Udp : option -sU Principe : Envoi d'un paquet Udp vide sur chaque port. Les ports ferms
retournent un paquet Icmp port unreachable. Avantage, permet d'avoir des informations sur NFS,
TFtp et certaines backdoor. Inconvnient, trs lent.
Scan RPC (Remote Procedure Call) : option -sR Principe : envoi de commandes SunRPC. Avantage,
dtermine s'il s'agit bel et bien de port RPC et si oui, de quel programme et/ou version il s'agit.
Inconvnient, assez voyant.
ACK et Window scan : option -sA et sW principe : Envoie respectivement un paquet ACK avec un
numro de squence alatoire et un paquet ayant une taille de fentre non valide. Les ports qui ne
rpondent pas par un RST sont filtrs. Avantage, permet de vrifier si un port est filtr et s'il l'est avec
une rgle stateful. Inconvnient, Le Window scan ne fonctionne pas sur tous les systmes
d'exploitation.
Scans personnaliss : option --scanflags L'utilisateur spcifie les flags Tcp qu'il souhaite activer.
Scan de protocoles : option -sO Permet de dterminer quels sont les protocoles supports par le
systme scann, gnralement un routeur.
Il n'est pas difficile de scanner dans l'anonymat :
Changer la vitesse du scan, grce l'option -T suivie des arguments Paranod, Sneaky, Polite, Normal,
Aggressive or Insane. Nmap attend 5 minutes entre chaque paquet envoy en mode Paranod et 15
secondes en mode Sneaky.
Utiliser des leurres (decoys, option -D) en envoyant d'autres paquets IP spoofs et semblant provenir
d'une autre adresse. Sur un rseau local on peut spoofer (option -S) l'adresse source, et rcuprer les
rponses par sniffage en mode promiscuous. Sur la technique de l'IDLE scan.
L'auteur de Nmap, Fyodor, dcrit sa technique de prise d'empreinte du systme d'exploitation (fingerprinting)
dans l'article Dtection d'OS distante par prise d'empreinte de pile Tcp/IP traduit en franais par
ArHuman, et l'original en anglais Remote OS detection via Tcp/IP Stack FingerPrinting . Le principe repose
sur le test de diffrentes particularits des piles Tcp/IP des diffrents systmes d'exploitation, lesquelles sont
:
Le type d'incrmentation du numro de squence initiale (ISN).
La prsence ou non du flag IP Don't Fragment.
Des tests sur les tailles de fentres.
Le type de service (ToS).
Diffrents tests sur des paquets Tcp.
Diffrents tests au niveau Icmp, comme la limite de vitesse d'envoi de certains types de paquets Icmp
d'erreurs.
Nmap utilise l'option -O pour effectuer une prise d'empreinte du systme, et en gnral on associe l'option -v
(Verbose) pour obtenir des informations supplmentaires comme les ports servant effectuer les tests de la
prise
d'empreinte.
Il m'a sembl important de remarquer le fait que de scanner un Firewall ou un systme protg par un
Firewall prend plus de temps qu'un systme non protg.
4.2.3 - HPING2
HPING2 est diffrent de Nmap d'abord parce qu'il est beaucoup plus configurable. On peut facilement
modifier n'importe quel octet de l'entte TcpIP. Cela permet d'tre rellement cratif au niveau des
techniques de balayage des fins de reconnaissance. On peut bien sr insrer des donnes malveillantes
dans les paquets (buffer overflow, trojan, ...) et les utiliser pour pntrer des rseaux.
HPING2 permet de :
tester les rgles de Firewall,
de faire du scan sophistiqu,
de tester les performances d'un rseau utilisant diffrents protocoles, le ToS et la fragmentation,
de faire du firewalk,
de l'empreinte de systme d'exploitation.
Actuellement, la version HPING3 est en train d'tre dvelopp par Salvatore SanFilippo, et d'autres
volontaires. Selon son site Web, Hping3 sera nettement suprieur l'actuelle version. Il y aura des
amliorations d'installation, des outputs plus lisibles, et sera exploitable par script. Le statut actuel du projet
peut
tre
suivi ici.
Il existe aussi des outils d'valuation de vulnrabilit :
Les payants : Retina (eEye) , NetRecon (Symantec), ISS Internet Scanner (ISS), Cybercop Scanner
(Network Associates).
Les freeware : Nessus (Renaud Deraison).
4.2.4 - NESSUS
Nessus a t crit par Renaud Deraison (depuis dbut 1998), un grand matre de Linux et de la scurit.
Nessus est devenu le Linux de l'valuation de la vulnrabilit, il surpasse certains de ses concurrents
commerciaux. Nessus emploie un modle de plug-in extensible qui permet la scurit d'ajouter la
demande des modules d'exploration. Nessus utilise un langage de script NASL (Nessus Attack Script
Language) pour crire des tests de scurit rapidement et facilement. Nessus est bas sur une architecture
client-Serveur, le serveur ralise les attaques et tourne sur un systme UNIX; les clients initialisent les
attaques et existent sur diffrentes plates-formes X11, Win32 et un client Java. Le fait d'tre open source et
d'utiliser des plug-in permet Nessus d'tre mis jour rgulirement au niveau de sa base de donnes
d'attaques et d'tre la pointe de la technologie. Nessus compte l'heure actuel plus de 500 contrles de
vulnrabilits, dont certains ne sont pas disponibles dans les scanners commerciaux.
4.3 - Configuration thorique des dfenses
La configuration d'un firewall est l'lment clef de son efficacit. Un firewall mal configur peut tre tout aussi
efficace... qu'aucun firewall du tout. C'est la clef de son bon fonctionnement et de son efficacit.
Il existe deux politiques de configurations diffrentes en ce qui concerne la base du firewall :
Tout autoriser sauf ce qui est dangereux : cette mthode est beaucoup trop laxiste. En effet, cela laisse toute
latitude l'imagination des intrus de s'exprimer. Et moins d'avoir tout prvu de faon exhaustive, on laissera
forcment des portes ouvertes, des failles bantes dans notre systme. A viter absolument.
Tout interdire sauf ce dont on a besoin et ce en quoi on a confiance : cette politique est beaucoup plus scuritaire.
En effet, les services sont examins avant d'tre autoriss passer le firewall, et sont donc tous soumis un
examen plus ou moins approfondi. Ainsi, pas de mauvaise surprise sur un service que l'on pensait ne pas avoir
install, plus d'oubli : tout service autoris est explicitement dclar dans le firewall. Cette politique s'accompagne
de la cration de deux zones : une zone interne et l'extrieur. On peut considrer que tout ce qui est dans notre
rseau local est autoris, sans prendre de trop gros risques : le firewall est l pour nous protger des attaques
extrieures, pas des attaques internes pour lesquelles il ne peut rien. Cette facette peut changer suivant la
politique de l'entreprise (interdire l'accs certains, jeux, etc.). La zone externe est par contre considre comme
non sre , et donc toute requte envoye sur un service non explicitement dclar comme accessible de
l'extrieur sera intercepte et ignore. La configuration de la DMZ est ici trs importante, et sa gestion aussi.
Cette
politique
s'accompagne
de
plusieurs
points
noter
:
Plus de services sont ouverts, plus vulnrable est le systme. C'est logique, car plus le nombre de logiciels
accessibles de l'extrieur est grand, plus le risque qu'un intrus exploite ces dits logiciels pour s'introduire dans le
systme est important. C'est ainsi que, par exemple, si on utilise un serveur Web qui interface dj le serveur de
base de donne, il est inutile d'autoriser le trafic entrant vers le serveur de base de donnes... vu que le serveur
Web
joue
le
rle
d'interface.
Suivant la politique de l'entreprise, l'accs ou non certains services peut tre bloqu dans les deux sens. Cela
peut servir, par exemple, empcher le jeu en ligne, ou autres activits que l'entreprise ne dsire pas voir se
drouler
sur
ses
propres
infrastructures.
Certains protocoles sont assez difficiles autoriser, notamment le Ftp. Le comportement du protocole Ftp est
assez atypique et mrite que l'on s'y attarde. Le fonctionnement du Ftp prvoit que ce soit le serveur qui initie la
connexion sur le client pour lui transmettre le fichier. Un exemple concret :
Le client demande le fichier index.txt
Le serveur envoie un message au client accepte la connexion sur le port 2563
Le client attend une connexion sur ce port et renvoie un ACK au serveur
Le serveur initie la connexion et lance le transfert de donnes.
Ce comportement implique que le serveur, dans la zone externe , initie une connexion sur un port choisi par
lui-mme sur le client. Or, nous avons explicitement interdit ce genre de manipulation via notre politique. Il y a
donc deux solutions :
Interdire le Ftp.
Forcer le client utiliser la commande PASV, qui indique que le serveur doit adopter un comportement
passif, et accepter la connexion du client sur un port spcifi par ce dernier. C'est donc le client qui initiera
la connexion, et donc, la connexion sera autorise par le firewall. Avec la commande PASV, l'change se
passe
donc
ainsi
:
-
Le
-
serveur
Le
Le
rpond
client
client
avec l'adresse
demande
envoie
la
commande
et le port auquel le client peut se
le
fichier
index.txt
(RETR
PASV
connecter
index.txt)
Le
serveur
envoie
un
- Le client se connecte et reoit le fichier
reu
et
attend
la
connexion
du
client
La configuration efficace d'un firewall n'est pas chose vidente, et implique une grande rigueur, la moindre erreur
ouvrant une brche exploitable par les hackers.
4.4 - Les ractions des firewalls aux attaques classiques
4.4.1 - IP spoofing
L'IP spoofing consiste modifier les paquets IP afin de faire croire au firewall qu'ils proviennent d'une
adresse IP considre comme de confiance . Par exemple, une IP prsente dans le rseau local de
l'entreprise. Cela laissera donc toute latitude au hacker de passer outre les rgles du firewall afin d'envoyer
ses propres paquets dans le rseau de l'entreprise. Les derniers firewalls peuvent offrir une protection contre
ce type d'attaque, notamment en utilisant un protocole VPN, par exemple IPSec. Cela va crypter les enttes
des paquets, et ainsi rendre impossible leur modification par un intrus, et surtout, l'intrus ne pourra gnrer
de paquets comme provenant de ce rseau local, ce dernier n'ayant pas la cl ncessaire au cryptage. Les
algorithmes utiliss dans de tels protocoles sont de type RSA.
4.4.2 - DOS et DDOS
Le DOS, ou Denial Of Service attack, consiste envoyer le plus de paquets possibles vers un serveur,
gnrant beaucoup de trafic inutile, et bloquant ainsi l'accs aux utilisateurs normaux. Le DDOS, pour
Distributed DOS, implique venir de diffrentes machines simultanes, cette action tant le plus souvent
dclenche par un virus : ce dernier va d'abord infecter nombre de machines, puis une date donne, va
envoyer depuis chaque ordinateur infect des paquets inutiles vers une cible donne. On appelle aussi ce
type d'attaque flood . Les firewalls ici n'ont que peu d'utilit. En effet, une attaque DOS ou DDOS utilise le
plus souvent des adresses sources diffrentes (le but n'est pas de rcuprer une rponse ici) et souvent,
impossible de distinguer ces paquets des autres... Certains firewalls offrent une protection basique contre ce
genre d'attaque, par exemple en droppant les paquets si une source devient trop gourmande, mais
gnralement, ces protections sont inutiles. Cette attaque brute reste un des gros problmes actuels, car elle
est trs difficilement vitable.
4.4.3 - Port scanning
Ceci constitue en fait une pr-attaque (Etape de dcouverte). Elle consiste dterminer quels ports sont
ouverts afin de dterminer quelles sont les vulnrabilits du systme. Le firewall va, dans quasiment tous les
cas, pouvoir bloquer ces scans en annoncent le port comme ferm . Elles sont aussi aisment dtectables
car elles proviennent de la mme source faisant les requtes sur tous les ports de la machine. Il suffit donc
au firewall de bloquer temporairement cette adresse afin de ne renvoyer aucun rsultat au scanner.
4.4.4 - Exploit
Les exploits se font en exploitant les vulnrabilits des logiciels installs, par exemple un serveur Http, Ftp,
etc. Le problme est que ce type d'attaque est trs souvent considr comme des requtes tout a fait
valides et que chaque attaque est diffrente d'une autre, vu que le bug passe souvent par reproduction de
requtes valides non prvues par le programmeur du logiciel. Autrement dit, il est quasiment impossible au
firewall d'intercepter ces attaques, qui sont considres comme des requtes normales au systme, mais
exploitant un bug du serveur le plus souvent. La seule solution est la mise jour priodique des logiciels
utiliss afin de barrer cette voie d'accs au fur et mesure qu'elles sont dcouvertes.
4.5 - Un exemple pratique : netfilter
Le
rseau
est
assez
basique
et
est
install
comme
suit
Le firewall dispose donc de deux cartes rseau, nommes sous linux eth0 et eth1. Nous allons donc dfinir deux
variables dcrivant quelle interface est relie au rseau local et laquelle est relie au WAN. Nous prciseront aussi
le nom de l'interface de loopback (qui redirige vers le routeur lui mme) :
IN="eth1"
EXT="eth0"
LO="lo"
Viennent ensuite plusieurs variables permettant de dcrire dans l'ordre le rseau actuel, les rseaux considrs
comme locaux, le chemin vers le binaire d'iptables et une commande permettant de rcuprer l'IP associe
l'interface externe, donc notre IP sur le WAN :
NETIN="192.168.0.1"
PRIVATE_NETS="10.0.0.0/8 172.16.0.0/12 192.168.0.0/16"
IPTABLES="/sbin/iptables"
EXTIP=`/sbin/ifconfig $EXT | grep inet | cut -d : -f 2 | cut -d \ -f 1`
Ensuite, comme nous voulons que nos machines en local puissant accder au WAN via le Nat, nous allons l'activer
:
echo 1 > /proc/sys/net/ipv4/ip_forward
Enfin vient la configuration en elle mme des rgles du firewall. Iptables repose sur un systme de tables qui
correspondent aux diffrents types de trafic. Ici, nous allons utiliser deux tables, filter et nat. La table nat
regroupe tout le trafic mis en local, tandis que filter lui va regrouper les trafics entrants non expressment
demands en local. A chaque table est associ diffrentes chanes correspondant aux tapes majeures du routage
interne
effectu
pour
ce
type
de
trafic
:
Pour
la
table
filter
INPUT et OUTPUT, si les paquets sont destins au routeur, un de ses processus, alors il va d'abord passer par la
chane INPUT, puis tre dlivr au processus local, qui va mettre ou non une rponse. La rponse, si mise,
devra
tre
conforme
aux
rgles
de
la
chane
OUTPUT.
FORWARD, si le paquet est destin un autre hte du rseau, alors ce dernier devra passer par cette chane.
Pour
PREROUTING,
la
c'est
la
chane
table
qui
va
tre
utilise
nat
pour
faire
du
DNAT,
:
ou
Destination
NAT.
POSTROUTING, elle se trouve la sortie du routeur, et servira faire du SNAT, ou Source NAT, c'est--dire du
masquage d'adresse source (cas typique : quand un ordinateur local veut sortir sur le WAN, le routeur va
remplacer
l'IP
du
paquet
mis
en
local
par
sa
propre
IP).
OUTPUT, cette chane va traiter les rponses mises en local si le paquet avait pour destination le routeur, comme
dans
le
cas
de
la
table
filter.
Nous allons donc initialiser ces tables, et les vider pour tre sur de commencer sur une base saine et vierge :
$IPTABLES -t filter -F INPUT
$IPTABLES -t filter -F FORWARD

$IPTABLES -t filter -F OUTPUT
$IPTABLES -t nat -F PREROUTING
$IPTABLES -t nat -F OUTPUT
$IPTABLES -t nat -F POSTROUTING
A ce stade, nous avons un systme vierge o toutes les chanes sont vides, c'est dire ou aucune rgle n'est en
vigueur. Nous allons donc crer ces rgles. Par dfaut, comme dcrit auparavant, nous allons interdire tout trafic
de la table filter qui ne soit pas expressment autoris. Ces rgles vont tre les politiques par dfaut , grant
le cas o aucune rgle de la chane ne s'applique au paquet concern.
$IPTABLES -t filter -P INPUT DROP
$IPTABLES -t filter -P FORWARD DROP
$IPTABLES -t filter -P OUTPUT DROP
Par contre, comme nous avons confiance en nos utilisateurs, nous allons autoriser le trafic vers l'extrieur
demand en interne. Il nous suffirait de calquer notre politique sur celle de la table filter pour obtenir le mme
type de scurit et fermer des services nos utilisateurs locaux :
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $EXT -j MASQUERADE
Nanmoins, lorsqu'un de nos utilisateurs locaux va demander par exemple une page Http, la rponse va passer
par la table filter et va donc tre jete. Nous devons donc autoriser les rponses revenir leur destinataire :
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Maintenant, nous allons commencer slectionner les paquets qui vont tre autoriss rentrer dans notre
rseau. Comme nous allons autoriser des services, nous devons d'abord tre srs que ces derniers sont autoriss
rentrer. C'est le but de cette commande qui va jeter tous les paquets qui nous sont parvenus dont l'adresse de
destination n'est pas la notre :
if [ -n "$EXTIP" ]; then
$IPTABLES -t nat -A PREROUTING -i $EXT -d ! $EXTIP -j LOG --log-prefix "FW abnormal prerouting: "
$IPTABLES -t nat -A PREROUTING -i $EXT -d ! $EXTIP -j DROP
fi
La loopback est aussi quelque chose que nous pouvons autoriser, il n'y a aucun danger ce que le routeur mette
des paquets pour lui mme :
$IPTABLES -A INPUT -i $LO -j ACCEPT
$IPTABLES -A OUTPUT -o $LO -j ACCEPT
Ensuite, nous allons autoriser tout le trafic expressment mis par le routeur. Il est assez sr d'autoriser cela, car
on imagine que l'administrateur systme et rseau, si il fait son propre firewall en iptables, sait ce qu'il installe sur
son routeur :
$IPTABLES -A OUTPUT -j ACCEPT
$IPTABLES -t nat -A OUTPUT -j ACCEPT
Comme nous avons encore confiance en nos utilisateurs, nous allons autoriser tout le trafic qu'ils gnrent vers le
routeur :
$IPTABLES -A INPUT -m state --state NEW -i $IN -j ACCEPT
$IPTABLES -A OUTPUT -m state --state NEW -o $IN -j ACCEPT
Et nous allons accepter toute redirection de trafic de notre rseau local vers l'extrieur.
$IPTABLES -A FORWARD -m state --state NEW -i $IN -o $EXT -j ACCEPT
A ce stade, tous les paquets entrants passeront par la table filter, et devront donc tre dropps. Nous avons
coup tout accs entrant non expressment autoris. Typiquement, c'est la configuration bastion ou l'entreprise
ne propose aucun service Http ou Ftp, mais veut permettre ses employs de sortir sur le WAN. Nous avons
autoris tout trafic considr comme sr, et si aucune rgle ne s'applique au paquet, il subira la politique par
dfaut
:
si
il
est
interne
il
est
autoris,
si
il
est
externe
il
est
interdit.
Enfin, nous allons autoriser expressment les services que nous ouvrons l'extrieur, par exemple le trafic Http,
qui est de type Tcp sur le port 80 :
$IPTABLES -A INPUT -m state --state NEW -i $EXT -p Tcp --dport 80 -j ACCEPT
Il nous suffit ainsi de rpter cette commande, en mettant le numro de port et le type de trafic ad hoc pour
ouvrir
nos
services
l'extrieur.
Ce firewall est trs robuste et permet ainsi un niveau de scurit assez lev, largement suffisant dans le cas d'un
rseau local.
5 - Conclusion
Nous avons vu, dans cette publication, les diffrents types de firewalls, les diffrentes attaques et parades. Il ne faut
pas perdre de vue qu'aucun firewall n'est infaillible et que tout firewall n'est efficace que si bien configur. De plus, un
firewall n'apporte pas une scurit maximale et n'est pas une fin en soi. Il n'est qu'un outil pour scuriser et ne peut en
aucun cas tre le seul instrument de scurisation d'un rseau. Un systme comportant normment de failles ne
deviendra
jamais
ultra-scuris
juste
par
l'installation
d'un
firewall.
Toutes ces technologies sont et seront en pleine volution, car la base mme de tout cela est de jouer au chat et la
souris entre les hackers et les programmeurs de firewall ainsi que les administrateurs. Une grande bataille
d'imagination qui n'aura certainement jamais de fin.
Saturation du processeur
1 - Le concept
2.1 - Schma
2.2 - Calcul du Checksum IP
2.3 - Calcul du Checksum TCP
2.4 - Calcul du Checksum UDP
4 - Les liens
5 - Les outils
6 - La conclusion
1 - Le concept
Le but est de saturer le processeur de la cible en lui demandant d'effectuer des calculs de checksum. L'attaque peut
tre mise partir d'un poste ou plusieurs simultanment. Dans le premier cas, vous aurez trs souvent vous-mme
besoin d'un bon processeur afin de surpasser celui de la cible, except, si vous utilisez des checksums pr calculs.
Dans le second cas, vous mettez alors l'attaque partir de N postes et disposant ainsi d'une puissance processeur
suprieur votre cible, d'une bande passante suprieur et des points d'accs non concentrs et donc plus difficile
stopper.
2.1 - Schma
Le fonctionnement est de gnrer une trame IP sans application spcifique afin d'obliger la cible calculer le
checksum
de
l'entte
IP afin
de
valider
la
conformit.
2.2 - Calcul du Checksum IP

Voici
le
schma
de
l'entte
IP avec
ce
fameux Checksum bas
sur
octets
La cible devra calculer le checksum pour chaque trame reue sollicitant implicitement son processeur. Le calcul
effectu par la cible est le suivant :

{
// ********************************************************
// ********************************************************
while(taille>1)
{
}
if(taille)
}
L'avantage de cette mthode est d'tre portable sur toutes piles IP, mme si aucun port n'est en coute.
2.3 - Calcul du Checksum TCP
Le fonctionnement est de gnrer une trame TCP afin d'obliger la cible calculer le checksum de l'entte IP et TCP
afin de valider la conformit. Voici le schma de l'entte TCP avec le Checksum bas sur 2 octets :
La cible devra calculer le checksum de l'entte IP puis celui de l'entte TCP pour chaque trame reue sollicitant
implicitement son processeur. Le calcul effectu par la cible pour le Checksum TCP est le suivant :
{
};
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];

// ********************************************************
// ********************************************************
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);
}
L'utilisation du checksum TCP permet d'obtenir de meilleur rsultat, car implicitement, il est combin au checksum
IP.
2.4 - Calcul du Checksum UDP
Le fonctionnement est identique la mthode TCP, pour cela, il faut gnrer une trame UDP afin d'obliger la cible
calculer le checksum de l'entte IP et UDP afin de valider la conformit. Voici le schma de l'entte UDPavec
le Checksum bas
sur
2
octets
:
La cible devra calculer le checksum de l'entte IP puis celui de l'entte UDP pour chaque trame reue sollicitant
implicitement son processeur. Le calcul effectu par la cible pour le Checksum UDP est le suivant :
{
};
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];
// ********************************************************
// ********************************************************
udp_tampon.checksum=0; // Doit tre 0 pour le calcul
// ********************************************************
// Le calcul du Checksum UDP (Idem TCP)
// ********************************************************
// Le calcul passe par une pseudo entete UDP + l'entete UDP + les Data
pseudo_udp.ip_source=ip_source_tampon;
pseudo_udp.ip_destination=ip_destination_tampon;
pseudo_udp.mbz=0;
pseudo_udp.type=IPPROTO_UDP;
pseudo_udp.length=htons((unsigned short)(sizeof(struct udp)+(unsigned short)strlen(data_tampon)));
memcpy(tampon,&pseudo_udp,sizeof(pseudo_udp));
memcpy(tampon+sizeof(pseudo_udp),&udp_tampon,sizeof(struct udp));
memcpy(tampon+sizeof(pseudo_udp)+sizeof(struct udp),data_tampon,strlen(data_tampon));
checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(pseudo_udp)+sizeof(struct
udp)+strlen(data_tampon));
return(checksum);
}

- L'astuce de l'metteur est d'envoyer des trames prconstruites afin de ne pas calculer soit mme le checksum
gagnant
ainsi
un
temps
considrable.
L'utilisation
de smurf augmentera
fortement
le
nombre
de
checksum
calculer.
- Le choix de la taille des donnes est important. Si les trames sont grandes, du style 65535 octets, alors le calcul du
checksum sera plus long et sollicitera plus de processeur.
4 - Les liens
5 - Les outils
- FrameIP est un gnrateur de trames IP. Il vous permettra de personnaliser les champs des diffrentes enttes
rseaux.
Vous
aurez
la
possibilit
grce
cet
outils
de
pr
calculer
les
checksum.
- PingIcmp permet d'effectuer des Ping Icmp sans interruption.
6 - La conclusion
La puissance de calcul est tel maintenant, que mme la combinaison Checksum IP et TCP n'croulera pas les rcents
processeurs. Cependant, destin des petits chipset tel que des botiers d'impression, des routeurs de particulier et
autres, la gne occasionne peut tre consquente.
SynFlood
1 - Le concept
2 - Le Fonctionnement
2.1 - Schma
2.2 - Envoi du SYN
2.3 - Rception par la cible A
2.4 - Rponse de la cible A
2.5 - Rponse de la cible B
4 - Les liens
5 - Les outils
6 - La conclusion
1 - Le concept
L'attaque SynFlood est base sur l'envoi massif de demande d'ouverture de session TCP. Les buts recherchs peuvent
tre
:
Le
Buffer
Overflow
du
process
coutant
- La saturation du nombre d'ouverture de session TCP en cours.
le port
TCP
de
destination.
2.1 - Schma
2.2 - Envoi du SYN

Le fonctionnement est de gnrer une trame TCP de demande de synchronisation destination de la cible. Cette
demande de synchronisation SYN est la premire tape d'une ouverture de session TCP. Voici le schma de
l'entte
TCP avec
ce
fameux flag
SYN bas
sur
1
bit
:
Les 5 autres flags doivent tre positionns 0.

2.3 - Rception par la cible A
La cible recevant la synchronisation TCP mmorise cette demande ncessitant donc de la mmoire et du
processeur. Voici l'tat des connexions d'un Windows XP avant la rception d'un Synflood :
Et
voici
aprs
la
rception
des
demandes
de
SYN
La cible passe les requtes reues en SYN_RECEIVED. Cet tat est temporaire, le temps de dure de vie est
variable
en
fonction
de
la
pile
IP.
Dans mon exemple, la cible tourne sur une station XP limite en nombre de session simultane. Ceci ayant pour
consquence
l'indisponibilit
temporaire
du
port
cibl.
* test depuis la machine ayant effectue le Synflood

2.4 - Rponse de la cible A
Aprs la rception d'une demande de SYN, la cible renvoi une rponse de type SYNACK en positionnant les flags
SYN, ACK 1 et les 4 autres 0. Puis, elle attend l'accus (ACK) finissant l'ouverture de session.
Voici
une
2003.09.23
capture
-
de
trame
Capture
effectue
l'aide
Synflood
de
Sniffer
-
Pro
4.70.04.
SnifferPro.cap
10.10.101.4
Correspond
la
Cible
Vous pourrez remarquer que les 11 premires rponses de la cible sont des SYNACK et que les suivantes sont des
ACKRST ! De plus, dans cet exemple, on peut s'apercevoir que Windows n'ayant pas eu c'est 11 ACK finalisant les
ouvertures de session, rmets ses 11 premiers SYNACK au cas o les trames n'auraient pas aboutis. Cela relve
purement du fonctionnement normal de TCP, du mode connect apportant la garantie de transfert. Mais cela peut
servir dans le cadre d'une attaque spoofe l'attention d'une seconde cible.
2.5 - Rponse de la cible B
Trois
hypothses
en
fonction
de
l'Ip
source
que
vous
aurez
- Le premier cas, correspond ne pas utiliser l'Ipspoofing et donc de faire correspondre la cible B l'metteur
originel. Vous recevrez donc alors le SYNACK de la cible A et vous en ferrez ce que vous dsirez.
- La seconde hypothse est de spcifier une IP non attribue. La rponse de la cible A n'aboutira donc pas et
n'engendra donc pas de trafic supplmentaire. La dure en tat d'attente d'tablissement de session sur la cible
sera au maximum. Except le cas o un routeur informe la cible A via ICMP du drop du paquet ou de l'Ip non
routable.
- La troisime possibilit est de spcifier une correspondance un Hte. Alors celui-ci rpondra certainement (cela
est dpendant de la pile IP) un RST indiquant : Je ne comprend pas ce que tu veux, je n'ai jamais rien
demand, alors ferme cette demande d'ouverture de session qui n'existe pas ! . Intressant, ce point de vue qui
gnre
encore
du
trafic
supplmentaire.
Voici
une
2003.09.23
capture
-
de
trame
Capture
effectue
2
l'aide
Synflood
de
Sniffer
-
Pro
4.70.04.
SnifferPro.cap
*
*
10.10.101.254
10.10.101.4
Correspond
Correspond
la
la
Cible
Cible
A
B
Vous pourrez remarquer que l'on retrouve bien les trois trames qui sont le SYN spoof en Ip source 10.10.101.4,
la rponse SYNACK de la cible A et le RST de la cible B qui n'a pas mit le SYN.

- Il n'y a pas d'intrt remplir la data de TCP, car la rponse ne la prendra pas en compte et ne figurera pas dans la
trame retour. Laissez le champ data vide afin de vous permettre d'conomiser de la bande passante pour gnrer plus
de
SYN.
- Testez cette attaque avec comme Ip source la cible A ou la 127.0.0.1 ou mme 0.0.0.0. Certaine pile Ip n'apprcie
pas
du
tout.
- Une combinaison avec le smurf amplifiera le dbit vers la cible A afin de l'engorger. Tester de spcifier comme Ip
source
le
broadcast
du
rseau
cible!
- Un Synflood avec une Ip source alatoire et changeante chaque SYN risque de blacklister la plante sur l'IDS qui
protge la cible A. Le rsultat sera un serveur devenu inaccessible de tous cause de son dfenseur.
4 - Les liens
5 - Les outils
- SynFlood est un outil spcifique pour l'envoi massif de SYN. De plus, vous pourrez changer l'Ip source volont.
- Frameip vous permettra de gnrer tous type de paquet IP. Ainsi, vous pourrez mettre les SYN volont.
6 - La conclusion
Cette mthode pour but de saturer le nombre de session de la cible. Il peut s'avrer sur certaine pile Ip que le
rsultat soit le crash du daemon coutant le port cibl.
Le smart-spoofing IP
1
2
3
4
5
Introduction
L'ARP cache poisoning
Le filtrage IP
Le spoofing IP
Le smart-spoofing IP
5.1 - Quelques cas de figure
6 - Comment se protger
6.1 - Scurit passive
6.2 - Scurit active
1 - Introduction
Cet article a pour but de prsenter une nouvelle technique de spoofing IP rduisant de manire importante la confiance
que l'on peut avoir dans les solutions de scurit bases sur le filtrage IP source. Cet article ne prsente pas une
nouvelle vulnrabilit, le concept du spoofing IP existant depuis longtemps. Toutefois, la technique employe, base
sur de l'ARP cache poisoning associe de la translation d'adresse, simplifie trs nettement sa mise en oeuvre,
rendant de ce fait les solutions de filtrage IP source incertaines, voire inutiles.
2 - L'ARP cache poisoning

Cette technique vise modifier le routage au niveau 2, et permet de jouer l'attaque de l'intercepteur (Man In The
Middle) sur un LAN. Le protocole ARP est le protocole assurant la correspondance sur un LAN entre les adresses de
niveau 2 (adresses Ethernet) et les adresses de niveau 3 (adresses IP). En modifiant les associations, il est possible de
faire croire une machine que l'adresse IP de son correspondant se trouve en fait l'adresse Ethernet d'une machine
pirate. Le protocole ARP (RFC 826) a t cr sans prendre en compte les aspects d'authentification des machines, de
sorte que n'importe quelle machine sur un rseau est capable de s'annoncer comme propritaire d'une adresse IP.
L'utilisation d'un protocole non scuris, associ de mauvaises implmentations dans les systmes d'exploitation, fait
qu' ce jour, quasiment tous les systmes sont vulnrables de l'ARP cache poisoning. Bien que la RFC dfinisse le
format des messages, il est possible de les envoyer sous de multiples formes. Ainsi, une trame ARP peut tre code de
8 faons diffrentes (broadcast ou unicast, whois ou reply, gratuitous ou pas). Selon le rsultat que l'on veut obtenir
(cration d'une entre en table, mise jour), il est possible d'employer ou de combiner ces messages. Des tests mens
sur de nombreux OS (Unix, Linux, BSD, Windows, IOS, IPSO...) montrent qu'il existe toujours une forme de requte
permettant de les "cache poisoner". Sur certains OS, Windows 9x, NT et 2000, il est mme possible de modifier des
entres dfinies en statique. Ce ne sont pas les seuls. Des tests mens sur un Solaris 8 ont permis d'identifier que cet
OS tait galement vulnrable de l'ARP cache poisoning sur des entres dfinies en statique en utilisant des requtes
de
type
gratuitous.
Les attaques mettant en oeuvre le protocole ARP sont nombreuses et vont de l'coute rseau sur un rseau switch au
dni de service, en passant par le spoofing et l'attaque de l'intercepteur.
3 - Le filtrage IP
Le filtrage IP consiste en la mise en place de rgles de contrle d'accs portant sur l'adresse IP source des paquets
entrant dans un quipement ou une application, qui a alors la possibilit de comparer l'adresse IP source du paquet
entrant avec une liste d'adresses autorises (adresses unitaires ou rseau tout entier). Le paquet IP sera accept
seulement si l'adresse fait partie de cette liste. Dans le cas contraire, le paquet sera rejet (mission d'un refus ou
poubellisation). A noter que d'autres contrles ou traitements sur le paquet peuvent tre appliqus avant de l'accepter
dfinitivement, mais ceci est hors de ce propos. Le concept de filtrage IP est galement la base de la notion de
cloisonnement des rseaux : telle machine ne peut communiquer qu'avec telle autre machine.
Le filtrage IP est donc un composant de scurit de base, simple et performant, que l'on retrouve dans nombre
d'quipements
et
de
logiciels
:
- Firewall avec
Filtres
utilisation
Routeurs
intgrs
dans
de
avec
les
rgles
piles
intgrant
Access
IP
des
l'IP
List
systmes
source
(ACL)
d'exploitation
TCP
Wrapper
sur
les
systmes
unix
- Filtrage IP effectu au sein des applications afin de limiter les communications entre deux machines (transfert de
zone
pour
un
serveur
DNS,
relais
SMTP,
serveur
Web...)
- ...
4 - Le spoofing IP
La mthode du spoofing d'IP source permet de contourner ce filtrage. Elle existe depuis longtemps et certaines
histoires clbres font tat de cette technique. Le concept est simple, les techniques pour y parvenir plus complexes. Il
suffit d'usurper l'adresse IP d'une machine autorise pour profiter de ses privilges. Pour y parvenir, seules les
techniques bases sur la construction manuelle de paquets IP taient jusqu'alors connues. Jumeles de l'coute
rseau, cela permettait au mieux de crer une pseudo communication avec la machine vise. La pile IP du systme
d'exploitation de la machine pirate tait dans ce cas inutilise. Des outils comme dsniff ou ettercap mettent en oeuvre
ce
principe.
Les
mises
en
oeuvre
de
cette
mthode
sont
les
suivantes
:
- Construction de paquets en aveugle. Les paquets sont construits et envoys sur le rseau, sans savoir ce que l'autre
machine
va
rpondre. En TCP,
cela
ncessite de prdire les numros
de
squence
changs.
- Hijacking de connexion TCP. Il s'agit d'attendre l'tablissement d'une connexion par une source autorise, puis de la
voler. Cela ncessite d'tre sur le chemin rseau, d'couter le trafic et de s'insrer dans la connexion. Cette mthode
permet de profiter des privilges de la source, le hijacking tant effectu aprs la phase d'authentification.
- Ecoute du rseau et construction de paquets. Il s'agit d'une mthode similaire au hijacking, mais en crant une
nouvelle connexion. Les paquets sont crits et lus sur le rseau sans passer par la pile IP de la machine, permettant de
spoofer l'adresse de la source. Restera jouer la phase d'authentification. Cf l'article "IP-spoofing Demystified" Les
mthodes prsentes ici sont possibles, mais difficilement exploitables, pour cause d'absence d'outillage volu.
5 - Le smart-spoofing IP
La technique prsente ici abandonne les principes d'coute du rseau et de forgeage de paquets. Elle permet de
spoofer une adresse IP de faon "propre", en permettant n'importe quelle application excute de "profiter" de cette
nouvelle identit. Cette mthode a t nomme le "smart-spoofing IP". Dans la suite de l'article, nous appellerons
"Paris" la machine sur laquelle le filtrage IP est effectu, "Londres" la machine autorise se connecter sur Paris et
"Evil" la machine oprant le smart-spoofing IP. Evil se doit d'tre sur le chemin rseau entre Paris et Londres. Deux
routeurs Rp et Rl sont positionns. Ils correspondent aux "next hops" permettant Evil de joindre respectivement Paris
et Londres. Selon que Evil se situe dans le mme rseau que Paris ou Londres, Rp et Rl pourront se confondre avec
Paris ou Londres. Les explications suivantes continueront identifier Rp et Rl afin de traiter le cas gnral.
Le smart-spoofing IP consiste oprer dans un premier temps un ARP cache poisoning de Rp afin d'insrer dans la
chane de routage niveau 2 des paquets circulant entre Londres et Paris. Il est ncessaire d'activer le routage sur Evil
afin que Londres continue recevoir les paquets qui lui sont destins. Dans le cas o Evil se situe sur le mme LAN que
Paris, un blocage des ICMP redirect sur Evil empchera de laisser trop de traces permettant une dtection de l'attaque.
Les ICMP redirect ne constituent toutefois pas une gne fonctionnelle car le routage a seulement t dtourn au
niveau 2 (les ICMP redirect agissant au niveau 3). Enfin, il est ncessaire d'empcher Rl d'effectuer des requtes ARP
en broadcast, vers d'autres machines. Ces broadcast auraient l'inconvnient de repositionner la vritable adresse ARP
de Rl dans le cache de Rp. Pour ce faire, on remplit le cache ARP de Rl avec l'ensemble des adresses MAC pouvant se
trouver sur le rseau. Il est noter que seul l'ARP cache poisoning de Rp est ncessaire.
Une
fois
ceci
ralis,
l'ensemble
des
paquets
circulant
de
Paris
vers
Londres
passera
par
Evil.
La deuxime tape consiste mettre en place un mcanisme de translation d'adresse source (SNAT) sur Evil, de sorte
que les connexions cres vers Paris le soit avec l'adresse source de Londres. Les paquets en retour seront
naturellement
traits
par
le
processus
de
SNAT
et
renvoys
dans
la
pile
IP
de
Evil.
La dernire tape consiste utiliser le logiciel client de l'application protge par le filtrage IP source (telnet, browser,
ftp, console d'administration...) afin d'accder Paris en se faisant passer pour Londres. Le logiciel client peut tre
excut sur Evil lui-mme ou sur Evil2, une machine sous Windows (pour profiter des GUI spcifiques cet OS) situe
dans un rseau juste derrire Evil. Ce concept a t mis en oeuvre sur une plate forme Linux 7.3 de base, quipe de
l'outil arp-sk pour oprer l'ARP cache poisoning ainsi que de iptables pour la gestion SNAT. L'outil arp-fillup est utilis
afin de saturer le cache ARP de Rl. L'utilisation de VMWare permet de crer sur Evil une machine Evil2 sous Windows,
ainsi
que
le
rseau
ddi
associ.
Cette mthode n'apporte rien de techniquement nouveau. Le spoofing IP tait dj ralisable auparavant. Les risques
pour les systmes taient existants. La nouveaut rside ici dans la simplicit de sa mise en oeuvre, dans la souplesse
d'utilisation qui en suit (utilisation d'une simple application cliente, telle un browser), et dans le nombre d'quipements
contre qui cette mthode peut tre mene. L'utilisation du filtrage IP devient quasiment inutile compte tenu de la
facilit de le contourner. Un certain nombre de rflexions s'en suit, pouvant remettre en question quelques certitudes
dans
le
domaine
de
la
scurit.
Notamment
la
rponse
cette
question
:
Que vaut rellement une rgle de filtrage IP source positionne sur Paris (qu'il soit un firewall, un routeur, une
application...)
et
n'autorisant
que
l'adresse
IP
de
Londres
?
Globalement, il faut considrer que la rgle en question correspond autoriser toutes les machines des rseaux situs
sur le chemin entre Paris et Londres. Ces machines ont en effet la possibilit d'effectuer un ARP cache poisoning de
leur Rp, et donc de se faire passer pour Londres. Ce n'est sans doute pas ce que l'on vous avait expliqu lors de votre
formation sur la cration de rgles sur votre firewall. Ceci est d'autant plus inquitant que les rseaux traverss ne
sont pas tous sous votre contrle (rseau du partenaire, rseau de l'oprateur...) Il est noter certaines techniques
(par exemple le spoofing DNS) permettent de s'insrer sur un chemin rseau (modification du routage au niveau 3
cette
fois
ci)
5.1 - Quelques cas de figure

- Votre architecture d'accs Internet impose le passage par un proxy HTTP incluant des fonctions
d'authentification, de filtrage d'URL, de contrle de contenu, de contrle antivirus et de traabilit. Ce proxy est
situ sur le rseau interne. Il est le seul tre autoris passer le firewall. Pensez-vous encore maintenant que
cet investissement en matire de scurit soit le garant de votre politique de scurit, alors qu'il est si facile de le
contourner ? Il est essentiel de reconsidrer son positionnement dans votre rseau (le placer dans une nouvelle
DMZ par exemple). Le positionnement de telles passerelles ne devrait plus tre prconis sur le rseau interne.
- Le rseau de votre entreprise a t cloisonn pour des raisons de scurit (prsence de serveurs critiques, de
bases de donnes sensibles, interconnexion avec un partenaire, client ou fournisseur...), de performance ou
fonctionnelles (rseau de production, rseau de dveloppement). Des routeurs quips d'ACL "qui vont bien"
permettent,
selon
vous,
d'assurer
la
scurit
car
ils
contrlent
les
flux
changs.
- Les quipements (routeurs, switchs, firewalls, appliance...) de votre rseau sont administrables via telnet et
HTTP. Des ACLs limitent l'accs depuis une machine bien prcise situe dans votre bureau, seule autorise s'y
connecter. En tes-vous si sr ? La rcupration des mots de passe d'accs relve de la mme technique (ARP
cache poisoning). Ds lors, que reste-t-il votre routeur pour se protger si la fois l'authentification et le filtrage
IP
sont
tombs
?
- Il en va de mme des applications protges par un TCP Wrapper (SSH, Telnet, FTP...), d'un serveur Web
possdant une arborescence spcifique, accessible uniquement depuis certaines adresses IP, d'un serveur DNS
matre, n'autorisant le transfert de zone que depuis un serveur secondaire bien prcis, d'un serveur de mail
n'autorisant le flux incoming qu'en provenance d'un relais bien prcis, du processus d'anti-relaying d'un relais de
mails
bas
sur
une
rsolution
inverse
de
l'adresse
IP
source.
Il doit encore tre possible de trouver bon nombre d'autres exemples plus inquitants les uns que les autres.
6 - Comment se protger
Le filtrage IP n'a jamais t considr comme un lment permettant de scuriser un systme. Tout au plus est-il un
frein. Ce document a montr que ce frein est en fait virtuel dans bien des situations. Il n'est d'ailleurs jamais (est-ce
bien sr ?) considr comme unique protection d'accs un quipement ou une ressource. L'accs ncessite
gnralement
une
phase
d'authentification
(par
mot
de
passe...).
Le problme pos ici est issu de l'aspect non scuris de la couche niveau 2 du rseau. Comme celui-ci n'a pas intgr
lors de sa conception (RFC 826) de mcanisme d'authentification forte des extrmits, il est ncessaire de remonter
cette scurit dans les couches suprieures. L'authentification forte des extrmits doit donc tre effectue au niveau
3, ou au niveau applicatif. L'utilisation systmatique de protocoles comme IPSec, SSL, SSH et plus gnralement les
VPNs est donc le seul moyen efficace de protection contre le spoofing IP. Par ailleurs, le chiffrement induit par
l'utilisation de ces technologies permet de supprimer le problme li l'coute sur le rseau. Encore faut-il que cette
cryptographie
soit
mise
en
oeuvre
correctement,
mais
ceci
est
un
autre
dbat.
Par ailleurs, il est galement possible de renforcer la scurit en empchant l'ARP cache poisoning. Le seul moyen d'y
parvenir est de travailler partir d'un rfrentiel de ce que devraient tre les associations adresses IP/MAC. Il s'agit en
gnral de mesures lourdes administrer, et dont l'efficacit est toute relative. Elle n'a comme porte que le segment
rseau du LAN. Si le paquet a travers un rseau non matris, alors rien ne vous prouve qu'il ne provient pas de la
machine Evil.
6.1 - Scurit passive
Il s'agit de mesures visant empcher l'ARP cache poisoning, en figeant l'association IP/MAC sur les OS
(utilisation des entres statiques des tables ARP). Ceci est lourd et pratiquement inexploitable grande chelle.
Qui plus est, certains OS grent mal ces entres statiques qui peuvent tre alors corrompues. C'est le cas des
Windows 9x, NT et 2000 (XP a corrig le problme). Ces OS sont donc fondamentalement vulnrables ce type
d'attaque et font profiter de leur faiblesse les logiciels (firewall, proxy, serveurs web...) qui leur sont ddis.
Le verrouillage IP/MAC peut galement tre pris en charge au niveau applicatif. Par exemple, certains firewalls
(dont iptables) sont capables de contrler l'association IP/MAC des paquets entrants. L'utilisation de
commutateurs de niveau 3, capables de grer l'association MAC/IP/port est galement une solution au problme.
6.2 - Scurit active
Lorsqu'il n'est pas raliste de verrouiller les entres ARP de chaque machine, il est possible de mettre en oeuvre
une solution de dtection centralise, qui agit comme une sonde de dtection. Certaines sondes sont d'ailleurs
capables de dtecter des paquets ARP anormaux, susceptibles de signifier un ARP cache poisoning. Cependant,
cette attaque tant ralisable avec des paquets normaux, la sonde n'a que peu d'intrt. L'utilisation de logiciels
comme arpwatch permet de centraliser les associations MAC/IP, et de contrler en temps rel les messages ARP
pour vrifier qu'un poisoning n'est pas en cours. Des alertes sont alors gnres en cas de divergence. Il pourrait
mme tre envisag un systme de contre mesure consistant repositionner la bonne association MAC/IP sur une
machine venant de se faire poisoner. Ce repositionnement pourrait s'effectuer par le mme processus que celui
qui a permis l'attaque : par ARP cache poisoning !
Smurf
1 - Le concept
2.1 - Schma
2.2 - Envoi
2.3 - Rception sur le rseau cible A
2.4 - Rponse du rseau cible A
4 - Les liens
5 - Les outils
6 - La conclusion
1 - Le concept
Le concept est d'mettre une trame de type ICMP une adresse IP de Broacast rseau. Cela permettant de s'adresser
plusieurs host simultanment appel Amplificateur . Le rsultat vous multiplie l'attaque par n fois.
2.1 - Schma
2.2 - Envoi
L'metteur envoi une trame Ip du type Icmp l'adresse de broacast du rseau cible A. Voici le schma de l'entte
IP avec le champ Type protocol bas sur 1 octet ainsi que le positionnement du broadcast dans le champs Ip
Destination
bas
sur
4
octets
:
2.3 - Rception sur le rseau cible A
Lorsque la trame arrive sur le Lan du rseau cible A, tous les priphriques la rceptionnent et la considrent.
Cela est d au fait quelle est destine l'adresse IP de broadcast signifiant Pour tous le monde . Ils
l'interprtent tous individuellement comme ci elle leur tait directement adress.
2.4 - Rponse du rseau cible A
Les priphriques du rseau cible A vont rpondre l'Ip source de la trame reu correspondant la cible B vis.
La rponse sera bien sur envoye n fois correspondant au nombre d'hte sur le LAN rpondant au broadcast.
Voici une capture de trame ralise l'aide de Sniffer Pro 4.70.04 montrant un ping sur l'adresse broadcast du
rseau
210.169.164.0/24.
Vous
pourrez
remarquer
les
73
rponses.
2003.09.27
2003.09.27
Capture
Capture
Smurf
Smurf
Netmon.cap (version
Network
SnifferPro.cap (version
Moniteur
Sniffer
2)
Pro)
Attention, certaine pile IP, tel que celle de Windows, ne rpondent pas au broadcast d une dsactivation par
dfaut.
Attention, si vous dsirez recevoir les rponses votre broadcast, l'analyse de trame ne vous montrera rien du
tout si vous utilisez du PAT (Port Address Translation). Car cette configuration vous empchera de rceptionner
les rponses du fait que les trames retours n'auront pas de correspondance avec l'Echo sortant.
- Vous pourrez multipliez une attaque si vous visez deux rseaux broadcast IP. Pour cela, vous spcifiez le premier en
IP
destination
et
le
second
en
IP
source.
L'effet
sera
ravageur.
- Vous pouvez utilisez un autre protocole que ICMP comme UDP bas sur le port 7 (echo). Le principe reste le mme,
sauf que le nom de l'attaque se nomme alors Fraggle .
4 - Les liens
- Un
article
- The
du
White
journal
Zdnet
Paper
5 - Les outils
-
2003.09.27 - Liste des IP - Smurf.xls reprsente la liste des blocs d'adresses IP ouverts au Smurf.
Pingicmp permet d'envoyer un paquet Icmp trs rapidement et bien sr des adresses de Broadcast.
Synflood, permet de gnrer une attaque bas sur le SYN TCP et bien sur des adresses de Broadcast.
FrameIP, permet de gnrer des trames IP et destination d'un Broadcast, vous ferez ce que vous voulez.
6 - La conclusion
Ce concept permet d'amplifier une attaque et vous aidera gnrer le nombre de trame ncessaire une liaison de
type Dial et xDsl.

All Cours Rezo 430 Pages

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

All Cours Rezo 430 Pages

Diunggah oleh

Hak Cipta:

Format Tersedia

RESEAUX

3 - Comparaison avec le modle OSI et critique

2 - Les diffrentes couches du modle

3 - Transmission de donnes au travers du modle OSI

4 - Critique du modle OSI

RFC : A Novice's Guide to the Internet Engineering Task Force

RFC : Multiprotocol Encapsulation over ATM Adaptation Layer 5

RFC : Multiprotocol Encapsulation over ATM Adaptation Layer 5

RFC : Errata de la RFC 894

RFC : Extensible Authentication Protocol (EAP)

RFC : The Point-to-Point Protocol (PPP)

RFC : PPP Vendor Extensions

RFC : A Method for Transmitting PPP Over Ethernet (PPPoE)

RFC : Une mthode pour la transmission du PPP sur ethernet

RFC : Point-to-Point Tunneling Protocol (PPTP)

RFC : Protocole de transmission sous tunnel point point

RFC : Internet Protocol

RFC : Internet Protocol

RFC : Ip Datagram Reassembly Algorithms

RFC : Computing the Internet Checksum

RFC : Assigned Numbers (Remplac par la RFC 1700)

RFC : Assigned Numbers

RFC : Type of Service in the Internet Protocol Suite

RFC : An Architecture for IP Address Allocation with CIDR

RFC : The IP Network Address Translator (NAT)

RFC : Variable Length Subnet Table For IPv4

RFC : Address Allocation for Private Internets

RFC : Internet Protocol, Version 6 (IPv6) - Specification

RFC : IP Authentication Header

RFC : IP Encapsulating Security Payload (ESP)

RFC : An Ethernet Address Resolution Protocol

RFC : IPv4 Address Conflict Detection

RFC : A Reverse Address Resolution Protocol

RFC : Host Extensions for Ip Multicasting

RFC : Internet Group Management Protocol, Version 2

RFC : Internet Control Message Protocol

RFC : Internet Control Message Protocol

RFC : Icmp Router Discovery Messages

RFC : Transmission Control Protocol

RFC : Transmission Control Protocol

RFC : Congestion Control in Ip/Tcp Internetworks

RFC : Computing the Internet Checksum

RFC : Assigned Numbers

RFC : TCP Extensions for High Performance

RFC : TCP Selective Acknowledgment Options

RFC : User Datagram Protocol

RFC : User Datagram Protocol

RFC : Computing the Internet Checksum

RFC : Assigned Numbers

RFC : Bootstrap Protocol (Bootp)

RFC : Protocole d'amorage (Bootp)

RFC : Bootp Vendor Information Extensions

RFC : Dynamic Host Configuration Protocol

RFC : Clarifications and Extensions for the Bootstrap Protocol

RFC : Dynamic Host Configuration Protocol

RFC : Protocole de configuration dynamique de machine (DHCP)

RFC : Dhcp Options and Bootp Vendor Extensions

RFC : Options DHCP et Extensions fournisseur BOOTP

RFC : Security Architecture for the Internet Protocol

RFC : Architecture de scurit pour IP

RFC : IP Authentication Header

RFC : IP Encapsulating Security Payload (ESP)

RFC : Internet Security Association and Key Management Protocol (ISAKMP)

RFC : The Internet Key Exchange (IKE)