Difference between revisions of "Historique de la standardisation d’IPv6"

From Livre IPv6

m (L'IESG (''Internet Engineering Steering Group''))
(Les RIR (Regional Internet Registries))
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
{{suivi |Les applications spécifiques|Les applications spécifiques|La standardisation d'IPv6|La standardisation d'IPv6}}
 
Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.
 
Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.
  
Line 25: Line 26:
 
===Les RFC (''Request For Comments'')===
 
===Les RFC (''Request For Comments'')===
  
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2002, nous en sommes au numéro 3221, pour un flux supérieur à 200 RFC par an.
+
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2006, nous en sommes au numéro 4400, pour un flux supérieur à 200 RFC par an.
 
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.
 
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.
  
Line 36: Line 37:
 
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué.  Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".
 
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué.  Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".
  
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou ''Best Current Practice''). Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC Best Current Practice documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.
+
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou "''Best Current Practice''". Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC "''Best Current Practice''" documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.
  
 
===L'ISOC (Internet Society)===
 
===L'ISOC (Internet Society)===
Line 55: Line 56:
 
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base).  C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.
 
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base).  C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.
  
===Les RIR (Regional Internet Registries)===
+
===<div id="RIR">Les RIR (Regional Internet Registries)</div>===
  
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de trois actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à celle échelle. Ce sont :
+
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de quatre actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à cette échelle. Ce sont :
 
*APNIC : Asia Pacific Network Information Centre,
 
*APNIC : Asia Pacific Network Information Centre,
 
*ARIN : American Registry for Internet Numbers,
 
*ARIN : American Registry for Internet Numbers,
Line 64: Line 65:
  
 
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs
 
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs
 +
{{suivi |Les applications spécifiques|Les applications spécifiques|La standardisation d'IPv6|La standardisation d'IPv6}}

Latest revision as of 13:29, 13 June 2006

Les applications spécifiques Table des matières La standardisation d'IPv6

Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.

La standardisation de l'Internet

Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet. Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.

L'IETF (Internet Engineering Task Force)

L’activité au sein de l'’ETF est organisée en groupes de travail (working group). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après). Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations. Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (Working Group Chairs). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418. Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (Internet Drafts), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (Request For Comments). Quand un groupe considère que ses objectifs sont atteints, il se dissout. Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:

  • IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.
  • NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde.

Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).

L'IESG (Internet Engineering Steering Group)

L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans le RFC 2028. C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.

Les RFC (Request For Comments)

Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2006, nous en sommes au numéro 4400, pour un flux supérieur à 200 RFC par an. Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (Standard Track) et les autres.

Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (Proposed Standard).

Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.

Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.

Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".

La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou "Best Current Practice". Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC "Best Current Practice" documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.

L'ISOC (Internet Society)

L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels. La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet. Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.

L’IAB (Internet Architecture Board)

L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.

L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.

L’ICANN (Internet Corporation for Assigned Names and Numbers)

L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.

Les RIR (Regional Internet Registries)

Les RIR ou RIAR (Regional Internet Address Registries) reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de quatre actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à cette échelle. Ce sont :

  • APNIC : Asia Pacific Network Information Centre,
  • ARIN : American Registry for Internet Numbers,
  • RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),
  • LACNIC : Réseaux d'Amérique Latine et des Caraïbes.

Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs

Les applications spécifiques Table des matières La standardisation d'IPv6
Personal tools