Difference between revisions of "AdressageBis-Recherches"

From Livre IPv6
(→‎Structuration des adresses et agrégation)
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{Suivi|AdressageBis-Questions|Questions Ouvertes|AdressageBis-Historique|Historique}}
 +
 +
=La recherche et IPv6=
 +
 +
A priori, la recherche autour d'IPv6 peut sembler dépasser car la nouvelle version du protocole IP arrive à maturité. Mais d'un autre côté, il ne faut surtout pas penser qu’IPv6 n’est qu’une recopie d’IPv4 avec des tailles d’adresses beaucoup plus grandes pour faire face à la pénurie. Certaines industries ont bien compris l’importance de cette nouvelle version du protocole IP. Ainsi les travaux sur les réseaux de capteurs se font uniquement sur cette version du protocole. Zigbee a récemment annoncé que la pile protocolaire allait l’inclure. L’industrie automobile a également fait ce choix…
 +
 +
L’utilisation que l'on fait actuellement d’IPv6 n’est évidemment pas la panacée et son usage ne doit pas être figé. En IPv4, l’espace d’adressage étant saturé, il est impossible d’inclure d’autres modes de fonctionnement que le routage hiérarchique. En IPv6 cette limitation saute et des pistes de recherche à plus ou moins long terme peuvent intéresser l’industrie des télécommunications ou des services :
 +
 +
*l’adressage peut se structurer différemment. Il peut prendre en compte d’autres paradigmes de routage, comme le routage géographique. Les réseaux de capteurs, les ITS, les applications militaires, auraient besoin de cette fonction pour  non plus communiquer avec des équipements précis, mais un équipement quelconque se trouvant autour d’une position donnée;
 +
*la généralisation des supports d’accès fait qu’un site ou un équipement sera connecté a plusieurs opérateurs qui offriront des services différents. Il n’existe à l’heure actuelle aucune solution satisfaisante pour gérer ce type d’architecture, même si des briques de base sont étudiées (SCTP, Shim6, etc.);
 +
*la sécurité est évidemment un enjeu majeur qui est souvent mis en avant pour justifier une refonte de l’Internet. Il faut voir à quel niveau doit se faire cette refonte, est-il nécessaire de changer les protocoles de transmission de l’information (IP, TCP, UDP) ou architecturer différemment le réseau et utiliser les possibilités de l’adressage pour rendre le communications plus sûres. Les approches CGA et HBA sont des pistes intéressantes à suivre.
 +
 +
IPv6 va servir de pivot pour l’évolution à moyen et long terme du réseau. En effet, un langage commun à tous les équipements réseaux a été le facteur clé qui a permis à l’Internet actuel de se développer. Ce chapitre a pour but de présenter des travaux de recherche autour de l'adressage. Le premier chapitre décrit l'adressage actuel, l'évolution des tables de routage dans le coeur du réseau et les méthodes pour prévoir la date où l'espace d'adresses IPv4 sera épuisé.
 +
 +
Si la transition vers IPv6 a beaucoup tardé, celà est dû en grande partie au fait que l'Internet v4 continue à fonctionner correctement même si des signes tangibles montrent qu'une dégradation de la connectivité pourrait se produire. À titre d'exemple, certains travaux présentés au chapitre « Prolonger la vie d'IPv4 » s'intéressent au partage d'une adresse IPv4 entre plusieurs utilisateurs.
 +
 
== Structuration des adresses et agrégation ==
 
== Structuration des adresses et agrégation ==
  
 
Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de router des ensembles de réseaux identifiés par un seul descripteur. CIDR apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec les adresses déjà allouées.
 
Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de router des ensembles de réseaux identifiés par un seul descripteur. CIDR apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec les adresses déjà allouées.
  
−
Attribuer une adresse à un équipement est un processus complexe, basé sur un compromis entre la facilité d'attribution et la facilité de gestion. Idéalement, pour minimiser la taille de routage, le réseau devrait avoir une topologie en arbre, cela rendrait l'adressage hiérarchique très efficace. Dans la réalité pour des raisons économiques, techniques, géographiques ou de performances, le réseau est beaucoup plus complexe et peut être vu comme un graphe. Il faut introduire des exceptions dans les tables de routages pour refléter cette topologie. On voit que pour avoir l'adressage le plus efficace possible, il faut dans ce graphe trouver la représentation arborescente qui génère le moins d'exceptions possibles. Or s'il était possible aujourd'hui de trouver une représentation valide, elle ne le sera pas nécessairement demain. En conséquence, la définition du plan d'adressage doit être la plus souple possible pour permettre une évolution de nature imprévisible.
+
Attribuer une adresse à un équipement est un processus complexe, basé sur un compromis entre la facilité d'attribution et la facilité de gestion. Idéalement, pour minimiser la taille de la table de routage, le réseau devrait avoir une topologie en arbre, cela rendrait l'adressage hiérarchique très efficace. Dans la réalité pour des raisons économiques, techniques, géographiques ou de performances, le réseau est beaucoup plus complexe et peut être vu comme un graphe. Il faut introduire des exceptions dans les tables de routages pour refléter cette topologie. On voit que pour avoir l'adressage le plus efficace possible, il faut dans ce graphe trouver la représentation arborescente qui génère le moins d'exceptions possibles. Or s'il était possible aujourd'hui de trouver une représentation valide, elle ne le serait pas nécessairement demain. En conséquence, la définition du plan d'adressage doit être la plus souple possible pour permettre une évolution de nature imprévisible.
  
 
D'autant plus que l'agrégation pour IPv4 ne semble plus aussi efficace. La figure suivante donne l'évolution de table de routage dans le coeur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.  
 
D'autant plus que l'agrégation pour IPv4 ne semble plus aussi efficace. La figure suivante donne l'évolution de table de routage dans le coeur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.  
  
−
[[Image:Cidr.png|thumb|frame|Evolution de la taille des tables de routage<br>Source: http://www.cidr-report.org]]
+
[[Image:CIDR.png|thumb|frame|Evolution de la taille des tables de routage<br>Source: http://www.cidr-report.org]]
  
 
En 2000, la progression linéaire de cette table a semblé compromise du fait :
 
En 2000, la progression linéaire de cette table a semblé compromise du fait :
  
−
* de la baisse du coût des liaisons longues distances, permettant une multi-domiciliation (''multi-homing'') des sites pour des raisons de fiabilité (en cas de panne d'un opérateur, le trafic pourra passer par un autre), de performances (aller directement sur le réseau avec lequel le site à un trafic important),
+
* de la baisse du coût des liaisons longues distances, permettant une multi-domiciliation (''multi-homing'') des sites pour des raisons de fiabilité (en cas de panne d'un opérateur, le trafic pourra passer par un autre), de performances (aller directement sur le réseau avec lequel le site à un trafic important);
 
* le manque d'adresses IPv4 qui force les opérateurs à allouer des préfixes de plus en plus long.
 
* le manque d'adresses IPv4 qui force les opérateurs à allouer des préfixes de plus en plus long.
  
 
Depuis, les opérateurs ont fortement aggrégé pour revenir à une progression linéaire de la table. Des études [[bibliographie#BTC02|[BTC02]]] montrent que :
 
Depuis, les opérateurs ont fortement aggrégé pour revenir à une progression linéaire de la table. Des études [[bibliographie#BTC02|[BTC02]]] montrent que :
  
−
* la multi-domiciliation, c'est-à-dire la connexion d'un site à plusieurs opérateurs pour fiabiliser l'accès, ajoute un surcoût de 20 à 30 pourcent,
+
* la multi-domiciliation, c'est-à-dire la connexion d'un site à plusieurs opérateurs pour fiabiliser l'accès, ajoute un surcoût de 20 à 30%;
−
* le partage de charge, c'est-à-dire réduire l'agregation pour annoncer un sous-ensemble de préfixe à chaque opérateur, induit un surcoût de 20 à 25 pourcent,
+
* le partage de charge, c'est-à-dire réduire l'agregation pour annoncer un sous-ensemble de préfixe à chaque opérateur, induit un surcoût de 20 à 25%;
−
* de mauvaises règles d'agrégation induisent une surcharge de 15 à 20 pourcent,
+
* de mauvaises règles d'agrégation induisent une surcharge de 15 à 20%;
−
* la fragmentation de l'espace d'adressage liée à la gestion des préfixes avant CIDR, et à l'allocation séquencielle des blocks d'adresses contribue à plus de 75 pourcent de la taille de la table.
+
* la fragmentation de l'espace d'adressage liée à la gestion des préfixes avant CIDR et à l'allocation séquentielle des blocs d'adresses contribue à plus de 75% de la taille de la table.
  
−
Actuellement, pour pouvoir assurer une bonne agrégation, les règles utilisées par CIDR pour IPv4 sont conservées. Mais la gestion des tables de routage dans le coeur du réseau s'en trouvera quand même améliorée car :
+
Actuellement, pour pouvoir assurer une bonne agrégation, les règles utilisées par CIDR pour IPv4 sont conservées. Mais la gestion des tables de routage dans le cœur du réseau s'en trouvera quand même améliorée car :
  
−
* dès le début le plan d'adressage est hiérarchique, éliminant les longs préfixes,
+
* dès le début le plan d'adressage est hiérarchique, éliminant les longs préfixes;
−
* les sites multi-domiciliés posséderont autant d'adresses que de fournisseurs, permettant ainsi de garantir une agrégation.
+
* les sites multi-domiciliés posséderont autant d'adresses que de fournisseurs, permettant ainsi de garantir une agrégation;
−
* des mécanismes de renumérotation automatiques permettent aux sites de changer facilement de préfixe quand cela est nécessaire.
+
* des mécanismes de renumérotation automatique permettent aux sites de changer facilement de préfixe quand cela est nécessaire.
  
 
Si un plan d'adressage hiérarchique semble actuellement le plus adapté, d'autres règles de numérotation pourraient être utilisées dans le futur, comme par exemple, les coordonnées géographiques de l'équipement. Ces techniques ne sont actuellement utilisées que dans quelques laboratoires de recherche pour des réseaux ad hoc, mais il reste assez de place dans l'espace d'adressage pour prendre en compte ces nouveaux types de réseaux si un jour ils se généralisent.
 
Si un plan d'adressage hiérarchique semble actuellement le plus adapté, d'autres règles de numérotation pourraient être utilisées dans le futur, comme par exemple, les coordonnées géographiques de l'équipement. Ces techniques ne sont actuellement utilisées que dans quelques laboratoires de recherche pour des réseaux ad hoc, mais il reste assez de place dans l'espace d'adressage pour prendre en compte ces nouveaux types de réseaux si un jour ils se généralisent.
  
 
Le choix d'un plan d'adressage a fait l'objet de nombreux débats à l'IETF. Il a été beaucoup plus difficile à définir que le format du paquet IPv6 présenté au chapitre suivant. Plusieurs plans ont été proposés puis abandonnés. Ces divers plans d'adressages sont commentés dans le chapitre sur l'[[La standardisation d'IPv6#plan|Historique]] de la standardisation d'IPv6. Le présent chapitre se contente de décrire les différents [[plans d'adressage]] actuellement utilisés.
 
Le choix d'un plan d'adressage a fait l'objet de nombreux débats à l'IETF. Il a été beaucoup plus difficile à définir que le format du paquet IPv6 présenté au chapitre suivant. Plusieurs plans ont été proposés puis abandonnés. Ces divers plans d'adressages sont commentés dans le chapitre sur l'[[La standardisation d'IPv6#plan|Historique]] de la standardisation d'IPv6. Le présent chapitre se contente de décrire les différents [[plans d'adressage]] actuellement utilisés.
−
 
  
 
== Évolution de l'adressage ==
 
== Évolution de l'adressage ==
  
−
La distinction entre les notions d'annuaires, de noms, d'adresses et de routes est comprise depuis longtemps. Cependant, depuis quelques années, au sein de l'Internet, la compréhension du rôle d'une adresse réseau a évolué. Dans l'Internet, une adresse sert en fait à deux fonctions distinctes : identification et localisation.
+
La distinction entre les notions d'annuaires, de noms, d'adresses et de routes est comprise depuis longtemps. Cependant, depuis quelques années, au sein de l'Internet, la compréhension du rôle d'une adresse réseau a évolué. Dans l'Internet, une adresse sert en fait à deux fonctions distinctes : identification et localisation;
  
−
* L'identification est utilisée pendant une connexion par chacun des intervenants pour reconnaître son interlocuteur. Cela permet entre autres de s'assurer de l'origine des paquets reçus. <br> Cette vérification se fait dans les pseudo-en-têtes TCP ou dans les associations de sécurité d'IPsec. La durée de vie minimale d'un identificateur est celle d'une connexion TCP.
+
* l'identification est utilisée pendant une connexion par chacun des intervenants pour reconnaître son interlocuteur. Cela permet entre autres de s'assurer de l'origine des paquets reçus. <br> Cette vérification se fait dans les pseudo-en-têtes TCP ou dans les associations de sécurité d'IPsec. La durée de vie minimale d'un identificateur est celle d'une connexion TCP;
−
* La localisation est utilisée pour trouver un intermédiaire qui saura délivrer les paquets. La durée de vie de la fonction de localisation est assez grande. En fait, elle ne varie qu'en cas de changement de prestataire IP ou de réorganisation du site. <br> En général la localisation est découpée en deux parties : localisation globale (identifiant le réseau) et locale, distinguant les machines sur un même réseau. La localisation est intrinsèquement liée aux fonctions de routage d'IP.
+
* la localisation est utilisée pour trouver un intermédiaire qui saura délivrer les paquets. La durée de vie de la fonction de localisation est assez grande. En fait, elle ne varie qu'en cas de changement de prestataire IP ou de réorganisation du site. <br> En général la localisation est découpée en deux parties : localisation globale (identifiant le réseau) et locale, distinguant les machines sur un même réseau. La localisation est intrinsèquement liée aux fonctions de routage d'IP.
  
−
En IPv4, on confond identification et localisation en une seule entité, l'adresse IP, globalement unique dans l'Internet. Cette construction a un prix : lors de la renumérotation d'un site, ou lorsqu'un mobile se déplace, la localisation change. Avec l'approche IPv4, l'adresse IP change, et donc l'identification... Cela implique une perte ou au mieux une renégociation des communications en cours.
+
En IPv4, on confond identification et localisation en une seule entité, l'adresse IP, globalement unique dans l'Internet. Cette construction a un prix : lors de la renumérotation d'un site, ou lorsqu'un mobile se déplace, la localisation change. Avec l'approche IPv4, l'adresse IP change, et donc l'identification… Cela implique une perte ou au mieux une renégociation des communications en cours.
  
−
Lors des études initiales pour IPv6, il a été proposé de séparer ces deux fonctions pour pouvoir résoudre simplement les problèmes de renumérotation, mobilité, multi-domiciliation... Ceci est encore un sujet de recherche. Cette proposition n'a donc pas été retenue ; en IPv6 comme en IPv4, l'adresse sert à la fois pour l'identification et la localisation. En effet, le plan d'adressage choisi dans un premier temps est une extension des règles d'adressage hiérarchiques (CIDR) utilisées dans IPv4.
+
Lors des études initiales pour IPv6, il a été proposé de séparer ces deux fonctions pour pouvoir résoudre simplement les problèmes de renumérotation, mobilité, multi-domiciliation… Ceci est encore un sujet de recherche. Cette proposition n'a donc pas été retenue; en IPv6 comme en IPv4, l'adresse sert à la fois pour l'identification et la localisation. En effet, le plan d'adressage choisi dans un premier temps est une extension des règles d'adressage hiérarchique (CIDR) utilisées dans IPv4.
  
−
Un autre débat est de savoir si une adresse identifie une machine ou une interface. Cette distinction n'est pas très importante dans le cas d'une machine simple ne possédant qu'une seule interface ; elle le devient dans le cas où elle en possède plusieurs ou est multi-domiciliée. En effet pour essayer de simplifier les tables de routage dans le coeur de réseau, si un site est connecté à plusieurs fournisseur d'accès, il possèdera autant de préfixes IPv6 que de fournisseurs. Contrairement à IPv4, où l'on associe généralement qu'une seule adresse à une interface, une interface possède plusieurs adresses IPv6.
+
Un autre débat est de savoir si une adresse identifie une machine ou une interface. Cette distinction n'est pas très importante dans le cas d'une machine simple ne possédant qu'une seule interface; elle le devient dans le cas où elle en possède plusieurs ou est multi-domiciliée. En effet pour essayer de simplifier les tables de routage dans le cœur de réseau, si un site est connecté à plusieurs fournisseur d'accès, il possèdera autant de préfixes IPv6 que de fournisseurs. Contrairement à IPv4, où l'on associe généralement qu'une seule adresse à une interface, une interface possède plusieurs adresses IPv6.
  
 
==Gestion de la Multi-domiciliation==
 
==Gestion de la Multi-domiciliation==
Line 49: Line 64:
 
La gestion de la multi-domociliation ('''multi-homing''') est encore un sujet de débat dans les groupes. Aucune solution n'est satisfaisante car le routage des paquets dans un domaine multi-domicilié se fait uniquement (comme dans tous l'Internet) sur l'adresse de la source. Si la machine choisit une adresse d'un fournisseur et que les paquets sont routés vers un autre, ce dernier va rejeter le paquet car l'adresse source ne correspond pas à une adresse qu'il a officiellement attribué.
 
La gestion de la multi-domociliation ('''multi-homing''') est encore un sujet de débat dans les groupes. Aucune solution n'est satisfaisante car le routage des paquets dans un domaine multi-domicilié se fait uniquement (comme dans tous l'Internet) sur l'adresse de la source. Si la machine choisit une adresse d'un fournisseur et que les paquets sont routés vers un autre, ce dernier va rejeter le paquet car l'adresse source ne correspond pas à une adresse qu'il a officiellement attribué.
  
−
Ce problème se résoud en IPv4 en attribuant aux sites multi-domiciliés des adresses PI ('''Provider Independant'''). Le site passe des accords avec ses fournisseurs pour qu'ils acceptent ces adresses. Les PI offrent aussi une très grande stabilité dans l'adressage puisque les adresses appartiennent à l'entreprie. En contre partie, les PI conduisent à une explosion des tables de routage dans le cœur du réseau.
+
Ce problème se résout en IPv4 en attribuant aux sites multi-domiciliés des adresses PI ('''Provider Independent'''). Le site passe des accords avec ses fournisseurs pour qu'ils acceptent de router ces adresses. Les PI offrent aussi une très grande stabilité dans l'adressage puisque les adresses appartiennent à l'entreprise. En contre partie, les PI conduisent à une explosion des tables de routage dans le cœur du réseau et ne garantissent pas à l'entreprise un routage universel : n'étant pas agrégées dans des supernets, les annonces de PI peuvent être refusées car la taille du réseau annoncé peut être sous le seuil autorisé (typiquement /24).
  
−
IPv6 aurait IPv6 a essayé de résoudre le problème en offrant la possibilité d'affecter une adresse IPv6 par fournisseur de service. Malheureusement cette solution ne permet pas de résoudre le problème car elle bute sur le choix de l'adresse source en coordination avec le routage. Plusieurs alternatives sont en cours d'étude:
+
IPv6 a essayé de résoudre le problème en offrant la possibilité d'affecter une adresse IPv6 par fournisseur de service. Malheureusement cette solution ne permet pas de résoudre le problème car elle bute sur le choix de l'adresse source en coordination avec le routage. Plusieurs alternatives sont en cours d'étude:
 
* utilisation des PI pour IPv6, mais avec le risque d'augmenter les tables de routage IPv6 dans le cœur du réseau. Comme, à court terme, il s'agit de la seule solution crédible, certaines autorités régionales offrent cette possibilité.
 
* utilisation des PI pour IPv6, mais avec le risque d'augmenter les tables de routage IPv6 dans le cœur du réseau. Comme, à court terme, il s'agit de la seule solution crédible, certaines autorités régionales offrent cette possibilité.
 
* le groupe [http://www.irtf.org/charter?gtype=rg&group=rrg RRG] (Routing Research Group) de l'IRTF, réfléchit à l'utilisation de tunnel entre les sites pour séparer les fonctions d'indentificateur et de localisateur de l'adresse.
 
* le groupe [http://www.irtf.org/charter?gtype=rg&group=rrg RRG] (Routing Research Group) de l'IRTF, réfléchit à l'utilisation de tunnel entre les sites pour séparer les fonctions d'indentificateur et de localisateur de l'adresse.
  
−
== Adresses de test ==
+
{{Suivi|AdressageBis-Questions|Questions Ouvertes|AdressageBis-Historique|Historique}}
−
 
+
−
Les expérimentations d'IPv6 sur un réseau devaient commencer avant que les règles d'attribution des préfixes soient complètement finalisées. La valeur 0x1FFE a été attribué par l'IANA au 6bone dans le plan d'adressage agrégé pour les expérimentations (RFC 3701). Il correspond au préfixe <tt>3FFE::/16</tt> pour l'ensemble du 6bone.
+
−
 
+
−
[[image:Fig3-4.jpg|thumb|right|350px|Figure 3-4 ''Adresse de test du plan agrégé'']]
+
−
 
+
−
Les 48 bits restant avant le champ Subnet ID recréent les niveaux hiérarchiques d'un réseau IPv6 défini dans le RFC 3587, d'où le terme pseudo accolé au nom du champ. La taille réduite n'étant pas un facteur limitant dans la phase expérimentale. Des pseudo-TLA d'une taille initialement de 8, mais portées à 12 bits par la suite, sont attribués à des opérateurs voulant expérimenter le protocole. Les 24 ou 20 bits suivants sont utilisés pour numéroter les sites.
+
−
 
+
−
Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. La liste complète est disponible sur le serveur Web http://www.6bone.net/6bone_pTLA_list.html. Le tableau Pseudo TLA attribués par le groupe ngtrans reprend quelques unes de ces valeurs.
+
−
 
+
−
{|
+
−
|+'''''Pseudo TLA attribués par le groupe ngtrans'''''
+
−
!Organismes/Pays!!Préfixe!! !!Organismes/Pays!!Préfixe
+
−
|-style="background:silver"
+
−
|ROOT66/US-CA||3FFE:0000::/24|| ||TRUMPET/AU||3FFE:8000::/28
+
−
|-
+
−
|TELEBIT/DK||3FFE:0100::/24|| ||ICM-PL/PL||3FFE:8010::/28
+
−
|-style="background:silver"
+
−
|SICS/SE||3FFE:0200::/24|| ||IIJ/JP||3FFE:8020::/28
+
−
|-
+
−
|G6/FR||3FFE:0300::/24|| ||QTPVSIX/EU||3FFE:8030::/28
+
−
|-style="background:silver"
+
−
|JOIN/DE||3FFE:0400::/24|| ||APAN-KR||3FFE:8040::/28
+
−
|-
+
−
|WIDE/JP||3FFE:0500::/24|| ||MIBH||3FFE:8050::/28
+
−
|-style="background:silver"
+
−
|SURFNET/NL||3FFE:0600::/24|| ||ATNET-AT||3FFE:8060::/28
+
−
|}
+
−
 
+
−
L'expérimentation lié au 6bone s'est terminée récemment; la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau a servi palier à l'absence d'opérateurs officiels au début de l'introduction d'IPv6, il a vite montré ses limites. L'utilisation de tunnels pour créer la connectivité a conduit à un trop fort maillage, à des routes relativement longues et par conséquence à une faible qualité de service.
+
−
 
+
−
<!--
+
−
 
+
−
== Adresses gérées par les RIR ==
+
−
 
+
−
La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délégation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de longueur supérieure ou égale à 48 bits.
+
−
 
+
−
Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire : par exemple machines branchées sur un même Ethernet, machines reliées par une connexion PPP, ou extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre noeuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]].
+
−
 
+
−
[[image:Fig3-5.jpg|thumb|right|400px|Figure 3-5 ''Adresse Lien_Local'']]
+
−
 
+
−
 
+
−
 
+
−
Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent pas à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]).
+
−
 
+
−
Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresse (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même noeud est autorisée.
+
−
 
+
−
Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.
+
  
−
Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.
+
==Prolonger la vie d'IPv4==
−
-->
+
Med: Trouver un autre titre que celui proposé par Laurent
  
−
==Selection du type d'identifiant d'interface==
+
Le ToC initialement proposé à Laurent:
  
−
Si l'on sélectionne correctement le type d'identifiant d'interface, la gestion de l'adressage IPv6 est aussi facile (voire plus simple) qu'en IPv6. Ainsi, il est préférable de donner aux serveurs des identifiants d'inteface construit manuellement. Il sera ainsi beaucoup plus facile de se rappeler de leur adresse. De plus si l'équipement est remplacé et par conséquent que la carte réseau est différente, l'adresse IPv6 restera stable. Pour les clients, il est plus simple d'utiliser l'identifiant d'interface construit à partir de l'adresse MAC.
+
1. Introduction
  
−
+
1.1 Contexte global
−
Les adresses site-local sont des adresses dont la validité était restreinte à un site. Par exemple, un site qui n'est pas encore connecté à l'Internet pouvait utiliser ces adresses, ce qui le dispensait de demander ou d'emprunter un préfixe. Ce système généralisait le concept d'adresse privée d'IPv4 (comme le réseau <tt>10.x.y.z</tt>). Un autre intérêt apparent des adresses site-local est qu'elles ne sont pas modifiées lors d'un changement de fournisseur de connectivité, qui ne perturbe donc pas les communications locales.
+
  
−
Une adresse site-local était construite en concaténant le préfixe <tt>FEC0::/48</tt>, un champ de 16 bits qui permet de définir plusieurs sous-réseaux, et les 64 bits de l'[[Identifiant d'interface|identifiant d'interface]].
+
1.2 Contribution du chapitre
  
−
[[image:Fig3-6.png|thumb|right|350px|Figure 3-6 ''Adresse Site_Local'']]
+
1.3 Structure
  
 +
2. Partage d'@ IPv4
  
−
Malgré ces propriétés, les adresses site-local n'ont pas réussi à s'imposer durant la phase de standardisation d'IPv6. Suivant les règles de l'IETF, elle doivent donc être retirées des documents pour la version finale du RFC décrivant IPv6. Le RFC 3879 décrit les problèmes liés à l'utilisation des adresses site-local. Contrairement à un lien facilement délimité par le support physique, la frontière du site est beaucoup plus vague. Il s'en suit des ambiguïtés qui rendent difficile l'utilisation de ce concept. En particulier, si un utilisateur est connecté à deux sites de deux companies différentes, l'adressage à plat offert par les adresses site-local rendent le routage difficile. Si le site dispose aussi d'adresses globales, l'ajout systématique d'adresses site-local rend également plus difficile le choix des adresses source et destination ainsi que la réponse aux requêtes DNS qui dépendent de la position de l'équipement demandeur.
+
2.1 Introduction
  
−
De plus si le réseau de deux companies fusionnent, comme l'adressage des sous-réseaux ne se fait que dans la partie Subnet ID, il y a de fortes chances de trouver des collisions dans les valeurs choisies.
+
2.2 Problèmes liés au partage d'@
  
−
<!--
+
3. L'approche CGN
−
=Recherche=
+
  
−
<font color=red>
+
3.1 Double NAT
  
 +
3.2 L'approche DS-lite
  
−
'''''LT: Je ne suis pas certain qu'il faille mettre ici cette discussion trompeuse sur le nombre d'adresse par mm2 car il ne s'agit pas vraiment des plans d'adressage, plutot le mettre dans la partie format de paquet pour indiquer les raisons d'un adressage de taille fixe'''''
+
4. L'approche A+P
  
−
Une adresse IPv6 est un mot de 128 bits. La taille d'une adresse IPv6 est le quadruple de celle d'une adresse IPv4. En prenant en compte les estimations les plus pessimistes et les plus optimistes [[bibliographie#BM95|[BM95]]], on obtient l'encadrement suivant où l'unité est le nombre d'adresses par mètre carré de surface terrestre (océans compris) :
+
4.1 Notion de Port Range
  
 +
4.2 Utilisation de Port Range en environnement IPv6
  
−
<math>1564 < adresses disponibles  < 3911873538269506102</math>
+
4.2.1 Aperçu
  
−
D'autres calculs indiquent que l'on pourrait potentiellement attribuer 60 000 milliards de milliards d'adresses par habitant.
+
4.2.2 Structure des préfixes/adresses IPv6
  
−
Ces calculs sont bien entendu complètement arbitraires. Il est difficile de prévoir l'utilisation des adresses dans les années futures. Ainsi, par exemple, le plan d'adressage actuellement mis en oeuvre utilise un identifiant d'équipement sur 64 bits, c'est-à-dire la moitié de la taille de l'adresse. En fait ce genre de calcul sert de justification aux partisans des adresses de taille fixe (ce qui simplifie le traitement des paquets) en montrant que le nombre d'équipements adressables est colossal.
+
4.3 Mode opératoire
  
−
Il ne faut toutefois pas faire un contre-sens sur l'interprétation de ces calculs. Le but d'IPv6 n'est pas d'attribuer une fois pour toute une adresse IPv6 à un équipement (ou à un être humain). Une adresse IPv6 n'a de sens et d'utilité que lors que l'équipement est connecté sur le réseau. De plus si l'emplacement sur le réseau de cet équipement change, l'adresse devra également être modifiée pour refléter ce déplacement.
+
4.3.1 Mode binding
  
−
</font>
+
4.3.2 Mode sans état
−
-->
+
  
−
<font color=red>Dans un premier temps, des adresses du type [[site-local]] dans l'espace <tt>FEC0::/10</tt> avaient été définies par l'IETF,
+
5. La pénurie dans le monde mobile
−
mais elles ont été retirées dans les dernières versions des standards.</font>
+
  
 +
5.1 Evolution des besoins d'adresses IP
  
−
Les adresses site-local sont des adresses dont la validité était restreinte à un site. Par exemple, un site qui n'est pas encore connecté à l'Internet pouvait utiliser ces adresses, ce qui le dispensait de demander ou d'emprunter un préfixe. Ce système généralisait le concept d'adresse privée d'IPv4 (comme le réseau <tt>10.x.y.z</tt>). Un autre intérêt apparent des adresses site-local est qu'elles ne sont pas modifiées lors d'un changement de fournisseur de connectivité, qui ne perturbe donc pas les communications locales.
+
5.2 Les solutions pour répondre à ces besoins
  
−
Une adresse site-local était construite en concaténant le préfixe <tt>FEC0::/48</tt>, un champ de 16 bits qui permet de définir plusieurs sous-réseaux, et les 64 bits de l'[[Identifiant d'interface|identifiant d'interface]].
+
5.2.1 Ingénierie CGN
  
−
[[image:Fig3-6.png|thumb|right|350px|Figure 3-6 ''Adresse Site_Local'']]
+
5.2.2 Ingénierie A+P
  
 +
6. Conclusions et perspectives
  
−
Malgré ces propriétés, les adresses site-local n'ont pas réussi à s'imposer durant la phase de standardisation d'IPv6. Suivant les règles de l'IETF, elle doivent donc être retirées des documents pour la version finale du RFC décrivant IPv6. Le RFC 3879 décrit les problèmes liés à l'utilisation des adresses site-local. Contrairement à un lien facilement délimité par le support physique, la frontière du site est beaucoup plus vague. Il s'en suit des ambiguïtés qui rendent difficile l'utilisation de ce concept. En particulier, si un utilisateur est connecté à deux sites de deux companies différentes, l'adressage à plat offert par les adresses site-local rendent le routage difficile. Si le site dispose aussi d'adresses globales, l'ajout systématique d'adresses site-local rend également plus difficile le choix des adresses source et destination ainsi que la réponse aux requêtes DNS qui dépendent de la position de l'équipement demandeur.
+
7. Références
  
−
De plus si le réseau de deux companies fusionnent, comme l'adressage des sous-réseaux ne se fait que dans la partie Subnet ID, il y a de fortes chances de trouver des collisions dans les valeurs choisies.
+
==L'adressage géographique==

Latest revision as of 14:00, 27 February 2010

Questions Ouvertes Table des matières Historique

La recherche et IPv6

A priori, la recherche autour d'IPv6 peut sembler dépasser car la nouvelle version du protocole IP arrive à maturité. Mais d'un autre côté, il ne faut surtout pas penser qu’IPv6 n’est qu’une recopie d’IPv4 avec des tailles d’adresses beaucoup plus grandes pour faire face à la pénurie. Certaines industries ont bien compris l’importance de cette nouvelle version du protocole IP. Ainsi les travaux sur les réseaux de capteurs se font uniquement sur cette version du protocole. Zigbee a récemment annoncé que la pile protocolaire allait l’inclure. L’industrie automobile a également fait ce choix…

L’utilisation que l'on fait actuellement d’IPv6 n’est évidemment pas la panacée et son usage ne doit pas être figé. En IPv4, l’espace d’adressage étant saturé, il est impossible d’inclure d’autres modes de fonctionnement que le routage hiérarchique. En IPv6 cette limitation saute et des pistes de recherche à plus ou moins long terme peuvent intéresser l’industrie des télécommunications ou des services :

  • l’adressage peut se structurer différemment. Il peut prendre en compte d’autres paradigmes de routage, comme le routage géographique. Les réseaux de capteurs, les ITS, les applications militaires, auraient besoin de cette fonction pour non plus communiquer avec des équipements précis, mais un équipement quelconque se trouvant autour d’une position donnée;
  • la généralisation des supports d’accès fait qu’un site ou un équipement sera connecté a plusieurs opérateurs qui offriront des services différents. Il n’existe à l’heure actuelle aucune solution satisfaisante pour gérer ce type d’architecture, même si des briques de base sont étudiées (SCTP, Shim6, etc.);
  • la sécurité est évidemment un enjeu majeur qui est souvent mis en avant pour justifier une refonte de l’Internet. Il faut voir à quel niveau doit se faire cette refonte, est-il nécessaire de changer les protocoles de transmission de l’information (IP, TCP, UDP) ou architecturer différemment le réseau et utiliser les possibilités de l’adressage pour rendre le communications plus sûres. Les approches CGA et HBA sont des pistes intéressantes à suivre.

IPv6 va servir de pivot pour l’évolution à moyen et long terme du réseau. En effet, un langage commun à tous les équipements réseaux a été le facteur clé qui a permis à l’Internet actuel de se développer. Ce chapitre a pour but de présenter des travaux de recherche autour de l'adressage. Le premier chapitre décrit l'adressage actuel, l'évolution des tables de routage dans le coeur du réseau et les méthodes pour prévoir la date où l'espace d'adresses IPv4 sera épuisé.

Si la transition vers IPv6 a beaucoup tardé, celà est dû en grande partie au fait que l'Internet v4 continue à fonctionner correctement même si des signes tangibles montrent qu'une dégradation de la connectivité pourrait se produire. À titre d'exemple, certains travaux présentés au chapitre « Prolonger la vie d'IPv4 » s'intéressent au partage d'une adresse IPv4 entre plusieurs utilisateurs.

Structuration des adresses et agrégation

Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de router des ensembles de réseaux identifiés par un seul descripteur. CIDR apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec les adresses déjà allouées.

Attribuer une adresse à un équipement est un processus complexe, basé sur un compromis entre la facilité d'attribution et la facilité de gestion. Idéalement, pour minimiser la taille de la table de routage, le réseau devrait avoir une topologie en arbre, cela rendrait l'adressage hiérarchique très efficace. Dans la réalité pour des raisons économiques, techniques, géographiques ou de performances, le réseau est beaucoup plus complexe et peut être vu comme un graphe. Il faut introduire des exceptions dans les tables de routages pour refléter cette topologie. On voit que pour avoir l'adressage le plus efficace possible, il faut dans ce graphe trouver la représentation arborescente qui génère le moins d'exceptions possibles. Or s'il était possible aujourd'hui de trouver une représentation valide, elle ne le serait pas nécessairement demain. En conséquence, la définition du plan d'adressage doit être la plus souple possible pour permettre une évolution de nature imprévisible.

D'autant plus que l'agrégation pour IPv4 ne semble plus aussi efficace. La figure suivante donne l'évolution de table de routage dans le coeur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.

Evolution de la taille des tables de routage
Source: http://www.cidr-report.org

En 2000, la progression linéaire de cette table a semblé compromise du fait :

  • de la baisse du coût des liaisons longues distances, permettant une multi-domiciliation (multi-homing) des sites pour des raisons de fiabilité (en cas de panne d'un opérateur, le trafic pourra passer par un autre), de performances (aller directement sur le réseau avec lequel le site à un trafic important);
  • le manque d'adresses IPv4 qui force les opérateurs à allouer des préfixes de plus en plus long.

Depuis, les opérateurs ont fortement aggrégé pour revenir à une progression linéaire de la table. Des études [BTC02] montrent que :

  • la multi-domiciliation, c'est-à-dire la connexion d'un site à plusieurs opérateurs pour fiabiliser l'accès, ajoute un surcoût de 20 à 30%;
  • le partage de charge, c'est-à-dire réduire l'agregation pour annoncer un sous-ensemble de préfixe à chaque opérateur, induit un surcoût de 20 à 25%;
  • de mauvaises règles d'agrégation induisent une surcharge de 15 à 20%;
  • la fragmentation de l'espace d'adressage liée à la gestion des préfixes avant CIDR et à l'allocation séquentielle des blocs d'adresses contribue à plus de 75% de la taille de la table.

Actuellement, pour pouvoir assurer une bonne agrégation, les règles utilisées par CIDR pour IPv4 sont conservées. Mais la gestion des tables de routage dans le cœur du réseau s'en trouvera quand même améliorée car :

  • dès le début le plan d'adressage est hiérarchique, éliminant les longs préfixes;
  • les sites multi-domiciliés posséderont autant d'adresses que de fournisseurs, permettant ainsi de garantir une agrégation;
  • des mécanismes de renumérotation automatique permettent aux sites de changer facilement de préfixe quand cela est nécessaire.

Si un plan d'adressage hiérarchique semble actuellement le plus adapté, d'autres règles de numérotation pourraient être utilisées dans le futur, comme par exemple, les coordonnées géographiques de l'équipement. Ces techniques ne sont actuellement utilisées que dans quelques laboratoires de recherche pour des réseaux ad hoc, mais il reste assez de place dans l'espace d'adressage pour prendre en compte ces nouveaux types de réseaux si un jour ils se généralisent.

Le choix d'un plan d'adressage a fait l'objet de nombreux débats à l'IETF. Il a été beaucoup plus difficile à définir que le format du paquet IPv6 présenté au chapitre suivant. Plusieurs plans ont été proposés puis abandonnés. Ces divers plans d'adressages sont commentés dans le chapitre sur l'Historique de la standardisation d'IPv6. Le présent chapitre se contente de décrire les différents plans d'adressage actuellement utilisés.

Évolution de l'adressage

La distinction entre les notions d'annuaires, de noms, d'adresses et de routes est comprise depuis longtemps. Cependant, depuis quelques années, au sein de l'Internet, la compréhension du rôle d'une adresse réseau a évolué. Dans l'Internet, une adresse sert en fait à deux fonctions distinctes : identification et localisation;

  • l'identification est utilisée pendant une connexion par chacun des intervenants pour reconnaître son interlocuteur. Cela permet entre autres de s'assurer de l'origine des paquets reçus.
    Cette vérification se fait dans les pseudo-en-têtes TCP ou dans les associations de sécurité d'IPsec. La durée de vie minimale d'un identificateur est celle d'une connexion TCP;
  • la localisation est utilisée pour trouver un intermédiaire qui saura délivrer les paquets. La durée de vie de la fonction de localisation est assez grande. En fait, elle ne varie qu'en cas de changement de prestataire IP ou de réorganisation du site.
    En général la localisation est découpée en deux parties : localisation globale (identifiant le réseau) et locale, distinguant les machines sur un même réseau. La localisation est intrinsèquement liée aux fonctions de routage d'IP.

En IPv4, on confond identification et localisation en une seule entité, l'adresse IP, globalement unique dans l'Internet. Cette construction a un prix : lors de la renumérotation d'un site, ou lorsqu'un mobile se déplace, la localisation change. Avec l'approche IPv4, l'adresse IP change, et donc l'identification… Cela implique une perte ou au mieux une renégociation des communications en cours.

Lors des études initiales pour IPv6, il a été proposé de séparer ces deux fonctions pour pouvoir résoudre simplement les problèmes de renumérotation, mobilité, multi-domiciliation… Ceci est encore un sujet de recherche. Cette proposition n'a donc pas été retenue; en IPv6 comme en IPv4, l'adresse sert à la fois pour l'identification et la localisation. En effet, le plan d'adressage choisi dans un premier temps est une extension des règles d'adressage hiérarchique (CIDR) utilisées dans IPv4.

Un autre débat est de savoir si une adresse identifie une machine ou une interface. Cette distinction n'est pas très importante dans le cas d'une machine simple ne possédant qu'une seule interface; elle le devient dans le cas où elle en possède plusieurs ou est multi-domiciliée. En effet pour essayer de simplifier les tables de routage dans le cœur de réseau, si un site est connecté à plusieurs fournisseur d'accès, il possèdera autant de préfixes IPv6 que de fournisseurs. Contrairement à IPv4, où l'on associe généralement qu'une seule adresse à une interface, une interface possède plusieurs adresses IPv6.

Gestion de la Multi-domiciliation

La gestion de la multi-domociliation (multi-homing) est encore un sujet de débat dans les groupes. Aucune solution n'est satisfaisante car le routage des paquets dans un domaine multi-domicilié se fait uniquement (comme dans tous l'Internet) sur l'adresse de la source. Si la machine choisit une adresse d'un fournisseur et que les paquets sont routés vers un autre, ce dernier va rejeter le paquet car l'adresse source ne correspond pas à une adresse qu'il a officiellement attribué.

Ce problème se résout en IPv4 en attribuant aux sites multi-domiciliés des adresses PI (Provider Independent). Le site passe des accords avec ses fournisseurs pour qu'ils acceptent de router ces adresses. Les PI offrent aussi une très grande stabilité dans l'adressage puisque les adresses appartiennent à l'entreprise. En contre partie, les PI conduisent à une explosion des tables de routage dans le cœur du réseau et ne garantissent pas à l'entreprise un routage universel : n'étant pas agrégées dans des supernets, les annonces de PI peuvent être refusées car la taille du réseau annoncé peut être sous le seuil autorisé (typiquement /24).

IPv6 a essayé de résoudre le problème en offrant la possibilité d'affecter une adresse IPv6 par fournisseur de service. Malheureusement cette solution ne permet pas de résoudre le problème car elle bute sur le choix de l'adresse source en coordination avec le routage. Plusieurs alternatives sont en cours d'étude:

  • utilisation des PI pour IPv6, mais avec le risque d'augmenter les tables de routage IPv6 dans le cœur du réseau. Comme, à court terme, il s'agit de la seule solution crédible, certaines autorités régionales offrent cette possibilité.
  • le groupe RRG (Routing Research Group) de l'IRTF, réfléchit à l'utilisation de tunnel entre les sites pour séparer les fonctions d'indentificateur et de localisateur de l'adresse.
Questions Ouvertes Table des matières Historique

Prolonger la vie d'IPv4

Med: Trouver un autre titre que celui proposé par Laurent

Le ToC initialement proposé à Laurent:

1. Introduction

1.1 Contexte global

1.2 Contribution du chapitre

1.3 Structure

2. Partage d'@ IPv4

2.1 Introduction

2.2 Problèmes liés au partage d'@

3. L'approche CGN

3.1 Double NAT

3.2 L'approche DS-lite

4. L'approche A+P

4.1 Notion de Port Range

4.2 Utilisation de Port Range en environnement IPv6

4.2.1 Aperçu

4.2.2 Structure des préfixes/adresses IPv6

4.3 Mode opératoire

4.3.1 Mode binding

4.3.2 Mode sans état

5. La pénurie dans le monde mobile

5.1 Evolution des besoins d'adresses IP

5.2 Les solutions pour répondre à ces besoins

5.2.1 Ingénierie CGN

5.2.2 Ingénierie A+P

6. Conclusions et perspectives

7. Références

L'adressage géographique

Retrieved from "http://livre.g6.asso.fr/index.php?title=AdressageBis-Recherches&oldid=4648"
Personal tools