La saturation d'adresses IP ( 2008 +/- 3ans)
Changements
de l'en-tête IPv4 -> IPv6
Trame IPv4
|
|
|
| Header Lenght (IHL) | Supprimé |
| ToS | Flow Label |
| ID, Flags et Fragment Offset (FO) | Supprimés |
| TTL | Hop Limit |
| Protocol | Next header (mêmes valeurs que dans IPv4) |
| Header CS | Supprimé |
| Adresses 32 bits (4octets) | Adresses 128 bits (16 Octets) |
| Alignement 32 bits | Alignement 64 bits |
|
|
|
| Vers | Version Number (=6) |
| Trafic Class | priorité ou classes de trafic (Differenciated Services) |
| Flow Label | Marquage des paquets "spéciaux" |
| Payload lenght | Longueur
des données utiles (en octets) autorise les paquets > 64 octets (payload = 0 et longueur du paquet inscrit dans l'option Hop By Hop) |
| Next Header | Il identifie le prochain en-tête. Il peut s'agir d'un protocole (UDP,TCP,ICMP) ou de la désignation d'une autre extension |
| Hop Limit | -1
à chaque fois que le paquet est commuté par un équipement
si Hop Limit = 0 le paquet est détruit -> Permet de réduire l'effet des bouclages de routage. |
| Source Address | Adresse de l'émetteur initial du paquet |
| Destination Address | Adresse de destination . Peut être différente de l'adresse finale si l'option "Routing Header" est présente |
Les options
|
|
|
| Hop-By-Hop Header | Transport d'information qui doit être examiné sur chaque noeud du chemin suivi par le datagramme IP |
| End-to-end Header | Transport d'information qui n'est à examiner que par le destinataire du datagramme |
| Routing Header | Routage
à partir de la source Liste de plusieurs noeuds intermédiaires "à visiter" au cours de l'acheminement du datagramme "Reverse bit " Si = 1 utiliser les informations de routage pour le retour sinon résoudre le routage à partir de l'extrémité destinataire |
| Fragment Header | Envoi
de paquets plus long que le MTU Maximum Transmission Unit : 512 -> 1500 octets MTU Minimun 576 octets la fragmentation n'est effectuée que par la source |
| Authentification Header | Authentification et intégrité des données |
| Privacy Header | Chiffrement
des données à protéger datagramme TCP/UDP ou datagramme IPv6 entier, à la demande |
Dans la
nouvelle version 6 d'IP, des informations complémentaires sont codées
dans des en-têtes qui doivent être placés dans le paquet
entre l'en-tête IPv6 l'en-tête de la couche transport. Il y a
un petit nombre d'extensions d'en-tête, chacun identifié par
une valeur de Next Header distincte. Comme illustré dans les exemples
suivants, un paquet IPv6 peut comporter aucune, une ou plus d'en-têtes
supplémentaires.
Repésentation des adresses
Une adresse Ipv6 est codée sur 128 bits. Les adresses sont représentées sous une nouvelle notation héxadécimale séparée par des double points :
FEDC:BA98:7654:3210:EDBC:A987:6543:210F
Plusieurs
champs nuls consécutifs peuvent être abrégés par
"::" de la manière suivante:
FEDC:0:0:0:400:A987
….. => FEDC::400:A987 …..
La représentation
des préfixes est similaire à la notation CIDR (Classeless Internet
Domain Routing) utilisée avec IPv4. Ces préfixes permettent
de caractériser le type d’adresse:
Adresse-ipv6
/ longueur du préfixe en bits
3EDC:BA98:7654:3210::/64 (Dans cet exemple, le préfixe est l'adresse IPv6)
Les Types d'adresses
Il y a 3 types d'adresses : Unicast, Multicast et Anycast
Il n'y a pas d'adresses de broadcast dans la version d'IPv6.
Les adresses Unicast
Plan d'adressage agrégé
Après de
multiples discussions le plan d'adressage agrégé (Aggregatable
Global Unicast Address Format) a été
retenu parmi les 4 plans étudiés (géographique,fournisseur,GSE,agrégé).
normalisé RFC 2373 & 2374.
Topologie publique (48 bits) :
Elle est constituée par l'ensemble des prestataires de services et des points d'échanges de connectivité IP. Les différentes subdivisions sont :
Le préfixe
: 2000::/3.
Une unité
d'agrégation haute : TLA (Top Level Aggregator) sur 18 bits.
Des unités
d'agrégation basses : NLA (Next Level Aggregator) dont la longueur
totale est de 32 bits. Le découpage de cette partie est laissé
libre au responsable de l'unité d'agrégation haute.
Topologie de site (16 bits) :
Site Level Aggregator. Elle est sous la responsabilité du gestionnaire du site. Il peut hiérarchiser son plan d'adressage.
Identificateur d'interface (64 bits) :
Il sert à distinguer les interfaces connectées. Les plans précédents suggéraient des champs de 48 bits correspondants aux adresses MAC IEEE 802. Celui proposé par le plan GSE et utilisé dans ce plan est un champ de 64 bits (format MAC EUI-64) permettant une identification globale. Ceci nous permet de construire des adresses mondialement uniques. Cette caractéristique est particulièrement intéressante pour les prochaines versions du protocole TCP qui pourra s'en servir comme identificateur de connexion.
Comme tous les identifiants d'interface n'ont pas 64 bits, il a fallu créer des méthodes afin d'y parvenir :
Si une interface avait une adresse de format IEEE EUI-64, sa structure serait de ce type. Le bit u vaut 0 si l'identifiant est universel. Le bit g à 1 indique que c'est une adresse de groupe multicast.
Si une interface avait une adresse de type MAC IEEE 802 à 48 bits universelle (Ethernet par exemple), on ajoute16 bits (0xFFFE) entre le numéro du constructeur et le numéro de série:
Adresse de lien-local
Leur validité est restreinte aux interfaces directement connectées entre elles sur le même lien sans routeur intermédiaire : Ethernet, connexion PPP,... Ces adresses sont utilisées par les protocoles de configuration des adresses globales, de découverte des voisins (remplaçant ARP) et de découverte de routeurs. Elles sont et doivent être uniques sur le lien. Le préfixe est FE80::/64.
Adresse de site local
Les adresses locales sont employées pour des sites ou des organisations qui ne sont pas (encore) connectés au monde Internet. Pour accéder à ce dernier, il n'est pas besoin d'en faire la demande ou de "voler" un préfixe d'adresse depuis le monde Internet, l'adresse locale suffit. Lorsque l'organisation veut se connecter au monde Internet, elle forme ses adresses globales en remplaçant le préfixe local par un préfixe souscripteur. Le préfixe est : FEC0::/48
Adresse indéterminée
L'adresse
0:0:0:0:0:0:0:0 est appelée adresse indeterminée (unspecified).
Elle ne doit être affectée à aucun noeud. Elle indique
l'absence d'adresse. Par exemple, on peut la trouver dans le champ d'une adresse
source de n'importe quels datagrammes envoyés par une station "initialisée"
avant que cette dernière n'est réussie à constituer sa
propre adresse.
L'adresse
indéterminée ne doit pas être employée comme adresse
destination des datagrammes ou dans les en-têtes de routage d'IPv6.
Adresse de bouclage
L'adresse unicast FE00:0:0:0:0:0:0:1 est appelée adresse de bouclage. Elle est utilisée par un noeud pour envoyer un datagramme à lui-même. Elle n'est affectée à aucune interface. L'adresse de bouclage ne doit pas être utilisée comme adresse source de datagrammes envoyés à l'extérieur du noeud.
Encapsulation des adresses Ipv4 (transition IPv6)
La première forme d'adresse est conçue pour représenter les adresses IPv4 des noeuds IPv4 (les noeuds ne peuvent pas comprendre le protocole IPv6) en adresses IPng.
L' adresse est conçue pour être utilisée par les noeuds IPv6 qui ont besoin de "dialoguer" avec des noeuds IPv4. On dira que ces adresses IPv4 sont compatibles IPv6.
Les adresses Multicast
Le préfixe
est FF00::/8. Le champs flag permet de définir si l'adresse est permanente
(T=0) ou temporaire (T=1). Le champ scope délimite le niveau
de diffusion du paquet. Si l'on place celui-ci à "2" (lien: link-local
scope), on évite d'envoyer les paquets d'une vidéoconférence
(par exemple) sur tout l'Internet. C'est cette méthode qui remplace
le connu time-to-live d'IPv4. Voici les valeurs possibles de champ scope :
|
|
| 0 : réservé |
| 1 : nœud (node-local scope) |
| 2 : lien (link-local scope) |
| 5 : site (site-local scope) |
| 8 : organisation (organisation-local scope) |
| E : global (global scope) |
| F : réservé |
Il est à noter qu'un paquet IPv6 ne peut avoir comme adresse source une adresse multicast.
Adresses multicast prédéfinies
Reserved
Multicast Address: FF0s:0:0:0:0:0:0:0.
Ces adresses
multicast (avec une valeur de scope, s) sont réservées, et ne
devront être assignées à aucun groupe multicast.
All Nodes
Adresses:
FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
Ces adresses
multicast identifient le groupe de tous les noeuds IPv6, à l'intérieur
d'une étendue intra-noeud (scope=1) ou intra-liaison (scope=2).
All Hosts
Adresses:
FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
Ces adresses
multicast identifient le groupe de toutes les stations IPv6, à l'intérieur
d'une étendue intra-noeud (scope=1) ou intra-liaison (scope=2).
All Routers
Adresses:
FF01:0:0:0:0:0:0:3
FF02:0:0:0:0:0:0:3
Ces adresses
multicast identifient le groupe de tous les routeurs IPv6, à l'intérieur
d'une étendue intra-noeud (scope=1) ou intra-liaison (scope=2).
Les adresses Anycast
Le trait
particulier de ce genre d'adresse est qu'un paquet anycast ayant comme destination
un groupe anycast n'est pas envoyé à toutes les
interfaces
de ce groupe, mais uniquement à une de celles-ci. En général
c'est l'interface la plus proche (au sens de la métrique des protocoles
de routage : RIPng, OSPF) qui est choisie.
Le principe
de l'anycast n'en est encore qu'à son stade de recherche. On ne peut,
à ce jour, attribuer une telle adresse qu'à un routeur. Il n'existe,
de
plus,
qu'une seule sorte de groupe qui possède une adresse anycast pour un
sous-réseau.
Un paquet
IPv6 ne peut avoir comme adresse source une adresse anycast.
Découverte des voisins (Neighbor Discovery)
Neighbor Discovery regroupe plusieurs protocoles utilisés par IPv4 tels que ARP ou la redirection d'adresses. Ce protocole n'utilise que cinq types de messages ICMPv6 avec la particularité que le champ nombre de sauts vaut 255. Ceci indique que le message provient du lien local et non de l'extérieur dans quel cas il sera rejeté.
les principales
fonctionnalités sont :
Les cinq types de paquets ICMP spécifiés par le protocole Neighbor Discovery sont :
équipement les voisins qui sont devenus inaccessibles (panne, changement d'adresse, ..).
Autoconfiguration à mémoire état
Cette méthode se base sur le modèle client-serveur et utilise le protocole DHCPv6 (Dynamic Host Configuration Protocol) . Ce dernier s'appuie sur le protocole BOOTP et la version IPv4 de DHCP
Le serveur mémorise l'état du client, fournit l'adresse IPv6 et des paramètres de configuration du client.
Le client émet des requêtes et des acquittements (selon le protocole DHCP).
Autoconfiguration sans état
Cette
méthode utilise le protocole ICMPv6. Il s'agit de construire une
adresse globale à partir de l'adresse MAC de la machine et des annonces
de préfixes faites par les routeurs sur le même lien. Ce mecanisme
ne s'applique pas aux routeurs.
Path : ensembles des liens traversés par un paquet IPv6 entre
la source et la destination (chemin)
link MTU : taille maximal de l'unité de transmission (un paquet)
qui peut être transporter sur le lien sans fragmentation
Patch MTU (pMTU) : = Min(link MTU) pour un path donné
Path MTU Discovery découverte automatique du pMTU pour un path
donné
Actions du protocole
Fait l'hypothèse
que pMTU = link MTU pour atteindre un voisin. S'il y a un équipement
intermédiaire et link MTU < pMTU, on a l'émission du message
"Packed Size Too Large". La source réduit le pMTU en utilisant l'information
contenue dans le paquet ICMPv6
Pour supporter
la qualité de service, il faut pouvoir différencier et garantir
certains flux.
Les champs supportant la Qos sont "Flow label" et "Tr.Class" dans l'entête . Ces champs serviront comme indicateur à l'hôte pour identifier les paquets nécessitant une manutention spéciale des routeurs compatible V6. Les routeurs pourront ainsi procéder à un service en temps réel ou de qualité soutenue.
La différenciation
de services permet d'offrir plus de bande passante en fonction de l'abonnement
choisi :
meilleur
temps de réponse pour les entreprises, meilleur rentabilisation des
infrastructures pour les fournisseurs.
Définition expérimentale du champ Traffic Class (1 octet)
Evolution vers DIFFSERV
L'IETF travaille sur un mécanisme , Diffserv, transformant l'internet en réseau de services différenciés. Il offrira à chaque application le niveau de performance requis. Le champs (Tos)sous Ipv4 ou champ en-tête sous IPv6 sert à classifier les paquets. Désormais appelé DS (Diffserv) ce champ de 8 bits est composé de deux parties :
La classe EF permet de garantir une certaine bande passante à chaque noeud, elle serait un peu l'équivalent d'une liaison louée. La classe AF permet de définir quatre priorité de traffic ayant différents niveaux de bande passante (Or, Argent, Bronze, Best Effort). Enfin pour les clients ne désirant pas de services différenciés, la classe DE, correspond à l'actuel service de base de l'Internet.
Principe
Réseau mère :
Pour tout de
même recevoir les paquets qu'ils lui sont envoyés, le mobile
a besoin d'une adresse temporaire, en plus de son adresse mère.
Cette adresse
est obtenue grâce au protocole d'autoconfiguration avec ou sans état.
Il est à noter que le mobile a la possibilité d'avoir plusieurs
adresses temporaires.
Associations :
L'avantage de ces associations est qu'elles permettent de diminuer la durée de transit des paquets en les routant tout de suite à la bonne adresse. Les données nécessaires à la création de ces associations sont transmises par l'intermédiaire de l'extension destination (p.*) lors de l'échange de paquets IPv6. Ces données sont contenues dans les options suivantes de l'extension destination :
Mise à
jour de l'association (Binding Update) : utilisée par le mobile
pour avertir un destinataire de son association courante, donc son adresse
temporaire. L'association
du mobile avec son agent mère est appelée enregistrement principal.
Acquittement
de l'association (Binding Acknoledge) : accuse la réception du
message précédent. Un en-tête d'authentification est
nécessaire
pour garantir
la provenance du message. L'adresse destination ne peut donc pas être
modifiée sans invalider cet en-tête. C'est pour cette raison
que
les paquets provenants
de l'agent mère en direction du mobile doivent être encapsulés
(tunnellés).
Demande de
mise à jour de l'association (Binding Request) : cette option
est souvent utilisée par un correspondant pour mettre à jour
son
association avec
un mobile. L'émetteur recevra en retour un message de mise à
jour de l'association.
Adresse principale
(Home address) : informe le correspondant de son adresse mère.
Les nouveaux correspondants connus avec l'adresse
temporaire pourront
ainsi toujours communiquer avec le mobile lorsque celui-ci aura regagné
son réseau mère.
La notion de sécurité
est intégrée dans ce nouveau protocole. Les services constituants
sont : l'authentification, l'intégrité, la confidentialité
(RFC
2401 -
2411 ).
elle est indépendante
des algorithmes de chiffrement (champ SAID : Security Association Identifier
: type de clé, durée de vie, algo...), l'administration des
clés est séparée. Les fonctions de sécurité
sont optionnelles, elles n'affectent pas les autres utilisateurs
L'authentification et intégrité
L'authentification consiste à garantir que les données reçues proviennent bien de l'entité identifiée par l'adresse source. L'intégrité utilise les mécanismes de signatures numériques pour garantir que les données n'ont pas été modifiées. C'est le résultat d'un calcul sur les données et champs d'en-têtes qui ne changent pas (hop count ..exclus) avec une clé secrète. Par défaut l'algorithme MD5 est utilisé de préférence entre sation d'origine et station de destination. cependant MD5 est obligatoire sur les stations IPv6
Confidentialité
Elle permet de
protéger les données circulant sur le réseau de manière
à ce quelles soient compréhensiblesque par les personnes autorisées.
Ce sont des algorithmes
à clé symétrique qui sont utilisés pour le transport
des données. Cette clé étant souvent utilisée
pour le chiffrement des informations, elle est donc vulnérable. Elle
est changée régulièrement via le réseau en utilisant
cette fois une clé asymétrique.
Le premier mot de 32 bits de cette extension contient l'indice des paramètres de sécurité SPI. Cet indice détermine quelle association de sécurité est employée.
Il existe deux modes de confidentialité : le mode de transport bout en bout où même les informations des niveaux supérieurs sont chiffrées et le mode tunnel entre deux passerelles où les paquets entiers sont chiffrés et encapsulés.
Il n'y a pas de
protection contre l'analyse de trafic
Le principal objectif de la transition vers IPv6 est double. Il doit permettre à des stations de travail implémentant IPv6 et/ou IPv4 de communiquer entre-elles ainsi qu'à des stations et des routeurs IPv6 d'être déployés sur l'Internet de manière incrémentale et à grande échelle. A ceci, un troisième objectif sous-jacent consiste à proposer une transition la plus simple possible pour tous les utilisateurs finaux, les administrateurs de réseaux et les opérateurs réseaux.
En effet, la transition vers IPv6 se fera en deux temps. (RFC 1752).
Seront d'abord introduites des stations supportant les deux versions, qui
communiqueront en encapsulant les datagrammes IPv6 dans les datagrammes IPv4
(tunneling), de manière à traverser les routeurs en place
implémentant IPv4.
Puis de nouveaux routeurs (dotés d'un logiciel IPv6) assureront les
fonctions d'encapsulation / de désencapsulation ou celles de traduction.
Ainsi, ces deux modes de communication seront donc possibles : l'encapsulation
des datagrammes et/ou la traduction de l'en-tête IP. Cette étape
est particulièrement cruciale, puisqu'elle met en jeu la viabilité
même d'Internet.
Encapsulation
de trames IPv4 dans des trames IPv6
La modification
de la taille des adresses a des conséquences sur l'usage des protocoles
de l'IETF et de ceux qui sont associés à IP. Ainsi, ARP, RARP,
BOOTP ou ICMP doivent être modifiés, tout comme les protocoles
de routage RIP (version 2), IDRP, OSPF, BGP, IS-IS. Enfin, une grande partie
des protocoles de niveau supérieur, FTP, DNS, SNMP devront prendre
en compte cette migration.
Afin de faciliter
la transition vers IPv6, un certain nombre de mécanismes obligatoires
et optionnels sont définis comme ceux évoqués précédemment.
Toutes ces techniques sous-entendent l'apparition d'un certain nombre d'issues
opérationnelles.
Cependant, ces objectifs ne pourront se réaliser aisément sans les caractéristiques suivantes définies dans SIT (Simple IPv6 Transition).
Les stations de travail et les routeurs actuels supportant IPv4 doivent s'adapter à IPv6 à tout moment sans recourir à d'autres stations ou routeurs intégrant déjà IPv6.
Aujourd'hui déja,
un bon nombre de routeurs fonctionnent en IPv6. Ils forment le 6bone: l'épine
dorsale IPv6 (voir cartes: Schéma
général, L'Europe,
Le
monde).
De plus, des patches
(mises à jour) existent déja pour tous les systèmes Unix,
Windows NT, Windows 95, MacOS ...)
Le 6-Bone
Le 6-bone est un réseau expérimental construit au-dessus de l'Internet IPv4 (tunnels) lancé le 15 juillet 1996 par 3 sites (WIDE/JP, UNI/DK, G6/FR). il compte aujourd'hui 400 sites et 27 pays
Le 6-Bone est constitué de nuages de machines connectées en IPv6 et de tunnels IPv4 pour les interconnecter. Le 6bone est un réseau de test, pas de production. A ce jour, les standards et les implémentations existent, il faut les déployer. A terme le réseau 6bone sera remplacé de façon transparente par les ISP (Internet Service Provider ) et autres réseaux publics Internet.
Le 6-REN
Les réseaux d'éducation et de recherche (REN) doivent contribuer à IPv6. ils doivent créer des réseaux de production IPv6 permettant d'utiliser des applications réelles. Le 6REN veut promouvoir et coordonner un service IPv6 de niveau production. Le 6REN à le rôle de coordinateur.
Le G6
Le G6 est le groupe français d'expérimentation IPv6, créé fin 1995 et animé par Alain Durand IMAG et Bernard Tuy UREC. Le G6 regroupe des académies et des industriels : CNRS, ENST, INRIA, Bull, Dassault Electronique, Eurocontrol...
Le
G6-Bone
Le G6-Bone est
l'infrastructure qui interconnecte les plates-formes de test françaises.
C'est la branche française du 6Bone. Le G6 est un groupe ouvert à
tous ceux qui veulent partager l'expérience acquise sur la mise en
oeuvre et la supervision du (des) protocoles IPv6 sur les équipements
traditionnels. Les évolutions en cours (dans le cadre de Renater 2)
vont permettre de commencer à expérimenter le trafic sur des
liaisons natives (IPv6/ATM). La phase ultime étant d'acheminer le trafic
IPv6 comme le trafic IPv4 sans distinction.
Livres
URLs
http://www.urec.cnrs.fr/ipv6/Biblio.html
http://phoebe.urec.fr/G6/
http://www.6bone.net
http://www.sun.com
http://www.hp.com
http://www.cisco.fr
http://www.rennes.enst-bretagne.fr
Dernière mise à jour en Janvier 2000