Je ne sais pas si tu le sais, mais le modèle OSI est tellement bien
normalisé, qu'on a même des sortes d'exemples de protocoles, comme
(j'espère ne pas dire de bêtise) ASN.1 pour la couche Presentation.
Donc deja de base on sort completement du modele quand on dit que tel
service internet est sur les couches 5-6-7.
Mais ce que je veux dire c'est que le modele OSI forme reellement un
tout et n'a pas ete fait pour faire de l'encapsulation de basses
couches.
En gros comme si on avait ethernet, TCP/IP, telnet au dessus et point
final. Pas des sortes de proxy, des triturations d'encapsulations, et
autres.
C'est un protocole decrit de A a Z, dont les couches sont
interchangeables il est vrai, mais chacune faisant tranquillement sa
fonction sans qu'il soit question d'un quelconque point de vue.
C'est pour cela que ca me choque un peu le fait de ramner du ssh a du
niveau 3 alors qu'il est deja transporte par TCP/IP.
Mais alors comparer au modele OSI n'est plus possible.
Ou alors on cree un modele completement different avec un nombre de
macro-couches infinies, chaques couches etant divisees en 7 couches
assimilees aux couches du modeles OSI. Où changer de "point de vue"
revient à changer de macro-couche.
Et là, je suis d'accord. :-)
(ouf, the end or not ?)
Je ne sais pas si tu le sais, mais le modèle OSI est tellement bien
normalisé, qu'on a même des sortes d'exemples de protocoles, comme
(j'espère ne pas dire de bêtise) ASN.1 pour la couche Presentation.
Donc deja de base on sort completement du modele quand on dit que tel
service internet est sur les couches 5-6-7.
Mais ce que je veux dire c'est que le modele OSI forme reellement un
tout et n'a pas ete fait pour faire de l'encapsulation de basses
couches.
En gros comme si on avait ethernet, TCP/IP, telnet au dessus et point
final. Pas des sortes de proxy, des triturations d'encapsulations, et
autres.
C'est un protocole decrit de A a Z, dont les couches sont
interchangeables il est vrai, mais chacune faisant tranquillement sa
fonction sans qu'il soit question d'un quelconque point de vue.
C'est pour cela que ca me choque un peu le fait de ramner du ssh a du
niveau 3 alors qu'il est deja transporte par TCP/IP.
Mais alors comparer au modele OSI n'est plus possible.
Ou alors on cree un modele completement different avec un nombre de
macro-couches infinies, chaques couches etant divisees en 7 couches
assimilees aux couches du modeles OSI. Où changer de "point de vue"
revient à changer de macro-couche.
Et là, je suis d'accord. :-)
(ouf, the end or not ?)
Je ne sais pas si tu le sais, mais le modèle OSI est tellement bien
normalisé, qu'on a même des sortes d'exemples de protocoles, comme
(j'espère ne pas dire de bêtise) ASN.1 pour la couche Presentation.
Donc deja de base on sort completement du modele quand on dit que tel
service internet est sur les couches 5-6-7.
Mais ce que je veux dire c'est que le modele OSI forme reellement un
tout et n'a pas ete fait pour faire de l'encapsulation de basses
couches.
En gros comme si on avait ethernet, TCP/IP, telnet au dessus et point
final. Pas des sortes de proxy, des triturations d'encapsulations, et
autres.
C'est un protocole decrit de A a Z, dont les couches sont
interchangeables il est vrai, mais chacune faisant tranquillement sa
fonction sans qu'il soit question d'un quelconque point de vue.
C'est pour cela que ca me choque un peu le fait de ramner du ssh a du
niveau 3 alors qu'il est deja transporte par TCP/IP.
Mais alors comparer au modele OSI n'est plus possible.
Ou alors on cree un modele completement different avec un nombre de
macro-couches infinies, chaques couches etant divisees en 7 couches
assimilees aux couches du modeles OSI. Où changer de "point de vue"
revient à changer de macro-couche.
Et là, je suis d'accord. :-)
(ouf, the end or not ?)
Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.
Donc en fait il y a plusieurs boulots, et ils peuvent être faits par
des gens différents.
On sort de plus en plus du modele OSI...
Hein ?
IPsec remplace IP en soit.
Et pas IP transporte IPsec.
Enfin c'est plus compliqué : dans IPv6, on peut choisir IP ou IPsec en
guise de couche 3, mais on a pas l'une qui transporte l'autre.
Bon, je propose SSL + TCP est de couche 4, comme TCP.
Ouais, une sorte de fusion des deux a la rigueur (ou mini-surcouche
entre TCP et SSL !).
Mais franchement on s'ecarte de plus en plus du modele OSI auquel tu
tiens tant a te raccrocher.
Tiens, deja sachant que TCP s'occupe de gerer une connexion, alors que
normalement c'est un des boulots de la couche Session (5)...
Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.
Donc en fait il y a plusieurs boulots, et ils peuvent être faits par
des gens différents.
On sort de plus en plus du modele OSI...
Hein ?
IPsec remplace IP en soit.
Et pas IP transporte IPsec.
Enfin c'est plus compliqué : dans IPv6, on peut choisir IP ou IPsec en
guise de couche 3, mais on a pas l'une qui transporte l'autre.
Bon, je propose SSL + TCP est de couche 4, comme TCP.
Ouais, une sorte de fusion des deux a la rigueur (ou mini-surcouche
entre TCP et SSL !).
Mais franchement on s'ecarte de plus en plus du modele OSI auquel tu
tiens tant a te raccrocher.
Tiens, deja sachant que TCP s'occupe de gerer une connexion, alors que
normalement c'est un des boulots de la couche Session (5)...
Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.
Donc en fait il y a plusieurs boulots, et ils peuvent être faits par
des gens différents.
On sort de plus en plus du modele OSI...
Hein ?
IPsec remplace IP en soit.
Et pas IP transporte IPsec.
Enfin c'est plus compliqué : dans IPv6, on peut choisir IP ou IPsec en
guise de couche 3, mais on a pas l'une qui transporte l'autre.
Bon, je propose SSL + TCP est de couche 4, comme TCP.
Ouais, une sorte de fusion des deux a la rigueur (ou mini-surcouche
entre TCP et SSL !).
Mais franchement on s'ecarte de plus en plus du modele OSI auquel tu
tiens tant a te raccrocher.
Tiens, deja sachant que TCP s'occupe de gerer une connexion, alors que
normalement c'est un des boulots de la couche Session (5)...
Et dans la maniere dont toi tu te connectes habituellement, le PPP
transportant ces paquets TCP/IP, PPP passant par une connexion ssh qui
elle meme est sur du tcp/ip passant sur du ethernet, tu le mets où
dans le modele OSI ?
J'accepte le fait qu'un service soit vu différemment selon le point de
vue adopté.
Bein non, je trouve qu'il est assez bien adapté. Il n'est certes pas
parfait, mais il est bien pratique. Le tout est d'accepter de changer
de point de vue.
Et dans la maniere dont toi tu te connectes habituellement, le PPP
transportant ces paquets TCP/IP, PPP passant par une connexion ssh qui
elle meme est sur du tcp/ip passant sur du ethernet, tu le mets où
dans le modele OSI ?
J'accepte le fait qu'un service soit vu différemment selon le point de
vue adopté.
Bein non, je trouve qu'il est assez bien adapté. Il n'est certes pas
parfait, mais il est bien pratique. Le tout est d'accepter de changer
de point de vue.
Et dans la maniere dont toi tu te connectes habituellement, le PPP
transportant ces paquets TCP/IP, PPP passant par une connexion ssh qui
elle meme est sur du tcp/ip passant sur du ethernet, tu le mets où
dans le modele OSI ?
J'accepte le fait qu'un service soit vu différemment selon le point de
vue adopté.
Bein non, je trouve qu'il est assez bien adapté. Il n'est certes pas
parfait, mais il est bien pratique. Le tout est d'accepter de changer
de point de vue.
Ah non, stop ! PPPoE et PPP sont transportés physiquement par les mêmes
fils (sur un bout de chemin), mais sans suivre le même protocole, et ils
ne s'empiètent pas l'un sur l'autre. Ils sont *à côté*.Donc PPPoE niveau 2, avec comme niveau 1 Ethernet, puis le réseau
téléphonique (mais avec des fraquences distinctes de celles utilisées
par le premier PPP). Tiens, au passage, ce PPPoE circule pendant un
moment au dessus d'ethernet, lui même de niveau 2.
Au-delà de la modulation électrique, l'ADSL, à la base, c'est de l'ATM
(couche ?), avec au-dessus AAL5 (ATM Adaptation Layer 5, donc couche 5
déjà), qui permet d'encapsuler tout un tas de protocoles. Si on utilise
PPPoE, le protocole encapsulé sur AAL5 est ethernet. Ensuite, PPPoE est
transporté sur cet ethernet, mais le modem, lui, n'est pas concerné par
PPPoE : il transforme de l'ethernet "physique" en ethernet encapsulé sur
AAL5 et vice versa. On pourrait aussi bien transporter directement de
l'IP au lieu de PPPoE, ou tout autre protocole passant sur ethernet.
Mais il se trouve qu'à l'autre bout, l'équipement ne comprend que PPPoE.
Donc, accès internet en ADSL, c'est :
IP sur PPPoE sur ethernet sur AAL5 sur ATM sur ADSL. Ouf !
Et notez bien que l'existence des trames ethernet, sous forme physique
ou encapsulée, perdure tout le long du lien ADSL, et même au-delà :
jusqu'à l'AC (Access Concentrator), c'est-à-dire le BAS chez FT.PPP -> PPPoE
Non, ils sont *à côté* l'un de l'autre. La preuve, si tu en coupes un,
tu n'affectes pas l'autre.
Ça dépend si on parle du PPP passant par le modem RTC ou du PPP
transporté par PPPoE. PPPoE est une version modifiée de PPP pour lui
permettre de passer par une liaison ethernet. Sous Linux, pppd se sert
de rp-pppoe pour gérer cette particularité, mais c'est toujours pppd qui
gère la partie PPP classique (LCP, NCP...)
Ici c'est le démon PPTP qui va lancer PPP (cette fois ci en tant que
"serveur" je suppose)...
J'ai donc :
PPTP -> PPP -> PPPoE ???
non. Au sens strict, tu as PPTP (niveau 2) au dessus de TCP (il me
semble -- niveau 4,
La connexion TCP mise en place dans le protocole PPTP ne sert que pour
le contrôle, pas pour le transport. Le transport est assuré par un
tunnel GRE (protocole IP 47).
mais vu comme une simple liaison série, niveau 1,
par le PPP de PPTP). TCP est lui même au dessus d'IP (niveau 3), lui
même au dessus du PPP (ou PPPoE, ça dépend si tu utilises ton lien RTC
ou ADSL pour cette connexion -- niveau 2).
PS: je poste cet article à travers une connexion NNTP sur TCP relayée
par SSH passant par un accès ADSL avec PPPoE ;o)
Ah non, stop ! PPPoE et PPP sont transportés physiquement par les mêmes
fils (sur un bout de chemin), mais sans suivre le même protocole, et ils
ne s'empiètent pas l'un sur l'autre. Ils sont *à côté*.
Donc PPPoE niveau 2, avec comme niveau 1 Ethernet, puis le réseau
téléphonique (mais avec des fraquences distinctes de celles utilisées
par le premier PPP). Tiens, au passage, ce PPPoE circule pendant un
moment au dessus d'ethernet, lui même de niveau 2.
Au-delà de la modulation électrique, l'ADSL, à la base, c'est de l'ATM
(couche ?), avec au-dessus AAL5 (ATM Adaptation Layer 5, donc couche 5
déjà), qui permet d'encapsuler tout un tas de protocoles. Si on utilise
PPPoE, le protocole encapsulé sur AAL5 est ethernet. Ensuite, PPPoE est
transporté sur cet ethernet, mais le modem, lui, n'est pas concerné par
PPPoE : il transforme de l'ethernet "physique" en ethernet encapsulé sur
AAL5 et vice versa. On pourrait aussi bien transporter directement de
l'IP au lieu de PPPoE, ou tout autre protocole passant sur ethernet.
Mais il se trouve qu'à l'autre bout, l'équipement ne comprend que PPPoE.
Donc, accès internet en ADSL, c'est :
IP sur PPPoE sur ethernet sur AAL5 sur ATM sur ADSL. Ouf !
Et notez bien que l'existence des trames ethernet, sous forme physique
ou encapsulée, perdure tout le long du lien ADSL, et même au-delà :
jusqu'à l'AC (Access Concentrator), c'est-à-dire le BAS chez FT.
PPP -> PPPoE
Non, ils sont *à côté* l'un de l'autre. La preuve, si tu en coupes un,
tu n'affectes pas l'autre.
Ça dépend si on parle du PPP passant par le modem RTC ou du PPP
transporté par PPPoE. PPPoE est une version modifiée de PPP pour lui
permettre de passer par une liaison ethernet. Sous Linux, pppd se sert
de rp-pppoe pour gérer cette particularité, mais c'est toujours pppd qui
gère la partie PPP classique (LCP, NCP...)
Ici c'est le démon PPTP qui va lancer PPP (cette fois ci en tant que
"serveur" je suppose)...
J'ai donc :
PPTP -> PPP -> PPPoE ???
non. Au sens strict, tu as PPTP (niveau 2) au dessus de TCP (il me
semble -- niveau 4,
La connexion TCP mise en place dans le protocole PPTP ne sert que pour
le contrôle, pas pour le transport. Le transport est assuré par un
tunnel GRE (protocole IP 47).
mais vu comme une simple liaison série, niveau 1,
par le PPP de PPTP). TCP est lui même au dessus d'IP (niveau 3), lui
même au dessus du PPP (ou PPPoE, ça dépend si tu utilises ton lien RTC
ou ADSL pour cette connexion -- niveau 2).
PS: je poste cet article à travers une connexion NNTP sur TCP relayée
par SSH passant par un accès ADSL avec PPPoE ;o)
Ah non, stop ! PPPoE et PPP sont transportés physiquement par les mêmes
fils (sur un bout de chemin), mais sans suivre le même protocole, et ils
ne s'empiètent pas l'un sur l'autre. Ils sont *à côté*.Donc PPPoE niveau 2, avec comme niveau 1 Ethernet, puis le réseau
téléphonique (mais avec des fraquences distinctes de celles utilisées
par le premier PPP). Tiens, au passage, ce PPPoE circule pendant un
moment au dessus d'ethernet, lui même de niveau 2.
Au-delà de la modulation électrique, l'ADSL, à la base, c'est de l'ATM
(couche ?), avec au-dessus AAL5 (ATM Adaptation Layer 5, donc couche 5
déjà), qui permet d'encapsuler tout un tas de protocoles. Si on utilise
PPPoE, le protocole encapsulé sur AAL5 est ethernet. Ensuite, PPPoE est
transporté sur cet ethernet, mais le modem, lui, n'est pas concerné par
PPPoE : il transforme de l'ethernet "physique" en ethernet encapsulé sur
AAL5 et vice versa. On pourrait aussi bien transporter directement de
l'IP au lieu de PPPoE, ou tout autre protocole passant sur ethernet.
Mais il se trouve qu'à l'autre bout, l'équipement ne comprend que PPPoE.
Donc, accès internet en ADSL, c'est :
IP sur PPPoE sur ethernet sur AAL5 sur ATM sur ADSL. Ouf !
Et notez bien que l'existence des trames ethernet, sous forme physique
ou encapsulée, perdure tout le long du lien ADSL, et même au-delà :
jusqu'à l'AC (Access Concentrator), c'est-à-dire le BAS chez FT.PPP -> PPPoE
Non, ils sont *à côté* l'un de l'autre. La preuve, si tu en coupes un,
tu n'affectes pas l'autre.
Ça dépend si on parle du PPP passant par le modem RTC ou du PPP
transporté par PPPoE. PPPoE est une version modifiée de PPP pour lui
permettre de passer par une liaison ethernet. Sous Linux, pppd se sert
de rp-pppoe pour gérer cette particularité, mais c'est toujours pppd qui
gère la partie PPP classique (LCP, NCP...)
Ici c'est le démon PPTP qui va lancer PPP (cette fois ci en tant que
"serveur" je suppose)...
J'ai donc :
PPTP -> PPP -> PPPoE ???
non. Au sens strict, tu as PPTP (niveau 2) au dessus de TCP (il me
semble -- niveau 4,
La connexion TCP mise en place dans le protocole PPTP ne sert que pour
le contrôle, pas pour le transport. Le transport est assuré par un
tunnel GRE (protocole IP 47).
mais vu comme une simple liaison série, niveau 1,
par le PPP de PPTP). TCP est lui même au dessus d'IP (niveau 3), lui
même au dessus du PPP (ou PPPoE, ça dépend si tu utilises ton lien RTC
ou ADSL pour cette connexion -- niveau 2).
PS: je poste cet article à travers une connexion NNTP sur TCP relayée
par SSH passant par un accès ADSL avec PPPoE ;o)
Je ne veux pas etre de mauvaise fois, mais ssh est fait pour etre
transporte par du TCP/IP, si tu enleves ca ca n'est plus du ssh.
On retombe sur un modele point a point apparemment, ce qui change
tout.
Si. Le principe d'indépendance des couches fait que je peux envisager
de faire passer du ssh dans autre chose que le sacro-saint
TCP-au-desus-d'IP, et que cela va rester du ssh.
Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.
Donc en fait il y a plusieurs boulots, et ils peuvent être faits par
des gens différents.
Non. SSL est transporté par TCP.
Apres il y a la cas particulier de IPsec mais la oui on touche
explicitement a la couche 3.
Donc, on peut transporter au dessus d'une couche 3 un serice de couche 3.
Bon, je propose SSL + TCP est de couche 4, comme TCP.
Je ne veux pas etre de mauvaise fois, mais ssh est fait pour etre
transporte par du TCP/IP, si tu enleves ca ca n'est plus du ssh.
On retombe sur un modele point a point apparemment, ce qui change
tout.
Si. Le principe d'indépendance des couches fait que je peux envisager
de faire passer du ssh dans autre chose que le sacro-saint
TCP-au-desus-d'IP, et que cela va rester du ssh.
Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.
Donc en fait il y a plusieurs boulots, et ils peuvent être faits par
des gens différents.
Non. SSL est transporté par TCP.
Apres il y a la cas particulier de IPsec mais la oui on touche
explicitement a la couche 3.
Donc, on peut transporter au dessus d'une couche 3 un serice de couche 3.
Bon, je propose SSL + TCP est de couche 4, comme TCP.
Je ne veux pas etre de mauvaise fois, mais ssh est fait pour etre
transporte par du TCP/IP, si tu enleves ca ca n'est plus du ssh.
On retombe sur un modele point a point apparemment, ce qui change
tout.
Si. Le principe d'indépendance des couches fait que je peux envisager
de faire passer du ssh dans autre chose que le sacro-saint
TCP-au-desus-d'IP, et que cela va rester du ssh.
Bon, plus exactement, la couche 4 s'occupe du bon acheminement entre
deux entités de sessions, ou faire un multiplexage des sessions.
C'est la notion de "port" dans UDP.
Donc en fait il y a plusieurs boulots, et ils peuvent être faits par
des gens différents.
Non. SSL est transporté par TCP.
Apres il y a la cas particulier de IPsec mais la oui on touche
explicitement a la couche 3.
Donc, on peut transporter au dessus d'une couche 3 un serice de couche 3.
Bon, je propose SSL + TCP est de couche 4, comme TCP.
Arf, j'ai 4 mois pour être à l'aise avec tout ça sinon chuis mort !! ;-)
Arf, j'ai 4 mois pour être à l'aise avec tout ça sinon chuis mort !! ;-)
Arf, j'ai 4 mois pour être à l'aise avec tout ça sinon chuis mort !! ;-)
C'est un rajout et pas une composante a part entiere du protocole
comme pour IPv6.
Apres j'en sais fichtre rien pour IPv4. Mais fatalement ca fait
tripatouiller OSI dans tous les sens je suppose.
C'est un rajout et pas une composante a part entiere du protocole
comme pour IPv6.
Apres j'en sais fichtre rien pour IPv4. Mais fatalement ca fait
tripatouiller OSI dans tous les sens je suppose.
C'est un rajout et pas une composante a part entiere du protocole
comme pour IPv6.
Apres j'en sais fichtre rien pour IPv4. Mais fatalement ca fait
tripatouiller OSI dans tous les sens je suppose.
Je sais bien que "la couche d'un protocole se définit par les services
qu'il propose, pas en ajoutant 1 au numéro de la couche sur laquelle il
s'appuie". Relis mes posts, c'est pour ça que j'ai écrit "si on suit ton
raisonnement,...".
Tu dis ici exactement ce que j'essaie de faire comprendre à Vincent,
Donc on peut dire alors que ssh fait le travail
d'une partie de TCP sur un bout du chemin
Donc il fournit plutôt des services de
niveau 4 ? Enfin, dans tous les cas, ssh est capable de fournir des
services de niveau 3 ou 4, selon comment il fait le travail, et c'est
sans doute 4.
Exactement comme SSL, qui bien qu'encapsulé dans du TCP, fournit des
services de niveau 4.
Je sais bien que "la couche d'un protocole se définit par les services
qu'il propose, pas en ajoutant 1 au numéro de la couche sur laquelle il
s'appuie". Relis mes posts, c'est pour ça que j'ai écrit "si on suit ton
raisonnement,...".
Tu dis ici exactement ce que j'essaie de faire comprendre à Vincent,
Donc on peut dire alors que ssh fait le travail
d'une partie de TCP sur un bout du chemin
Donc il fournit plutôt des services de
niveau 4 ? Enfin, dans tous les cas, ssh est capable de fournir des
services de niveau 3 ou 4, selon comment il fait le travail, et c'est
sans doute 4.
Exactement comme SSL, qui bien qu'encapsulé dans du TCP, fournit des
services de niveau 4.
Je sais bien que "la couche d'un protocole se définit par les services
qu'il propose, pas en ajoutant 1 au numéro de la couche sur laquelle il
s'appuie". Relis mes posts, c'est pour ça que j'ai écrit "si on suit ton
raisonnement,...".
Tu dis ici exactement ce que j'essaie de faire comprendre à Vincent,
Donc on peut dire alors que ssh fait le travail
d'une partie de TCP sur un bout du chemin
Donc il fournit plutôt des services de
niveau 4 ? Enfin, dans tous les cas, ssh est capable de fournir des
services de niveau 3 ou 4, selon comment il fait le travail, et c'est
sans doute 4.
Exactement comme SSL, qui bien qu'encapsulé dans du TCP, fournit des
services de niveau 4.
Enfin c'est plus compliqué : dans IPv6, on peut choisir IP ou IPsec en
guise de couche 3, mais on a pas l'une qui transporte l'autre.
Ah bon. Et dans IPv4 ?
Enfin c'est plus compliqué : dans IPv6, on peut choisir IP ou IPsec en
guise de couche 3, mais on a pas l'une qui transporte l'autre.
Ah bon. Et dans IPv4 ?
Enfin c'est plus compliqué : dans IPv6, on peut choisir IP ou IPsec en
guise de couche 3, mais on a pas l'une qui transporte l'autre.
Ah bon. Et dans IPv4 ?
Donc ne te casse pas la tete.
Connais les differentes fonctionnalités des diverses couches OSI.
Sache a quoi c'est "equivalent" dans les autres modeles.
Et ne t'embete pas avec les histoire d'encapsulation de
sous-protocoles car tu sors completment du modele.
Meme les specialistes discutent sans fin et ne sont pas toujours
d'accord de la maniere dont on colle IP sur le modèle OSI.
Donc ne te casse pas la tete.
Connais les differentes fonctionnalités des diverses couches OSI.
Sache a quoi c'est "equivalent" dans les autres modeles.
Et ne t'embete pas avec les histoire d'encapsulation de
sous-protocoles car tu sors completment du modele.
Meme les specialistes discutent sans fin et ne sont pas toujours
d'accord de la maniere dont on colle IP sur le modèle OSI.
Donc ne te casse pas la tete.
Connais les differentes fonctionnalités des diverses couches OSI.
Sache a quoi c'est "equivalent" dans les autres modeles.
Et ne t'embete pas avec les histoire d'encapsulation de
sous-protocoles car tu sors completment du modele.
Meme les specialistes discutent sans fin et ne sont pas toujours
d'accord de la maniere dont on colle IP sur le modèle OSI.
