You are on page 1of 52

Guillaume Desgeorge

INTRODUCTION......................................................................................................................................................................3
LA FAMILLE TCP/IP ...............................................................................................................................................................5
I. TCP : TRANSMISSION CONTROL PROTOCOL.......................................................................................................... 5
II. LE PROTOCOLE IP........................................................................................................................................................ 12
III. UDP : USER DATAGRAM PROTOCOL.................................................................................................................... 17
IV. ICMP : INTERNET CONTROL MESSAGE PROTOCOL......................................................................................... 18
V. SNMP : SIMPLE NETWORK M ANAGEMENT PROTOCOL......................................................................................... 19
VI. ARP : ADDRESS RESOLUTION PROTOCOL.......................................................................................................... 21
VII. RIP2 : ROUTING INFORMATION PROTOCOL 2................................................................................................... 23
LE PROTOCOLE X25 ...........................................................................................................................................................24
I. LAPB.................................................................................................................................................................................. 24
II. X25 .................................................................................................................................................................................... 26
III. HDLC............................................................................................................................................................................... 27
RNIS : RSEAU NUMRIQUE INTGRATION DE SERVICES ..............................................................................28
1.A RCHITECTURE ................................................................................................................................................................ 28
2.SPCIFICATIONS............................................................................................................................................................... 28
LES PROTOCOLES NOVELL.............................................................................................................................................30
I. IPX...................................................................................................................................................................................... 30
II. RIPX.................................................................................................................................................................................. 31
III. BCAST ............................................................................................................................................................................ 32
IV. DIAG................................................................................................................................................................................ 32
V. SER.................................................................................................................................................................................... 33
VI. WDOG............................................................................................................................................................................. 33
VII. SPX................................................................................................................................................................................. 34
VIII. SAP............................................................................................................................................................................... 34
IX. NOVELNET BIOS............................................................................................................................................................. 35
X. BMP (BURST ) .................................................................................................................................................................. 36
XI. NCP.................................................................................................................................................................................. 37
IPV6 ...........................................................................................................................................................................................39
POURQUOI UNE NOUVELLE VERSION D'IP ?.............................................................................................................. 39
DESCRIPTION DES PRINCIPALES CARACTRISTIQUES D'IPV6........................................................................... 39
FORMAT D'EN-TTE IPV6 ............................................................................................................................................... 41
EN-TTES SUPPLMENTAIRES..................................................................................................................................... 41
ANNEXES .................................................................................................................................................................................47
PROTOCOL NUMBERS ..................................................................................................................................................... 47
PORT NUMBERS ................................................................................................................................................................ 49

Guillaume Desgeorge

INTRODUCTION
Le but des rseaux est de faire communiquer plusieurs ordinateurs ensemble. Si les hommes
communiquent entre eux grce aux diffrentes langues, les ordinateurs utilisent diffrents protocoles.
Les communications sont souvent internationales, et comme pour les hommes, il n'existe pas de
protocole universel. Certains sont plus utiliss que d'autres, il en existe cependant un trs grand nombre,
chacun cherchant imposer sa propre norme. Par soucis de clart, nous n'tudierons dans ce rapport
que les protocoles les plus courants.
Comment expliquer clairement ce qu'est un protocole? Supposons que quelqu'un veuille envoyer
une lettre quelqu'un d'autre. On va placer cette lettre dans une enveloppe et on y notera l'adresse. Pour
l'acheminement du courrier, le contenu de la lettre n'est d'aucune utilit. Les diffrents services de la
poste regardent les diffrents champs de l'adresse et dirigent l'enveloppe, donc son contenu dans la
bonne direction.
Il en est de mme quand un ordinateur veut envoyer des donnes un autre ordinateur. Les
donnes sont enfermes (on dit encapsules) dans une enveloppe qui contient les informations
permettant l'acheminement des donnes. Un protocole, c'est la faon dont l'adresse est crite sur
l'enveloppe, le fait de mettre d'abord le nom, puis la rue et enfin la ville. Un autre protocole, c'est aussi le
fait de mettre le lieu et la date en haut droite et la signature en bas.
Finalement, un protocole est une description formelle de rgles et de conventions suivre dans
un change d'informations, que ce soit pour acheminer les donnes jusqu'au destinataire ou pour que le
destinataire comprenne comment il doit utiliser les donnes qu'il a reues.
Pour s'y retrouver plus facilement dans l'ensemble des protocoles, l'International Standard
Organization (ISO) a dfini un modle de base appel modle OSI. Ce modle dfinit 7 niveaux diffrents
pour le transfert de donnes. Ces niveaux sont galement appels couches.
Le septime niveau, la couche Application, gre le transfert des informations entre programmes.
Le sixime niveau, la couche Prsentation, s'occupe de la mise en forme des textes et des conventions
d'affichage. Le cinquime niveau, la couche Session, s'occupe de l'tablissement, de la gestion et
coordination des communications. Le quatrime niveau, la couche Transport, gre la remise correcte des
informations. Vient ensuite le niveau trois, la couche Rseau, qui dtermine les routes de transport et qui
s'occupe du traitement et du transfert de messages. Le niveau deux, la couche Liaison de donnes,
s'occupe du codage, de l'adressage, et de la transmission des informations. Le premier niveau, la
couche physique, gre les connections matrielles.
A chacun de ces niveaux, on encapsule un en-tte et une fin de trame qui comporte les
informations ncessaires en suivant les rgles dfinies par le protocole utilis. Sur le schma cidessous, la partie qui est rajoute chaque niveau est la partie sur fond blanc. La partie sur fond gris
est celle obtenue aprs encapsulation du niveau prcdent. La dernire trame, celle qu'on obtient aprs
avoir encapsul la couche physique, est celle qui sera envoye sur le rseau.

Guillaume Desgeorge

Le modle OSI

Donnes

niveau 7 : Application

Application donnes 7

niveau 6 : Prsentation

Prsentation niveau 1 6

Session

Transport

Rseau

Liaison de donnes

Physique

niveau 1 &
2
niveau 1, 2 &
3
niveau 1 4

niveau 5 : Session

niveau 4 : Transport

niveau 1 5

niveau 1 6

Guillaume Desgeorge

niveau 3 : Rseau
2

niveau 2 : Liaison
niveau 1 : Physique

LA FAMILLE TCP/IP
I. TCP : TRANSMISSION CONTROL PROTOCOL
1. INTRODUCTION
Le protocole TCP est dfini dans le but de fournir un service de transfert de donnes de haute fiabilit
entre deux ordinateurs "matres" raccords sur un rseau de type "paquets commuts", et sur tout
systme rsultant de l'interconnexion de ce type de rseaux.
1.Motivation
La communication entre systmes d'information joue un rle croissant dans les domaines militaires,
institutionnels, scientifiques et commerciaux.
Au fur et mesure que les rseaux de communication informatiques caractre stratgiques ou
tactiques sont dploys, il devient essentiel de trouver un moyen d'interconnexion de ces rseaux, et
des standards de transmission de donnes permettant de supporter une vaste gamme d'applications.
Anticipant le besoin de tels standards, le dput et sous-secrtaire d'tat la recherche de la Dfense
Amricaine a officialis le protocole dcrit ici en tant que base pour la standardisation des processus
d'intercommunication de donnes du Dpartement de la Dfense Amricaine (DoD).
TCP est un protocole scuris orient connexion conu pour s'implanter dans un ensemble de
protocoles multicouches, supportant le fonctionnement de rseaux htrognes. TCP fournit un moyen
d'tablir une communication fiable entre deux tches excutes sur deux ordinateurs autonomes
raccords un rseau de donnes. Le protocole TCP s'affranchit le plus possible de la fiabilit
intrinsques des couches infrieures de communication sur lesquelles il s'appuie. TCP suppose donc
uniquement que les couches de communication qui lui sont infrieures lui procurent un service de
transmission de paquet simple, dont la qualit n'est pas garantie.
En principe, TCP doit pouvoir supporter la transmission de donnes sur une large gamme
d'implmentations de rseaux, depuis les liaisons filaires cbles, jusqu'aux rseaux commuts, ou
asynchrones.
TCP s'intgre dans une architecture multicouche des protocoles, juste au-dessus du protocole Internet
IP. Ce dernier permet TCP l'envoi et la rception de segments de longueur variable, encapsuls dans
un paquet Internet appel aussi "datagramme". Le datagramme Internet dispose des mcanismes
permettant l'adressage d'un service TCP source et un destinataire, quelles que soient leur position dans
le rseau. Le protocole IP s'occupe aussi de la fragmentation et du rassemblage des paquets TCP lors
de la traverse de rseaux de plus faibles caractristiques. Le protocole IP transporte aussi les
informations de priorit, compartimentation et classification en termes de scurit relatives aux
segments TCP. Ces informations se retrouvent alors transmises de bout en bout de la communication.

Couches de protocoles
Niveaux Suprieurs
TCP
IP
Couche Physique

Guillaume Desgeorge

De grandes parties de ce document sont crites dans un contexte o les implmentations TCP sont
concomitantes d'autres protocoles de haut niveau dans la mme machine. Certains systmes
informatiques seront raccords au rseau via un frontal qui accueillera les fonctions TCP et IP, ainsi que
les protocoles rseau de bas niveau. La spcification TCP dcrit une interface destination des
applications de niveau suprieur, y compris dans le cas d'une architecture avec un frontal, pour autant
que les protocoles "poste vers frontal" soient implments.
1.2. Porte
TCP prtend fournir un service de communication de processus processus, dans un environnement
rseau complexe. TCP est dfini comme un protocole de communication "host to host", c'est dire de
matre matre (par opposition "central terminal").

2. SPECIFICATION FONCTIONNELLE
2.1. Format de l'en-tte
Les paquets TCP sont envoys sous forme de datagrammes Internet. L'en-tte IP transmet
un certain nombre de paramtres, tels que les adresses Internet source et destinataires.
L'en-tte TCP est place la suite, contenant les informations spcifiques au protocole
TCP. Cette division permet l'utilisation de protocoles autres que TCP, au dessus de la
couche IP.
En-tte TCP
0
Port Source
Numro de squence
Accus de rception
Data
Rserv
Offset
Checksum
Option
Data

16

32bits
Port Destination

Fentre
Pointeur donnes urgentes
Bourrage

Port source: 16 bits


Le numro de port de la source.
Port Destinataire: 16 bits
Le numro de port du destinataire.
Numro de squence: 32 bits
Le numro du premier octet de donnes par rapport au dbut de la transmission (sauf si SYN est
marqu). Si SYN est marqu, le numro de squence est le numro de squence initial (ISN) et le
premier octet pour numro ISN+1.
Accus de rception: 32 bits
Si ACK est marqu ce champ contient le numro de squence du prochain octet que le rcepteur
s'attend recevoir. Une fois la connexion tablie, ce champ est toujours renseign.
Data Offset: 4 bits

Guillaume Desgeorge

La taille de l'en-tte TCP en nombre de mots de 32 bits. Il indique l ou commence les donnes. L'entte TCP, dans tous les cas une taille correspondant un nombre entier de mots de 32 bits.
Rserv: 6 bits
Rservs pour usage futur. Doivent ncessairement tre 0.
Bits de contrle: 6 bits (de gauche droite):
URG: Pointeur de donnes urgentes significatif
ACK: Accus de rception significatif
PSH: Fonction Push
RST: Rinitialisation de la connexion
SYN: Synchronisation des numros de squence
FIN: Fin de transmission
Fentre: 16 bits
Le nombre d'octets partir de la position marque dans l'accus de rception que le rcepteur est
capable de recevoir.
Checksum: 16 bits
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 marqus 0.
Le Checksum couvre de plus une pseudo en-tte de 96 bits prfixe l'en-tte TCP. Cette pseudo entte comporte les adresses Internet source et destinataires, le type de protocole et la longueur du
message TCP. Ceci protge TCP contre les erreurs de routage. Cette information sera vhicule par IP,
et est donne comme argument par l'interface TCP/Rseau lors des appels d'IP par TCP.
Adresse Source
Adresse Destinataire
Zro
PTCL
0

Longueur TCP
32bits

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.
Pointeur de donnes urgentes: 16 bits
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 champs n'est interprt que
lorsque URG est marqu.
Options: variable
Les champs d'option 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 1: Option mono-octet.
Cas 2: Octet de type d'option, octet de longueur d'option, octets de valeurs d'option.

Guillaume Desgeorge

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 octets.
Notez que la liste d'option peut tre plus courte que ce que l'offset de donnes pourrait le faire supposer.
Un octet de remplissage (padding) devra tre dans ce cas rajout aprs le code de fin d'options. Ce octet
est ncessairement 0.
TCP doit implmenter toutes les options.
Actuellement, les options dfinies sont (type indiqu en octal):
Type
---0
1
2

Longueur
-----4

Description
------Fin de liste d'option
Nop
Taille de segment maximal

Dfinition des options spcifiques :


Fin de liste d'options
00000000
Type=0
Ce code indique la fin du champ d'options. Sa position peut ne pas concider avec l'indication du dbut
du champ de donnes marqu dans l'Offset de donnes. Il doit tre plac aprs toutes les options, et
non aprs chaque option. Il ne doit tre utilis que dans le cas ou la fin des options ne concide pas avec
le dbut du champ de donnes.
No-Operation
00000001
Type=1
Cette option peut tre utilise entre deux options, par exemple pour aligner le dbut d'une option sur un
dbut de mot de 16 bits. L'utilisation de ce sparateur n'est pas une obligation. L'implmentation doit
donc prvoir de pouvoir prendre en compte un option mme au milieu d'un mot.
Taille maximale de segment
00000010

00000100

Taille max segment

Type=2 Longueur=4
Donne d'option : Taille maximale de segment: 16 bits
Si cette option est prsente, elle communique l'metteur la taille maximale des segments qu'il pourra
envoyer. Ce champ doit tre envoy dans la requte de connexion initiale (avec SYN marqu). Si cette
option est absente, le segment pourra tre pris de n'importe quelle taille.
Bourrage (padding): variable
Les octets de bourrage terminent l'en-tte TCP:
de sorte que le nombre d'octet de celle-ci soit toujours multiple de 4 (32 bits)
de sorte que l'offset de donnes marqu dans l'en-tte corresponde bien au dbut
des donnes applicatives.
Guillaume Desgeorge

3. Etablissement et rupture des connexions


TCP indique un identificateur de port. Comme ces identificateurs sont choisis indpendamment par
chaque extrmit, ils peuvent se rvler identiques. L'adresse unique d'une communication TCP est
obtenue par la concatnation de l'adresse Internet avec l'identificateur du port slectionn, constituant
ainsi ce que l'on nome une "socket". Cette socket est alors unique dans l'ensemble du rseau.
Une connexion de base est dfinie par un couple de sockets, l'un dfinissant l'metteur, l'autre le
rcepteur. Un socket peut devenir le destinataire ou la source pour plusieurs sockets distinctes. La
connexion est rsolument bidirectionnelle, et prend la dnomination de "full-duplex".
TCP est libre d'associer ses ports avec les processus excuts sur sa machine. Cependant, quelques
rgles ont t tablies pour l'implmentation. Ont t dfinis un certain nombre de sockets "rservs"
que TCP ne doit associer qu'avec certains processus bien identifis. Ceci revient dire que certains
processus peuvent s'attribuer la proprit de certains ports, et ne pourront initier de communication que
sur ceux-ci. (Actuellement, cette "proprit" est issue d'une implmentation locale, mais nous
envisageons une commande utilisateur Request Port, ou une autre mthode pour assigner
automatiquement un ensemble de ports une application, par exemple en utilisant quelques bits de
poids fort du numro de port pour coder l'application).
Une connexion est demande par activation de la commande OPEN indiquant le port local et les
paramtres du socket distant. En retour, TCP rpond par un nom local (court) symbolique que
l'application utilisera dans ses prochains appels. Plusieurs choses doivent tre retenues propos des
connexions. Pour garder la trace de cette connexion, nous supposons l'existence d'une structure de
donnes appele Transmission Control Block (TCB). Une des stratgies d'implmentation est de dire
que le nom local donn est un pointeur vers le TCB associ cette connexion. La commande OPEN
spcifie en outre si le processus de connexion doit tre effectu jusqu' son terme, ou s'il s'agit d'une
ouverture en mode passif.
Une ouverture passive signifie que le processus de connexion se met en attente d'une demande de
connexion plutt que de l'initier lui-mme. Dans la plupart des cas, ce mode est utilis lorsque
l'application est prte rpondre tout appel. Dans ce cas, le socket distant spcifi n'est compos que
de zros (socket indfini). Le socket indfini ne peut tre pass TCP que dans le cas d'une connexion
passive.
Un utilitaire dsireux de fournir un service un processus non identifi pourra initier une connexion
passive. Tout appelant effectuant une requte de connexion sur le socket local sera reconnu. Il sera bon
de garder en mmoire que ce socket est associ ce service.
Les sockets "rservs" sont un bon moyen d'associer priori des ports des applications standard. Par
exemple, le serveur "Telnet" est en permanence associ un socket particulier, d'autres tant rservs
pour les transferts de fichiers, sessions de terminal distant, gnrateur de texte, cho (ces deux pour
des besoins de test), etc. Un socket peut tre rserv la fonction de serveur de domaines, transcodant
les "noms explicites" de services en sockets Internet. Si le concept mme de l'assignation priori de
sockets fait partie de TCP, l'assignation concrte des sockets "rservs" est dfinie dans un autre
document.
Les processus peuvent ouvrir une connexion passive et attendre qu'une connexion active les impliquant
provienne d'une autre machine. TCP aura la charge d'avertir l'application qu'une communication est
tablie. Deux processus mettant au mme moment une requte de connexion l'un vers l'autre se
retrouveront normalement connects. Cette souplesse est indispensable pour assurer un bon
fonctionnement du rseau compos d'lments totalement asynchrones.
Les deux cas de conclusion d'une communication impliquant une connexion passive et une active sont
les suivants. Soit le socket distant a t prcis lors de la requte de connexion passive, auquel cas
seule une requte de connexion du distant attendu vers le local peut aboutir l'tablissement d'une

Guillaume Desgeorge

communication. Soit le socket distant a t laiss indfini, et toute requte de connexion sur le socket
local, d'o qu'elle vienne aboutit une communication valide. D'autres fonctionnalits permettront une
acceptation sur correspondance partielle entre sockets.
Si plusieurs requtes de connexion passive sont en attente (enregistres dans la table de TCBs) pour le
mme socket local, et qu'une demande de connexion active provient de l'extrieur, le protocole prvoit de
d'abord chercher s'il l'une des requtes dont le socket distant a t clairement exprim correspond
celui de la demande. Si tel est le cas, ce socket sera activ. Sinon, c'est une requte "indfinie" qui sera
active.
La procdure de connexion utilise le bit de contrle de synchronisation (SYN) et suppose la
transmission de trois messages. Cet change est appel "ngociation ternaire".
La connexion suppose le rendez-vous d'un segment marqu du bit SYN et d'une requte locale (TCB),
chacun des deux tant cr par l'excution d'une commande de connexion. La correspondance entre le
socket arriv et le socket attendu dtermine l'opportunit de la connexion. Celle-ci ne devient rellement
tablie que lorsque les deux numros de squence ont t synchroniss dans les deux directions.
La rupture d'une connexion suppose l'mission de segments, marqus du bit FIN.

4. Communication de donnes
Les donnes circulant dans la connexion ouverte doivent tre vues comme un flux d'octets. L'application
indique dans la commande SEND si les donnes soumises lors de cet appel (et toutes celles en
attente) doivent tre immdiatement mises par l'activation du flag PUSH.
Par dfaut, TCP reste libre de stocker les donnes soumises par l'application pour les mettre sa
convenance, jusqu' ce que le signal PUSH soit activ. Dans ce dernier cas, toutes les donnes non
mises doivent tre envoyes. Symtriquement, lorsque le TCP rcepteur voit le flag PUSH marqu, il
devra passer immdiatement toutes les donnes collectes l'application destinataire.
Il n'y a priori aucune corrlation entre la fonction PUSH et les limites des segments. Les donnes d'un
segment peuvent tre le rsultat d'une seule commande SEND, en tout ou partie, ou celui de plusieurs
appels SEND.
La fonction de la fonction push et du flag PUSH est de forcer la transmission immdiate de toutes les
donnes latentes entre les deux TCP. Il ne s'agit aucunement d'une fonction d'enregistrement (Cf.
langage Perl).
Il y a par contre une relation entre la fonction push et l'usage des tampons dans l'interface
TCP/application. Chaque fois qu'un flag PUSH est associ des donnes stockes dans le tampon de
rception, celui-ci est intgralement transmis l'application mme s'il n'est pas plein. Si le tampon est
rempli avant qu'un flag PUSH soit vu, les donnes sont transmises l'application par lments de la
taille du tampon.
TCP dispose d'un moyen d'avertir l'application que, dans le flux de donnes qu'il est en train de lire, au
del de la position de lecture courante, des donnes de caractre urgent sont apparues. TCP ne dfinit
pas ce que l'application est sense faire lorsqu'elle est avise de la prsence de ces donnes. En
gnral, c'est l'implmentation de l'application qui traitera ces donnes urgentes selon ses besoins
propres.

5. Priorit et Scurit
TCP utilise le champ "type de service" et les options de scurit du protocole Internet pour fournir les
fonctions relatives la priorit et la scurit des communications TCP, sur un principe de "dtection".
Tous les modules TCP ne fonctionneront pas ncessairement dans un environnement scuris
plusieurs niveaux; certains pourront tre limits un fonctionnement sans scurit, d'autres ne pourront
Guillaume Desgeorge

10

prendre en compte qu'un seul niveau la fois. Par consquent, les implmentations TCP ne pourront
rpondre en termes de scurit qu' un sous ensembles de cas du modle scuris multi-niveaux.
Les modules TCP oprant dans un environnement scuris plusieurs niveaux devront correctement
renseigner les segments sortants en termes de scurit, niveau de scurit, et priorit. De tels modules
TCP doivent fournir aux applications suprieures telles que Telnet ou THP une interface leur permettant
de spcifier ces paramtres.

Guillaume Desgeorge

11

II. LE PROTOCOLE IP
1. Description fonctionnelle
La fonction ou rle du Protocole Internet est d'acheminer les datagrammes travers un ensemble de
rseaux interconnects. Ceci est ralis en transfrant les datagrammes d'un module Internet l'autre
jusqu' atteindre la destination. Les modules Internet sont des programmes excuts dans des htes et
des routeurs du rseau Internet. Les datagrammes sont transfrs d'un module Internet l'autre sur un
segment particulier de rseau selon l'interprtation d'une adresse Internet. De ce fait, un des plus
importants mcanismes du protocole Internet est la gestion de cette adresse Internet.
Lors de l'acheminement d'un datagramme d'un module Internet vers un autre, les datagrammes peuvent
avoir ventuellement traverser une section de rseau qui admet une taille maximale de paquet
infrieure celle du datagramme. Pour surmonter ce problme, un mcanisme de fragmentation est gr
par le protocole Internet.
Adressage
Une distinction doit tre faite entre noms, adresses, et chemins. Un nom indique ce que nous
cherchons. Une adresse indique o cela se trouve. Un chemin indique comment y aboutir. Le protocole
Internet s'occupe essentiellement des adresses. C'est des protocoles de niveau plus lev (ex., htevers-hte ou application) que revient la tche de lier des noms des adresses. Le module Internet dduit
de l'adresse Internet une adresse rseau local. La tche qui consiste transcrire l'adresse de rseau
local en termes de chemin (ex., sur un rseau local ou dans un routeur) revient au protocole de bas
niveau.
Les adresses ont une longueur fixe de 4 octets (32 bits). Une adresse commence toujours par un
numro de rseau, suivi d'une adresse locale (appele le champ "reste") codant l'adresse de l'hte sur
ce rseau. Il existe trois formats ou classes d'adresses Internet : pour la classe A, le bit de poids fort
vaut zro, les 7 bits suivants dsignent le rseau, les derniers 24 bits dsignent l'adresse locale de la
machine; pour la classe B, les deux bits de poids fort valent 1 et 0, les 14 bits suivants dsignent le
rseau et les 16 derniers bits l'adresse locale de machine ; pour la classe C, les trois bits de poids fort
forment le schme 110, les 21 bits suivants forment l'adresse rseau et les 8 derniers bits l'adresse
locale.
La transcription d'adresse Internet en adresses de rseau local doit tre sujette quelques prcautions ;
un hte physique unique peut abriter plusieurs adresses Internet distinctes comme s'il s'agissait de
plusieurs htes indpendants. Certains htes peuvent disposer de plusieurs interfaces physiques (multihoming).
De ce fait, il faudra pouvoir considrer le cas d'un hte plusieurs interfaces physiques chacune abritant
plusieurs adresses Internet distinctes.
Des exemples de rpartition d'adresses peuvent tre trouvs dans "Address Mappings" (rfc 1060).
Fragmentation
La fragmentation du datagramme Internet devient ncessaire ds lors qu'un datagramme de grande taille
arrive sur une portion de rseau qui n'accepte la transmission que de paquets plus courts.
Un datagramme Internet peut tre spcifi "non fractionnable" Un tel datagramme Internet ne doit jamais
tre fragment quelques soient les circonstances. Si un datagramme Internet non fractionnable ne peut
tre achemin jusqu' sa destination sans tre fragment, alors il devra tre rejet.
La fragmentation, la transmission et le rassemblage travers un rseau local hors de vue d'un module
de protocole Internet est appele fragmentation Intranet .
Guillaume Desgeorge

12

Les procdures de fragmentation et rassemblage Internet doivent pouvoir "casser" un datagramme


Internet en un nombre de "fragments" arbitraire et quelconque pourvu que le rassemblage soit possible.
Le rcepteur des fragments utilise le champ d'identification pour s'assurer que des fragments de
plusieurs datagrammes ne puissent tre mlangs. Le champ "Fragment Offset" indique au rcepteur la
position du fragment reu dans le datagramme original. Les champs "Fragment Offset" et "Longueur
Totale" dterminent la portion du datagramme original que reprsente le fragment. L'indicateur bit
"Dernier Fragment" indique (lors de sa remise zro) au rcepteur qu'il s'agit du dernier fragment. Ces
champs vhiculent suffisamment d'information pour rassembler les datagrammes.
Le champ d'identification sert distinguer les fragments d'un datagramme de ceux d'un autre
datagramme. Le module Internet metteur d'un datagramme Internet initialise le champ d'identification
une valeur qui doit tre unique pour cette paire source-destination et pour ce protocole pendant toute la
dure de transmission de ce datagramme. Le module Internet terminant l'mission d'un datagramme met
le bit "Dernier Fragment" et le champ "Fragment Offset" zro.
Pour fragmenter un long datagramme, un module Internet (par exemple, dans un routeur), cre deux
nouveaux datagrammes et copie le contenu des champs d'en-tte Internet originaux dans les deux
nouvel en-ttes. Les donnes du datagramme original sont divises en deux portions, la premire d'une
taille multiple de 8 octets (64 bit) (la taille de la seconde portion n'est donc pas ncessairement un
multiple de 8 octets). Nous appellerons le nombre de blocs de 8 octets dans la premire portion NBF (ou
Nombre de Blocs du Fragment). La premire portion de donnes est place dans le premier des deux
nouveaux datagramme, et le champ "Longueur Totale" est renseign avec la taille de ce datagramme.
Le bit "Dernier Fragment" est bascul 1. La seconde portion de donnes est place dans le second
des deux nouveaux datagrammes, et le champ "longueur totale" est renseign avec la taille du second
datagramme. Le bit "Dernier Fragment" est plac la mme valeur que celui du datagramme original. Le
champ "Fragment Offset" du second datagramme constitu est renseign avec la valeur du mme
champ du datagramme original plus NFB.
Cette procdure peut tre gnralise une fragmentation en n fragments, plutt que les deux dcrits cidessus.
Pour rassembler les fragments d'un datagramme Internet, un module Internet (par exemple dans un
hte destinataire) recombine les datagrammes dont les valeurs des quatre champs suivants sont
identiques : identification, source, destination, et protocole. La recombinaison est ralise en replaant
la portion de donne contenue dans chaque fragment dans un tampon la position relative indique par
le champ "Fragment Offset" lu dans l'en-tte correspondant. Le premier fragment sera donc plac en
dbut de tampon, et le dernier fragment rcupr aura le bit "Dernier Fragment" zro.

2. SPECIFICATION
2.1. Format d'en-tte Internet
Un rsum du contenu de l'en-tte Internet suit :
0

16
32 bits
LET
Type de service
Longueur totale
Identification
Flags
Fragment Offset
Dure de vie
Protocole
Checksum den-tte
Adresse source
Adresse destination
Option + Bourrage
Data

Ver.

Version : 4 bits

Guillaume Desgeorge

13

Le champ Version renseigne sur le format de l'en-tte Internet. Ce document dcrit le format de la
version 4 du protocole.
Longueur d'En-Tte : 4 bits
Le champ Longueur d'En-Tte (LET) code la longueur de l'en-tte Internet, l'unit tant le mots de 32
bits, et de ce fait, marque le dbut des donnes. Notez que ce champ ne peut prendre une valeur en
dessous de 5 pour tre valide.
Type de Service : 8 bits
Le Type de Service donne une indication sur la qualit de service souhaite, qui reste cependant un
paramtre "abstrait". Ce paramtre est utilis pour "guider" le choix des paramtres des services actuels
lorsqu'un datagramme transite dans un rseau particulier. Certains rseaux offrent un mcanisme de
priorit, traitant prfrentiellement un tel trafic par rapport un trafic moins prioritaire (en gnral en
acceptant seulement de vhiculer des paquets d'un niveau de priorit au dessus d'un certain seuil lors
d'une surcharge momentane). Principalement, le choix offert est une ngociation entre les trois
contraintes suivantes : faible retard, faible taux d'erreur, et haut dbit.
Bits 0-2 :
Priorit.
Bit 3 :
0 = Retard standard,
1 = Retard faible.
Bits 4 :
0 = Dbit standard,
1 = Haut dbit.
Bits 5 :
0 = Taux d'erreur standard
1 = Taux d'erreur faible.
Bit 6-7 :
Rserv.
Priorit

0
8 bits

Priorit
111 Network Control
110 Internetwork Control
101 CRITIC/ECP
100 Flash Override
011 Flash
010 Immediate
001 Priority
000 Routine
L'utilisation des indications en termes de retard, dbit, et qualit de transmission peut augmenter le
"cot" (d'un certain point de vue) du service. Dans la plupart des rseaux, de meilleures performances
pour l'un de ces paramtres s'obtient au prix d'une dgradation des performances pour un autre. A moins
Guillaume Desgeorge

14

d'une situation exceptionnelle, il sera prfrable de ne pas activer plus de deux optimisations sur les
trois.
Le "Type de Service" sert prciser le traitement effectu sur le datagramme pendant sa transmission
travers Internet. Des exemples d'association de ce code aux amliorations de service proposes par des
rseaux existants comme AUTODIN II, ARPANET, SATNET, et PRNET sont donnes dans la RFC 795
"Service Mappings" [8].
La priorit dite "Network Control" est stipule comme tant une priorit l'intrieur d'un seul rseau. Le
fait d'utiliser cette option instaure une priorit pour chaque section traverse. La priorit "Internetwork
Control" n'est gre que par les routeurs. Si l'utilisation de ces priorits ont une signification particulire
ou supplmentaire pour l'un des rseaux, il est de la responsabilit de ce dernier de lire et d'interprter
les prsentes informations.
Longueur Totale : 16 bits
Le champ "Longueur Totale" est la longueur du datagramme entier y compris en-tte et donnes,
mesure en octets. Ce champ ne permet de coder qu'une longueur de datagramme d'au plus 65,535
octets. Une telle longueur rendrait de toutes faon les datagrammes impossible grer pour la plus
grande partie des rseaux. Les htes devront au moins pouvoir accepter des datagrammes d'une
longueur jusqu' 576 octets (qu'il s'agisse d'un datagramme unique ou d'un fragment). Il est de mme
recommand que des htes ne dcident d'envoyer des datagrammes de plus de 576 octets que dans la
mesure o ils sont srs que la destination est capable de les accepter.
Le nombre 576 a t choisi pour permettre un bloc de donnes de taille raisonnable d'tre transmis
dans un datagramme, tenant compte des donnes ajouter pour constituer les en-ttes de protocole.
Par exemple, cette taille permet la transmission d'un bloc de 512 octets, plus 64 octets d'en-tte dans
un datagramme unique. (NdT : je rappelle ici que la taille de 512 octets correspond un secteur sur la
plupart des supports de stockage) La taille maximale d'un en-tte Internet tant de 60 octets, et sa taille
typique tant de 20 octets, ce nombre permet de conserver une bonne marge pour les donnes
protocolaires de plus haut niveau.
Identification : 16 bits
Une valeur d'identification assigne par l'metteur pour identifier les fragments d'un mme datagramme.
Flags : 3 bits
Divers commutateurs de contrle.
Bit 0 : rserv, doit tre laiss zro
Bit 1: (AF)
0 = Fragmentation possible,
1 = Non fractionnable.
Bit 2: (DF)
0 = Dernier fragment,
1 = Fragment intermdiaire.
0

AF

DF

Fragment Offset : 13 bits


Ce champ indique le dcalage du premier octet du fragment par rapport au datagramme complet. Cette
position relative est mesure en blocs de 8 octets (64 bits). Le dcalage du premier fragment vaut zro.
Dure de vie : 8 bits
Ce champ permet de limiter le temps pendant lequel un datagramme reste dans le rseau. Si ce champ
prend la valeur zro, le datagramme doit tre dtruit. Ce champ est modifi pendant le traitement de l'entte Internet. La dure de vie est mesure en secondes. Chaque module Internet doit retirer au moins
une unit de temps ce champ, mme si le traitement complet du datagramme par le module est
Guillaume Desgeorge

15

effectu en moins d'une seconde. De ce fait, cette dure de vie doit tre interprte comme la limite
absolue maximale de temps pendant lequel un datagramme peut exister. Ce mcanisme est motiv par
la ncessit de dtruire les datagrammes qui n'ont pu tre achemins, en limitant la dure de vie mme
du datagramme.
Protocole : 8 bits
Ce champ indique quel protocole de niveau suprieur est utilis dans la section donnes du datagramme
Internet. Les diffrentes valeurs admises pour divers protocoles sont liste dans la RFC "Assigned
Numbers" [rfc1060].

Checksum d'en-tte : 16 bits


Un Checksum calcul sur l'en-tte uniquement. Comme certains champs de l'en-tte sont modifis (ex.,
dure de vie) pendant leur transit travers le rseau, ce Checksum doit tre recalcul et vrifi en
chaque point du rseau o l'en-tte est rinterprte.
L'algorithme utilis pour le Checksum est le suivant :
On calcule le complment un sur 16 bits de la somme des complments un de tous les octets de
l'en-tte pris par paires (mots de 16 bits). Lorsque l'on calcule le Checksum, on considre une en-tte
dont le champ rserv pour ce mme Checksum vaut zro.
L'algorithme de Checksum peut paratre lmentaire mais l'exprimentation a montr que cette
technique tait suffisante. Il se peut que cet algorithme soit plus tard remplac par un calcul de type
CRC, suivant la ncessit future.
Adresse source : 32 bits
L'adresse Internet de la source.
Adresse destination : 32 bits
L'adresse Internet du destinataire.
Options : variable
Les datagrammes peuvent contenir des options. Celles-ci doivent tre implmentes par tous les
modules IP (htes et routeurs). Le caractre "optionnel" concerne leur transmission, et non leur
implmentation.
Dans certains environnements, l'option de scurit peut tre obligatoire dans tous les datagrammes.
Le champ d'option est de longueur variable. Un datagramme peut comporter zro ou plus options. Voici
les deux formats possibles d'une option :
Cas 1: Une option code sur un seul octet.
Cas 2: Un octet codant le type d'option, un octet donnant la taille de l'option, les octets de donnes
d'option.
La taille de l'option compte tous les octets de l'option y compris le type, son propre octet et tous les
octets de donne d'option.
L'octet de type d'option est compos de trois champs de bits :
1 bit
indicateur de recopie
2 bits
classe d'option
5 bits
numro d'option.

Guillaume Desgeorge

16

III. UDP : USER DATAGRAM PROTOCOL


Introduction
Le protocole User Datagram Protocol (UDP) est dfini dans le but de fournir une communication par
paquet unique entre deux processus dans un environnement rseau tendu. Ce protocole suppose
l'utilisation du protocole IP comme support de base la communication.
Ce protocole dfinit une procdure permettant une application d'envoyer un message court une autre
application, selon un mcanisme minimaliste. Ce protocole est transactionnel, et ne garantit ni la
dlivrance du message, ni son ventuelle duplication. Les applications ncessitant une transmission
fiabilise et ordonne d'un flux de donnes implmenteront de prfrence le protocole TCP (Transmission
Control Protocol) .
Format :
0

32 bits
Port source
Longueur
Donnes

Port destinataire
Checksum

En-tte UDP
Champs
Le Port Source est un champ optionnel. Lorsqu'il est significatif, il indique le numro de port du
processus metteur, et l'on supposera, en l'absence d'informations complmentaires, que toute rponse
devra y tre dirige. S'il n'est pas utilis, ce champ conservera une valeur 0.
Le Port Destinataire a une signification dans le cadre d'adresses Internet particulires.
La Longueur compte le nombre d'octets dans le datagramme entier y compris le prsent en-tte. (Et par
consquent la longueur minimale mentionne dans ce champ vaut huit, si le datagramme ne transporte
aucune donne).
Le Checksum se calcule en prenant le complment un de la somme sur 16 bits des complments
un calcul sur un pseudo en-tte constitu de l'information typique d'une en-tte IP, l'en-tte UDP ellemme, et les donnes, le tout additionn d'un octet nul ventuel afin que le nombre total d'octets soit
pair.
La pr en-tte ajoute avant l'en-tte UDP contient l'adresse IP source, l'adresse IP destinataire, le code
de protocole, et la longueur du segment UDP. Cette informationpermet d'augmenter l'immunit du rseau
aux erreurs de routage de datagrammes. La procdure de calcul du Checksum est la mme que pour
TCP.
Si le calcul du checksum vaut zro, il sera transmis tous ses bits un (le complment un). UN
Checksum transmis avec une valeur zro a effectivement une signification particulire. Dans ce cas, le
segment indique qu'aucun Checksum n'a t calcul (pour des besoins de mise au point ou pour des
protocoles de niveaux suprieurs qui rendent cette vrification inutile).
Interface Utilisateur
L'interface utilisateur doit permettre l'ouverture de nouveaux ports de rception, la rception des donnes
et leur transmission ainsi que celle de l'adresse source l'application sur le port de rception mis en
place, et doit mettre en place une commande permettant l'mission d'un datagramme, par laquelle
seront spcifis les donnes, l'adresse et ports source et destination utiliser.

Guillaume Desgeorge

17

Interface IP
Le module UDP doit extraire les adresses source et destination de l'en-tte IP, et vrifier le numro de
protocole. Une interface UDP/IP plausible pourrait retourner le datagrammeentier y compris l'en-tte
Internet en rponse du datagramme reu. Une interface devra pour cela permettre UDP de passer un
datagramme Internet complet avec une en-tte IP la couche IP elle mme pour mission. IP n'aura
plus qu' vrifier la cohrence des champs d'en-tte IP prpars par UDP et calculer le Checksum.
Applications du Protocole
Ce protocole sera utilis principalement pour les communications avec les serveurs de noms de
domaines , et dans les transactions utilisant le protocole Trivial File Transfer.
Numro de protocole
Ce protocole porte le numro 17 (21 en octal) lorsqu'il est transport par le Protocole Internet. D'autres
numros de protocoles pour d'autres couches support sont donnes dans la rfrence .

IV. ICMP : INTERNET CONTROL MESSAGE PROTOCOL


Introduction
Le Protocole Internet (IP) est utilis pour la transmission de datagrammes de hte hte l'intrieur
d'un systme de rseaux interconnects appel Catenet .
Les appareils raccordant les rseaux entre eux sont appels des Routeurs. Ces routeurs communiquent
entre eux en utilisant le protocole Routeur Routeur (GGP) afin d'changer des informations de contrle
et de gestion du rseau. Occasionnellement, un routeur ou un hte destinataire peut avoir
communiquer vers l'metteur du datagramme, par exemple, pour signaler une erreur de traitement du
datagramme. C'est dans cette perspective qu'a t mis en place le protocole Internet Control Message
Protocol (ICMP). Il s'appuie sur le support de base fourni par IP comme s'il s'agissait d'un protocole d'une
couche suprieure. ICMP n'en reste pas moins une partie intgrante du protocole IP, et doit de ce fait
tre implment dans chaque module IP.
Les messages ICMP sont envoys dans diverses situations: par exemple, lorsqu'un datagramme ne peut
pas atteindre sa destination, lorsque le routeur manque de rserve de mmoire pour retransmettre
correctement le datagramme, ou lorsque le routeur dcode de viser l'hte destinataire via une route
alternative pour optimiser le trafic.
Le protocole Internet n'est pas, dans sa dfinition, absolument fiable. Le but de ces messages de
contrle est de pouvoir signaler l'apparition d'un cas d'erreur dans l'environnement IP, pas de rendre IP
fiable. Aucune garantie que le datagramme soit achemin ni qu'un message de contrle soit retourn, de
peut tre donne.
Certains datagrammes pourront se perdre dans le rseau sans qu'aucun message de contrle ne le
signale. Les protocoles de niveau suprieur s'appuyant sur une couche IP devront implmenter leurs
propres mcanismes de contrle d'erreur et de retransmission si leur objet ncessite un circuit de
communication scuris.
Les messages ICMP reportent principalement des erreurs concernant le traitement d'un datagramme
dans un module IP. Pour viter de ne pas entrer dans un cercle vicieux de rmission de message de
contrle en rponse un autre message de contrle et ce sans fin, aucun message ICMP ne sera
rmis en rponse un message ICMP. De mme les messages ICMP ne seront transmis qu'en
rponse un traitement erron du fragment zro dans le cas d'un datagramme fragment. (Le fragment
zro est celui dont l'offset vaut zro).

Guillaume Desgeorge

18

Formats de message
Les messages ICMP sont mis en utilisant l'en-tte IP de base. Le premier octet de la section de
donnes du datagramme est le champ de type ICMP; Sa valeur dtermine le format du reste des
donnes dans le datagramme ICMP.

En-tte ICMP
Type

Code
Identifiant

Checksum
Numro de squence

Masque dadresse
16

32bits

Rsum des types de Message (champ Type)


0 Rponse Echo
3 Destination non accessible
4 Contrle de flux
5 Redirection
8 Echo
11 Dure de vie coule
12 Erreur de Paramtre
13 Marqueur temporelle
14 Rponse marqueur temporel
15 Demande d'information
Rponse demande d'information
Champ Identifiant : un identifiant pour aider qualifier les rponses/requtes (souvent zro)
Champ Numro de squence : un numro de squence pour aider qualifier les rponses/requtes (
zro)

V. SNMP : Simple Network Management Protocol


1.Introduction
Le protocole SNMP est le langage que les agents et les stations de gestion (managers) utilisent pour
communiquer. Cest un protocole de type question/rponse asynchrone. Ce protocole est situ au niveau
application du modle OSI, cest lui qui dfinit la structure formelle des communications. SNMP est
encapsul dans des trames UDP.
La MIB (Management Information Base) regroupe lensemble des variables relatives aux matriels et aux
logiciels supports par le rseau, et dfinit les objets de gestion dans lenvironnement TCP/IP.
La SMI (Structure of Management Information), dfinit comment sont reprsentes , dans la MIB, les
informations relatives aux objets de gestion et comment sont obtenues ces informations.
Les stations interrogent donc les agents pour observer leur fonctionnement et leur envoient des
commandes pour leur faire excuter certaines taches. Les agents renvoient les informations requises
aux stations de gestion. Certains vnements du rseau, tels que des erreurs de transmission, peuvent
dclencher des alarmes envoyes aux stations de gestion. Cependant, lenvoi de messages de faon
spontane de lagent vers le manager est limit. Les managers effectuent une interrogation priodique
des agents de manire vrifier leur tat. La structure des paquets est dfinie en utilisant la syntaxe
ASN1 (Abstract Syntax Notation).

Guillaume Desgeorge

19

SNMP a lavantage dtre simple, cependant il a des capacits trs limits au niveau scurit,
principalement pour lauthentification. Tous les systmes SNMP doivent galement supporter les
protocoles DUPER et IP pour transporter les donnes entre les agents et les stations de gestion.
2.Spcifications
Le format de la trame SNMP est dcrit ci-dessous :

Version

Communaut

PDU

Champs
Version : numro de version SNMP. Le manager et lagent doivent utiliser le mme numro.
Communaut : ce champ sert identifier auprs du manager lagent avant de lui accorder un accs.
PDU : il y a 5 types de PDU : GetRequest, GetNextRequest, GetResponse, SetRequest, et TRAP.
Une description de ces PDU est donnes ensuite.
Un premier format est utilis pour les PDU du genre GET, ou SET :
Type de PDU

ID de requte

Statut derreur

Index derreur

Obj 1, val 1

Champs
Type de PDU :

0:
1:
2:
3:

GetRequest
GetNextRequest
GetResponse
SetRequest

ID de requte : champ qui coordonne la requte du manager et la rponse de lagent.


Statut derreur : entier qui indique une opration normale (cas 0) ou bien une erreur( cas 0)
Index derreur : identifie les entes avec la liste des variables qui ont caus lerreur.
Obj/Val : association du nom de la variable transmettre avec sa valeur.
Un second format est utilis pour la TRAP PDU :
Type de PDU

Entreprise

Adresse
Agent

Type
Generique

Type
Specifique

Timestamp

Obj 1, val 1

Champs
Type de PDU : dans ce cas toujours gal 4.
Entreprise : identifie lentreprise de management qui a dfini la Trap .
Adresse Agent : adresse IP de lagent.
Type Gnrique : dcrit quel type de problme est survenu. (7 valeurs sont possibles).
Type Spcifique : est utilis afin didentifier une TRAP spcifique une entreprise.

Guillaume Desgeorge

20

Timestamp : contient la valeur de lobjet sysUptime reprsentant le temps coul depuis la dernire
initialisation..
Obj/Val : association du nom de la variable transmettre avec sa valeur.

VI. ARP : ADDRESS RESOLUTION PROTOCOL


1.Introduction
Les adresses IP sont attribues indpendamment des adresses matrielles des machines. Pour envoyer
un datagramme dans linternet, le logiciel rseau doit convertir ladresse IP en une adresse physique qui
est utilise pour transmettre la trame. Si ladresse physique est un entier court, elle peut tre facilement
modifie pour lui faire correspondre ladresse machine IP. Sinon, la traduction doit tre effectue
dynamiquement.
Cest le protocole ARP qui effectue cette traduction en sappuyant sur le rseau physique. ARP permet
aux machines de rsoudre les adresses sans utiliser de table statique. Une machine utilise ARP pour
dterminer ladresse physique destinataire en diffusant (broadcast), sur le sous rseau, une requte ARP
qui contient ladresse IP traduire. La machine possdant ladresse IP concerne rpond en renvoyant
son adresse physique. Pour redre ARP plus performant, chaque machine tient jour, en mmoire, une
table des adresses rsolues et rduit ainsi le nombre dmissions en mode broadcast.
2.Spcifications
La structure dune trame ARP est dfinie ci-dessous :
0
16
Type Hardware
Type de protocole
Hlen
Plen
Opration
Adresse hardware de lexpditeur
Adresse protocole de lexpditeur
Adresse hardware du destinataire
Adresse protocole du destinataire

32 bits

Champs
Type Hardware : spcifie le type de linterface hardware
Type de protocole : spcifie le type du protocole de haut niveau mis par lexpditeur
Hlen : longueur de ladresse hardware
Plen : longueur de ladresse de haut niveau
Opration : type de lopration effectue :
Requte ARP
Rponse ARP
Requte RARP
Rponse RARP
Requte RARP dynamique
Rponse RARP dynamique
Erreur RARP dynamique
Requte InARP
Rponse InARP
Adresse hardware de lexpditeur : explicite
Adresse protocole de lexpditeur : explicite
Guillaume Desgeorge

21

Adresse hardware du destinataire : explicite


Adresse protocole du destinataire : explicite

Guillaume Desgeorge

22

VII. RIP2 : ROUTING INFORMATION PROTOCOL 2


1.Introduction
RIP2 est utilis pour changer des informations de routage. Il drive dun premier protocole dvelopp par
Xerox (RIP). Chaque machine qui utilise un protocole RIP2 a un processus qui envoie et reoit des
datagrammes transports par de lUDP port numro 520.
La structure des trames RIP2 est dcrite ci-dessous :
0
Commande
Version
Identifiant de la famille dadresses
Adresse IP
Masque de sous rseau
Saut suivant
Mtrique

16
Inutilis
Route tag

32 bits

Commande : utilis pour dfinir le sujet du datagramme


Requte
Rponse
Rserv (Utilis par Sun microsystems)
Version : numro de la version RIP.
Identifiant de la famille dadresses : indique quel type dadresse est utilis cela car RIP2 peut
transporter dautres informations de routage.
Route tag : (utilis par RIP2 ; 0 pour RIP) attribue une route qui doit tre prserve par une route. Ce
champ permet de sparer les routes RIP internes des routes externes qui ont pu tre importe dun EGP
ou dun autre IGP.
Adresse IP : adresse IP de la destination.
Masque de sous-rseau : (utilis par RIP2; 0 pour RIP) masque du sous rseau destination.
Saut suivant: adresse IP laquelle les paquets devront tre envoy au prochain saut.
Mtrique : reprsente le cot total de la source la destination (en nombre de sauts).

Guillaume Desgeorge

23

LE PROTOCOLE X25
Introduction
Le protocole X25 dfinit l'interface entre un ETTD ( Equipement Terminal de Traitement des Donnes ) et
un ETCD ( Equipement Terminal de Circuit de Donnes ). Il a t adopt par le CCITT en septembre
1976. On entend souvent par X25 l'ensemble des protocoles lis X25 et qui couvre les couches 1 3
du modle OSI. Pourtant, le terme X25 dsigne uniquement le niveau 3 ou niveau paquet transport entre
les champs d'information des trames LAPB.

I. LAPB
Le protocole LAPB est le protocole de niveau 2 qui transporte les paquets X25. Le format standard d'une
trame LAPB est le suivant:
Flag

Champ adresse

Champ de contrle

Donnes

FCS

Flag

Flag: Toujours 0x7E

Address Field: Ce champ n'a aucune raison d'tre quand on travaille de point point. Cet octet est
rserv plusieurs utilisations. Il sert sparer les commandes des rponses et peut seulement prendre
les valeur 0x01 et 0x03. 01 dsigne une commande de l'ETTD l'ETCD et 03 contient une rponse de
l'ETCD l'ETTD.
Champ de contrle: Identifie le type de trame. En plus, il inclut la squence de nombre, les fonctions de
contrles et le traquage des erreurs en fonction du type de trame.

FCS: Frame Check Sequence.

Type de trame:
Trame de supervision:
RR
: Prt recevoir.
REJ
: Demande de retransmission.
RNR
: Pas prt recevoir.
Trames non squentielles:
DISC : Demande de dconnexion.
UA
: Trame d'acquitement.
DM
: Rponse DISC, mode dconnexion.
FRMR: Rejet de trame.
SABM: Mode asynchrone, pas de matre et d'esclave.
Trame d'information:
INFO
Guillaume Desgeorge

24

Guillaume Desgeorge

25

II. X25
La structure du paquet de donnes X25 est la suivante:
8
7
6
5
4
3
2
Q
D
0
1
Numro de groupe de voie logique
Numro de voie logique
P(R)
M
P(S)
O

Donnes

GFI: Identifiant de format gnral. Q indique un paquet X25 (0) ou X29 (1). D indique un acquittement
local (0 : ETCD) ou distant (1 : ETTD). Les bits 01 indiquent que les numros de trames vont de 0 7.
Le format de trame o ils indiquent 10 montre que l'on numrote les trames de 0 127 (10). Cela permet
d'envoyer beaucoup de trame avant d'acquitter ce qui est intressant pour les rseaux lents tels que les
rseaux sattelites.

Type de paquet:
P(R)
: Nombre des paquets reus.
P(S)
: Nombre de paquets envoys.
M
: Seulement dans les paquets de donnes. Ce champ indique, lorsqu'il est 1, que le paquet fait
partie d'un ensemble de paquets traiter comme un tout.
Les paquets peuvent tre de diffrents types:
CALL ACC
: Appel accept.
CALL REQ
: Demande d'appel.
CLR CNF
: Confirmation d'effacement.
CLR REQ
: Demande d'effacement.
DATA
: Paquet de donnes
DIAG
: Diagnostique.
INF CNF
: Confirmation d'interruption.
INT REQ
: Demande d'interruption.
REJ
: Rejet.
RES CNF
: Confirmation de remise zro.
RES REQ
: Demande de remise zro.
RNR
: Non prt recevoir.
RR
: Prt recevoir.
RSTR CNF
: Confirmation pour recommencer.
RSTR REQ
: Demande qu'on recommence.
REG REQ
: Demande de registration.
REG CNF
: Confirmation de registration.

Guillaume Desgeorge

26

III. HDLC
Flag

Adresse

Champ de contle

Donnes

FCS

Flag

Flag: Toujours 0x7E

Champ de contrle: Indique le type de trame auquel on a affaire. Les diffrents types de trames
comprennent les mme types de trames que pour le protocole LAPB plus d'autres numres ci-aprs:
Trame de supervision:
SREJ : Demande de retransmission d'une trame.
Trames non squentielles:
SARM : Mode de rponse asynchrone. Demi-relation matre/esclave.
REST : Remise zro du nombre de trame.
CMDR : Commande rejete.
SNRM : Mode de rponse normal. Relation matre/esclave.
RD
: Requete dconnecte.
RIM
: Deuxime demande d'initialisation aprs dconnection.
SIM
: Mode d'initialisation.
UP
: Election non squentielle.
UI
: Information non squentielle.
XID
: Commande d'change d'identification.

Guillaume Desgeorge

27

RNIS : RESEAU NUMERIQUE


A INTEGRATION DE SERVICES
1.Architecture
Les services de transmission de donnes se sont dvelopps, depuis le dbut des annes 70, sur le
principe des rseaux spcialiss : un usage correspondait un rseau spcifique. Lutilisateur qui avait
besoin de communiquer avec chacun de ces rseaux tait donc oblig davoir autant de raccordements
que de rseaux ou dapplications atteindre.
Cette multitude de raccordements diffrents et indpendants ntait optimale ni du point de vue de
lutilisateur ni point de vue de lexploitant Tlcom ; de cette constattation est n le concept dintgration
de services.
Ce rseau sappuie sur le concept RNIS (Rseau Numrique Intgration de Services) ou ISDN
(Integrated Services Digital Network). Le RNIS propose lintgration des supports et des services et, pour
cela, il sappuie sur la numrisation et se dveloppe au sein dune structure puissante de normes
internationales.
Le RNIS est une volution du rseau tlphonique actuel. Il propose la continuit numrique de bout en
bout. Ce nest pas un rseau supplmentaire entrant en concurrence avec les rseaux existants comme
le tlphonique traditionnel, les rseaux X.25 ou les liaisons spcialises. Cest plutt un accs
universel ces rseaux ou plus exactement ces services supports.
En jouant sur son sigle , le RNIS apparat comme un moyen de communication rapide, normalis,
intelligent et souple :
rapide, car laccs de base 144 Kbit/s comporte 2 voies 64 Kbit/s et une voie 16 Kbit/s (2B+D).
Les canaux B permettent, par exemple, de tlphoner tout en envoyant une tlcopie rapide. Le canal D,
pour sa part, convoie les signaux servant ltablissement de la communication et toutes les
informations de service ; il peut aussi transporter des informations bas dbit. Il existe des accs
primaires qui comportent 30 canaux B et un canal D.
Normalis, car tous les lments daccs au RNIS sont spcifis par des normes internationales :
mme canal de base, mme canal D, mme cablge et mme prise (RJ 45) servent pour tous.
Intelligent, car les centraux sont capables de grer une signalisation bien plus riche que celle du
tlphone classique. Cette possibilit offre un grand nombre de services complmentaires comme, par
exemple, lidentification de lappelant ou la possibilit de transfert dappel. Par ailleurs, il existe un
contact permanent entre labonn et le rseau ; par exemple, si un abonn occupe ses 2 canaux B avec
une communication tlphonique et un transfert de donnes, le rseau pourra, grce au canal D, avertir
lutilisateur quun autre correspondant cherche le joindre.
Souple et simple, car le RNIS a la vocation dhberger la grande majorit des services de communication
et fait un pas vers la transparence des rseaux avec son accs universel aux services de
tlcommunication.

2.Spcifications
Le LAPD (Link Access Protocol channel D) is un protocole de niveau 2 qui travaille avec
lAsynchronous Balanced Mode (ABM). Ce mode est compltement quilibr (ni maitre, ni esclave).
Chaque station peut intialiser, superviser et envoyer des trame tout moment.

Guillaume Desgeorge

28

Le format de la rame est dcrit ci-dessous :


Flag

Adresse

Contrle

Information

FCS

Flag

Champs :
Flag : Sa valeur est toujours (0x7E). De sorte ce que le flag ne soit pas dupliqu dans la trame on
utilise la technique du Bit Stuffing.
Adresse : Les 2 premiers octets de la trame aprs le champ flag sont les champs dadresse. Le format
de Adresse est le suivant :
1

8
SAPI
TEI

C/R

EA1
EA2

EA1 : premier bit dextension dadresse qui est toujours 0


C/R : bit Commande/Rponse. Les trames qui proviennent dun utilisateur avec ce bit 0 sont des
trames de commande
SAPI : Service Access Point Identifier.
Les valeurs sont :
procdure appel-contrle
mode communication de paquets utilisant la procdure dappel-contrle I.451
communication de paquets X.25 niveau 3
manager de procdures niveau 2
Contrle : identifie le type de trame avec un contrle sur la trame
FCS : Frame Check Sequence.
STRUCTURE DE LA TRAME RNIS

2
3
4
Discriminateur protocole
0
0
0
Flag
Valeur appel ref.
0
Type message
Autres lments requis

5
0

Longueur valeur appel ref.

Champs :
Discriminateur protocole : protocole utilis
Longueur valeur appel rfrence : dtermine la longueur du champ suivant. La rfrence dappel
peut tre dune longueur de 1 ou 2 octets qui dpend de la taille de la valeur code.
Flag : mis 0 pour les messages mis par le parti qui allou la valeur de lappel de rfrence ;
autrement mis 1.
Valeur appel ref : une valeur arbitraire est alloue pour la dure de la session, qui identifie lappel entre
la machine maintenant lappel et le switch RNIS

Guillaume Desgeorge

29

Type message : dfinit le premier sujet de la trame. Le type de message peut tre de 1 ou 2 octets.
Quand il y a plus dun octet, le premier octet ne contient que des 0.

LES PROTOCOLES NOVELL


1.Introduction
Lensemble des protocole Novell Netware a t grandement influence par le design et limplmentation
de larchitecture de protocoles du Xerox Network System (XNS). Il fournit un support comprhensible par
DOS, Windows, Macintosh, OS/2 et UNIX. De plus, Novell fournit un large support aux rseaux locaux et
aux communications asynchrones de large zone. Novell comprend les protocoles suivants :
IPX Internetwork Packet Exchange
RIPX Routing Information Protocol
BCAST Broadcast
DIAG Diagnostic Responder
SER Serialization
WDOG Watchdog
SPX Sequenced Packet Exchange
SAP Service Advertising Protocol
NovelNetBios
BMP Burst Mode Protocol
NCP Netware Core Protocol
NDS Netware Directory Services

I. IPX
1.Spcifications
IPX est limplmentation Novell du Internet Datagram Protocol (IDP) dvelopp par Xerox. IPX est un
protocole datagramme sans connexion qui transmet des paquets travers Internet et fournit aux stations
Netware et aux serveurs de fichiers des services dadressage et de routage inter rseaux.
La structure du paquet IPX est dcrite ci-dessous :
0
Checksum
Longueur du paquet
Contrle transport
Type paquet
Rseau destination (4 octets)
Nud destination (6 octets)
Socket destination
Rseau source (4 octets)
Nud source (6 octets)
Socket source
Donnes (contient des info. RIP, SAP,SPX.)

15 bits

Champs
Checksum : mis FFFFH
Longueur du paquet : longueur du datagramme IPX en octets
Control transport : utilis par les routeurs Netware. Mis zro avant une transmission de paquet

Guillaume Desgeorge

30

Type de paquet : spcifie linformation contenue dans le paquet


Hello ou SAP
RIP
Paquet ECHO
Paquet erreur
Netware 386 ou SAP
Protocole de squencement de paquets
16/31 Protocoles exprimentaux
Netware 286
Numro de rseau : nombre sur 32 bits dtermin par ladministrateur rseau. 0 en local
Numro de nud : nombre sur 48 bits qui identifie ladresse hardware LAN. Si ce nombre est FFFF
FFFF FFFF FFFF cest un broadcast.
Numro socket : nombre sur 16 bit qui identifie la paquet de haut niveau
0451H
NCP
0452H
SAP
0453H
RIP
0455H
Netbios
0456H
diagnostique
0457H
Paquet de serialisatin (SER)
4000-6000H
Sockets phmres utilises pour les communications des serveurs de fichiers et des
rseaux

II. RIPX
1.Spcifications
RIPX est utilis pour collecter, maintenir et changer des informations de routage correctes entre les
passerelles dans Internet. Il ne faut pas confondre ce protocole avec celui de la famille TCP/IP ! !
La description du paquet est donne ci-dessous :
15
Opration
Numro rseau
Nombre de sauts
Nombre de ticks
.
.
.
.
.
Champs :
Opration : Spcifie le type dopration
Requte RIP
Rponse RIP
Numro rseau : adresse sur 32 bits du rseau spcifi
Nombre de sauts : nombre de routeurs jusquau rseau spcifi
Nombre de ticks : mesure de temps ncessaire pour atteindre le rseau spcifi (18,21 ticks/seconde)

Guillaume Desgeorge

31

III. BCAST
Spcifications
BCAST sert diffuser les annonces du rseau informant lutilisateur quil a bien reu un message.
La description de la trame est explique ci-dessous :
0
Numro de connexion
Signature

15 bits

Champs :

Numro de connexion : communiqu la station durant le processus de login

Signature : la valeur est 0x21 (caractre ASCII) qui signifie broadcast message waiting.

IV. DIAG
DIAG est trs utilis pour analyser les LAN Netware. DIAG peut tre utilis pour tester les connexions et
les configurations.
La structure des paquets est dcrite ci-dessous :
Compteur dexclusion dadresse (1 octet)
Exclusion dadresse 0 (6 octets)
.
.
.
.
Exclusion dadresse 79 (6 octets)
Paquet de requte DIAG
Champs :
Compteur dexclusion dadresse : le nombre de stations qui on demande de ne pas rpondre. 0
dans ce champ signifie que lon demande toutes les stations de rpondre.
0
16 bits
Major version
Minor version
SPX diagnostic socket
Component count
Component Type 0 (longueur de la variable)
Paquet de rponse DIAG
Champs :
Major/Minor version : version du diagnostique install dans la station qui rpond
SPX diagnostic socket : le numro de socket auquel tous les diagnostiques rponses SPX peuvent
tre adresss
Component count : nombre de composants trouvs dans le paquet rponse
Guillaume Desgeorge

32

Component Type : contient des informations propos dun des composants ou processus actif au
nud rpondant.
Simple :
0= IPX/SPX
1= drivers de routeurs
2= drivers de LANs
3= Shells
4= VAPs
Etendu :
5= Routeur
6= Serveur de fichiers/routeur
7= IPX/SPX non ddis
Chaque champ tendu est suivi de champs additionnels :
Nombre de rseaux locaux (1 octet)
Champ spcifique :
Nombre de rseaux locaux :
communiquer.

nombre de rseaux locaux avec lesquels le composant peut

Pour chaque rseau local il y aura en plus :


Type du rseau local (1 octet)
Adresse rseau (4 octets)
Adresse nud (6 octets)
Type du rseau local : contient un nombre indiquant le type de rseau local avec
communiquer le composant

lequel

va

Adresse rseau : contient ladresse sur 4 bits du rseau dfinit dans le cham prcdent
Adresse nud : contient ladresse sur 6 bits du nud qui accompagne ladresse rseau

V. SER
Pour assurer quune simple version de Netware nest pas en train dtre charge sur diffrents serveurs,
lOS diffuse des paquets appels paquets de srialisation pour dterminer si il y a multiple copies du
mme OS sur le rseau.
Ces paquets ne contiennent quun seul champ de 6 octets appel champ de donne de srialisation.

VI. WDOG
Spcifications
Le WDOG fournit les validations de connexion aux stations sur le systme Netware et rend compte
lOS lorsque une connexion doit tre ferme pour cause de trop longue priode sans communications.
La description de la trame est donne ci-dessous :
Numro de connexion

Signature

16bits
Champs
Numro de connexion : donn la station durant le login
Signature : contient un caractre 0x3F ou 0x59
Guillaume Desgeorge

33

VII. SPX
SPx est la version Novell du Sequenced Packet Protocol de Xerox (SPP). Cest un protocol situ au
niveau de la couche liaison et il permet une distribution des paquet des applications tierces.
La description du paquet SPX est faite ci-dessous :
16bits
Flag contrle connexion
ID source connexion
ID destinataire connexion
Numro de squence
Numro acquittement
Numro allocation
0-534 octets de donnes

Type flux donnes

Champs
Flag contrle connexion : 4 flags qui contrlent le fux bidirectionnel travers une connexion SPX. Lz
valeur est 1 pour un bit mis, 0 sinon.
Bit 4 Eom :end of message
Bit 5 Att : pas utilis par SPX
Bit 6 Ack : pas utilis
Bit 7 Sys : contrle de transport
Type flux donnes : spcifie la donne
0-253 ignor par SPX
Fin de connexion
Ack de fin de connexion
ID source connexion : nombre sur 16 bits assign par SPX pour identifier la connexion
ID destination connexion : le nombre de rfrence utilis pour identifier la destination du transport
Numro de squence : nombre de 16 bits contrl par SPX qui indique le nombre de paquets transmis
Numro dacquittement : nombre sur 16 bits qui indique le prochain paquet
Numro dallocation : nombre sur 16 bits qui indique le nombre de paquets envoys mais pas encore
acquitts.

VIII. SAP
Spcifications
Avant quun client ne puisse communiquer avec un serveur, il doit savoir quels serveur sont disponibles
sur le rseau. Cette information est rendue disponible grce au Novells Service Advertsing Protocol
(SAP). Le service SAP diffuse linformation sur la liste des serveurs connu travers tout le rseau.Ces
serveurs peuvent comprendre des serveurs de fichiers, des serveurs dimpression, des serveurs daccs
Netware, et des serveurs distants.
Le format de la trame SAP de rponse est dcrite ci-dessous :
Opration (2octets)
Type service (2 octets)
Nom serveur (48 octets)
Adresse rseau (4 octets)
Adresse nud (6 octets)
Adresse socket (2 octets)
Guillaume Desgeorge

34

Sauts (2 octets)
.
Le paquet SAP peut contenir linformation de 7 serveurs.
Champs
Opration : spcifie lopration que le paquet va effectuer :
1
Requte de service gnral
2
Rponse de service gnral
3
Requte du service le plus proche
4
Rponse du service le plus proche
Type service : spcifie le service excut :
01H
Utilisateur
04H
Service de fichiers
07H
service dimpression
21H
passerelle NAS SAN
23H
NACS
27H
passerelle TCP/IP
98H
serveur daccs Netware
107H Netware386 STOREXP Spec.
137H Netware 386 queue dimpression
H signifie hexadcimal.
Nom serveur : contient sur 48 octets le nom du serveur
Adresse rseau : numro du serveur de rseau sur 32 bits
Adresse nud : numro du serveur de nuds sur48 bits
Adresse socket : numro de serveur de socket sur 16 bits
Sauts : nombre de routeurs par lesquels sont passs les paquets pour atteindre le rseau spcifi.
Opration (2 octets)
Type service (2 octets)
Format du paquet de requte SAP

IX. NovelNetBios
Spcifications
Cest un protocole propritaire dvelopp par Novell bas sur NetBios.
Le champ type de flot de donnes est constitu dun octet. Les autres champ sont de taille variable.
Exemples pour loctet type de flot de donnes :
Trouve nom
Nom reconnu
Vrifie nom
Nom utilis
De-register nom
Session donnes
Session fin
Session fin ack
Statut requte
Statut rponse
Datagram direct
Guillaume Desgeorge

35

X. BMP (Burst)
Spcifications
Le BMP est en fait un type de paquet NCP ( Request type=7777H). BMP a t cr afin de permettre de
multiple rponses pour une seule requte et donc transfrer jusqu 64 ko de donnes pour une seule
requte en lecture de fichiers.
Le format de la trame BMP est donn ci-desous :
16
24
32 bits
Type requte
Flag type flot
Type flot
ID source connexion
ID destinataire connexion
Numro de squence du paquet
temps dlais
Numro de squence burst
Numro dACK de squence
Longueur totale du burst
Offset total du burst
Longueur du paquet
Nombre des entres de liste
Fragment manquant de la liste
Code fonction
Handle de fichier
Offset de dbut
Octets crire
Champs
Type requte : Identique type requ^te dans NCP et toujours positionn 7777H (mode paquets burst)
Flags type flot : flags disponibles
Type flot : contrle du mode Burst
ID source connexion : numro dID assign la station source
ID detinataire connexion : numro dID assign la station destination
Numro de squence du paquet : utilis par la station et les serveurs de fichiers pour identifier les
paquets envoys et reus
Temps de dlais : dlais entre 2 paquets
Numro de squence burst : numro de la squence en cours de transmission
Numro de squence ACK : numro de la prochaine squence burst accepte
Longueur totale burst : loongueur de la burst transmise (en octets)
Offset burst : position des donns dans le burst
Longueur paquet : longueur des donnes burst (en octets)
Nombre dentres de liste : nombre dlments dans la liste des fragments manquant

Guillaume Desgeorge

36

Liste des fragments manquants : fragment de donnes encore non reues


Code fonction : fontion lire ou crire
Offset dbut : Offset du dbut criture (/lecture)

XI. NCP
Spcifications
Le Novell Netware Core Rotocol (NCP) soccupe de laccs ressources du serveur primaire Netware. Il
fait des appels de procdures au NFSP (Netware File Sharing Protocol) .
Le format du paquet NCP est dcrit ci-dessous :
Le type requte est sur 2 octets ; tous les autres sont sur un octet.
Type requte
Numro squence
Numro de connexion bas
Numro de task
Numro de connexion haut
Code requte
Donnes
En-tte du paquet requte
Champ
Type requte : identifie le type de paquet
1111H
Requte dallocation de slot
2222H
Requte de serveur de fichiers
3333H
Rponse de serveur de fichier
5555H
Requte de dsallocation de slot
7777H
Mode BMP
9999H
Ack positif
H signifie hexadcimal.
Numro de squence : numro utilis par la station et les serveurs de fichiers pour identifier les
paquets qui sont envoys et reus
Numro de connexion bas : ID de connexion bas associ la station.
Numro de task : identifie le systme dexploitation, DOS
Numro de connexion haut : ID de connexion haut associ la station. Utilis seulement sur la
version 1000-user de Netware, sur les autres versions il est zro
Code requte : identifie le code spcifique de la requte
A prsent voici le paquet de rponse NCP qui est le mme que celui de requte NCP except les deux
octets suivant loctet Numro de connexion haut. Ces deux octets sont dfinis ci-dessous :
Code completion
Statut connexion
Code completion : ce code indique si la requte du client a abouti ou pas. Une valeur de 0 indique une
russite.
Statut connexion : le 4eme bit sera mis un si le serveur doit tre arrt
Guillaume Desgeorge

37

Guillaume Desgeorge

38

IPV6
POURQUOI UNE NOUVELLE VERSION D'IP ?
IPng est une nouvelle version d' IP qui s'inscrit comme l'volution naturelle et normale du protocole IP en
place IPv4. Protocole IPv4 qui, tout en ayant permis l'norme croissance de l'Internet, souffre de
plusieurs faiblesses. IPng est conu pour fonctionner aussi bien sur des rseaux trs hauts dbits
comme ATM que sur des rseaux faible bande passante tels que les rseaux sans fils.
Nous allons voir que le dveloppement d' IPng, malgr les limitesd'IPv4, correspond aussi une rponse
des besoins croissants sur des nouveaux marchs en pleine expansion ainsi qu' un effort de
modernisation et d'volution de la technologie propose par l'Internet.
Les faiblesses du protocole IP actuel (IPv4)
Ds sa cration, IP a suscit de nombreuses discussions notamment sur la conception de l'en-tte
[RFC 791].
Le problme le plus connu concerne l'espace d'adressage. Les adresses IP sont actuellement stockes
sur 32 bits ce qui permet environ plus de quatre milliards d'adresses, taille largement suffisante l'origine
lorsque le modle dominant tait celui d'un ordinateur par campus ou centre de recherche. Aujourd'hui,
l'informatique industrielle et commerciale ainsi que celle des particuliers rendent ce nombre trop faible,
d'autant que de nombreuses adresses sont "gaspille" par le mcanisme d'allocation hirarchique. En
outre, la gnralisation des machines connectes en rseau("toasternet problem" ou "paradigm shift")
risque d'aggraver ce problme.
La description de l'en-tte IPv4 nous permet de mieux apprhender les limites du protocole actuel.

(chaque ligne du tableau reprsente 32 bits)


IHL : Internet Header Length,
Fragment
Offset
:
la
place
du
fragment,
Padding : le bourrage.
Un autre problme est celui pos par l'explosion de la taille des tables de routage dans l'Internet. Le
routage, dans un trs grand rseau, doit tre hirarchique avec une profondeur d'autant plus importante
que le rseau est grand. Le routage IP n'esthirarchique qu' trois niveaux : rseau, sous-rseau et
machine. Les routeurs des grands rseaux d'interconnexion doivent possder une entre dans leurs
tables pour tous les rseaux IP existants. Ce problme est particulirement rsolu par le "supernetting"
ou CIDR (Classless Internet Domain Routing) [RFC 1519].
IPv4 ne permet pas d'indiquer de faon pratique le type de donnes transportes (TOS ou Type of
Service dans IPv4)d'o, par consquent, leur urgence ou le niveau de service souhait. Ce besoin est
particulirement critique pour les applications "temps rel" comme la vido mais aussi celles plus
classiques (par exemple, en donnant des priorits tel ou tel trafic). Ce problme a t voqu et clarifi
mais reste peu mis en oeuvre [RFC 1349]. Il est symptomatique que les protocoles de routage les plus
rpandus ne tiennent pas vraiment compte du TOS dans le calcul des routes.
Enfin, IPv4 ne fournit pas de mcanismes de scurit comme l'authentification des paquets, leur intgrit
ou leur confidentialit. Il a toujours t considr que ces techniques taient de la responsabilit des
applications elles-mmes.
L'volution des besoins des utilisateurs ainsi que l'apparition de nouveaux marchs ne cessent d'amplifier
les "carences" du protocole IPv4 actuel.

DESCRIPTION DES PRINCIPALES CARACTRISTIQUES D'IPv6

Guillaume Desgeorge

39

IPv6 est la nouvelle version d' IP et reprsente une trs forte volution par rapport IPv4. Les principales
fonctionnalits d'IPv4 sont conserves dans IPv6 except certaines fonctions peu ou pas utilises qui ont
t supprimes ou rendues optionnelles. En outre, quelques priorits ont t ajoutes.
Il est possible de dgager huit grandes caractristiques inclues dans IPv6.
Des possibilits tendues d'adressage et de routage
La taille de l'adresse IP augmente de 32 128 bits afin de supporter un plus grand nombre de noeuds
adressables, davantage de niveaux d' adressage hirarchique ainsi qu'une auto configuration plus simple
des adresses.
Un mcanisme adaptable de diffusion ainsi qu'un nouveau type d' adresses en "cluster" sont dfinis dans
IPv6.
Un format d'en-tte simplifi
Des champs du format de l'en-tte IPv4 ont t abandonns ou rendus optionnels, ainsi l'en-tte IPv6 est
simplifi et rduite un traitement commun dans tous les routeurs ce qui diminue donc le cot de
traitement dans ces routeurs.
Des possibilits d'extension des en-ttes et desoptions
Dans IPv6, les options sont ranges dans des en-ttes supplmentaires situs entre l'en-tte IPv6 et
l'en-tte du paquet de transport (T-PDU, Transport Protocol Data Unit ou Units de donnes du service
de transport). La plupart des options dans les en-ttes IPv6 ne sont ni examines, ni traites par les
routeurs intermdiaires. Contrairement IPv4, les options IPv6 peuvent tre de longueur arbitraire, il n'
existe pas de taille limite.
Une des caractristiques d'IPv6 est la possibilit de coder, dans les options, l'action qu'un routeur ou une
station de travail doit raliser si l'option est inconnue, ce qui permet l'ajout de fonctionnalits
supplmentaires dans un rseau dj oprationnel avec un minimum de perturbations.

Des possibilits d'authentification et de confidentialit


IPv6 intgre des extension permettant l'authentification des usagers et l'intgrit des donnes grce
des outils de cryptographie.
Des possibilits d' autoconfiguration
IPv6 dispose de plusieurs formes d' autoconfiguration comme la configuration "plug and play" d'adresses
de noeuds sur un rseau isol grce aux caractristiques offertes par DHCP.
Des possibilits pour le "Source Route"
IPv6 intgre une fonction tendue de source routing grce SDRP (Source Demand Routing Protocol)
afin d'tendre le routage des routes interdomaine et intradomaine.
Une transition d'IPv4 IPv6 simple et flexible
La transition d'IPv4 IPv6 rpond quatre objectifs essentiels :
un besoin de modernisation,
un besoin de redploiement,
un adressage facile,
une diminution du cot de dmarrage.
Tous ces aspects seront revus ultrieurement lors de l'tude approfondie de la transition d'IPv4 IPv6 (cf.
XII).
Des possibilits de qualit de service

Guillaume Desgeorge

40

L'introduction de flux tiquets (avec des priorits), les services de contraintes <<temps rel>> sont de
nouveaux lments rendant possible la qualit de service.
Aprs cette numration succincte rapide des principales caractristiques d'IPv6, il convient de
reprendre un certain nombre de ces lments afin d'apporter quelques claircissements sur les nouvelles
possibilits d'IPv6.

FORMAT D'EN-TTE IPv6


Avant toute chose, donnons quelques dfinitions :
Noeud (node) : un module protocolaire qui implmente IPv6.
Router (routeur) : un noeud qui transmet des paquets IPv6 non explicitement adresss lui-mme.
Station (host) : tout noeud qui n'est pas un routeur.
Interface : un attachement d'un noeud une liaison.
Adresse (address) : un identifiant de la couche IPng pour une interface ou un groupe d'interfaces.
Liaison (link) : un moyen de communication ou mdium sur lequel les noeudspeuvent communiquer avec
la couche liaison (la couche immdiatement sous IPv6).
Voisins (neighbors) : noeuds rattachs la mme liaison.
MTU de liaison (link MTU) l'unit de transmission maximale (Maximum Transmission Unit - MTU), c'est
dire la taille maximale du paquet en octets, qui peut tre achemin en un seul "morceau" sur une liaison
(un paquet tant compos d'une en-te IPv6 et de son "payload").
MTU de chemin (path MTU) : le plus petit MTU de liaison de toutes les liaisons que compose un chemin
entre un noeud source et un noeud de destination.
Bien que plus longue que la version 4 d'IP, l'en-tte de IPng a t simplifie. Un certain nombre de
fonctions prsentent dans l'en-tte d'IPv4 ont t soit disposes dans des en-ttes supplmentaires, soit
abandonnes.

- Version (4 bits): ce champ dfini le numro de version du Protocole IP.


IPng est la version 6.
- Flow Label (28 bits): ce champ, tiquette de flux, peut tre utilis par une station pour "marquer"
certains paquets afin qu'ils suivent un routage (service) particulier dans un rseau, tel un service de
qualit sans dfaut, ou un service "temps-rel".
- Payload Length (16 bits): elle reprsente la longueur des donnes aprs l'en-tte IPv6 en octets. Pour
tendre cette valeur plus de 64 KOctets, la valeur est donne dans une option noeud-par-noeud. Le
champ longueur donnes est alors 0.
- Next Header (8 bits): il identifie le type d'en-tte suivant immdiatement l'en-tte IPv6. Ce champ est le
mme que le champ protocole d'IPv4.
- Hop limit (8 bits): utilis pour dtruire les paquets qui pourraient rester dans le rseau la suite de
boucles dues aux tables de routage, ce champ est dcrment de une unit chaque noeud qui
retransmet le paquet (quivalent au Time To Live d'IPv4 - dure de vie).
- Source Address (128 bits): champ adresse de l'metteur du datagramme.
- Destination address (128 bits): champ adresse du destinataire du paquet. Il est possible que l'adresse
ne soit pas celle du destinataire final si une option de routage est prsente.

EN-TTES SUPPLMENTAIRES
Dans la nouvelle version 6 d' IP, des informations complmentaires sont codes dans des en-ttes qui
doivent tre placs dans le paquet entre l'en-tte IPv6 l'en-tte de la couche transport. Ily a un petit
nombre d'extensions d'en-tte, chacun identifi par une valeur de Next Header distincte. Comme illustr

Guillaume Desgeorge

41

dans les exemples suivants, un paquet IPv6 peut comporter aucune, une ou plus d'en-ttes
supplmentaires,

Mise part une exception, les en-ttes supplmentaires ne sont nullement examins ou manipuls par
les noeuds atteints parle paquet le long de son chemin, jusqu' ce que le paquet arrive aunoeud (ou
chaque groupe de noeuds dans le cas du multicast)identifi par le champ adresse destinataire de l'entte IPv6. Ace moment l, le premier en-tte supplmentaire, ou l'en-tte transport dans le cas
d'absence d'en-tte supplmentaire, est trait. Le contenu de chaque en-tte dterminera s'il faut, ou
pas, traiter l'en-tte suivant.
La seule exception est l'en-tte de l'option noeud-par-noeud, elle porte des informations qui doivent tre
examines par les noeuds du rseau. Cette en-tte "Hop-by-Hop" Options, lorsqu'elle est prsente, doit
suivre immdiatement l'en-tte IPv6.
Chaque en-tte supplmentaire est d'une longueur d'un multiple de8 octets, afin de conserver un
alignement de 8 octets pour les en-ttes suivants.

Ordre des en-ttes supplmentaires


Lorsqu'il y a plus d'un en-tte supplmentaire utilis dans le mme paquet, les en-ttes doivent
apparatre dans l'ordre suivant :
IPv6 Header
Hop-by-Hop Options Header
Routing Header
Fragment Header
Authentication Header
End-to-End Options Header
Chaque type d'en-tte ne doit apparatre qu'une seule fois dans le paquet (excepter dans le cas d'une
encapsulation IPv6 dans IPv6, o chaque en-tte IPv6 encapsul doit tre suivi par son propre en-tte
supplmentaire).

Option noeud-par-nud
L'en-tte d'options noeud-par-noeud comporte des informations analyses par les diffrents noeuds du
chemin pris par le paquet. L'en-tte des options noeud-par-noeud est identifi par une valeur de Next
Header gale 0, et a le format suivant :

- Next Header (8 bits): identifie le type d'en-tte suivant immdiatement l'en-tte d'options noeud-parnoeud. Les valeurs sont identiques au champ de protocole de IPv4.
- Hdr Ext Len (8 bits): longueur de l'en-tte des options noeud-par-noeud en multiple de 8 octets,
l'exclusion des 8 premiers.
- Options: ce champ contient une ou plusieurs options codes en TLV(Type-Length-Value). Ce premier
est de longueur variable, il est un multiple de 8 octets. Nous allons dcrire ce champ dans le paragraphe
suivant.

Options d'en-tte IPv6

Deux des en-ttes supplmentaires actuellement dfinis, celle des options noeud-par-noeud et celle des
options bout-en-bout, doivent porter un nombre variable d'options codes TLV suivant le format:

Guillaume Desgeorge

42

- Option Type (8 bits): identifiant de la nature de l'option.


- Opt Data Len (8 bits): longueur du champ de donnes de cette option en octets.
- Option Data (longueur variable): donnes de l'option. Champ de longueur variable.
Les identifiants Option Type sont cods de manire ce que les deux bits de poids fort provoque
l'opration suivante si un noeud ne reconnat pas le Option Type:
00 ne traite pas cette option et poursuit le traitement de l'en-tte
01
dtruit le paquet
10 dtruit le paquet et envoie l'adresse source un message ICMP de non reconnaissance, et indique la
faute en donnant le Option Type.
11 non dfini
Dans le seul cas des options noeud-par-noeud, le troisime bit de poids fort de Option Type indique si
les donnes de cette option doivent tre soumises au calcul d'assurance intgrit lorsque l'en-tte
d'authentification est prsente. Les donnes de l'option modifies en cours de routage sont exclues de
ce calcul.
inclus un calcul d'intgrit
exclus du calcul d'intgrit

Les champs Option Data des options de bout-en-bout ne changent jamais en route et donc, sont
toujours inclus dans le calcul d'intgrit.

En-tte de routage

L'en-tte de routage est utilis par une source pour tablir une table de noeud(s) intermdiaire(s) (ou
ensemble de groupes) que doit emprunter le paquet pour arriver destination. Cette forme particulire
d'en-tte de routage est conue pour supporter le "protocole de routage la demande de la source"
(Source Demand Routing Protocol, SDRP) [Estrin94b].

Next Header: identifie le type d'en-tte suivant immdiatement l'en-tte de routage. Les valeurs sont
identiques au champ de protocole de IPv4.
Routing Type: indique le type de routage supporter par cette en-tte. La valeur est 1.

MRE (Must Report Errors) flag: si ce bit est 1 et qu'un routeur ne puisse mettre, conformment la
liste Source Route, le paquet (avec un routage incomplet), le routeur gnre un message d'erreur ICMP.
Dans le cas o le bit MRE est 0, le routeur ne gnre pas de message d'erreur ICMP.
F (Failure of Source Route Behavior) flag (1 bit): si ce bit est positionn 1, il indique que si un routeur
ne peut acheminer plus loin un paquet (avec un routage incomplet), comme spcifi dans le Source
Route, le routeur fixe la valeur du champ Next Hop Pointer la valeur du champ Source Route Length.
Ainsi la destination suivante du paquet sera uniquement base sur l'adresse de destination (destination
address). De mme si le bit F est 0, alors dans les mmes conditions, le routeur dtruira le paquet.

Reserved (6 bits): initialis 0 l'mission, ignor la rception.

Guillaume Desgeorge

43

- Source Route Length (8 bits): c'est le nombre d'lments/noeuds dans une en-tte de routage SDRP.
La longueur de cet en-tte peut tre calcule partir de cette valeur (longueur=SrcRouteLen*16+8). Ce
champ ne doit pas excder la valeur de 24.
Next Hop Pointer (NextHopPtr - 8 bits): il pointe les lments/noeuds atteindre. Il est initialis 0 pour
pointer le premier lment/noeud de Source Route. Quand il est gal au Source Route Length, alors le
Source Route est termin.
Strict/Loose Bit Mask (24 bits): ce masque est utilis pour prendre une dcision d'aiguillage un noeud.
Si la valeur de Next Hop Pointer est N, alors que le Nme bit du Strict/Loose Bit Mask est 1, cela
indique que le prochain noeud est un noeud Strict Source Route Hop. Tandis que s'il est 0, le prochain
noeud est un Loose Route Hop.

- Source Route (multiple de 128 bits): c'est une liste d'adresses IPv6, indiquant le chemin suivre par le
paquet. Le Source Route peut contenir un ensemble d'adresses de types unicast et cluster.

VI.E)En-tte de fragmentation
L'en-tte de fragmentation est utilis par la source pour envoyer des paquets plus grands que ne peut
acheminer le rseau leurs destinataires. A la diffrence de la version 4 d' IP, la fragmentation est
excute seulement par les noeuds source et non plus par les routeurs qui acheminent les paquets le
long du chemin. L'en-tte de fragmentation est repr par une valeur de Next Header gale 44 juste
aprs le prcdent en-tte. Le format est le suivant :

Next Headr (8 bits): identifie le type d'en-tte suivant immdiatement l'en-tte de fragmentation. Les
valeurs sont identiques au champ de protocole de IPv4.
Reserved (8 bits), Res (2 bits) : initialiss 0 l'mission, ignors la rception.

Fragmentation Offset (13 bits): il indique la position du premier octet dans le datagramme total (non
fragment). Le premier fragment la place 0. La valeur du champ est un multiple de 8 octets.
M flag (1 bit): si le bit est 1, il reste un ou des fragments. Tandis que s'il est 0 il n'y en a plus.

Identification (32 bits): une valeur assigne au paquet d'origine qui est diffrente de tous les autres
paquets fragments rcemment avec la mme adresse source, les mmes adresses de destination et
valeur du Fragment Next Header. Ce champ permet d'identifier le datagramme pour scuriser le
rassemblage des paquets. Le numro d'identification est port par l'en-tte de tous les diffrents
fragments
VI.F)En-tte d'authentification
L'en-tte d'authentification est utilis pour authentifier et assurer l'intgrit des paquets. La nonrpudiation est obtenue par un algorithme d'authentification excut sur l'en-tte d'authentification. Mais
elle n'est pas obtenue par tous les algorithmes d'authentification excuts sur cet en-tte. L'en-tte
d'authentification est dtermin par la valeur 51du champ Next Header, et a le format suivant :

Next Header (8 bits): identifie le type d'en-tte suivant immdiatement l'en-tte d'authentification. Les
valeurs sont identiques celles du champ de protocole de IPv4.

Guillaume Desgeorge

44

Authentication Data Length (Auth Data Len - 8 bits): c'est la longueur du champ Authentication Data,
multiple de 8 octets.

Reserved (16 bits): initialis 0 l'mission, ignor la rception.


Security Association ID (SAID - 32 bits): lorsqu'il est combin avec l'adresse source, il identifie au(x)
destinataire(s) le type de scurit tabli, associ au paquets concerns.

- Authentication Data (longueur variable): information sur l'algorithme spcifique ncessaire authentifier
la source du paquet et assurer son intgrit conformment la scurit associe. La longueur de ce
champ est variable et est un multiple de 8 octets.

VI.G)En-tte de confidentialit
L'en-tte priv cherche donner une confidentialit et une intgrit en cryptant les donnes protger et
en les plaant dans la section donnes de l'en-tte de confidentialit (Privacy Header). Suivant les
exigences de scurit de l'utilisateur, soit la trame de couche transport (e.g. UDP ou TCP) est crypte,
soit le datagramme entierd'IPv6 l'est. Cette approche par encapsulation est ncessaire pour assurer une
confidentialit du datagramme complet original. S'il est prsent, l'en-tte de confidentialit est toujours le
dernier champ non-crypt dans un paquet.
Le Privacy Header travaille entre stations, entre une station et un gateway(passerelle) de scurit, ou
entre des gateways de scurit. Ceci permet sans d'importants cots financiers et de performance
d'assurer un rseau digne de confiance en transitant dut rafic scuris sur des segments du rseau qui
ne le sont pas.

Security Association Identifier (SAID - 32 bits): identifie le type de scurit au datagramme. Si aucune
association de scurit n'a t tablie, la valeur de ce champ est 0x0000. Une association de scurit
est unilatrale. Une communication scurise entre deux stations doit avoir normalement deux SAID (un
pour chaque sens des changes). La station destinataire utilise la combinaison de la valeur du SAID et
de l'adresse origine pour distinguer la correcte association.
Initialization Vector (longueur dpendant du SAID): ce champ est optionnel et sa valeur dpend du SAID
utilis. Par exemple, le champ peut contenir des donnes de synchronisation de cryptographie pour un
algorithme de codage. Il peut aussi contenir un vecteur d' initialisation cryptographique. L'implantation
d'une en-tte de confidentialit utilisera une valeur de SAID pour dterminer si le champ n'est pas vide, et
si c'est le cas, value la longueur du champ et l'utilise.

Next Header (8 bits), crypt: identifie le type d'en-tte suivant immdiatement l'en-tte de confidentialit.
Les valeurs sont identiques celles du champ de protocole de IPv4.
Reserved (17 bits), crypt: ignor la rception.

Length (8 bits), crypt: longueur de l'en-tte priv, l'exclusion des 8 premiers octets, donne en un
multiple de 8 octets.
Protected Data (longueur variable), crypt: ce champ peut contenir un datagramme complet encapsul
IPv6, une squence d'option(s) IPv6 ou pas, et enfin le paquet de la couche transport. Ou bien, il est
constitu du paquet de la couche transport prcd ou pas d'une srie d'option(s).

Algorithme-dependant Trailer (trailer - longueur variable suivant SAID), crypt: ce champ est utilis pour
faire du bourrage (ncessit de certains algorithmes) ou pour enregistrer des donnes d'authentification
Guillaume Desgeorge

45

utiliser avec un algorithme de cryptographie qui fournit la confidentialit sans l'authentification. Ce champ
n'est prsent que si l'algorithme utilis le ncessite.
En-tte de bout-en-bout
L'en-tte d'options bout-en-bout donne une information optionnelle qui doit tre contrle par le(s)
noeud(s) destinataire(s) du paquet. L'en-tte des options bout-en-bout est identifi par une valeur de Next
Header de TBD suivant immdiatement l'en-tte prcdent, et a le mme format que l'en-tte d'option
noeud-par-noeud, l'exception de la capacit d'exclure une option de calcul d'intgrit.

Guillaume Desgeorge

46

Conclusion

A moins dune entente cordiale entre les organismes de normalisation et les constructeurs, on verra
apparatre de nouveaux protocoles imposs par les constructeurs. Les avances technologiques en
matire de transmissions laissent supposer de futurs protocoles pouvant jouir des nouvelles possibilits
de traitement. La dmocratisation du monde des rseaux rend communs des mots comme IP ou
internet. Mais avec cette dmocratisation, il faut grer une demande forte et une qualit de service. Les
projets sont donc ambitieux et lATM figure comme lun des prcurseurs ; il est adaptable et permet
plusieurs dbits. Cest dans la pluralit des services que lATM se montre aujourdhui comme le premier
des protocoles du futur.

ANNEXES
PROTOCOL NUMBERS
In the Internet Protocol (IP) [45,105] there is a field, called
Protocol, to identify the the next level protocol. This is an 8 bit
field.
Assigned Internet Protocol Numbers
Decimal
------0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Keyword
-------

Protocol
-------Reserved
ICMP
Internet Control Message
IGMP
Internet Group Management
GGP
Gateway-to-Gateway
Unassigned
ST
Stream
TCP
Transmission Control
UCL
UCL
EGP
Exterior Gateway Protocol
IGP
any private interior gateway
BBN-RCC-MON BBN RCC Monitoring
NVP-II
Network Voice Protocol
PUP
PUP
ARGUS
ARGUS
EMCON
EMCON
XNET
Cross Net Debugger
CHAOS
Chaos
UDP
User Datagram
MUX
Multiplexing
DCN-MEAS
DCN Measurement Subsystems
HMP
Host Monitoring
PRM
Packet Radio Measurement
XNS-IDP
XEROX NS IDP
TRUNK-1
Trunk-1
TRUNK-2
Trunk-2
LEAF-1
Leaf-1
LEAF-2
Leaf-2
RDP
Reliable Data Protocol
IRTP
Internet Reliable Transaction
ISO-TP4
ISO Transport Protocol Class 4
Guillaume Desgeorge

References
---------[JBP]
[97,JBP]
[43,JBP]
[60,MB]
[JBP]
[49,JWF]
[106,JBP]
[PK]
[123,DLM1]
[JBP]
[SGC]
[22,SC3]
[8,XEROX]
[RWS4]
[BN7]
[56,JFH2]
[NC3]
[104,JBP]
[23,JBP]
[DLM1]
[59,RH6]
[ZSU]
[133,XEROX]
[BWB6]
[BWB6]
[BWB6]
[BWB6]
[138,RH6]
[79,TXM]
[63,RC77]
47

30
31
32
33
34
35-60
61
62
63
64
65
66
67
68
69
70
71
72-75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92-254
255

NETBLT
MFE-NSP
MERIT-INP
SEP
3PC

Bulk Data Transfer Protocol


[20,DDC1]
MFE Network Services Protocol
[124,BCH2]
MERIT Internodal Protocol
[HWB]
Sequential Exchange Protocol
[JC120]
Third Party Connect Protocol
[SAF3]
Unassigned
[JBP]
any host internal protocol
[JBP]
CFTP
CFTP
[50,HCF2]
any local network
[JBP]
SAT-EXPAK
SATNET and Backroom EXPAK
[SHB]
Unassigned
[JBP]
RVD
MIT Remote Virtual Disk Protocol
[MBG]
IPPC
Internet Pluribus Packet Core
[SHB]
any distributed file system
[JBP]
SAT-MON
SATNET Monitoring
[SHB]
VISA
VISA Protocol
[GXT1]
IPCV
Internet Packet Core Utility
[SHB]
Unassigned
[JBP]
BR-SAT-MON Backroom SATNET Monitoring
[SHB]
SUN-ND
SUN ND PROTOCOL-Temporary
[WM3]
WB-MON
WIDEBAND Monitoring
[SHB]
WB-EXPAK
WIDEBAND EXPAK
[SHB]
ISO-IP
ISO Internet Protocol
[MTR]
VMTP
VMTP
[DRC3]
SECURE-VMTP SECURE-VMTP
[DRC3]
VINES
VINES
[BXH]
TTP
TTP
[JXS]
NSFNET-IGP NSFNET-IGP
[HWB]
DGP
Dissimilar Gateway Protocol
[74,ML109]
TCF
TCF
[GAL5]
IGRP
IGRP
[18,GXS]
OSPFIGP
OSPFIGP
[83,JTM4]
Sprite-RPC Sprite RPC Protocol
[143,BXW]
LARP
Locus Address Resolution Protocol
[BXH]
Unassigned
[JBP]
Reserved
[JBP]

Guillaume Desgeorge

48

PORT NUMBERS
Ports are used in the TCP [45,106] to name the ends of logical
connections which carry long term conversations. For the purpose of
providing services to unknown callers, a service contact port is
defined. This list specifies the port used by the server process as its
contact port. The contact port is sometimes called the "well-known
port".
To the extent possible, these same port assignments are used with the
UDP [46,104].
To the extent possible, these same port assignments are used with the
ISO-TP4 [64].
The assigned ports use a small portion of the possible port numbers.
The assigned ports have all except the low order eight bits cleared to
zero. The low order eight bits are specified here.
Port Assignments:
Decimal
------0
1
2-4
5
7
9
11
13
15
17
19
20
21
23
25
27
29
31
33
35
37
39
41
42
43
44
45
46
47
49
51
53
55
57

Keyword
-------

Description
----------Reserved
TCPMUX
TCP Port Service Multiplexer
Unassigned
RJE
Remote Job Entry
ECHO
Echo
DISCARD
Discard
USERS
Active Users
DAYTIME
Daytime
Unassigned
QUOTE
Quote of the Day
CHARGEN
Character Generator
FTP-DATA
File Transfer [Default Data]
FTP
File Transfer [Control]
TELNET
Telnet
SMTP
Simple Mail Transfer
NSW-FE
NSW User System FE
MSG-ICP
MSG ICP
MSG-AUTH
MSG Authentication
DSP
Display Support Protocol
any private printer server
TIME
Time
RLP
Resource Location Protocol
GRAPHICS
Graphics
NAMESERVER Host Name Server
NICNAME
Who Is
MPM-FLAGS MPM FLAGS Protocol
MPM
Message Processing Module [recv]
MPM-SND
MPM [default send]
NI-FTP
NI FTP
LOGIN
Login Host Protocol
LA-MAINT
IMP Logical Address Maintenance
DOMAIN
Domain Name Server
ISI-GL
ISI Graphics Language
any private terminal access

Guillaume Desgeorge

References
---------[JBP]
[MKL]
[JBP]
[12,JBP]
[95,JBP]
[94,JBP]
[89,JBP]
[93,JBP]
[JBP]
[100,JBP]
[92,JBP]
[96,JBP]
[96,JBP]
[112,JBP]
[102,JBP]
[24,RHT]
[85,RHT]
[85,RHT]
[EXC]
[JBP]
[108,JBP]
[MA]
[129,JBP]
[99,JBP]
[55,MARY]
[JBP]
[98,JBP]
[98,JBP]
[134,SK8]
[PHD1]
[76,AGM]
[81,95,PM1]
[7,RB9]
[JBP]

49

59
61
63
65
67
68
69
71
72
73
74
75
77
79
81
83
85
87
89
91
93
95
97
98
99
101
102
103
104
105
107
109
110
111
113
115
117
119
121
123
125
127
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144

any private file service


NI MAIL
VIA Systems - FTP
TACACS-Database Service
Bootstrap Protocol Server
Bootstrap Protocol Client
Trivial File Transfer
Remote Job Service
Remote Job Service
Remote Job Service
Remote Job Service
any private dial out service
any private RJE service
FINGER
Finger
HOSTS2-NS HOSTS2 Name Server
MIT-ML-DEV MIT ML Device
MIT-ML-DEV MIT ML Device
any private terminal link
SU-MIT-TG SU/MIT Telnet Gateway
MIT-DOV
MIT Dover Spooler
DCP
Device Control Protocol
SUPDUP
SUPDUP
SWIFT-RVF Swift Remote Vitural File Protocol
TACNEWS
TAC News
METAGRAM
Metagram Relay
HOSTNAME
NIC Host Name Server
ISO-TSAP
ISO-TSAP
X400
X400
X400-SND
X400-SND
CSNET-NS
Mailbox Name Nameserver
RTELNET
Remote Telnet Service
POP2
Post Office Protocol - Version 2
POP3
Post Office Protocol - Version 3
SUNRPC
SUN Remote Procedure Call
AUTH
Authentication Service
SFTP
Simple File Transfer Protocol
UUCP-PATH UUCP Path Service
NNTP
Network News Transfer Protocol
ERPC
Encore Expedited Remote Proc. Call
NTP
Network Time Protocol
LOCUS-MAP Locus PC-Interface Net Map Server
LOCUS-CON Locus PC-Interface Conn Server
PWDGEN
Password Generator Protocol
CISCO-FNA CISCO FNATIVE
CISCO-TNA CISCO TNATIVE
CISCO-SYS CISCO SYSMAINT
STATSRV
Statistics Service
INGRES-NET INGRES-NET Service
LOC-SRV
Location Service
PROFILE
PROFILE Naming System
NETBIOS-NS NETBIOS Name Service
NETBIOS-DGM NETBIOS Datagram Service
NETBIOS-SSN NETBIOS Session Service
EMFIS-DATA EMFIS Data Service
EMFIS-CNTL EMFIS Control Service
BL-IDM
Britton-Lee IDM
IMAP2
Interim Mail Access Protocol v2
NEWS
NewS
NI-MAIL
VIA-FTP
TACACS-DS
BOOTPS
BOOTPC
TFTP
NETRJS-1
NETRJS-2
NETRJS-3
NETRJS-4

Guillaume Desgeorge

[JBP]
[5,SK8]
[DXD]
[3,KH43]
[36,WJC2]
[36,WJC2]
[126,DDC1]
[10,RTB3]
[10,RTB3]
[10,RTB3]
[10,RTB3]
[JBP]
[JBP]
[52,KLH]
[EAK1]
[DPR]
[DPR]
[JBP]
[MRC]
[EBM]
[DT15]
[27,MRC]
[MXR]
[ANM2]
[GEOF]
[54,MARY]
[16,MTR]
[HCF2]
[HCF2]
[127,MS56]
[101,JBP]
[14,JKR1]
[122,MTR]
[DXG]
[130,MCSJ]
[73,MKL1]
[44,MAE]
[65,PL4]
[132,JXO]
[80,DLM1]
[137,EP53]
[137,EP53]
[141,FJW]
[WXB]
[WXB]
[WXB]
[DLM1]
[MXB]
[JXP]
[LLP]
[JBP]
[JBP]
[JBP]
[GB7]
[GB7]
[SXS1]
[MRC]
[JAG]
50

145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
198-200
201
202
203

UAAC
UAAC Protocol
[DAG4]
ISO-TP0
ISO-IP0
[86,MTR]
ISO-IP
ISO-IP
[MTR]
CRONUS
CRONUS-SUPPORT
[135,JXB]
AED-512
AED 512 Emulation Service
[AXB]
SQL-NET
SQL-NET
[MXP]
HEMS
HEMS
[87,CXT]
BFTP
Background File Transfer Program
[AD14]
SGMP
SGMP
[37,MS9]
NETSC-PROD NETSC
[SH37]
NETSC-DEV NETSC
[SH37]
SQLSRV
SQL Service
[CMR]
KNET-CMP
KNET/VM Command/Message Protocol
[77,GSM11]
PCMail-SRV PCMail Server
[19,MXL]
NSS-Routing NSS-Routing
[JXR]
SGMP-TRAPS SGMP-TRAPS
[37,MS9]
SNMP
SNMP
[15,MTR]
SNMPTRAP
SNMPTRAP
[15,MTR]
CMIP-Manage CMIP/TCP Manager
[4,AXB1]
CMIP-Agent CMIP/TCP Agent
[4,AXB1]
XNS-Courier Xerox
[144,SXA]
S-Net
Sirius Systems
[BXL]
NAMP
NAMP
[MS9]
RSVD
RSVD
[NT12]
SEND
SEND
[WDW11]
Print-SRV Network PostScript
[BKR]
Multiplex Network Innovations Multiplex
[KXD]
CL/1
Network Innovations CL/1
[KXD]
Xyplex-MUX Xyplex
[BXS]
MAILQ
MAILQ
[RXZ]
VMNET
VMNET
[CXT]
GENRAD-MUX GENRAD-MUX
[RXT]
XDMCP
X Display Manager Control Protocol
[RWS4]
NextStep
NextStep Window Server
[LXH]
BGP
Border Gateway Protocol
[KSL]
RIS
Intergraph
[DXB]
Unify
Unify
[VXS]
Unisys-Cam Unisys-Cam
[GXG]
OCBinder
OCBinder
[JXO1]
OCServer
OCServer
[JXO1]
Remote-KIS Remote-KIS
[RXD1]
KIS
KIS Protocol
[RXD1]
ACI
Application Communication Interface
[RXC1]
MUMPS
MUMPS
[HS23]
QFT
Queued File Transport
[WXS]
GACP
Gateway Access Control Protocol
[PCW]
Prospero
Prospero
[BCN]
OSU-NMS
OSU Network Monitoring System
[DXK]
SRMP
Spider Remote Monitoring Protocol
[TXS]
IRC
Internet Relay Chat Protocol
[JXO2]
DN6-NLM-AUD DNSIX Network Level Module Audit
[LL69]
DN6-SMM-RED DNSIX Session Mgt Module Audit Redirect[LL69]
DLS
Directory Location Service
[SXB]
DLS-Mon
Directory Location Service Monitor
[SXB]
Unassigned
[JBP]
AT-RMTP
AppleTalk Routing Maintenance
[RXC]
AT-NBP
AppleTalk Name Binding
[RXC]
AT-3
AppleTalk Unused
[RXC]
Guillaume Desgeorge

51

204
205
206
207
208
209-223
224-241
243
245
246
247-255

AT-ECHO
AT-5
AT-ZIS
AT-7
AT-8

SUR-MEAS
LINK
DSP3270

AppleTalk Echo
AppleTalk Unused
AppleTalk Zone Information
AppleTalk Unused
AppleTalk Unused
Unassigned
Reserved
Survey Measurement
LINK
Display Systems Protocol
Reserved

Guillaume Desgeorge

[RXC]
[RXC]
[RXC]
[RXC]
[RXC]
[JBP]
[JBP]
[6,DDC1]
[1,RDB2]
[39,WJS1]
[JBP]

52